Fronteer

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

Функционал:

• карта с локациями;
• инвентарь, экипировка, взаимодействие с предметами;
• диалоги с NPC с гибкой системой состояний и событийной моделью;
• крафтинг предметов;
• квесты с гибкой системой состояний и триггерами;
• сражения (PvE, PvP);
• рынок с игроками.

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

Бэкенд пишется на микросервисной архитектуре. Стек: Clean Architecture, Python+GRPC, Postgres, Redis, Kafka, Yandex.Cloud.

Перед выполнением задачи стоял вопрос архитектуры бэкенда: либо stateful игровые сервера с периодической синхронизацией с базой данных, либо stateless сервера с очередью сообщений и распределённым кэшем для масштабирования. Второй вариант означал чуть больший средний latency на запрос, однако в рамках допустимых значений для данного кейса; с другой стороны, он был значительно дешевле в реализации. Выбрали второй вариант.

PvP сражения по сути являются сессиями. Для сессионных онлайн-игр часто используют специализированные решения (Microsoft Azure PlayFab, Amazon GameLift, Google Cloud Game Servers)*. Для текущего ТЗ эти решения необязательны, однако мы заложили в архитектуре ПО возможность интегрирования таких решений конкретно для сражений.

Мобильное приложение пишется на Flutter. Обычно для мобильных игр используют Unity, однако в данной игре есть элементы, использующиеся в обычных приложениях (древо навигации, app-like модальные окна). Flutter поддерживает эти элементы значительно лучше. С другой стороны, в проекте не планируется поддержка таких игровых элементов, как 3д, шейдеры, физика, коллизии, продвинутая синхронизация состояния между игроками и прочее. В связи с этим выбрали Flutter.

* К слову, в России нет аналогов таких сервисов, вот вам идея для стартапа.

Продукт ещё находится в разработке, однако поставленная задача успешно выполняется. Вдумчивый выбор архитектуры ПО на старте позволяет без проблем справляться с проблемами масштабирования исходного кода, вызванного наличием обширного функционала.

Разработка ведётся параллельно с доработками ТЗ со стороны заказчика, поэтому с нашей стороны необходим гибкий подход. В связи с этим мы:

• выбираем с заказчиком наиболее приоритетные и близкие к финальной версии подзадачи;
• строим гибкую архитектуру ПО с возможностью расширения функционала.