アラジンのソースコードの宝物を探して

1993年のリリースの時点で、セガジェネシスのディズニーのアラジン （または90年代前半に水たまりの反対側に住んでいた場合はメガドライブ）は驚くほど美しいゲームでした。



後にDigicelとして知られるようになったテクノロジー、ミドルウェアの正しい選択、および著者の印象的な才能のおかげで、アラジンはその時代の他のジェネシスゲームから際立っていました。 美しい手描きのアラジングラフィックスは、Genesisのハードウェアで達成できるものに新しいレベルの品質を設定します。 これは、特に興味深いラスター効果や秘密のハードウェア技術の助けではなく、壮大なグラフィック、デザイン、適切な技術の組み合わせのおかげで可能になりました。



このグラフィックとテクノロジーのユニークな組み合わせが、アラジンがビデオゲームの歴史の中で特別な地位を占めることを可能にした主な理由でした。 したがって、 Video Game History Foundationコレクションで、ゲームの完全なソースコードを含むアーカイブを見つけることができてとても嬉しかったです！ 貴重なデータソースに加えて、このアーカイブは、ソースコードの保存、ツールの依存関係の追跡、VGHFのその他の多くのプロセス指向の側面に関する標準を作成する絶好の機会です。











このアーカイブでは、ほぼすべての開発ツールと資料がそのまま残っています。 私はすぐにそれらのフラグメントのマージを開始し、ソースコード（完全にアセンブルされた言語M68Kで記述されている）を作業バイナリに埋め込む作業を開始しました。 私の旅とその各段階での発見についてお話しします。 多くの未リリースの資料を見つけたり、ゲームの商用リリース前に削除されたオブジェクトや敵を再販売したりすることも含まれます！



何も隠さないので、技術的な話を楽しんでください。 気に入らなければ、写真があります（パート3.0の隠された宝物にすぐに行くことができます）！ Noesisのコピーをダウンロードして、私と一緒にプロジェクトを探索することもできます。 このツールが不明な場合は、簡単に説明します。フレームワークに基づいて構築されており、リバースエンジニアリングとすべてのデータタイプの調査に役立ちます。 スクリプトfmt_virginmd_chopper.pyがあり、Aladdinのすべての既知の（商用およびその他の）ROMイメージからChopperタイルのすべてのデータを抽出できます。 結果のデータは、Noesis自体で表示できます。 リリースに達していないデータにアクセスすることはできませんが、完成した製品でフレームを表示し、タイルがどのように使用されているかを観察することができます。



また、NoesisがCESのAladdinデモビルドからChopperデータのバックアップを抽出できることも注目に値します。 このアセンブリには、通常のゲームプロセス中にアセンブリで使用できない追加ドラフトを含む、いくつかのユニークなものがあります。











CESのデモビルドにはChicago CESというラベルが付いていますが、TCRFビルドの記事に示されているように、SNASMで生成されたタイムスタンプの日付は1993年6月27日です。 これは、展示会の数週間後にアセンブリが作成されたことを証明しています。



ソースコードアーカイブを見ると、ソースグラフィックスの一部が6月に既に変更されており、CESのデモアセンブリのROMから削除されていることがわかります。 これから結論を引き出すことはできません（データベースからChopperを削除した後、ソースグラフィックスが変更されたかどうかはわかりません）プロジェクトの以前のスナップショットのさらなる開発ではありませんでした。 ただし、簡単にするために、このアセンブリに関連する資料について説明するときは、引き続き「CESのデモアセンブリ」と呼びます。

1.概要

Aladdinゲームのアーカイブは、ソースコードとゲームデータの誰かの作業コピーであり、一般的なリポジトリではないように見えます。 アーカイブには、データの依存関係の一部がありません。これは、ある段階でゲームが同じ職場に向かったため、少し驚くべきことです。 しかし、ほとんど問題なく欠落データを再現し、動作するバイナリを取得することができました。



他のすべてはアラジンの小売コピーと一致しているように見えますが、一部のソースファイルへの変更は1993年9月30日までさかのぼります。 これは、1993年9月20日にリリースされた日本の小売バージョンのビルド日より10日後です。 データに目立った変更はありませんが、バイト比較ではビルド条件が大きく異なるため問題が発生します。



ここで非常に興味深いのは、このアーカイブに元のグラフィック素材の大部分が含まれていることです！ ここに、ゲームにはなかったものがあります。 この資料は通常、他のツールによってより理想的でコンパクトな形式で収集され、ROM自体に含まれています。 この記事では、これらすべてのツールとプロセスについて検討します。









アニメーションフレームのソースデータの例。



このAladdinアーカイブでのもう1つの大きな発見は、プロトタイプ機能やリモート機能のコメントアウトされたコードの大きなセクションでした。 現在、プログラマがコメント内の既に使用されていないコードの数百行を完全に削除するのではなく削除する場合、コード分析プログラムはほとんどの場合それを切り捨てます。 しかし、この驚くべき実践のおかげで、24年後にはゲームに参加するはずだった機会、敵、その他多くのものを楽しむことができます！ ちょっとしたコード記述基準を取りましょう！

2.ツール

コードの構築から使用するデータの作成と準備までのプロセス全体で、Aladdinは便利なMS-DOS環境に配置されたかなり大量のツールセットを使用します。 このアーカイブにより、Virginがこのゲームを実装するために使用する実際のコンテンツ作成プロセスを効果的に調査できます。 このセクションでは、各ツールの機能を説明し、これらのツールの研究と使用の記録を概説します。

2.1。 SNASM68K

アーカイブ内の古いログは、Aladdinのソースアセンブラーがバージョン1.29（またはコードコメントに示されているように1.30） SNASM68Kであったことを報告しています。 何年も前にSega CDの開発に少し脱線した後、私はすでにSNASMに少し精通していましたが、このツールの新しいバージョンにアクセスできました。 これは、いくつかの変更を加える必要があるソースを構築することを意味しました。 最も不快な変更は、ある時点でSNASMが「！」から切り替えることを決めたことです。 および「|」 OR演算子を使用すると、マクロが大幅に変更されます。 また、メモリアーキテクチャが商用バイナリに比べて比較的変化していなかったとしても、いくつかの分岐演算子を追加する必要がありました。



コードを調べると、FOLDER.68Kというファイルがアセンブラのエントリポイントになることがすぐに明らかになりました。 このファイルには、「ビルド構成」のようないくつかの変数が定義されています。 変数の多くは、条件付きでコードビットを含む/除外し、ROMに書き込むデータを決定します：PALまたはNTSC。 これに対処し、SNASMバージョンの違いに関連する問題を解決した後、結果のバイナリを実行しようとしましたが、これを見てうれしかったです。











チート画面のこの断片は、判明したように、小売版でアクティブです。 SNASMによって追加された更新されたタイムスタンプでこのアーカイブのコードを実行すると、デフォルトで表示されます。 起動時の外観は、これらの「ビルド構成」変数のいずれかに依存します。



私は喜んでゲームに移りましたが、最初のレベルをロードするときにハングに遭遇しました。 デバッガーを試してみましょう！ だから、私はデバッガを持っていません。 クラッシュの範囲を狭めるために自分自身にトランジションを挿入して問題を解決しようと数回試みた後、ゲームの拷問を停止し、デバッガーで独自のアセンブリを作成するために50個のライブラリをダウンロードする必要のない組み込みデバッガーを備えたGenesisエミュレーターがあるかどうかを確認することにしました。 この時点で、デバッガーをオンにしてRegenビルドを見つけました。



凍結状態の後にRegenにブレークポイントを設定すると、プログラムカウンターが理解できない場所にあり、レジスタのステータスが乱れ、スタックにジャンクがあったため、組み込みのAladdin例外ハンドラーを使用しようとしても最後の通常のコード実行場所を見つけることができませんでした。 そして、それは楽しくないことが明らかになりました。



何が起こっているのかを理解するためにSNASMを使用してアドレススキームを作成した後、コードのポイントでアドレスを取得しました。これは、レベルのロードが始まる場所のようなものです。 このアドレスにPCブレークポイントを設定し、プログラムを実行します。 チェックポイントで停止した後、プログラムを段階的に続行しましたが、RAMでのProPackのアンパック手順の近くのどこかで忘却に陥っていることに気付きました。 つまり、FLOORレベルのデータを展開するとき。 それらは名前と一致します-これはフロアセックスタイルを設定するルックアップテーブルです。



かなり長い間、私は最終的に目的地の住所に気付くまで、問題を観察することなく、段階的に開梱サイクルを経験しました。 この手順では、ユーザースタック全体のフロアデータを展開しました。 それは間違いのようです！ RAM内のアクティブなフロアの位置を決定するラベルを調べましたが、実際には、それらはユーザーのスタックのすぐ上にありました。



判明したように、すべてのアンパックされたフロアタイルの最大サイズを取得し、それを使用してRAMのフロア領域のサイズを決定するマクロには、何らかの魔法がありました。 結果として、私のバージョンのSNASMのこのマクロマジックは優れた値-0を計算しました。このエラーを修正し、同じマジックを使用するコード内の他の場所を探しました。 ゲームの表面には明らかなエラーはありませんでした。

2.2。 チョッパー

Chopperは、VirginがDigicelテクノロジーと呼んだものの基礎を築いた名声のないヒーローです。 残念ながら、ある時点でグラフィックがDeluxePaint Animationにインポートされたという事実を除き、グラフィックを手動でレンダリングしてデジタル化するプロセスに関する情報はありません。 標準のハードウェア/ソフトウェアソリューションが主に使用されたのか、Virginが独自の開発を追加したのかはわかりません。 私が知っているのは、データがDeluxePaint Animationに入った後、そこからChopperが取得されたことです。



チョッパーは、独自のスプライトデータベース形式に基づいて動作する完全に独自のインターフェイス駆動型ツールです。 その主な開発者はAndy Astorでしたが、他の人々が開発に参加したようです。 Genesis出力データ形式を思いついたDavid Perryを含む。 残念ながら、アーカイブにはChopperのソースコードがないため、添付のドキュメントからのみその開発を調査できます。



Chopperの主なタスクは、インポートしたアニメーションを1×1から4×4のサイズのタイルにカットすることでした（各タイルのサイズが8×8ピクセルの長方形サイズを含む）。 彼には多くのスライスオプションがあり、アニメーションの各フレームの衝突境界を設定し、フレームスライス、フレームシーケンス、またはデータベース全体を選択するオプションもありました。 インターフェイス自体は次のようになりました。











上の画像では、ゲームの小売バージョンから除外された囚人（囚人）をインポートしました。 現在のフレームがタイルのグループに分割された明確な境界が表示されます。 黄色の長方形は衝突フレームの境界を表し、各数値はタイルのグループが使用される回数を決定します。



Chopperは独自のデータベース形式で動作しますが、GenesisとSNESに焦点を当てた理想的なプラットフォームのさまざまなターゲット形式にタイルデータをエクスポートできます。 Aladdin / Genesisの場合、Chopperは複数の.SEGファイルを書き込みます（Doomの内部プログラマーまたはマップ作成者が考えたように、「セグメント」ではなく、セガという言葉から）、1から各サイズの生タイルデータの全量を表します×1×4×4。 チョッパーは、コードとしてアセンブルし、各フレームの追加プロパティ（パーツ番号、衝突、タイルサイズ、オフセット、インデックスなどの各パーツのプロパティ）を設定する必要がある複数の.68Kファイルも生成します。 これらのファイルは、データの埋め込みの望ましい順序も決定し、ROM内のデータの最終的な場所を反映し、データタイル自体の場所に必要なすべての制限を設定します。



記事に記載されているNoesis fmt_virginmd_chopper.pyスクリプトは、予想されるGenesis形式のフレームデータを見つけ、それを一連の.SEGファイルと、ネイティブのSega Chopperデータと同じ形式の.SEGファイルを参照する.68Kテキストファイルに変換しようとします。 テキストファイルを試して、実際のハードウェアと同じように、プロパティの変更がタイルの使用にどのように影響するかを観察できます。



チョッパーのもう1つの興味深い側面は、1ピクセルの長方形を検索してアニメーションシーケンスの境界を設定するように構成されていることです。 NoesisのDeluxePaint Animationのインポーターでこれを繰り返すパラメーターオプションもエンコードしました。 したがって、多くのアニメーションソースは次のようになります。











多くのソースには、目的の長方形の外側にアクティブな画像データが含まれています。これはおそらく、メモの記録と比較に通常使用されていました。 Chopperがデフォルトの処理でシーケンスをインポートすると、結果は次のようになります。











Aladdinゲームのチョッパーインポートプロセスで使用するために、追加のフレームごとのテーブル/リストを生成する最も簡単な方法でネイティブ出力.68Kチョッパーを処理する別のツールが作成されました。 これらには、各フレームへのポインターの線形リストが含まれます。 おそらく、これは各フレームの可変サイズ（パーツの数が異なるため）を処理するのではなく、ポインター間の遷移によってフレームカウンターを増加させたいために行われます。

2.3。 チューム

Aladdinは、tUME汎用タイルマップエディターを使用します。 tUMEを使用したその時代の他のゲームと同様に、アラジンには独自のtUMEパッカーがあります。 パッカーは、プラットフォームと特定のゲームに最適な形式のセットにデータをエクスポートする別個のツールです。











アラジンの場合、tUMEラッパーは「tPJungle」と呼ばれます。 ジャングルブックでの使用を目的としていたため、おそらく名前が付けられています。 tPJungleは、ブロック/キャラクターデータ、等高線データ（通常はレベルに共通）、フロア検索/フロアデータ、さまざまなタイプの部屋データ（レベルが従来の部屋か絵部屋かによって、魔神のボーナス画面やゲームで使用される他のカメオ画面など）、部屋の複数のレイヤーがキャラクター/タイルデータを参照できるようにするパレットおよび視差ファイル。



通常、tUMEパッカーからの出力は別のバッチプロセスで圧縮され、その後、圧縮（または場合によっては非圧縮）データへのリンクが手動で.68Kファイルに入力されます。



敵とオブジェクトは、タイル番号に従って配置されます。 これは、以下のタイルテーブルのビットマップが、タイルインデックスに基づいて対応するオブジェクトのスポーナー/ジェネレーターの実行を開始するコード内のテーブルに直接対応することを意味します。











テーブルには多くの未使用のセルと、現在削除されているオブジェクト（PrisonerやSword Swallowerなど）を参照するために使用されるセルがあり、実行をダミー関数にリダイレクトします。 残念ながら、リモートの敵はtUMEソースに追加されていないようです。つまり、設計ドキュメントの参照を除いて、これらの敵の位置と方法に関する情報はありません。

2.4。 宝石

アラジンはGEMSサウンドドライバーを使用し、FMドライバーとPSGパッチを使用して音楽を再生します。 また、PALバージョンには、個別に生成されたデータセットがあります。 アーカイブにはGEMS中間ソースはありません。GEMSを使用して生成されたコード/データには、ネットワークディレクトリからローカルにコピーされたバッチファイルが付属しています。 つまり、このアーカイブから取得できるものはすべて、バイナリファイルからGEMSシーケンサー/サンプル/パッチデータのバックアップコピーを掘り下げることで、ゲームの小売バージョンから取得することもできます。



ただし、このアーカイブには、実際のCakewalk MIDIソースコード（GEMSデータを送信するシーケンサーへの送信に使用）およびTommy Tallarico自身が提供するリニアPCMサンプルが含まれています！ 詳細については、3.5サウンドと音楽をご覧ください。

2.5。 プロパック

多くのAladdinデータタイプでは、性別のルックアップテーブルとキャラクターのデータタイル（アニメーション/カットではない）を含め、Rob NortenのProPackが積極的に使用されています。 セガレトロに関する記事（リンク先）で述べたように、アラジンは方法1のみを使用します。デコーダー（特にアセンブリ言語8086、M68K、6502）のリファレンスドキュメントが大量にあるため、デコーダーの実装も記述しました。ノエシス。



Aladdinアーカイブには、必要なすべてのレベルデータを変換および圧縮するために手動で変更されたと思われる多くのバッチファイルがあり、これらは直接ROMに含まれています。 レベルを作成するプロセスは、「tUMEへの変更、保存、tUMEの終了、バッチファイルの実行、収集、ゲームの起動」のようなものだったと思います。

3.0 隠された宝

このアーカイブの研究で最も驚くべきことは、ゲームの小売バージョンに含まれていない多数の資料を発見したことです。 私は非常に多くのものが無傷のままであったことに非常に驚きました、そして、コードベースにそれらに対応するコードの束がまだあることを発見したとき、私はさらに驚きました（それは小売ROMイメージにコンパイルされていませんが）。



チョッパーと他のツールをマスターしたので、リモートリソースの一部を再インポートし、古いオブジェクトジェネレーター、アニメーション、要素ロジック（最近はファンである場合は通常、アクターまたはエンティティと呼ばれます）などの要素のコードのさまざまな部分を追加することにしました地震）。 ROMサイズを4メガバイト（32メガバイト）に拡張し、「ペーストボード」で切り取られた「テープ」の一部を返すのに十分なスペースを確保し、返品対象を慎重に選択する必要がないようにしました。 コードの一部はすぐに動作する準備ができていましたが、他のケースでは、完全な機能を復元するために何かを微調整して調整する必要がありました。



これらのファイルで見つかったもう1つの驚くべきボーナスは、1993年4月27日付のゲームバージョン3.3のオリジナルデザインドキュメントのコピーです。 このドキュメントを参考にして、旅で見つけた不完全なコードと機能の真の目的を理解しました。



ここですべての資料を説明するわけではありませんが、これまでの最大の発見を共有します。 また、CESのデモビルドからすぐに再生できるスケルトンアニメーションと、追加のウォーキングアニメーションを見つけました。 作成者は、それをプレイヤーの方向に落とし、それから爆発させようとしたようです。 このアーカイブにはコードがありません。また、まったく新しいアニメーション/ステートロジックを記述することにまだ慣れていないので、将来のために残しました。

3.1。 ボーナスラウンド

古い魔神ボーナスラウンドのコードに出会ったのはほぼ初めてです。 スロットマシンのレバーである「アーム」要素を明示的に定義し、追加の移動コードとステータスコードも使用します。 スロットマシンのジニーコードを完全に返し、Chopperを使用してすべてのアニメーションの依存関係を再インポートしました。 また、グラフィックソースには、スロットマシンのテーマを考えると理にかなっている、精霊と一緒に回転するコインのアニメーションがあることに気づいたので、私もそれを返しました。 結果は次のとおりです。











背景がスロットマシンのレバーと完全に一致していないことに気付くかもしれません。 幸いなことに、私はそれが属するバックグラウンドのtUMEマップのソースを見つけることができました;それはTRASHディレクトリに埋もれていました。 tPJungleを使用して古いtUMEマップをエクスポートし、ゲームに挿入し直しました。











ただし、この背景には独自の問題があります。 フロントレイヤーが正しく構成されておらず、3つのリールを備えたスロットマシンのアイデアに対応するコードにロジックが残っていません。 言うのは難しいかもしれませんが、この背景がカットブロックにヒットする前にプロトタイピングの段階に達しなかったか、またはそれに関連付けられたコードが完全に削除された可能性があります。 また、TRASHのこのコピーは、スロットマシンでこのテーマボーナスラウンドを削除する前に使用された最終的な背景ではない可能性があります。



このボーナスゲームを返すには、論理的に見え、スロットマシンの元のテーマと組み合わされるように、かなり多くを自分で修正する必要があります。 ただし、新しい実装で元のアイデアをもっともらしい形で再現するために必要なデータはすべて残っています。 スロットマシンを使用したこのボーナスゲームのバージョンについては、ゲームのデザインドキュメントで詳しく説明されています。 また、ゲーム「石、はさみ、紙」についても説明していますが、そのソースコードやグラフィックスの痕跡はどこにも存在しないため、このアイデアは実装されていなかったようです。

3.2。 敵

商用リリースの前に、多くの敵がゲームから削除されました。 削除の理由はおそらく特定の状況に依存していました：デザイン/外観との不一致、開発時間の不足、ROMのスペースの制限。 小売ゲームが2メガバイト（16メガバイト）のROMにどれだけ収まるかを考えると、各ケースでの意思決定のバランスについてしか推測できません。 これらの敵の何人かは完全に働いていましたが、他の敵は救いへの愛とケアを要求しました。

飲み込む

ソード・スワローはデザインがナイフ・ジャグラーに非常に似ており、市場レベルで敵のラインの一部になることを意図していました。 彼は1か所に座り、口から無限の剣の流れを引き出し、画面全体に投げます。 彼の剣のコードを接続することも必要でしたが、彼は追加の修正なしで働いていました。 CESのデモアセンブリの実装とまったく同じように動作するようです。

囚人

囚人（囚人）は、スルタンのダンジョン（スルタンのダンジョン）と同じレベルに現れることになっていた。 完全に完成しており、いくつかのアニメーションシーケンスがあります。 スタンバイモードでは、彼は足からチェーンを切断し、接近すると、チェーンのコアをスイングし始めます。 彼はまた、痛み/反応のアニメーションを持っています。これは、関連付けられたコードの痕跡がなかったため、ゼロから実装する必要がありました。 囚人はCESのデモアセンブリにも表示されますが、間違ったパレットで表示され、ROMにはリアクションアニメーションがありません。

ゴールデンモンキー

ゴールデンモンキー（ゴールデンモンキー）はかなり単純な敵で、プレイヤーに無限の宝石の流れを投げかけます。 ビデオでは、彼女は間違った文脈で示されています（実際、彼女は奇跡の洞窟（Cave of Wonders）で会うことになっていた）。 彼女はもう他のアニメーションを持っていなかったし、彼女の仕事に追加のコードは必要ありませんでした。



設計文書では、ゴールデンモンキーの動作は、完成したゲームのシヴァの像の動作に似ていると説明されています。シヴァの像はさらに興味深い敵になるはずで、イアゴが彼女に飛びついて泡を投げたときに生き返ります。ある時点で、彼らは単に金猿を捨てて、代わりにシヴァの像を使うことにしたようです。

イアーゴフラミンゴ

スルタン宮殿レベルでは、イアーゴはフラミンゴを装って登場することになっていた。彼は高床式で画面を歩き回り、触れたときにプレイヤーにダメージを与えます。





IagoフラミンゴのアニメーションシーケンスもCESのROMデモアセンブリに含まれていましたが、この敵はゲームでは使用されませんでした。

ローリングヘビ

ヘビはゲームのリリースまで生きていましたが、最初は乗らなければなりませんでした。実際には、その内部名はROLLY_SNAKEです。私は、攻撃後に彼女がプレーヤーに十分近づいたら、彼女はスケートをするべきだと主張するコードを見つけました。このコードを接続し直しましたが、かなり奇妙な振る舞いがあり、ローリングの方向は非常にランダムでした。アニメーションが完了した後でも、ヘビは「スケート」モードのままになることがありました。私は修正に少し努力しなければなりませんでしたが、より論理的に見える状態にロールバックすることで、この攻撃に戻すことができました。





興味深いことに、このバージョンのデザインドキュメントでは、記述されている動作はコードに表示されている動作とはまったく異なります。



蛇がオブジェクトを投げて2回ヒットすると、蛇の輪に変わり、他の敵を通り抜けて右に転がり、それらを殺します。ヘビは非常に速く転がり、アラジンはそれに追いつくことができず、画面から転がり落ちます。



ソースコードには、この動作が一般的にゲームに組み込まれたという証拠はありません。推測できます。これは、ローリングの既存の実装がテストであったことの証拠であり、この機能は弱いように見えましたが、開発者はまだ作成済みのアニメーションを使用しようとしました。スネークアニメーション（スケートアニメーションを含む）は、CESのROMデモにも含まれていますが、このデモにはスネークが含まれていません。

3.3。 魔神の体の部分

Genieに関連するいくつかのオブジェクトがゲームのリリースから削除されましたが、それらのどれも完成されていないようです。これらのオブジェクトは、Inside the Lampレベルで使用され、マップ上のプレイヤーの動きに影響を与えます。

魔神の手

魔神の手は、6つのボールに接続された魔神の手のひらです。彼女は永続的なルートに沿って移動し、プレイヤーを一緒に運びます。











魔神の手は、デザインドキュメントで説明されているように、生き残ったプラットフォームの手（小売ゲームに到達しました）を補完するはずです。



これらはレベルの基本的な構成要素であり、アラジンが移動するプラットフォームの大部分を構成します。これらのプラットフォームの一部は、定期的に縮小し、再びサイズが大きくなっています。明らかに、ハンドが大きいほど、ジャンプしやすくなります。なぜなら、それは大きな目標を表しているからです。レベル設計では、ジャンプのためにこの正確なタイミングメカニズムを最大限に使用する必要があります。



他の手のプラットフォームは少し異なって見え、スプライトではなくタイルで構成されます。これにより、迷惑なちらつきのあるスプライトを回避できます。



実装の性質上、コードにはシングルトンとして記述されているため、一度に1つの魔神の手しか存在できません。新しい手がスコープに入ると、前の手は新しくなります。つまり、前の手は消えます。

魔神の手

Jinnの手はドキュメントには記載されていません。実装に残されているのは、拍手です。それらとの相互作用は不可能です。











それらが何らかの危険であったのか、それとも何らかの形で運動に影響を与えたのかを言うのは困難です。重要/関連するコードの一部が削除されている可能性があります（参照用に保存されていない）。別の（プレーヤー関連の）ロジックに関連付けられているためです。

魔神ボール

魔神ボールは、プレーヤーが近づくと発生し、タッチするとプレーヤーを所定の位置に保持します。











魔神ボールの目的は、設計文書に記載されています。



これは両刃の剣です。アラジンが転がり魔神の頂点に達した場合、彼はそれを移動エレベーターとして使用して、ランプのさまざまな領域を回ることができます。また、ボールは追加の高さを与えますが、これはボーナスまたはシークレットエリアにジャンプするために必要な場合がありますが、アラジンはジャンプする場所に到達するまでしばらくボールのバランスを取る必要があります。



魔神のボールコードはプレーヤーの動作コードにほとんど統合されているため、新しい再作成されたフォームで何かがひどく破損していても驚くことではありません。おそらく、オブジェクトには、CESのデモアセンブリでの動作から判断して、ここで指定されていない追加の設定も必要です。

3.4。 アウトライン

グラフィックソースにはいくつかのデジタル化されたスケッチがあります。たとえば、アラジンの秋のアニメーションの各フレームのスケッチは次のとおりです。











アラジンの落下の2番目のアニメーションの概要には、詳細があります。画像自体はループの特定のフレームを示し、保持します：











これにより、グラフィックスを作成するプロセスが実際に何であったかについて、少しヒントが得られます。特に注目に値するのは、Abuがゲームの準備ができていると感じたアニメーションで、まだドラフト状態です。











このアニメーションでは、アブはバッグを覗き込んでいます。このアニメーションは、ゲームのイベントや保存されたプロトタイプコードには反映されていないようです。ただし、それに関連するメカニズムは、ボス戦に影響しますが、設計文書に記載されています。



アラジンがボスに来て、スクロールが停止し、音楽がすべてのボスに使用されるボステーマに変更されます。音楽を変えた後、アブは画面に飛び込み、宝石を入れた魔法の袋を入れます。



, «»! ( , ), ( ).



— , , . , , , ( ), , , .



魔法の袋を返すとき、アブの反応/行動はアラジンがボスに費やした石の数に依存します。より多くの宝石が使われればされるほど、猿のジェスチャーは激怒します。アラジンが石を使用しない場合、アブは彼の特徴的なスタイルで彼の喜びを示します。ほとんどの場合、カートリッジのバージョンでは、CDバージョンでは3つのアブ反応（喜び、平穏、怒り）、5つの反応があります。



CESのデモアセンブリにも存在するこの魚のアニメーションは、グラフィックソースの完成版とともに保存されました。











彼女は、マスク付きのすぐにプレイできるグラフィックがあり、それはまだアウトライン形式であり、さらなる作業の準備ができており、その一部がゲームでデモアセンブリに使用されたと言います。この時点までにグラフィックスを作成するプロセスが信じられないほど合理化されていなかった場合、これは起こりそうにありませんでした。これは、非常に興味深いワークフローを示しています！

3.5。 音と音楽

GEMS関連のソース/プロジェクト中間データはありませんが、アーカイブでさらに興味深いものが見つかりました：生のCakewalk MIDIファイルとTommy Tallaricoから提供されたサンプルデータです。これらのデジタルサンプルはすべて、生の8ビットリニアPCMブロックの形で提供されました。これはまさに、トミーが添付の手紙でサンプリングレートと呼んでいる



ことです。PAL-NTSCで奇妙なことが起こった場合に備えて、すべての曲のテンポをチェックする価値があります。あなたは今、問題に気付いていると確信しています！次を除くすべてのサンプルの周波数は10.4 kHzです：jl87.vmd 8.7honk.vmd 5.2xplode2.vmd 5.8camel2.vmd 8.7finger.vmd 7.3feet2.vmd 7.3feet3.vmd 8.7cash2.vmd 7.3feet5.vmd 8.7



トミーはここで、NTSCとPALのタイミングの違いにも言及しています。これはGEMSドライバーに渡される最終シーケンサーデータにタイミングが書き込まれるため、GEMSを使用する場合に特に重要でした。アラジンでは、クリエイターがPALに個別のオーディオデータを追加するよう特別な注意を払っていました。



CakewalkシーケンサーデータをGEMSに転送するために使用されるツールと機器は不明ですが、リニアPCMの生ブロックは、GEMSがサンプルデータを処理する方法に対応しています。 （GEMSドライバー用のバイナリファイルを調べる代わりに）Cakewalkプロジェクトのファイルを見ると、ソーストラックのより明確な画像を取得できます。











MIDIのソースとリテールバージョンに挿入されたGEMSデータの比較をさらに見つけるために、さらに深く掘り下げることは興味深いかもしれませんが、今後はこれを残すと思います。

3.6。 設計文書

別のzipファイルの中に埋もれているzipファイルの中にあるのを見つけてショックを受けました。膨大な量の情報と予想以上の機能が計画されています。設計ドキュメントにはバージョン3.3があり、1993年4月27日付けです。多くの人々がそれに貢献しました。文書自体は、David Bishop、Seth Mendelssohn、Mike Dietz、Mark Yamadaによって書かれ、David Perryがチェックしました。



設計ドキュメントに入ったものとゲーム内にあることが判明したものとの間には多くの矛盾があります。この資料についてのみ記事全体を書くことができましたが、このセクションでは最も興味深い矛盾を示します。



一般に、このドキュメントでは、古いアイデアや機会、特にある程度のグラフィックスがあるものを再現できる多くの資料を提供しています。また、次のように、ゲーム/コードで参照されていないグラフィックスの小さな断片に関する詳細情報も提供します。











元の設計では、プレーヤーがバナナを収集して、Abuがレベルのランダムな場所に表示されることを暗示していました。このアニメーションは、カーペットの上を飛んでいる間にアブを拾うことができるように作成されました（これは髪のポーズと動きによって示唆されます）が、他の場所ではアブをつかむ兆候は保持されませんでした。また、このアニメーションはCESのROMデモに含まれていますが、ゲームプレイで使用されたことはありませんが、これは非常に興味深いことです。



ソースコードとデータをどのように処理する場合でも、この設計ドキュメントは非常に貴重な情報源です。

レベル

解体では、ゲームが元のレベルスキームに分類されます。

 レベル目標ボス
-------------------------------------------------- ----------
1.マーケットプレイスジャスミンラズルの保存
2.砂漠検索スカラベ1いいえ
3.マーケットプレイスの屋上でスカラベ2ガジムを見つける
4.刑務所からの脱出
5.不思議の洞窟（ゴールド）ランプモンキーシヴァと一緒に部屋まで歩く
6洞窟の不思議（ランプ）ランプを入手いいえ
7.洞窟から飛び出す洞窟からの脱出
8.ランプの中にGenie Noを見つける
9.「グッド」パレスグラブジャファーイアーゴ
10. Razul Palace 2へのマーケットプレイスブレイクスルー
11.「邪悪な」宮殿の破壊Jafar Jafar 

また、Sega CDのゲームのバージョンにはさまざまなレベルとボスの計画があります。これについては、Sega CDセクションで検討します。いくつかの注目すべき変更を除いて、レベル構造はほとんど変更されていません。

• GazimとRazulの両方が屋根のあるレベルに表示され、レベル1にはボスがいません。
• Cave of Wondersのウォークスルーが少し改善され、徒歩で進むと、カーペットが暴走するようです。
• 宮殿への道をめぐる市場での戦いはなくなり、スルタン宮殿からジャファール宮殿への移行が直ちに行われました。また、この段階で、Razulとの2回目の会議が計画されました。

市場エリアのリモートレベルの痕跡はないため、おそらく時間の制約またはROMサイズのために、おそらくその作業は開始されませんでした。

プレイヤーの仕組み

dzdockのこのバージョンと完成したゲームの間で、プレイヤーのメカニズムにかなりの変更が加えられました。最も興味深いもののいくつかを次に示します。

• アラジンは、ジャンプでのみ、おそらく上向きの弧でのみ、秋にオブジェクトを攻撃または投げることができなかったはずです。この場合、ゲームは間違いなくまったく異なる方法でプレイされます！
• 設計文書では、アラジンの剣による攻撃は近接攻撃や冷戦の攻撃をブロックするために使用されないが、リリースの動作は完全に反対であることが明らかにされており、これはガード攻撃によるダメージを避けるために非常に重要であることが多い。
• ジョイスティッククロスピースでさまざまな方向を保持しながら、アラジンは元々、オブジェクトを「左上」、「上」、「右上」の方向に投げるはずでした。
• クロスを上下に押しながら視線を上下に移動する際の遅延は、最初は3秒でした。
• 非CDバージョンでも、いくつかのレベルでは、リンゴに加えて、メロンと石がオブジェクトを投げていました。 文書には記載されていませんが、ゲームのある時点でレモンを投げることがありました。 私は石が砂漠のようなレベルにあるべきだったのではないかと疑っていますが、人や動物を石で殺すというアイデアは、おそらくディズニーでは受け入れられませんでした！
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
• いくつかのレベルでは、アラジンはジンを連れてくることになっていた。 このプロセス用に設計されていると思われるアニメーションをいくつか見つけたようです。
  
  
  
  
  
  
  
  
  
  
• カートリッジゲームバージョンでも、追加の待機アニメーションが計画されました。
  
  
  
  王女についての考えの雲がアラジンの上に現れます（市場広場の少女がジャスミンであることがわかった後にだけ）、これは彼が再び彼女に会いたいことを強調します。
  
  
  
  アラジンの上に、彼が市場広場に保存した少女についての考えとともに、思考の雲が現れます（保存してからだけですが、彼女が王女であることを知る前に、これは、アップルディーラーのためにゲームでRazulがどのように再出現するかによって変わります）
  
  
  
  じゅうたんがフレームに飛び込み、ジェスチャによってプレイヤーはプログラムに慣れるようになります（洞窟のレベルの後でのみ）。
• アラジンの健康状態が特定のレベルを下回ると、屋外レベルでいくつかのスカベンジャーが現れることが計画されていました。 それらは視差層に存在し、彼の死を見越して渦巻いています。

一般的に、完成したゲームには最高のゲームが残っているようですが、純粋に審美的な追加だけでなく、方向性のあるスローや追加のスローオブジェクトも楽しいでしょう！

敵

元のスケジュール（上記参照）で見つけたものから判断すると、dzdokに記載されているものと完成したゲームに残っているものとの間には非常に大きな違いがあります。 敵のメインリストをリストし、レベルごとに配布することに加えて、ドキュメントは各レベル内の一意の敵を識別します。



多くの場合、設計は敵の行動の完全に異なる特性とシナリオを定義します。

• 腹の低い警備員は棒を振って攻撃することになっており、背の高い細い警備員はナイフを投げなければなりませんでした。 製品版では、攻撃を交換しました。
• 大規模な警備員は、リリースに残った笑に加えて、上下の攻撃を使用する必要がありました。 アラジンはそれらの下に潜入するか、これらの攻撃を飛び越えることができるはずでした。
• 太った女性は市場広場に現れるはずでした：
  
  
  
  彼らは左/右に走り、マウスに追いかけられ、彼が邪魔にならない（ジャンプしない）ならばアラジンを打つ。 女性を殺すことはできません。
• Razulとの戦闘の状況とペースは、当初は完全に異なっていました。
  
  
  
  ラズルは刑務所の建物の屋根の上にいるはずです。 建物の幅は画面の約半分を占め、ラズルは壁の後ろから見えます（彼の体の上部のみが見えます）。 屋根の両側には、樽でできたピラミッドがあります。
  
  
  
  ラズルは屋根の上で前後に歩きます。 建物はスクリーンの中央にあるため、アラジンはスクリーンの端にある建物の両側にある一連のプラットフォームを使用して、その側面に沿って登ることができます。 プラットフォームにより、アラジンはラズルに近づき、ラズルの側に、または彼の真上にある最高のプラットフォームからジャンプすることができます。 アラジンは屋根を登ることができません。
  
  
  
  ラズルが屋根の端に近づくと、彼は端から樽を押します。 樽はプラットフォームからプラットフォームへと転がり落ち、地面に到達するまで（ドンキーコングのように）、その後中央の穴に落ちます。 Razulは1秒間に1回程度バレルを押す必要があります。 ラズルは、アラジンが屋根の反対側に到達するまで樽を回転させ続け、その後、屋根の反対側に戻り、再び樽を押し始めます。
  
  
  
  Razulは、片方からもう片方に走ったときにのみヒットできます。 アラジンが最高のプラットフォームにいるとき、ラズルは彼にナイフを投げます。 バレルの衝突の間にナイフを投げるので、アラジンは長く1か所に留まりません。
  
  
  
  バレルはアラジンにダメージを与え、特別な色のバレルを除いて破壊することはできません。 ボーナスアイテム（健康、ライフなど）を開いている間に、剣を一撃することで破壊できます。 Razulを倒すには、アラジンが左右に走り、建物の両側のプラットフォームを上る必要があります。 床の真ん中には、アラジンがジャンプしなければならない穴があります。そうでなければ、彼は命を失います。 床の真上に天蓋があり、アラジンがラズルに直接オブジェクトを投げることを防ぎます。
• 黄色の縞模様の緑の蛇のバージョンが計画されました。
• Iago兄弟の定期的な攻撃が計画されました（羽の色がIagoと異なります）。
  
  
  
  イアーゴの兄弟はそれぞれ、足に赤い泡を1つずつ運ぶことができます。 赤い泡が爆発し、オブジェクトに触れます。 鳥が画面に飛び、アラジンの上にいるようにしてから、泡を投げます。 その後、再び画面から飛び出します（バブルを投げたときに移動した方向を保ちます）。
  
  
  
  アラジンに落ちると、泡が彼にダメージを与えます。 アラジンはまた、泡が彼の近くに落ちると煙を吐き出しますが、彼もダメージを受けます。 煙のパフは0.5秒後に消えます。
• 砂漠のレベルでは、rage気楼の敵が計画されていたが、それは現存する敵の形をとって現れたり消えたりするはずだった。 ミラージュは、アラジンによってダメージを与えられ、殺される可能性があります。
• 元のスケジュールで見つかった敵の「囚人」は、もともと黒と白の縞模様のターバンが付いたローブを着ることになっていた。 彼はアラジンと同じ身長であり、私たちが見た非常に背が高く、気味の悪いキャラクターではなく、チェーンスイングで追加の攻撃を受けることになっていた。
• 当初、コウモリは特別な飛び込み攻撃を受けることが計画されていました。
• イアーゴの兄弟の一人が飛び込んで、スルタンのダンジョンダンジョンの最初の骸骨に泡を投げることが計画されていました。 これは、このレベルでスケルトンが生き返るという事実を説明するでしょう。
• 黄金の猿はもともと別の洞窟の金のレベルで計画されていました。そこでは洞窟が金貨、宝石、その他の宝物で満たされるべきです。 最も可能性が高いのは、彼らがこのレベルを完全に削減することを決めたため、黄金の猿が取り除かれ、その行動がシヴァの像に移されたことです。
• Cave of Wondersの2番目のレベルでは、金猿のように振る舞うはずの石猿が計画されましたが、コイン/金/宝石ではなく石を投げます。
• 金色/石猿のデザインで不思議の洞窟レベルに現れるシヴァの像は、もともと宮殿に現れ、次のようなデザインを持っているはずでした：
  
  
  
  アクション：
  
  
  
  Iagoが到着し、その上に泡を落とすまで、ほとんどの彫像のように動かないままです。 それから彼女は魔法のように命を吹き込み、アラジンを攻撃し始めます。
  
  
  
  攻撃：
  
  
  
  彼女の多くの手で、彼女は頭飾りから貴重な石を引き出し、アラジンにそれらを投げなければなりません。 宝石が地面に落ちると、魔法のように炎に変わり、2〜3秒間燃えます。 アラジンが彼女にぶつかるたびに、彼女は片手を失います。
  
  
  
  外観：
  
  
  
  アラジンからほぼ成長しますが、8つの武器があります。 ハーレムパンツと帽子と多くの宝石を身に着けています。 大理石の彫像の色と質感は、生き生きとしたものでなくてはなりません。
• スルタンの宮殿のフラミンゴは、最初はやや攻撃的なメカニズムがありました。
  
  
  
  プレーヤーがフラミンゴの上に立っている時間が長すぎる場合、鳥は向きを変えてそれをつつきます。 フラミンゴの1つは変装したIagoであり、プレイヤーが着陸しようとすると常に迷ってしまいます。
• Iagoのボスとの戦いでは、当初はAagoの宝石を使用してIagoを攻撃することに重点が置かれていました。 これがIagoをギアに近づける唯一の方法でした。
• ジャファーは、人間の形で、危険な煙の長くて分散しない雲を作り出す赤い泡を投げなければならないことがありました。
  
  
  
  
  
  
  
  
  
  
• 蛇を装ったジャファーは舌で攻撃しなければならず、攻撃が成功した場合、彼は微笑まなければならなかった。 彼には他にもかなりの攻撃/行動のバリエーションがありました。

これは何にも影響しません。また、ゲームの設計と実装の間にはまだ多くの小さな違いがあります。

石、はさみ、紙

対応するコードもデータも保存されていませんが、ゲーム「岩、はさみ、紙」の完全な説明があります。 ここで完全に引用する価値があります。



ボーナス画面に移動すると、プレイヤーは画面の左中央部に左ブラシで手を振っているカーペットを見ます。 アラジンは画面の右中央に立ち、右手を振る。 石はボタンAに、紙はボタンBに、はさみはボタンCに対応します。ツールチップは画面の中央下に表示されます。



ルールは通常のゲームのルールに似ています。各プレイヤーは石、紙、はさみを選択します。 石は拳で、紙は手のひらで、ハサミは人差し指と中指で文字Vの形に伸びています。 ユーザーはアラジンでプレーします。



カーペットがブラシと手を振ってアラジンを振っている間（これはプレーヤーが選択するまで続きます）、プレーヤーはA、BまたはCの3つのボタンのいずれかを選択する必要があります。目的のアイテムを選択した後、カーペットとアラジンはブラシと手をさらに2回振って、そして、第三波で、彼らの選択を示します。 勝者は勝利を祝い、画面に表示されます。



アラジンが負けた場合、ゲームは終了し、レベルを離れた同じ場所に戻ります。 その後、彼は数秒間不死身になります（誰が勝ったかに関係なく、このプロセスは3回目のゲームの後にも発生します）。 アラジンが勝った場合、彼の賞品はグラフィカルに（通常のゲームと同じように）および/またはテキスト形式（余分なポイントの場合）に表示されます。



プレーヤーは、すでに獲得したアイテムを保持したまま、さらに勝つために、またはゲームを離れるために、再びプレーするかどうかを尋ねられます。 プレイヤーが再びプレイすると、以前に獲得したアイテムをすべて失ったり、失ったりすることがあります（たとえば、最初のゲームでアラジンが1つのライフを獲得し、2番目で-10の宝石と2つのライフを獲得し、3番目のゲームで彼が失った場合、彼は勝ったすべてを失います）以前：10個の宝石と2つの命）。



ボーナスゲームに1回アクセスすると、3回までプレイできます。 アラジンは、1回目と3回目で勝った場合にのみ、2回目のゲームをプレイできます。



同点の場合、誰かが勝つまでゲームが繰り返されます。



ルール



石はハサミを破る

紙は石を征服する

はさみは紙を打ちます



両方のプレイヤーが同じアイテムを持っている場合。 その後、引き分けがカウントされ、ゲームが繰り返されます。



賞品



最初の勝利：人生

2番目の勝利：10個の宝石と2つの命

3番目の勝利：1つの精霊のスマート爆弾、15の宝石、3つの命



注：選択したゲームの難易度に応じて賞品を変更できます（難易度が低い方が勝ちです）。 これは、ゲームのセットアップ時に決定されます。



注：賞品は累積的です;アラジンが3つのゲームすべてに勝った場合、彼は6つの命、25の宝石、1つのスマートジーニーボムを獲得します



このアイデアは開発の初期段階で生まれたようです。ご覧のとおり、説明の一部の要素は他の設計メカニズムやオブジェクトに対応していません。

ROM故障

ディズドカでは、実際にはこれが完全に達成されなかったという事実にもかかわらず、すべてのキャラクター、レベル、および機能のメモリ要件を打破する試みが事前に行われました。 これにより、注意深いデザイナーやアーティストが対象の情報媒体の技術的限界にどのようにならなければならないかを評価する絶好の機会が得られます。



2048 KB-使用可能なカートリッジメモリの合計

推定メモリ使用量

480 KB -8レベル、レベルごとに60 KB（これには、タイル、トリガー、パス、その他すべてのセットが含まれます）

132 KB-タイルセットなしの3レベル、レベルごとに44 KB

175 KB-音楽と効果音

64 KB-プログラム

64 KB-スプライトテーブル

64 KB-チェックリスト

120 KB-スクリーンセーバーの開始/サイドショー/スクリーンセーバーの終了/最終ムービー（各間奏のイメージ= 4 KB）

30 KB-セガ、ディズニー、アラジン、バージンのロゴ

491 KB-アラジンと、レベルに関連付けられていないすべてのキャラクター

369 KB-レベル接続スプライト

241 KB-ボス

80 KB-すべてのボーナスゲーム

___________

2274 KBが必要

2048 KB -___________

226 KB追加。 うーん

レベルごとの60 KBの内訳：

11500バイト-バックグラウンド文字データ（圧縮）

32768バイト-リンクとバックグラウンドブロックの組み合わせ

1200バイト-性別とスプライトの切り替え情報（圧縮）

400バイト-ループ情報

10,699バイト-カードデータ（圧縮）

2171バイト-視差データをマップ（圧縮）

___________

レベルごとに約58,738バイト。 [グラフィックスタイルがシンプルな場合、またはレベルのサイズが最大サイズよりも小さい場合、この評価は低下します]



このような慎重な調整と計画は、実際には多くの理由で優れた実践であり、現代のゲーム開発におけるグラフィックス、デザイン、プログラミングの間にしばしば見られる不均衡からはほど遠いものです。 ゲームに巨大な4096×4096テクスチャを配置したアーティストや、3分間レベルを最初にロードしてからすべてが修復されることを望むデザイナーには決して誓わなかったと思います。 「空のテクスチャは、20年前にゲーム全体が占有していたスペースよりも多くのスペースを占有する」という言葉で従業員を恥じていました。

3.7。 セガのCD

Sega CDのゲームのバージョンは最初から計画されていたようです。 残念ながら、設計文書でセガのCDが頻繁に言及されているにもかかわらず、Aladdinを使用した場合、元のグラフィックはアーカイブに対応していなかったようです。 dizdokから抜け出したCDに関連するすべての機能と要素を以下に示します。

• 多くの追加レベルのセガCDアラジンがアリ王子を装って登場することが計画されていました。 Disdockは、アリ王子はカートリッジの1つのバージョンにのみ表示されると述べていますが、ROMスペースを節約するために意図的に切断されました。
• ゲームのCDバージョンでは、Jafarが精霊の形式で3番目の形式を持つことが計画されていました。 アーカイブ内のこの段階のグラフィックの痕跡は保存されませんでした。
• アブのマジックバッグが小売版を生き延びた場合、CDバージョンでは、アラジンが使用したジュエリーの量に対するアブの反応がさらに2つ計画されていました。
• CDバージョンでは、Razulのマーケットスクエアのボスをボスの「リンゴ商人」（Apple Merchant）に置き換えることが計画されていました。 ラズル自身は、刑務所を持つレベルのボスになることでした。
• 砂漠レベルのCDバージョンでは、ボス「砂サソリ」が表示されるはずでした。 デザインには、このボスに関する追加情報はありません。
• Jafarの宮殿につながるマーケット広場の2番目のレベル（リリースには至りませんでした）では、Razulとの2回目のミーティングの代わりに、ゲームのCDバージョンでFire Eaterのボスが計画されました。
• CDバージョンでは、追加のスローアイテム-スノーボールが計画されました。
• 特にCDバージョンでは、追加の待機アニメーションが計画されました。
  
  
  
  
  • 魔神は画面に飛び、フレーズの1つを言います（CDバージョンの洞窟のあるレベルの後のみ）
  • カーペットはスクリーン上を飛び、アラジンは肩をなでて、再び飛びます（CDバージョンでは洞窟のあるレベルの後にのみ）
• CDバージョンでは、爪の上に横たわる男の形で障害物が現れることがあります。これにより、アラジンはダメージを受けずに一度彼から離れることができました。 最初のジャンプの後、「inり」の男は立ち上がり、ジャンプに使用できなくなりました。
• 砂漠レベルでは、流砂はCDバージョンで計画されていました。
  
  
  
  アラジンが砂の特定のセクションを通過すると、沈み始めます。 ジャンプして、彼は徐々に砂から出て、drれることなくこれらのエリアを通過することができます。 プレイヤーがあまりにも長い間彼を離れた場合、アラジンは砂にdrれ、彼のライフを失います（または、それが彼の最後のライフであった場合、ゲームは終了します）。 注意深いプレーヤーがこの危険を予見できるように、流砂は外側が通常の砂とわずかに異なるはずです。
  
  
  
  一流の流砂が秘密のエリアにつながります。 アラジンはそこにたどり着くために、trapから脱出したいという彼の自然な欲求を克服し、その場に留まらなければなりません。 アラジンが流砂のこのエリアの表面に落ちたとき、アラベインは砂漠の新しいエリア、おそらく洞窟のようなものを発見したと言って飛び出します（これらのタイルがある場合）、アラジンは追加の人生を見つけることができます、ゲームの継続その他のさまざまなボーナス。
  
  
  
  アラジンが砂漠の地に戻ったときの視覚的およびゲームプレイの仕組みを決定する必要がありますが、整合性のために、スカラベを使用した別のフレームトランジションを使用します。
• CDバージョンでは、サボテンを使用する可能性も計画されました。
  
  
  
  それらはさまざまな形状とサイズになります（2つのタイプの可能性があります）。 アラジンの世界のスタイルに準拠していない場合、ゲームから削除します。 サボテンに触れると、アラジンにダメージが与えられます（タッチごとに1ポイントのダメージ）。
  
  
  
  サボテンの一種は、アイテムを投げたり、剣を打ったりすることで破壊できます。 別の、より完全に見えるサボテン種は消えません、それは避けることができるだけです。
  
  
  
  両方のタイプのサボテンはグラフィカルに配置されるため、多くのグラフィックスを使用せずにメモリを使用せずに、外観の異なる複数のサボテンを作成できます。
• マーケット広場と同じレベルで登ることができる静的ロープに加えて、スイング式の物干しロープがゲームのCDバージョン用に計画されました。
• カーペットは炎に近づいた後、燃えるブラシで特別なアニメーションを作成する必要がありました。

多くの場合、CDバージョンの計画は、カートリッジゲームバージョンの計画された（ただし、リリースまでは機能しなかった）要素/機能と絡み合っています。

3.8。 コード

ソースコード自体について多くを伝えることができます。ゲームコード自体の最も興味深い側面の1つは、本質的に信じられないほど単純なステートマシンであるメカニズムによって制御されることです。このコードスニペットは、アセンブラがアニメーションシーケンスなどの側面を定義する方法を示しています。

;  AN_ROLLY_SNAKE: dc.w SN_SLTHR_FRAME1 mface_man R_S: dc.w SN_SLTHR_FRAME1 dc.w SN_SLTHR_FRAME1 dc.w SN_SLTHR_FRAME1 mif_within_X 85,AN_ROLLY_SNAKE_BITE dc.w SN_SLTHR_FRAME2 dc.w SN_SLTHR_FRAME2 dc.w SN_SLTHR_FRAME2 dc.w SN_SLTHR_FRAME3 dc.w SN_SLTHR_FRAME3 dc.w SN_SLTHR_FRAME3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、「コマンド」ごとにバイト/ワードが生成されます。 アニメーションの各フレームは単語を生成することで設定され、この単語はROMの先頭付近のフレームポインターのリストへのポインターです。 次に、上記のmif_within_X条件ロジックなど、対応するコマンドバイトを生成するためのマクロがたくさんあります。 コマンドバイトは、既知のフレームポインタ値の範囲外にあるのが便利です。 このコマンドの結果として、ステータスデータポインターは、次の実行サイクルのために他の値を持つ場合があります。



要素（オブジェクト/アクター）は、ほとんどの場合、このような状態データのコード処理によって制御されます。 モーションも同様に処理されます。 モーションのロジックは生成されたバイトによって決定され、各要素はモーションステータスデータへのポインターを渡すことができます。 また、アニメーション状態データがモーション状態データへのポインタを置き換える場合が非常に多いため、この操作に対応するバイトを生成するために使用される特別なマクロがあります。



これらの小さな状態ブロックの実行と、物理/衝突、さらには基本的な動きの階層などの計算の制御専用のかなり大量のコードがあります。 もちろん、プレーヤーは独自の方法で処理されます。 標準要素と同様に、状態データを使用しますが、より複雑な状態ロジックのほとんどを処理する独自のアセンブラーボイラープレートロジックを備えており、多くの場合、直接状態ポインターを設定します。



この処理方法は、新しいオブジェクトを追加する作業を簡素化し、各オブジェクトに必要な新しいコードの量を最小限に抑え、ロジックを非常に効果的な状態コマンドにパックすることにより、メモリコストを削減できます。 状態のロジック自体は非常に単純であり、ロジックのかなり複雑なすべてのケースに特別なマクロがあるという事実と組み合わせて、スケールアラジンのゲームにとってこれは優れたシステムです。



さらに、VRAMでの直接メモリアクセスを使用したデータ転送など、システムレベルの側面を処理するための定型コードが多数あります。 DMA_ITプロシージャは、VRAMでのブラスト処理によるチョッパータイルの書き込みの基礎でした。 チョッパーは、コストを最小限に抑えるのに非常に効果的であるように設計されました。 彼はCPUのアンパックコストを回避しながら、アニメーションフレームごとの一意のタイルの数を最小限に抑えました。 私はアラジンのプロファイリングに取り組んでおらず、ここで通常何サイクル使用されるかを研究しませんでしたが、最終的な結果から判断すると、システムは十分に機能します。



ここでは数え切れないほどのシステムの研究に深く潜ることができますが、あまり詳しく説明しなければ、Aladdinコードベースで最も注目すべき高レベルの操作をリストしました。



上記のすべてに加えて、勉強中に気づいた他の興味深い断片があります：

• デモの記録に使用できるMAKEDEMOアセンブリ時間変数があります。 ゲームを記録するとき、各フレームはコントローラーからVRAMにコマンドを書き込みます。 興味深いことに、デモを記録すると、背景タイルにアーティファクトが徐々に表示されることがわかります。 割り当てられたVRAMバッファーをいっぱいにした後、ゲームはデータをVRAMからメインRAMにコピーし、無限にループします（メインメモリのみを破壊するため）。デバッガーを接続し、既知のアドレスからデモデータをダウンロードできます。 楽しみのために、この方法で独自のデモを作成しました。
• デモに関するその他の興味深い事実：デモデータ自体は、コントローラーからのフレームごとの入力の生ストリームです。 デモの記録と再生の両方で、同じ初期乱数の疑似乱数ジェネレーター「12345678」を使用して、確定的な結果を提供します。
• MASTERアセンブリ時間変数もあります。 リテールコピーでは、オフになっています。 ONに設定すると、リリースまで生き残ったチート画面の部分が無効になりますが、有効にすると、変更のないコードはアセンブルされません。 チート画面（電話番号とFAX番号がまだ含まれている）は、製品版には残っていないはずです。
• チートコードとその他の多くの静的データは、TABLES.68Kファイルにリストされています。 一度に1バイトずつ読み取られます。 チートコードのロジックは、チートコードの対応するテーブルへのポインターを増やし、間違ったボタンをクリックするとリセットします。 リリース内の追加の（既知/文書化されたものを除く）隠された/無効化されたチートコードは、ソースに保存されませんでした。
• この記事のビデオ録画中に、アラジンが損傷したときに発生する高周波フリッカーをオフにしたかったのです。 これは、ビデオをより低いフレームレートにトランスコードするときに、いくつかのフレームで完全に消失しないようにするために必要でした。 コードの必要な部分を見つけた後、アセンブラーチェック「IF TO_DEMO = OFF」を見つけました。 明らかに、コマーシャルの録音中にこの問題に遭遇したのは私が初めてではありませんでした！ TO_DEMOがCESのデモアセンブリから削除されたか、このアセンブリにフリッカーが存在することに基づいて、この特定のパーツが後で追加されたようです（脆弱性が無効になっている場合）。

私はあなたについて何を知りませんが、個人的にこれらすべてのことは、ゲーム開発の黄金時代について私を熟考させました。

4.0。 次は？

各ゲームには独自のストーリーがあり、場合によってはバイナリコードのほうが言葉よりも雄弁です。 しかし、ソースコードは通常、さらに大きな声で話します！ キャンセルされたプロトタイプ、破棄されたデモ、およびハードウェア障害により、ビデオゲームの歴史の中ですでに多くの驚くべき瞬間を失いました。 特にDRMハードウェアテクノロジの場合、ビデオゲーム業界での保存とアーカイブに注意を払わないと、さらに多くの損失が発生する可能性があります。



このプロジェクトは、適切な保存のためにアラジンアーカイブを準備することを目標として開始し、VGHFでのソースコードの保存とアーカイブの標準化に向けた最初のステップを踏み出しました。 これには、目的と他のツールやデータへのすべての外部依存関係を決定するためにトップレベルからソースコードを文書化することが含まれていたため、これらの依存関係も標準化できました。 その過程で、アラジンが興味深い物語を語れることがすぐに明らかになりました。 これが他の多くの人の最初の話に過ぎないことを願っています。ゲームに隠されている他のものを見つけるのが待ち遠しいです！



じゃあね！