Зауважимо: коли команда отримує типове технічне завдання (ТЗ) для VR-гри, спринти йдуть на уточнення: «який trigger radius?», «яка анімація при хапанні?». Без чітких специфікацій проєкт буксує. Ми спеціалізуємося на розробці VR-ігор та складанні ТЗ, які виключають ці питання, спираючись на досвід більш ніж 10 комерційних VR-проєктів (понад 7 років досвіду). У результаті розробники отримують документ — специфікація VR гри, де кожен нюанс прописаний — від performance budget VR до типу locomotion VR. Замовники економлять у середньому 20% на етапі розробки за рахунок зниження кількості переробок. Вартість ТЗ починається від 5000 грн для прототипу. Замовте складання ТЗ просто зараз і отримайте документ, який виключає неоднозначності.
Детальніше про Interaction Model
Чому Interaction Model — основа будь-якого 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 від контролера».
Такий рівень деталізації здається надмірним, поки розробник не починає реалізовувати це і не ставить десяток питань, кожне з яких затримує спринт. Згідно зі специфікацією OpenXR Specification, Section 6.2, trigger-зона має бути не менше 5 см, але в нашому ТЗ ми враховуємо конкретні значення під задачу. Наше ТЗ краще за типові шаблони в 4 рази за глибиною опрацювання механік, що підтверджує зворотний зв'язок від клієнтів. Використання нашого ТЗ скорочує кількість ітерацій у 2 рази порівняно з типовими шаблонами.
Які розділи обов'язкові для комфорту у VR?
Comfort Requirements — розділ, який найчастіше пропускають. Тут фіксуються: допустимі locomotion типи, параметри vignette (увімкнено за замовчуванням, чи можна вимкнути), максимальна кутова швидкість camera rig при snap turn, мінімальний high framerate target (72/90/120 Гц залежно від платформи), та список контенту, що потребує попередження про motion sickness. Комфорт у VR важливий для задоволення гравців.
Performance Requirements — конкретні числа, не «висока продуктивність». Для Meta Quest 3: target framerate 90 fps, maximum draw calls на frame 250, GPU time budget < 11 ms, memory budget 3.5 GB. Для SteamVR (PC): minimum GPU — RTX 2060, target 90 fps, reprojection не повинен активуватися при нормальній ігровій ситуації. Performance Budget — основа VR оптимізації. Чіткий Performance Budget економить до 30% бюджету на переробках — це підтверджує наш досвід. Розробка за нашим ТЗ у 2 рази швидше, ніж без нього.
Платформна матриця та технічний стек
У ТЗ обов'язково включаємо платформну матрицю — таблицю, в якій для кожної платформи (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).
| Платформа | Target FPS | Макс. Draw Calls | GPU Time Budget | Memory Budget |
|---|---|---|---|---|
| Meta Quest 3 | 90 | 250 | < 11 ms | 3.5 GB |
| SteamVR PC | 90 (min 72) | 500 | < 12 ms | 6 GB |
| PICO 4 | 90 | 250 | < 11 ms | 3.5 GB |
Технічний стек фіксується з точними версіями: Unity LTS (остання стабільна версія), XR Plugin Management, використовувані SDK (OpenXR, Meta XR SDK, SteamVR Plugin), сторонні пакети. Це виключає конфлікти версій.
Процес складання ТЗ
Покроковий чек-лист:
- Аналіз концепту та брифу: виявляємо ключові механіки та платформи.
- Драфт ТЗ: описуємо Interaction Model, продуктивність, комфорт.
- Технічне рев'ю з розробниками: перевіряємо реалізованість та несуперечливість.
- Фінальна версія з acceptance criteria для кожної механіки, включаючи QA-тестування. VR QA тестування проводиться з урахуванням специфіки платформ.
Ми організовуємо 2-3 ітерації, щоб документ був повністю узгоджений. Наше ТЗ у 5 разів детальніше за типові шаблони — це підтверджує зворотний зв'язок від клієнтів. Приймальні тести (acceptance criteria) включають перевірку продуктивності, взаємодії та відсутності помилок — це основа QA-тестування VR-проєкту.
Що входить у роботу
- Повний документ ТЗ у форматі PDF/Google Docs.
- Рев'ю з вашою командою розробників.
- Acceptance criteria для кожного модуля.
- Підтримка при питаннях протягом місяця.
Орієнтовні терміни
| Обсяг проєкту | Терміни |
|---|---|
| MVP / прототип (3–5 механік) | 1–2 тижні |
| Повноцінна гра (10–20 механік, 1–2 платформи) | 3–5 тижнів |
| Мультиплатформний проєкт з мультиплеєром (підтримка VR мультиплеєра) | 5–8 тижнів |
Точне ТЗ дозволяє заощадити до 35% бюджету проєкту. Вартість розраховується після аналізу концепції та вимог до проєкту. Зв'яжіться з нами для консультації. Отримайте попередній аналіз вашого проєкту вже сьогодні.
Гарантія: ми гарантуємо точність специфікацій і підтримуємо документ в актуальному стані.