Duke Nukem: Zero Hour N64 ROMのリバースエンジニアリングプロジェクトが100%達成

 (github.com/Gillou68310)
1 ポイント 投稿者 GN⁺ 2025-10-20 | 1件のコメント | WhatsAppで共有
  • Duke Nukem: Zero Hour のNintendo 64 ROMを完全にディコンパイルしたオープンソースプロジェクトを紹介します
  • このリポジトリは、元ゲームソフトウェアのすべてのソースコードを復元する作業を100%達成しました
  • 利用者はゲームのROMを自分で所有する必要があり、米国版またはフランス版のオリジナルROMを使ってフルビルドとテストを行うことができます
  • 既存のデコンパイルプロジェクトと比較すると、完全な機能互換性とデバッグツールのサポートで技術的な優位性を持ちます
  • このプロジェクトはゲームエンジン研究、改変、移植、エンジン分析にとって非常に価値の高い資料です

プロジェクトの意義と競争力

  • Duke Nukem: Zero Hour はNintendo 64プラットフォームで独占発売された有名アクションゲームです
  • このオープンソースプロジェクトは、該当ゲームのROM全体をC、Pythonなどで完全にディコンパイルし、ソースコードレベルで再構成しています
  • 他のN64デコンパイルプロジェクトと異なり、完全な互換性を確保し、通常のROMビルドと実行、ソースコードベースのデバッグ、マルチバージョンサポートまで提供します
  • ゲームエンジン構造と1990年代のコンソールゲーム開発ノウハウを研究する上で、優れた資料的価値があります
  • 複数の自動解析・デコンパイルツール（asm-differ、mips2c、splat、decomp-permuterなど）がプロジェクトに統合され、開発者の効率が最大化されます

主な機能と構成

全体構成

  • プロジェクトはマルチ言語で構成され、C（95%以上）、Python、Roff、C++、Makefile、Shellなどで各パートが分かれています
  • 主要ディレクトリ:
    • .github/workflows: CIおよび自動化の設定
    • include、libs、src: ゲームソースとライブラリ、ヘッダー管理
    • tools: 解析、抽出、変換ツール
    • versions: US/FRなど、複数のゲーム版を同時にサポートする構成
  • 約370件近くコミットされ、活発にメンテナンスされています

ビルドと使用方法の概要

  • Ubuntu 20.04ベースの環境およびDockerサポート
  • ROM抽出、ビット単位比較、非一致（NON_MATCHING）モードのサポート
  • フランス語版と米国版ROMの両方をサポートし、ユーザーの要件に応じてオプションを指定できます
  • Docker環境およびMutagen Extensionを活用し、さまざまなOS（WIN/Mac/Linux）での互換性を提供

デバッグと開発ツール

  • gdbとmupen64plusベースのソースコードレベルデバッグをサポート（現在はWindows優先）
  • Visual Studio CodeおよびNative Debug Extensionとの連携をサポート
  • 主要な自動化・分析ツール:
    • asm-differ: アセンブリレベルのソース/ターゲット比較
    • decomp-permuter: コード再調整および自動スコアリング
    • mips2c: MIPSアセンブリからCへのコード変換
    • splat: ROM構造解析ツール

活用方法

  • ゲームリバースエンジニアリング、移植、エンジン分析、クラシックゲーム改修プロジェクトへのソース活用
  • 歴史的保存および教育研究目的にも非常に適しています
  • 複数のプラットフォームとバージョンの保守・アップデートが活発に進められています

結論

  • このオープンソースプロジェクトは1990年代のクラシックコンソールゲームソフトウェアの完全なソース公開を実現した、珍しい事例です
  • ゲームおよびコンソールのリバースエンジニアリング研究者、若手開発者、ゲーム移植およびファンゲーム制作の制作者すべてにとって貴重な資源です

関連記事

1件のコメント

 
GN⁺ 2025-10-20
Hacker Newsのコメント
  • 100% Cでデコンパイルされた状態ではあるものの、関数名や変数名の多くが自動生成のままで、まだラベリングが完全ではない点が興味深い。今この段階で誰かが移植を試みたら面白そう
    • LLMがラベリングにどれほど有効なのか気になる。誤ったラベル付けで時間を無駄にしないか心配
    • 今はGhidraのようなツールが無料で使えるので、「100% Cでデコンパイル」自体はそこまで大したことではないようにも感じる
    • Buildエンジンのソースコードが非営利目的で公開されているので、関数名や変数名のマッピングに役立つのではないかと思う
  • Gillou68310が99%をほぼ一人でやり遂げたようで、本当にすごい献身だと思う。The Legend of Zelda: Twilight Princessも順調に進んでいる https://decomp.dev/zeldaret/tp
    • この機会にCastlevania: Symphony of the Nightのデコンパイルプロジェクトにも声援を送りたい。かなり順調に進んでいる（まだやることは多いが） https://github.com/Xeeynamo/sotn-decomp
  • Zero HourはN64時代を代表するタイトルのひとつで、Duke Nukemシリーズ後期では珍しく出来の良い作品だった。歯ごたえのあるプラットフォーム要素やかなり意地悪なステージもあるが、全体として堅実な作りで、Duke 3Dの魅力を再現しようという努力が印象的だった。最近のPerfect Dark移植が素晴らしかったので、今回のデコンパイルも同じくらいのクオリティで扱われることを期待している
  • なぜよりによってDuke Nukem: Zero Hourが選ばれたのか気になる
    • Zero Hourはやや埋もれた名作だ。PlaystationのDuke Nukem作品はTomb Raiderの亜流で評価もいまひとつだが、Zero HourはオリジナルのDuke Nukem 3Dと同じくBuildエンジン系の作品だ。さすがにその水準には届かないものの、3D Realms製ではないDuke Nukem作品としては最高傑作と言ってもいいかもしれない。欠点としては視点が三人称になっていること（未完成の一人称モードはチートで存在する）と操作感があまり良くないことだ。ただ、今はソースコードがあるので、そうした問題も修正できるはず
    • いい質問だと思う。ただ、スクリーンショットがあれば友人に共有したかったのでそこは残念。昔友人たちと遊んだときは混沌そのものの楽しさだった
  • こういうデコンパイルプロジェクトに個人やグループが時間と労力を注ぐ理由が気になる。好きなゲームを愛する趣味人の集まりなのか、それともデジタル保存が目的なのか知りたい
    • 自分はCosmo's Cosmic Adventure（DOS, 1992）を再実装した人間だ。理由は単純で、このゲームが低スペックなハードウェア（IBM AT）上でどうやってあんな見事なグラフィックトリックを実現していたのか知りたかったから。このゲーム自体が特別に優れているというより、子ども時代の大切な思い出だったので愛着があった。この経験を通じてPCプラットフォームや80年代のCエコシステム、そして自分の好みまで理解できた https://github.com/smitelli/cosmore https://cosmodoc.org/
    • 自分はヴィンテージシンセサイザーのファームウェアをリバースエンジニアリングするのにかなり時間を注いできた（現代のゲームより単純ではある）。たとえばYamaha DX7やDX9のシンセROMに注釈を付けたりしていて、その過程でエンジニアリングのスキルが大きく広がった。楽しいし、とても賢い人たちと知り合う機会にもなった。技術的なジグソーパズルのようなものだ。この過程から生まれた面白いファームウェア改造もある DX7注釈化 DX9注釈化 DX97 そしてリバースエンジニアリングの過程についてのチュートリアルも書いた チュートリアル 考古学のように、以前のエンジニアの思考様式を垣間見られることもある。N64も当時としては開発難度が高かった記憶がある
    • 単純にそのゲームへの愛情が理由ということもある。自分も子どものころMega Man Battle Network 2というゲームが本当に大好きで、そのおかげで英語を学び、プログラマーにもなった。実物のカートリッジを2本保管しているくらいだ。ときどきIDAで解析して少しずつゲームを理解しようとしているが、本格的なROMハッキングコミュニティほどの腕や時間はなくても、それでも挑戦している
    • 自分から見れば、実際にやってみたい人や、並外れて挑戦心の強い人たちなんだと思う
    • 今年のGame On ExpoでCastlevania: Symphony of the Nightのデコンパイルについて発表した https://github.com/xeeynamo/sotn-decomp。こうした作業に参加する人の大半は、そのゲームを心から愛していることが動機だと思う。その次に移植、Mod制作、学習、保存欲求などいろいろある。個人的には挑戦そのものの面白さもある（数学パズルを解く感覚に近い）。長く続けるにはコンパイラの歴史や理論、さらにゲーム制作当時のビジネス上・工学上の制約まで理解する必要がある。その過程で、なぜゲームの一部がああ作られたのか気づくこともある。SotN作業の配信もしていて、質問があればチャットで何でも歓迎 https://m.twitch.tv/madeupofwires/home
  • 素晴らしいプロジェクトだ！ ただ……プラットフォームがGitHubなのが少し気になる。そのうち削除要請が来るのではないかと心配
    • リポジトリをざっと見た限りでは、著作権物は入っていないようだ。実際にデコンパイルを行うためのコードだけが置かれている
    • Nintendo作品のデコンパイルもGitHubで公開されているのに、なぜこれだけ削除される必要があるのかわからない
  • 「これはDuke Nukem Zero Hour N64のデコンパイルです。注意: このリポジトリを使用するにはゲームカートリッジが必要です」という案内があることを強調している
  • LLMがこうしたリバースエンジニアリングに向いているのか気になる
    • LLMでラベリングをかなり自動化できる。"バイナリと一致するまで反復修正する"こともできそうだが、実際に整理された事例はまだ見たことがない。参考までに decompai プロジェクトが近いアプローチを取っている（このプロジェクトとは少し違う）。自分でも試したが、ある程度情報がそろっていれば変数名の推定にはかなり役立つ。カウンタや一時変数の命名のような退屈で反復的な作業には特に有効だ。関数名もアルゴリズムのパターンを見て推測できる
    • LLM活用についてEFFが公式見解を出しているかは知らないが、著作権の観点で法的リスクがあると思う。デコンパイルは新しい創作物が生まれるからこそ可能だが、LLMは派生的・非創作的な結果を作るだけだという主張にさらされやすい。AI企業が学習データのライセンスに巨額を支払っていることも状況を複雑にしている。自分ならこうした著作権リスクがあるので使うのは避けると思う。ただ、もしLLMによるデコンパイルが本当に簡単になれば、近いうちに新しい判例が出るだろう
    • かなり使えると思う。完璧ではないが、大幅に時間を短縮してくれる。特にライブラリ関数や有名アルゴリズムの識別では、人間では太刀打ちできないほど正確だ。コンパイルとデコンパイルの過程で損なわれたコードからでも見抜ける
    • エージェントを使ってゲームの移植を進めている。ソースコードがあってもうまくいかないことが多い。LLMが多くのライブラリを移植したがらないせいで、反復作業を減らそうとして逆にスタブや仮定だらけになり、全体の作業が絡まってしまったことが何度もある
    • 自分では使ったことはないが、変数名や関数名のリネームのような局所的な改善には役立つと思う
  • 「リポジトリを使うにはゲームカートリッジの所有が必要」という注意書きにわざわざ触れている
    • 中国製のレトロ携帯ゲーム機を使う人たちは、自分でROMを吸い出さないと合法にならない。でも1万本入りの安いゲームセットを買えば、不思議なことに全部合法になる。もちろん実際に処罰される人はほとんどいないので、こういう注意書きは少し微笑ましく感じる
    • 実際にはゲームカートリッジがなくても普通に使えた。その注意書きは間違っていると思う
    • これは本当に法的な注意文にすぎず、実際の適用条件ではない
  • いまだにDuke Nukem Foreverを首を長くして待っている。もうどれくらい経ったのかさえ思い出せない