Darkside（リンクエラー修正しました）

　改めて２周目の第１→第２→直角コーナーのスクリプト探索を始めて、誤解に気付いた。
　１周に要するフレーム数は、大抵の場合整数ではない。半端なタイミングでゴールラインを通過するものだ。だから同一地点であっても、内部座標でどこまで到達するかというのは、周回ごとに異なる。

　直角コーナーのバグを取ったら内部座標で３も改善されたというのは、２周目と３周目を混同した誤りだった。
　実際には、１しか改善されていない。
　とはいえ、比較すれば差は明白だ。部分的に改善されたのだから、この後も作りなおして確かめるしかない。

直角コーナー改善前	改善後

　ところが、とんでもなく謎な現象が発生。改善して早くなったはずが、以前と同じキー入力では一点読みの隙間飛び込みができないのである。余裕が出来てしまうのなら分かるが、どうやってもキツい。
　改善解は大量に存在する。直角コーナーまでは別解だらけであり、ガードビームを削るのと削らないのと、いずれも正解である。どっちでも良い。しかし、内部座標の１未満の部分でいろいろあるようだ。例えば、(10,10)
より(10,11) が勝るとは限らない。デジタル世界で大抵の場合、端数は切り捨てになる。実は (10.9 , 10.9) と (10.0 , 11.0) であって前者が勝っている可能性もある。

　半端な角度の走行が加わることにより、座標計算のアヤが生じている気がする。
　とにかく最適化も内部座標で１を争う段階になると、速い遅いが不明確になって来る。その一方で、どっちが速いかを確認するスクリプトは１件走らせるだけで１日掛かる。精密にやろうとすると、２日以上掛かる。早くできる「可能性」の大きさに比べて、手間暇が激増する。ガチガチに最適化して誰も改善できあいようなものを作ろうとしていたが、現実には不可能だと思えて来た。どこで妥協するかの見極めが必要だ。

　別解を試し、一点読みの出口までタイ記録というのを得た。
　しかし、内部座標や内部速度は同一だが、ムービーファイルを接木すると１秒以内にズレる。やはり１未満の世界が絡んでいる。一応ヘアピン突入探索スクリプトを走らせてみる。

　１周目のダート抜けパターンの発掘に威力を発揮したスクリプトが、なぜ解を発見できないのか？
　理由は、目的の向きに自機を向けられないからである。

　神パターンを実現するためには、自機の向きをかなり限定された値に調整せねばならない。
　ハンドルを何フレーム切っても、その値にならない。曲がり方が小さ過ぎて、しかしもう１フレーム余計に切ったら今度は曲がり過ぎる。
　前回までは、たまたま適切なフレーム数が存在した。初期座標が僅かに変わっただけで、そのようなフレーム数が存在しなくなってしまったのだ。

　となれば逆ハンドル調整だが、神パターン発見スクリプトは経路探索が２パスになっている。
　そのため、逆ハンドルのコードを追加する改造が恐ろしく面倒なのだ。
　修正に取り掛かったが、変更箇所は膨大だし案の定不具合出まくりで、まっとうに自機が走らない。２周目以降用のスクリプトは自機の向きがややアバウトで構わないので、解無しにはならない。つまり、この苦労も１周目専用。

　やっと働くようになったスクリプトで全探索した結果、内部座標で１劣る結果しか得られなかった。
　ダブル一点読みまでの微妙なアドバンテージには意味が無く、作り直す前の方が早いのだった。

　ついでに１周目の直角コーナーもスクリプトで確認。
　第１コーナーを曲がった直後まではソニックスタートとの関係で自由度がないので与件として扱う。しかもアクセルオフ無しだから、場合の数は少ない。検索はすぐに終了し、こちらもベターな解はゼロ。
　なんだかんだ大騒ぎしたが、こうして１周目は既に最適化済みとの結論に至る。

　見た目は最速ではない部分があって気分的に割り切れないものがあるが、全体としては最速だ。

　１周目の直角コーナーは、アクセルを離してはならないという縛りがある。
　そのため、２周目以降に比べるとキー入力のバリエーションに乏しく、手動で最適化可能である。だが、その後の経験により、直角コーナーを早く抜けるコツというか有望なパラメーターが分かって来た。それを元に、１周目を再検討する余地はある。

　製作途中で改善点や疑問点が次々に浮上し、過去分の作り直しを強いられ、いつまで経っても完成が見えない。そういうのは確かにある時期まではモチベーション低下要因である。だが、既にそういう限界点は乗り越えた。今や、徹底的に最速を追及しようという気分になっている。
　作り直しは無駄なようでいて、どんどん経験値は溜まるので改善可能性の未開拓部分が狭まって行くのが実感できる。こういう徒労が終わるのは、時間の問題である。
　また、動画投稿の経験も長いので、半端な結果を上げるデメリットも分かっている。
　改善動画は、伸びない。

　純粋な出来からすれば、半端に上げた動画よりその更新版の方が上である。
　だがそれでも、更新版の方が多く再生されるという例は、皆無に近い。圧倒的多数の動画が、自作他作に関わらず最初の動画を越えられない。半端な出来でアップしたが最後、会心の動画が最高に伸びるという機会は奪われるのだ。
　改善の余地があると分かっていながらＴＡＳ動画を公開するのは、その瞬間に敗北が約束されてしまう。

　そこで１周目に戻ってチェックしたところ、走行ラインは既にスイートスポットに含まれていた。すなわち、最速の確率が高い「おいしい」領域である。
　積みあがった経験を元に再度の最適化を試みたが、速くならない。

　これで話が済めば簡単だが、１周目はダブル一点読みにも疑問が残っている。飛び込む直前に、走行ラインをガードビームと平行に戻しているのである。平行に戻さない方がハンドル切り角が小さくなるため、有利である。ただし差は微小であり、実際には差が生じない可能性が高い。それでも見た目の印象が違うので、平行に戻さないパターンを作ってみる。
　１周目を前に作った時は、平行に戻さないままガードビームを適切量だけ削って飛び込むという操作を手動で実現できなかった。しかし今は製作慣れしたので、それができる。

　やってみると、やはり結果は変わらないようだ。
　ところが、右ガードビーム際から左ガードビーム際へ移動するハンドル操作が最適化できてしまい、内部変数で１だけという微妙に速くなってしまった。
　ダブル一点読みは４５度走行なので、内部座標はＸとＹが同時に変化する。ここで、Ｘ座標は同じでＹ座標だけが１改善されたのだ。それでも改善に違いなさそうだが、ガードビームとの間合いに微妙な問題があり、改善扱い可能かどうか不明確なことも分かっている。
　とはいえ、改善された確率は無視できないので、改めてここから神パターン発掘スクリプトを走らせてみる。

　すると、スクリプトが解を発見できない。最適解が無いのではなく、遅いとか速いとか無関係に解の個数がゼロなのだ。

　S-JET 噴射開始の最適パターンを見つけ出し、続いて３周目第１→第２→直角コーナーの探索に入る。
　しかしここで、１周目には存在しなかった邪魔カーが障害になる。そのままでは探索中に衝突してしまうので、インかアウトに回避してから探索開始せねばならない。
　アウトから抜くほうが動きは少ないが、走行距離は明らかに伸びる。インから抜くパターンを手動で最適化し、衝突が回避できる座標で真北を向かせてステートセーブ。スクリプト探索開始。

　暫く走らせたところで、自機が爆発。
　これは良くある話で、スクリプトがエラーで停止すると自機が暴走する。最後はどこかのガードビームに突っ込むので、どんどんエネルギーが無くなってすぐに爆発という次第。
　今更になって、スクリプトのバグが発覚した。それも、大バグだ。

　原因は、第２コーナーを曲がった後の進路判定を手抜きしていた点にある。
　直角コーナーの突入時に、ガードビームとの間合いをある範囲内に収めたい。確実なのは、実際にそこまで走って内部座標を読む方式である。しかしその場合、第２コーナーの曲がり量を変化させるたびに直角コーナー手前まで走る訳で、時間を食う。そこで、第２コーナーを曲がった後の向きだけで判定していた。向きだけで判定するためには、根元の座標が安定していなければならない。根元とは、第２コーナーを曲がり終えた段階である。
　第２コーナーで膨らむとタイムが遅くなるし根元の位置もズレるから、そういうのは探索木の枝刈りで捨てていた。

　問題は、逆に第２コーナーをコンパクトに曲がれた場合だった。
　今度は、想定外にガードビームに接近してしまう結果となる。コンパクトに曲がれるというのはタイムが速い可能性が高いのだが、そんな良候補の走行ラインがガードビームに近くなり過ぎて、まっとうに直角コーナーを曲がれなくなっていた。このたび余りにも接近し過ぎてガードビームに突っ込んだおかげで、バグが発覚した。
　直角コーナー手前まで走り、ガードビームとの正確な距離を調べるように修正したところ、内部座標で３もの改善が可能だと判明。

　２周目の作り直しが確定した。

　探索時間は伸びるが、探索結果を検討したところ、第１コーナーを曲がった直後のガードビームとの間合いを車体半分という最適値近辺に絞っても大丈夫だと見通しが付いた。そっちで枝刈りすることにより、探索時間の伸びを抑えられる。
　だが、より恐ろしい可能性が頭に浮かんだ。１周目の直角コーナーは最適なのだろうか？

　ガチＴＡＳを作る上で、ヘアピン → S-JET と続く流れは厄介である。
　ヘアピン脱出の最適解は複数存在し、それぞれ微妙に速度が違う。S-JET は整数組み合わせ問題であるため、単純に初期値が大きい方が有利とは限らない。複数の最適解それぞれに
S-JET 最適化を加えた場合、結果が異なることが充分に予想される。
　すなわち、幾つかの最適解それぞれに対し、S-JET 最適化を実行して結果を確認せねばならない。

　S-JET 最適化は噴射期間をどれだけ余らせるかによって結果が異なるので、これも余らせ量を変えて何度も実行せねばならない。こうなると煩雑過ぎて、やってられない。どうしても、噴射期間の余らせ量はスクリプトで自動的に変化させ、１回走らせるだけで済むようにせねばならない。
　そんなことは最上位ループ回すだけでいいだろ？と思うだろうが、コトはそう簡単ではない。
　噴射期間の余らせ量が異なる場合、結果を直接比較できない。余った分は時速４７８キロで走るとみなし、フレームあたり内部座標９の補正を施せば比較可能である。しかしそれは、走行ラインが真北を向いた状態で行わねばならない。また、既に
S-JET が噴射されているから、時速４７８キロに戻った瞬間に座標を取得して計算せねばならない。

　まあ後者は簡単だが、前者の真北というのは相当に面倒臭い。
　４５度や直角コーナーを抜けるのに比べ、ヘアピンでは各解のバラツキが大きい。どんな状態で抜けて来ても真北に補正するスクリプトは、案外面倒だ。
S-JET の第１ループ探索が終わった後でターンフレーム数を変化させて調べるのは簡単だが、問題は第１ループ探索の途中で旋回が完了する場合。
　第１ループ探索の途中で、ターン終了タイミングまで変化させて真北安定するかどうかまで調べていたら、スクリプトの実行時間が伸び過ぎる。仕方なく簡易判定で済ませ、最初から曲がり過ぎている場合は逆ハンドル補正を掛けることにする。これは手抜きであり、本来より僅かに遅いと判定されることがある。しかし、それを頭に入れて最終的な判断を行えば大丈夫と思われる。