このトピックのさらなる開発は、それ自体を示唆しました：ゲームパラメーターの境界フレームを設定できる基本的なアルゴリズムがわかっている場合、これらの同じアルゴリズムを使用して、プレーヤーを少なくとも部分的に交換し、ゲームプレイの「ライブ」をチェックできるAIを作成できます。
シングルプレイヤーゲーム用のプレイヤーシミュレートボットの作成に関するトピックは、Habréで繰り返し登場しましたが、原則として、「スポーツへの関心」または単調なアクションが必要なゲームの「ワインドアップ」パラメータを目的として作成されました。 ただし、AIはこの記事の最初の部分であるゲーム開発プロセスでも有益です。
まず、タワーディフェンス（TD）ゲームでAIが必要になる理由を判断します。
まず、ボットはレベルの表面的な評価、特にジオメトリのチェックに必要でした。 ゲームには自由なフィールドがあるため（無料開発）、ボットの助けを借りて、さまざまな建物オプションで敵のパスグラフがどれだけ変化するかをすばやく確認できました。
第二に、ボットを作成する過程で、非常に便利な機能がゲームに導入されました（デバッグオプション）。ゲームメカニックの計算のみで、グラフィックスをレンダリングせずにクリープウェーブを実行する最速の「加速」です。 これにより、ボットの動作をすばやく確認したり、各フィールド構成（およびタワーをフィールドに配置するさまざまな方法）の個々の波のバランスをデバッグしたりできました。 この方法は、さまざまな状況でさまざまな種類のタワーの適用性を「実際に」検証するために必要でした。 これにより、さまざまなカードを短時間で「プレイ」でき、数学的に検証されたデータが実際の状態とどのように一致するかを示す統計を収集できます。
ボットの原理について話すと、次のアルゴリズムがありました（パラグラフはボットの進化、その異なる反復を示しています）。
1.ボットは常に実行されており、いつでも行動を起こすことができます-敵の波を見越して、敵がフィールドを横切って移動するとき。
2.すべてのクリープ波の経路が計算されるたびに。 1つのウェーブでは、異なるポイントから来る複数の敵ユニットが存在する可能性があることに注意してください。
3.フィールドの各セルには、クリープの分隊の数に応じて、独自の「重み」が割り当てられます。 ボットは1波先をカウントし、どのポイントからクリープが発生するかを知っていることがわかります。
4.また、ボットは、どのポイントからどのクリープがどのポイントから、どの間隔で、どのようなクリープが続くのか、つまり後続の各ウェーブ/サブウェーブの「パワー」に関するデータを追加することで、より「スマート」にすることができます。
5.後続の各波の「重み」は、波が始まるまでの時間に基づいて計算されました。 つまり、ボットは「1ステップ前進」を無作法に見つめ、すぐに「戦略的に」行動することができます。 各波の各セルの値の合計が追加されたため、最終的にフィールドの各セルには1つの値、つまり「重み」があることがわかりました。 もちろん、この係数のマトリックスは、残りの波の数によって異なります。すでに通過した波（クリープの経路）は、「ウェイトマップ」では考慮されなくなりました。
6.どのセルが最大の「重量」を持っているかによって、この時点でタワーが配置されます。
7.最初の反復では、経済のプロファイルに応じたボットのロジックは単純でした。タワーに十分なお金があるとすぐに購入されます。 主なタスクは建設中にレベルジオメトリをチェックすることだったため、最初は1つのタワーのみが使用されました。
8.タワーをいくつかのタイルに設置するとクリープの軌跡が変わる可能性があるため、2回目の反復でフィールドの誤計算と1ターン先の敵の行動が追加されました。 したがって、各場所について、この時点でタワーが置かれた場合、敵の弾道が変更された場合、そして、最後に設置されたタワーだけでなく、以前に設置されたすべてのタワーがどのくらいのダメージを与えるかが確認されました。 この機会がなければ、塔が一見理想的な場所に設置されると、クリープが残りの大砲の周りを動き始め、塔の残りの部分が役に立たなくなることが繰り返し起こりました。
9.ボットのさらなる開発-タワーアップグレードの使用。 再び、それは1ターン先に見え、より収益性が高くなります-タワーの1つをアップグレードします（最初に最大の損傷を引き起こすタワーが選択され、2回目の反復ですべてのタワーが移動しました。非線形に変化する可能性があります）、または別のものを置く。 もちろん、与えられたダメージの差は、アクションのコストに正規化されました。
10.次に、ボットに未使用のタワーの販売を教える必要がありました。 これは、ボットが次の波の場所Xにあるタワーが関与しないことを「知っている」場合に使用されました。 これは、タワーの場所を選択する原理と同様に計算されましたが、反対の符号のみが使用されました。 タワーを販売しても、その価値の50％しか返されなかったことを考慮することが重要です。 したがって、設置されたタワーが現在の場所のタワーの2倍の損害を引き起こす場所がマップにある場合、タワーは販売する価値があります（販売中の損失を補うため）。
ただし、ボットのさらなる開発（他のタワー、ボーナス、ユニークな能力を持つ有能な敵に対抗できるようにするため）は実用的ではないと見なされましたが、このユーティリティの一部では、ゲームリプレイの記録と表示というまったく異なる分野でのアプリケーションが見つかりました。
さらに、同じカード上のボットと人のロジックを比較した結果、ボットはジオメトリに関してはよく見えることがわかりましたが、タワーのアップグレードと販売に関係する人は通常より優れています。 これに基づいて、AIが非常によく示されている次のポイントが推測されました。
1.ベースタワーのみがレベルを簡単に通過することを確認します。
2.ジオメトリをチェックし、波の1つが不均衡になっていないかどうかを確認します。実際、タワーを配置するのに便利なポイントがいくつあるか、プレイヤーが少なくともレベルの中間までタワー建設サイトを選択できるかどうかを確認しました。
3.一般的に最初の波でレベルに達しているかどうかを確認します。ボットのおかげで、開始資金の適切な残高を計算できました。
実際、AIはその使命を果たしました。失敗したカードを除外し、タワーと対戦相手の特定のバランスでどのタイプのレベルジオメトリが許容できるかをゲームデザイナーに明らかにしました。
ただし、AIモジュールの使用も将来的に関連性がありました。つまり、プレーヤーの単一のアクション（タワーの構築、アップグレード、販売、ゲーム時間の加速など）をシミュレートできるコードの部分です。
これはすべて、デザインベクター自体が選択され、ライブプレーヤーでレベルの複雑さと興味深い部分の調整が行われたときに、他のテスターからのリプレイの記録（および表示）に役立ちました。 実際、決定を発行するソースは単純に変更されています-AIがこれを行う前に、アクションのシーケンス全体がログファイルから読み取られました。
ログの記録と表示
各ゲームセッションで、次のアクションが記録されました。
1.ゲームセッションの開始/終了、
2.一時停止のオン/オフ、
3.ゲームの速度を変更し、
4.初期のコールウェーブ、
5.タワーXをABの座標に設置し、
6.場所Xでタワーをアップグレードします。
7.場所Xでのタワーの販売、
8.コントロールのために-一杯の命の損失、
9.制御のために-勝ち/負けレベル、
10.コントロールのために-波の最後のクリープの殺人の事実（クリープの座標が書かれています）。
ログの例
level3.lvl start; 03/22/2012 19:39:12;
level3.lvl; 6.41; ビルド; active_tower; 5.1; 250;
level3.lvl; 10.25; ビルド; active_tower; 9.1; 190;
level3.lvl; 12.16; アップグレード; 5.1; 130;
level3.lvl; 13.86; アップグレード; 9.1; 80;
level3.lvl; 35.68; killlast; wave1; 7.0; 6;
level3.lvl; 60.76; killlast; wave2; 7.0; 10;
level3.lvl; 85.97; ビルド; splash_tower; 11.0; 190;
level3.lvl; 88.44; ライフル wave3; 56;
level3.lvl; 88.98; ライフル wave3; 56;
level3.lvl; 99.08; killlast; wave3; 7.0; 6;
ゲーム時間はイベントごとに書き込まれます。時間はゲームの速度に依存しません。つまり、実際の時間とは異なる場合があります。
したがって、プレーヤーのアクションとゲームの状態の両方を表示できます。 これは、リプレイを開始するときのゲームプレイの「同期」にとって重要です。
たとえば、リプレイで最後の波のクリープが殺されず、ログが死んだことを示している場合、同期を維持するには、このクリープを人為的に破壊する方が良いでしょう。
ゲーム時間を記録することにより、プレイヤーが「刺激物」（敵の新しい波）の出現に反応する速さを計算できます。
リプレイファイルは、電話のファイルシステムに自動的に記録された後、削除され、ゲームのデスクトップバージョンで再生されました。 ゲームはUnityで記述されているため、エディターではゲームをモバイルデバイスと同じ方法で起動できます。 もちろん、リプレイをプレイするときにこれを利用しました。
また、プレーヤーのアクションに応じて、ゲーム内の「たるみ」アクションコンポーネントがある場所を確認できます。
この「マップ」により、多くの個別のリプレイの分析に頼ることなく、レベルの弱点を識別できます。また、視覚表示により、ゲームレベル自体のログデータをより適切に「オーバーレイ」できます。
したがって、この手法はプロジェクトのさまざまな段階で役立ちました：プレイテストでは、ゲーム中のプレイヤーの「進化」を含む各テスターの動作を確認することが重要であり、後の段階では多くのウォークスルーを分析する必要がありました