Разработка мобильной стратегии
Мы создаём мобильные стратегии под ключ — от прототипа до публикации в App Store и Google Play. Сталкивались с ситуацией, когда асинхронные таймеры строительства рассинхронизируются, игроки теряют прогресс, а сервер падает под нагрузкой массовых атак. Наш опыт — предотвратить эти проблемы на этапе архитектуры. Серверная логика даёт в 5 раз меньше ошибок синхронизации по сравнению с клиентскими таймерами, а экономия на серверной инфраструктуре достигает 40%. Свяжитесь с нами для оценки вашего проекта — за 2 дня получите детальный план.
Почему архитектура клиент-сервер — основа мобильной стратегии?
Главная ошибка в стратегиях — доверять клиенту. Если таймеры строительства считаются на клиенте, их можно подкрутить системным временем. Если войска считаются локально — можно накрутить ресурсы. Правильная архитектура: сервер — единственный источник истины. Всё игровое состояние живёт на сервере: ресурсы, постройки, войска, таймеры. Клиент отображает snapshot состояния и отправляет команды (BuildCommand, AttackCommand, CollectCommand). Сервер валидирует, применяет, возвращает новый snapshot или delta.
Для persistence: PostgreSQL со строгой схемой для игрового состояния + Redis для горячих данных (активные таймеры, онлайн-статус альянсов). REST API для мета-операций, WebSocket для real-time уведомлений (тебя атакуют, строительство завершено).
На клиенте — оптимистичное обновление UI с откатом: когда игрок жмёт «собрать ресурсы», UI обновляется немедленно, запрос идёт на сервер параллельно. Если сервер возвращает ошибку — UI откатывается. Это убирает ощущение «лагающей» игры при хорошем интернете.
Как избежать перегрузки сервера при массовых атаках?
В стратегиях с PvP одновременные действия сотен игроков — частая причина timeout’ов. На одном из проектов нашего клиента (4X-стратегия) при атаке 30+ игроков на один замок сервер уходил в timeout. Решение — Command Queue на Redis Stream: атаки складываются в очередь, воркер обрабатывает их последовательно и публикует результат через WebSocket. Latency восприятия — мгновенный (UI показывает «атака отправлена»), фактическая обработка — 100–300ms. Игроки не замечают разницы, сервер перестал падать. Такой подход снижает нагрузку на PostgreSQL в 5 раз по сравнению с синхронной записью.
Для оптимизации под массовые атаки следуйте этим шагам:
- Используйте Command Queue на Redis Stream.
- Обрабатывайте атаки последовательно в воркере.
- Публикуйте результат через WebSocket.
- На клиенте показывайте оптимистичное подтверждение.
Что даёт серверная логика для безопасности?
Если игровые данные (ресурсы, таймеры) доступны на клиенте, их можно модифицировать через отладчик или подмену запросов. Все расчёты выполняются на сервере с последующей синхронизацией. Это увеличивает сложность серверной части, но гарантирует честность игры и упрощает античит. Как описано в Best Practices for Mobile Game Security, такой подход является отраслевым стандартом.
Карта и рендер тысяч объектов
Для стратегий с большой картой (классический 4X или war-game с сотнями игроков) стандартный подход — тайловая карта с LOD. Unity Tilemap + Composite Collider2D для базовой геометрии. При zoom-out: заменяем детальные тайлы на атлас-текстуру всего региона (RenderTexture snapshot), убираем коллайдеры, отключаем обновление анимаций.
Для маркеров других игроков на большой карте — GPU Instancing через Graphics.DrawMeshInstanced. 1000 маркеров игроков в один draw call вместо 1000 отдельных GameObject'ов. Позиции и цвета передаются через MaterialPropertyBlock.
Push-уведомления как retention-инструмент
Firebase Cloud Messaging — обязательно. Триггеры: строительство завершено, нападение на базу, ресурсы заполнены. На iOS нужно корректно запрашивать UNUserNotificationCenter.requestAuthorization — запрашивай разрешение не при первом запуске, а после первого завершения строительства, когда игрок уже понимает ценность уведомлений. Конверсия на разрешение в таком случае — 60–70% vs 30–40% при запросе на старте. Правильный момент запроса повышает retention на 25%.
Что входит в работу
- Геймдизайн-документация и server API спецификация (OpenAPI)
- Исходный код клиента и сервера с комментариями
- Настройка CI/CD (GitHub Actions, Firebase App Distribution, TestFlight)
- Доступы к репозиторию, админ-панели, логам
- Инструкция по развёртыванию
- Бесплатная поддержка 1 месяц после запуска
Сроки и этапы работы
| Этап | Длительность |
|---|---|
| Препродакшн (проектирование архитектуры, геймдизайн) | 4–6 недель |
| Разработка клиента (iOS + Android) | 3–6 месяцев в зависимости от сложности |
| Разработка серверной части (авторизация, игровая логика, PvP) | 5–10 месяцев |
| Интеграция, тестирование и деплой | 1–2 месяца |
| Поддержка после запуска | от 1 месяца |
| Масштаб | Срок |
|---|---|
| Одиночная стратегия (без PvP) | 5–8 месяцев |
| PvP с асинхронными атаками | 8–12 месяцев |
| Полноценный war-game с альянсами, real-time картой | 14–20 месяцев |
Стоимость рассчитывается индивидуально после анализа серверных требований, объёма карты и PvP-механик. Оценим ваш проект в течение 2 дней — свяжитесь с нами для консультации. Получите бесплатную оценку уже сегодня!