Location-Based AR Game Development
Pokémon GO had earned over 6 billion dollars by 2023. Mechanic is simple: real world becomes the map, GPS determines player position, AR camera shows characters over real surroundings. Repeating this technically is non-trivial: location-based AR requires working stack of precise positioning, AR content rendering, server game logic, and multiplayer synchronization.
Positioning: GPS Accuracy and Its Limits
CLLocationManager on iOS gives 5–65 meter accuracy depending on conditions. FusedLocationProviderClient (Google Play Services) on Android—3–20 meters. For gameplay "monster standing 3 meters away" this is unacceptable.
Compensate via ARKit/ARCore World Tracking. Algorithm: GPS gives rough position → AR session refines relative movement via VIO → next GPS fix corrects world anchor. ARCore Geospatial API (Streetscape Geometry + VPS) gives 10–30 cm accuracy in covered zones—sufficient for urban games.
ARGeoAnchor (ARKit 4, iOS 14+) allows anchoring AR objects directly to GPS coordinates. Apple uses its own VPS infrastructure to refine position. Works in major cities with good Apple Maps coverage.
Server Architecture for Location-Based Game
Game objects (monsters, artifacts, collectibles) stored in geodatabase with spatial index. For PostGIS: ST_DWithin(location, ST_Point(lon, lat)::geography, radius_meters)—query all objects within radius. Client sends coordinates every N seconds, server returns current list of objects in visible zone.
For real-time: WebSocket connection instead of polling. When other player moves or new object appears → push via WebSocket → client updates AR scene.
Geosharding: when scaling, divide map into hex grid (Uber's H3—good library) and assign services by sector.
AR Rendering in World Coordinates
Main question: how show monster 30 meters away when AR session works in local coordinates?
Approach 1 (ARGeoAnchor): anchor ARAnchor to monster GPS coordinates. ARKit manages positioning. Limitation: 500-meter radius, only supported cities.
Approach 2 (computed offset): convert monster GPS coordinates to relative offset from player position via haversine formula → get vector (dX, dY) in meters → place ARAnchor in AR space at this offset. When player GPS updates—recalculate and update all object positions.
For distant objects (50+ meters) AR render loses meaning due to GPS error. Switch to 2D radar-view: mini-map over AR image with object icons.
Typical Gotchas
Battery. GPS + ARKit + render = iPhone dies in 2–3 hours. Optimize: CLLocationManager.desiredAccuracy = kCLLocationAccuracyNearestTenMeters (not Best) during walking, reduce GPS request frequency at low movement speed.
Background tracking. For "monster appeared nearby, notify" mode need CLLocationManager with allowsBackgroundLocationUpdates = true and UIBackgroundModes: location in Info.plist. Apple checks at review—justification must be compelling.
Spoofing. Jailbreak/root + GPS spoofing—classic problem. Detection: CLLocation.horizontalAccuracy anomalously low with spoofing, sudden teleports (speed > 50 m/s), JailbreakDetector libraries. Server validation: verify physical movement possibility between points.
Timeline
Prototype with basic geolocation mechanic and AR render: 8–12 weeks. Full game with server logic, multiplayer, PvP mechanics and event system: 6–12 months. Cost calculated individually after game design.







