Darkside（https対応しました）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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