Составление технического задания на разработку игр
Проект без ТЗ — это проект, где через три месяца разработки выясняется, что заказчик имел в виду «мультиплеер» как «можно играть вдвоём на одном экране», а команда сделала полноценный сетевой матчмейкинг. Или художники рисовали UI под разрешение 1920×1080, а игра должна работать на устройствах с 720×1280. Техническое задание на игровой проект — не формальность, а инструмент синхронизации ожиданий.
При этом ТЗ на игру принципиально отличается от ТЗ на корпоративный сайт. Здесь нужно описывать не только функциональность, но и технические характеристики, которые напрямую влияют на стоимость и сроки: целевые платформы, производительностные требования, сетевая архитектура, поддержка контента.
Что должно быть в ТЗ на игровой проект
Хорошее ТЗ закрывает три вопроса: что делаем, как это работает технически и как проверим, что сделали правильно.
Платформы и производительностные требования. Не просто «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 мс?). Это не просто «мы хотим multiplayer» — это решения, которые формируют архитектуру на годы вперёд.
Контентная модель. Как добавляется новый контент: через редактор (разработчик), через CMS (гейм-дизайнер) или через DLC (пользователь). Поддержка модификаций? Это определяет, нужна ли система Addressables с remote content, локализуемые ассеты, формат конфигурационных данных (JSON, ScriptableObject, внешняя база данных).
Типичные пробелы, которые мы закрываем
Большинство клиентов приходят с Game Design Document (или его части) — описанием геймплея, механик, сюжета. Но GDD — это не ТЗ. Из GDD непонятно: в каком движке делать, какой Render Pipeline, как будет устроен save/load, нужна ли система аналитики, как работает монетизация на техническом уровне (IAP, реклама, серверная валидация покупок).
Мы берём GDD или устное описание проекта и переводим его в технические требования. Для каждой игровой системы определяем: технический стек (библиотеки, SDK), зависимости между системами, edge cases и граничные условия, критерии приёмки.
Пример проработки одной системы. Система достижений: 50 достижений, прогресс сохраняется локально + синхронизируется с сервером, поддержка Game Center (iOS) и Google Play Games (Android). Техническое требование: AchievementManager должен обеспечивать offline-queue — достижения, разблокированные без интернета, отправляются при следующем подключении. Дедупликация на сервере по playerId + achievementId. Максимальное время синхронизации — 5 секунд при хорошем соединении. Это уже spec, с которой разработчик понимает задачу.
Структура ТЗ, которую мы используем
- Общее описание проекта — жанр, целевая аудитория, платформы, язык интерфейса, сроки
- Технические требования к платформе — ОС, железо, производительность, ориентация экрана
- Архитектура проекта — движок, Render Pipeline, сетевая архитектура, backend-сервисы
- Игровые системы — спецификация каждой системы с функциональными и нефункциональными требованиями
- Интеграции третьих сторон — аналитика (Firebase, GameAnalytics), монетизация (Unity IAP, AdMob), аутентификация (PlayFab, GameSparks)
- Требования к контенту — форматы ассетов, pipeline поставки, объёмы
- Критерии приёмки — для каждого модуля: что значит «готово»
Объём итогового документа — от 15 до 60 страниц в зависимости от сложности проекта. Для простого гипер-казуала — 15 страниц достаточно. Для RPG с открытым миром и multiplayer — меньше 40 страниц не обойтись.
| Масштаб задачи | Ориентировочные сроки |
|---|---|
| ТЗ для гипер-казуала / прототипа (1–3 системы) | 3–5 дней |
| ТЗ для мидкор-игры (5–10 систем) | 1–2 недели |
| ТЗ для сложного проекта (MMO, open world, 15+ систем) | 3–5 недель |
| Ревизия существующего ТЗ + аудит технических рисков | 3–7 дней |
Стоимость рассчитывается индивидуально после ознакомления с концепцией проекта.