現代の都市建設ゲームでは、複雑な経済、交通、インフラをシミュレートするために、マルチコアCPUやギガヘルツ単位の処理能力が必要になることがよくあります。しかし、オリジナルのSimCityは、わずか16 MHzで動作するIntel 386SXプロセッサ上でこれらのシミュレーションを実行することができました。このエンジニアリングの快挙は、生のパワーによってではなく、計算の重みを時間的に分散させる巧妙なソフトウェアの最適化によって達成されました。
この画像は、限られたハードウェア上での効率的なソフトウェアエンジニアリングの主要な例として記事で論じられているオリジナルのSimCityゲームを示しています。
ゲームのオープンソースコード（2008年にMicropolisとして公開）の分析により、`s_sim.c`内の`Simulate()`関数における特定のメカニズムが明らかになりました。犯罪スキャン、火災分析、税金徴収といったすべてのシミュレーションサブシステムを毎フレーム実行するのではなく、ゲームは`mod16`パラメータを使用しています。このパラメータは0から15までループするフレームカウンターとして機能し、任意のフレームでシミュレーションのどの特定の部分を更新するかを決定します。ほとんどのフレームでシミュレーションロジックの大部分をスキップすることで、ゲームは1フレームあたりのCPU負荷を1980年代のハードウェアで管理可能なレベルまで削減しました。
この手法は、ゲームがプレイヤーの入力に反応する際にわずかな遅延を生じさせますが、都市建設ジャンルにおいてはそのトレードオフは無視できるほど小さいことが多いです。平均して、シミュレーションの側面は8フレームで反応し、最悪のシナリオでも15フレームです。この作業をフレーム間で分散させるという原理はレトロゲームに限られたものではありません。反射レンダリングのためのAssetto Corsaや、照明計算を管理するためのUnreal EngineのLumenシステムなど、現代のタイトルでも依然として使用されています。SimCityの例は、多くの重い計算タスクが、それらが本当に単一のフレーム内で完了する必要があるかを問うことで最適化できるという基礎的な証明として機能しています。