Gamingsimcitymicropoliswill-wrightgame-developmentoptimizationopen-source
SimCity Ran on Slow Hardware by Splitting Its Simulation Into 16 Turns and Scanning an Eighth of the Map at a Time
The open-sourced Micropolis code, Electronic Arts' release of the SimCity engine, shows Simulate() stepping a counter from 0 to 15 so map scans, taxes, power, pollution, crime, population and fire each take a turn instead of running every frame.

Lars, who writes about game development, walked through the trick on his blog, Larst Of Us, using the code EA opened up for the One Laptop Per Child project. “This source code was made public and released under the GPL license in 2008, under the name Micropolis,” he wrote. The name changed because the trademark didn’t come along with the code.
The file’s own header sets expectations. It calls itself “Micropolis, Unix Version,” a game “released for the Unix platform in or about 1990 and has been modified for inclusion in the One Laptop Per Child program,” copyright “1989 - 2007 Electronic Arts Inc.” The project’s README traces that line through the Commodore 64, the Mac and Unix workstations, and credits the game to Will Wright.
Everything starts in SimFrame(). On each call it bumps a frame counter and hands the bottom four bits of it, Fcycle & 15, to Simulate(), so the simulation walks through sixteen numbered turns over and over. At the slowest running speed, SimFrame() returns early unless a second counter is a multiple of five, and at medium speed unless it’s a multiple of three, so the city ticks along on only some of the frames.
Inside Simulate(), a switch statement gives each turn its job. Turn 0 advances the city clock and clears the census. Turns 1 through 8 each call MapScan() on one-eighth of the map’s width, MapScan(0, 1 * WORLD_X / 8) and so on to the far edge. Turn 9 does the census and collects taxes on schedule. Turn 10 lets traffic and pollution readings decay and sends messages to the player. Turns 11 through 15 run the power scan, the pollution, terrain and land value scan, the crime scan, the population density scan, and the fire analysis plus disasters.
Then the code throttles the expensive scans by speed. A row of small tables sets how often each runs: static short SpdCri[4] = { 1, 1, 8, 18 }; means that at the fastest setting, crime gets recalculated only once every 18 full cycles. Power, pollution, population and fire have their own rows. The counter that tracks those full cycles wraps at 1023, and the line that bumps it carries a three-word comment: “this is cosmic.”
Lars measured what that costs in responsiveness. “On average the simulation of an aspect takes 8 frames to react to the player’s action, 15 frames in the worst case,” he wrote. “As an input lag for a shooter this would be obviously a disaster, but for the simulation of a city? I’d argue it might actually feel better than an instant reaction.”
Lars’s headline puts the game on a 16 MHz machine. His post cites the 386SX listed in SimCity’s system requirements, and he has already corrected his own clock speed once, from 12.5 MHz. We couldn’t find the original box’s requirements in a primary source, so no clock speed is printed here. There’s a second gap, too. The code anyone can read is the Unix version from around 1990, adapted for One Laptop Per Child, and nothing in that file says whether the 1989 DOS release divided its city into the same sixteen turns.