Routing System

Overview

The TinyMUX routing system provides a room-to-room pathfinding engine that computes shortest paths through the game’s exit graph. It was developed in four phases, each adding capability on top of the previous one.

Phase 1: Static Unconditional Routes

The foundation of the routing system is a static next-hop table built by the @route/set command. This table records, for every reachable pair of rooms, the first exit to take on the shortest path.

@route/set

@route/set

Computes the routing table for the current zone. The table is stored in memory and provides O(1) lookup for the next hop between any two rooms.

route()

route(<source>, <destination>)

Returns the dbref of the exit to take from <source> to move one step closer to <destination>. Returns #-1 if no route exists.

routepath()

routepath(<source>, <destination>)

Returns the complete list of rooms along the shortest path from <source> to <destination>, including both endpoints.

Phase 2: Per-Zone Routing with Gateway Selection

Phase 2 introduces per-zone routing tables. Each zone maintains its own internal routing table. Cross-zone travel is handled by a meta-table that records gateway rooms – rooms with exits leading into other zones. When route() or routepath() is asked for a path that spans zones, the engine first identifies the gateway room in the source zone that leads toward the destination zone, routes to that gateway, then continues in the next zone.

Phase 3: Lock-Validated Routing

Phase 3 adds exit lock awareness. When computing a route, the engine evaluates the lock on each exit along candidate paths. Exits whose locks fail for the traveling object are excluded from consideration. This means route() and routepath() return paths that the object can actually traverse, not merely paths that exist topologically.

Lock validation occurs at query time, so results reflect the current lock state. An exit that was locked a moment ago and is now unlocked will immediately become available for routing.

Phase 4: NPC Movement Primitives

Phase 4 builds on the routing engine to provide automated movement commands for objects (typically NPCs).

@walk

@walk <object> = <destination>

Moves <object> along the computed route from its current location to <destination>, one room per tick. The object traverses exits normally, triggering all associated attributes (@oenter, @oleave, etc.) as it moves. If no route exists, the command fails silently.

@patrol

@patrol <object> = <room1> <room2> [<room3> ...]

Cycles <object> through a list of waypoint rooms indefinitely. The object walks to the first waypoint, then to the second, and so on. After reaching the last waypoint, it starts again from the first. The patrol continues until explicitly stopped with @halt.

Examples

Set up routing for a zone and query a path:

@route/set
Route table built: 47 rooms, 112 exits.

> say route(here, #200)
You say "#345"

> say routepath(here, #200)
You say "#100 #150 #175 #200"

Send a guard NPC on a patrol route between three rooms:

@patrol #500 = #100 #200 #300

Walk a messenger NPC to a specific room:

@walk #501 = #200

Related Topics

route(), routepath(), @walk, @patrol, Zones, Movement System.