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

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

ほとんどの例は疑似コードで書かれているので、深いプログラミング知識は必要ありません。カットの下には写真と GIF を含む 35 ページのテキストがありますので、準備してください。

更新しました。申し訳ありませんが、私はすでにこの記事をHabrで翻訳しています。 ペイシェントゼロ。彼のバージョンを読むことができます ここで、しかし、何らかの理由で、その記事を見逃してしまいました（検索を使用しましたが、何か問題が発生しました）。私はゲーム開発に特化したブログを書いているので、購読者向けに独自の翻訳バージョンを残すことにしました (いくつかの点は異なる形式で表記し、開発者のアドバイスに従って意図的に省略した部分もあります)。

AIとは

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

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

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

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

ゲームAIの限界

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

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

感知/思考/行動サイクル全体にわたる AI アプローチを見てみましょう。

基本的な意思決定

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

条件演算子

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

擬似コードで記述された、このための簡単なアルゴリズムは次のとおりです。

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

プラットフォームがボールの速度で動く場合、これは Pong の AI に最適なアルゴリズムです。エージェントのデータや実行可能なアクションがそれほど多くない場合は、複雑にする必要はありません。

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

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

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

決定木

Pong の例は、実際には決定木と呼ばれる正式な AI 概念に相当します。アルゴリズムはそれを調べて「葉」に到達し、どのようなアクションを取るかを決定します。

プラットフォームのアルゴリズムの決定木フローチャートを作成しましょう。

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

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

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

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

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

決定木は、大量の例から自動的に構築される場合（たとえば、ID3 アルゴリズムを使用）に非常に便利です。これにより、受信したデータに基づいて状況を分類するための効率的で高性能なツールになります。ただし、エージェントがアクションを選択するための単純なシステムを超えています。

シナリオ

事前に定義された条件とアクションを使用する意思決定ツリー システムを検討しました。 AI を設計する人はツリーを好きなように配置できますが、それでもすべてをプログラムしたコーダーに頼る必要があります。デザイナーに独自の条件やアクションを作成するツールを提供できたらどうなるでしょうか?

プログラマーが「ボールはパドルの左側にあるか」および「ボールはパドルの右側にあるか」の条件のコードを記述しなくても済むように、設計者がこれらの値をチェックする条件を記述するシステムを作成できます。すると、決定木データは次のようになります。

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

この例では、スクリプト言語は条件式の評価にのみ使用されていますが、アクションにも使用できます。たとえば、「Move Paddle Right」データはスクリプト ステートメント (ball.position.x += 10) になります。これにより、Move Paddle Right をプログラムする必要なく、アクションもスクリプトで定義されます。

さらに進んで、決定木全体をスクリプト言語で記述することもできます。これはハードコードされた条件文の形式のコードですが、外部スクリプト ファイル内にあるため、プログラム全体を再コンパイルせずに変更できます。多くの場合、プレイ中にスクリプト ファイルを変更して、さまざまな AI の反応をすばやくテストできます。

出来事への反応

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

敵がプレイヤーを見つけるまでは動かず、その後は「専門分野」に応じて行動するシューティングゲームを想像してください。敵の中には走って「突進」するものもいれば、遠くから攻撃するものもいます。これは依然として基本的な反応システム (「プレイヤーが見られたら何かする」) ですが、論理的には「プレイヤーが見られた場合」イベントと反応 (応答を選択して実行する) に分割できます。

ここでSense/Think/Actループに戻ります。AIがプレイヤーを視認しているかどうかを毎フレーム確認するSenseパートをコーディングできます。視認していない場合は何も起こりませんが、視認している場合はPlayer Seenイベントを発生させます。コードには「Player Seenイベントが発生したら、実行する」という独立したセクションがあり、そこにThinkパートとActパートを呼び出すための答えが記述されます。つまり、Player Seenイベントに対する反応を設定します。突進するキャラクターの場合はChargeAndAttack、スナイパーの場合はHideAndSnipeです。これらの接続はデータファイルで作成できるため、再コンパイルせずに簡単に編集できます。また、ここでスクリプト言語を使用することもできます。

難しい決断を下す

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

有限状態機械

有限状態マシン (FSM) は、エージェントが現在複数の可能な状態のうちの 1 つにあり、ある状態から別の状態に遷移できることを示す方法です。そのような状態が一定数存在するため、この名前が付けられています。人生における最良の例は信号機です。場所によって信号の順序は異なりますが、原則は同じです。つまり、それぞれの状態は何かを表します (停止、進むなど)。信号機は、ある時点では 1 つの状態のみにあり、単純なルールに基づいて状態が切り替わります。

ゲーム内の NPC でも同様です。例として、次の状態を持つガードを見てみましょう。

• パトロール中。
• 攻撃。
• 逃げる。

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

• 警備員は敵を見つけると攻撃します。
• 警備員が攻撃しても敵が見えなくなった場合は、巡回に戻ります。
• 警備員が攻撃して重傷を負った場合、逃げます。

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

• 怠惰 - パトロールの合間。
• 捜索中 - 発見した敵が消えたとき。
• 助けを求める - 敵を発見したが、単独で戦うには強すぎる場合。

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

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

これは状態遷移表であり、FSM を表現する複雑な方法です。図を描いて、NPC の動作がどのように変化するかを完全に把握してみましょう。

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

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

これは状態間の遷移を処理しますが、状態自体に関連付けられた動作についてはどうでしょうか?特定の状態に対する実際の動作を実装する場合、通常、FSM にアクションを割り当てる「フック」には 2 種類あります。

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

最初のタイプの例。パトロール状態では、エージェントはフレームごとにパトロール ルートに沿って移動します。攻撃状態では、毎フレーム攻撃を開始したり、攻撃が可能な状態に移行したりしようとします。

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

もう一度、このシステムを「感知/思考/行動」サイクルの観点から見てみましょう。センスは、遷移ロジックによって使用されるデータに具体化されます。考えてみましょう — 各状態で利用可能な遷移。そして、Act は、状態内または状態間の遷移時に定期的に実行されるアクションによって実行されます。

遷移条件の継続的なポーリングはコストがかかる場合があります。たとえば、各エージェントが敵を見ることができるかどうか、パトロールから攻撃に移行できるかどうかを判断するためにフレームごとに複雑な計算を実行すると、CPU 時間が大量にかかります。

世界の状態における重要な変化は、発生するとすぐに処理されるイベントと考えることができます。 FSM に「エージェントはプレーヤーを見ることができますか?」と確認させる代わりに、フレームごとに遷移条件をチェックするのではなく、別のシステムを設定して、より低い頻度（たとえば、5 秒あたり XNUMX 回）でチェックすることもできます。チェックに合格したら、Player Seen を結果として返します。

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

階層型有限状態マシン

ただし、大規模な FSM での作業は必ずしも便利ではありません。攻撃状態を拡張して MeleeAttacking と RangedAttacking を別々にしたい場合は、攻撃状態につながる他のすべての状態 (現在および将来) からの遷移を変更する必要があります。

この例では、重複した遷移が多数あることに気付いたかもしれません。アイドリング状態のほとんどの遷移は、パトロール状態の遷移と同一です。特に、同様の状態をさらに追加する場合は、同じことを繰り返さない方がよいでしょう。アイドリングとパトロールを「非戦闘」という一般的なラベルの下にグループ化するのは理にかなっています。戦闘状態への移行には共通のセットが 1 つだけあります。このラベルを状態と考えると、Idling と Patrolling がサブ状態になります。新しい非戦闘サブステートに別の遷移テーブルを使用する例:

主な州:


戦闘外のステータス:


図で表すと次のようになります。

同じシステムですが、アイドリングやパトロールを含む新しい非戦闘状態が追加されています。各状態にサブ状態を持つ FSM が含まれ (さらにこれらのサブ状態には独自の FSM が含まれるなど、必要に応じてこれも同様)、階層型有限状態マシン (HFSM) が得られます。非戦闘状態をグループ化することで、冗長な遷移を多数削減しました。共通の遷移を持つ新しい状態に対しても同じことを行うことができます。たとえば、将来的に Attacking 状態を MeleeAttacking 状態と MissileAttacking 状態に拡張すると、それらは敵までの距離と弾薬の有無に基づいて相互に遷移するサブ状態になります。その結果、最小限の重複した遷移で複雑な動作モデルと動作のサブモデルを表現できるようになります。

行動ツリー

HFSM を使用すると、複雑な動作の組み合わせが簡単な方法で作成されます。ただし、遷移ルール​​の形での意思決定は、現在の状態と密接に関係しているという若干の難しさがあります。そして多くのゲームでは、まさにそれが必要なのです。また、状態階層を慎重に使用することで、遷移中の繰り返しの量を減らすことができます。しかし、時には、どの州にいても機能するルール、またはほぼすべての州に適用されるルールが必要になることがあります。たとえば、エージェントの体力が 25% まで低下した場合、エージェントが戦闘中、アイドル状態、または会話中であるかどうかに関係なく、エージェントが逃げるようにしたいとします。この条件を各状態に追加する必要があります。そして、デザイナーが後から低体力しきい値を 25% から 10% に変更したい場合、すべてをやり直す必要があります。

理想的には、この状況では、「どの状態になるか」に関する決定が状態自体の外部で行われ、変更は 1 か所でのみ行う必要があり、遷移条件に影響を与えないシステムが必要です。ここで動作ツリーが登場します。

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

• ノードは、成功 (作業が完了した場合)、失敗 (実行できない場合)、実行中 (まだ実行中で最終結果がない場合) の 3 つの値のいずれかを返すようになりました。
• 2 つの選択肢から選択するための決定ノードはなくなりました。代わりに、1 つの子ノードを持つ Decorator ノードがあります。成功した場合、唯一の子ノードを実行します。
• アクションを実行するノードは、実行中のアクションを表す実行値を返します。

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

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

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

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

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

ゲームによっては、さまざまなメカニズムを持つものもあります。シンプルで一般的な遷移ルール​​の利点をすべて得ることが望ましいですが、必ずしも完全な動作ツリーを得る必要はありません。明確な選択肢や実行可能なアクションのツリーを用意する代わりに、すべてのアクションを調べて、その時点で最も適切なアクションを選択する方が簡単です。

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

エージェントは現在の状態と環境に基づいてアクションの有用性を計算し、いつでも最も適切な他の状態をチェックして選択できます。これは FSM に似ていますが、現在の状態を含む各潜在的な状態の評価によって遷移が決定される点が異なります。次に進む（または、すでに完了している場合はそのまま進む）最も有用なアクションを選択することに注意してください。より多様性を持たせるには、小さなリストから慎重にランダムに選択することもできます。

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

アクション間の遷移はあいまいです。つまり、どの状態も他の状態に続く可能性があります。アクションの優先順位は、返されるユーティリティ値にあります。敵が見えていて、その敵が強く、キャラクターの体力が低い場合、Fleeing と FindingHelp の両方がゼロ以外の高い値を返します。 FindingHelp は常に上位になります。同様に、非戦闘アクションは 50 を超える値を返すことはないため、常に戦闘アクションよりも低くなります。アクションを作成し、その有用性を計算するときは、これを考慮する必要があります。

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

各アクションにはプログラム計算のための多くの条件があります。これらはスクリプト言語で記述することも、一連の数式として記述することもできます。キャラクターの日常生活をモデル化する「ザ・シムズ」では、計算のレベルがさらに追加され、エージェントはユーティリティ スコアに影響を与えるいくつかの「動機」を受け取ります。キャラクターが空腹の場合、時間の経過とともに空腹度が増し、EatFood アクションの有用性は、キャラクターがアクションを完了するまで増加し、空腹レベルが下がり、EatFood 値がゼロに戻ります。

評価システムに基づいてアクションを選択するというアイデアは非常にシンプルなので、ユーティリティベースのシステムは、AI の意思決定プロセスを完全に置き換えるのではなく、その一部として使用できます。決定木は、2 つの子ノードからユーティリティ スコアを要求し、より高いスコアを選択する場合があります。同様に、動作ツリーには、アクションのユーティリティを評価してどの子を実行するかを決定するユーティリティ複合ノードが含まれる場合があります。

移動とナビゲーション

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

Управление

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

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

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

いつでも値を再計算できます。エージェントがゴールの半分まで来た場合、移動距離は半分になりますが、エージェントの最大速度は 5 m/s なので (これは上で決定しました)、速度は同じになります。これは移動するターゲットにも機能し、エージェントは移動しながら小さな調整を行うことができます。

しかし、もっとバリエーションが欲しいです。例えば、ゆっくりと速度を上げて、キャラクターが立った状態から走る状態に移行する様子をシミュレートしたいのです。停止する前に同じことを最後に実行できます。これらの機能はステアリング動作と呼ばれ、それぞれに特定の名前が付けられています: 探索、逃走、到着など。エージェントの位置と現在の速度を目的地と比較し、加速力をエージェントの速度に適用して、目標に向かって移動するさまざまな方法を使用するという考え方です。

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

より困難な状況では、異なる動作の組み合わせはうまく機能しません。たとえば、エージェントは、到着と障害物回避の競合により壁に引っかかってしまう可能性があります。したがって、すべての値を単純に合計するよりも複雑なオプションを考慮する必要があります。その方法は、各動作の結果を合計するのではなく、さまざまな方向の動きを考慮して、最適なオプションを選択することです。

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

方法を見つける

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

最も単純な方法は、エージェントの近くの各マスにグリッドを配置し、どのエージェントが移動できるかを推定することです。いずれかのマスが目的地である場合は、各マスから前のマスまでのルートをたどってスタート地点に到達します。これがルートです。それ以外の場合は、目的地が見つかるか、マス目がなくなる（つまり、可能なルートがない）まで、最も近い他のマス目でこのプロセスを繰り返します。これは正式には幅優先探索または BFS (幅優先探索アルゴリズム) として知られています。彼は一歩ごとにあらゆる方向を見ています（したがって、幅は「広さ」です）。検索空間は、目的の場所に到達するまで移動する波面のようなものです。検索領域は各ステップで拡大し、終点に到達したら、開始点に戻る経路をたどることができます。

その結果、必要なルートが作成される正方形のリストが表示されます。これはパス（つまりパスファインディング）であり、エージェントが目的地に向かう途中で訪れる場所のリストです。

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

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

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

グリッドのない動き

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

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

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

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

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

ここで、ナビゲーション メッシュまたは navmesh が登場します。これは通常、エージェントが歩行できる場所であればどこでも、ワールド ジオメトリに重ねられる三角形の 2D グリッドです。グリッド内の各三角形はグラフ内のノードになり、最大 XNUMX つの隣接する三角形があり、グラフ内の隣接ノードになります。

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

A* アルゴリズムを再度使用して、このグリッドを通るルートを見つけることができます。これにより、すべてのジオメトリを考慮し、不要なノードやウェイポイントを必要としない、世界中でほぼ完璧なルートが得られます。

パスファインディングは、記事の 1 つのセクションだけでカバーするには広すぎるトピックです。もっと詳しく勉強したいなら、これが役に立つでしょう アミット・パテルのウェブサイト.

計画

パスファインディングでは、方向を選択して移動するだけでは十分ではない場合があることがわかりました。目的地に到達するには、ルートを選択して数回曲がる必要があります。この考え方を一般化することができます。目標を達成することは、次のステップだけではなく、一連の流れ全体であり、最初のステップが何であるかを判断するために、いくつかのステップを先読みする必要がある場合もあります。それは計画と呼ばれます。パスファインディングは、いくつかの計画アドオンの 1 つと考えることができます。 Sense/Think/Act サイクルの観点から言えば、これは Think 部分が将来に向けて複数の Act 部分を計画する場所です。

ボードゲーム「マジック：ザ・ギャザリング」の例を見てみましょう。私たちは最初に以下のカードセットを手にして行動します:

• 沼 - 黒マナ 1 点 (土地カード) を与えます。
• 森 - 緑マナ 1 点 (土地カード) を与えます。
• 逃亡魔法使い - 召喚するには青マナが 1 個必要です。
• エルフの神秘家 - 召喚するには緑マナが 1 個必要です。

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

シンプルな計画

単純なアプローチは、適切なアクションがなくなるまで各アクションを順番に試すことです。 AIはカードを見て、Swampがプレイできると認識します。そしてそれを演奏します。このターンに他に何かアクションは残っていますか?彼は《エルフの神秘家》や《逃亡者の魔術師》を召喚することができません。召喚するにはそれぞれ緑と青のマナが必要ですが、《沼》は黒マナしか提供しないからです。そして、彼はすでに沼をプレイしているので、もう森をプレイすることはできません。つまり、ゲーム AI はルールに従いましたが、うまく実行できませんでした。改善の余地あり。

計画により、ゲームを望ましい状態にするためのアクションのリストを見つけることができます。パス上のすべてのマス目に隣接するマス目があるのと同様に (パスファインディングにおいて)、プラン内のすべてのアクションにも隣接するマス目または後続のマス目があります。目的の状態に到達するまで、これらのアクションと後続のアクションを検索できます。

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

1. 沼をプレイする（結果：沼がプレイ中）
2. Forest をプレイ (結果: Forest がプレイ中)

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

1. 沼をプレイする（結果：沼がプレイ中）
1.1 沼を「タップ」する (結果: 沼は「タップ」され、黒マナ +1)
利用可能なアクションはありません - 終了
2. Forest をプレイ (結果: Forest がプレイ中)

行動のリストが短かったため、行き詰まりに陥りました。次のアクションのためにこのプロセスを繰り返します。私たちは Forest をプレイし、「緑マナを 1 個得る」アクションを開始します。これにより、XNUMX 番目のアクションである「エルフの神秘家を召喚する」アクションが開始されます。

1. 沼をプレイする（結果：沼がプレイ中）
1.1 沼を「タップ」する (結果: 沼は「タップ」され、黒マナ +1)
利用可能なアクションはありません - 終了
2. Forest をプレイ (結果: Forest がプレイ中)
2.1 森を「タップ」する (結果: 森は「タップ」され、緑マナ +1)
2.1.1 エルフの神秘家を召喚する (結果: エルフの神秘家が場に出る、緑マナ -1)
利用可能なアクションはありません - 終了

最終的に、私たちはすべての可能なアクションを検討し、クリーチャーを召喚する計画を見つけました。

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

これがマジック：ザ・ギャザリングでの計画の仕組みですが、同じロジックが他の状況にも当てはまります。たとえば、チェスでポーンを動かしてビショップを動かすスペースを作ることなどです。または、このように壁の後ろに隠れて、XCOM を安全に撃つこともできます。とにかく、その考えは理解できるでしょう。

計画の改善

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

最初の方法は後方連鎖です。すべての組み合わせを試すのではなく、最終結果から始めて直接的なルートを見つける方がよいでしょう。木の根元から特定の葉へ進むのではなく、反対方向、つまり葉から根元へ進みます。この方法はより簡単かつ高速です。

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

1. ダメージは呪文によって与えることができます。呪文は手札になければなりません。
2. 呪文を唱えるにはマナが必要です。
3. マナを得るには、土地カードをプレイする必要があります。
4. 土地カードをプレイするには、そのカードを手札に持っている必要があります。

もう一つの方法は、最良優先検索です。すべてのパスを試すのではなく、最も適切なパスを選択します。ほとんどの場合、この方法は不必要な検索コストをかけずに最適なプランを提供します。 A* は最良優先探索の一種です。最初から最も有望なルートを探索することで、他のオプションを確認しなくても最適なパスを見つけることができます。

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

ゲームの計画に関する議論は、目標指向アクション計画 (GOAP) なしでは完結しません。これは広く使用され、議論されている方法ですが、いくつかの特徴的な詳細を除けば、基本的には先ほど説明した後方連鎖法と同じです。目的が「プレイヤーを殺す」ことであり、プレイヤーがカバーの後ろにいる場合、計画は「手榴弾で殺す → 手榴弾を手に入れる → 手榴弾を投げる」となるかもしれません。

通常、複数の目標があり、それぞれに優先順位が付けられています。最も優先度の高いターゲットを完了できない場合 (プレイヤーが見えないため、アクションの組み合わせで「プレイヤーを殺す」計画が作成されない)、AI は優先度の低いターゲットにフォールバックします。

トレーニングと適応

すでに述べたように、ゲーム AI では、エージェントをリアルタイムで制御するのに適していないため、通常は機械学習は使用されません。しかし、これはこの地域から何かを借りることができないという意味ではありません。シューティングゲームでは、何かを学べる相手が欲しいです。たとえば、地図上の最適な位置を調べます。あるいは、格闘ゲームでプレイヤーが頻繁に使用するコンボ技をブロックし、他の技を使用するように動機付ける対戦相手もいます。したがって、このような状況では機械学習が非常に役立ちます。

統計と確率

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

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

プレイヤーの過去の好みが将来も同じであると仮定して、特定のアクションの可能性を評価するときにも同様のアプローチが使用されます。プレイヤーが火の玉で 62,5 回、雷で 25 回、近接攻撃で 12,5 回攻撃した場合、そのプレイヤーが火の玉を好むのは明らかです。さまざまな武器を使用する確率を推測してみましょう: 火の玉 = XNUMX%、稲妻 = XNUMX%、近接攻撃 = XNUMX%。私たちのゲーム AI は火災防御に備える必要があります。

もうひとつの興味深い方法は、大量の入力データを見て状況を分類し、AI が適切に対応できるようにする、単純ベイズ分類器を使うことです。ベイズ分類器は、電子メールのスパム フィルターでの使用で最もよく知られています。そこで、単語を調べ、それらの単語が以前に出現した場所（スパムかどうかにかかわらず）と比較し、受信メールに関する結論を導き出します。入力データが少ない場合でも、同じことを行うことができます。 AI が見るすべての有用な情報 (作成された敵ユニット、使用する呪文、研究した技術など) と最終結果 (戦争か平和か、突撃か防御かなど) に基づいて、望ましい AI の動作を選択します。

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

価値に基づく適応

ゲームの世界の内容とルールを考慮すると、入力データを使用するだけでなく、決定に影響を与える値のセットを変更できます。次のようにしてみましょう:

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

たとえば、エージェントは一人称視点のシューティング マップ上で複数の部屋から選択できます。各部屋には独自の価値があり、それによって訪問する価値が決まります。 AIは値に基づいてどの部屋に行くかをランダムに選択します。エージェントは自分がどの部屋で殺されたかを記憶し、その部屋の価値（自分がそこに戻る可能性）を減らします。逆の状況でも同様です。エージェントが多くの敵を倒すと、部屋の価値が高まります。

マルコフモデル

収集したデータを使用して予測を行うとどうなるでしょうか?一定期間にわたってプレイヤーがいるすべての部屋を記憶しておけば、プレイヤーがどの部屋に移動するかを予測できます。部屋（値）間でのプレイヤーの動きを追跡して記録することで、それを予測することができます。

赤、緑、青の 3 つの部屋を見てみましょう。また、ゲームセッションを観戦しながら記録した観察事項は次のとおりです。

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

グリーン ルームがプレイヤーに適していることは明らかです。レッド ルームのほとんどの人がグリーン ルームに移動し、そのうち 50% がそこに留まります。対照的に、青い部屋は人気がありません。そこに行く人はほとんどいませんし、行ったとしても長く滞在することはありません。

しかし、データはより重要なことを教えてくれます。プレイヤーが青い部屋にいる場合、次にそのプレイヤーがいる部屋は緑ではなく赤である可能性が高いのです。緑の部屋は赤の部屋よりも人気がありますが、プレイヤーが青の部屋にいる場合は状況が変わります。次の状態 (つまり、プレイヤーが移動する部屋) は、前の状態 (つまり、プレイヤーが現在いる部屋) によって決まります。依存関係を調べることで、観測値を単純に個別にカウントする場合よりも正確な予測が可能になります。

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

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

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

これは、51 回の観察後にプレイヤーがグリーン ルームにいるのを目にする確率が 21% になることを示しています。そのうち 5% はプレイヤーがレッド ルームから来ており、そのうち 25% はプレイヤーがその間にブルー ルームを訪れ、XNUMX% はプレイヤーがグリーン ルームからまったく出ないことを示しています。

表は単なる視覚的なツールであり、手順では各ステップで確率を掛け合わせるだけです。これは、1 つの注意点を除けば、遠い未来を予測できることを意味します。つまり、部屋に入る可能性は現在の部屋に完全に依存すると想定します。これはマルコフ特性と呼ばれ、将来の状態は現在のみに依存します。しかし、これは100%正確ではありません。プレイヤーは、体力レベルや弾薬レベルなどの他の要因に基づいて決定を変更する場合があります。これらの値は記録されないため、予測の精度は低くなります。

Nグラム

格闘ゲームを例にとり、プレイヤーのコンボの動きを予測するのはどうでしょうか?同じ！ただし、単一の状態またはイベントではなく、コンボ攻撃を構成するシーケンス全体を調べます。

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

(太字部分はプレイヤーがスーパーデスフィスト攻撃を発動したときのセリフです。)

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

これらのイベントのシーケンスは N グラムと呼ばれ、N は保存される要素の数です。前の例では、3 グラム (トライグラム) でした。つまり、最初の 5 つのエントリが XNUMX 番目のエントリを予測するために使用されます。したがって、XNUMX グラムでは、最初の XNUMX つのエントリが XNUMX 番目のエントリを予測し、以下同様に続きます。

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

一方、数字が大きくなるほど多くのメモリが必要となり、選択肢が増えるため AI の学習が難しくなります。キック、パンチ、ブロックの 10 つの入力が可能で、60 グラムを使用した場合、約 XNUMX 通りのオプションが存在することになります。

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

まとめ

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

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

• ヒルクライミング、勾配降下法、遺伝的アルゴリズムなどの最適化アルゴリズム
• 競合検索/計画アルゴリズム（ミニマックスとアルファベータプルーニング）
• 分類方法（パーセプトロン、ニューラルネットワーク、サポートベクターマシン）
• エージェントの知覚と記憶を処理するシステム
• AIへのアーキテクチャ的アプローチ（ハイブリッドシステム、サブセットアーキテクチャ、AIシステムを階層化するその他の方法）
• アニメーションツール（モーションプランニングと調整）
• パフォーマンス要因（詳細レベル、いつでもアルゴリズム、タイムスライス）

関連リソース：

1. GameDev.netは AIに関する記事やチュートリアルのセクションと форум.
2. 翻訳元 ゲーム AI 開発に関連する幅広いトピックに関する多数のプレゼンテーションと記事が含まれています。
3. GDC の金庫 GDC AI サミットのトピックが含まれており、その多くは無料で利用できます。
4. 役に立つ資料はウェブサイトでもご覧いただけます AI ゲームプログラマーギルド.
5. AI研究者兼ゲーム開発者のトミー・トンプソンはYouTubeで動画を制作している AIとゲーム 商用ゲームにおける AI の説明と研究。

このテーマに関する書籍:

1. Game AI Pro ブックシリーズは、特定の機能を実装する方法や特定の問題を解決する方法を説明する短い記事のコレクションです。

ゲーム AI プロ: ゲーム AI プロフェッショナルの知恵の集大成
ゲーム AI プロ 2: ゲーム AI プロフェッショナルの知恵の集大成
ゲーム AI プロ 3: ゲーム AI プロフェッショナルの知恵の集大成

2. AI Game Programming Wisdom シリーズは、Game AI Pro シリーズの前身です。古い方法も含まれていますが、そのほとんどは今日でも有効です。

AIゲームプログラミングの知恵1
AIゲームプログラミングの知恵2
AIゲームプログラミングの知恵3
AIゲームプログラミングの知恵4

3. 人工知能：現代的なアプローチ — は、人工知能の一般的な分野を理解したい人にとって基本的なテキストの 1 つです。これはゲーム開発に関する本ではなく、AI の基礎を教える本です。

出所： habr.com