NPCのアニメーションのシーケンスを選択する-動作ツリーを使用しますか?


8

NPCを実装して、仮想空間、具体的には猫を歩き回っています。一連の短いアニメーションクリップ(3〜5秒)があります。私の最初の本能は、最後のアニメーションが終了したときにランダムなアニメーションを選択することだけでしたが、次のアニメーションが物理的に偶発的な可能性に制限されていても、動作が頻繁に変更されるため、現実的に見えないことに気付きました。

私の意図する解決策は、各アニメーションに次のアニメーションの重み付きリストがある、動作ツリー(http://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_AI_How_they_work.php)のようなものです。つまり、猫が歩いている場合、歩き続ける確率は80%、座っている確率は20%、睡眠は0%です。基本的にマルコフモデルを使用して適切な次のステップを取得します。

ただし、これが良い解決策であるかどうかはわかりません。また、現在のアニメーションから次のアニメーションの可能性と確率へのマッピングを生成する方法もわかりません。30のアニメーション* 30の次のアニメーション= 900の重み付け。手動で計算するのは大変です。

猫は障害物にぶつかると反応することがありますが、問題の先を行くと、事前にすべてを選択せず​​に現実的なアニメーションのシーケンスを選択することになります。ツリーには、人への近さ、部屋の場所、最後に食べてからの時間など、他のいくつかの入力もあります。


2
私はこのようなことをしたことがありませんが、より単純なアプローチで十分でしょうか?つまり、アニメーションを「狩猟」、「再生」、「休憩」、「迷惑な人間」などの「行動」にグループ化します。その場合、おそらくそのマルコフモデルがなくても簡単な確率しか得られません。グループ内および時間/外部イベントに基づいてグループを切り替えるための確率。
マット2016年

回答:


3

通常、アニメーションから猫のロジックを分割する必要があります。

次に、最初に猫のロジックを記述する必要があります。私が見つけた1つの良いアプローチは、ロジックをレイヤーに分割することです。

ニーズ

猫は、時間の経過とともにゆっくりと成長し、それらを行うと減少するいくつかの動機/ニーズ(食べる、睡眠など)を持ついくつかの状態を持つことができます(シムズを考えてください)。必要に応じて、ファジーロジックを使用して最大のニーズを満たす現在のタスクを選択できます。

タスク

今、猫はいつでもタスクを持っています(食べ物を見つける、寝るベッドを探す、走り回るスペースなど、アイドル状態であることもタスクです)。これらのタスクは、どこに行きたいか、何をしたいかを猫に伝えます。

行動

これで、第3層-アクションがあります。各ゴールには、実行するアクション(立ち上がる、歩く、しゃがむ、食べるなど)のキューがあります。各アクションは、その実行に責任があります。たとえば、歩行アクションは障害物をチェックし、サブアクション(障害物を飛び越えたり、家具の下にしゃがんだりするなど)を含む可能性があるポイントAからポイントBに猫を運ぶ必要があります。

アニメーション

これで、猫にタスクとアクションが必要になったときに、そのアクションに適したアニメーションを選択できます。現在のアニメーションと次のアニメーションが分かれば、あるアニメーションから別のアニメーションに移行できるはずです。たとえば、枕まで歩いた後に猫が寝るべきだとタスクが言った場合、アニメーションはキューに入れられます-walk-stop-sit-lay。

アニメーションのキューイングは、それらをノードとしてグラフにマッピングし、遷移可能なアニメーション間でノードを接続する場合に効果的に実行できます(たとえば、座って歩くことは可能ですが、噛んでジャンプする-できません)。次に、このグラフのA *を使用して、各アニメーションを他のアニメーションにキューイングできます。

例:猫は休憩して食べる必要があります。「休憩」タスクで休憩場所を見つけ、猫を散歩させ、寝かせて休憩させます。「休憩」タスクに状況を時々チェックさせ、周囲が不快になった場合は、タスクを終了させて​​ください。猫がまだ休んでいる場合は、猫が今何を望んでいるかを確認します-前の部分を繰り返します。猫が休んでいるとき-新しいタスクを選択してください。


2

あなたが探しているのは有限状態機械またはFSMだと思います。つまり、NPCの動作を現在の状態に応じて変更する方法です。

編集:

これは動作ツリーのようなものですが、NPCが戻るいくつかのグループ「状態」に要約されます。動作ツリーでは、動作の柔軟性が大幅に向上しますが、確率の重み付けのためにより多くのデータが必要になります(それを自動化する賢い方法は、scriptinが彼の回答で提案するように、タグを使用することです)。状態を使用するときは、その状態でのアクションとアクションの確率の特定のセットを決定します。現在のアクションを実際に変更するには、同じアクションを維持するために、おそらく80%のバイアスをかけることができます。アクションを変更する必要がある場合は、異なる確率を使用して新しいアクションを選択します。

あなたの場合、状態は(少し簡略化されている)可能性があります:

  • スリーピー:睡眠80%、座っている15%、歩く5%
  • 怒り:轟音(猫は轟音を発しますか?)40%、ヒス40%、実行20%
  • 空腹:40%食べる、40%狩る、10%走る
  • プレイフル:60%プレイ、20%ラン、10%ジャンプ
  • 傷跡:50%を隠す、50%を実行

たとえば怒りや傷跡のある状態は長続きしない可能性があります。州によって、合法的なルールが異なる場合があります(「眠い」から「遊び心のある」への変更は違法になる可能性がありますが、猫はそれを気にしないようです)。さまざまなイベントが状態の変化をトリガーする可能性があります。

持って見て FSMとAIのためのWebを検索して周り、あなたはそれがどのように動作するかを確認することができます。説明すると複雑に見えるかもしれませんが、とても簡単です。


質問で提案された解決策を別の名前で説明しました。
スクリプトイン

動作ツリーはステートマシンよりもはるかに複雑であり、実装と重みの設定の必要性ははるかに簡単です
Fredrik Lundvall

という事は承知しています。しかし、質問で説明されているアルゴリズムは、まさにあなたが説明したものです。(OPは動作ツリーではなくFSMを記述していると思います。)また、状態の順列が多すぎるという問題に対処していません。これは質問の主な関心事のようです。
スクリプトイン

私の答えは実際には問題に対処していませんでした。私は彼を正しい方向に向けたかったのです。順列がステートマシンの問題ではないため
Fredrik Lundvall

その追加情報は非常に役立つ可能性があります。回答を編集して、FSMとBTのこれらの違いについて詳しく説明できますか?
スクリプトイン

1

タグ付けを使用できます。

  • 「敷設」、「座る」、「立つ」、「歩く」、「走る」などの動きタグがあるかもしれません。次に、タグの非現実的な組み合わせを排除することができます。

  • 他のタグは、「眠る」、「食べる」、「狩る」などのアクティビティを説明する場合があります。繰り返しますが、「眠る」->「狩る」は中間状態なしでは不可能です。

  • 「立ち上がる」などのアニメーションは一時的なものであるため、各アニメーションの開始と終了に別々のタグを付けることをお勧めします。たとえば、「立ち上がる」とは、「座っている」から「滞在している」などへの移行です。

したがって、アニメーションごとにいくつかのタグを付けることができます。

  • 最初と最後の位置/動きを説明するもの
  • アクティビティを説明する少なくとも1つ。また、アクティビティにもトランジションがあるため、ここに最初と最後のタグがある場合があります

これらを使用すると、「A->B可能な場合にのみ可能」などの制限を設定することで、可能な組み合わせのみをフィルタリングできますfinal_movement_tag(A) == initial_movement_tag(B)。これにより、数が大幅に少なくなります。これらの可能な組み合わせで、あなたはあなたが説明したことを行うことができます-確率を追加します。同じアクティビティにとどまることはアクティビティを変更するよりも可能性が高いため、確率の追加はアクティビティタグに基づく場合があります。

したがって、タグを使用すると、FSM /動作ツリー内のすべての遷移の作成を自動化し、一部の組み合わせに満足できない場合は後で調整することができます。


1

動作ツリーの豊富な可能性を維持したい場合は、マルコフセレクターノードという新しい種類の複合セレクターノードを追加できます。

マルコフセレクタノードを自分で実装する必要があります。以前に成功(または失敗)した(子)ノードに応じて、子ノードの1つをランダムに選択します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.