DQ6 Extended(拡張ベースパッチ)作成にあたっての考慮点

DQ6の改造は今のところ断片的なアイディアはあるものの、それほど思い入れもないせいかシステム面の変更以外はあまりやりたいことも思いつかないわけですが、現状DQ3のような拡張パッチもないためにちょっとしたメッセージの変更すらままならないという状況なので、作業をするにはまず土台からということで何をやらないといけないかを思いつくまま列挙していきます。DQ3 Extended同様、オリジナルのゲーム性には一切手を付けないことを前提とします。ちなみにSFC版DQ5はちょこっと解析をやっていますが、改造したいという気がまるで起きないせいか(文句があるならDS版やればいいとしか思わないし、それくらいDS版の出来はいいと思います。特産品というアレは置いといて)、びっくりするくらい解析も進みません。やはりモチベーションは重要なようです。

• アイテム

レコード数:256→376?(+128Rec)
メモリ中のIDが1バイトで管理されているところがあるので、拡張しようとすると結構大掛かりになる。キャラクターの持ち物リスト、ふくろリストのメモリ領域にも拡張が必要になり、「オリジナルのゲーム性には手を付けない」という前提を守る場合、セーブデータにオリジナルとの互換性がなくなる。それ以外のテンポラリの部分についてはおそらくモンスターID同様2バイトの変数に入れていると思われるのでそれほど問題にはならないだろうが要調査。どっちにしろかなりの手間はかかると思われる。また、耐性アイテム、鍛冶屋リスト、ショップ、モンスタードロップアイテムなど1バイト設定している部分が多いのでこれらも拡張が必要。モンスタードロップは隣接ビットがパレットアクセス(10bit)なので、下位1bitをアイテムに回して9bitでモンスター専用パレットアクセス領域に飛ばせばレコードサイズの変更は不要になる。

アイテム数が増える場合、袋のアイテム数のメモリ上の領域、袋の中身のウィンドウ表示時のバッファ領域が十分に確保できるかを調査する必要がある。袋の中身については、移動中のみなので戦闘中のメモリ領域(7E2030-)が使えるが、袋のアイテム数のことを考えると+256Recはトータル512Byteをまとめて確保する必要があり、作業が大変になると思われるので+128Recくらいで収めておくか。バイナリwikiを見る限り、空き領域を探すのが大変になりそう。

もう1つの案としては一切手を付けず、パッチ作成者各自の裁量で「いらなそうなものを削る」という方向がある。そもそもDQ6のアイテム数がなぜこれほどパンパンなのかというと、おしゃれな鍛冶屋導入により、アイテム名が同じでステータス(ほとんどはかっこよさ)が違うだけのアイテムがそこそこあるからである。具体的には以下の36アイテム。このうち、一部を削ればその分余裕はできる。

この他にも、イベントアイテムの中にはアイテムというよりは機能拡張的な存在のもの(不思議な地図、マーメイドハープ、天馬の手綱など)は「入手した」というフラグだけにしてしまい、トリガーは特殊ボタンのみとしてしまえば数は稼げるが、プログラムを変更しないといけない上、節約できるのは数個なので効果は薄い。ちいさなメダルも同様。

「既存の項目を削って入れ替える」というのはそれなりの理由があって削る以外は思考の方向性がみみっちくなるので極力やりたくない。となると互換性を捨てても拡張するべきか。

• モンスター

レコード数:256→512(+256) +10,752Byte
メモリ中のIDが基本的に2バイト管理なのでアイテムに比べて作業難度は低いものの、戦闘中のキャラクターIDの管理がPC側は+#$100しているため、この部分を全部+#$200に変更する必要がある。全ての部分を洗い出す必要があるため、戦闘部分について完全に把握する必要あり(+要テスト)。また、キャラクターIDの隣接ビットは$204Fの9bit目は味方フラグ、10bit目はAIが死んでいると判断、$2051の9bit目は味方フラグ、10bit目は混乱扱いなので、10bit目を別の場所に移動し、9bit目をみて味方と判断している箇所の変更、10bit目を参照している箇所を全て変更する必要あり。それ以外は場所移動+アドレス用レコード追加+参照しているSRの変更をする。また、エンカウント、サブモンスターは1バイト管理なので全部変更が必要。AI用各モンスター脅威値も+256する必要あり。エンカウントはbit数が足りないので1レコードのサイズをやむを得ず拡張する。

• 移動中メッセージ

レコード数:6957→10240?(+3283)
ハフマン圧縮されているのでDQ3 Extended同様解凍した状態でROMに書き戻し(1回だけしかやらないけどここ面倒くさそう……割と簡単に終わった)+メッセージデコードプログラムの書き換えが必要。DQ3 Extendedの該当箇所が分かったので比較的簡単に実装できた。デコード後のオリジナルの文字列サイズは688,971Byteと、DQ3の328,713Byteと比べると倍以上の容量を使っている。実際の文字列の使用可能容量をどれくらい確保しておくか。

• 戦闘中メッセージ

レコード数:603→1280(+677)
実際の文字列の使用可能容量をどれくらい確保しておくか。

• 固定文字列

レコード数:2506→4096(+1590)
実際の文字列の使用可能容量をどれくらい確保しておくか。

• 戦闘行動

レコード数:レコード数:410→512(+102) or 768(+358)
場所移動+アドレス用レコード追加+参照しているSRを変更すればいいだけ。モンスターの戦闘行動のビット数が9ビット、戦闘中キャラクター情報の戦闘行動が9bitで上7bitがターゲット情報で埋まっているため、512レコード以上にする場合、変更範囲がかなり広くなる。戦闘中キャラクター情報を拡張するのは、すぐ後ろも別の用途でぎっしり埋まっているため、戦闘関係のプログラムの大幅な書き換えが発生するためあまり現実的ではなさそうだ。必要なのはあと3ビットなのでAIの脅威値の下位1bitを1つずつ使わせてもらえばなんとかなるか?どちらにしろプログラムでいろいろこねくる必要がある。512レコードの場合、+102レコードになるが、これでよしとするかどうか微妙なところ。DQ3 Extendedでは、274→384レコードで+110レコードなので、ギリギリ許容範囲か?ちなみにDQ3 K.Mixではver1.6.2で残り5レコードなので+102で十分な感じがするが。足りなければあそび(全57レコード)を削ってもらうか。とりあえず768レコード分の領域だけ確保しておく。

• パレットアクセス

レコード数:714→1024+512(モンスター分を別立て)(+822) +13,152Byte
+310レコードでは心もとないので86氏がやったようにモンスターのパレットアクセスは予め別立てにしておくと単純計算でさらに256レコードを別の用途に使えるのでだいぶ余裕が出る。戦闘中以外でモンスターグラフィックが使われる場所に注意。調査したところ、以下の場所で使用されていたため、シフトした。

• パレット

レコード数:2435→4096(+1661) +53,152Byte
これだけあれば十分か。あと全体的にだっさいあの色使い何とかならんのかね。1年後に出てるDQ3は文句ないのに。

• ルイーダ待機可能人数

レコード数:24→36(+12)
拡張してもデフォルトでは24のままにしておく。セーブデータの拡張が必要。このへんのノウハウはDQ3 K.Mixである程度積んだのでオリジナルのセーブデータとの互換性を捨てればそれほど苦労しなさそう。これを実装するならオリジナルとの互換性はどちらにしろ捨てることになるのでアイテムを+256してもいいかもしれない。

まだグラフィック読み込みインデックスやらスプライトグラフィックインデックスやらいろいろと拡張する必要がある物は多いのですが、面倒になってきたので一旦ここで終わりにします。気が付き次第追記していく予定。あと、何バイト増えるかの試算を全くやっていないわけですが、2MB増やせば何とか収まるんちゃうん?という感じでちゃんと計算したらそれも書こうと思います。現状1ミリも手を動かしていないので実際に作業を始めればもうちょっとはやる気が出てくるでしょう。それにしてもDQ3 Extendedは偉大だったとつくづく思わされます。