「最適化のゴールドスタンダード：ローラーコースター・タイクーンの内部を探る」
## Japanese Translation:
クリス・ソーヤーの *RollerCoaster Tycoon*（1999）は、ほぼすべてのコードをアセンブリで書き、細部にわたる低レベル最適化を施したことで、滑らかなゲームプレイのベンチマークを確立しました。金額は最大想定範囲にちょうど合ったデータ型（ショップ価格は1バイト、総公園価値は4バイト）で保存されており、後にオープンソース再実装 OpenRCT2 ではこれらを統一的な8バイト変数へ移行し、現代のCPUアーキテクチャに合わせました。乗算・除算の代わりにビットシフト（`<<`/`>>`）が使用されており、コンパイラが自動で行うはずだった処理を手動で実装しています。
ゲームデザインの決定は性能制約と密接に結びついています。ソーヤーはデザイナー兼プログラマーとして、CPUフレンドリーな計算を優先する設計選択が可能でした。ゲストの移動はアトラクションへ向かう完全な経路探索ではなくランダムウォークに依存しており、多数のエージェントによる高価な計算を大幅に削減しました。パスファインディングは特定のシナリオ（例：乗物修理のメカニック、出口を探すゲスト）でのみ呼び出され、深さ制限が設けられています—デフォルトでは5つのジャンクション、条件に応じて7または8に増加し、フレームスパイクを回避します。混雑した道では同一タイルに複数のゲストが存在でき、衝突回避は完全に省かれ、近接による幸福度計算のみが影響を受けます。
OpenRCT2 はこの元のロジックをリバースエンジニアリングし、現代CPU向けに変数サイズを標準化し、パスファインダーの制限を拡張することで更新しました。これにより、レガシートリックが新しいハードウェアに適応できることが示されました。将来のアップデートでは、衝突チェックや厳密なデータサイズといった古い制約を緩和しつつ、今日のマシンで性能を損なわずにコア体験を保持することが可能です。
これらの洞察は、デザイナーとプログラマーの緊密な協働と意図的な低レベル最適化が、小規模チームでも高性能ゲームを構築できることを示しており、大手スタジオも採用すべきアプローチです。
## Text to translate
(including missing points):**
Chris Sawyer’s *RollerCoaster Tycoon* (1999) set a benchmark for smooth gameplay by writing almost all of its code in Assembly and applying meticulous low‑level optimizations. Money values were stored in data types sized exactly to their maximum expected range (1‑byte for shop prices, 4‑bytes for total park value), and the original engine later shifted these to uniform 8‑byte variables in the open‑source reimplementation OpenRCT2 to match modern CPU architecture. Bit shifting (`<<`/`>>`) was used instead of multiplication/division by powers of two, a manual trick that compilers no longer perform automatically.
Game‑design decisions were tightly coupled with performance constraints: Sawyer served as both designer and programmer, allowing design choices to favor CPU‑friendly calculations. Guest movement relied on random walking rather than full pathfinding toward attractions, drastically reducing expensive calculations for thousands of agents. Pathfinding was invoked only in specific scenarios (e.g., mechanics repairing rides, guests seeking exits) and had a depth limit—default 5 junctions, increased to 7 or 8 under certain conditions—to avoid frame‑spikes. Overcrowded paths allowed multiple guests on the same tile; collision avoidance was omitted entirely, with only happiness calculations affected by proximity.
OpenRCT2 reverse‑engineered this original logic and modernized it—standardizing variable sizes for current CPUs and extending pathfinder limits—showing how legacy tricks can be adapted to new hardware. Future updates could relax some of these old constraints (such as collision checks or strict data sizing) without harming performance on today’s machines while still preserving the core experience.
These insights underscore that close collaboration between designers and programmers, coupled with deliberate low‑level optimization, enables small teams to build high‑performance games—an approach larger studios might emulate.
