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

　３連続コーナーの最終３つ目のコーナーを抜ける前で、作り直し前に比べて１．１フレーム速かった。抜けた後を実走させ、シケインを抜けた段階でアドバンテージ確定。２周目のラップは、１．３フレーム速かった。
　ラップ１６９１フレームで、２５秒３６。それも、思い切り余裕があって貯金を残してのゴールラインだ。

　２分９秒台へと、幸先の良い走行である。ＴＡＳは、作り直せば作り直すほど速くなる。やればやるほど速くなるのは、人力実機プレイと変わらない。どこまでやれるか。どこまでやるか。である。
　余剰を活かし、ショートカットファールでは２周目比で１６９１フレーム差をキープ。更にＦ２が小さくなったので、１フレーム未満のオマケも期待できる。

　オフィシャルに捕まる直前の右ハンドルが多ければ多いほど、再スタート後の右旋回がスムーズになりＦ２が小さくなる。しかし一方では右旋回が早くなることでＦに悪影響がある・・・というのは一般論として正しいが、究極を狙うとここでも非線形になる。右ハンドルを増やした方がＦが小さくなったり、右ハンドルを減らすことでＦ２が小さくなるという、理屈と逆の現象も発生するのだ。
　これは、１フレームの間に自機が移動する距離よりも小さな座標差による当たり判定が無視できなくなるせいだと考えられ、そのような小さな差が問題になるほど限界ギリギリまで最適化を行おうとすると悩まされる。

　そんなこまかなことを考えなければ、製作は桁違いに容易になるが、１周あたり何フレームも遅くなる。最近も、そんなＴＡＳを見たばかりだ。

　棒磁石地帯に入るところで、急に遅くなった。
　どう頑張っても、１．５フレームも速い解など出て来ない。そのまま３連続コーナーを製作するも、２つ目のコーナーをクリアした段階で１．１フレーム速いだけに落ちてしまった。

　遅くなった原因が不明なので、有望解を片っ端からスクリプトに放り込んで計算しまくった。そのため、製作が遅々として進まない。
　だが、３つ目のコーナーをクリアするところで、突然速くなった。１．８フレームぐらい速い。
　しかしここは、速遅判定の誤差が大きい場所である。実際にどれぐらい速くなったのかは、実走させねば分からない。そして現在まだ計算途中の中間結果で話をしている。度重なるスクリプト改良により計算時間は短縮されたが、一方では速遅判定の厳格化で時間を食っている。

　スクリプトの製作と改良が一通り完了して、今や人間は結果の管理やりつつスクリプトの動作環境を整えている状態である。だがそれだけに、完全に計算リソースが制約条件になっている。膨大な計算量と貧弱な計算リソースの前では、製作をこれ以上早くするのは不可能だ。
　ＴＡＳの品質を落とさない限りは。

　分割スクリプトの前半は素晴らしく機能し、強烈なイン攻めを実現させた。
　だが、それを初期値として後半を計算すると、解が出て来ない。

　これで、スクリプトのバグが発覚。
　前半は旋回性能が追い付くため、単なる折れ線走行である。しかし後半は旋回し切れないため、連続ブレーキを併用している。これは、クリッピングポイント付近で行うのが効率的だ。そこでガードビームとの接触を検出し、その前後でブレーキを掛けるスクリプトになっている。
　ここで接触判定が誤っていてブレーキのタイミングが過剰に早くなり、結果として旋回性能が不十分になっていた。これは、タイムを悪化させるばかりでなく、曲がり切れずに解無しとなったのだ。

　バグを修正し効率的に旋回できるようになったことと、分割により最適化が強化されたことで、何と１．５フレームも速くなった。もはや２分９秒台を出せるかどうかで悩む必要はない。
　確実に２分９秒台が出せる。

　１周目では、２つのコーナーを１つのスクリプトで処理した方が速かった。これは、１周目は最高速に達していないため後半のキツいコーナーでブレーキが使えないことが大きい。それだけ走行ライン調整の余地が小さい。また、折れ線走行するにはコーナー間が短過ぎる。
　だから、単独でコーナーを攻めると、操作バリエーションを確保できない。

　２周目のショートカットファールでは、０．３フレームが１フレームに化けた。作り直し前よりも、１フレーム早く引き戻されたのだ。ただしギリギリなので、右旋回の度合いを示すＦ２は大きくなってしまっている。このまま走ったとして、完全に１フレーム速くなるというほど話はうまくないと思われる。
　また、引き戻しが同じフレームの場合、Ｆ２が３フレーム小さくなった。

　取り合えずＦが１フレーム小さいのが何と言っても大きいので、そっちから試す。S-JET 噴射のスクリプトを通す。すると何と、作り直し前より遅くなった。
　Ｆが同一でＦ２が３フレーム小さい方は、S-JET 噴射後に作り直し前より速くなった。だがそれは０．１フレーム未満であり、０．３フレームのアドバンテージはフッ飛んでしまっている。
　このままでは、壮絶にクタビレモウケである。

　そもそも、Ｆが１フレーム早いという大アドバンテージがフッ飛んだのは何故か？
　ムービーを再生して確認すると、途中でガードビームのイン攻めが甘い。

　S-JET 噴射中には、コーナーが４つある。対して、使用スクリプトは３つ。
　２つ目のスクリプトが、コーナー２つを受け持っている。そのため計算量が多く、折れ線走行やってないのだ。だから、１フレーム未満の調整ができず、究極のイン攻めができていない。

　だからと言ってスクリプトを分割すると、これまた遅くなると１周目で判明している。しかし、１周目は S-JET を使っていない。ここまであからさまにイン攻めが甘いのでは、論外だ。
　スクリプト分割を考えるべきだ。まずは、この左コーナーだけを攻めるスクリプトを製作し、折れ線走行させてみよう。

　地味に厄介なのが、３連続コーナーを抜けた直後の左旋回である。

　高速突破で右に膨らむと、左への切り返しが大変になってスクリプトが解を出力しなくなる。あるいは、解は出力するがそれを次スクリプトの初期値として与えると、走行可能な解が皆無になる。
　そこで遂に、この部分も独立したスクリプト化することにした。

　スクリプトによる絨毯爆撃で最速走行ラインを調査し、既存のスクリプトへとリレーする。これにより、２周目が０．１フレームぐらい速くなった。これで３周目のショートカットファールを改善できるかもしれない、となった時点で別の事実に気付いた。
　それは、幾つかの解を処理したのだが、どれも似たような操作が最速なのだ。
　ここはガードビームとの間合いが狭過ぎるし直進可能フレーム数も小さいので、折れ線走行する物理的余裕がない。だから単純なスクリプトで速く解が得られるが、バリエーションが貧弱になり結局いつも似たような操作が速い。

　だとすれば、典型操作パターンを固定的に採用し、３つ目のコーナーを抜けた際の速遅判定に使えないか？
　今に至るまで、３連続コーナーの３つ目は速遅判定の誤差が大きく、ギリギリの最適化を行おうとした際に厄介な問題となっている。とにかく、どれが速いのか分からない。

　スクリプトで３つ目のコーナーを抜ける際の操作生成は、非常に僅かな走行ラインの差を生み出す。それにより、典型操作パターンにおける「折れ線走行できない」という弱点を補える。手前のコーナー抜けでバリエーションが確保されるからだ。
　たまたま左ガードビームとの当たり判定が幸運な座標になったとき、速いと判定されるだろう。

　典型操作パターンの生成は数秒以内なので、３つ目のコーナーを抜けるスクリプトにくっつけても実用的な時間で処理可能だ。
　これで１周目のコーナー抜けを処理したところ、１周目が０．３フレームも速くなった。
　１周目の３連続コーナーは偶然に、異様というか特異的に速く、何度も爆速という単語を使った。それが、更に０．３フレームも速くなったのだ。

　１周目のラップは２８秒５０のままだが、ギリギリで１９００フレームだったものが余裕ある１９００フレームとなっている。この余裕で、２周目のショートカットファールに好影響が期待できる。