ThunderCat

Первое что приходит в голову - конвертировать игровую валюту в реальные вещи/услуги, например за условный миллион фантиков поход с папой в интересное место - зоопарк, аквапарк, кино, роллердром, просто в кафе.

Так же, в списке может быть что-то полезное из материального, например моя племяшка обожает книги, что сильно облегчает мне выбор подарков. Книга, одежда/обувь или бижутерия вполне могут быть призом.

Что касается внутриигрового контента - вполне можно попробовать на какой-нибудь полубирже (Яндекс Задания, Воркзилла) заказать набор спрайтов для игры у студентов за шапку сухарей. Генерится на компе за пару часов, у многих уже готовые сборки нейронок стоят локально, по этому особо проблем с платным Миджорней/Дали уже нету.

Что касается разных персонажей, вроде использование сида (заранее заданного числа которое задает некоторую рандомность начальной генерации) создает низкую вариативность нечетко прописанных вещей, делая упор на описанные детали. Так можно получить вариации одежды на одинаковых персонажах.

Если для написания тз у вас не хватает компетенций, то для начала сделайте юзерстори и/или майндмап. Распишите все возможные действия пользователя + желательно самые простые картинки как это +- выглядит и как работает. Во первых оцEните объем работ, во вторых откроете для себя кучу нюансов различного характера, в третьих с этим уже можно идти к более-менее адекватной команде за ПРИМЕРНЫМ ценником.

Более простой путь - тыкнуть пальцем в готовое решение и сказать "хочу такое". Минус - скорее всего как при реализации так и при приеме вы можете упустить часть функционала (что впрочем может случиться и в первом варианте), так же, в любом случае административная часть чужого проекта вам будет недоступна и ее нужно будет описывать самому.

Ну и третий путь, скажем так, совсем кривая дорожка - взять готовые решения, кои всегда существуют для популярных задач. Плюсы - дешево и быстро. Минус - скорее всего качество околоплинтусное.

Варианты перехода с Bootstrap 3 на Bootstrap 5:
1. Постепенная миграция (Hybrid approach)

Подключить Bootstrap 5 с префиксом классов
Переписывать компоненты по одному
Использовать CSS-изоляцию для избежания конфликтов
Плюсы: Сайт остается рабочим, можно мигрировать частями
Минусы: Увеличенный размер CSS, сложность поддержки

2. Использование Bootstrap Migration Tool

Автоматические инструменты для замены классов
Скрипты для массовой замены в файлах
Плюсы: Быстрая автоматизация базовых изменений
Минусы: Не покрывает все кейсы, нужна ручная доработка

3. Создание CSS-моста (Polyfill)

Написать CSS-правила для совместимости классов BS3
Создать алиасы для старых классов
Плюсы: Минимальные изменения в HTML
Минусы: Не все компоненты можно эмулировать, устаревший подход

4. Полная перепись с нуля

Установить Bootstrap 5
Переписать все компоненты и страницы
Плюсы: Современный код, лучшая производительность
Минусы: Много времени, высокий риск поломок

5. Использование CSS-in-JS или препроцессоров

Создать миксины для совместимости
Использовать SCSS для переопределения
Плюсы: Гибкость настройки
Минусы: Нужны знания препроцессоров

6. Bootstrap 4 как промежуточный этап

Сначала мигрировать на BS4, потом на BS5
Плюсы: Меньше кардинальных изменений за раз
Минусы: Двойная работа

7. Микросервисный подход

Переписывать отдельные секции сайта на новом Bootstrap
Постепенно заменять старые части
Плюсы: Изолированные изменения
Минусы: Сложность интеграции

Для больших проектов: Постепенная миграция (#1)
Для средних проектов: Bootstrap 4 как промежуточный этап (#6)
Для небольших сайтов: Полная перепись (#4)
При ограниченном времени: CSS-мост (#3)

это делает сайт более уязвимым к XSS атакам.

Нет, скорее это наносит больший ущерб в случае удачной атаки, к самой защите от атак это никак не относится.

Так что же лучше, устанавливать куки стороне клиента или сервере?

Что лучше, мягкое или теплое? Разные куки подходят для разных задач. Если речь все еще про токены и авторизацию - только бэкенд.

По началу я устанавливал куки и помещал в них токен на стороне бекенда, так-же удалял куки, с этим способом возникли некоторые проблемы.

Некоторые проблемы очевидно решаются, судя по тому что миллионы программистов с этим как-то справляются. Очевидно надо искать как решаются типовые задачи вместо поиска черных костылей в темной комнате.

По моему вы пытаетесь переизобрести реакт/вуе.
Простой ответ - react router.

Как мне их правильно соединить?

Во первых - зачем? Смысл разноса api и приложения в том что бэк работает одинаково со всеми запросами (не особо важно кто и как их дергает, лишь бы права позволяли), а фронт не зависит от бэка в представлении. По этому фронт пишется как морда на каком-нибудь реакте, который от бэкенда получает данные по запросу. Нужно авторизоваться - стучишся в эндпоинт авторизации, отдаешь креденшелы, получаешь токен. Нужно список юзеров - берешь доку по апи, стучишся с нужным пэйлоадом на эндпоинт, получаешь жсон списка, из него рисуешь что хочешь...
Во вторых -

Или frontend и backend размещены разными программами?

что-то мне подсказывает что наверное вы рановато по знаниям взялись за задачу...

пути к файлам пишут от корня сайта, а не от папки темплейта, соответственно если документ рут у вас в app_dir, то путь должен быть src="/static/img.png" и src="/templates/img.png"

https://web.archive.org/web/20120420212500/http://...

И заметила, что основная часть задач - инфраструктурная.

Такой работы всегда много, но есть нюансы.

Настройка тестов

Да, это в любой разработке будет, не только во фронте

CI/CD

Сомнительно, но окэй, знать это очень желательно, но в крупных проектах этим занимается девопс, как минимум настраивает скрипты. В малых компаниях это раскидывается на разрабов, есть такая практика.

OLAP CUBE, оптимизация запросов к БД.

А это вообще чисто бэкендерские заморочки, конечно никто бить за понимание таких штук не будет, но в целом фронту это не особо важно, у него должно быть расписано апи/эндпоинты и чего туда пихать и что получать. Уж оптимизацией запросов чистый фронтендер точно не обязан заниматься.

Вообще описанное больше похоже на позицию фуллстек. "В быту" фронт не особо занимается именно интерфейсами, чаще всего это уже сделал дизайнер, задача фронтера - сверстать и оживить, ну реакт, вуе, реквесты-отрисовка и вот это все...

Извините, но
Первое - определить проблему. Как базовый вариант - ларавель дебагбар + телескоп. Смотреть что и как по времени отрабатывает, смотреть какие куски тормозят, делать точечные замеры исполнения. Обратить внимание на количество и качество запросов, вполне возможно что где-то натыкано левых или кривых запросов, еще и настаканных по 200 штук...
Второе - 80% что тормозит не код, а бд, но тут это чисто статистическое предположение, так как что там у вас в базе никто не знает. Проверьте запросы, долговыполняющиеся прогнать руками через експлэйн, проверить наличие нужных индексов и отсутствие ненужных.
Если критических косяков нет, то даже весьма средняя машинка потянет некрупный проект с небольшой базой.

FF + AdGuard?
Алсо, что-то типа тампермонки/оранжмонки...

1) Указывайте язык, который используете, телепаты в отпуске. Ок, из кода понятно что питон, но в вопросе об этом ничего не написано.
2) Так как структура данных у вас хранится в коде (что однозначно не айс), подойдут словари с соответствующей вложенностью - регион : области. Из него через .keys() и list() получаем регионы, а по регионам уже и области в виде списка получить можно. Алсо, я бы хранил словарь в отдельном файле как json, что сделает работу с кодом независимой от данных.
3) Все еще не вижу причин издеваться над пользователем через консоль. Страничка с 2 полями и запрос на сервер, вроде в питоне даже свой какой-то вебсервер есть искаропки.

Насколько известно, REST не хранит состояние клиента между запросам.

Это не значит что он вообще не хранит состояние клиента, это значит что он хранит только состояние на момент синхронизации, а МЕЖУ запросами состояние клиента находится в неопределенном состоянии до момента следующей синхронизации. То есть это не принцип который надо соблюдать, а констатация факта. Кроме того, в вашем примере бэкенду/апи вообще должно быть фиолетово на состояние клиента.

Клиент передаёт необходимые данные в первом запросе. Эти данные меняют состояние сущности (лабиринт) на сервере.

Сущность лабиринт НИКАК не затрагивается, у вас может изменяться только принадлежащие вам сущности, в данном примере у вас будет меняться состояние робота.

Если бы клиент располагал всеми данными,

то он был бы бэкендом и апи было бы не нужно. Собственно апи - способ обмена запрашиваемыми данными.

Последующие запрос-ответы связаны с предыдущими, не имеют смысла без выполнения предыдущих, поскольку сервер хранит изменяемую сущность (лабиринт).

Не лабиринт.

Как серию "запрос-ответ" логически объединить?

Зависит. Так как вопрос у вас на пальцах и вообще без конкретики, то и ответ будет достаточно общим в рамках описанной системы.
1) Вы не работаете с сущностью лабиринт, вы работаете с сущностью робот, которая имеет некоторое положение/координаты в лабиринте.
2) Сущность робот имеет уникальный идентификатор - id, по которому вы однозначно можете определить какой конкретно робот вами будет задействован. Собственно при первом запросе апи должно вам в числе прочего вернуть id робота и его положение.
3) Запрос к апи для получения позиции робота на момент следующего запроса примерно: GET someapi.tld/api/v1/robot/{id}, в результате назад вы получите объект робота с координатами. Что с ними делать зависит от вашего функционала, например можно задать новые целевые координаты.
4) Если вам нужно чтобы роботы принадлежали конкретным пользователям, вводим ключи/авторизацию, через которую апи будет определять что робот 55 принадлежит Василию Пупкину, и только он может менять координаты данного робота. Читать соответствующие мануалы.