Разработка мобильной стратегии
Мобильные стратегии — жанр, в котором backend убивает проект чаще, чем слабый геймплей. Город построен, войска отправлены, игрок закрыл приложение — и когда через 6 часов он вернётся, всё должно быть там, где нужно. Асинхронные таймеры, атаки от других игроков, ресурсный баланс — всё это нельзя хранить только на клиенте.
Архитектура: клиент как display layer
Главная ошибка в стратегиях — доверять клиенту. Если таймеры строительства считаются на клиенте, их можно подкрутить системным временем. Если войска считаются локально — можно накрутить ресурсы. Правильная архитектура:
Сервер — единственный источник истины. Всё игровое состояние живёт на сервере: ресурсы, постройки, войска, таймеры. Клиент отображает snapshot состояния и отправляет команды (BuildCommand, AttackCommand, CollectCommand). Сервер валидирует, применяет, возвращает новый snapshot или delta.
Для persistence: PostgreSQL со строгой схемой для игрового состояния + Redis для горячих данных (активные таймеры, онлайн-статус альянсов). REST API для мета-операций, WebSocket для real-time уведомлений (тебя атакуют, строительство завершено).
На клиенте — оптимистичное обновление UI с откатом: когда игрок жмёт «собрать ресурсы», UI обновляется немедленно, запрос идёт на сервер параллельно. Если сервер возвращает ошибку — UI откатывается. Это убирает ощущение «лагающей» игры при хорошем интернете.
Карта и рендер тысяч объектов
Для стратегий с большой картой (классический 4X или war-game с сотнями игроков) стандартный подход — тайловая карта с LOD. Unity Tilemap + Composite Collider2D для базовой геометрии. При zoom-out: заменяем детальные тайлы на атлас-текстуру всего региона (RenderTexture snapshot), убираем коллайдеры, отключаем обновление анимаций.
Для маркеров других игроков на большой карте — GPU Instancing через Graphics.DrawMeshInstanced. 1000 маркеров игроков в один draw call вместо 1000 отдельных GameObject'ов. Позиции и цвета передаются через MaterialPropertyBlock.
Реальный кейс: alliance war с 100 участниками
На одном 4X-проекте при одновременной атаке 30+ игроков на один замок сервер уходил в timeout. Проблема: каждая атака писала в одну строку PostgreSQL синхронно. Решение — Command Queue на Redis Stream: атаки складываются в очередь, воркер обрабатывает их последовательно и публикует результат через WebSocket. Latency восприятия — мгновенный (UI показывает «атака отправлена»), фактическая обработка — 100–300ms. Игроки не замечают разницы, сервер перестал падать.
Push-уведомления как retention-инструмент
Firebase Cloud Messaging — обязательно. Триггеры: строительство завершено, нападение на базу, ресурсы заполнены. На iOS нужно корректно запрашивать UNUserNotificationCenter.requestAuthorization — запрашивай разрешение не при первом запуске, а после первого завершения строительства, когда игрок уже понимает ценность уведомлений. Конверсия на разрешение в таком случае — 60–70% vs 30–40% при запросе на старте.
Сроки
| Масштаб | Срок |
|---|---|
| Одиночная стратегия (без PvP) | 5–8 месяцев |
| PvP с асинхронными атаками | 8–12 месяцев |
| Полноценный war-game с альянсами, real-time картой | 14–20 месяцев |
Препродакшн — минимум 4 недели на проектирование серверной архитектуры. Запускать стратегию без продуманного backend — значит переписывать его на живой аудитории, что в жанре с асинхронным прогрессом крайне болезненно.
Стоимость рассчитывается индивидуально после анализа серверных требований, объёма карты и PvP-механик.