Розробка 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 місяців. Вартість розраховується індивідуально після проектування геймдизайну.