詳細解説
なぜアセンブリ言語なのか
1999年当時、ゲーム開発はCやC++が主流になりつつあった。id SoftwareのDoom（1993年）もCで書かれていた。にもかかわらず、Chris Sawyerはアセンブリ言語を選択した。理由は、限られたハードウェアリソースから最大限のパフォーマンスを引き出すため。彼はプログラマーであると同時にゲームデザイナーでもあり、技術的な制約を深く理解した上でゲーム設計を行った。
極限のメモリ効率
RCTのデータ表現は徹底的に圧縮されている。公園の総価値は4バイト（32ビット整数）、商品の価格は1バイトで表現。すべてのデータサイズが最小限に抑えられ、当時の限られたRAMでも数千人のゲストと複数のコースターを同時にシミュレーションできた。
ビットシフトと2の累乗設計
乗算や除算はCPUにとって重い演算だが、2の累乗の乗除算はビットシフトで高速に処理できる。RCTはゲーム設計自体を2の累乗前提で構築した。タイルサイズ、ゲストの移動単位、価格の刻みなど、あらゆる数値が2の累乗に合わせて設計されている。技術的制約がゲームの根幹に組み込まれている。
革新的な経路探索 — 「迷子」という設計
一般的なゲームでは、AIキャラクターにA*などの経路探索アルゴリズムを使わせる。しかし数千人のゲスト全員にリアルタイム経路探索をさせるのは、当時のCPUでは不可能だった。Sawyerの解決策は大胆だった：ゲストは目的地を持たず、ランダムに歩き回り、偶然乗り物やショップに出会う。
技術的制約 → ゲームデザイン：この設計のおかげで経路探索の計算負荷はほぼゼロになった。同時に、「ゲストが出口を見つけられない」というプレイヤーの有名な不満（そしてそれ自体がゲームの面白さ）が生まれた。看板を適切に配置してゲストを誘導するのもゲームプレイの一部になった。
プログラマー兼デザイナーの強み
Chris Sawyerが一人でほぼ全体を作ったからこそ、技術と設計がここまで深く統合できた。大規模チームでは「プログラマーはコードを書き、デザイナーは仕様を書く」と分業するが、Sawyerは両方を同時に考えていた。技術的制約をゲームの面白さに変換するという、まさに一人の天才による仕事だった。