Game Systems/The Network

Demand and ridership

Every rider number in MetroForge comes from one place: the assignment pass. It builds a demand matrix, routes that demand through your network, and produces flows. Ridership, revenue and crowding are all derived from those flows.

The vehicles you watch moving around the city are a visualisation. They are never the source of a statistic.

Where trips come from#

Demand is a gravity model over districts. Each resident generates 0.9 transit-relevant trips per day. Destination choice decays with distance on a 3,600 m kernel, and each origin considers at most 14 destinations — so a district generates plausible local trips rather than a uniform spray across the map.

How a trip chooses a path#

The assignment builds a graph whose nodes are (station, route) pairs plus a street node per station, then runs Dijkstra over it. The cost of a journey is measured in minutes and adds up:

Walking to and from stations, at 1.35 m/s, within the mode's walk radius.
Waiting, charged as half the headway. Doubling your frequency halves the wait cost, which is why frequency competes directly with coverage.
In-vehicle time, from the mode's speed and dwell.
Transfers, at a flat 5-minute penalty each. A trip requiring two changes starts 10 minutes behind a direct one before anyone has moved.
Crowding, see below.

Beyond a total transit cost of 90 minutes, nobody rides at all.

Competing with the car#

Every origin-destination pair is a choice between your network and driving. The car is modelled at 8.3 m/s effective urban speed plus an 8-minute overhead for parking and access.

The split is a logit with a sensitivity of 9 minutes. That means it is smooth, not a cliff: being 9 minutes worse than the car does not lose you every rider, and being marginally better does not win you all of them. Small improvements in generalized cost move ridership continuously.

Crowding#

Daily route ridership is converted to a peak-hour load using a peak fraction of 14% — the share of daily riders travelling in the busiest hour.

Crowding is peak load divided by capacity. Below a knee of 0.8 it is comfortable and free. Above the knee, each unit of crowding adds up to 22 minutes of discomfort to the route's in-vehicle cost, BPR-style.

This is the negative feedback that stops a single line absorbing a whole city. An overcrowded route becomes expensive in generalized cost, so riders shed to alternate routes or back to the car. Sustained crowding above 1.1 also drags your approval down a little each day.

Headway and capacity#

Service frequency is derived from vehicles and route length. A single vehicle on a huge loop still reports a finite headway — capped at 30 minutes — rather than "never comes".

Each mode has a minimum headway you cannot beat, which is the real ceiling on a corridor's capacity. Once you are at minimum headway on a crowded metro line, more vehicles will not help; you need another line or a higher-capacity mode.

Cadence#

Assignment reruns at most every 300 ticks, and whenever the network changes. A tick is one game-second and a game day is 1,200 ticks, so demand re-solves several times a day and immediately after you edit anything.

What this means in play#

Frequency is a lever as strong as coverage. Wait cost is half the headway, in the same minutes as everything else.
Transfers are expensive. 5 minutes each. A direct route that is slightly longer often beats a fast two-seat ride.
Crowding is self-limiting, and it costs you approval. A line at 1.1+ is shedding riders and losing you public support.
You are always competing with the car, not with nothing. A new line only earns the trips where it beats 8.3 m/s plus 8 minutes.
Watch the unserved overlay. Pairs served worse than a 35% transit share are flagged as gaps, which is where new demand is actually available.