Разработка AR-игры с геолокацией (Location-Based AR)
Pokémon GO к 2023 году собрал более 6 млрд долларов. Механика проста: реальный мир становится картой, GPS определяет позицию игрока, AR-камера показывает персонажей поверх реального окружения. Повторить это технически — не trivial задача: геолокационный AR требует работающего стека из точного позиционирования, рендера AR-контента, серверной игровой логики и мультиплеерной синхронизации.
Позиционирование: точность GPS и её ограничения
CLLocationManager на iOS дает точность 5–65 метров в зависимости от условий. FusedLocationProviderClient (Google Play Services) на Android — 3–20 метров. Для игрового опыта «монстр стоит в 3 метрах от меня» это неприемлемо.
Компенсация через ARKit/ARCore World Tracking. Алгоритм: GPS даёт грубую позицию → AR-сессия уточняет относительное движение через VIO → при следующем GPS-фиксе корректируем world anchor. ARCore Geospatial API (Streetscape Geometry + VPS) даёт точность 10–30 см в покрытых зонах — для городских игр это достаточно.
ARGeoAnchor (ARKit 4, iOS 14+) позволяет привязывать AR-объекты напрямую к GPS-координатам. Apple использует свою VPS-инфраструктуру для уточнения позиции. Работает в крупных городах с хорошим покрытием Apple Maps.
Серверная архитектура location-based игры
Игровые объекты (монстры, артефакты, точки сбора) хранятся в геобазе данных с spatial индексом. Для PostGIS: ST_DWithin(location, ST_Point(lon, lat)::geography, radius_meters) — запрос всех объектов в радиусе. Клиент отправляет координаты каждые N секунд, сервер возвращает актуальный список объектов в видимой зоне.
Для realtime: WebSocket соединение вместо polling. При перемещении другого игрока или появлении нового объекта → push через WebSocket → клиент обновляет AR-сцену.
Геошардинг: при масштабировании делим карту на hex-сетку (H3 от Uber — хорошая библиотека) и назначаем сервисы по секторам.
AR-рендер в мировых координатах
Главный вопрос: как показать монстра в 30 метрах, если AR-сессия работает в локальных координатах?
Подход 1 (ARGeoAnchor): привязываем ARAnchor к GPS-координатам монстра. ARKit сам управляет позиционированием. Ограничение: радиус 500 метров, только поддерживаемые города.
Подход 2 (вычисленный offset): конвертируем GPS-координаты монстра в относительный offset от позиции игрока через haversine формулу → получаем вектор (dX, dY) в метрах → размещаем ARAnchor в AR-пространстве на этом offset. При обновлении GPS игрока — пересчитываем и обновляем позиции всех объектов.
Для дальних объектов (50+ метров) AR-рендер теряет смысл из-за погрешности GPS. Переходим на 2D radar-view: мини-карта поверх AR-изображения с иконками объектов.
Типичные грабли
Батарея. GPS + ARKit + рендер = iPhone садится за 2–3 часа. Оптимизация: CLLocationManager.desiredAccuracy = kCLLocationAccuracyNearestTenMeters (не Best) при движении пешком, уменьшать частоту GPS-запросов при низкой скорости перемещения.
Background tracking. Для режима «монстр появился рядом, уведомление» нужен CLLocationManager с allowsBackgroundLocationUpdates = true и UIBackgroundModes: location в Info.plist. Apple проверяет это при ревью — обоснование должно быть убедительным.
Spoofing. Jailbreak/root + GPS spoofing — классическая проблема. Детекция: CLLocation.horizontalAccuracy аномально низкая при spoofing, резкие телепортации (скорость > 50 м/с), JailbreakDetector библиотеки. Серверная валидация: сервер проверяет физическую возможность перемещения между точками.
Сроки
Прототип с базовой геолокационной механикой и AR-рендером: 8–12 недель. Полноценная игра с серверной логикой, мультиплеером, PvP-механиками и системой событий: 6–12 месяцев. Стоимость рассчитывается индивидуально после проектирования геймдизайна.