DK64 ReKONGpiled、AI生成コードなしでDonkey Kong 64をAMD Intel PCにネイティブ移植

DK64 ReKONGpiledは、公開発表から3か月足らずで、1999年発売のNintendo 64ゲームをAMD Intel PCへネイティブ移植した。この非公式移植版は、上限なしのフレームレート、ウルトラワイド出力、ロード時間の短縮、現代的な操作体系、コミュニティMODへの対応をうたう。開発者はさらに、ひときわ異例の制作上の点を強調している。移植コードの作成には生成AIを一切使用していない。

この主張は単なるマーケティング文句ではない。プロジェクトは、AI生成コードに大きく依存した別の再コンパイル版に、経験豊富なDonkey Kong 64開発者が異議を唱えたことを受けて生まれた。その対応により、懐かしのPC移植は、競合する2つの開発モデルをめぐる試金石へと変わった。

一方のモデルは、AIコーディングエージェントによる迅速な成果物の生成を優先する。もう一方は、ゲーム本体、ツール群、独特な挙動をすでに理解しているメンテナーに依存する。DK64 ReKONGpiledは後者のモデルでバージョン1.0に到達したが、長期的な品質は公開テスト、保守、MOD互換性に左右される。

DK64 ReKONGpiledはAMD Intel PCでネイティブ動作する

差し当たっての変化はシンプルだ。Donkey Kong 64は従来型のコンソールエミュレーションを必要とせず、現代的なネイティブ実行ファイルとして動作する。

開発者は2026年8月最後の週末に、Windows、Linux、macOS向けのDK64 ReKONGpiledをリリースした。プレイヤーは、プロジェクトが配布しない著作権保護済みのゲームデータを含む、互換性のある米国版Donkey Kong 64 ROMを用意する必要がある。

インストールはプラットフォーム別パッケージから始まる。アプリケーションはゲーム起動前に、合法的に取得したROMを選択するようプレイヤーに求める。プロジェクトのセットアップガイドでは、WindowsとLinux向けに個別の手順を提供しており、SteamOSおよびSteam Deckシステム向けのFlatpakも含まれている。

このリリースは、エミュレーターの設定でも従来型のROMハックでもない。静的再コンパイルを用いており、これはゲーム本来のMIPS機械命令を事前にCコードへ変換するプロセスだ。その変換コードは、その後、現代的なプロセッサーアーキテクチャ向けにコンパイルできる。

この違いは重要だ。従来のエミュレーターは、ゲームがシミュレートされた環境内で動作する間、Nintendo 64ハードウェアの挙動を再現する。静的再コンパイルは、グラフィックス、オーディオ、入力、メモリ、OS統合を支援システムが担いながら、オリジナルのプログラムロジックをネイティブアプリケーションへ移す。

DK64 ReKONGpiledは、その変換プロセスにWiseguyのオープンソースN64: Recompiledフレームワークを使用している。また、Nintendo 64ゲームの現代化版向けに開発されたレンダリングシステム、RT64も採用する。

その結果、現行のx86-64およびARM64ハードウェア上でネイティブプログラムとして動作する。この対応範囲には、対応するARMベースのマシンに加え、主流のAMD IntelデスクトップおよびノートPC用プロセッサーが含まれる。

リリース直後の動向は、相応の関心を示唆している。Hardware Bustersによると、最初のビルドは8月29日19時03分UTCに公開された。約3時間半後には、バージョン1.0.1のホットフィックスが配信された。

同メディアは、公開直後の期間にWindowsパッケージが約6,000回ダウンロードされたとも報じた。オリジナルゲーム本体やそのアセットを含まないため、このパッケージの容量は約17.6MBだった。

これらの数値は継続的な普及傾向ではなく、初期のスナップショットにすぎない。それでも、認知度のあるゲームを対象にした特化型の保存プロジェクトが、どれほど迅速に支持を集め得るかを示している。

ネイティブ構造により、開発者は表示と挙動をより直接的に制御できる。フレームペーシング、入力処理、アスペクト比、ロード、描画距離は、外部エミュレーターの調整ではなく、アプリケーションレベルの課題になる。

これは、オリジナルハードウェアのすべての構成要素が消えることを意味しない。RT64は依然として、現代のシステム向けにNintendo 64のグラフィックスパイプラインを再現している。重要な違いは、ゲームのCPU命令が実行時に解釈されるのではなく、実行前に変換されている点だ。

この技術的な境界が、「ネイティブ」という表現が正確である一方、エミュレーションが完全にゼロだという主張には留保が必要な理由を説明する。DK64 ReKONGpiledはNintendo 64全体をシミュレートしているわけではないが、変換されたゲームロジックの周囲には依然として互換性システムを必要とする。

したがって、このリリースが変えるのはアクセス性だけではない。開発者が多くのエミュレーター設定より深いレベルで変更できる、保守可能なPCアプリケーションを生み出している。

この移植版は解像度とフレームレート以上のものを変える

DK64 ReKONGpiledは、ネイティブ実行を修正、インターフェース変更、ゲームメカニクス改善の基盤として扱う。

最も目に見える強化点は、高解像度、ワイドスクリーンディスプレイ、ウルトラワイドモニター、高フレームレートへの対応だ。これらの機能はPCゲームでは一般的に聞こえるが、Nintendo 64タイトルに追加するには、メニューオプションを解除する以上の作業が必要になる。

Donkey Kong 64は4:3表示と、オリジナルコンソールの性能特性を前提に設計されていた。ビューポートやレンダリングレートが変わると、インターフェース要素、視覚効果、アニメーション挙動、タイミングが破綻する可能性がある。

チームは、オリジナルのアスペクト比に結び付いていたエフェクトを修正したと述べている。プロジェクトの機能概要によると、エフェクトをソースゲームと視覚的に一貫させたまま、あらゆるアスペクト比をサポートする。

高フレームレート対応は、カメラ移動だけにとどまらない。開発者によれば、地形、ゲームオブジェクト、テクスチャスクロール、画面エフェクト、ヘッドアップディスプレイ要素も、選択したレートでレンダリングできる。

これは重要な違いだ。一部のレトロ移植版は画像の一部だけを補間し、メニューやエフェクトをオリジナルの更新頻度に固定したままにする。その結果、移動中は滑らかに見えても、ほかの場面では一貫性を欠くことがある。

この移植版は描画距離も伸ばし、遠方の細部が消える頻度を抑える。アプリケーションはNintendo 64のカートリッジやメモリ環境に制約されないため、場面転換も速くなる。

現代的な入力オプションには、マウス操作とジャイロ操作が含まれる。プレイヤーはコントローラーも引き続き使用でき、オリジナル体験に近い操作感を維持できる。

開発者は関連設定を常設メニューにも移した。これにより、プレイヤーは外部エミュレーターのプロファイルや設定ファイルを扱うことなく、表示と操作のオプションを調整できる。

MODとテクスチャパックへの対応は、ネイティブ移植版を選ぶより大きな理由になる。プロジェクトチームによると、アプリケーションには利用可能なコミュニティMODを見つけるためのインターフェースが組み込まれている。

代表例の一つがTag Anywhereだ。このMODでは、プレイヤーは指定されたバレルへ戻らなくても、ゲーム内の5人の操作可能なKongを切り替えられる。

この変更は、Donkey Kong 64に対する根強い批判の一つに対応する。多くの収集アイテムは特定キャラクターに紐付けられており、プレイヤーは必要な切り替え地点を見つけた後にエリアを再訪することを強いられる。

移植版はTag Anywhereを唯一の遊び方として強制しない。代わりにMOD構造により、オリジナルの進行を維持するか、関連する往復移動を減らすかをプレイヤーが選べる。

そのほかに挙げられているMODには、Beaver Botherの修正や、最初からすべてのKongを使用可能にするオプションがある。今後実装予定のランダマイザーは、開発チームにとってすでに馴染みのある作業を土台に、再プレイ時のためにゲーム要素を再配置できるようにする。

パフォーマンス向上によってゲーム側の前提が変化したため、必要になった変更もある。オリジナルソフトウェアは、チャレンジのタイミングを決める際、意図的かどうかにかかわらずフレーム落ちに依存することがあった。

Fungi Forestの2回目のウサギレースは、安定した現代的なパフォーマンスでは不公平になった。より難しいKrazy Kong Klamourミニゲームのバージョンにも同様の問題があった。

開発者は両方のシーケンスを補正した。これは、保存が常に介入なしにすべての命令を再現することを意味するわけではない理由を示す、示唆的な例だ。

より高速なマシンは、オリジナルハードウェア上では一貫して現れなかったタイミング挙動を露呈させることがある。忠実なプレイには、オリジナルのボトルネックではなく、体験された結果を保つことが必要になる場合がある。

チームはHideout Helmのバグも修正した。オリジナル版では、特定の部屋でメダルを回収せずに退出すると、その後に入手できなくなる可能性があった。

これらは限定的な変更だが、エンジンレベルへのアクセスを実証している。解像度の向上は注目を集める一方、タイミングの修正と状態修正は、ネイティブ制御が実際に何をもたらすかを示している。

オーディオは引き続き、オリジナルのNintendo 64における処理挙動を基にしている。チームによれば、十分に成熟していない互換性ソリューションで発生し得るポップノイズや音の途切れなしに、音楽と効果音が維持されている。

より広範なテストがより多くのシステムを対象に実施されるまでは、プレイヤーはこれらの説明を開発者の主張として扱うべきだ。AMD Intel PCには、多くの世代のプロセッサー、グラフィックスドライバー、コントローラー、OS、ディスプレイ構成が含まれる。

リリースにはすでに迅速なホットフィックスが配信されている。これはコミュニティソフトウェアでは一般的なことだが、バージョン1.0が公開検証の終着点ではなく出発点であることも示している。

静的再コンパイルはレトロPC移植を変えつつある

DK64 ReKONGpiledが重要なのは、再利用可能な再コンパイルフレームワークが、コンソールバイナリから変更可能なPCアプリケーションまでの道のりを短縮しているからだ。

従来のソース移植は、完全なデコンパイルから始まることが多い。貢献者は機械語を研究し、オリジナルプログラムを再現する、人間が読めるソースコードを復元する。

このプロセスには何年もかかる可能性がある。開発者は、オリジナルスタジオ内では明確だったものの、製品版バイナリからは失われた関数、データ構造、メモリ挙動、関係性を特定しなければならない。

静的再コンパイルは異なる経路を取る。ツールが機械命令を現代のコンパイラーで処理可能なコードへ変換するため、何かを動かす前にすべての関数を手作業で復元する必要性を減らせる。

DK64 ReKONGpiledは、2024年に公開されたオープンソースフレームワークN64: Recompiledを使用している。このフレームワークは、Nintendo 64ソフトウェアを変換し、現代のランタイムコンポーネントへ接続するための、再現可能な基盤を提供する。

このアプローチによって個々のゲームが自動的に移植できるわけではない。開発者には依然として、ゲーム固有の知識、パッチ、設定、レンダリング統合、テスト、オリジナルハードウェアに依存する挙動への修正が必要だ。

この要件はDonkey Kong 64では特に重要である。このゲームには数多くのワールド、キャラクター、収集アイテム、ミニゲーム、カットシーン、独特な進行条件が含まれている。

タイトル画面に到達するビルドは、ゲーム全体の信頼性についてほとんど何も証明しない。開発者は、何時間も後に発生する場面転換、セーブ、ボス、キャラクター能力、スクリプトイベント、相互作用をテストしなければならない。

DK64 ReKONGpiledの貢献者は、関連する経験を持ってプロジェクトに参加した。プロジェクト報道ではRainchus、Ballaam、Killklli、2dos、Umedtakesの名前が挙げられており、複数の貢献者は確立されたDonkey Kong 64 Randomizerコミュニティとつながりがある。

この背景は開発の前提を変える。ランダマイザー作業には、進行ロジック、アイテム配置、レベル構造、セーブ挙動、失敗条件に関する深い知識が必要だ。

開発者は、グループがゲームのバックエンドに10年以上取り組んできたと述べた。この発言はチームによるものだが、既存のランダマイザー作業は、その主張を裏付ける目に見える文脈を提供している。

N64: Recompiledはすでに、ほかの現代的な移植版も支えている。Majora’s Mask、Banjo-Kazooie、Star Fox 64、Mario Kart 64に関するプロジェクトは、より広範なモデルを実証している。

これらのプロジェクトは、完成度や機能面でさまざまだ。共通する意義は、再コンパイルを一度限りの技術デモではなく、インフラとして扱っている点にある。

再利用可能なツールは、次の移植を始めるコストを下げる。レンダリングとランタイムのコンポーネントを共有すれば、あるプロジェクトでの改善が他のプロジェクトにも恩恵をもたらす。

その共有基盤には、もう一つ責任が伴う。プロジェクト固有の開発者は、互換性を損ねたり、上流コンポーネントの保守を難しくしたりする変更を避けなければならない。

レンダラー内の素早い修正は、あるゲームで見えている問題を解決できるかもしれない。一方で、同じモジュールに依存する他の移植版に副作用を生む可能性もある。

ここでDK64 ReKONGpiledの開発を巡る対立が重要になる。この衝突は、AIツールが機能するコードを生成できるかどうかだけを争点としていたわけではない。生成された変更が、ゲームを取り巻くアーキテクチャを尊重していたかが問われていた。

静的再コンパイルは移植をより多く可能にするが、ソフトウェアエンジニアリングを不要にするわけではない。労力の中心を、コンソール全体を再現する作業から、変換されたゲーム挙動の統合、テスト、保守へと移す。

プレイヤーにとって、これは古いソフトウェアとの新たな関係を生む。ネイティブ移植版は、公式再リリースを待たずに、新しいOS、入力方式、ディスプレイ、アクセシビリティの変更、MODをサポートできる。

保存活動のコミュニティにとっては、エミュレーションや完全なデコンパイルと並ぶ別の道筋となる。それぞれの手法は異なる問題を解決する。

エミュレーションはハードウェアの挙動を保存することを目指し、大規模なライブラリにも対応できる。完全なデコンパイルは可読性の高いソースを提供するが、広範なリバースエンジニアリング作業を要する。

静的再コンパイルはその中間に位置する。完全なデコンパイルより速くネイティブアプリケーションを生み出せる一方、複雑なゲームを信頼できる水準に仕上げるには、なお相当な人手が必要だ。

AIコードを一切使わないことが、プロジェクト最大の競争上の主張になった

このプロジェクトの中心的な対立は、保守可能で人間主導のエンジニアリングと、同等のドメイン理解を伴わないAI支援によるスピードとの対立である。

DK64 ReKONGpiledは、Donkey Kong 64を再コンパイルする最初の試みではなかった。別のプロジェクトがAI生成コードに大きく依存し始めた後、その開発者たちは自分たちのバージョンを公に発表した。

コントリビューターの2dosは、ランダマイザーチームが別の取り組みを引き継いだのは、他方のプロジェクトの方向性が保守しにくいと判断したためだと述べた。開発者らは、増大する技術的負債が貢献を妨げ、将来の修正を複雑にすると主張した。

PC Gamerは、AIコーディングを巡る対立に関する報道で、より広い論争を記録した。同誌は、経験豊富な保守担当者と、迅速な変換のためにコーディングエージェントを使う開発者に分かれたレトロ移植シーンを描写した。

「Vibe coding」は通常、自然言語のプロンプトでAIシステムを指示し、その生成実装の多くを受け入れることを指す。開発者は、すべての行を理解するよりも、目に見える挙動に重点を置く場合がある。

この手法は、動作するプロトタイプを迅速に生み出せる。一方で、重複したロジック、不明確な抽象化、文書化されていない依存関係、原因ではなく症状に対処する修正を、保守担当者に残す可能性もある。

こうしたリスクはAI生成コードに限らない。人間の開発者も同じ問題を生み出し得る。懸念は、誰かがコードの完全なメンタルモデルを築く前に、急速な生成がコード量を増やす点にある。

DK64チームは、具体的なアーキテクチャ上の異議を示した。2dosによれば、競合プロジェクトはゲーム固有のレンダリング問題を解決しようとする過程で、RT64そのものを変更した。

RT64は、Nintendo 64の出力を現代のシステムで表示するのに役立つ共有グラフィックスレイヤーだ。この基盤コンポーネントを変更すれば、1本のゲームを超えて互換性に影響する可能性がある。

2dosは、そのような変更は管理上の問題や予期しない視覚的副作用を引き起こすと主張した。これは利害関係者による評価であり、競合リポジトリに対する独立監査ではない。

それでも、この点は技術的な争点を明確にする。異議は、修正がどこに属すべきか、作者がどれだけ理解していたか、他のコントリビューターがそれを保守できるかに関するものだった。

Ballaamは、AI支援によるGoldenEyeプロジェクトを、もう一つの注意例として挙げた。同氏は、重大なバグによってその再コンパイル版がほとんどプレイ不能になったと主張した。

繰り返すが、この批判を、人間が書いたすべての移植版とAI支援移植版の統制された比較として扱うべきではない。プロジェクトごとに、経験、テスト範囲、目標、成熟度が異なる。

DK64 ReKONGpiledについて得られる最も強い証拠は、リリース済みのソフトウェアである。起動し、現代的な設定を提供し、複数のOSをサポートし、すでに保守アップデートも受けている。

「生成AIを一切使わない」という声明は、独立して検証するのがより難しい。外部の人間は、最終リポジトリを調べるだけで、すべてのコントリビューターが開発全体を通じてどのツールを使ったかを証明できない。

プロジェクトはこの主張を、明確な作者性へのコミットメントとして提示している。PC Gamerは、2dosがBlueskyとリリーストレーラーでこの点を繰り返したと報じた。

生成AIが趣味の開発で一般的になったため、このメッセージは響いた。生成コードを使っていないという宣言は、今では技術だけでなくプロセスに関するラベルとして機能する。

ただし、プロセスのラベルは品質を保証しない。人間が書いたコードにも、回帰、不正確な互換性、安全上の弱点、あるいは不十分な文書化が含まれ得る。

同様に、AI支援がプロジェクトを自動的に使い物にならなくするわけでもない。知識を持つ保守担当者であれば、生成された変更をレビューし、範囲を制限し、テストし、欠陥のある出力を却下できる。

実務上の境界線は説明責任だ。初期デモが注目を集めた後も、失敗を診断し、実装を保守できるほど、誰かが実装を理解していなければならない。

DK64 ReKONGpiledのリリースは、開発者にその立場を裏付ける機会を与える。継続的な修正、整理された貢献、安定したMOD、透明性の高いIssue対応は、ゼロAIというスローガンだけよりも強い証拠となる。

対立する開発モデルも、自らを証明する圧力にさらされ続ける。プレイヤーがゲームを完走でき、他のプログラマーが安全に拡張できなければ、速いプロトタイプに意味はない。

このため、このプロジェクトは非常に具体的なAIコーディングのケーススタディとなる。双方は同じ原作ゲームと似た再コンパイル基盤を扱っており、より広範なソフトウェア比較に見られる変数の一部を減らしている。

チームの背景や目的が異なるため、比較は依然として不完全だ。それでも競合する移植版は、コーディングエージェントが専門知識の価値を狭めるのか、それともレビュー時の重要性を高めるのかという現実的な問いを浮かび上がらせる。

現時点のDK64 ReKONGpiledは、後者の答えを支持している。その迅速なリリースは、一般的なコーディング能力だけから生まれたものではない。非常に複雑な1本のゲームを長年かけて理解してきた経験に支えられている。

ネイティブ化は、完成済み・無リスク・法的に単純という意味ではない

このリリースはアクセスと現代化の問題を解決するが、互換性、正確性、長期的なサポートは、今後の公開テストでなお確立されなければならない。

バージョン1.0は節目であり、Donkey Kong 64のあらゆる進行経路が正しく動作する証明ではない。ゲームの規模ゆえに、とりわけ多様なハードウェアおよびソフトウェア構成にまたがる包括的なテストは難しい。

プレイヤーは、世代の異なるAMD Intelプロセッサを、複数ベンダーのグラフィックスハードウェアと組み合わせて使用できる。ドライバーの挙動、ディスプレイスケーリング、コントローラー割り当て、Linuxディストリビューション、OSアップデートはいずれも潜在的な障害点となる。

フレームレート上限の撤廃は、別のテスト次元を加える。開発者は、元のパフォーマンスにタイミングが依存していた2つのチャレンジを調整したが、より広くプレイされれば、他の微妙な依存関係が表面化するかもしれない。

セーブデータの互換性も重要だ。プレイヤーには、アップデートで進行状況が破損したり、ゲーム状態が予期せず変わったりしないという信頼が必要になる。

MODはその保守負担を増やす。基本ゲームが安定していても、コアアップデートはTag Anywhere、テクスチャパック、ランダマイザー、その他の拡張機能に影響し得る。

ゲーム内MOD発見システムは導入を容易にするが、同時にバージョン確認と互換性情報への期待も高める。コミュニティプロジェクトでは、ユーザーが一緒にテストされたことのない変更を組み合わせると、しばしば問題が生じる。

数時間以内に最初のホットフィックスが届いたことは、対応力を示す前向きな証拠だ。同時に、公開リリースが小規模なテストグループでは得られなかった問題を即座に露呈させることも確認している。

ROMが必要であることも制約となる。DK64 ReKONGpiledはDonkey Kong 64そのものを提供せず、公式手順では、ユーザーが自ら所有するUS版を合法的にダンプする必要があるとしている。

この方式は、開発者が配布するNintendoの著作権保護対象素材の量を減らす。ただし、あらゆるリバースエンジニアリングプロジェクトや、あらゆる法域に対して、普遍的な法的保護を生むわけではない。

相互運用性、回避行為、バックアップ、著作権保護されたソフトウェアを取り巻く法律は複雑だ。移植版がROMを必要とするからといって、非公式アーカイブからROMをダウンロードすることが合法になると、ユーザーは考えるべきではない。

ネイティブ再コンパイルは、ホスティング、ソースリポジトリ、開発知識への継続的なアクセスにも依存する。主要な保守担当者が離れれば、専門的なパッチは新規参加者にとって理解しにくくなる可能性がある。

ここで、チームの反AIという主張はそれ自体の試練に直面する。人間の専門知識はより整理された判断を生み得るが、専門知識の集中は後継者リスクも生む。

優れた文書化、モジュール化された変更、テスト範囲、参加しやすい貢献の仕組みが、その専門知識を持続的なコミュニティ知識に変えられるかを決める。

「エミュレーションのオーバーヘッドなし」という表現も、慎重に解釈する必要がある。静的再コンパイルは、プレイ中にゲームのCPUコードを解釈または動的変換する必要を取り除く。

しかし、すべてのマシンでより良いパフォーマンスを保証するものではない。グラフィックス変換、ディスプレイ設定、OSの挙動、個別パッチは、依然としてリソースを消費する。

AMD Intelシステムにおいて、DK64 ReKONGpiledと成熟したNintendo 64エミュレーターを比較する広範な独立ベンチマークはまだない。したがって、低遅延や高速実行に関する主張は、プロジェクトの設計と初期報告に結び付けたままにすべきだ。

利用可能な機能リストは、より直接的に検証しやすい。ウルトラワイド出力、高フレームレート、設定メニュー、現代的な操作、より速い遷移、描画距離の拡張、MODサポートは、いずれもユーザーがテストできる。

正確性はより複雑だ。移植版は、元の物理演算、タイミング、音声、エフェクト、エッジケースのロジックから逸脱しつつも、より滑らかに見える場合がある。

安定したパフォーマンスの影響を受けるシーケンスを再調整するというプロジェクトの決定は、チームがこの問題を認識していることを示す。同時に、忠実性には判断が伴うことも意味する。

フレーム落ちをなくしたことで難しくなったレースを現代の移植版で再現すべきか、それとも元の体験に合わせてタイマーを調整すべきか。DK64 ReKONGpiledはこの場合、体験上の忠実性を選んでいる。

純粋主義者は、変更されていないタイミングを好むかもしれない。他のプレイヤーは、この調整を必要な保存措置と見るだろう。

選択肢を提供すれば一部の意見の相違は解決できるが、選択肢が増えるたびにコードとテストの要件も増える。プロジェクトは、設定可能性と管理可能な保守範囲のバランスを取らなければならない。

したがって、このリリースは、有望で技術的野心の高いコミュニティ移植版として理解するのが最適だ。エミュレーション、実機、あるいは将来の公式リリースの決定的な代替品ではない。

ReKONGpiledが続くかを示す3つのシグナル

次の試練は、ローンチ時の注目を、信頼できる保守、健全なMOD、説得力のある技術的証拠へと変えられるかどうかだ。

最初のシグナルは、2026年9月までのIssue解決状況である。初期報告は、プレイヤーがサポート対象プラットフォームで、大きなクラッシュ、セーブ失敗、進行不能バグなしにゲームを完走できるかを明らかにするはずだ。

一連の的を絞った修正を着実に重ねられれば、チームの保守性に関する主張は強まるだろう。反復するリグレッションや終盤に残る未解決の不具合は、元のコードがどのように書かれていたかにかかわらず、その主張を弱める。

特に有用なのはリリースノートだ。問題が孤立したプラットフォーム固有のものなのか、ゲーム固有の変換エラーなのか、レンダラーの相互作用なのか、あるいはmodの競合なのかを示せる。

第二の指標は、modエコシステムの健全性である。Tag Anywhereは、ネイティブアクセスによって、元の設計における煩わしい部分をどのように変えられるかをすでに示している。

より重要なのは、複数の独立したコントリビューターが、変更のたびにコアチームへ依存せず、改造を作成・更新できるかどうかだ。

安定したインターフェース、ドキュメント、互換性のあるリリースは、経験豊かな保守担当者が扱いやすいコードベースを生み出したという主張を裏付ける。通常の更新後に拡張機能が壊れるなら、アーキテクチャ上の弱点が露呈する。

modの多様性も重要だ。コスメティックパックは表現面の柔軟性を示す一方、ランダマイザーやゲームメカニクスの変更は、ゲーム状態へのより深いアクセスを試すことになる。

第三の指標は、競合するAI支援プロジェクトとの直接比較である。完了率、未解決のissue、パフォーマンステスト、コントリビューターの活動状況、コード変更の範囲は、どちらのチームのスローガンよりも有用な証拠となる。

比較では、リリース段階や機能目標の違いを考慮しなければならない。先に公開されたプロジェクトでは、より多くの人がテストするため、目に見えるバグが多く蓄積される可能性がある。

独立したレビュー担当者は、起動時のパフォーマンスとゲーム全体の正確性も区別すべきだ。高解像度での短いデモでは、セーブ、ボス戦、まれな進行状態が正しく機能するかどうかは分からない。

より広範なネイティブ移植の動きも、追加の証拠をもたらす。ほかのゲーム向けのN64: Recompiledプロジェクトは、ゲーム固有の修正が共通コンポーネントを汚染することなく、共有ツール群が成熟を続けているかを示せる。

DK64 ReKONGpiledはすでに一つの点を確立している。静的再コンパイルにより、複雑なNintendo 64ゲームを現代のPCへ移植しつつ、ディスプレイ、入力、パフォーマンス、ゲームプレイの改造を可能にできる。

同時に、ソフトウェアの来歴も製品ストーリーの一部にした。プレイヤーは今や、移植版が動作するかだけでなく、コントリビューターがそれをどのように作成し、保守しているかにも関心を向けるよう求められている。

このような検証は、証拠に基づく限り健全だ。「人間が書いた」という言葉はテストの代わりになるべきではなく、「AI支援」もまた、動作するソフトウェアを自動的に無効とみなす理由にはならない。

移植版を評価する人にとって、次に取るべき最善の行動は実践的だ。合法的なROMダンプを保存し、リリースノートを読み、クリーンなインストール環境でテストし、再現可能な問題を報告する。AMD Intelハードウェアでは、詳細なシステム情報があれば、保守担当者はゲームの不具合とドライバーまたはプラットフォームの問題を切り分けやすくなる。

このプロジェクトの長期的な成果は、ローンチ時のスローガンではない。最初の注目が去った後も、理解しやすく、修正可能で、楽しめるDonkey Kong 64移植版であることだ。