Player Navigation, Tracking, and World Guidance
What This System Is
The navigation layer turns quest markers, discovered points of interest, travel nodes, live world-event markers, personal pins, and party pings into one player-facing target model. World and quest facts remain authored or server-owned; choosing what to track is a responsive client preference.
Rules And Invariants
WorldNavigationTargetKeyidentifies every target by kind and stable id.WorldNavigationCatalogmerges target sources and reports duplicate, incomplete, or malformed targets.WorldNavigationStatepersists the primary target, pinned targets, personal pins, party pings, request ids, and revision.apply_world_navigation_commandapplies tracking changes atomically and idempotently, enforces the pin limit, and rejects unknown or unavailable targets.- Party pings use the same target representation but require party authority metadata and an expiry time.
Tracking preferences are stored in a dedicated versioned client-local preferences document. Restored targets are reconciled against the current server-authored catalog, so removed quest markers or expired pings cannot leave stale guidance behind.
How Authors Use It
Designers do not author duplicate navigation markers. Quest objectives, exploration POIs, travel nodes, active world events, personal pins, and party pings all contribute to the same target projection. Use the owning quest, exploration, travel, or event catalog to change guidance.
Guidance Projection
Same-scene targets produce compass cues containing cardinal direction, player-relative bearing, tile distance, layer difference, and arrival state. Cross-scene targets use discovered travel nodes and condition-valid routes to find the shortest route by authored travel time.
The player HUD shows the primary compass cue or next travel instruction. The journal provides a Track action for the selected quest, and the world-map panel reuses the journal surface to show unified targets, tracking state, local guidance, and route steps.
Validation And Debugging
Validation checks duplicate, incomplete, and unavailable targets before they reach the HUD, journal, or map. When guidance looks stale, reconcile restored client preferences against the current target catalog and check whether the target is still discovered, active, or in the same scene.
Examples
New authoritative POI discoveries enqueue a single discovery notification after the initial projection. Initial save/bootstrap discoveries do not flood the notification queue.
A quest objective can become the primary compass target, while a discovered waypoint supplies the cross-scene route step. A personal pin on the world map remains a client-owned target and resolves route guidance through the nearest known travel node.