<< 前のページ
2017年4月30日(日) 21:14
スリップを終えて二股磁石に向かう極めてライン取りの自由度が少ない場所で、地雷マシンに絡まれる。
スクリプトを実行させても、手動操作で試行錯誤しても、回避不可能。ほんとうに、どうにもならない最悪のタイミングで絡んで来やがる。
しかし、地雷マシンは急速にアウト側へ逃げて行くので、僅かにタイミングが異なればインから突破できそうだ。
そこで、手前の左スリップゾーン旋回の最速解ではなく、次善解を使ってみる。これだと1フレーム近く遅いのだが、逆に言えばそれだけタイミングを外すことができる。
スクリプトをそのまま走らせると、綺麗に回避可能だった。
written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]
2017年4月29日(土) 21:47
反射ドリフトの最速解。
反射時の大減速が連続3フレームに留まるケースが高確率で大量発生するという、4周目と共通の状況だ。
後半連続ヘアピンのエントリーで、スクリプトが邪魔カーを回避できなくなる。
本来のコース形状に加えて邪魔カーが立ち塞がった場合、スクリプトが自動的に回避可能なパターン中から解を探す場合と、探してくれない場合がある。これは、かなり偶然に左右される。
どんな場合でも邪魔カーの存在を想定していると、スクリプトが複雑になる。ソフトでありがちなことだが、 重要だから対策を立てるのではなく対策が簡単だから対策を立てるというパターンだ。 これは仕事ではなく趣味のスクリプトだから、時間効率が気になるのは仕方がない。
ここは邪魔カーとガードビームの間に十分な隙間があるため、対処はまだ簡単。
written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]
2017年4月28日(金) 21:51
現状はWIPなので、先を急ぐ。究極の最適化は求めず、スクリプトが完全に終了していなくても「かなり速い解」が得られた感触があれば投機実行を進める。
4周目の暫定ラップは36秒25。TAS製作でありがちなことだが、慣れるに従ってラップが速くなる。つまり、最初の方のラップには無駄が多い。だからこそエキスパートクラスを走らざるを得ないゲーム仕様は、渡りに船と思うしかない。
2周目は反射ドリフトで邪魔カーに酷く妨害されたから遅いのは仕方ないが、それを除いてもここまでをムービー再生して見ると、最初の方ほど明らかに最適ではないことが分かる。
どうやらトータル3分5秒台になりそうだ。
反射ドリフトの連続ヘアピンにエントリーする際は、アウト一杯に寄せない方が速いと判明。
これぐらいガードビームと隙間を残して突入するのが最速っぽい。ガードビームへの当たり所を良くするには、この走行ラインなのだ。
written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]
2017年4月27日(木) 21:22
モンテカルロ法により、解が出て来ないと思われた最速候補初期値から相当に速い解が得られた。
だが、続く左スリップゾーンでまた行き詰った。既存スクリプトが、うまく働かない。
手前の右コーナーの脱出ラインがこれまでより僅かにキツくなった影響で、スムーズに左旋回へ接続できない。
想定したパラメーターよりアウト寄りから突入せねばならない。状況次第で適切なパラメーター範囲が変わるのは仕方ないものの、スクリプトに任せられない部分が増えるのは辛い。
今はまだ良いが、ファイアーフィールドをクリアして本番マスタークラスに突入した場合、再びファイアーフィールドを手掛けるのは何ヶ月も先になる。当然記憶は薄れている訳で、手動調整が増えるのは結構負担がでかい。うっかり手順ミスして最適ではないムービーを作ってしまうリスクも上がる。
遂に、二股磁石で邪魔カーが絡む。
これ普通に自動運転させたら突破できなかったのだが、棒磁石に接触減速させてでも強引にインから抜こうとしたら、減速無しに抜けてしまった。
つまり、自動運転中の減速を許可したら、結果的に減速せず突破可能なパターンが発見されたのだ。ここの自動運転では24フレーム先まで試走させているが、24フレーム以内に減速するとしても実際に減速するとは限らない。なぜなら試走結果を集計した後には1フレームだけしか実走しないからである。
得られた自動運転は、邪魔カーの手前でいったん通常よりアウト寄りに走行し、そこから一気にインを突く華麗なフェイントモーションになっている。そういうテクをプログラムした訳じゃないのに、人間が手動でCPUをあしらったかのような走りに結果としてなったのが面白い。
written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]
2017年4月26日(水) 21:43
この右旋回では、最初に左旋回を少し行ってガードビームから車体を離し、続いて直進を少し行う。それからフルハンドルを右に切る。
つまり、フル旋回の前に「左旋回フレーム数」「直進フレーム数」という2つのパラメーターが存在する。
これら2つのパラメーターをどう設定するのがベストかというのは結構厄介な問題であり、簡易判定しているものの決定版がない。パラメーターを適切に設定しないと速い解は出て来ないが、速い解を探す計算コストが極めて大きい。S-JET の適切なブレーキタイミングは自明ではなく、しかし片っ端から試したのでは実行時間が実用にならない。
2つのパラメーターを絞り込んでから、集中的に調べたい。
ここでふと思い付いた。だったら、有望パラメーター探しに、モンテカルロ法はどうだろう?
フル右旋回では、まず S-JET のブレーキタイミングを計算する。これは、意味がありそうなタイミングの範囲を計算するものだ。そして、その範囲内でブレーキタイミングを変化させて操作結果を調べる。この計算と試行は、S-JET の速度ループが1周するごとに行う。
右旋回で8周期とか9周期が当たり前なので、ブレーキタイミングのバリエーション数が8乗とか9乗された操作パターン数になる。とても全数調査できないので、ガードビームに弾かれずに右旋回を最後まで無事に行えるかどうかを重視している。最後まで走れれば類似の走行パターンは調査せず切り捨てる。
どうやらこの手法で、速い解が切り捨てられているフシがある。
かと言って全部調べるのは無理。ならば、ブレーキタイミング候補の中からランダムに1候補だけ選んで試行。これで最後まで右旋回させ、結果をチェックする。ランダムに何度か繰り返せば、速そうな解が存在しそうかどうか見当が付くのでは?
やってみると、思った以上にうまく機能した。
モンテカルロ法では、有望そうな選択肢に絞って乱数を使うのが効果的である。このスクリプトでは、もともとブレーキタイミングとして有望な範囲を計算しているから、その中からランダムに選んでも悪くはない。
また、並列実行が容易というメリットも大きい。
普通のスクリプトを並列実行する場合、試行パラメーターが重複しないよう管理する手間が掛かる。また、途中でスクリプトを止めると重複回避は困難になる。
しかしランダムなプレイアウトを行うモンテカルロ法であれば、スクリプトをいっさい書き換えずに並列実行できる。許容できる実行時間内で、ただ走らせれば良い。非常に使い勝手が良い。そして期待通り、従来のスクリプトでは発見できない解を見つけ出してくれた。
さっそく、デスウインド2の S-JET 右旋回スクリプトも、モンテカルロ版を用意した。
written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]
<< 前のページ
Generated by MySketch GE 1.4.1
Remodelling origin is MySketch 2.7.4