袋の中身にアクセスするSRを自作します。基本的にはオリジナルで存在しているSR: $090717などとやっていることは同じなのですが、用途を限定化し袋の中身のアクセス専用にすることで不要な処理を飛ばし高速化するというのが主目的です。今回のケースでは扱う対象のデータが最長でも9bitであるため、3バイトに渡ってデータを操作する必要がないというのがかなり大きいです。

続きを読む

前回のエントリで領域の問題はクリアしたところまで説明しました。あとはPCのアイテム領域の操作、袋の中身の操作のプログラムを書くだけ、という話になりそうなのですが、以下の2点が問題となります。

1. 対象範囲がかなり広いため、十分なテストが必要
2. ビット単位でデータを詰めてセットしているので、アイテムの操作にまつわる処理量が10倍～に膨れ上がり、人が操作していて違和感を覚えるくらいに遅くなりかねない

1に関しては十分にテストをすればいいだけという話ではありますが、対象範囲を把握するのがかなり大変です。先日もテストプレイ中に間違った場所に情報をセットしてしまう箇所が残っていていつの間にかPCの最大MPが999になっていたりしました。一応そこそこテストをしてからテストプレイを開始したわけですが、ポロポロと問題が見つかるという始末です。PCのデータというかなりデリケートな箇所の操作なので、対処漏れがあると非常にまずいです。一通りテストしてOKだと思って別の方にテストプレイをしてもらったら対処漏れが見つかったりしたので(DQ3のアイテム操作のバリエーションは意外と多い)、rcまで出せたとしても正式版までは2ヶ月位置きたいと思っています。

続きを読む

氷の洞窟の実装を進めていて、マップのインポートはギミックも含めて終わったのですが、肝心のグランドラゴーンまわりのイベントの実装をすすめる気が起きず、よくよく考えてみると「使えるアイテム枠がない」ということが原因なのがわかりました。現在リリースしているver1.6.7ですでに255個(アイテムID:#$0はターミネーターとして使われているので使えません)全部使ってしまっているので枠がありません。このパッチを作る方針として極力「削る」ということはしたくなかったので(性格を変えるアイテムの整理は「必要である」と思って作業していたので例外)、削ることは最初に検討しましたが、もし増やしたいアイテムがさらに出てきた場合、ますます思考がみみっちくならざるをえないので非常に抵抗感がありました。ちなみに検討していた削除対象アイテムは以下の通り。

他にも真面目に検証したら削れるものはあるかもしれませんが、削るにしてもある程度の作業は避けられない上に、何より作業が後ろ向きなのが非常に不愉快です。同じ労力を使うなら増やす方に使いたい、というわけでアイテムIDの9ビット化について検討をし、可能であるという結論になったので作業した結果がこちら。

9ビット化というとあと255種類アイテムを新規定義できそうですが、いろいろ制限があったために+44種類のトータル299種類までしか拡張できていません。とはいえ、オリジナルから言うと+72種類なのでそこそこ頑張ったほうだと思いますｗｗ。DQ3 K.Mixにおいてはこれだけ枠があれば十分という判断です。

続きを読む