Составление технического задания на разработку VR игр
Техническое задание для VR-игры — один из самых сложных документов в геймдеве. Проблема не в объёме, а в специфике: большинство шаблонов ТЗ написаны для веб-приложений или обычных игр и не покрывают VR-специфику. Команда, получившая такое ТЗ, вынуждена додумывать детали на ходу — и эти «додуманные» детали оборачиваются переделками на поздних этапах.
Что обязательно в ТЗ для VR, чего нет в обычном ТЗ
Раздел Interaction Model — подробное описание всех механизмов взаимодействия. Не «игрок подбирает предметы», а «при входе правой или левой руки в trigger-зону объекта на расстоянии ≤ 10 см появляется highlight outline (цвет #FFE066, толщина 2 мм в world space). При нажатии Grip Button объект прикрепляется к attach point [right/left hand palm], с transition анимацией 0.1 с. При отпускании Grip Button с velocity < 0.5 м/с объект остаётся на месте. При velocity ≥ 0.5 м/с — физика броска с inherit velocity от контроллера».
Такой уровень детализации кажется избыточным, пока разработчик не начинает реализовывать это и не задаёт десяток вопросов, каждый из которых задерживает спринт.
Платформенная матрица — таблица, в которой для каждой платформы (Meta Quest 2, Quest 3, Steam VR, PICO 4) расписаны: input method (контроллеры / hand tracking / keyboard), минимальная версия OS/firmware, required SDK (OpenXR / OVR / SteamVR), поддерживаемые features (passthrough, spatial anchors, eye tracking).
Comfort Requirements — раздел, который чаще всего пропускают. Здесь фиксируются: допустимые locomotion типы, параметры vignette (включена по умолчанию, можно ли отключить), максимальная угловая скорость camera rig при snap turn, минимальная high framerate target (72/90/120 Гц в зависимости от платформы), и список контента, требующего предупреждения о motion sickness.
Performance Requirements — конкретные числа, не «высокая производительность». Для Meta Quest 3: target framerate 90 fps, maximum draw calls на frame 250, GPU time budget < 11 мс, memory budget 3.5 GB. Для SteamVR (PC): minimum GPU — RTX 2060, target 90 fps, reprojection не должен активироваться при нормальной игровой ситуации.
Структура ТЗ для VR-проекта
Хорошее ТЗ для VR-игры включает следующие разделы:
1. Обзор проекта и платформы. Краткое описание, целевые платформы, минимальные системные требования, целевая аудитория, возрастной рейтинг.
2. Технический стек. Unity версия (с конкретным номером, например 2023.2.x LTS), XR Plugin Management конфигурация, используемые SDK (OpenXR, Meta XR SDK, SteamVR Plugin), сторонние пакеты.
3. Interaction Model Document. Все взаимодействия с детализацией на уровне «условие → действие → фидбек».
4. Locomotion Specification. Типы перемещения, параметры comfort settings, обработка boundary violations.
5. Scene Requirements. Для каждой сцены: play area size, object count estimate, lighting approach (baked / realtime / mixed), audio setup.
6. Performance Budget. По платформам: framerate, draw calls, poly count, texture memory, shadow casting lights count.
7. Audio Specification. 3D audio engine (Unity AudioSource / FMOD / Wwise), spatial audio approach, haptic feedback mapping.
8. Multiplayer / Networking (если применимо): topology, sync rate, latency requirements, state reconciliation approach.
9. Save System. Что сохраняется, формат, миграция при обновлении версии.
10. QA Requirements. Acceptance criteria для каждой механики, тест-кейсы для критических сценариев.
Практика составления
Одна из самых частых ошибок при составлении ТЗ для VR — описывать то, что видит пользователь, а не то, как это должно работать. «Рука игрока физически взаимодействует с рычагом» — это не ТЗ. ТЗ: «При входе ладони в trigger-зону рычага активируется XRGrabInteractable. Рычаг перемещается вдоль оси Y в диапазоне от -30° до +30° относительно pivot point. Текущий угол передаётся через event OnLeverAngleChanged(float angle). При угле > 25° активируется GameEvent LeverActivated. Physics simulation: Rigidbody с angular drag 2.0, без gravity».
Работа над ТЗ включает несколько итераций с командой: сначала черновик на основе концепта и брифа, затем техническая ревью с разработчиками (выявляем нереализуемые или противоречивые требования), затем финальная версия с acceptance criteria.
| Объём проекта | Ориентировочные сроки |
|---|---|
| MVP / прототип (3–5 механик) | 1–2 недели |
| Полноценная игра (10–20 механик, 1–2 платформы) | 3–5 недель |
| Мультиплатформенный проект с мультиплеером | 5–8 недель |
Стоимость рассчитывается после анализа концепции и требований к проекту.