とりあえず 1 分切りは達成。50 秒切りが可能かどうかはまだ何ともいえない(タ イマー設定はたぶん不要なので、それだけで 1 秒近くは短縮できそうだが)。
52.83 (fcmファイル → fcmoptimで最適化したもの)
現段階では逆アセンブル解析はほとんど行っていません。
乱数値はフレームごとに 2000～3000 程度増加する他、方向キー入力によって微 妙に変化します。が、変化に規則性が見当たらないため、手動での乱数調整はかなり 面倒です。デバッガで追ってみたところ、フレーム処理を終えた時点からひたすら無 限ループで乱数値をインクリメントし、NMI 割り込みが発生したら抜けるようになっ ている模様。入力処理ルーチンを解析すれば乱数値の変化も予測できるのだろうか??
今のところは乱数値が予測できないので、Lua スクリプトによる Bot アタックで ゴリ押ししています。乱数調整に関してはこれでもかなりよい結果が得られるようで す。
ただし、一部のメッセージが表示されるまでにかかる時間にばらつきがあります。 このラグ?の最小化まで考えると、やはり逆アセンブル解析が必要になりそうです。
また、一部の場面では事前に Lua スクリプトで全乱数値に対する結果をリストアッ プして調査を行っています。ただしここにもちょっとした穴があり、厳密には乱数依 存の結果は「前フレームの乱数値」ではなく「前フレームの乱数値とそれまでの入力」 に依存する可能性があるため、やはり逆アセンブル解析しないと完璧とはいえなさそ うです(実際、乱数値が同じなのに事前に作成した表と微妙に異なる結果が出るケー スがあった)。
なお、一部の Lua スクリプトでは 2 段階のステートセーブを行っているため、 Bot の試行数がそのまま追記回数に反映されてしまっています。Bot を入力記録方式 にすればこの問題は解消されますが、まだ追記回数を気にするような段階でもないの でそのままにしています。
作成した資料などを置いておきます(自分用なので全然まとまってませんが):
Bot その他のスクリプトは上記以外にも多数作成しましたが、似たり寄ったりな ので省略。なお、Bot の入力生成ルーチンは全て事前に手動で調査した上で作成して います。泥臭いですが、前述の表示ラグの件などがあってなかなかルーチンの使いま わしができませんでした。
WERDNA への与ダメージ表を見ればわかる通り、近い乱数値ではほとんど同じよう な結果しか起こりません。よって、数フレームキー入力を行った程度ではまともな乱 数調整ができないので、なるべく早い段階から Bot によるランダム入力を開始する 必要があります。数フレーム待てば乱数値は大きく変化しますが、あくまでこれは最 後の手段。
メモ:
参考資料: