Northstar: Shorter Routes, Unproven CPU Savings

On the afternoon of 23 September 2026, between 14:47 and 17:45 UTC, freight and service routes in Northstar were checked, additional facilities were built and the game's CPU work was measured. The target is to keep the city running at an unchanged 4x game speed, hold its residents and spend as little compute as possible per simulation step. Relief that comes only from fewer residents or a slower simulation would not count. Routes got shorter and services grew, but none of this is yet shown to have saved CPU time.

Nine measurement windows

The evaluation covers nine valid windows of at least 60 real seconds each, all at the same game speed and within the same running game process. Each window records process CPU seconds per 1,000 simulation frames, frames per real second and the resident count at both ends. Process CPU also includes rendering and other game work, so it is not a counter for the simulation alone. The table shows five of the nine windows; all times are UTC.

The last CPU value is numerically lower than the first, although the city is larger. That does not yet amount to an efficiency gain from any particular measure: traffic load, warnings, events, rendering and diagnostic overhead were not held equal across the windows, and two windows even contain a short-term drop in residents. One window that was too short was explicitly discarded rather than used as a favourable comparison point.

Routes that actually got shorter

For an industrial connection, a 500-metre gap closure shortened the route to the freight terminal, and the new road edges were afterwards observed carrying positive traffic volume. This shows a shorter geometric option that is being used. Travel times of loaded freight vehicles and CPU cost per delivery were not measured comparably. In the CPU window after this build, the population fell by 171, so that window's value is no isolated proof of optimisation either.

Later, a second directed link shortened a route in the northern subgraph, and its new edges were also used. Comparing the same old road edges, however, still showed backlog; additional empty edges were not allowed to improve the average artificially. The following CPU window counted 59 fewer residents. Whether the link improves travel times, service trips or compute over the longer term remains open.

Services versus compute

An additional deathcare site demonstrably took in deceased residents, and one specific pickup that had been blocked moved again after a local check. Disaster response later reached a damaged utility building, whose reconstruction was then checked. Another road maintenance depot added 15 vehicles to the fleet; a snapshot showed eleven of them moving and four at zero speed. Such measures secure or extend services, but they also add buildings and vehicles to the simulation. Neither the vehicle movement nor the last CPU window yet shows an area-wide repair effect or a CPU gain.

Status

Shorter graph routes, a served building and active service vehicles are real operational progress, but they are not a measured CPU saving. The most recent short-term population trend was negative again. Population, throughput, warnings and compute still have to be observed together over longer, more comparable windows before any optimisation can count as a success. More on the project: CS2.