Складання технічного завдання на розробку 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. Всі взаємодії з детализацією на рівні «умова → дія → feedback».
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 тижнів |
Вартість розраховується після аналізу концепції та вимог проекту.