Как грамотно составить ТЗ для игры в мобильной разработке

Почему ТЗ — ключ к адекватной разработке мобильной игры

Без четко сформулированного технического задания мобильная игра чаще всего превращается в хаотичный эксперимент. Один из характерных примеров — мобильный платформер, заказанный под Android и iOS, где изначально не были зафиксированы механики управления, тип монетизации и ограничения по производительности. В итоге: игра не влезла по объему в целевой бюджет, вышла с задержкой в 3 месяца и не прошла модерацию в App Store из-за багов и несоответствий заявленным параметрам.

Техническое задание определяет параметры продукта: от жанра до поведения кнопки “Пауза”. Оно фиксирует не только то, что должно быть реализовано, — но и то, чего делать не надо. Это защищает и разработчиков, и заказчика от подмены понятий и двусмысленностей.

При отсутствии внятного ТЗ команда обращается к “устным договоренностям” и личным представлениям о проекте. В результате появляются играбельные, но неиграбельные прототипы: у каждого отдела свое понимание задачи. Если ТЗ составлено грамотно, оно становится опорой в управлении разработкой, позволяет точно планировать сроки, назначать ресурсы и следить за отклонениями по спринтам.

Идея — это эмоциональный вектор. ТЗ — это структурный документ, в котором идея превращается в конкретный набор требований. Между “хотелось бы сделать фэнтези-RPG с мультяшной графикой” и “мобильная пошаговая игра с изометрической камерой, рассчитанная на Android 9.0+, уровень монетизации — бесплатная с IAP для ускорения прогресса” — ключевая разница во времени, деньгах и результате.

Что включает хорошее ТЗ для мобильной игры: структура и примеры

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

1. Цель и жанр игры
2. В ТЗ должно быть ясно указано, к какому жанру относится игра (например, 2D-платформер, idle-RPG или clicker с мультиплеером). Конкретизация жанра позволяет сразу определить ядро механик и ожидания по игровому опыту. Пример: “Мобильная гиперказуальная аркада на реакцию, с партией не более 60 секунд.”
3. Целевая аудитория и платформа
4. Указать, кто будет играть, на каких устройствах и в каком регионе. Это критично для выстраивания UI/UX, скорости реакции интерфейса, уровня графики и методов монетизации. В идеале в ТЗ фиксируются и технически значимые платформенные параметры: Android 9+, iOS 14+, поддержка планшетов, портретная ориентация.
5. Основные игровые механики
6. Включаются базовые элементы: передвижение, атака, использование предметов, прокачка. Эти элементы желательно структурировать в таблицах или списках, выделяя обязательные и опциональные механики. Часто недостающий в слабых ТЗ пункт — описание состояния персонажа (жив/мертв, статус эффекты), что критично для логики игры.
7. Сценарий или сюжет (если есть)
8. Не всегда нужен глубоко проработанный лор. В casual-играх достаточно четкой логики: “Уровень представляет собой цепь вызовов, визуально — офис. Главный герой — менеджер, уворачивается от бумаг и дедлайнов”. Чем чётче прописан игровой контекст и сценарная структура — тем проще адаптировать UI, звук и флоу.
9. Игровой баланс и монетизация
10. ТЗ должно отражать уровень баланса: фиксированные числа (скорости, урон), уровни сложности, экономику прогресса. По монетизации обязательно указывают: модели (IAP, реклама, подписка), условия появления офферов, поведение платёжных интерфейсов. Типичная ошибка — отсутствие связки между балансом и стоимостью внутриигровых покупок.
11. Требования к графике, UI/UX и звуку
12. Форматы ассетов, допустимые разрешения, FPS, типы анимации (скелетная, покадровая), цветовая палитра (например, “не использовать более 6 базовых цветов в кадре”). Для звука: типы эффекта (loop/background/system FX), длительность, вес. UI/UX должны учитывать платформу, размер пальца, тип коммуникации (туториалы, ошибки, уведомления).
13. Технические ограничения
14. Нужно указать минимальные требования по оперативной памяти, особенности поддержки геймпада, ограничения по весу билдов (например, не более 200 МБ для Google Play), запреты на тяжелую графику в онлайн-моде и т.д.
15. Функциональность админки и параметры аналитики
16. Даже для малого проекта важно зафиксировать: нужны ли метрики по уровням, время сессии, воронки встраивания новых фичей. В админке могут предусматриваться переключатели уровней, A/B тестирования, валидация новых механик.
17. Тестирование и релиз
18. Часто в ТЗ забывают указать: что и как проверять. Хорошее ТЗ включает: тип покрытия тестами (unit/end-to-end), количество устройств для Smoke-теста, этапы soft launch (страна и длительность), требования к подготовке в App Store и Google Play, необходимые сертификаты и SDK.

Наконец, раздел “Показатели успеха” — избыточен для программирования, но полезен для ведения проекта: сколько DAU, retention на D1/D7, плановая оценка CPI и LTV — если проект направлен на коммерческую отдачу, эти параметры важно обозначить заранее.

ТЗ или GDD: в каких случаях нужен один, в каких — оба

Путаница между GDD (Game Design Document) и техническим заданием — один из частых источников недопонимания. Хотя оба документа описывают будущую игру, их назначение и стиль написания различаются.

GDD — это гейм-дизайнерский документ. Он описывает все аспекты игрового процесса: от логики уровня, через таблицы прокачки до поведения врагов и структуры туториала. GDD часто содержит диаграммы, скетчи, VFX-концепты, описание поведения без привязки к реализации. Это “что в идеале”, без технической конкретики.

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

Когда проект компактный или очень типовой (например, гиперказуал на Unity без PvP), можно обойтись только ТЗ с вложенными UI-мокапами. Но для сложных mid-core RPG, особенно с сюжетом и прогрессией, GDD необходим: без него дизайнеры и сценаристы будут работать вслепую.

Оптимальная практика — вести и GDD, и ТЗ, при этом TЗ может ссылаться на GDD внутри (например, “см. раздел 3.2 механики боя в GDD v2.1”). В компактных проектах иногда делают объединённый документ, где структура идет от структуры ТЗ, а внутрь встраиваются элементы GDD. Такой подход подходит для команд с плотной координацией и ограниченными ресурсами — например, инди-студий из 3–5 человек.

Кто и как должен составлять ТЗ: роли и границы ответственности

Один из самых распространённых вопросов от заказчиков — «А кто вообще должен писать это ТЗ?» Ответ: зависит от стадии проекта и уровня зрелости команды. Но главное — подходить к составлению как к совместной проработке, а не как к попытке «переложить всё на технарей» или «написать на коленке самому».

Может ли заказчик написать ТЗ самостоятельно?

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

Кто участвует в составлении ТЗ на стороне подрядчика:

1. Гейм-дизайнер — разбирает идею на игровые механики, определяет элементы взаимодействия с игроком, отвечает за баланс и сценарные развилки.
2. Технический директор или тимлид — оценивает реализуемость функций, добавляет технические ограничения, описывает технологический стек, SDK, ограничение по памяти/устройствам.
3. UI/UX дизайнер — формализует интерфейс, задаёт принципы взаимодействия, говорит, где и что должно быть доступно на экране.
4. Аналитик или дата-инженер — добавляет требования к метрикам, трекингу, связке событий с аналитикой.
5. Проджект-менеджер — собирает всё в единую структуру, оформляет документ по стандарту проекта, следит за непротиворечивостью и версионированием.

Заказчику на этом этапе важно сосредоточиться на формулировке вводных и целей:

1. Почему этот проект важен?
2. На какого пользователя он ориентирован?
3. Какой опыт игрок должен получить?
4. Есть ли у проекта аналоги — и чем мы хотим отличаться?

Хороший способ взаимодействия — так называемая “структурированная передача намерения”: заказчик выдает набор тезисов (цели, мечты, референсы, ограничения), а исполнитель превращает их в корректное ТЗ. В таком формате никто не тратит ресурсы впустую, и обе стороны включены в процесс.

Пример типичной ошибки из брифа:

«Хочется, чтобы механика была как в Clash Royale, но в фэнтези-мире, и попроще. Давайте миксуем PvP и кликер — ну чтобы было весело, и вон тот NFT добавить».

→ На выходе: несостыкованный жанр, конфликт темпа PvP и механики кликера, неясная аудитория и полное отсутствие технических ограничений.

Зрелый заказчик не превращается в гейм-дизайнера, но и не пишет: “Сделайте клёвую игру со злыми мишками”. Он формулирует рамки, цели, ограничения — и передаёт задачу той части студии, которая умеет переводить идеи в язык исполнения.

Типовые ошибки в составлении ТЗ для игр

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

1. Недостаточное описание геймплейных механик
2. Просто фразы вроде “игрок должен уворачиваться от объектов” не раскрывают, как это реализуется: на чем построено управление, каким образом считывается столкновение, что происходит при поражении. В результате программисты имплементируют “как поняли”, а потом всё переписывается.
3. Отсутствие экономической модели
4. Часто заказчики игнорируют поведение внутриигровой экономики: сколько и чего нужно для прокачки, как функционируют награды, какие ограничения есть на покупки. Без этих данных игра не может быть сбалансирована — и либо слишком лёгкая, либо вынуждает донатить с первых минут.
5. Платформенные противоречия
6. ТЗ требует использовать технологии, несовместимые с целевыми платформами. Например, Unity + ARKit при цели выпустить Android-приложение. Или — задаётся портативность на все устройства, но при этом указывается поддержка расширенного HDR-графики, не совместимой с бюджетными смартфонами.
7. Слишком общие или субъективные формулировки
8. “Игра должна быть веселой”, “красивая графика” или “простой геймплей” — такие абстракции не дают точек отсчёта для оценки результата. Все эти требования нужно обеспечивать конкретными метриками или примерами: “частоты взаимодействия не менее 1 на 1,5 секунды”, “графический стиль — low poly, как в Alto’s Odyssey”.
9. Нереалистичные сроки
10. Указание явно несоответствующих сроков без оценки этапов. Например, “прототип и релиз через 30 дней” при наличии 3D-контента, монетизации и аналитики. Результат — провал тестирования, утерянный код или отмена релиза.
11. Игнорирование ограничений SDK и движков
12. Часто в ТЗ записывают требования, которые не поддерживаются версией Unity, Unreal или SDK платформ. Например, “поддержка In-App Review API” на Android ниже 5.0. В итоге — фатальные ошибки при компиляции или отклонение при публикации.

Лучшим способом избежать этих ошибок — передача документа на ревью техническому и гейм-дизайнерскому специалисту, ещё до начала этапа продакшн.

Как понять, что ТЗ готово к передаче в разработку

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

1. Чётко определён жанр и игровой концепт
2. Без метафор и аналогий: указано, как именно игрок взаимодействует с игрой + основные фичи сформулированы в явном виде.
3. Изложена точка зрения игрока
4. Понятно, что видит и делает пользователь на каждом этапе — от первого входа до выхода из игры.
5. Описаны все игровые механики
6. Не просто «будет прыжок», а “по нажатию клавиши X герой подпрыгивает на Y пикселей с Z ускорением, анимация длится T секунд”.
7. Указаны технические ограничения
8. Платформа, SDK, минимальные устройства, ограничения по весу и т.п.
9. Есть блок требований к графике и звуку
10. Размеры, форматы, ограничения по FPS, звуковые сигналы по событиям.
11. Прописана аналитика и метрики
12. Какие события нужно трекать, в каком сервисе, для чего будет использоваться аналитика.
13. Регламентирован релиз и тестирование
14. Этапы финальной проверки, soft launch, условия релиза. Если нет — риск релиза с фатальными багами крайне высок.

Если документ проходит по всем пунктам — он готов к передаче в разработку. Небольшие недостающие детали допустимы, если они не влияют на ядро архитектуры или базовые механики. Но остальное должно быть зафиксировано точно.