タグ付けされた質問 「behavior」

http://altdevblogaday.org/2011/02/24/introduction-to-behavior-trees/ 明らかに、私がこのウェブサイトで見つけた最も興味深い記事。あなたはそれについてどう思いますか ？ それはいくつかのコード例を欠いています、あなたは少しも知りませんか？また、ステートマシンはビヘイビアツリーに比べてあまり柔軟ではないことも読みました...その上、ステートマシンと状態パターンの間に真のリンクがあるかどうかはわかりません...

23 ai  state  tree  behavior 

私がビヘイビアツリーで理解していることから、各ビヘイビアは、数回の反復で実行できる短い目標指向のアクションである必要があります。 したがって、たとえば、以下はビヘイビアツリーの画像です。 ここで、Drive To Enemyの動作には、ツリー内で数回以上の反復が必要であると想定しましょう。そのため、各パスでDrive To Enemyが呼び出されるのは、現在実行状態になっているためです。 問題は、敵が近くにいる場合、Evade Enemyに電話したいことです。Drive To Enemyが常に呼び出されることを考慮すると、Evade Enemyを呼び出す機会はありません（おそらく、Enemyを避ける必要があります）。 万一私はツリーを横断し、各アクションが現在実行されているものに関係なく渡しますか？ 私はこれについて正しい方法で行っていますか？ そのような動作を処理する適切な方法は何ですか？ もともとStackoverflowで尋ねられました。ここで考えたほうが、この質問をするのに適した場所です。

19 ai  game-loop  behavior 

私は最近、単純なテキストベースのアドベンチャーゲームをプログラミングして楽しませており、非常に単純なデザインの問題のように見えます。 概要を説明すると、ゲームはRoomオブジェクトに分解されます。それぞれにRoomは、Entityその部屋にあるオブジェクトのリストがあります。それぞれEntityに、単純な文字列->ブールマップであるイベント状態と、文字列->関数マップであるアクションリストがあります。 ユーザー入力は次の形式を取ります[action] [entity]。Room適切戻るには、エンティティ名を使用Entityして、正しい機能を見つけるために、アクション名を使用するオブジェクトを、それを実行します。 部屋の説明を生成するために、各Roomオブジェクトは独自の説明文字列を表示し、すべての説明文字列を追加しますEntity。Entity説明は（ETC、「ドアが開いている」、「ドアが閉じている」、「ドアがロックされている」）、その状態に基づいて変更することができます。 ここに問題があります。この方法を使用すると、実装する必要のある記述およびアクション関数の数がすぐに手に負えなくなります。私のスターティングルームだけでも、5つのエンティティの間に約20の機能があります。 すべてのアクションを1つの関数に結合し、それらをif-else / switchで結合できますが、それでもエンティティあたり2つの関数です。またEntity、ドアやキーなどの一般的なオブジェクトや一般的なオブジェクトの特定のサブクラスを作成することもできますが、それだけではこれまでのところはできません。 編集1：要求どおり、これらのアクション関数の疑似コード例。 string outsideDungeonBushesSearch(currentRoom, thisEntity, player) if thisEntity["is_searched"] then return "There was nothing more in the bushes." else thisEntity["is_searched"] := true currentRoom.setEntity("dungeonDoorKey") return "You found a key in the bushes." end if string dungeonDoorKeyUse(currentRoom, thisEntity, player) if getEntity("outsideDungeonDoor")["is_locked"] then getEntity("outsideDungeonDoor")["is_locked"] := false …

11 architecture  software-engineering  text-based  behavior 

ここで何が質問されているのかを理解することは困難です。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 6年前に閉鎖されました。 これまでは、有限状態機械（FSM）や階層型FSMなどの単純なシステムを使用してAIの動作を制御してきました。このパターンは、非常に迅速に、または複雑なシステムで崩壊します。 行動ツリーについて聞いたことがあります。それらは次の明白なステップのように見えますが、動作する実装を見たことがないか、実際に実際に試したことはありません。 複雑なAIの動作を管理しやすくする他のパターンは何ですか？

11 architecture  ai  behavior 

私の現在のプロジェクトでは、コンポーネント/エンティティベースのシステムを実装しました。基本的に、このかなり未定義の領域にあるベストプラクティスのほとんどに従っています。 だから私は（少し拡張された）エンティティを取得しました。これは基本的にintID、人間が読める名前、std::mapコンポーネントのa 、およびlong存在するコンポーネントを示すために使用される「タイプインジケーター」です（私はenumすべてのコンポーネントに対して2の累乗を持っています）タイプと、コンポーネントがエンティティに追加されるときはいつでも、ビット単位の演算によってその長さを自動的に変更し、比較しますます。この回答を）。 次に、Componentsもあります。これもかなり単純です。コンポーネントタイプとしてのintID enum、親エンティティポインター、およびstd::mapこのコンポーネントが保持するすべてのプロパティのa です。 最後に、実際のロジック処理を処理するいくつかのシステム/マネージャー。彼らは最初に、現在処理されているエンティティに一致するlong「タイプインジケーター」があるかどうかをチェックします=そのシステムに必要なすべてのコンポーネントが存在します。次に、必要に応じていくつかのプロパティにアクセスし、それぞれのコンポーネントの関数を直接呼び出すか、メッセージディスパッチャを介してメッセージを送信します。 結論：ここまでは、かなり標準的なイベント駆動型のコンポーネント/エンティティベースのシステムとデータ駆動型のアプローチを組み合わせたものです（比較すると、コンポーネントにはハードコードされたデータ変数がなく、（一部の）コンポーネントとして一般的なマップがありますコンポーネントの/ archetypesは後で、実際のコンポーネントコードの一部ではない追加データを追加するオプションを使用してファイルから読み取られます。 次に、そのプロジェクトに（AiGameDev BTSKに基づく）動作ツリーも導入したいと思いますが、それらを既存のコンポーネントにリンクする必要があるかどうか、どのようにリンクするべきか、またはそれらのデザインを一般的に統合する方法はわかりません。 いくつかの関連するアイデア/ポイント/質問が頭に浮かびます： 私のBTはファイルから（再び）読み込まれます。現在BT Action、ツリー内のとアプリケーションの実際のコーディングとの間の接続を最適にする方法を確認するのに苦労しています。BTファイルで使用されるアクション名と実際のロジック実装への関数ポインターとの間に何らかのマップを作成する必要がありますか？それを解決するための通常のアプローチは何ですか？ 私はすべての異なるEntityタイプ（つまり、ゲームロジックとAIに関連するコンポーネントの組み合わせのそれぞれについて、何度も言及した長い「タイプインジケーター」で示されるように）に対してBTを作成する必要があると思います。結果として、BT Actionアクションごとに多くのコンポーネントが関与する可能性が最も高いため、コンポーネントに実装を配置することは意味がありませんか？ それで、BT Actionロジックは複数の個別のシステムに配置する必要がありますか（アイデア＃1からのマップが指し示すメソッドに）。次に、システムは私のlong「タイプインジケーター」ごとにEntity、BTが現在チェックされており、特定のアクション（=システム内のメソッド）の実行が実際に許可されている（=必要なコンポーネントがある）かどうかをチェックします。しかし、そうでない場合（たとえば、BT作成者が特定の状況を見落とし、実行時に必要なコンポーネントがエンティティにアタッチされなくなる可能性があるため）、何も起こりません。 質問： そのような統合のための実証済みの概念はありますか？ 上記の3つの点についてどう思いますか？ コンポーネント/エンティティベースのデザイン全般に関して、他に思い浮かぶことはありますか？

9 ai  component-based  entity-system  behavior 

私はしばらくの間BDD-Behavior Driven Developmentについて読んでおり、機能をコードに変換することは本当に簡単で便利だと思います。BDDユーザーは、それをTDDが正しく行われたと呼ぶことがよくあります。 BDDは、ビジネス値（またはゲームプレイ値）からコードに至るまで、ソフトウェア設計のためのツールです。 ダンノースがBDDを発表 これ以外にBDDとゲームに関するリソースを知っていますか？

9 testing  methodology  behavior  test-driven-development