- 1999年発売の RollerCoaster Tycoon は、ほぼ全編が アセンブリ言語で書かれたシミュレーションゲーム であり、数千人の来園者をリアルタイムで処理しながらも安定した性能を維持
- 開発者 Chris Sawyer は高水準言語ではなく低水準の制御を選び、CPU 演算効率を極限まで高めた最後の世代のアセンブリゲーム を完成
- ファンプロジェクト OpenRCT2 を通じて、原作の 精密な最適化パターンとメモリ節約技法 がリバースエンジニアリングにより分析された
- ゲームは ビットシフト演算とデータ型の細分化 を活用して演算速度とキャッシュ効率を高め、経路探索の深さ制限 と 衝突演算の排除 によって大規模シミュレーションを可能にした
- こうした構造は、技術的制約を創造的に活用した最適化の典型 として、今日でも設計段階で不要な演算を取り除くアプローチの重要性を示している
RollerCoaster Tycoon の最適化構造分析
- 1999年に発売された RollerCoaster Tycoon(RCT) は、ほぼ全編が アセンブリ言語(Assembly) で書かれており、数千のエージェントをリアルタイムでシミュレーションしながらも、当時のハードウェアで安定したフレームレートを維持したゲームとして評価されている
- ドイツのゲームポッドキャスト Stay Forever で取り上げられた内容をもとに、Chris Sawyer がどのように極端なレベルの最適化を達成したのかを具体的に分析する
- 原作のソースコードは公開されていないが、ファンが制作した OpenRCT2 プロジェクトを通じて、コード構造と最適化技法をリバースエンジニアリング的に確認できる
-
アセンブリ言語ベースの性能極大化
- RCT は C や C++ ではなくアセンブリ言語 で書かれており、当時の他のゲームよりはるかに細かな性能制御が可能だった
- たとえば Doom (1993) は大半が C で書かれていたが、RCT はほぼ全編がアセンブリ言語で実装されていた
- このアプローチは1990年代後半にはすでに珍しい方式であり、RCT は 最後の大規模アセンブリゲーム の一つと見なされている
- 当時はコンパイラの自動最適化が限定的だったため、手動最適化が性能に大きな差を生んでいた
-
OpenRCT2 を通じたコード分析
- OpenRCT2 はファンが原作ゲームを完全に再実装したオープンソースプロジェクトで、原作アセットをそのまま使いながらも 100% の互換性 を維持している
- 初期バージョンは原作コードとほぼ同じ挙動を再現しており、その後さまざまな改善が加えられた
- このプロジェクトにより、原作コードの 緻密な最適化パターン を確認できた
-
データ型の細分化 — メモリ節約
- RCT は 金額データのサイズを状況ごとに変えて保存 している
- 例: 公園全体の価値は4バイト変数、売店の価格は1バイト変数を使用
- こうした細分化はメモリ節約とキャッシュ効率向上のためのもので、現代の CPU では性能差がほとんどないため、OpenRCT2 では単一の8バイト変数に統一されている
-
ビットシフトを用いた数値演算の最適化
- コード内では
NewValue = OldValue >> 演算が、2のべき乗で割る演算の代替として使われている
- この種の最適化は 乗算・除算の相手が2のべき乗のときにしか使えない ため、ゲーム内の数式自体がこの条件に合うよう設計されていたとみられる
- つまり、ゲームデザインの段階から CPU 演算効率を考慮した数理構造 が使われていたということだ
-
性能を考慮したゲームデザイン
- RCT では Chris Sawyer が プログラマであり唯一のゲームデザイナー でもあったため、設計段階から性能を意識した構造を作ることができた
- 代表例が 来園者(Pathfinding)システム である
- 多くのシミュレーションゲームでは来園者が目的地を決めて経路を探索するが、RCT では来園者が ランダムに歩き回り、偶然アトラクションを見つける
- この方式は 大規模な経路探索計算を避ける構造 であり、数千人の来園者を同時に処理できるようにしている
- 経路探索が必要な場合(例: 整備員が故障したアトラクションへ向かう場合)は、探索深度に制限 を設けてフレーム落ちを防いでいる
- 一般の来園者は交差点5つ分まで探索、整備員は8つ分まで探索
- 地図を購入した来園者は探索上限が7に増える
- こうした制限は単なる技術的妥協ではなく、ゲームプレイ要素へ自然に統合された最適化構造 である
-
群衆処理と衝突回避の省略
- RCT は 来園者同士の衝突や回避計算を完全に取り除いている
- その代わり、周辺の人口密度を追跡し、混雑度が高いと来園者の幸福度が低下する よう設計されている
- プレイヤーは依然として混雑を管理する必要がある一方、計算量は大幅に少ない
- この方式は、複雑な物理計算を取り除きつつゲーム体験を維持した 代表例として評価されている
-
現代の開発への示唆
- RCT の最適化は、技術的制約を創造的に活用した事例 として評価されている
- 今日でもこうしたアプローチは可能だが、プログラマとデザイナーの緊密な協業 が必要になる
- ときには技術的問題を解決するよりも、問題そのものを設計段階で取り除くアプローチ のほうが、より大きな性能向上をもたらすことがある
2件のコメント
ロルコタをたくさん愛してください
Hacker Newsのコメント
Warcraft 1、2、StarCraft はいずれも 2 の冪単位のマップサイズ を使っていた。
そのおかげで低速な 386/486 CPU でも、除算・乗算の代わりにシフト演算で速度を稼げた。
マップ描画、スプライト、フォント、霧効果などは数千行のアセンブリで処理し、残りは C で書かれた移植性の高いコード だった。
Blackthorne の場合、SNES、Genesis、DOS 版はそれぞれ別のアセンブリで手作業移植され、PC 版は VGA Mode X のために 10 万行のレンダリングコードをマクロで生成していた。
こうした経験から、Blizzard では「アセンブリは開発時間を食いすぎる」という教訓を得た。
Comanche: Maximum Overkill は全面的にアセンブリで書かれた ボクセルベースのヘリコプターシミュレータ だったが、プロテクトモードへの移植があまりに大変だったため、後続作からはポリゴンレンダリングに切り替えた。
EA は Command & Conquer シリーズのソースコード を公開したが、Tiberian Sun と Red Alert 2 は含まれていなかった。
StarCraft も歴史保存の観点から公開されていてほしかった。
それ以来、ゲームに完全に夢中になった。
デモシーン(demoscene) 活動もしていたのか気になる。
自分は WC3 の発売前後にコンサルタントとして少しだけ在籍していた。
記事で触れられているように、デザイナーとプログラマが同一人物 のときのほうが、はるかに印象的な成果物が生まれる気がする。
大企業の階層的な構造でも、結局は人海戦術で何かしら作れるが、本当に創造的な結果は一人の頭の中から完成することが多い。
AI 開発ツールの未来 も、こうした「1 人開発時代」への回帰になるのかもしれないと思う。
ゲームデザイナーも依然として 数値的特性 を考慮すべきだ。
優れたデザイナーほど、計算効率や精度のような要素がゲームバランスに影響すると分かっている。
今はこうした点を無視する開発者も多いが、それがゲーム品質低下の 隠れた原因 になることもある。
今では加算 1 サイクル、乗算 3 サイクル、除算 12 サイクル程度で、しかも複数の演算を同時に並列処理する。
昔の Pentium 時代は 46 サイクルかかり、クロックも 100MHz だった。
今は メモリレイアウト のほうがはるかに重要で、キャッシュミス 1 回で 100〜1000 サイクル失われる。
int[]で処理するほうがMonster[]よりずっと速い。速度、精度、保存サイズ、複雑さの間にはトレードオフがある。
Toward an API for the Real Numbers のような論文は、こうした問題を段階的に解決しようとするアプローチを示している。
浮動小数点誤差、区間演算、シンボリック演算などさまざまな方法があるが、結局 トレードオフを理解していないと問題に飲み込まれる。
たとえば Fumito Ueda は『Shadow of the Colossus』で技術的実現可能性を細かく考慮しており、Doom も創造性と技術の結合だった。
関連インタビュー 参照。
バグ、ストーリーの一貫性、没入感のほうが重要だ。
もちろんフレーム落ちがひどければ品質低下だが、ターゲットハードウェアで滑らかに動くなら、改善は別の部分に集中すべきだ。
Thumb-2 命令で定数を即値ロードできるよう調整し、メモリストールを避けた。
そのおかげで高速かつ効率的に乱数を使え、テストもすべて通った。
ただ、後に Cortex-M0 に変わったことでこのコードは破棄された。
技術的制約を ゲームプレイ要素に変換する 部分が興味深かった。
『ゼルダの伝説』の Blood Moon システム を思い出した。
「
/8の代わりに>>3を使えば除算を節約できる」という説明は、現代のコンパイラでは事実ではない。型が合っていれば、コンパイラが自動的にシフト演算へ最適化する。
「2 進数では左シフトで 2 倍になる」という説明を見て驚いた。
2026 年にこんな基本概念が改めて新鮮に感じられるほど珍しくなっているのが不思議だ。
「コンパイラは 2 の冪の乗算をシフトに変えない」というのは古いジョークだ。
2000 年代の時点ですら、コンパイラはそんなコードを見たらあくびするくらい当然のように最適化していた。
楽しく読んだ。RCT 関連では以下の資料もおすすめ。
大手スタジオでも 技術的制約をゲームの特徴へと昇華 できるのか気になる。
ストーリーテリングでも障害が物語を面白くするように、1 人開発者は技術的限界を 創造的要素へ変換 できる。
たとえばバグやグリッチをミニゲームとして再解釈するようなアプローチが思い浮かぶ。
RCT の 経路探索(pathfinding) を見て Marcel Vos の YouTube 動画 を思い出した。
彼は RCT の内部動作を深く掘り下げる動画を多数投稿している。