Разработка технического стека и выбор модулей для игр

«Возьмём Unity, там всё есть» — это не технический стек, а отсутствие решения. Мы видим такие запросы постоянно: команда начинает на базовом движке, а через полгода выясняется, что Render Pipeline не подходит для таргетных платформ, сетевой код не масштабируется, а аналитика не собирает нужные метрики. По статистике, около 60% проектов сталкиваются с необходимостью пересмотра стека на поздних этапах. На старте мы помогаем выбрать и обосновать каждую компоненту: от Render Pipeline до CI/CD. Это экономит недели переработок и сотни тысяч рублей. Неверный выбор на старте стоит дорого. Например, URP выбран для мобильного проекта — правильно. Но через три месяца потребовалась кастомная post-process эффекты — и оказалось, что команда использовала встроенные Renderer Features неправильно, несовместимые с target API Level. Переход с URP на Built-in посередине разработки — это 2–4 недели переработки материалов. Стоимость такой ошибки существенна. Закажите аудит текущего стека, чтобы избежать таких проблем.

Как выбрать Render Pipeline?

Render Pipeline — архитектурное решение без обратного пути без значительных затрат. URP — стандарт для мобильных и консольных проектов. URP обеспечивает в 2-3 раза лучшую производительность на мобильных устройствах по сравнению с Built-in. Кастомные Renderer Features для post-processing и Custom Render Pass API. Обязателен для проектов с VR/AR. HDRP — для PC/консолей с акцентом на фотореализм: Ray Tracing, Volume-based lighting, Screen Space Global Illumination. Не подходит для мобильных и WebGL. Built-in Render Pipeline — legacy, но всё ещё актуален для максимальной совместимости (WebGL, старые Android, Nintendo Switch). Выбор Pipeline принимается в самом начале на основе матрицы требований. Подробнее о Render Pipeline.

Почему сетевой стек — самое дорогое решение?

Сетевой код пронизывает всю игру, и смена сетевой библиотеки на поздних этапах — это почти переписывание игровой логики заново. Netcode for GameObjects (NGO) — официальный Unity multiplayer SDK для co-op игр с < 16 игроками. Mirror — open source с большим сообществом, подходит для независимых проектов с собственной серверной инфраструктурой. Photon PUN 2 / Fusion — managed cloud solution, берёт на себя relay, matchmaking. Nakama — open source game server с поддержкой economy и турниров. PlayFab — Azure-based backend с аналитикой и cloud scripts. Выбор зависит от количества игроков, платформ и бюджета операционных расходов. Смена сетевой библиотеки на позднем этапе может стоить значительную сумму.

Аналитика и монетизация

Для мобильных проектов с монетизацией стек обычно включает Firebase Analytics или GameAnalytics, Unity IAP с серверной валидацией и mediation платформы (ironSource, AppLovin) для рекламы. Push-уведомления через FCM и APNs. Правильная аналитика может увеличить retention на 15-20% и ARPU на 25%.

Как мы проводим выбор стека

1. Анализ требований: платформы, жанр, механики, бюджет, опыт команды.
2. Проектирование: для каждого ключевого выбора создаём Architecture Decision Record (ADR) с вариантами, обоснованием и компромиссами.
3. Прототипирование: интеграция выбранных компонентов в минимальный тестовый проект.
4. Тестирование: нагрузочное тестирование сетевого кода, производительность графики.
5. Документирование: финальный Tech Stack Document с версиями, лицензиями, ответственными.

Что входит в работу

• ADR документы по каждому ключевому компоненту (Render Pipeline, сетевой стек, аналитика, IAP)
• Tech Stack Document с версиями, лицензиями и ответственными
• Прототип интеграции стека (proof of concept)
• Обучение команды основам выбранных технологий
• Поддержка при внедрении в течение 2 недель после передачи

Ориентировочные сроки

Типичные ошибки при выборе стека

• Выбор на основе личных предпочтений, а не требований проекта
• Игнорирование совместимости с платформой (например, HDRP на мобильных)
• Отсутствие серверной валидации IAP
• Использование одного ad network без mediation
• Отсутствие ADR и документирования решений

Получите консультацию по выбору стека уже сегодня. Обратитесь к нам — мы имеем многолетний опыт в игровой разработке, выполнили более 50 игровых проектов для мобильных, PC и консолей. Наш опыт включает Unity и Unreal Engine, а также собственные разработки на Godot.

Планирование игрового проекта

Типичная ситуация: к нам приходит команда после трёх месяцев разработки с вопросом «почему у нас в репозитории 40 гигабайт и Git падает при каждом pull?». Ответ почти всегда один: PNG-текстуры и FBX-файлы закоммичены напрямую без Git LFS, история репозитория раздулась до неработоспособного состояния. Это решается, но переписывание истории в живом проекте — болезненный процесс, которого можно было легко избежать.

Планирование игр — это не про диаграммы Ганта. Это про технические решения первых двух недель, которые не станут проблемами через три месяца.

Почему планирование игр — это не про Ганта?

График работ — только вершина. Настоящее планирование игрового проекта включает:

• жёсткую фиксацию целевых платформ и минимальных требований (например, iPhone 11, 60 fps);
• декомпозицию механик до числовых параметров с версионированием;
• выбор стека, от которого зависит вся архитектура (render pipeline, сеть, ECS);
• настройку инфраструктуры до первого коммита с ассетами.

Без этого «план» — список задач без опоры. Через месяц выясняется, что Unreal-проект сборки под мобильные платформы не тянет, а ECS оказался избыточным для простого раннера. Время потрачено, бюджет ушёл на прототипы, которые нужно переписывать.

Документация: GDD как живой инструмент

GDD (Game Design Document) в плохом исполнении — это 80-страничный PDF, который никто не читает после второго спринта. GDD в хорошем исполнении — это структурированная база знаний, которую команда реально использует каждый день.

Что должно быть в GDD

Минимальный набор, без которого нельзя начинать разработку:

• Геймплейные системы — точное описание каждой механики с параметрами. Не «персонаж прыгает», а «прыжок: высота 2.4 юнита, время в воздухе 0.6 сек, есть 150 мс coyote time, double jump разрешён, приземление блокирует атаку на 200 мс». Числа могут меняться в ходе балансинга, но они должны быть зафиксированы и версионированы.
• Технические ограничения — целевые платформы, минимальные требования к железу, ограничения по памяти и draw calls. Если игра должна работать на iPhone 11 с 60 fps, это ограничение влияет на все арт-решения с самого начала.
• Scope и фичи — явный список того, что входит в MVP и что остаётся на потом. «Может быть добавим крафтинг» — это не планирование, это источник feature creep.
• Референсы — конкретные игры с конкретными механиками, которые берутся за основу. «Как в Dark Souls, но быстрее» — это рабочий референс для combat designer.

Как мы ведём GDD

Используем Notion или Confluence — GDD живёт как wiki, а не как файл. Изменения видны в истории, можно оставлять комментарии, механики связаны между собой перекрёстными ссылками. Технический дизайн и художественный дизайн хранятся отдельными разделами, но ссылаются друг на друга. Каждая механика имеет статус: в разработке, готово, на ревью, заморожено. Это позволяет в любой момент понять реальное состояние проекта без звонков.

Техническая архитектура

Выбор стека — не религия

Выбор между Unity и Unreal разбираем детально в общем разделе каталога. Но на этапе планирования есть несколько смежных решений, критически влияющих на проект:

• Render pipeline в Unity. URP — для мобильных и VR. HDRP — для PC/консолей. Built-in (Legacy) — только если берёте старый проект. Менять pipeline в середине разработки — пересборка всех материалов. Решение принимается в день первого коммита.
• Архитектура игровых объектов. Классический MonoBehaviour против ECS (Entity Component System через Unity DOTS). ECS даёт порядки производительности на тысячах объектов, но резко увеличивает сложность кода. Для гиперкажуальных игр — избыточно. Для стратегий — необходимо.
• Сетевая архитектура. Если мультиплеер планируется — решение принимается до первой игровой механики. Single-player и networked code устроены принципиально по-разному: в сетевой игре каждое изменение состояния должно быть явным и синхронизируемым.

ScriptableObjects как конфигурационный слой

В Unity используем ScriptableObject-ориентированный подход для хранения игровых данных. Конфигурация оружия, параметры врагов, настройки уровней — всё это ScriptableObject-ассеты, а не захардкоженные значения. Это позволяет гейм-дизайнеру менять баланс без участия программиста и без пересборки проекта.

Версионирование и работа с ассетами

Это та область, где большинство небольших команд теряет время самым обидным способом.

Git + Git LFS

Стандартный Git не предназначен для бинарных файлов. Текстура 4K в PNG весит 20–50 MB. Если её коммитить как обычный файл, история репозитория раздувается катастрофически быстро. Git LFS хранит бинарные файлы отдельно, а в Git-историю кладёт только указатели. Настраивается один раз в .gitattributes:

*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

Это должно быть настроено до первого коммита с ассетами. После — болезненная миграция, которая может стоить до 200 000 руб. времени разработчиков.

Perforce

Альтернатива для крупных Unreal-проектов. Epic Games сами используют Perforce. Лучше работает с очень большими репозиториями (сотни гигабайт), нативная поддержка в Unreal Editor. Выше стоимость инфраструктуры и сложность настройки.

Ветвление

Для игровых проектов используем упрощённый Git Flow: main, develop, feature/*, release/*. Правило: в main никогда не коммитится ничего, что не прошло QA. Его нарушение приводит к тому, что «последняя стабильная версия» становится термином без содержания.

CI/CD для игровых проектов

Автоматическая сборка при каждом пуше решает проблему «у меня на машине собирается, у тебя нет». Pipeline включает:

1. Активация Unity лицензии (headless)
2. Запуск тестов (Unity Test Runner)
3. Сборка под Android (APK/AAB)
4. Сборка под iOS (Xcode проект)
5. Сборка под PC (Standalone)
6. Загрузка артефактов в S3 или Firebase App Distribution

Время сборки — 15–40 минут. Команда получает свежую сборку без ручной работы.

GameCI — GitHub Actions для Unity. Unity Cloud Build — хостинг от Unity, проще настройки, дороже при большом количестве сборок. Jenkins — полный контроль, используется для консольных платформ.

Что входит в работу

• Документация: техническое задание, GDD (MVP-scope), архитектурная схема, модели данных.
• Настройка репозитория: Git + LFS, правила ветвления, шаблон проекта, соглашения о коде.
• CI/CD: конфигурация сборок под все целевые платформы, автоматическое тестирование.
• Доступы: к репозиторию, CI/CD, баг-трекеру; обучение команды работе с инструментами.
• Поддержка: сопровождение в течение первого месяца разработки — ответы на вопросы, корректировка настроек, ревью архитектурных решений.

Временные рамки планирования

Итого до начала полноценного производства: 4–6 недель. Это не бюрократия — это страховка от переписывания, которая экономит до 40% времени на этапе продакшена.

Как планирование игр предотвращает технический долг?

Ошибка в планировании на первом спринте обходится в 10 раз дороже, чем исправление на прототипе. Неправильный выбор стека или отсутствие LFS приводят к пересборке архитектуры, потере коммитов и демотивации команды. Грамотное планирование игр — это инвестиция, которая окупается снижением багов на 30% и ускорением релиза в среднем на 2 месяца.

Оценим ваш проект — свяжитесь с нами, чтобы получить консультацию и детальный план первых шагов. Закажите планирование игрового проекта и избегите типичных граблей, которые мы видим в 90% обращений.