Разработка технического стека и выбор модулей игр
«Возьмём Unity, там всё есть» — это не технический стек, это отсутствие решения. Unity предоставляет базовый движок. Но выбор Render Pipeline (Built-in / URP / HDRP), подход к сетевому коду (Netcode for GameObjects / Mirror / Photon / Nakama), система аналитики, backend для сохранений, IAP-провайдер, CI/CD инфраструктура — всё это нужно выбрать и обосновать до начала разработки.
Неверный выбор на старте стоит дорого. Например, URP выбран для мобильного проекта — правильно. Но через три месяца потребовалась кастомная post-process эффекты — и оказалось, что команда использовала встроенные Renderer Features неправильно, несовместимые с target API Level. Переход с URP на Built-in посередине разработки — это 2–4 недели переработки материалов.
Render Pipeline: принципы выбора
Built-in Render Pipeline — legacy, но всё ещё актуален для проектов с максимальной совместимостью (WebGL, старые Android, Nintendo Switch через специфические паттерны). Максимальная экосистема Asset Store-совместимости.
URP (Universal Render Pipeline) — стандарт для мобильных и консольных проектов. Meaner и faster built-in. Кастомные Renderer Features для post-processing. Custom Render Pass API. Обязателен для проектов с VR/AR (XR Interaction Toolkit работает лучше с URP).
HDRP (High Definition Render Pipeline) — для PC/консолей с акцентом на фотореализм. Ray Tracing, Volume-based lighting, Screen Space Global Illumination. Не для мобильных. Не для WebGL. Минимальные требования: DX12/Vulkan/Metal.
Выбор Pipeline — архитектурное решение без обратного пути без значительных затрат. Принимаем в самом начале.
Сетевой стек для multiplayer
Это то, где ошибки стоят дороже всего. Сетевой код пронизывает всю игру, и смена сетевой библиотеки на поздних этапах — это почти переписывание игровой логики заново.
Netcode for GameObjects (NGO) — официальный Unity multiplayer SDK. Подходит для co-op игр с < 16 игроками, относительно простой в интеграции. Требует Relay-сервер (Unity Gaming Services) или собственного транспорта.
Mirror — open source, battle-tested, отличная документация, большое сообщество. Для независимых и indie-проектов с собственной серверной инфраструктурой. Поддерживает большое количество игроков (с правильной архитектурой — сотни на сцену).
Photon PUN 2 / Fusion — managed cloud solution. Photon берёт на себя инфраструктуру: relay, matchmaking, lobbies. PUN 2 — для turn-based и слабо-связанного real-time. Fusion — для быстрого action с client-side prediction и server reconciliation.
Nakama — open source game server с поддержкой matchmaking, leaderboard, chat, economy, tournaments. Self-hosted или managed cloud. Правильный выбор если нужен полноценный game backend, а не только сетевой код.
PlayFab — Microsoft Azure-based game backend. Аналитика, экономика, player profiles, cloud scripts, matchmaking. Быстрый старт, managed-инфраструктура. Платная модель зависит от MAU.
Аналитика и монетизация
Для мобильных проектов с монетизацией стек обычно выглядит так:
- Аналитика: Firebase Analytics (бесплатно, tight integration с Unity) или GameAnalytics (специализирован под игры, voronka, retention cohorts). Оба через одну интеграцию.
- IAP: Unity IAP (обёртка над App Store / Google Play, поддерживает 20+ сторов). Серверная валидация покупок обязательна — через собственный endpoint или PlayFab Cloud Script.
- Реклама: ironSource / AppLovin MAX (mediation платформы) вместо прямой интеграции одного ad network. Mediation оптимизирует fill rate и eCPM автоматически.
- Push notifications: Firebase Cloud Messaging (FCM) для Android и APNs для iOS, через Unity package или OneSignal.
Как проводим выбор стека
Начинаем с матрицы требований: платформы → это исключает некоторые варианты. Жанр и механики → определяют требования к сетевому коду. Команда → опыт с конкретными технологиями влияет на скорость разработки. Бюджет операционных расходов → managed services vs self-hosted.
Для каждого ключевого выбора готовим ADR (Architecture Decision Record): проблема, рассматриваемые варианты, выбранный вариант, обоснование, известные компромиссы. Это документ, к которому возвращаются при сомнениях.
Финальный стек оформляем в Tech Stack Document с указанием версий, лицензий и ответственных за каждый компонент.
| Масштаб задачи | Ориентировочные сроки |
|---|---|
| Технический стек + ADR для нового проекта | 3–7 дней |
| Аудит текущего стека + рекомендации по обновлению | 3–5 дней |
| Смена Render Pipeline в существующем проекте | 3–6 недель |
| Выбор и прототипирование сетевого стека | 1–3 недели |
Стоимость рассчитывается после ознакомления с требованиями проекта.