How to run a city builder on 16 MHz

The original SimCity ran on an Intel 386SX at 16 MHz, a striking feat for a game simulating city systems such as traffic, fire, power, and crime. Its source code, later released as the GPL-licensed Micropolis, reveals a key reason it could run on such limited hardware: the central Simulate() function does not update every system on every frame. Instead, a counter cycles through 16 values, and each value determines which parts of the simulation run. This spreads computational work over time rather than demanding that the CPU handle it all at once. A city system typically takes about eight frames to respond to a player’s action, and at most 15; the author argues that this delay is barely noticeable in a city builder.

The same approach appears in other kinds of games. Assetto Corsa updates only some faces of reflective cubemaps per frame, with the number controlled by a quality setting, rather than recalculating each whole cubemap at once. More adaptive systems can vary the amount or selection of work according to conditions such as screen size or time since the last update. Unreal’s Lumen, for example, distributes lighting updates, helping it produce rich visuals without recalculating everything each frame, though incomplete updates can cause temporary visual artifacts. The broader lesson is to question whether gameplay or rendering code truly needs to run in full every frame: dividing work across frames can make expensive systems practical, even when the underlying hardware is limited.