You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've had this idea floating around to reduce the need for writing nearly-identical BTs. It would allow SubTree to act as an optional decorator in XML, and for any <BehaviorTree> to have access to a Child node. When parsing the XML into instances of BT::TreeNode, the Child is substituted with the child of <SubTree> from where it was instantiated. A simple example:
<BehaviorTreeID="MainTree">
<Sequence>
<SubTreePID="PrintAndTick">
<X />
</SubTree>
</Sequence>
</BehaviorTree>
<BehaviorTreeID="PrintAndTick">
<Sequence>
<Printmessage="Ticking the child" />
<!-- A "magic" Child node provided by the parser, could be made more obvious with different syntax -->
<Child />
</Sequence>
</BehaviorTree>
The flexibility of an arbitrary child means you can write generic BTs that operate on any child, and save the need for writing multiple copies of PrintAndTick for all combinations of X. Given the hierarchical nature of BTs, Child may itself be a tree of nodes, with possible Child substitutions, and so on and so forth.
Handling input ports is open to discussion too. Child could share a blackboard with its parent, or explicit/auto remapping could work too, effectively making Child into its own subtree with its own blackboard.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've had this idea floating around to reduce the need for writing nearly-identical BTs. It would allow
SubTree
to act as an optional decorator in XML, and for any<BehaviorTree>
to have access to aChild
node. When parsing the XML into instances ofBT::TreeNode
, theChild
is substituted with the child of<SubTree>
from where it was instantiated. A simple example:The flexibility of an arbitrary child means you can write generic BTs that operate on any child, and save the need for writing multiple copies of
PrintAndTick
for all combinations ofX
. Given the hierarchical nature of BTs,Child
may itself be a tree of nodes, with possibleChild
substitutions, and so on and so forth.Handling input ports is open to discussion too.
Child
could share a blackboard with its parent, or explicit/auto remapping could work too, effectively makingChild
into its own subtree with its own blackboard.Beta Was this translation helpful? Give feedback.
All reactions