Разработка 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). Для геймдев-проектов часто правильнее взять 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 пайплайн с Xcode Cloud / Firebase Test Lab, но финальное QA — физически, с несколькими устройствами в помещении. Метрики: latency позиции объекта между устройствами, рассинхрон якорей, поведение при потере и восстановлении соединения.
Сроки: базовый shared AR с Cloud Anchors для двух игроков в одной локации — 4–7 недель. Мультиплеерная AR-игра с серверной синхронизацией, несколькими комнатами и физикой — 3–6 месяцев. Стоимость рассчитывается индивидуально.