Darkside(リンクエラー修正しました)

2016年07月の記事

<< 前のページ

2016年7月31日(日) 20:20

改良を要する

 ここまで1周余りのミュート1ムービーファイルを使用し、1周目直角コーナー直後からスクリプトを適用してみた。
 その結果として発見された最速の一点読み飛び込みパターンを、実際のムービーファイルと比較。
 映像では座標が同一に見える。ただし、向きはかなり違う。一点読みという細い道に入っているにも関わらず、向きが違う。それは興味深いが、問題はスクリプトが現実より遅い解しか出力しなかった点にある。

 左がスクリプトの出力、右が現実のムービーだ。現実のムービーでは、一点読みの飛び込みは手動の試行錯誤で行った。要するに、スクリプトが手動に負けている。
 内部メモリーを見ると、座標は同一だが Xsub や Ysub とある 1/256 単位まで見ると差がある。この状態では、座標は小さいほど速い。

 もう2年前なので記憶から消えていたが、一点読み飛び込みの旧スクリプトでは飛び込む直前で結果がセーブされていた。つまり、自動では手動に勝てないから、手動任せにするため直前セーブになっていたのだろう。
 しかし、ここは完全自動化しないと困る。

 フレーム未満の罠に対処するには、最速解だけでなくある程度速い解はすべて試さねばならない。そうすると、1つの解を完成させるのに手動の試行錯誤などやってられない。少なくとも、そんな手間を掛けるのであればスクリプトを改良するのに手間を掛けるべきだ。

 PSリッジでは完全自動化を諦めて手動で調整しまくった。それは、サイレントドリフトの特性が複雑であり、考慮すべきパラメーターが余りに多かったからである。人知を使用せねば、まっとうな最適化など不可能だった。そりゃ AlpaGo じゃないけど何年も研究すれば自動スクリプトを開発できたかもしれない。しかし、対局囲碁だ人工知能だというならともかく、1つのゲームのTAS製作に、それはない。
 これに対し F-ZERO は、通常走行も S-JET も挙動は完全に判明している。それらはシンプルだ。だから、考慮するパラメーターは少ない。キー操作だってデジタルだ。だから、完全自動化も現実的と思われる。

written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2016年7月30日(土) 21:03

ステートセーブ

 F-ZERO に関しては、厄介なトラブルが発生している。それは、ステートロードに失敗する件だ。
 スクリプトが発見した解は、ステートセーブする。利用時はムービーを読み書き可能モードにしたうえで、Load Named State を使って読み込む。
 ところが、error と表示されて読み込めない場合があるのだ。

 PSリッジでは発生したことがないのに、F-ZERO では多発する。
 止むを得ず、ステートセーブと同時に、念のためムービーセーブも行うことにした。ムービーセーブの場合、ムービーファイル名が変わると管理が厄介なので、まる標準ファイル名にリネームする。そのうえで、最新フレームまでいちいち最初からムービー再生せねばならない。
 この、ムービー再生が必要というのがステートセーブとの最大の差であり、ステートセーブが読めないと作業効率が大幅に落ちてしまう。それでも、読めなければ手も足も出ないので、バックアップとしてのムービーセーブも必要だ。

 直角コーナーを回ったら、適切に一点読みするスクリプトへと引き継ぐ。

 これも1から作ると大変だが、ミュート3の時から開発していた旧スクリプトがある。それを、全周回汎用で使えるように修正する。
 スクリプトはまずジャンプ台を飛ばないよう回避し、ガードビームとの間合いを適正範囲に保ったうえで飛び込む。飛び込み方には4パターンほどあり、ジャンプ台絡みの斜め走行により微調整と併用して多数の試行を行う。そして、うまく飛び込めた一点読みを出力する。

 こうやって書くと単純作業のようだが、実用的な時間で解を出力するためには、ガードビームとの適切な間合いなどが分かっていなくてはならない。さもないと試行回数が増大する。スクリプトは実時間の3倍程度の速度でしか動かない。SFCのエミュレートだからさすがにPSリッジよりは何割か速く動作するが、それでも遅いことに変わりはない。試行可能な回数には限度がある。
 過去にさんざん試して、一点読みを成功させるために必要な条件がかなり煮詰まっている。だから実用的なスクリプトが書けるのであり、スクリプト開発には長い時間を要する。

 攻略上重要な定数は、長期の試行により煮詰める必要がある。そもそも、どのような定数が重要であるかを見出すところから始めねばならない。それらはコースごとコーナーごとに別であり、すべて1から別個に調査せねばならない。
 スクリプトにお任せできるようになるまでの手間は膨大であり、だからレースゲームのTASは量産できない。もしくは、最適化が中途半端に終わってしまうかだ。

written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2016年7月29日(金) 21:07

完全な別解

 一直線走行と折れ線走行と言っても、ステートセーブを作る段階での差は「どれだけハンドルを切るか」だけである。
 ミュート3の製作をしていた時は、まず一直線走行を解として出力した。その後で、ムービーファイルを手動編集してハンドル時間を短くし、ガードビームと平行走行になるよう調整した。
 つまり、最後の操作が違うだけで同一走行だったのだ。

 手動編集ではなくスクリプトが自動出力してくれれば、かなり楽になる。
 その際、実際に走行させるのは1回だけで判定を2回行うのが効率的である。判定はインタープリター言語の通常速度で行われるが、走行は実時間の3倍ていどという極端に遅い速度で行われるからだ。
 だが、いざスクリプトに手を加えようとすると、同一走行に判定2回は困難だと判明。というのも、時間が掛かる実走行を減らすため、ガードビームとの間合いなどを何度もチェックして早期に切り捨てているのだ。

 一直線走行と折れ線走行ではガードビームとの間合いが異なるため、切り捨て条件も異なる。
 どう考えても、走行2回でそれぞれ別々の判定を行う方が楽だ。確かに時間が掛かるが、完全に2倍ではない。走行を繰り返すのは、走行の最終部分だけである。それに、スクリプトの安定性が向上しているので、実行を開始したら基本的に放置可能。その間に別のことができる。ほんと、以前のバージョンに比べると感動的なほど、訳の分からないエラーで落ちることが無くなった。
 だから、スクリプトの完成度を高めて、できるだけスクリプトに任せられるようにするのは効果的だ。

 2回走行を行うと、意外な収穫があった。
 ガードビームに平行な走行を行う折れ線走行では、一直線走行と異なる解が存在するのだ。すなわち、一直線走行のハンドル時間を変えただけではなく、もっと手前からキー操作が異なる走行ということである。
 一直線走行では、ガードビームとの間合いが特定の範囲に入るものだけを選んでいる。そこで特定範囲にには入らないが、ハンドル時間を変えることでガードビームと平行走行になる・・・そんな解が存在する。

 フレーム未満の罠対策として、解にはバリエーションが必要。完全な別解が得られる価値は大きい。

written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2016年7月28日(木) 21:07

フレーム未満の罠

 例えば、あるコーナーを曲がるのに初期状態から11.5フレーム前進してからハンドルを切るのがベストだとしよう。

 実際には、キー操作は1フレーム単位でしか受け付けられないため、この例なら12フレーム前進してからハンドルを切るのが最速である。11フレームでハンドルを切れば、イン側の壁の衝突してしまう。
 だが、ちょっと蛇行するなどして12フレームで11.5フレーム分しか前進しなかったらどうなるか?
 この場合、理論上の最高のタイミングでコーナーリング可能だ。

 コーナーリングがベストになるメリットと、コーナーリング開始まで0.5フレーム遅いデメリット。いずれが上回るかはケースバイケースで何とも言えない。だが過去の例からして、途中まで遅い走行がその後の当たり判定の妙で逆に速くなるというのは、しばしば発生している。
 これを、フレーム未満の罠と呼んでいる。

 特に古いゲームの場合、コースが滑らかな曲面ではなく荒い多角形なので、当たり判定の運不運によるタイム変化が大きい。コース形状の角部分がフレームとフレームの中間になると、当たり安定が大甘になり易い。だから、フレーム未満の罠が多発する。
 これをキッチリと考慮するかどうかで、1ラップあたり1フレームや2フレームは簡単に変化してしまう。

 ミュート1のようにガチガチに煮詰まっているコースの場合、フレーム未満の罠を回避するのはマストであり、そのためTAS製作の手間が桁違いに増える。
 確実に回避しようとすれば、最速から0.5フレーム以内の遅い走行は捨てられない。逆転で速くなる可能性を残している。

 スクリプトで解を出力する場合、速い解を得るのは最優先だが、解のバリエーションもまた重要である。
 第2コーナーを回って直角コーナーに向かう際に、コーナーリングのエントリー位置に一直線に向かうパターンと、ガードビームと並行に走行して途中でエントリー位置にハンドルを切る折れ線走行の2通りがある。幾何学的には前者が速いに決まっているが、フレーム未満の罠対策としては僅かに遅い後者も魅力的である。
 そこで、スクリプトでは両方の解を出力するようにした。

written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2016年7月27日(水) 21:57

ペースダウン

 F-ZERO もミュート1に限定すれば、リッジTTよりもコースが単純。すなわち、スクリプトの種類は少なくて済む。
 とはいえ見た目だけではなくダブル一点読みとかダート抜けがあるため、スクリプト化が非常に厄介な部分があるのだが。
 また、周回が5ラップもある。1周目は完全に別物としても、2周目スクリプトをしっかり作り込めば3〜5周目でも流用できる。

 要するに、じっくりと完成度の高いスクリプトを開発する必要があるということだ。

 F-ZERO に関しては、ずっと前からTAS製作やってることだし理論限界も読めている。だから、PSリッジほど製作で熱狂することもない。
 マイペースで、ゆっくり製作を進めようと思う。
 スクリプトの改良には、ただでさえ時間が掛かる。だから、見た目の製作ペースは更に遅くなるだろう。

 以前書いた通り、ミュート1の理論限界は1分57秒10〜20の間である。たぶん1分57秒18あたりになるだろうと予想している。
 最初から終わりまでフレーム未満の罠が効きまくるため、理論限界が明白でもそれをムービーファイル化するのは極端に大変というのが F-ZERO である。スクリプトでは多数の候補を列挙し、それを次のスクリプトに引き継いで最速を探るという計算量と手間の増える手法を採らねばならない。

 後のシリーズよりも地味に見えることもあり、TAS製作がハイリスクローリターン状態である。古いゲームなのに需要は多いにも関わらず、TAS製作者が少ないのはこのあたりの事情だ。
 フレーム未満の罠を無視して単純にその場で最速のフレームを選択して行くだけだと、確実にトータル0.1秒以上遅くなる。ミュート1のように煮詰まったコースで0.1秒も遅れたのでは、TAS動画としてお話にならない。

written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

<< 前のページ

Darkside(リンクエラー修正しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4