毎年恒例のロシアAIカップ2015での勝利の歴史

Mail.Ru Groupの年次AIプログラミングコンテスト「Russian AI Cup 2015」への参加と勝利についてお話ししたいと思います。 ご希望の方は、競技ウェブサイトrussianaicup.ruで競技の詳細なルールと試合の記録をご覧ください 。







今年のコンテストはまったく新しいレベルで開催されました。 AIが動作するゲームワールドの規模と、競争のWebサイトの両方で変化が起こっています。 3次元の視覚化のおかげで、ゲームははるかにエキサイティングに見えました。 エンターテインメントの面では、私の意見では、競争は昨年のホッケーと2013年の「兵士」を大きく上回りました。



参加者は、サバイバルレースで車を運転するためのAIを書くように求められました。 昨年と同様に、課題は「物理学」でした。 しかし、今回は、「物理エンジン」のソースは公開されていました。 また、昨年とは異なり、今回はゲーム世界のすべてのランダム現象は視覚的でした-ランダムカード、ランダムに配置されたボーナス。 運があなたの側にあり、それがあなたから背を向けたとき-それはすぐに明白でした。 昨年のホッケーでは、強さが大幅に異なる対戦相手の試合を観戦しても、チャンスがチャンスによるものかスキルによるものかを理解することは困難でした。 これは競技のエンターテイメントに良い影響を与えると思います。

ルールの簡単な説明

目標は、閉鎖された高速道路で誰よりも速く2周を走ることです。 より正確には、最も多くのポイントを獲得する必要がありますが、ポイントを獲得する主な方法は最初に来ることです。 また、道路上のボーナスを収集し、敵にダメージを与えるためのポイントを与えます。 トラックは、コンストラクターとして、正方形の「タイル」から組み立てられます;これらは、トラックの直線部分、コーナー（トラックの90度回転）、または交差点（T字型と通常）です。 トラックのキーポイント（「タイル」）に特定の順序で移動する必要があります。ループを作成する必要がある場合もあれば、戻ることもあります。 また、車には燃料の水たまりを背後に注ぎ、特別なシェル（タイヤとワッシャー）でお互いを撃ち、特別なニトロアクセラレータを使用する機会があります。 これらすべてのデバイスの料金は制限されており、マップ上にランダムに散らばったボーナスを選択することで補充されます。



私のAIがどのように機能するのか、そしてどのように（私は）勝つことができたのかを説明します。

最初のバージョン

コンテストに参加するのはこれが初めてではなく、毎年、前回よりも良い結果を達成することができました。 私の経験から、成功の大部分は戦略を適切に組織化することです。 時間は非常に限られているため、最初から何をどの順序で行うかを考える必要があります。 すべてを捨てて書き直さなければならない場合、勝利の可能性はほとんどありません。

私の戦略には「キラー機能」はなかったと思いますが、多くの小さな成功したソリューションが1つの大きな利点を形成しました。 ストーリーは非常に長く、これらすべてのポイントの詳細な説明が含まれます。



テストとデバッグについて。 過去数年、私のアルゴリズムが期待していた利益をもたらさない理由を理解しようとして頭を壁にぶつけたことがありました。 そして、多くの時間を費やして、アルゴリズムの核心に突然バグを発見しました-そして、すべてが予想よりもさらに高くなりました。 今年でさえ、バグのために勝利を逃しそうになりました。テストにより多くの時間を割く必要がありました。 今回は、視覚化がデバッグの主な方法になりました。 短いが効果的なテストを思い付くことができなかったので、長いテストを書くのに多くの時間を費やすのは残念でした。 予測された軌道を実際の軌道と比較する物理シミュレーターのテストのみがありました。 それなしでは、衝突の物理をデバッグすることは完全に不可能です。



私は最初のバージョンを教えて、トラックをパスするだけにすることにしました。 しかし、この最小限でさえ、正直に実装された場合、かなり多くの作業が必要でした。機械の自由な動きの物理シミュレーター、側面との衝突検出、経路の探索、軌道計画者が必要でした。 最初の3つのコンポーネントは明確でした-方法、4番目はあまりありません。



以前のように、私は物理シミュレーターを書くことから始めました。 問題はありませんでした-物理エンジンのソースが利用可能でした。 エンジンのようにティックごとに10回繰り返しを行うと、パフォーマンスに問題がある可能性があることがすぐに明らかになりました。 昨年の受賞者の記事を思い出して、絶対的な正確さが必要かどうか疑問に思いました。 それにもかかわらず、私はそれを正確に行うことにし、必要に応じて、10回ではなく1回の反復でそれをやり直しました。結局、正しい選択でした。 次に、フェンスとの衝突を検出し始めました。 エンジンで衝突検出を行うのが怖かったので、遅すぎると判断しました。 いくつかのオプションを検討したので、このアルゴリズムに決めました。



各タイルは、正方形のグリッドで9つのセクターに分割されています。 各セクターにあるため、マシンは4つの側面の1つにある特定のタイプのフェンスにのみ遭遇でき、一部のタイプではミラーのようなフェンスに遭遇します。



フェンシングのタイプは次のとおりです。

• ストレート壁右/下/左/上
• 内側の角
• 外角
• 円周
• セクター外の片側で円に変わる壁。 4つの側面があり、それぞれにまだ鏡像があります
• セクター外の片側の壁に変わる円。 4つの側面と鏡像もあります

これらの6つのオプションは、考えられるすべてのケースをカバーしています。 マシンは1つの「タイル」に置かれ、フェンスのあるコーナーは別の「タイル」に置かれるため、オプション5と6が必要です。 次に、マップ全体のテーブルが作成され、各「タイル」の9つのセクターのそれぞれに、マシンがフェンスと衝突したかどうかをチェックできるオブジェクトが置かれました。 実装は非常に効果的であることが判明し、反復に費やされた時間の3分の1未満でした。 これにより、パフォーマンスが大幅に低下することなく、ティックごとに1回ではなく、反復ごとに衝突チェックが可能になりました。



別の最適化について説明します。 角速度がモーションに関与していたため、最初の実装では各反復でサインとコサインを計算しました-遅いです。 しかし、ホイールの回転角（角速度に影響する）はティックごとに1回しか変化せず、衝突からの角速度はめったに現れなかったため、通常は各反復で同じ一定の角度をマシンのオリエンテーション角に追加する必要がありました。 マシンの方向角をベクトルで保持し、各反復で一定の値で回転させました。これらは4回の乗算と2回の加算です。 サインとコサインは、ティックごとに1回だけカウントする必要があり、まれに、各反復での衝突後にカウントする必要がありました。



パスの検索は、最も単純な方法であるウェーブアルゴリズムで行われました。 それから、ターン、ボーナス、燃料油のプールの存在を何らかの形で考慮するために、ダイクストラのアルゴリズムにそれを書き直したかったのです。 しかし、彼は決してこれに戻りませんでした。



最後のコンポーネント-トラジェクトリプランナー。 私は彼といじらなければならなかった、私は、全体の競争の一般的な説明では、彼は半分の時間がかかったと思う。 後半は物理シミュレーターで、最小限の時間が他のすべてに費やされました。 最初は、以前と同じ方法で問題を解決しようとしました-特定の形式の軌道を列挙します。 最も単純な形式：Nティックを直接移動し、Mティックでステアリングホイールを一方向に回転させてから、ステアリングホイールを中立位置に戻します。 うまくいきましたが、悪くて非常に遅く、事前に100ティックのすべてのオプションを誤って計算すると、時間制限に収まりませんでした。 マシンは、ターンの前に次の列のレーンを変更する必要があることを理解していませんでした。 このアイデアに数日費やした後、私は何か他のものが必要であることに気づきました。



軌跡のツリーを作成することにしました。多くの参加者がこの考えに来たと思います。 しかし、おそらく私がそれを構築した方法は興味深いものです。 このツリーを構築するための成功したアルゴリズムのおかげで、私は大部分が勝ったと思う。 彼は、既知の何かに基づいてではなく、自分でアルゴリズムを発明しました。 自転車を発明したかどうかを厳密に判断しないでください。 ツリーは次のように構築されました。



450ティックの長さでいくつかの初期軌道を作成します（ここと以下の長さはティックで測定され、すぐに450で停止しませんでした）。 その後、何度も（割り当てられた時間がなくなるまで）、再帰的なメソッドが呼び出されました。このメソッドは、ツリーのブランチのいずれかで「ブランチ」を生成しました。 「分岐」中に、分岐点へのパスのセクションが新しいサブツリーのトランクになり、その後のセクションが新しいサブツリーのブランチの1つとなり、新しいブランチが追加されました。 すべてのブランチの長さは、ルートから最終状態までのパスの全長が一定またはそれ以下で、ブランチが衝突で終了するように選択されました。 最初のバージョンでは、4つのモーションオプションが分岐に使用されました。 ガスは常に床にあり、ステアリングホイールを4つの位置で回します。右、左、中立位置、現在の位置を維持します。 後に、ブレーキと後方への乗車のオプションが追加されました。 このツリー構築アルゴリズムの操作には、3つの評価関数が使用されました。

1. 子孫の枝の平均の長さが幹の長さより短い場合、現在のツリーの幹の「枝」を作成します（常に中央に）。 それ以外の場合は、再帰呼び出しの子孫を選択します。 私はここで多くのことを試しました-このオプションが最高であることが判明しました。
2. 現在のツリーの子孫を選択して、再帰呼び出しを行います。 最大値を持つ子が選択されます：<ツリー内のブランチの平均長> * <3番目の評価関数> / sqrt（ツリーのすべてのブランチの長さの合計）。 ツリーが縮退しないように、分割が必要です。ブランチの探索に時間がかかるほど、分母が大きくなり、優先度が低くなります。
3. 主な評価関数。これに基づいて、どのブランチを使用するかが決定されます（どちらのブランチが優れているか）。 最初のバージョンでは、この関数の値はトランクのスコアと子孫の最大スコアの合計に等しくなりました。 フィニッシュラインに近づくと、「タイルを取る」という報酬が与えられました。 この機能は、かなり後に変更されました。

それは、仕上げにつながったそれらのブランチのブランチ優先順位を持つかなり均一なブランチツリーであることが判明しました。 残念ながら、そのツリーの写真はありませんでしたが、視覚的には最新バージョンとほとんど変わりませんでした。



これは、私の戦略の最新バージョンの視覚化が、可視性が制限された状態のマップの1つでどのように見えるかです。 これらは、1ティックで構築される軌道です。 最適なものは、多くのティックに対して取得されたそのようなツリーのセットから選択されます（これとその他のトリックについては、以下の記事で説明します）。







ここで主催者に感謝したいと思います。 今回、AIが動作していた世界は過去よりも著しく複雑であることが判明したため、参加者は新しいアルゴリズムとアプローチを探すようになりました。 このような軌跡の木は、昨年のホッケーやタンクで完璧に機能したと思います。



最初のラウンドの約9日前に、最初のバージョンの準備が整いました。 彼女は普通に運転し、約200x-300xの場所に登りました。 さらに、それは戦略のフレームワークになり、根本的に変更されず、新しい機能のみが追加されました。

最初のラウンドの準備

当時はまだカードが少なく、それらはシンプルでしたが、マシンはしばしば行き詰まりました。 彼女は後方に乗ることができなかったので、壁に寄りかかって。 メインアルゴリズムに障害が発生した場合の「スマートガイ」への切り替えは無効でした。 私はすべてを主要なものに教えるつもりで、時間を無駄にしたくないので、私は緊急の発見的アルゴリズムを書きませんでした。 ツリーパスのルートの分岐オプションにリバースライドを追加しました。 この段階で、ティックごとに軌跡のツリーを再構築しました。 すべての分岐に分岐オプションを追加すると、通常の分岐の分岐が大幅に削減され（リソースは限られています）、マシンの性能が低下し始めました。 そのため、ルートにのみ、そして緊急（スタック）の場合にのみ新しいブランチを追加しようとしました。 私は簡単な状況から離れることを学びました-病変は少なかった。 評価はratingい上がり、二百に達しました。



ここで私は、最初に問題を解決するために、すべての改善をこの順序で実行しようとしたことに注意してください。これは、最も多くの敗北の原因です。 いくつかの問題を修正する必要がなかったため、このアプローチが功を奏し、時間を節約しました。



次の改善は非常に簡単でしたが、非常に効果的でした。 見つかったパスのすべてのティックを捨てて、次のティックで再び探すのはなぜですか？ 物理シミュレーターは小数点以下10〜12桁の精度を示したため、数十ティックの間、車は非常に高い精度で選択されたパスに残りました。 その後、軌道を完全に正確に予測することで、多くのコンピューティングリソースを節約できることに気付きました。 新しく構築されたツリーの各ティックは、前のティックに保存されているものと比較され、古いものを残すか、新しいものに置き換えるかの決定が行われました。 彼は、予測された座標と実際の座標または速度が7番目のサインで異なる場合、機械が軌道から「外れた」と信じていました。 ツリーは対称ではなく、ターゲットに向かって伸びており、各ブランチの長さは最大10ティック以上だったため、見つかったツリーはかなり「古くなった」ようになりました。



したがって、軌跡は、数十本以上のチークで作られた森全体から選択されました。 絶対的な精度は必要ないというアドバイスに従った場合-この手法を適用するのは難しいかもしれませんが、累積誤差を制御する必要があります。 各ティックの10回の反復により、軌道の計算速度が10倍（実際にははるかに）減少しましたが、数十倍の計算が可能になりました。 そして、絶対的な正確さなしにタイヤを一気に振り回すようなトリックを行うことは困難です（これは十分な正確さの問題です）。



前回の最適化の後、パフォーマンスの問題は緩和されました。ツリーを構築する時間を3〜4倍短縮しても、戦略を弱めることはほとんどありませんでした。 別の改良により、ブレーキを使用できるようになりました。 ここで問題が発生しました。すでにほとんど停止しているマシンのブレーキングに割り当てられたすべての時間を費やして、互いにほとんど区別できない多くの状態。 私はそれを非常に大まかに決めましたが、うまくいきました。機械の縦方向の速度が指定された速度よりも遅い場合、速度を落とすことを禁じました。 急激なターンのあるマップでの永続的な敗北は停止しました-評価は最初の100で修正されました。



次に、ニトロの使用を追加しました。 分岐オプションがいくつかありますが、これはルート専用です。 活性化されたニトロで見つかったパスの長さが7「タイル」を超える場合、ニトロの使用が許可されました。 アルゴリズムはしばらくしてニトロを使用することを計画できませんでしたが、リソースを節約するために必要ではないと考え、それをしませんでした。 彼はバグを修正し、いくつかの「クランチ」を追加して、どういうわけか撮影、水たまりを設定しました。



次に実装することにしたのは、ボーナスの収集です。 その時までに、それらを集めた人はほとんどいませんでした。 私はボーナスで衝突の物理学をするのが面倒で、競争の終わりまでそれをしませんでした。 そのため、ボーナスのコレクションを追加することは難しくありませんでした。物理シミュレーターの各ティックは、ボーナスとの交差をチェックしました。 3番目の評価機能でボーナス報酬を受け取ります。 「ニトロ」と「修理キット」の平均であるポイントに大きな報酬を与えながら、残りはゼロです（まだ使用できませんでした）。 このバージョンは最初のラウンドに参加し、14位になりました。ラウンド後、「top20」で修正されました。

第2ラウンドの準備

週末、ラウンドが行われている間に、少しリラックスして、一般的なアプローチについて再考する時間がありました。 私はまだ水たまりを撃って注ぎ込む方法を知らなかったという事実に加えて、ボーナスを拾うことに奇妙さがあり、マシンは高速セクションで悪化し始めました。



2番目の問題から始めることにしました。 ツリーの分岐のバリエーションにブレーキを追加すると、制限がある場合でも、ツリーの分岐が少なくなるため、高速区間での走行には依然として悪影響がありました。 ツリーの評価関数を実験するのにかなりの時間を費やしてきたので、何も達成できませんでした。 そして、私は両方のツリーを（ブレーキの有無に関係なく）構築し、最良のものを選択することが可能であると判断しました。 それは素晴らしいアイデアでしたが、複合アルゴリズムであることが判明しました。将来的には、衝突解決を備えたツリーをコンポジションに追加することで拡張しました。 ただし、ツリーごとの反復回数を減らすことが必要な場合があり、パフォーマンスのマージンが非常に役立ちました。 アルゴリズムは両方のバージョンの利点を組み合わせました。 上記の軌跡ツリーの画像では、3本の緑の線が表示されています。これらは3つの異なるツリーのそれぞれで最適な軌跡です。 黒い線は、これら3つの経路のいずれかでブレーキがかかる領域です。



ボーナスの問題はより根本的なものでした。 マシンの動作を調べてみると、彼女は非常に単純なボーナスを超えて運転していたことが明らかでした。 その理由は、2つのボーナスが先に（より近く、より遠くに）あったからです。 戦略は両方のボーナスを取ることができる軌道を計算する時間がなく、2番目のボーナスを選択しました。 彼女は隣人を連れて行ったが、遠くのものを手に入れる方法を簡単に見つけるだろう。 一流のボーナスをとる動機付けをするために-3番目の評価機能で、イベントの賞の指数関数的減衰を追加しました。 最良の結果は、ティックあたり0.99のかなり遅い減衰でした（約70ティックに対して2回）。 確かに言うのは難しいですが、この手法はタイプライターと将来の撮影の両方にプラスの効果をもたらしたと思います。



ゲームをさらに分析すると、燃料の水たまりとの衝突による多くの敗北が示されました。 燃料の水たまりにぶつかった場合のペナルティが追加されました。 それから彼はこれで十分ではないと判断し、非常に無害な水たまりを非常に恐れました。 水たまりと接触する摩擦係数の低下をシミュレータに追加しました。 「ロケールランナー」を詳しく調べて、式を見つけました。燃料油のプールと最初に接触したときに角速度がどのように変化するかです。 「ランダム」であることが判明しました。2つのオプションしかありません。右または左にスピンし、スピン速度を正確に計算できます。 彼は、自分の子孫にこれら2つのオプションを設定し、それらの推定値を平均することで、軌跡ツリーに「確率的」分岐を作成しました。 彼は水たまりを非常にうまく回り始め、時にはそれを彼の利益のために使いさえしました。



第2ラウンドが近づいていた、それはタイヤをマスターする時間でした。 ここでは、根本的に新しいことは何もしませんでした。 物理シミュレータータイヤ、側面およびマシンとの衝突に追加されました。 それには多くの時間がかかり、すべてをテストするために、エンジンの衝突の物理に対処しなければなりませんでした。 損害を受けた場合、彼は評価機能に罰金を科し、死に対しては非常に大きな罰金を科しました。 その後、タイヤをかわす方法を知っていて、タイヤとの衝突を利用することさえできましたが、それでも撃つことができませんでした。 現在、射撃の追加は完全に簡単な作業になっています。 自分が敵だと想像し、タイヤをかわそうとしました。 これがうまくいかなかった場合、または判明したが、壁を切るコストがかかった場合は、撮影する必要があります。 アルゴリズムで敵を最適な弾道を見つけるために置き換え、ショット中の弾道の全体的な評価（すべてを考慮して：移動、ダメージ、ボーナス）が大幅に減少した場合、私は撃ちます。



敵の場合、軌跡は150ティックで計算され、その軌跡の検索よりも10〜20倍少ない時間が割り当てられました。 自分のタイヤを打つことによる逆転のトリックは自分で判明しました-戦略は敵へのショットをシミュレートし、飛行タイヤを考慮して詳述された独自の軌道が悪化しなかったことを確認し、ショットを許可しました。 水たまりのステージングも同様の方法で追加されたので、撮影の前後で覚えていません。 計算量が少ないために多くのミスがありましたが、私はすでに第2ラウンドを大きなマージンで1位で終えました。 2回目のラウンドが進行中に、私はバギーを撃つ方法を教えました。 タイヤを撃つようにした。 最初はパックを回避することを学んだ後、射撃を追加しました。

最終準備

フィナーレ機能の準備をします。 主催者は、未知のカードと限られた可視性を約束しました。 そのような状況で何が重要かは明らかではありませんでした。 視界が限られている状況でのライディングに問題があったため、これを行うことにしました。



おそらく、決勝のすべての参加者のように、私は単に未知の「タイル」交差点を考えました。 私は視覚化を完成させました-私は「戦争の霧」、私が知っているすべての「タイル」を描きました。 未知のものの代わりに、交差点を描きました。今、タイプライターの目を通して世界を見ました。 レースの最初の視聴で問題が明らかになりました。 マシンは、交差点と見なされる未知の「タイル」を介して最適な軌道を見つけましたが、それらを開いた後、壁に直進していましたが、リセットしませんでした。 新しい情報を受信するたびに、ティックごとに保存された軌跡のツリーを「カット」する小さなアルゴリズムを作成しました。 ブランチが未知の「タイル」を通過し、その「オープン」後に、想定されていないタイプであることが判明した場合-このブランチはツリーから切り離されました。 また、他のイベント（水たまり、貝殻、ボーナスの出現）の処理を行う必要がありましたが、時間がなかったため、ツリー全体がダンプされました。



視覚化が明らかにした別の問題がありました。 一部の「タイル」は「通過可能」（空ではない）と見なされていましたが、近隣の「タイル」からそうではないことが明らかでした。 わずかに修正されたウェーブアルゴリズム（壁の存在に関する新しいデータが見つかった「タイル」を繰り返し通過する）がこの状況を修正しました。 これで、間接データから道路がないことが明らかになった時点で、マップの全領域が急激に大きな空の領域に「崩壊」する可能性があります。 これによりゲームの強度が向上したかどうかはわかりませんが、視覚化を見るとはるかに快適になりました。



視界が限られている状況で戦略を大きく弱めたものは他にありますか？ 予想外のターンは多くの問題を生み出し、壁に触れることを恐れてパニックに陥り、戦略は多くの時間を失いました。 ひどく減速したか、わずかな角度でも壁にわずかに触れただけで、逆になりました。 最後に、機械と壁の衝突の解決策を講じることにしました。 また、ここで特別なことは何もありません-ロジックをコピーしてテストするのに多くの時間を費やし、すべてを非常に遅くならないようにします。 基本的な問題がありました。 これより前に、壁に触れることによって軌道が切断された場合、壁の近くを押す長い（ティック単位の）軌道が現れました。 機械は実際には移動せず、壁にもたれており、軌道の木はこれらほとんど区別できない状態で再び縮退しました。



ブレーキングの際に同様の問題を解決しようとして、私は多くの実験を行った古いアイデアに戻らなければなりませんでした。 その意味は、「ティックの長さ」を実際の長さに置き換えることでした。 それは通常の軌道を台無しにしましたが、衝突軌道については、これが私が思いつく最高のものです。 この乗車オプションを彼の「合成」軌道検索アルゴリズムに追加しました。 これにより、戦略のほぼすべての側面が強化されました。予想外の交差点は問題ではなくなり、水たまりの周りを運転し、タイヤをかわすことがはるかに自信になりました（間違いなくタイヤにぶつかると、大きな事故を起こさずに「偶然に」壁を走り続けることができました）。タイヤでの射撃と水たまりの設置も危険になり、回避の機会、壁へのちょっとした攻撃がはるかに少なくなりました。そして、壁との衝突を処理するロジックを書き直す過程で、バグ（角度との衝突が誤って決定された）を発見しました。バグを修正すると、他の何よりも戦略が強化されました。



利用可能なマップでは、戦略がかなりうまくいき始めました。唯一の明らかな問題は、車同士の衝突と自分での射撃でした。これはまれでしたが、すべてを台無しにする可能性があります。彼は独自の方法で射撃を修正しました。射撃する場合は、これが自分の車両の1つの最適な軌道の評価を所定量以上「損なう」かどうかを確認します。今では、車同士が衝突しないように教える必要がありました。走行する各マシンの軌道が保存されているので、車を横断するための罰金を追加できます。そのため、ペナルティはマシンの相対速度の2乗に比例しました。高速では衝突はより危険だからです。驚くほどうまくいきました。今では車は交差点で互いに口pastをふり、慎重に列を運転し、丁寧にお互いを通過させます。



未知の最終カードからのサプライズを期待していました。新しいマップで予想外で非常に不愉快なことを考えて、結論は、これまでのところ、後方に乗る必要はなく、衝突後にのみ曲がることでした。これを提供する必要があり、後方へのライディングの実験を開始しました。その後、評価関数に「バグ」を見つけましたが、これは後に「機能」であることが判明しました。フィニッシュラインに近づいたことに対する報酬と距離に対するペナルティを与えると、マシンは向きを変えず、短時間であってもフィニッシュラインから離れることを非常に恐れていました。したがって、私は最初の「タイルのキャプチャ」に対してのみ報酬を与えました。その後、戻って再び近づいた場合-報酬を与えず、距離については罰金を科しませんでした。この論理にはバグがありました;木の枝には、繰り返し「タイルをとる」ことに対する報酬がまだ与えられていました。このため、後進するとき、機械は「タイル」の間に挟まって前後にひきつり、繰り返し受け取る喜びの報酬。このバグの修正により、バックライディングが大幅に改善されましたが、新しい「ランダム」カード（これは最終日で、すでにレイアウトされていました）では、これにより戦略が予想外に大幅に弱まりました。私は、前方に乗るための古いロジックを早急に戻さなければならず、後方に乗るためだけに新しいロジックを残す必要がありました。それから私はミスを犯しました-時々後方へのライディング中に立ち往生しました、そして、このため、私は決勝戦で勝利を逃しそうになり、休憩中にのみ修正されました。しかし、なぜその「バグ」が「機能」であることが判明したのでしょうか？ 「タイルをとる」ことに対する報酬の減少と同時に、「タイルをとる」ことの誤った報酬は、マシンを少し前進させて、すぐに減速して後方に運転するのではなく、ループを作るように動機付けました（可能であれば）。



, , . «», , . , — . — , ( , , ), - . , .

おわりに

- . . , , .



.