DQ6 AI処理の解析2

多少間があいてしまいましたが、徐々に通常モードに復帰します。今回はまだリハビリ中ということで軽めに。

このSRがAI行動決定の一番トップのSRです。この中で全てAIに関する行動が決まります。条件に応じてAI行動決定コアSRを飛ばすようになっているだけで、特筆する点はありません。

ここもまだ大きなSRの段階なのでこのSR自体も「まあそんなもん」という感じでしかありません。次回からよく使われるRAMの意味を説明してから更に掘り進んでいきます。

例のAI実装についてはほぼ終わったので、まずは学習機能をOFFにしておかしな行動を取らないかの確認をするべく0からテストプレイをしています(ちんたらやっているのでまだダーマ近辺)。やはりというべきか、ポツポツと期待した通りの動作をしていないのを見つけてデバッグをしながら進めているので進行度合いはかなり遅いです。自動SS採取機能付きのSnes9Xでプレイしているので、再現に手間がかからないのがいいです。現状気になる点として「行動決定までに一瞬間があるキャラクターがいる」という点です。行動可能な戦闘行動についてすべてシミュレーションをする必要がある以上、レベルが上がるほど(行動の選択肢が増えれば増えるほど)トータルの計算量が増え、人間が違和感を感じるレベルまでの遅延が発生する可能性はどうしても防げないのですが、選択肢の少ない序盤にもかかわらず違和感を感じるキャラクターが出てきてしまったのでこれからデバッグをするところです。明らかにバグっていて処理が遅いというのであればバグを直せばいいだけなのですが、問題は「正しい処理をしているが、プログラムの書き方が悪くて遅い」場合の対処法です。理想を言えば「とある箇所でブレークポイントを張り、その次に止まったところまでのサイクル数のカウント及びどのSRでサイクル数を食っているかを表示するプロファイラーのような機能」があれば少なくとも遅い箇所を特定することはできます。実際その箇所の処理を早くできるかどうかは別として、時間のかかっている場所を特定できなければ適切な対処もできないということで、一番近いところにいそうなGeiger’s Snes9x Debuggerにその機能がないかざっくり見てみたのですが、なさそうです。ソースも公開されていなそうなので機能追加するというわけにもいかなそうなので、プレーンなSnes9Xに機能を付けるとしたら結構面倒くさそうです。