1993年のAmiga用ゲームをLLMが解析しGodotへ移植、作者が詳細を公開

何が起きたのか

開発者は1993年、イラクのバグダッドでAmiga 500向けのゲーム「Babylonian Twins」を制作した。512KBのメモリしかない環境で、グラフィックスやサウンドを68000アセンブリで直接制御しており、このゲームはイラクで初めて商業公開されたゲームだったとされる。その後、2010年にiPhone向けへ約34,000行のC++で手作業移植され、AppleとGoogleで特集されて約200万ダウンロードを超えた。

今回の記事では、同じ作者がLLMを使い、2010年版のC++エンジンと1993年版の68000アセンブリをそれぞれGodot 4へ移植した過程が報告されている。使われたのはClaude Fable 5というモデルで、作業は3段階に分かれ、最初にC++エンジンをGodotへ移し、次にアセンブリ版をGodot上で再現し、最後に2つを1つのアプリから起動できるようにした。すべて成功したという。

LLMは何をしたのか

作業環境はClaude Codeだ。LLMはターミナルとファイルシステムにアクセスでき、ファイル編集、アセンブラの実行、ゲームのビルドと起動、出力の確認までを自動的に行えた。実際にvasmを使って1993年のソースを組み立て直し、当時のバイナリとdiffを取って一致させる作業から始めている。

アセンブラの方言差にも対応が必要だった。当時の開発環境ASM-Oneとvasmでは、cmp命令のエンコーディングや、データを特定アドレスに配置するorgの挙動が異なるため、LLMはそれらの差分を埋める前処理を書いた。さらに、出荷済みバイナリが実行後のメモリを保存したスナップショットであることも判明し、変数領域に約108バイトの差があることが確かめられた。

移植先で変えなかったこと

注目すべきは、Godotが標準で用意するCharacterBody2Dやmove_and_slide()をプレイヤーに使っていない点だ。オリジナルの手書き移動処理と約150行の衝突判定をNode2D上にほぼそのまま移植し、当時の操作感を保った。コードの中には、作者が15年前に感覚で入れた0.49という数値や、未来の自分に向けたコメントも残っている。

実行レートも分けて維持している。2010年のiOS版は60Hzで動くように調整されていたが、1993年のAmiga版は50Hzだ。速度に毎フレーム0.85を掛けるような処理は、フレームレートが変わると結果が違ってくるため、2つの時計を統一せず、それぞれのレートで動かす判断をしている。

見えた限界と課題

一方で、自動化の範囲には限界がある。LLMはゲームのスクリーンショットを出力するが、その画像を人間が見て判断する必要があり、現代版と旧版の自動的な画像比較は行っていない。操作感についても、作者と13歳の息子が実際に遊んで確認したとされている。

作者は数週間後にコードを読み返し、一部の判断が誤っていたことも報告している。ASM-One独自のorgを処理する最初の回避策が誤り、ファイル内の後続データが944バイトずれたケースがあった。LLMの出力を追跡可能な形で検証する仕組みの重要性が、この事例からは見えてくる。