Розробка AR-мультиплеєрної взаємодії в мобільному додатку
Дві людини в одній кімнаті бачать один й той же AR-об'єкт з різних кутів. Звучить просто. Насправді — синхронізація AR-просторів двох пристроїв, кожен з яких живе в своїй системі координат, плюс latency мережі, плюс drift позиціонування. Без правильної архітектури ігрова фігура в першого гравця буде в метрі від того місця, де її бачить другий.
Shared AR: синхронізація простору
ARKit — Collaborative Session. З iOS 13 ARKit підтримує ARCollaborationData — бінарні пакети з feature points та anchor інформацією, якими пристрої обмінюються прямо. Через MultipeerConnectivity (Bonjour, peer-to-peer Wi-Fi/Bluetooth) або через власний relay-сервер. Кожен пристрій будує спільну карту простору, об'єкти на ARAnchor синхронізуються автоматично.
// Відправляємо collaboration data іншим учасникам
func session(_ session: ARSession, didOutputCollaborationData data: ARSession.CollaborationData) {
let encoded = try? NSKeyedArchiver.archivedData(withRootObject: data,
requiringSecureCoding: true)
sendToPeers(encoded)
}
Обмеження: працює лише iOS–iOS, немає Android. Для кросс-платформи потрібне інше рішення.
ARCore — Cloud Anchors. Google надає серверну інфраструктуру: hostCloudAnchor() завантажує feature map якоря в хмару, повертає cloudAnchorId. Другий користувач викликає resolveCloudAnchor(cloudAnchorId) — отримує той самий якорь у своєму просторі. Синхронізуємо позиції всіх shared-об'єктів через нього. Працює iOS (ARCore SDK for iOS) ↔ Android.
Unity + Photon + ARDK (Niantic Lightship). Для gamedev-проектів часто правильніше взяти Niantic Lightship ARDK — нативна підтримка shared AR spaces, мультиплеєр через Photon, кросс-платформа. Але це Unity, не нативна розробка.
Мережевий стек для AR-мультиплеєра
AR-об'єкти у реальному часі вимагають низького latency. Архітектура:
Peer-to-peer (локально, одна мережа). MultipeerConnectivity (iOS) / Wi-Fi Aware (Android 8+) / Bluetooth GATT. Latency 10–50 мс, без сервера. Відмінно для настільних ігор в одній кімнаті, освітніх додатків. Проблема: NAT traversal при переході в інтернет.
Relay-сервер. WebSocket або WebRTC Data Channels через власний сервер або Firebase Realtime Database. Latency 50–200 мс залежно від географії. Firebase добре для прототипу, custom WebSocket потрібен при високому навантаженню (>100 одночасних учасників у сесії).
State synchronization. Два підходи: State Sync (сервер — source of truth, усі клієнти синхронізують повний стан) та Delta Sync (передаємо тільки зміни). Для AR-об'єктів з високою частотою оновлення позиції — Delta Sync з інтерполяцією на клієнті (Entity Interpolation / Dead Reckoning).
Синхронізація фізики та взаємодій
Якщо AR-об'єкти мають фізику (м'яч котиться, кубики падають) — потрібна авторитетна фізична симуляція. Варіанти:
- Server-authoritative: сервер (headless) симулює фізику, клієнти отримують стани та інтерполюють. Виключає читерство, вимагає потужного сервера
- Client prediction + rollback: клієнт передбачає результат локально, сервер підтверджує або відкатує. Складніше у реалізації, але краще по UX
Для casual AR-ігор достатньо client-side фізики з періодичною синхронізацією через state snapshot.
Тестування AR-мультиплеєра
Неможливо повноцінно протестувати в симуляторі — потрібні реальні пристрої у реальному просторі. Налаштовуємо CI/CD pipeline з Xcode Cloud / Firebase Test Lab, але фінальне QA — фізично, з кількома пристроями у приміщенні. Метрики: latency позиції об'єкту між пристроями, рассинхрон якорів, поведінка при втраті та відновленні з'єднання.
Терміни: базовий shared AR з Cloud Anchors для двох гравців в одній локації — 4–7 тижнів. Мультиплеєрна AR-гра з серверною синхронізацією, кількома кімнатами та фізикою — 3–6 місяців. Вартість розраховується індивідуально.