Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualEnder1618

Posted 18 April 2013 - 07:17 PM

So I'm working with my BehaviorTree implementation as part of my Sim AI (FPS like Sim, but alot of social interaction).

I keep coming to the issue where I am at a particular node of my BT (say part of the idle subtree), but at that point there are a large number of things the player can do that an observing AI agent(s) needs to respond to (gaze zones, (non)aggressive postures, picking up various object in the scene, shooting at, dropped a grenade, all the things you can can say, gestures, and many more).

Another instance where this type of thing happens is player to NPC dialogs.

This need to respond to a large number of things (at any time), quickly really complicates the BT (at least the way im constructing it). Also my BT visual editor becomes a mess that is dificult to navigate and understand. With BTs I was trying to avoid the mess that happens with a visual HFSM editor.

How do people usually deal with this in a BT framework? Lots and lots of monitor nodes high up in the tree (or a high up active selector with MANY children)? Also if a monitor picks up a specific event, that event needs to be handled with respect to previous context (where you were in the tree before the event), how is that usually accomplished?

Is it a common practice for the BT to have a more DAG like structure, where nodes lower in the tree have children that are higher up in the tree (multiple parents for that node), potentially causing cyclical references? Dialogs seem to potentially need something like this.

Thanks for any advice?


#2Ender1618

Posted 18 April 2013 - 02:17 PM

So I'm working with my BehaviorTree implementation as part of my Sim AI (FPS like Sim, but alot of social interaction).

I keep coming to the issue where I am at a particular node of my BT (say part of the idle subtree), but at that point there are a large number of things the player can do that an observing AI agent(s) needs to respond to (gaze zones, (non)aggressive postures, picking up various object in the scene, shooting at, dropped a grenade, all the things you can can say, gestures, and many more).

Another instance where this type of thing happens is player to NPC dialogs.

This need to respond to a large number of things (at any time), quickly really complicates the BT (at least the way im constructing it). Also my BT visual editor becomes a mess that is dificult to navigate and understand. With BTs I was trying to avoid the mess that happens with a visual HFSM editor.

How do people usually deal with this in a BT framework? Lots and lots of monitor nodes high up in the tree (of a high up active selector with MANY children)? Also if a monitor picks up a specific event, that event needs to be handled with respect to previous context (where you were in the tree before the event), how is that usually accomplished?

Is it a common practice for the BT to have a more DAG like structure, where nodes lower in the tree have children that are higher up in the tree (multiple parents for that node), potentially causing cyclical references? Dialogs seem to potentially need something like this.

Thanks for any advice?


#1Ender1618

Posted 18 April 2013 - 02:00 PM

So I'm working with my BehaviorTree implementation as part of my Sim AI (FPS like Sim, but alot of social interaction).

I keep coming to the issue where I am at a particular node of my BT (say part of the idle subtree), but at that point there are a large number of things the player can do that an observing AI agent(s) needs to respond to (gaze zones, (non)aggressive postures, picking up various object in the scene, shooting at, dropped a grenade, all the things you can can say, gestures, and many more).

Another instance where this type of thing happens is player to NPC dialogs.

This need to respond to a large number of things (at any time), quickly really complicates the BT (at least the way im constructing it). Also my BT visual editor becomes a mess that is dificult to navigate and understand. With BTs I was trying to avoid the mess that happens with a visual HFSM editor.

How do people usually deal with this in a BT framework? Lots and lots of monitor nodes high up in the tree? Also if a monitor picks up a specific event, that event needs to be handled with respect to previous context (where you were in the tree before the event), how is that usually accomplished?

Is it a common practice for the BT to have a more DAG like structure, where nodes lower in the tree have children that are higher up in the tree (multiple parents for that node), potentially causing cyclical references? Dialogs seem to potentially need something like this.

Thanks for any advice?


PARTNERS