Розробка мобільної стратегії
Мобільні стратегії — жанр, в якому backend убивает проект частіше, ніж слабий геймплей. Місто побудовано, військо відправлено, гравець закрив додаток — і коли через 6 годин він повернеться, усе повинно бути на місці. Асинхронні таймери, атаки від інших гравців, ресурсний баланс — все це не можна зберігати лише на клієнті.
Архітектура: клієнт як layer відображення
Головна помилка в стратегіях — довіряти клієнту. Якщо таймери будівництва рахуються на клієнті, їх можна перекрутити системним часом. Якщо військо рахується локально — можна накрутити ресурси. Правильна архітектура:
Сервер — єдиний джерело істини. Усе ігрове стан живе на сервері: ресурси, будівлі, військо, таймери. Клієнт відображає снімок стану та відправляє команди (BuildCommand, AttackCommand, CollectCommand). Сервер валідує, застосовує, повертає новий снімок або delta.
Для persistence: PostgreSQL з суворою схемою для ігрового стану + Redis для гарячих даних (активні таймери, статус online альянсів). REST API для мета-операцій, WebSocket для real-time сповіщень (тебе атакують, будівництво завершено).
На клієнті — оптимістичне оновлення UI з відкатом: коли гравець натискає «зібрати ресурси», UI оновлюється миттєво, запит йде на сервер паралельно. Якщо сервер повертає помилку — UI откатывается. Це усуває відчуття «лаганої» гри при хорошому інтернеті.
Карта та рендеринг тисяч об'єктів
Для стратегій з великою картою (класичний 4X або war-game зі сотнями гравців) стандартний підхід — тайлова карта з LOD. Unity Tilemap + Composite Collider2D для базової геометрії. При zoom-out: замінюємо детальні тайли на atlas-текстуру всього регіону (RenderTexture snapshot), відключаємо collider'и, вимикаємо оновлення анімацій.
Для маркерів інших гравців на великій карті — 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-механік.