Functional iOS architecture prototype

RelicWorld

Formerly WorldTag

A location-based capture-the-flag system exploring how real-world movement, map data, and spatial state can become playable interaction.

Category
Spatial infrastructure & prototyping
Timeline
Earlier prototype · revisited 2026
Status
Functional iOS architecture prototype
Medium
iOS · MapKit · SwiftUI · Core Location
Theme
Physical space as an interactive system
Role
Concept, systems architecture, AI-assisted prototyping

The problem

A live outdoor environment is the most hostile design surface there is: no level designer authored it, GPS drifts by the second, and the map doesn’t know which side of a fence you’re on. The engineering challenge isn’t the game — it’s turning raw, noisy sensor input into an interaction layer that is fair (objectives never land somewhere unreachable), safe (play stays away from traffic and private property), and deterministic (the same physical action always produces the same state), all without backend authority or an asset pipeline.

RelicWorld is where I worked that problem — progressively evolving an iOS prototype from a simple coordinate-proximity check into a three-phase spatial state machine.

From WorldTag to RelicWorld

RelicWorld began as WorldTag, an earlier iOS spatial prototype, and was later revisited as a more structured location-based gameplay system. The rebrand — naming only, no gameplay change — marks the shift from spatial-tagging groundwork toward a playable capture-the-flag application layer. Residual “WorldTag” references in the repository are historical.

WorldTag · the baseline

  • The earlier spatial prototype — the road-aware navigation baseline.
  • SwiftUI · MapKit · Core Location; all state local, zero backend.
  • Road-aware target placement via MKDirections walking routes.
  • Walking-route polyline sampling to keep targets on valid paths.
  • Completion gated on proximity plus heading alignment (±15°).

v0.2-road-aware-mvp · v0.2-worldtag-prototype

RelicWorld · the revisit

  • Three-phase spatial state machine: Explore → Trigger → Escape.
  • Nested world ~120 m from spawn: 50 m zone, 10 m chamber, relic revealed at 30 m.
  • Dual hysteresis buffers (5 m zone / 3 m chamber) to absorb GPS jitter.
  • Contextual target routing: zone center → relic → nearest boundary exit.
  • Flanking hazards (±30° / ±100°) with a retry-lockout loop.
  • Escape-first win: cross the zone boundary while carrying the relic.

feature/zone-foundation · zone-foundation-v1

Spatial hierarchy

The world model is a set of nested spatial containers with hysteresis buffers on every boundary — the structure that makes noisy GPS behave like a stable game state.

Spatial hierarchybase spawn → zone → chamber → relic, with hysteresis buffers~120 mBasespawn · 6 m arrivalZone · 50 m5 m exit hysteresisChamber10 m · 3 m hyst.relicflanking hazards±30° / ±100°
Nested spatial containers with dual hysteresis. The relic and chamber stay hidden until the player crosses into the zone; hazards appear only inside the chamber and guard the route back to base.

The spatial state engine

What keeps the machine legible is a deliberate separation between three kinds of state, each with a single owner.

Game phase layer

The run state machine — setup → pursuing → carrying → completed — plus a separate retry-lockout flag for a compromised escape.

World object layer

The placed entities — base, zone, chamber, relic, hazards — as fixed coordinates and radii, independent of the player’s phase.

Derived spatial layer

Live computed relationships — distances, bearings, containment, and the active target — recomputed each location update, owning no persistent state of its own.

The phases map cleanly to the loop: Explore (.pursuing) approaches with coarse guidance; Trigger fires on chamber entry — auto-pickup, hazards placed; Escape (.carrying) routes toward the nearest zone-boundary exit, and crossing it while carrying lands .completed.

Real-world engineering triumphs

The decisive lessons came from walking the prototype around an actual block, not from the simulator.

  • Dual hysteresis for boundary jitter. Field testing exposed heavy GPS noise: at any container edge the state would flap on and off many times a second. The fix was asymmetric hysteresis buffers — a 5 m exit buffer on the outer zone and a 3 m buffer on the chamber — so you enter at the line but only exit after meaningfully leaving. Crossings became deterministic instead of jittery.
  • Route polylines as a placement proxy. Rather than fetch a separate road-class dataset, placement reads geometry already in hand — sampling the MKDirections walking-route polylines and scoring candidates by connectivity and segment length to favor walkable, mid-block positions. It’s a pragmatic heuristic, not ground truth (route proximity isn’t the same as walkability), but it removes a whole data dependency and keeps objectives off yards and out of intersections in practice.

What it demonstrates

The throughline of RelicWorld is the same one in the rest of this work: take a messy, unpredictable human reality — here, raw physical movement through unauthored space — and engineer it into something intentional, fair, and safe to interact with. The substance is the systems architecture: a clean state machine, a layered separation of state, and field-hardened heuristics that survive contact with real GPS.

Field validation

Captured on-device while walking the prototype around a real block — showing zone reveal, carrying state, and retry lockout without exposing live coordinates or identifiable map detail.

Zone reveal

Zone reveal

Entering the zone reveals the relic and shifts the interface from broad guidance to target-specific tracking.

Carrying state

Carrying state

Once the relic is acquired, the target changes from retrieval to escape, proving the gameplay loop is driven by state.

Retry lockout

Retry lockout

A failed run requires physically exiting the zone before retrying, preventing rapid state-flapping and reinforcing real-world movement.

On-device captures from outdoor field testing.