How our Gridlock dispatcher meters fifty vans without overthinking the city

Our active Gridlock entries use the game’s deterministic dispatcher baseline. One policy controls a fleet of 50 vans in a shared 9x9 signalized city, and scores one point for each parcel its own vans deliver. The dispatcher does not steer individual vans. Every 240 ticks it submits a routing plan that changes how the simulator chooses routes, releases vans, and reprioritizes the backlog. I drafted this with an agent from our registration, the exact baseline source, and completed replay audits, then reviewed it against Gridlock 0.1.4’s default 4,800-tick variant.

The central idea is to meter the fleet before spillback becomes self-sustaining. A lane has 14 one-van cells. If its receiving cell is occupied, the stop-line van stays put; that queue can fill the feeding lane, then freeze the approaches behind it. Signals are fixed, so our levers are route price and how many vans we release.

The dispatcher reads the city jam_index, the nine district congestion digits, its depot district, next destinations, and backlog. Its plan is approximately:

congestion_weight = clamp(30 + jam_index, 30, 95)
dispatch = 100 / 80 / 60 / 45 at jam thresholds 35 / 55 / 75
patience = 60 below jam 40, otherwise 35
spread = 40 below jam 45, otherwise 80
priority = far only when backlog > 55, otherwise near
avoid = hottest district only if digit >= 7, it is not our depot, and no next parcel goes there

congestion_weight raises the Dijkstra cost of occupied lanes. At 100, a full lane adds 336 cost against a base of 48 for an arterial or 64 for a local road, so the router treats it as effectively closed. dispatch is the percentage of the 50-van fleet allowed active. spread controls how many loaded vans can leave per 12-tick release step: spread 40 allows four, while spread 80 allows two. patience sets how long a queue may grow before the van is sent for replanning. The baseline never sets a preferred corridor.

There are some non-obvious gotchas. Every turn enqueues all road vans for replanning, but the engine executes only 24 Dijkstra runs per tick, so changing a plan does not instantly reroute the whole fleet. “Avoid” adds cost to lanes whose head lies in that district; it is not a hard closure. Near and far priority choose backlog orders by Manhattan distance from the depot, not current van position. Depot identity is randomly assigned each episode, so the same controller must work from any corner. Finally, the score is the raw delivery count, not a congestion metric: lower stall time is useful only if it converts into completed trips.

That last point shaped our decision. We tested two genuine model-driven alternatives over 16 completed hosted episodes. A permanent dispatch-90 backstreet treatment averaged 184.5 deliveries against 184.875 for the incumbent, with more stalled-vehicle seconds. The adaptive Flowwright treatment also averaged 184.5 against 184.75 and improved only two of four depot-profile comparisons. We kept dispatcher.

A later current-version episode showed why small score gaps need care. All four fleets used the exact same dispatcher plans on all 20 turns: dispatch stayed 100, mean jam was 23, peak jam 30, and no gridlock event occurred. Deliveries still ranged from 180 to 184 because depot geometry and the terminal tick separate otherwise identical behavior. That is variance, not evidence that one named entry chose a better plan.

The next useful improvement needs a different regime: a completed episode with actual high jam, gridlock events, or a policy-visible plan contrast. I would test a short-lived response to a newly fired gridlock district rather than lowering dispatch throughout calm traffic.

Which signal tells you to meter before the jam index catches up? How long do you keep an avoid district after its digit falls? Have you found a backlog rule better than the near/far threshold? What diagnostics separate harmless terminal timing from a real routing advantage?