お気に入りのゲーム「プリンス・オブ・ペルシャ」でフロンティアモデルの進歩を分析する

投稿へスキップ プリヤンのブログ 2026年9月25日 金曜日 お気に入りのゲーム「プリンス・オブ・ペルシャ」でフロンティアモデルの進歩を分析する （Apple II、1989年）ジョーダン・メクナー作 私は1995年にIBM PC XTで初めてプリンス・オブ・ペルシャをプレイしました。時々、私はそれに立ち返ります。ロトスコープのアニメーション、王子が崖からぶら下がっている様子、ゲートが閉まる音。30年経っても、それは他に類を見ないものです。 2012年、ジョーダン・メクナーは、20年以上箱に入っていた3.5インチフロッピーディスクから復元されたオリジナルのApple II 6502アセンブリソースを公開しました（復元自体もかなりの物語です）：github.com/jmechner/Prince-of-Persia-Apple-II C#は私のお気に入りの言語なので、実験をすることにしました。そのソースコードをAIモデルに渡し、C#に移植するように依頼しました。自分でコードを読んだり編集したりしませんでした。私の唯一の仕事は、結果をプレイして何が間違っているかを言うことでした。 新しいフロンティアモデルが出るたびに、プロンプト以外は何も変えずに同じプロジェクトを与えました。 ソースはhttps://github.com/priyanr/PrinceOfPersia_C-Sharp_Port_By_AIにあります。 以下はその経過です。 ラウンド1 — Claude Opus 4.6（2026年2月） 私の最初のプロンプトはシンプルでした：「この元のコードにはプリンス・オブ・ペルシャの6502アセンブリコードがあります。レベル保存ファイルを使用し、C#コンソールで実行してみてください。」 2日間でOpus 4.6はC#コンソールゲーム、次にレベルエディタ、次にRaylibグラフィックスバージョンを生成しました。オリジナルのレベルファイル（部屋、タイル、ゲート、ガードの位置）を正しく解析しました。Apple IIゲームのように見えるものもレンダリングしました。 しかし、プリンス・オブ・ペルシャのようにプレイできませんでした。当時の私のプロンプトがその物語を語っています：「プレイできない、ひどい。グラフィックスが乱れている。」「キャラクターは出てくるが、動きがすべて間違っている…王子が床にいない。」「床の下に落ちてしまい、矢印キーで動かない。」 後で学んだコアな問題はアーキテクチャでした。王子は一度に1タイルずつ移動し、セルからセルへと飛び移りました。実際のゲームは、1フレームあたりわずかな動きで手描きのフレームアニメーションを再生します。 ラウンド2 — OpenAI Codex（2026年3月） Codexも試しましたが、どのモデルだったかは覚えていません。同じコードベースを与えました：「これはプリンス・オブ・ペルシャのオリジナルのアセンブリコードをC#に移植したもので、Claudeが作成しましたが、グラフィックスはまだ良くありません。修正できますか？」 それは、アートがぼやけないようにシャープなピクセルフィルタリング、ぼやけたスプライト背景、歩ける開いたゲート、壁として機能しなくなった柱の上部など、いくつかのまともな小さな修正を行いました。 王子はまだ間違った位置にいたり、引っかかったりしていました。表面は磨かれましたが、下のエンジンはまだ間違っていました。 ラウンド3 — Claude Opus 5（2026年9月） ここでルールを少し変えました。DOSBoxを制御する（プログラムを起動し、キーを送信し、スクリーンショットを撮る）Claudeコードスキルと、任意のWindowsプログラムを制御するスキルを作成しました。その後、オリジナルのDOS版プリンス・オブ・ペルシャにOpus 5を向け、「実物と比較し、成功するか午前6時まで実行してください」と言いました。 夜通し作業し、最初に診断したのはアーキテクチャの問題でした。古いエンジンはタイルグリッドエンジンでしたが、実際のゲームはフレームシーケンスによって駆動されていました。そのため、オリジナルの設計に基づいてエンジンを再構築しました。 そして、予想以上に進みました。DOSゲームファイルのフォーマットを解明し、実際のデータを直接読み込みました。王子のすべてのフレームアニメーション、ダンジョンアート、そして15のレベルすべてです。Apple IIソースから認識できるバイトパターンを探して、PRINCE.EXE内のオリジナルのアニメーションテーブルを見つけ、各テーブルを2番目の既知の値と比較して信頼しました。 ゲームの著作権で保護されたデータは何も私のリポジトリには入りませんでした。C#プログラムは、私のDOSインストールからライブで読み取ります。 朝にはプレイ可能なものがありました。王子は降りてきて、着地し、向きを変え、走り、ジャンプし、隙間に落ち、着地時にしゃがみ、すべて本物のアニメーションで行われました。 2回目のセッションでは、DOSBoxで最初の画面をプレイしながら、スクリーンショットを監視させ、崖を検出する方法にバグがあることを発見しました。間違ったセルで崖を探していました。オリジナルのアセンブリルーチンに戻って修正しました。 しかし、レベルはまだ正しく見えませんでした。レンガ、ゲート、装飾品はすべてわずかにずれていました。Opus 5は、スクリーンショットと1つずつ照合して各ピースを配置し、説明できないものは推測で埋めました。 ラウンド4 — Claude Opus 5.5（2026年9月）：1つのプロンプト Opus 5.5が登場したとき、私は1つのプロンプトを与えました：「キャラクターは動き、走り、ジャンプしますが、ゲートの位置やレンガなどがすべて異なります。あなたは新しいモデルです。改善できる点を見てみましょう。」 まったく異なるアプローチを取りました。目視で位置を調整する代わりに、SDLPoP by Dávid Nagyとprinced.orgコミュニティ（DOSゲームのオープンソースポートで、その逆アセンブリから再構築されたもの）で文書化されているオリジナルの部屋描画ルーチンを見つけ、そのルーチンを移植しました。 結果のDosRoomDrawer.csは、SDLPoPの部屋描画コード（src/seg008.c）の直接のC#ポートであり、ファイルヘッダーにもその旨が記載されています。 SDLPoPのドキュメントは、以前のセッションが推測していたことを説明していました。 「ランダム」なレンガパターンはまったくランダムではありません。オリジナルは部屋、行、列から乱数ジェネレーターをシードするため、壁は訪れるたびに同じように見えます。 レベル1の開始時のゲートは、実際にはレベルデータで開いています。オリジナルのゲームは、降りてくると隠しボタンを押すため、ゲートが閉まる音が聞こえます。 Opus 5.5は、私のファイルや実物と比較することで、いくつかのことを自分で見つけました。 PRINCE.EXEは実際には圧縮されています（Microsoft EXEPACK）。以前のテーブルが機能したのは、パッカーが変更を加えなかった領域にあったためだけでした。アンパッカーを作成し、実行可能ファイルからタイル描画テーブルを読み取りました。 以前のセッションで使用されたスクリーンショットの切り抜きは、1ピクセル行ずれており、以前の「ステンシルカラー」に関する理論は間違っていました。それらの色は、出口ドアの実際のティール色です。 その後、DOSBoxで実行されている実物と比較して、ピクセルごとに作業を確認しました。レベル1の最初の画面では、オリジナルと異なっていたピクセルの数は8,429から2になりました（トーチの炎が異なる瞬間に捉えられました）。2番目の部屋とレベル3の出口ドアも一致しました。 完璧ではありませんでした。また、オリジナルのコードに基づいて、王子のスプライトが描画される場所も変更しましたが、彼は片方だけを向いている状態でしか検証していませんでした。反対側を向くと、壁に数ピクセル沈みました。 何かがおかしいことに気づき、変更前のバックアップを提供しました。すべてのテストティックで動き自体が同一であることを証明し、スプライトの問題を見つけ、その部分だけを元に戻しました。この自己チェックも進歩の兆候です。 初めて、レベルがプリンス・オブ・ペルシャのように見えました。 私が持ち帰るもの Opus 4.6：6502を読み、C#を書くことができたが、間違ったアーキテクチャを選択し、それを区別できなかった。 Codex（2026年3月）：小さな修正は良かったが、基盤に疑問を持たず、ゲームを実行しなかった。 Opus 5：実物を見るためのツールを使って、アーキテクチャを診断し、再構築し、オリジナルのファイルから実データを掘り出した。それが最初のプレイ可能なバージョンだった。 Opus 5.5：1つのプロンプトから、近似するのではなく、オリジナルが実際にどのように行っているかを探し、結果をピクセルごとに証明した。 公平を期すために言うと、最後のセッションの鍵は、すでに存在していた知識でした。Dávid NagyとSDLPoPコミュニティが長年のリバースエンジニアリングから文書化した部屋描画ルーチンです。Opus 5.5はどこを探すべきかを知っており、それを移植して検証しました。DOSバイナリだけからこれらすべてを解明できたかどうかはわかりません。 そこで尋ねたところ、次のように答えました。「正直に言って、おそらく1つのプロンプトでは無理でしょう。描画コードをリバースエンジニアリングしたわけではありません。SDLPoPの再構築を読み、それを移植しました。PRINCE.EXE内のテーブルを見つけたのは、SDLPoPがその内容を教えてくれたからです。前のモデルは、その鍵なしで実行可能ファイルを検索しましたが、何も見つかりませんでした。SDLPoPなしでは、