NESゲームを研究するためのツールを作成する

NESゲームの内部構造に関する一連の出版物を続けることにしました。今回は、使用する研究ツールについてお話します。



研究者が必要とするもののほとんどは、すでにゲームのデバッグに適したFCEUXエミュレーターにあります。 ドキュメントはデバッグセクションを徹底的に研究する必要があり、そこからの各ツールは研究者にとって有用であり、それらを互いに使用する能力はハッカーの能力を高めます。



ただし、ドキュメントの再説明は行いませんが、エミュレータの機能が不十分で新しい機能を追加する必要がある場合、またはゲームコードの長い研究をバイパスして、ROMファイルで必要なものを直接見つける異常な方法がある場合に焦点を当てます。

Luaスクリプトの使用

実際、注意を引くために図に示されている最初の方法は、インタプリタエミュレータに組み込まれたLuaスクリプトを使用して補助ツールを作成することです。

上記の例では、ゲームの研究（および必要に応じて不正行為）のために、エミュレーターによって描画された画像の上に画面上に画像を表示するなど、このスクリプト機能が使用されます 。



したがって、研究者は通常のプレーヤーがアクセスできないものに気付くことができます。たとえば、上の3つの隠されたダイヤモンドのスクリーンショットでは、プレーヤーは最初の2つにしかジャンプできず、3つ目を取得することも、その存在を推測することもできません。 「Duck Tales 2」には、一般にゲームレベルの外側にあるような宝石もあります。



画面に追加データを表示するスクリプトのもう1つの例は、「ジャングルブック」の最も近い宝石へのコンパスです。







当然、RAMまたはROMゲームからの情報の視覚化だけがスクリプトの可能性ではありません。



別の頻繁に使用される機能は、ゲームコードで何が起こっているかを記録することです。たとえば、 解凍したデータを解凍した直後にダンプするスクリプトテンプレートです（SMDゲームの場合、原則はNESにも適用されます）。



さて、エミュレータにすでに含まれているTasEditorキーストロークエディタなど、 Luaスクリプトで本格的なユーティリティを作成することを禁止する人はいません。



また、私の意見では、ゲームプレイを変更するためにゲームデータがスクリプトによって即座に修正される場合、 スクリプト内のゲームコードを部分的に書き換えるという考えは過小評価されています。 「New Ghostbusters 2」の敵を修正するこのようなスクリプトの概念実証：







ただし、特定のゲームの複雑な処理や新しいハックメソッドの作成には、次のメソッドの使用を検討する価値があります。

エミュレーターのソースコードの変更

実績のサポート、 3Dレンダリング 、 改善されたグラフィックスをエミュレーターに追加するなど、ゲームの研究に関連しないさまざまなトピックについて想像する余地がありますが、記事の範囲内に留まるようにします。



リバースエンジニアリングの可能性を向上させるためにエミュレータを拡張する方向の1つは、 可能な限り多くの内部機能をLuaライブラリに投入することです。 サイクルの2番目の記事では 、新しい機能のペア全体をスクロールすることで、ユニバーサル（あらゆるゲームの探索に適した）研究ツールを作成する方法を既に示しました。







エミュレータの最新バージョンではまだ利用できない、もう1つの単純で便利な例は、メモリスクリプトからPPUを変更する機能です。



エミュレータの変更を使用して、特定のゲーム用のエディタを埋め込み、その場で実行し、加えられた変更を確認することもできます。

ゲームコードの静的分析用スクリプト

変更の前の2つのカテゴリは、実行中のゲームの動的分析に関するものでした。 ただし、ほとんどの研究は、ゲームのROMファイルの静的分析（またはそこからのデータのダンプ）です。



このコード分析のメインプログラムは、 IDA Interactive Disassemblerです。 アセンブラ6502をサポートしますが、nes形式のファイルを正しくダウンロード するためのプラグインと、ダウンロードしたファイルをコームコードに変換するルーチンアクションを自動化するスクリプトセットの両方が必要です。 NESゲームの研究に固有の一連のスクリプトがここにまとめられています 。



IDAスクリプト自体は、組み込みのidcまたはpythonコマンド言語で記述できます。いずれの場合も、テキストエディターとスタディで開くことをお勧めします。ほとんどの場合、これは、IDAスクリプトの操作に役立つIDAコマンドの理解と、そのようなスクリプトの記述方法を学ぶのに役立ちます。 これは、バイトをポインターに結合したり、いくつかのルールに従って配列を割り当てたりするなど、同様のアクションを数百回実行する必要がある場合に非常に便利です。

ゲームデータの静的分析ツール

IDAはコード分析のための優れたツールであるため、一部のゲーム研究の達人はゲームを研究し修正するだけで十分であるとさえ考えるほど優れています。 ただし、コンパイルされコメントされたソースに分解されたゲームであっても、レベル、グラフィックカード、キャラクターアニメーションなどのゲームデータを変更することは困難です。 残念ながら、ゲームのデータ形式はしばしばゲームごとに大きく異なるため、ほとんどのゲームに適したユニバーサルツールを作成することは非常に困難です。

タイルマップエディター

グラフィックバンクを保存するための形式（グラフィックを保存する最低レベル）はすべてのNESゲームの標準であるため、多くのタイルマップエディターがありますが、その中に、アプリケーションでこれらのタイルをレンダリングできる単一のライブラリが見つかりませんでした。



このようなプログラムは、CHR-ROM（グラフィックスのバンク全体）の存在下でゲームのグラフィックスタイルを編集できます。 他のゲームでは、CHR-RAMが使用されます-タイルのビデオメモリは、データとコードとともにバンクから部分的に読み取られ、ビデオメモリにコピーされます（時には非常に難しい方法ですが、データ圧縮に関する記事で説明する方が良いでしょう）。



より高いレベルでは、ゲームはすでに非常に異なっているため、一般的な編集プログラムはほとんどありません。同じエンジンで複数のゲームをカバーする最大のエディターがいます。 記事の最後に、ユニバーサルレベルのエディターを作成する試みについて説明します。その間、これらのアイデアを実装するゲームやユーティリティでデータを検索する方法について、より一般的なアイデアを紹介します。



実装言語として、私はpythonを使用します。これは、いくつかの推測をすばやく簡単に確認できること、時にはインタラクティブモードで直接確認することもできるという事実のためです。

Corrapt ROM

実際、このアイデアはサイクルの2番目の記事でした -ROMで1バイトを変更するためのすべての可能なオプションを並べ替えて、それが画面にどのように影響するかを確認すると、ゲームの内部構造を明確にするのに役立ちます。 その後、ゲームエディターの簡単なバージョンを作成することも可能です-最後に行くことなく、画面が構築されるトップレベルのブロック画像のセットを準備し、これらの画像自体がROMデータからどのように構築され、この方法で発見されたこれらの画像の配列を表示する必要があります

ブロック検索

反対側から行くこともできます。



画面に表示される背景は、固定PPUアドレスのビデオメモリタイルのインデックスの配列によって設定されます。NESには、PPU設定に応じてさまざまな方法で表示できる4つの画面があります。 画面に何が表示されるかは問題ではなく、分析のためにロードされたページを取得するだけです。



最初の画面（名前テーブル）は、PPUアドレス$ 2000- $ 23BFにあります。 FCEUXエミュレーターの内容は、 [ デバッグ]→[名前テーブルビューアー]ウィンドウで表示できます。







また、ウィンドウDebug→Hex Editor、View→PPU Memoryのバイト形式でも（アドレス$ 2000に移動します）。



ここで、ビデオメモリ全体をダンプできます。これは、分析に役立ちます（ [ファイル]→[ファイルにダンプ]→[PPUメモリ] ）。



これは、小さな8x8ピクセルのビデオメモリタイルの960インデックスの配列です。 同時に、多数のゲームが逆になった後、ゲーム画面は多くの場合、16x16または32x32ピクセルなどの大きなブロックで記述されることが知られています。 したがって、特定のブロックサイズを想定すると（最初は最も標準的なもの-スクリーンショットで赤枠で強調表示されている2x2タイルを試してみます）、画面のデータをセクションに分割できます。各セクションには1つのブロックの説明が含まれます。



これにより、画面に存在するすべてのブロックのリストが表示されます。 さらに、キャラクタースプライトに関する情報を持たない（スプライトは異なる方法で描画される）ブロックの「クリーンな」記述があり、アニメーションとは無関係です（ほとんどの場合、背景アニメーションはパレットまたはビデオメモリ自体の変更を使用して行われ、名前テーブルのタイル番号は変更されません）。 ただし、ブロック番号はわかりません。



画面にはブロックの説明がありますが、ROM内のブロックの順序はわかりません。 それにもかかわらず、ブロックの記述が正確にどこにあるかをある程度の確率で推測できます。 このアルゴリズムは次のとおりです。



1. ROM全体を調べ、ブロックが検出されたすべてのアドレスをマークしますが、その番号を維持します（実際の番号は異なる場合があり、ブロック間の違いのみに注意することが重要です）。



2. ROMで、最も多くのDIFFERENTブロックが見つかる領域を見つけます。 ほとんどの場合、これはまさにブロックの説明です。



https://gist.github.com/spiiin/500262e8d9da86f10a093bbb41833360



したがって、ゲーム内で2x2のブロックを順番に保存することができます。



これはすでに悪いことではありませんが、アルゴリズムの結果を根本的に改善する方法があります。 実際、ROMに格納する基本的なブロックサイズと方法は限られているため、すべてを並べ替えることができます。



メインブロックサイズ：2x2、4x2、2x4、および4x4ですが、必要に応じて他のサイズを簡単に追加できます。



それらをROMに格納する方法を少し複雑にすることで、ブロックを線形配列と断片化された配列の両方に格納できます（ Structure of Arrays 、略称SoA）。 最初に、ブロックの最初の部分のみの配列がROMに格納され、その後に次の部分の配列が続きます。 ほとんどの場合、そのような配列は次々に格納されますが、配列の先頭間のギャップはブロック数に等しくなります。 ROMでそのようなSoAアレイを見つけるには、すべてのオプションを列挙することで長さを調べる必要があります（多くの場合、ゲームはそれぞれ256ブロックを使用するため、この数からチェックを開始し、徐々に減らす必要があります）。



ゲームが特定のタイプのブロックを使用する確率のみに依存しているため、これはかなり混乱しているように見えますが、実際には、ユーティリティはテストされたゲームの80-90％でブロックを見つけます！







https://github.com/spiiin/NesBlockFinder



さらに、通常とは異なる構造（非ブロック）のゲームをフィルターで除外して、より詳しく調べることができます。

CDLファイルの比較

エミュレータFCEUXは、エミュレーション中に、各バイトがコードとして解釈され、どのバイトがデータとして解釈されたかを記録できます（メニューデバッグ→コード/データロガー... ）。 この機能はそれ自体有用であり、エミュレータの他のデバッグ機能と緊密に統合されています。このモードをオンにして、他のデバッグウィンドウがどのように変化したかを確認してください。 ただし、その特定のアプリケーションについて説明したいと思います。 このようなcdlファイルを2つ保存すると、1つはスタディアクションが実行される前に、もう1つは完了直後に、2つのそのようなファイルの違いはアクション中に使用されたデータ（またはコード）のみを表示します。 適切なカットオフにより、測定されたイベント間の適切な2つの時点を選択するだけで必要なデータを検索できます。



ファイル形式は、比較スクリプトのように非常に単純ですが、多くの利点をもたらす可能性があります。その上で、通常、個別のデバッグ方法論を構築できます。

コンプレッサー/デコンプレッサー

このトピックは2、3段落で開示することはできません。また、NESゲームのみのコンテキストではあまりにも単純すぎるため、別の記事に値します。

ユニバーサルCadEditorレベルエディター

実際、このプログラムは最初にゲーム「Chip＆Dale」（ Cヒップアンドデールエディター ）のレベルを表示するために作成され、その後、リクエストに応じてエディターに再作成され、最終的に他のCapcomゲーム（「Darkwing Duck」、「Duck」テイルズ1-2 "、"テイルスピン "、"リトルマーメイド "）。







後に、これらのゲームのブロックレベリングの原理は他の多くのゲームのレベルを整理する方法と非常に似ていることが判明しましたが、悪魔は詳細にあります-各ゲームの小さな違いは、これらの構造の組み合わせを使用するために、エディターの内部構造を可能な限り柔軟に記述することを必要としますエディター自体のカーネルを変更せずに、本来意図されていなかったゲームのレベル形式を記述します。



エディターの汎用性が提供される機能は、いわゆるゲーム設定です。 これらは、特定のゲームのデータをロードする方法を記述したC＃言語のスクリプトファイルです。 なぜ正確にC＃なのか？ エディターは既にこの言語で書かれており、これによりコードを変更せずにカーネルから構成に簡単に転送できました。これはLuaなどのより古典的なスクリプト言語を使用する場合に行う必要があります。



単純な設定ファイルの代わりに本格的な言語を使用すると、必要な複雑さのデータをロードおよび保存するための機能を設定で記述できます。 スクリプトは通常のテキストファイルであり、必要に応じて、既存の構成をテンプレートとして使用して、エディターを再コンパイルせずに独自の構成を作成できます。 エディターには60種類のゲームの約500個の構成が含まれています。そのうちの約100個は、参加していないエディターのユーザーによって作成されたものです。







ただし、現時点では、ユニバーサルエディターを作成しようとしても、エディター自体を変更しないと説明できないゲームが見つかります（ただし、多くのゲームは既にこの方法で追加できます）。 そのようなゲームに関する情報を通常とは異なる構造で収集するために、私はもう少し進んで、エディター自体をPythonのライブラリーとして使用し、ゲームにエディターを追加する前にゲームの形式を調べ、特定のゲームのレベルを構築する正しい理解をテストし始めました。 これをJupyterノートブックの形式で実装しました。これは、インタラクティブモードでのコードの記述方法が便利だからです。



基本的なタイルから大きなゲーム構造をコンパイルし、結果としてレベル全体を組み立てることは、数千のピースのパズルを組み立てることに似ており、最終的に各ピースがその場所にあるときに同じ喜びを与えます。



次の記事では、このような豊富な技術情報は取り上げません。標準レベル以外の構造でゲームレベルを組み立てたり、標準ブロックアーキテクチャの通常とは異なる変更を行ったりする例を紹介します。 また、コメントでNESのゲームに名前を付けることができます。そのレベル形式はあなたにとって興味深いものです。おそらく私もそれを調べます。