古いゲームを新しいエンジンへ移す、というだけなら珍しくありません。けれど今回の話は、1993年にバグダッドで作られたAmigaゲームを、LLMに68000 assemblyを読ませながらGodotへ持っていった、という点でかなり変わっています。作者自身が手を動かしたのではなく、モデルに解析と移植を任せ、その結果を後から自分の目で検証した。しかも対象は、ソースも長く、コメントも少なく、30年越しの事情を背負った作品です。この記事は、その実験がどこまでうまくいったのかを、当事者の視点でかなり細かく追っています。
元記事の中心は、Rabah Shihab氏が自作のAmigaゲーム「Babylonian Twins」をGodotへ移植した経緯だ。元のゲームは1993年、バグダッドで、Amiga 500上に68000 assemblyだけで作られた。512KBのRAM、ハードディスクなし、テレビにつないで動かす機械で、OSに頼らずハードを直接叩く作りだったという。美術はMurtadha Salman氏、音楽はMahir AlSalman氏が担当した。制裁下でインターネットも開発資源もなく、頼れたのはAmiga Hardware Reference Manualの1冊だけだった、と本人は振り返っている。
今回の移植で作者がまず試したのは、既存の2010年版エンジンではなく、その前提をそのままGodot 4に持ち込むことだった。最初の「安全な依頼」は、34,000行のC++で書かれた2010年のエンジンをGodotへ移すこと。次の「無茶な依頼」は、コメントも少なく、ファイル名も一部失われた72,758行の68000 assemblyをGodotで再現すること。さらに三つ目として、その1993年版を現代版の中に同梱し、購入者が後から起動できる形にする、という案まで試した。結果として、3つとも動いたと書いている。
実際の作業はClaude Code上で進めた。モデルには端末とファイルシステムがあり、コード編集だけでなく、assemblerを走らせ、ゲームを起動し、差分を確認できた。作者は命令のたびに細かく介入したわけではなく、毎晩プレイして違和感を伝え、最終判断だけを下したという。初期段階では、コマンドライン引数を追加して自動操作しやすくし、--levelで任意の面を読み込み、--poseで座標を固定し、--driveでフレーム単位の入力を送り、--probeでスイッチや扉の状態を見て、--screenshotで1フレームだけ描いて終了するようにした。これで、ジャンプの「気持ちよさ」まで機械的に確認できる土台を作った。
最初に移されたのは2010年版のC++エンジンで、22:23にGodot 4のプロジェクトを起こし、22:44には双子キャラが動き、23:19には38種類のエンティティが全部入った。翌2:15にはmacOS、iOS、Android向けの書き出しまで到達している。だが作者が本当に試したかったのはそこではない。数日後、元の68000 assemblyを渡すと、LLMはまず古いバイナリを再アセンブルし、出荷版とbyte-identicalになるところまで合わせた。そのうえで、ASM-Oneとvasmの違いを埋める前処理を自動で作り、壊れていたファイル名の対応も修復した。Amiga側のレベルデータはアドレスを手書きで並べる世界で、org命令の扱いひとつで出力がずれる。実際、ある場所では944 bytesずれて誤った絵が出たし、別の箇所では未初期化の変数が出荷済みディスクのスナップショット由来だと分かった。作者は、そこまで踏み込んで初めて「何が起きていたのか」を理解したと書いている。
まず驚くのは、作者が「移植した」のではなく、かなりの部分で「見届けた」側に回っていることだと思う。普通の移植記事なら、誰がどこを書き換えたかが主語になる。だがここでは、モデルがまず手を動かし、作者は夜に遊んで違和感だけを返す。その距離感が、かなり新しい。便利さの話で終わらないのは、作者自身が「週をまたいで読んだら、実は一番重要な発見がそこにあった」と書いているからだ。つまりLLMは単に古いコードを現代語に直したのではなく、作者が半分忘れていた実装の意味まで掘り起こした。これは生産性の話でもあるが、同時に、巨大なコード資産の再読解を機械に肩代わりさせる時代の始まりでもあるのではないかと思う。
一方で、この記事は「AIが全部やってくれた」で終わっていない。むしろ逆で、移植の難所は最後まで手触りに残っている。たとえば移動の計算はフレームレートに強く依存していて、0.85を毎フレーム掛ける設計なら、60Hzと50Hzで結果が変わる。だから1993年版は50Hz、現代版は60Hzのまま別々に保った。GodotのCharacterBody2Dも使わず、昔の手書き移動をそのまま再現している。ここは重要で、コードが「正しい」ことと、遊んだときに「同じに感じる」ことは別だ。LLMは前者をかなり押し進めたが、後者は作者と息子が実際に遊んで詰めた。技術の進歩で縮むのは実装時間でも、最終的な責任は人間から消えない。この記事が妙に信頼できるのは、その線引きをあいまいにしていないからだ。
もうひとつ面白いのは、当時の制約が、そのまま今の検証手法に接続していることだ。Amiga時代のゲームは、OSを止め、ハードウェアレジスタを直接書き、ディスクの中身も手で詰める世界だった。そのせいで、今回の移植でも「画面を見て確かめる」だけでは足りず、バイナリ一致、アセンブルの再現、フレーム単位の操作、スクリーンショット、実機ツールチェーンでのビルドといった細かな確認が必要になった。つまり昔のハードな制約が、結果的に今のLLM向けの厳密なテスト環境を要求したわけだ。
ここには、古いゲームを保存する意味も見える。単に遊べるようにするだけならエミュレータで済むこともあるが、このケースではソースの構造そのものが研究対象になっている。出荷版が「実行後のメモリのスナップショット」だったと分かったくだりは象徴的で、保存とは単純なアーカイブではないのだと分かる。過去の制作現場の癖や偶然まで、後から読み解ける形で残っていく。その作業をLLMがかなりの速度で進めた、という事実は、保存と再現のやり方を少し変えるかもしれない。
この記事は、LLMのすごさを誇る話に見えて、実はそれだけではない。むしろ強く感じたのは、30年前のコードをもう一度読むこと自体に価値がある、ということだ。作者は長いあいだ、元のバイナリを再構築する必要を感じていなかったと明かしている。だが一度そこに機械が入ると、ファイル形式、レベルデータ、メモリ配置、出荷版の生成経路まで、今まで見えていなかった輪郭が立ち上がる。LLMは答えを出しただけでなく、作者に「自分の過去を読み直させた」ように見える。
同時に、これは万能論にはならないと思う。コメントのない手書きassembly、壊れたファイル名、機種ごとの癖、感触の調整。こうしたものは、モデルが一気に突破できても、最後の納得には人間の経験が要る。だからこの記事の面白さは、AIが職人を置き換えた点より、職人がAIを使って昔の仕事を再発見した点にある。古いゲームの移植記録なのに、実は「読むこと」と「確かめること」の話として読めるのが強い。
参考: Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly — Babylonian Twins
