Техническое задание для игр: составляем документацию под ключ

Мы составляем технические задания для игровых проектов любой сложности — от гипер-казуалов до MMO. Наш опыт — более 10 лет в геймдеве, свыше 70 успешных проектов, сертифицированные специалисты Unity и Unreal. Проект без ТЗ — это проект, где через три месяца выясняется, что заказчик имел в виду «мультиплеер» как «можно играть вдвоём на одном экране», а команда сделала полноценный сетевой матчмейкинг. Или художники рисовали UI под разрешение 1920×1080, а игра должна работать на устройствах с 720×1280. Техническое задание — не формальность, а инструмент синхронизации ожиданий, который сокращает бюджет на переделки до 40%. Средняя экономия на переделках составляет 35% бюджета проекта. Проекты с ТЗ сдаются на 40% быстрее, чем без него.

При этом ТЗ на игру принципиально отличается от ТЗ на корпоративный сайт. Здесь нужно описывать не только функциональность, но и технические характеристики, которые напрямую влияют на стоимость и сроки: целевые платформы, производительностные требования, сетевая архитектура, поддержка контента. Наши заказчики получают документ, с которым разработчик может сразу приступить к реализации — без уточнений и переписок.

Почему техническое задание критично для игрового проекта?

ТЗ закрывает три вопроса: что делаем, как это работает технически и как проверим правильность. Хороший документ снижает количество правок на этапе разработки в два раза по сравнению с устным брифингом.

Платформы и производительностные требования. Не просто «Android и iOS», а минимальные и целевые устройства. Минимум Android: Snapdragon 660, 3 ГБ RAM, Android 8.0. Целевой fps: 60 на целевых устройствах, 30 на минимальных. Это влияет на выбор Render Pipeline, политику LOD, ограничения Draw Calls.

Игровые системы с поведенческими спецификациями. Не «система инвентаря», а «инвентарь поддерживает до 200 слотов, предметы с атрибутами (тип, редкость, стакаемость до 99), Drag&Drop между слотами, фильтрация по типу, сортировка по 3 параметрам». Чем конкретнее описание — тем точнее оценка трудозатрат.

Сетевая архитектура (если multiplayer). Client-server или P2P. Авторитетный сервер или client-side prediction с reconciliation. Максимальное количество одновременных игроков в сессии. Требования к латентности (100 мс? 50 мс?). Это решения, формирующие архитектуру на годы вперёд.

Контентная модель. Как добавляется новый контент: через редактор, через CMS или через DLC. Поддержка модификаций? Это определяет, нужна ли система Addressables с remote content, локализуемые ассеты, формат конфигурационных данных.

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

• Анализ концепции (GDD, устное описание, референсы)
• Составление технического документа (15–60 страниц)
• Ревью с командой разработки и заказчиком
• Финальная версия с подписанными критериями приёмки
• Консультации по реализации — ответы на вопросы в течение 30 дней

Сравнение: проект с ТЗ и без

Как мы переводим GDD в технические требования?

Большинство клиентов приходят с Game Design Document (GDD) — описанием геймплея, механик, сюжета. Но GDD — это не ТЗ. Из него непонятно: в каком движке делать, какой Render Pipeline, как устроен save/load, нужна ли аналитика, как работает монетизация на техническом уровне (IAP, реклама, серверная валидация).

Мы берём GDD или устное описание и переводим в технические требования. Для каждой игровой системы определяем: стек (библиотеки, SDK), зависимости, edge cases, критерии приёмки. Пример: система достижений — 50 достижений, прогресс локально + синхронизация с сервером, поддержка Game Center и Google Play Games. Техническое требование: AchievementManager с offline-queue, дедупликация по playerId + achievementId, максимальное время синхронизации — 5 секунд. С этой spec разработчик понимает задачу без дополнительных вопросов.

Какие типичные пробелы мы закрываем?

• Отсутствие требований к производительности. Указываем целевые fps, бюджет draw calls, политику ассетов.
• Неопределённая сетевая архитектура. Фиксируем протокол, авторитетность сервера, количество игроков.
• Пропуски в контентной модели. Определяем pipeline поставки: Addressables, remote config, локализация.

По данным отраслевых исследований, детальное ТЗ сокращает время разработки на 30–50% за счёт снижения переделок. Закажите ТЗ — и вы получите документ, который окупится уже на первом этапе разработки.

Как заказать составление ТЗ?

Если вам нужно ТЗ для игрового проекта — свяжитесь с нами, мы оценим ваш проект за 2 часа. Предоставим пример структуры документа и сроки под ключ. Получите консультацию — пишите, обсудим детали.

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

Типичная ситуация: к нам приходит команда после трёх месяцев разработки с вопросом «почему у нас в репозитории 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% обращений.