🥇ゲーム AI の作成方法: 初心者向けガイド

ゲームにおける人工知能に関する興味深い資料を見つけました。 AI に関する基本的な事項を簡単な例を使って説明しており、その中には AI の開発や設計に便利なツールや手法が多数含まれています。いつ、どこで、どのように使用するかについても記載されています。

ほとんどの例は疑似コードで記述されているため、高度なプログラミング知識は必要ありません。カットの下には、写真と GIF を含む 35 枚のテキストがあるので、準備をしてください。

更新。申し訳ありませんが、ハブレに関するこの記事はすでに私自身で翻訳しています。ペイシェントゼロ。彼のバージョンを読むことができますここで, しかし、どういうわけか記事が通り過ぎてしまいました（検索を使用しましたが、問題が発生しました）。そして、私はゲーム開発専用のブログに書いているので、購読者向けに私のバージョンの翻訳を残すことにしました (いくつかの点は形式が異なり、開発者のアドバイスにより意図的に省略された点もあります)。

AIとは

ゲーム AI は、オブジェクトが置かれている状況に基づいて、オブジェクトがどのようなアクションを実行するかに焦点を当てます。これは一般に「インテリジェントエージェント」管理と呼ばれます。エージェントとは、プレイヤーキャラクター、車両、ボット、またはより抽象的なもの、つまりエンティティのグループ全体や文明のことです。いずれの場合も、環境を見て、それに基づいて判断し、それに応じて行動しなければならないものです。これは、「感覚/思考/行動」サイクルと呼ばれます。

センス: エージェントは、その行動に影響を与える可能性のある環境内の物事に関する情報 (近くの脅威、収集すべきアイテム、探索すべき興味深い場所) を見つけたり受け取ったりします。
考える: エージェントはどのように反応するかを決定します (アイテムを収集するのに十分安全かどうか、または最初に戦うか隠れるべきかを検討します)。
動作: エージェントは、前の決定を実行するために動作を実行します (敵またはオブジェクトに向かって移動を開始します)。
...キャラクターの行動により状況が変化したため、新しいデータでサイクルが繰り返されます。

AI はループのセンス部分に焦点を当てる傾向があります。たとえば、自動運転車は道路の写真を撮影し、レーダーやライダーのデータと組み合わせて解釈します。これは通常、受信データを処理して意味を与え、「20 ヤード先に別の車があります」などの意味情報を抽出する機械学習によって行われます。これらはいわゆる分類問題です。

ゲームでは、ほとんどのデータがすでにゲームの不可欠な部分になっているため、情報を抽出するための複雑なシステムは必要ありません。前方に敵がいるかどうかを判断するために画像認識アルゴリズムを実行する必要はありません。ゲームはすでに認識しており、その情報を意思決定プロセスに直接入力します。したがって、サイクルの感覚部分は、多くの場合、考えて行動する部分よりもはるかに単純です。

ゲームAIの限界

AI には、遵守しなければならない制限がいくつかあります。

AI は、機械学習アルゴリズムのように、事前にトレーニングする必要はありません。開発中に何万人ものプレイヤーを監視し、それらと対戦するための最適な方法を学習するニューラルネットワークを作成することは意味がありません。なぜ？ゲームがリリースされておらず、プレイヤーがいないためです。
ゲームは楽しくてやりがいのあるものでなければならないため、エージェントは人々に対して最適なアプローチを見つけるべきではありません。
プレイヤーが実際の人間と対戦しているかのように感じられるように、エージェントはリアルに見える必要があります。 AlphaGo プログラムは人間よりも優れた成績を収めましたが、選択された手順はゲームの従来の理解からは非常に遠いものでした。ゲームが人間の対戦相手をシミュレートしている場合、この感情は存在しないはずです。理想的な決定ではなく、もっともらしい決定を下せるようにアルゴリズムを変更する必要があります。
AIはリアルタイムで動作する必要があります。これは、アルゴリズムが意思決定を行うために CPU 使用率を長期間独占できないことを意味します。ほとんどのゲームでは、すべての処理を実行して次のグラフィックスフレームに進むのに 10 ～ 16 ミリ秒しか必要ないため、33 ミリ秒でも長すぎます。
理想的には、システムの少なくとも一部はデータ駆動型であるべきです。そうすれば、コーディング者以外でも変更を加えることができ、より迅速に調整を行うことができます。

感覚/思考/行動のサイクル全体をカバーする AI アプローチを見てみましょう。

基本的な決定を下す

最も単純なゲーム、ポンから始めましょう。目標: ボールがパドルを通り過ぎるのではなく、パドルから跳ね返るようにパドルを動かします。ボールを打たなければ負けになるテニスと同じです。ここで AI は、プラットフォームをどの方向に移動するかを決定するという比較的簡単なタスクを実行します。

条件文

ポンの AI にとって、最も明白な解決策は、常にボールの下にプラットフォームを配置しようとすることです。

このための簡単なアルゴリズムを疑似コードで記述します。

ゲーム実行中のすべてのフレーム/更新:
ボールがパドルの左側にある場合:
パドルを左に動かす
ボールがパドルの右側にある場合:
パドルを右に動かす

プラットフォームがボールの速度で動く場合、これはポンの AI にとって理想的なアルゴリズムです。データがそれほど多くなく、エージェントが実行できるアクションもない場合は、何も複雑にする必要はありません。

このアプローチは非常にシンプルなので、感覚/思考/行動のサイクル全体がほとんど目立ちません。しかし、それはそこにあります:

Sense 部分は XNUMX つの if ステートメントで構成されます。ゲームはボールがどこにあるのか、台がどこにあるのかを知っているため、AI はその情報を求めます。
Think 部分も XNUMX つの if ステートメントに含まれています。これらは XNUMX つのソリューションを具体化していますが、この場合は相互に排他的です。その結果、XNUMX つのアクションのうち XNUMX つが選択されます。プラットフォームを左に移動するか、右に移動するか、すでに正しく配置されている場合は何もしません。
Act 部分は、Move Paddle Left および Move Paddle Right ステートメントにあります。ゲームのデザインに応じて、プラットフォームを瞬時に移動したり、特定の速度で移動したりできます。

このようなアプローチはリアクティブと呼ばれます。世界の現在の状態に反応してアクションを実行する、単純なルールのセット (この場合はコード内の if ステートメント) があります。

デシジョンツリー

Pong の例は、実際には、デシジョンツリーと呼ばれる正式な AI 概念に相当します。アルゴリズムはそれを通過して、「リーフ」、つまりどのようなアクションを実行するかについての決定に到達します。

プラットフォームのアルゴリズムのデシジョンツリーのブロック図を作成してみましょう。

ツリーの各部分はノードと呼ばれます。AI はグラフ理論を使用してそのような構造を記述します。ノードには次の XNUMX 種類があります。

意思決定ノード: 何らかの条件のテストに基づいて XNUMX つの選択肢から選択します。各選択肢は個別のノードとして表されます。
終了ノード: 最終的な決定を表す実行するアクション。

アルゴリズムは最初のノード (ツリーの「ルート」) から開始します。どの子ノードに移動するかを決定するか、ノードに保存されているアクションを実行して終了します。

前のセクションの if ステートメントと同じ仕事をデシジョンツリーに実行させる利点は何でしょうか? ここには一般的なシステムがあり、各決定には XNUMX つの条件と XNUMX つの可能な結果のみが含まれます。これにより、開発者はハードコーディングすることなく、ツリー内の意思決定を表すデータから AI を作成できます。それを表の形式で示してみましょう。

コード側では、文字列を読み取るためのシステムが得られます。それぞれにノードを作成し、XNUMX 番目の列に基づいて決定ロジックを接続し、XNUMX 番目と XNUMX 番目の列に基づいて子ノードを接続します。条件とアクションをプログラムする必要はありますが、ゲームの構造はより複雑になります。ここでは、追加の決定とアクションを追加し、ツリー定義テキストファイルを編集するだけで AI 全体をカスタマイズします。次に、ファイルをゲームデザイナーに転送すると、ゲームデザイナーはゲームを再コンパイルしたりコードを変更したりせずに動作を変更できます。

デシジョンツリーは、大規模な例のセットから (たとえば、ID3 アルゴリズムを使用して) 自動的に構築される場合に非常に役立ちます。これにより、取得したデータに基づいて状況を分類するための効果的かつ高性能なツールとなります。ただし、エージェントがアクションを選択するための単純なシステムを超えています。

シナリオ

事前に作成された条件とアクションを使用するデシジョンツリーシステムを分析しました。 AI を設計する人はツリーを自由に編成できますが、それでもすべてをプログラムしたコーダーに依存する必要があります。デザイナーに独自の条件やアクションを作成するツールを提供できたらどうなるでしょうか?

プログラマーが「ボールはパドルの左にある」および「ボールはパドルの右にある」という条件のコードを記述する必要がないように、設計者がこれらの値をチェックする条件を記述するシステムを作成できます。デシジョンツリーデータは次のようになります。

これは基本的に最初の表と同じですが、ソリューション自体には、if ステートメントの条件部分に似た独自のコードがあります。コード側では、これは決定ノードの XNUMX 番目の列を読み取りますが、実行する特定の条件 (ボールがパドルの左側にある) を探す代わりに、条件式を評価し、それに応じて true または false を返します。これは、Lua または Angelscript スクリプト言語を使用して行われます。これらを使用すると、開発者はゲーム内のオブジェクト (ボールとパドル) を取得し、スクリプトで使用できる変数 (ball.position) を作成できます。また、スクリプト言語は C++ よりも単純です。完全なコンパイル段階を必要としないため、ゲームロジックを迅速に調整するのに最適であり、「非コーダー」でも必要な関数を自分で作成できます。

上の例では、スクリプト言語は条件式を評価するためにのみ使用されていますが、アクションにも使用できます。たとえば、データ Move Paddle Right はスクリプトステートメント (ball.position.x += 10) になる可能性があります。そのため、パドルを右に移動するプログラムを作成する必要がなく、アクションもスクリプト内で定義されます。

さらに進んで、デシジョンツリー全体をスクリプト言語で記述することもできます。これはハードコードされた条件ステートメントの形式のコードですが、外部スクリプトファイルに配置されます。つまり、プログラム全体を再コンパイルしなくても変更できます。多くの場合、ゲームプレイ中にスクリプトファイルを編集して、さまざまな AI の反応をすばやくテストできます。

イベント応答

上記の例は Pong に最適です。彼らは、感覚・思考・行動のサイクルを継続的に実行し、世界の最新の状況に基づいて行動します。しかし、より複雑なゲームでは、すべてを一度に評価するのではなく、個々のイベントに反応する必要があります。この場合のポンはすでに悪い例です。別のものを選択しましょう。

プレイヤーを発見するまで敵は動かず、その後敵はその「専門性」に応じて行動するシューティングゲームを想像してみてください。誰かが「急いで」走り、誰かが遠くから攻撃します。これは依然として「プレイヤーが発見されたら何かをする」という基本的な反応システムですが、論理的には Player Seen イベントとリアクション (応答を選択して実行) に分けることができます。

これは、私たちを「感覚/思考/行動」のサイクルに戻します。 AI がプレーヤーを認識しているかどうかをすべてのフレームでチェックする Sense パーツをコード化できます。そうでない場合は何も起こりませんが、認識された場合は、Player Seen イベントが作成されます。コードには、「Player Seen イベントが発生したら、実行する」という別のセクションがあり、Think 部分と Act 部分に対処するために必要な応答がここにあります。したがって、Player Seen イベントに対する反応を設定します。「突進」キャラクターの場合は ChargeAnd Attack、スナイパーの場合は HideAndSnipe です。これらの関係はデータファイル内に作成できるため、再コンパイルすることなく迅速に編集できます。ここでもスクリプト言語を使用できます。

難しい決断を下す

単純な反応システムは非常に強力ですが、それだけでは不十分な状況も多くあります。エージェントが現在行っていることに基づいて、異なる決定を下す必要がある場合がありますが、これを条件として想像するのは困難です。場合によっては、条件が多すぎてデシジョンツリーやスクリプトで効果的に表現できない場合があります。次のステップを決定する前に、状況がどのように変化するかを事前に評価する必要がある場合があります。これらの問題を解決するには、より洗練されたアプローチが必要です。

有限状態機械

有限状態マシンまたは FSM (有限状態マシン) は、エージェントが現在いくつかの可能な状態の XNUMX つにあり、ある状態から別の状態に遷移できることを示す方法です。このような州が一定数存在するため、この名前が付けられました。人生における最良の例は信号機です。さまざまな場所でさまざまなライトのシーケンスがありますが、原理は同じです。各状態は何か (停止、歩行など) を表します。信号機は常に XNUMX つの状態のみを持ち、単純なルールに基づいて状態から状態へと移動します。

ゲームのNPCにも似たような話があります。たとえば、次の状態のガードを考えてみましょう。

パトロール中。
攻撃。
逃亡中。

そして、その状態を変更するための条件は次のとおりです。

衛兵は敵を見つけると攻撃します。
警備員が攻撃しても敵が見えなくなった場合、警備員はパトロールに戻ります。
警備員が攻撃して重傷を負った場合、警備員は逃げます。

また、ガーディアン状態変数とさまざまなチェック (近くに敵がいるかどうか、NPC の健康レベルはどれくらいかなど) を含む if ステートメントを記述することもできます。さらにいくつかの状態を追加してみましょう。

怠惰 - パトロールの合間に。
探索中 - 気づいた敵がいなくなったとき。
助けを見つける - 敵が発見されたが、単独で戦うには強すぎるとき。

それぞれの選択肢は限られています。たとえば、衛兵は体力が低い場合、隠れた敵を探しに行きません。

結局のところ、「if」の膨大なリストがあります。、それ」は非常に煩雑になる可能性があるため、状態と状態間の遷移を念頭に置くことを可能にするメソッドを形式化する必要があります。これを行うために、すべての状態を考慮し、各状態の下で、他の状態へのすべての移行と、それらに必要な条件をリストに書き留めます。

これは状態遷移テーブルであり、FSM を表す包括的な方法です。図を描いて、NPC の行動がどのように変化するかを完全に把握してみましょう。

この図は、現在の状況に基づいたこのエージェントの意思決定の本質を反映しています。さらに、各矢印は、その隣の条件が真である場合の状態間の遷移を示します。

更新のたびに、エージェントの現在の状態をチェックし、遷移のリストを調べ、遷移の条件が満たされている場合は、新しい状態を受け入れます。たとえば、各フレームで 10 秒タイマーが期限切れになっているかどうかがチェックされ、期限切れになっている場合は、ガードはアイドリング状態からパトロール状態に移行します。同様に、攻撃状態ではエージェントの健康状態がチェックされ、状態が低い場合は逃走状態になります。

これは状態間の遷移を処理していますが、状態自体に関連する動作はどうなるのでしょうか? 特定の状態の実際の動作を実装するという点では、FSM にアクションを割り当てる「フック」には通常 XNUMX つのタイプがあります。

現在の状態に対して定期的に実行するアクション。
ある状態から別の状態に移行するときに実行するアクション。

最初のタイプの例。パトロール状態では、フレームごとにエージェントがパトロールルートに沿って移動します。攻撃状態は、フレームごとに攻撃の開始を試みるか、これが可能な状態への移行を試みます。

XNUMX 番目のタイプでは、「敵が見えていて敵が強すぎる場合は、ヘルプを探す状態に移行する」という遷移を検討します。エージェントは、ヘルプを求めてどこに行くかを選択し、この情報を保存して、ヘルプ検索状態がどこに行くべきかを認識できるようにする必要があります。助けが見つかると、エージェントは攻撃状態に戻ります。この時点で、彼は同盟者に脅威について伝えたいと考えているため、NotifyFriendOfThreat アクションが発生する可能性があります。

もう一度、このシステムを、感覚/思考/行動サイクルのレンズを通して見ることができます。センスは、遷移ロジックによって使用されるデータに組み込まれます。考えてみましょう - 各状態で利用可能な遷移。そして、Act は、状態内または状態間の遷移時に定期的に実行されるアクションによって実行されます。

移行条件を継続的にポーリングするとコストがかかる場合があります。たとえば、各エージェントがフレームごとに複雑な計算を実行して、敵が見えるかどうかを判断し、巡回状態から攻撃状態に移行できるかどうかを理解する場合、これには多くの CPU 時間がかかります。

世界情勢における重要な変化は、発生時に処理されるイベントと考えることができます。 FSM が「エージェントはプレーヤーを認識できますか?」という移行条件をフレームごとにチェックする代わりに、別のシステムを設定してチェック頻度を下げるように設定できます (例: 5 秒あたり XNUMX 回)。その結果、チェックに合格すると Player Seen が発行されます。

これは FSM に渡され、FSM は Player Seen イベントの受信条件に進み、それに応じて応答する必要があります。結果として生じる動作は、応答するまでにほとんど知覚できないほどの遅延があることを除いて同じです。しかし、Sense 部分をプログラムの別の部分に分離した結果、パフォーマンスが向上しました。

階層型有限状態マシン

ただし、大規模な FSM の操作は必ずしも便利であるとは限りません。攻撃状態を拡張して近接攻撃と遠隔攻撃を分離したい場合は、攻撃状態 (現在および将来) に至る他のすべての状態からの遷移を変更する必要があります。

おそらく、この例では重複したトランジションが多数あることに気づいたでしょう。アイドリング状態のほとんどの遷移は、パトロール状態の遷移と同じです。特に同様の州をさらに追加する場合は、同じことを繰り返さないことが望ましいでしょう。アイドリングとパトロールを「非戦闘」という一般的なラベルの下にグループ化することは合理的であり、戦闘状態への共通の移行セットは XNUMX つだけです。このラベルを状態と考えると、アイドリングとパトロールがサブ状態になります。新しい非戦闘サブ状態に別個の遷移テーブルを使用する例:

主な州:

非戦闘状態:

そして図の形で:

システムは同じですが、アイドリングとパトロールを含む新しい非戦闘状態が追加されています。各状態にサブステートを含む FSM (そしてこれらのサブステートにも独自の FSM が含まれ、必要な限りこれが続く) を使用すると、階層型有限状態マシンまたは HFSM (階層型有限状態マシン) が得られます。非戦闘状態をグループ化することで、多数の冗長な遷移を削除します。共通の遷移を持つ新しい状態に対しても同じことができます。たとえば、将来的に攻撃状態を近接攻撃状態とミサイル攻撃状態に拡張した場合、これらは敵までの距離と弾薬の入手可能性に基づいて相互に遷移するサブ状態になります。その結果、複雑な動作とサブ動作を最小限の重複遷移で表現できます。

動作ツリー

HFSM を使用すると、動作の複雑な組み合わせが簡単な方法で作成されます。ただし、移行ルールの意思決定が現状と密接に関係している点が若干の難点がある。そして多くのゲームでは、これがまさに必要なものです。また、状態階層を注意深く使用すると、遷移の繰り返しの数を減らすことができます。しかし、場合によっては、どの州にいても機能する、またはほぼすべての州に適用されるルールが必要になることがあります。たとえば、エージェントの健康状態が 25% に低下した場合、エージェントが戦闘中であるか、アイドル状態であるか、会話中であるかに関係なく、エージェントに逃げてもらいたいとします。この条件を各状態に追加する必要があります。また、設計者が後で健全性の下限しきい値を 25% から 10% に変更したい場合は、これを再度実行する必要があります。

理想的には、この状況では、XNUMX か所のみで変更を加え、移行条件に触れないようにするために、「どの状態になるか」についての決定が状態自体の外部で行われるシステムが必要です。ここにビヘイビアツリーが表示されます。

これらを実装するにはいくつかの方法がありますが、本質はどれもほぼ同じであり、決定ツリーに似ています。アルゴリズムは「ルート」ノードから始まり、ツリーには決定またはアクションのいずれかを表すノードが含まれます。ただし、いくつかの重要な違いがあります。

ノードは、Succeeded (ジョブが完了した場合)、Failed (ジョブを開始できない場合)、Running (まだ実行中で最終結果がない場合) の XNUMX つの値のいずれかを返すようになりました。
XNUMX つの選択肢から選択するための意思決定ノードはもうありません。代わりに、これらは XNUMX つの子ノードを持つ Decorator ノードです。成功すると、唯一の子ノードが実行されます。
アクションを実行するノードは、実行されているアクションを表す Running 値を返します。

この小さなノードのセットを組み合わせて、多数の複雑な動作を作成できます。前の例の HFSM ガードを動作ツリーとして想像してみましょう。

この構造では、アイドリング/パトロール状態から攻撃状態またはその他の状態への明らかな移行はありません。敵が表示され、キャラクターの体力が低い場合、パトロール、アイドリング、攻撃など、以前にどのノードが実行されていたかに関係なく、実行は逃走ノードで停止します。

ビヘイビアツリーは複雑です。ビヘイビアツリーを構成する方法は数多くあり、デコレータと複合ノードの適切な組み合わせを見つけるのは困難な場合があります。また、ツリーをどのくらいの頻度でチェックするかについても疑問があります。ツリーのすべての部分をチェックするのか、それとも条件の 10 つが変化した場合にのみチェックするのか。ノードに関連する状態をどのように保存するのでしょうか。XNUMX 秒間のアイドリングがいつ行われたかをどのように知るのでしょうか。また、シーケンスを正しく処理できるように、どのノードが最後に実行されていたかをどのように知るのでしょうか?

このため、多くの実装が存在します。たとえば、一部のシステムではデコレータノードがインラインデコレータに置き換えられています。デコレータの条件が変化したときにツリーを再評価し、ノードの結合を支援し、定期的な更新を提供します。

ユーティリティベースのシステム

一部のゲームにはさまざまな仕組みがあります。単純かつ一般的な移行ルールの利点をすべて享受できることが望ましいですが、必ずしも完全な動作ツリーの形で享受できるわけではありません。明確な選択肢や可能なアクションのツリーを用意するよりも、すべてのアクションを調べて、現時点で最も適切なものを選択する方が簡単です。

ユーティリティベースのシステムはまさにこれに役立ちます。これは、エージェントがさまざまなアクションを持ち、それぞれの相対的な有用性に基づいて実行するアクションを選択するシステムです。ここで、ユーティリティは、エージェントがこのアクションを実行することがどれほど重要であるか、または望ましいかを示す任意の尺度です。

現在の状態と環境に基づいてアクションのユーティリティが計算され、エージェントはいつでも最も適切な他の状態を確認して選択できます。これは、現在の状態を含む各潜在的な状態の推定によって遷移が決定される点を除いて、FSM に似ています。最も有用なアクションを選択して次に進むことに注意してください (すでに完了している場合はそのまま残ります)。多様性を高めるには、小さなリストからバランスをとりながらランダムに選択することもできます。

システムは、ユーティリティ値の任意の範囲を割り当てます。たとえば、0 (まったく望ましくない) から 100 (完全に望ましい) までです。各アクションには、この値の計算に影響を与える多数のパラメーターがあります。ガーディアンの例に戻ります。

アクション間の遷移は曖昧であり、任意の状態が他の状態に従うことができます。アクションの優先順位は、返されたユーティリティ値に含まれます。敵が表示され、その敵が強く、キャラクターの健康状態が低い場合、Fleeing と FindingHelp は両方ともゼロ以外の高い値を返します。この場合、FindingHelp は常に高くなります。同様に、非戦闘アクティビティでは 50 を超える値が返されることはないため、常に戦闘アクティビティよりも低くなります。アクションを作成し、その有用性を計算するときは、これを考慮する必要があります。

この例では、アクションは固定定数値または XNUMX つの固定値のいずれかを返します。より現実的なシステムでは、連続した範囲の値から推定値を返します。たとえば、エージェントの体力が低い場合、逃げるアクションはより高いユーティリティ値を返し、敵が強すぎる場合、攻撃アクションはより低いユーティリティ値を返します。このため、エージェントが敵を倒すのに十分な体力がないと感じる状況では、逃げるアクションが攻撃よりも優先されます。これにより、任意の数の基準に基づいてアクションに優先順位を付けることができるため、このアプローチはビヘイビアツリーや FSM よりも柔軟で可変なものになります。

各アクションにはプログラム計算のための多くの条件があります。これらは、スクリプト言語または一連の数式として記述できます。キャラクターの日常業務をシミュレートする「ザ・シムズ」では、計算の層がさらに追加されます。エージェントは、公共料金の評価に影響を与える一連の「動機」を受け取ります。キャラクターがお腹が空いている場合、時間の経過とともにさらにお腹が空いてきます。キャラクターがそれを実行するまで、EatFood アクションの利用価値は増加し、空腹レベルが低下し、EatFood 値がゼロに戻ります。

評価システムに基づいてアクションを選択するというアイデアは非常にシンプルなので、ユーティリティベースのシステムは、AI の意思決定プロセスの完全な代替としてではなく、AI の意思決定プロセスの一部として使用できます。デシジョンツリーは XNUMX つの子ノードのユーティリティ評価を要求し、より高い方を選択する場合があります。同様に、ビヘイビアツリーには、アクションのユーティリティを評価してどの子を実行するかを決定するための複合ユーティリティノードを含めることができます。

移動とナビゲーション

前の例では、左右に移動するプラットフォームと、巡回または攻撃する警備員がありました。しかし、一定期間にわたるエージェントの移動を正確にどのように処理すればよいでしょうか? 速度をどのように設定し、障害物を回避し、目的地に到達することが単に直線で移動するよりも難しい場合、ルートをどのように計画しますか? これを見てみましょう。

Управление

初期段階では、各エージェントがどのくらいの速度でどの方向に移動しているかを含む速度値を持っていると仮定します。これは、メートル/秒、キロメートル/時、ピクセル/秒などで測定できます。Sense/Think/Act ループを思い出すと、Think 部分が速度を選択し、Act 部分がその速度をエージェントに適用すると想像できます。通常、ゲームにはこのタスクを実行する物理システムがあり、各オブジェクトの速度値を学習して調整します。したがって、AI にエージェントの速度を決定するという XNUMX つのタスクを任せることができます。エージェントがいるべき場所がわかっている場合は、設定された速度で正しい方向にエージェントを移動する必要があります。非常に自明な方程式:

希望旅行 = 目的地位置 – エージェント位置

2Dの世界を想像してみてください。エージェントは点 (-2,-2) におり、目的地は北東のどこかの点 (30, 20) にあり、エージェントがそこに到達するために必要なパスは (32, 22) です。これらの位置がメートル単位で測定されているとします。エージェントの速度を 5 メートル/秒とすると、変位ベクトルをスケーリングして、約 (4.12, 2.83) の速度が得られます。これらのパラメータを使用すると、エージェントはほぼ 8 秒で目的地に到着します。

値はいつでも再計算できます。エージェントがターゲットの半分にある場合、移動の長さは半分になりますが、エージェントの最大速度は 5 m/s (上記で決定しました) であるため、速度は同じになります。これは移動ターゲットにも機能し、エージェントが移動に応じて小さな変更を加えることができます。

ただし、より多くのバリエーションが必要です。たとえば、速度を徐々に上げて、キャラクターが立っている状態から走る状態に移行する様子をシミュレートします。最後に停止する前に同じことを行うことができます。これらの機能はステアリング動作として知られており、それぞれにシーク、逃走、到着などの特定の名前が付いています。そのアイデアは、エージェントの位置と現在の速度を目的地と比較することに基づいて、加速力をエージェントの速度に適用できるということです。ゴールに向かうためにさまざまな方法を使用するためです。

それぞれの動作にはわずかに異なる目的があります。シークと到着は、エージェントを目的地に移動する方法です。障害物の回避と分離は、ゴールに向かう途中の障害物を回避するためにエージェントの動きを調整します。連携と結束力により、エージェントは常に連携して行動できます。あらゆる要素を考慮して、任意の数の異なるステアリング動作を合計して、単一のパスベクトルを生成できます。到着、分離、障害物回避の動作を使用して壁や他のエージェントから遠ざかるエージェント。このアプローチは、不必要な詳細がないオープンな場所でうまく機能します。

より困難な状況では、さまざまな動作を追加すると、動作がさらに悪くなります。たとえば、到着と障害物回避の間の競合により、エージェントが壁にはまってしまう可能性があります。したがって、すべての値を単純に加算するよりも複雑なオプションを考慮する必要があります。その方法は次のとおりです。各行動の結果を合計する代わりに、さまざまな方向への動きを検討し、最適な選択肢を選択できます。

しかし、行き止まりや進むべき道についての選択肢がある複雑な環境では、さらに高度なものが必要になります。

方法を見つける

ステアリング動作は、A 地点から B 地点まで直線で移動し、障害物を迂回するだけのオープンエリア (サッカー場またはアリーナ) での単純な移動に最適です。複雑なルートの場合は、世界を探索し、その世界を通過するルートを決定する方法であるパスファインディングが必要です。

最も簡単な方法は、エージェントの隣の各正方形にグリッドを適用し、どのエージェントが移動できるかを評価することです。そのうちの XNUMX つが目的地の場合は、開始点に到達するまで、各マス目から前のマス目までのルートをたどります。これがルートです。それ以外の場合は、目的地が見つかるか、正方形がなくなるまで (ルート可能なルートがなくなるまで)、近くの他の正方形でこのプロセスを繰り返します。これは、正式には幅優先検索または BFS (幅優先検索アルゴリズム) として知られています。一歩ごとに、彼はあらゆる方向を見ます（したがって、幅、「幅」）。検索空間は、目的の位置に到達するまで移動する波面のようなものです。検索空間は、終点が含まれるまで各ステップで拡張され、その後は開始点まで追跡できます。

その結果、目的のルートがまとめられた正方形のリストが表示されます。これはパス (したがって、パスファインディング)、つまりエージェントが目的地をたどる際に訪れる場所のリストです。

世界のすべての正方形の位置がわかっているとすると、ステアリング動作を使用して、ノード 1 からノード 2、次にノード 2 からノード 3 など、パスに沿って移動できます。最も簡単なオプションは、次の正方形の中心に向かうことですが、さらに良いオプションは、現在の正方形と次の正方形の間の端の中央で停止することです。このため、エージェントは急な曲がり角でコーナーをカットすることができます。

BFS アルゴリズムには欠点もあります。BFS アルゴリズムは、「正しい」方向と同じ数の正方形を「間違った」方向にも探索します。ここで、A* (A スター) と呼ばれるより複雑なアルゴリズムが登場します。これも同様に機能しますが、隣接する正方形を盲目的に検査する代わりに (次に隣接する正方形の隣接、次に隣接の隣接の隣接の隣接など)、ノードをリストに収集し、次に検査されるノードが常にそのノードになるように並べ替えます。最短ルートにつながるもの。ノードは XNUMX つのことを考慮したヒューリスティックに基づいて並べ替えられます。それは、目的の広場までの仮想ルートの「コスト」 (移動コストを含む) と、その広場が目的地からどのくらい離れているかの推定値 (検索のバイアスになります) です。右方向）。

この例では、エージェントが一度に XNUMX つの正方形を探索し、そのたびに最も有望な隣接する正方形を選択することを示しています。結果のパスは BFS と同じですが、プロセスで考慮される正方形の数が減り、ゲームのパフォーマンスに大きな影響を与えます。

グリッドのない動き

しかし、ほとんどのゲームはグリッド上にレイアウトされておらず、リアリズムを犠牲にすることなくレイアウトするのは不可能なことがよくあります。妥協が必要です。正方形の大きさはどれくらいにすべきでしょうか？大きすぎると、小さな廊下や曲がり角を正しく表現できなくなります。小さすぎると、検索するマスが多すぎるため、最終的には時間がかかります。

まず理解すべきことは、メッシュは接続されたノードのグラフを提供するということです。 A* および BFS アルゴリズムは実際にはグラフ上で動作し、メッシュについてはまったく考慮しません。ゲーム世界のどこにでもノードを配置できます。接続された XNUMX つのノード間、および開始点と終了点と少なくとも XNUMX つのノードの間に接続がある限り、アルゴリズムは以前と同様に機能します。各ノードは、任意の数の仮想パスの一部となり得る世界内の重要な位置を表すため、これはウェイポイントシステムと呼ばれることがよくあります。

例 1: 各正方形の結び目。検索は、エージェントが配置されているノードから開始され、目的の正方形のノードで終了します。

例 2: より小規模なノード (ウェイポイント) のセット。検索はエージェントの広場から開始され、必要な数のノードを通過して、目的地まで続行されます。

これは完全に柔軟で強力なシステムです。ただし、ウェイポイントをどこにどのように配置するかを決定する際には注意が必要です。そうしないと、エージェントが最も近いポイントを認識できず、パスを開始できない可能性があります。世界の形状に基づいてウェイポイントを自動的に配置できれば、もっと簡単になるでしょう。

ここに、ナビゲーションメッシュまたは navmesh (ナビゲーションメッシュ) が表示されます。これは通常、エージェントが歩くことを許可されている世界のジオメトリにオーバーレイされる三角形の 2D メッシュです。メッシュ内の各三角形はグラフ内のノードになり、グラフ内の隣接ノードとなる隣接する三角形が最大 XNUMX つあります。

この画像は Unity エンジンの例です。このエンジンはワールドのジオメトリを分析し、ナビメッシュを作成しました (スクリーンショットでは水色)。ナビメッシュ内の各ポリゴンは、エージェントが立っているか、あるポリゴンから別のポリゴンに移動できるエリアです。この例では、ポリゴンはポリゴンが配置されているフロアよりも小さくなっています。これは、公称位置を超えて広がるエージェントのサイズを考慮するために行われます。

再び A* アルゴリズムを使用して、このメッシュを介してルートを検索できます。これにより、すべてのジオメトリを考慮し、不必要なノードやウェイポイントの作成を必要としない、世界でほぼ完璧なルートが得られます。

パスファインディングは広すぎるトピックなので、記事の XNUMX つのセクションでは十分ではありません。もっと詳しく調べたい場合は、これが役立ちますアミット・パテルのウェブサイト.

計画

私たちは経路探索を通じて、方向を選択して移動するだけでは不十分な場合があることを学びました。目的の目的地に到達するには、ルートを選択し、数回曲がる必要があるということです。この考え方は一般化できます。目標の達成は単なる次のステップではなく、最初のステップを見つけるためにいくつかのステップを先読みする必要がある一連の流れ全体です。これを計画といいます。パスファインディングは、計画のいくつかの拡張機能の XNUMX つと考えることができます。感覚/思考/行動サイクルの観点から見ると、ここは考える部分が将来に向けて複数の行動部分を計画する場所です。

ボードゲームの Magic: The Gathering の例を見てみましょう。まず、次のカードのセットを手に持っていきます。

沼 - 黒マナ（土地カード）を 1 つ与えます。
森 - 1 緑マナ (土地カード) を与えます。
逃亡者ウィザード - 召喚するには青マナが 1 必要です。
エルフの神秘家 - 召喚するには緑マナが 1 必要です。

簡単にするために、残りの 1 枚のカードは無視します。ルールによれば、プレイヤーはターンごとに1枚の土地カードをプレイすることができ、このカードを「タップ」してそこからマナを抽出し、マナの量に応じて呪文（クリーチャーの召喚を含む）を唱えることができます。この状況では、人間のプレイヤーは森をプレイし、緑マナを XNUMX 枚タップしてからエルフの神秘家を召喚する必要があることを知っています。しかし、ゲーム AI はどのようにしてこれを理解できるのでしょうか?

簡単な計画

簡単なアプローチは、適切なアクションがなくなるまで各アクションを順番に試していくことです。カードを見ることで、AI はスワンプが何をプレイできるかを判断します。そして彼はそれを演奏します。このターンに他にアクションは残っていますか? エルフの神秘家や逃亡者ウィザードを召喚するにはそれぞれ緑と青のマナが必要であるため、召喚することはできませんが、沼地は黒マナのみを提供します。そして、彼はすでにスワンプをプレイしているため、フォレストをプレイすることはできなくなります。したがって、ゲーム AI はルールに従いましたが、結果は不十分でした。改善できる。

計画では、ゲームを望ましい状態にするアクションのリストを見つけることができます。パス上のすべての正方形に (パスファインディングで) 隣接するものがあるのと同じように、計画内のすべてのアクションにも隣接するものまたは後継者があります。望ましい状態に到達するまで、これらのアクションとその後のアクションを探すことができます。

この例では、望ましい結果は「可能であればクリーチャーを召喚する」です。ターンの開始時に、ゲームのルールで許可されている可能なアクションは XNUMX つだけです。

1. Swamp をプレイする (結果: ゲーム内の Swamp)
2. 森をプレイする (結果: ゲーム内の森)

実行される各アクションは、ゲームのルールに応じて、さらなるアクションにつながり、他のアクションを閉じることができます。私たちが「沼」をプレイしたと想像してください。これにより、次のステップとして「沼」が削除され (すでにプレイ済みです)、また「森」も削除されます (ルールによれば、1 ターンに 1 枚の土地カードをプレイできるため)。この後、他に選択肢がないため、AI は次のステップとして黒マナを XNUMX つ獲得することを追加します。彼が先に進んで「沼地をタップ」を選択した場合、彼は黒マナを XNUMX 単位受け取り、それを使って何もすることができなくなります。

1. Swamp をプレイする (結果: ゲーム内の Swamp)
1.1 「タップ」沼地 (結果: 沼地が「タップ」され、+1 ユニットの黒マナ)
利用可能なアクションはありません - 終了
2. 森をプレイする (結果: ゲーム内の森)

行動のリストは短く、行き止まりに達しました。次のステップでこのプロセスを繰り返します。私たちは森をプレイし、「緑のマナを1つ獲得する」アクションを開始します。これにより、XNUMX番目のアクションが開始されます - エルフのミスティックを召喚します。

1. Swamp をプレイする (結果: ゲーム内の Swamp)
1.1 「タップ」沼地 (結果: 沼地が「タップ」され、+1 ユニットの黒マナ)
利用可能なアクションはありません - 終了
2. 森をプレイする (結果: ゲーム内の森)
2.1 森を「タップ」 (結果: 森が「タップ」され、+1 ユニットの緑マナ)
2.1.1 エルフのミスティックを召喚する (結果: エルフのミスティックが場にあり、-1 緑マナ)
利用可能なアクションはありません - 終了

最後に、私たちは考えられるすべてのアクションを検討し、クリーチャーを召喚する計画を見つけました。

これは非常に単純化された例です。いくつかの条件を満たすプランだけを選択するのではなく、可能な限り最適なプランを選択することをお勧めします。一般に、実行の結果や全体的な利点に基づいて、潜在的な計画を評価することが可能です。土地カードをプレイすると 1 ポイント、クリーチャーを召喚すると 3 ポイントを獲得できます。 Swamp をプレイすると 1 ポイントのプランになります。そして、森をプレイ→森をタップ→エルフの神秘家を召喚すると、すぐに4ポイントが与えられます。

これがマジック:ザ・ギャザリングにおける計画の仕組みですが、同じロジックが他の状況にも当てはまります。たとえば、チェスでビショップが移動できるスペースを作るためにポーンを移動します。または、このように XCOM で安全に撮影するために壁の後ろに隠れてください。一般的には、アイデアはわかります。

計画の改善

場合によっては、考えられるアクションが多すぎて、すべての可能なオプションを検討することができません。マジック：ザ・ギャザリングの例に戻ります。ゲーム内と手札に数枚の土地とクリーチャーのカードがあるとします。可能な動きの組み合わせの数は数十に及ぶ可能性があります。この問題にはいくつかの解決策があります。

XNUMX つ目の方法は、後方連鎖です。すべての組み合わせを試すのではなく、最終結果から始めて直接的なルートを見つけることをお勧めします。木のルートから特定のリーフに移動するのではなく、逆方向、つまりリーフからルートに移動します。この方法の方が簡単かつ迅速です。

敵の体力が 1 の場合、「1 以上のダメージを与える」プランを見つけることができます。これを達成するには、次のような多くの条件を満たす必要があります。

1. ダメージは呪文によって引き起こされる可能性があります - それは手札にある必要があります。
2. 呪文を唱えるにはマナが必要です。
3. マナを獲得するには、土地カードをプレイする必要があります。
4. 土地カードをプレイするには、それが手札にある必要があります。

もう XNUMX つの方法は、最良優先検索です。すべてのパスを試す代わりに、最も適切なパスを選択します。ほとんどの場合、この方法により、不必要な検索コストを発生させずに最適なプランが得られます。 A* は最良の最初の検索の形式です。最初から最も有望なルートを調べることで、他のオプションをチェックすることなく、すでに最適なパスを見つけることができます。

興味深く人気が高まっているベストファースト検索オプションは、モンテカルロツリー検索です。後続の各アクションを選択するときに、どの計画が他の計画よりも優れているかを推測するのではなく、アルゴリズムは、最後に到達する (計画の結果が勝利または敗北したとき) まで、各ステップでランダムな後続者を選択します。最終結果は、前のオプションの重みを増減するために使用されます。このプロセスを連続して数回繰り返すことにより、状況が変化した場合でも (敵がプレイヤーを妨害する行動を取った場合でも)、アルゴリズムは最適な次の動きを適切に推定します。

ゲームの計画に関するストーリーは、目標指向アクションプランニングまたは GOAP (目標指向アクションプランニング) なしには完成しません。これは広く使用され、議論されている方法ですが、いくつかの特徴的な詳細を除けば、本質的には前に説明した逆方向連鎖方法です。目的が「プレイヤーを破壊する」で、プレイヤーが物陰に隠れている場合、計画は次のようになります: 手榴弾で破壊→入手→投げる。

通常、複数の目標があり、それぞれに独自の優先順位があります。最も優先度の高い目標を完了できない場合（プレイヤーが見えないため、アクションの組み合わせによって「プレイヤーを殺す」計画が作成されない場合）、AI は優先度の低い目標に戻ります。

トレーニングと適応

ゲーム AI はエージェントをリアルタイムで管理するのに適していないため、通常は機械学習を使用しないとすでに述べました。ただし、この地域から何かを借りることができないという意味ではありません。私たちはシューターにおいて、何かを学ぶことができる対戦相手を望んでいます。たとえば、地図上で最適な位置を見つけます。または、格闘ゲームで、プレイヤーが頻繁に使用するコンボ技をブロックし、他の技を使うよう仕向ける対戦相手。したがって、機械学習はそのような状況で非常に役立ちます。

統計と確率

複雑な例に入る前に、いくつかの簡単な測定を行い、それを使用して意思決定を行うことで、どこまでできるかを見てみましょう。たとえば、リアルタイム戦略 - プレーヤーがゲームの最初の数分間に攻撃を開始できるかどうか、またこれに対してどのような防御を準備すべきかをどのように判断するのでしょうか? プレイヤーの過去の経験を研究して、将来の反応がどのようなものになるかを理解することができます。そもそも、私たちはそのような生データを持っていませんが、それを収集することはできます。AIが人間と対戦するたびに、最初の攻撃の時間を記録できます。いくつかのセッションの後、プレイヤーが今後攻撃するのにかかる平均時間を取得します。

平均値にも問題があります。プレイヤーが 20 回急いで 20 回ゆっくりとプレイした場合、必要な値は中間のどこかになり、これでは何も役に立ちません。解決策の 20 つは、入力データを制限することです。最後の XNUMX 個が考慮されます。

プレイヤーの過去の好みが将来も同じであると仮定して、特定のアクションの可能性を推定するときにも同様のアプローチが使用されます。プレイヤーがファイアボールで 62,5 回、稲妻で 25 回、近接攻撃で 12,5 回攻撃した場合、そのプレイヤーがファイアボールを好むことは明らかです。さまざまな武器を使用する確率を推定して見てみましょう: ファイアボール = XNUMX%、ライトニング = XNUMX%、近接 = XNUMX%。ゲーム AI は火災から身を守る準備をする必要があります。

もう XNUMX つの興味深い方法は、単純ベイズ分類器を使用して大量の入力データを調査し、AI が望ましい方法で反応するように状況を分類することです。ベイジアン分類器は、電子メールのスパムフィルターでの使用で最もよく知られています。そこで彼らは単語を調べ、その単語が以前に出現した場所 (スパム内かどうか) と比較し、受信メールに関する結論を導き出します。入力が少なくても同じことができます。 AI が認識するすべての有用な情報 (どのような敵ユニットが作成されるか、どのような呪文を使用するか、どのようなテクノロジーが研究されたかなど) と最終結果 (戦争か平和か、突撃か防御かなど) に基づいて決定されます。 - 希望する AI の動作を選択します。

これらのトレーニング方法はすべて十分ですが、テストデータに基づいて使用することをお勧めします。 AI は、プレイテスターが使用したさまざまな戦略に適応することを学習します。リリース後にプレイヤーに適応する AI は、予測しすぎたり、倒すのが困難になったりする可能性があります。

価値観に基づく適応

ゲーム世界の内容とルールを考慮すると、単に入力データを使用するだけでなく、意思決定に影響を与える一連の値を変更できます。私たちはこれを行います:

AI に世界の情勢とゲーム中の主要なイベントに関するデータを収集させます (上記と同様)。
このデータに基づいて、いくつかの重要な値を変更してみましょう。
当社は、これらの値の処理または評価に基づいて決定を実行します。

たとえば、エージェントは一人称シューティングゲームのマップ上でいくつかの部屋から選択できます。各部屋には独自の価値があり、それによって訪問する価値が決まります。 AIはその値に基づいてどの部屋に行くかをランダムに選択します。次に、エージェントは自分がどの部屋で殺されたかを記憶し、その価値 (彼がそこに戻る確率) を減らします。逆の状況でも同様です。エージェントが多くの対戦相手を破壊した場合、ルームの価値は増加します。

マルコフモデル

収集したデータを使用して予測を行ったらどうなるでしょうか? 一定期間にプレイヤーを見たすべての部屋を覚えていれば、プレイヤーがどの部屋に行くかを予測できます。部屋間でのプレイヤーの動き (値) を追跡および記録することで、それらを予測できます。

赤、緑、青の XNUMX つの部屋を考えてみましょう。また、ゲームセッションを観察しながら記録した観察結果も以下のとおりです。

各部屋の観測数はほぼ同じですが、どこに待ち伏せに適した場所を作るかはまだわかりません。統計の収集は、マップ全体に均等に出現するプレイヤーのリスポーンによっても複雑になります。しかし、地図上に表示された後に次に入る部屋に関するデータはすでに役に立ちます。

緑の部屋がプレイヤーに適していることがわかります。ほとんどの人は赤い部屋からそこに移動し、そのうちの 50% はさらにそこに残ります。逆に青い部屋は人気がなく、ほとんど誰も行かず、行っても長居はしません。

しかし、データはもっと重要なことを教えてくれます。プレイヤーが青い部屋にいるとき、次に彼がいる部屋は緑ではなく赤になるということです。赤い部屋よりも緑の部屋の方が人気がありますが、プレイヤーが青い部屋にいる場合は状況が変わります。次の状態 (つまり、プレーヤーが行く部屋) は、前の状態 (つまり、プレーヤーが現在いる部屋) によって異なります。依存関係を調査するため、単に観測値を独立してカウントする場合よりも正確な予測が可能になります。

過去の状態のデータに基づいて将来の状態を予測することはマルコフモデルと呼ばれ、そのような例 (ルーム付き) はマルコフ連鎖と呼ばれます。パターンは連続する状態間の変化の確率を表すため、各遷移の周囲の確率を持つ FSM として視覚的に表示されます。以前は、エージェントの動作状態を表すために FSM を使用していましたが、この概念は、エージェントに関連付けられているかどうかに関係なく、あらゆる状態に拡張されます。この場合、状態はエージェントが占める部屋を表します。

これは状態変化の相対的な可能性を表す簡単な方法であり、AI に次の状態を予測する能力を与えます。数歩先を予測することができます。

プレーヤーがグリーンルームにいる場合、次に観察されたときにそのプレーヤーがそこに留まる可能性は 50% です。しかし、その後も彼がまだそこにいる可能性はどのくらいでしょうか？プレーヤーがXNUMX回の観察後にグリーンルームに残った可能性だけでなく、退出して戻った可能性もある。新しいデータを考慮した新しいテーブルは次のとおりです。

これは、51 回の観察後に緑の部屋でプレーヤーを見る確率は 21% に等しく、彼が赤い部屋から来る確率は 5%、そのうちの 25% はプレーヤーがそれらの間の青い部屋を訪れる確率であることを示しています。プレーヤーがグリーンルームから出ない場合は XNUMX% です。

表は単なる視覚的なツールです。この手順では、各ステップで確率を乗算するだけで済みます。これは、XNUMX つの注意点を除いて、遠い将来を見ることができることを意味します。部屋に入る可能性は、現在の部屋に完全に依存すると想定しています。これはマルコフ特性と呼ばれます。将来の状態は現在にのみ依存します。しかし、これは XNUMX パーセント正確ではありません。プレイヤーは、健康レベルや弾薬の量など、他の要因に応じて決定を変更できます。これらの値は記録されないため、予測の精度は低くなります。

Nグラム

格闘ゲームの例で、プレイヤーのコンボ技を予測する場合はどうでしょうか? 同じ！ただし、XNUMX つの状態やイベントではなく、コンボストライクを構成するシーケンス全体を調べます。

これを行う XNUMX つの方法は、各入力 (キック、パンチ、ブロックなど) をバッファーに保存し、バッファー全体をイベントとして書き込むことです。そのため、プレイヤーはキック、キック、パンチを繰り返し押して SuperDeathFist 攻撃を使用すると、AI システムはすべての入力をバッファーに保存し、各ステップで使用された最後の XNUMX つを記憶します。

(太線はプレイヤーが SuperDeathFist 攻撃を開始したときのものです。)

プレイヤーがキックを選択し、続いて別のキックを選択すると、AI はすべてのオプションを確認し、次の入力が常にパンチであることに気づきます。これにより、エージェントは SuperDeathFist のコンボ動作を予測し、可能であればブロックすることができます。

これらの一連のイベントは N グラムと呼ばれます。N は格納される要素の数です。前の例では、それは 3 グラム (トライグラム) でした。これは、最初の 5 つのエントリが XNUMX 番目のエントリを予測するために使用されることを意味します。したがって、XNUMX グラムでは、最初の XNUMX つのエントリが XNUMX 番目のエントリなどを予測します。

設計者は N グラムのサイズを慎重に選択する必要があります。 N が小さいほど、必要なメモリは少なくなりますが、保存される履歴も少なくなります。たとえば、2グラム（バイグラム）はキック、キック、またはキック、パンチを記録しますが、キック、キック、パンチを保存することはできないため、AIはSuperDeathFistコンボに反応しません。

一方で、数値が大きいほど多くのメモリが必要となり、可能なオプションがより多くなるため、AI のトレーニングがより困難になります。キック、パンチ、ブロックの 10 つの可能な入力があり、60 グラムを使用した場合、約 XNUMX の異なるオプションになります。

バイグラムモデルは単純なマルコフ連鎖です。過去の状態と現在の状態の各ペアはバイグラムであり、最初の状態に基づいて 3 番目の状態を予測できます。 XNUMX グラム以上の N グラムはマルコフ連鎖と考えることもでき、すべての要素 (N グラムの最後の要素を除く) が一緒になって最初の状態を形成し、最後の要素が XNUMX 番目の状態を形成します。格闘ゲームの例では、キック＆キック状態からキック＆パンチ状態に移行する可能性を示しています。複数の入力履歴エントリを XNUMX つのユニットとして扱うことにより、基本的に入力シーケンスを状態全体の一部に変換します。これによりマルコフプロパティが得られ、マルコフチェーンを使用して次の入力を予測し、次にどのようなコンボの動きになるかを推測できるようになります。

まとめ

人工知能の開発における最も一般的なツールとアプローチについて話しました。また、それらを使用する必要がある状況と、特に役立つ状況についても検討しました。

ゲーム AI の基本を理解するにはこれで十分です。しかし、もちろん、これらがすべての方法ではありません。あまり人気はありませんが、効果が劣らないものには次のようなものがあります。

山登り、勾配降下、遺伝的アルゴリズムを含む最適化アルゴリズム
敵対的検索/スケジューリングアルゴリズム (ミニマックスおよびアルファベータプルーニング)
分類方法 (パーセプトロン、ニューラルネットワーク、サポートベクターマシン)
エージェントの知覚と記憶を処理するシステム
AI へのアーキテクチャ的アプローチ (ハイブリッドシステム、サブセットアーキテクチャ、および AI システムをオーバーレイするその他の方法)
アニメーションツール（プランニングとモーション調整）
パフォーマンス要素 (詳細レベル、いつでも、タイムスライスアルゴリズム)

ゲーム AI の作成方法: 初心者向けガイド