Аналіз технічних обмежень цільових AR пристроїв для ігор
Розробляти AR-гру без аналізу цільових пристроїв — значить проектувати у вакуумі. Те, що відмінно працює на HoloLens 2 з x86 процесором та 4 GB RAM, виявиться нереалізуємим на Meta Quest 3 у passthrough-режимі, а те, що працює на Quest 3, може не запуститися на бюджетному Android-смартфоні з ARCore. Аналіз технічних обмежень — це перший технічний документ, який повинен з'явитися у AR-проекті, до будь-якого проектування архітектури.
Чому AR-пристрої відрізняються сильніше, ніж здається
На перший погляд: всі AR-пристрої показують віртуальний контент поверх реального світу. На практиці: вони роблять це принципово різними способами, та ці різниці диктують можливості та обмеження на рівні фізики пристрою.
Optical see-through (OST) — HoloLens 2, Magic Leap 2. Стекла буквально прозорі, доповнена реальність накладається оптично. Наслідок: неможливо відобразити непрозорий контент (не можна «закрити» реальний об'єкт віртуальним), кольори сприймаються інакше (темні відтінки практично невидимі на фоні реального світу), field of view обмежений (HoloLens 2 — близько 52°). Для ігор це означає: весь контент повинен бути достатньо яскравим та контрастним, механіки не можуть основуватися на окклюзії реальних об'єктів віртуальними.
Video see-through (VST) — Meta Quest 3, PICO 4 у AR/passthrough режимі, мобільний AR. Камера знімає реальний світ та рендерить його разом з віртуальним контентом. Перевага: повний контроль над compositing, можна робити окклюзію. Обмеження: latency між реальним світом та його відеозображенням (на Quest 3 — близько 12–15 мс), кольорові артефакти на краях об'єктів, якість пассрту залежить від камери пристрою.
Мобільний AR (iOS ARKit, Android ARCore) — VST через основну камеру смартфона. Обмеження: відсутність глибини (немає стереозрення), трекінг тільки через SLAM на одній камері, точність розміщення об'єктів ~1–2 см, немає haptic feedback рівня контролерів.
Ключові технічні параметри для аналізу
Трекінг можливості. Що вміє пристрій з коробки: plane detection, image tracking, object tracking, face tracking, hand tracking, spatial anchors, scene understanding (mesh reconstruction)?
ARKit на iPhone 12+ підтримує LiDAR-сканування, яке дає mesh реального світу та дозволяє віртуальним об'єктам «приховуватися» за реальними поверхнями через occlusion. ARCore не має depth sensor на більшості Android-пристроїв та використовує monocular depth estimation — значно менш точний.
Compute budget. AR вимагає паралельної роботи: камера + SLAM + рендер + ігрова логіка. На Snapdragon 888 це цілком працює при правильній оптимізації. На Snapdragon 680 (бюджетний сегмент) SLAM-алгоритм ARCore вже займає 20–30% CPU, та для ігрової логіки залишається значно менше. Аналіз повинен включати конкретні CPU/GPU бюджети для кожної цільової платформи.
Memory constraints. Текстури для AR-ігор часто не компресуються так агресивно, як у звичайних іграх, тому що вони накладаються на реальний світ та артефакти компресії помітніше. На пристроях з 2–3 GB RAM це створює тиск.
Display характеристики. FOV, refresh rate, pixel density — для OST пристроїв критично. HoloLens 2 має ~60 Гц refresh rate та обмежений FOV, що впливає на те, які ефекти та анімації будуть виглядати прийнятно.
Формат аналізу
Результат роботи — технічний документ з матрицею можливостей по пристроях та список constraint'ів, які повинні бути враховані в архітектурі.
Типова структура матриці: пристрій × можливість (hand tracking, plane detection, occlusion, spatial anchors) × статус (supported / not supported / limited) × обмеження та SDK-залежності.
На основі цієї матриці визначити minimum viable platform — пристрій, обмеження якого задають нижню планку для проекту, та premium experience — що доступно на більш потужних платформах.
На практиці при аналізі для мобільної AR-гри з мультиплеєром виявилось, що ARWorldMap (iOS-only API для sharing spatial anchors) дозволяє двом iPhone в одному просторі бачити одинаково розташовані об'єкти. Android-аналог через ARCore Cloud Anchors вимагає підключення до сервера Google та додає latency 500–2000 мс на синхронізацію. Це фундаментально змінює дизайн мультиплеєрної механіки: on-device sync для iOS працює майже миттєво, cloud-based sync для Android вимагає совсім іншого UX-підходу.
| Обсяг аналізу | Ориентировочні терміни |
|---|---|
| Один пристрій / одна платформа | 3–5 днів |
| Порівняльний аналіз 3–5 пристроїв | 1–2 тижня |
| Повний аналіз + рекомендації по архітектурі | 2–3 тижня |
Вартість розраховується після визначення цільових платформ та вимог проекту.