Modern city-building games often require multi-core CPUs and gigahertz of processing power to simulate complex economies, traffic, and infrastructure. However, the original SimCity was capable of running these simulations on an Intel 386SX processor, which operated at a mere 16 MHz. This feat of engineering was achieved not through raw power, but through clever software optimizations that distributed computational weight over time.
This image illustrates the original SimCity game which the article discusses as a prime example of efficient software engineering on limited hardware.
Analysis of the game's open-source code (released as Micropolis in 2008) reveals a specific mechanism in the `Simulate()` function within `s_sim.c`. Rather than executing every simulation sub-system—such as crime scanning, fire analysis, and tax collection—during every single frame, the game uses a `mod16` parameter. This parameter acts as a frame counter that loops from 0 to 15, determining which specific part of the simulation is updated in any given frame. By skipping most of the simulation logic on most frames, the game reduced the per-frame CPU load to a level manageable by 1980s hardware.
While this technique introduces a slight delay in how the game reacts to player inputs, the trade-off is often negligible in the city-builder genre. On average, a simulation aspect might take 8 frames to react, with a worst-case scenario of 15 frames. This principle of distributing work across frames is not limited to retro games; it is still used in modern titles like Assetto Corsa for reflection rendering and in Unreal Engine's Lumen system to manage lighting calculations. The SimCity example serves as a foundational proof that many heavy computational tasks can be optimized by asking whether they truly need to be completed in a single frame.