Comments on: Shocker: Naive Object-Oriented Behavior Tree Isn’t Data-Oriented Hehe, thanks for looking forward to my next behavior tree post. Here’s a teaser: Data-Oriented Streams Sping Behavior Trees – figures and diagrams.

Sorry for the long post delay so far – the next article really taxes my writing a lot and I don’t want to break it into multiple parts this time.

]]>
By: Cam Jackson/2011/03/10/shocker-naive-object-oriented-behavior-tree-isnt-data-oriented/#comment-2924 Cam Jackson Mon, 18 Apr 2011 11:14:14 +0000 Hi Martin, cool to "meet" you here :-) Which programming language to use and which development methodology to apply hinges on many factors: target hardware and OS/runtime environment, performance and power requirements, databases or services to connect to, the already existing code base, knowledge and capabilities of the team, and then team leaders, management and company politics come into play, too. When I use C++ in an OO I often observe that I start to invest time into the wrong areas, e.g. create a reusable, abstract, perfect ontology of the things forming the solution/problem domain - instead of concentrating solely on finishing a concrete solution for a concrete problem. I feel an urge to create a flexible, elegant (ahem), and highly reusable (ahem, ahem) universal solution - looking more at possible use cases than the one at hand. This often (always?) results in nests of indirections and pattern-melt. This is my fault - but I have seen the same tendencies in others and in other code - especially when C++ and OO are combined. Use of Java seems to breed legions of indirection, too. Energy-aware and performance-oriented programming of parallel many-core processors necessitates good use of the available memory hierarchy. Does this conflict with save programming that tries to minimize buffer overflows and wrong memory accesses? Whatever the answer is today - we have a lot to learn, research, and educate to foster development conditions that lead to efficient, reliable, and maintainable solutions while also enabling high productivity. Ok, enough buzz words for this comment :-) Hi Martin,
cool to “meet” you here :-)

Which programming language to use and which development methodology to apply hinges on many factors: target hardware and OS/runtime environment, performance and power requirements, databases or services to connect to, the already existing code base, knowledge and capabilities of the team, and then team leaders, management and company politics come into play, too.

When I use C++ in an OO I often observe that I start to invest time into the wrong areas, e.g. create a reusable, abstract, perfect ontology of the things forming the solution/problem domain – instead of concentrating solely on finishing a concrete solution for a concrete problem. I feel an urge to create a flexible, elegant (ahem), and highly reusable (ahem, ahem) universal solution – looking more at possible use cases than the one at hand. This often (always?) results in nests of indirections and pattern-melt. This is my fault – but I have seen the same tendencies in others and in other code – especially when C++ and OO are combined. Use of Java seems to breed legions of indirection, too.

Energy-aware and performance-oriented programming of parallel many-core processors necessitates good use of the available memory hierarchy. Does this conflict with save programming that tries to minimize buffer overflows and wrong memory accesses? Whatever the answer is today – we have a lot to learn, research, and educate to foster development conditions that lead to efficient, reliable, and maintainable solutions while also enabling high productivity.

Ok, enough buzz words for this comment :-)

]]>
By: Therac-25/2011/03/10/shocker-naive-object-oriented-behavior-tree-isnt-data-oriented/#comment-2201 Therac-25 Fri, 01 Apr 2011 10:59:02 +0000 Hi Jason, Your event-driven behavior approach sounds very interesting. On the one hand you seem to lose control how the event-triggered behaviors interact with each other as there is no imposed structure I can see by a full-blown behavior tree. On the other hand - especially with many BT controlled actors - you have less event-polling per behavior tree traversal. The events enumerate all the things that can happen (perhaps even at the same time) and how you are reacting to them. I am not sure if I'd call that a behavior tree but I like the idea of it - why throw a concept (full BT) at a problem that can be solved in a more simple, lean, and straightforward manner :-) My main way to fight the cache trashing when calling into children-actions will be be deferring such actions - like what Jesse said above. Deferred actions are collected and can therefore be batched and called based on their data-needs. More about that in a week. For my experiment I'll separate static and per-actor dynamic state like you describe but won't try to minimize how much state I need to store at first. If state-size is a problem - do you have a clear memory budget? How many actors need to fit into it? How many nodes does/will your avg BT have? Hi Jason,

Your event-driven behavior approach sounds very interesting. On the one hand you seem to lose control how the event-triggered behaviors interact with each other as there is no imposed structure I can see by a full-blown behavior tree. On the other hand – especially with many BT controlled actors – you have less event-polling per behavior tree traversal.
The events enumerate all the things that can happen (perhaps even at the same time) and how you are reacting to them. I am not sure if I’d call that a behavior tree but I like the idea of it – why throw a concept (full BT) at a problem that can be solved in a more simple, lean, and straightforward manner :-)

My main way to fight the cache trashing when calling into children-actions will be be deferring such actions – like what Jesse said above. Deferred actions are collected and can therefore be batched and called based on their data-needs. More about that in a week.

For my experiment I’ll separate static and per-actor dynamic state like you describe but won’t try to minimize how much state I need to store at first.

If state-size is a problem – do you have a clear memory budget? How many actors need to fit into it? How many nodes does/will your avg BT have?

]]>
By: Jason Booth/2011/03/10/shocker-naive-object-oriented-behavior-tree-isnt-data-oriented/#comment-1760 Jason Booth Sat, 19 Mar 2011 14:16:58 +0000 Thank you Christopher! Yeah, I am blogging about my experiment to take a technique (decision making) that might not be the most ideal candidate to apply data-oriented design to (because it might not even show in a profiler) and find out what data-orientation means for it. It's a learning experiment for me and while I have a clear idea what to do I am curious to see it in comparison to the more traditional implementation. Thank you Christopher! Yeah, I am blogging about my experiment to take a technique (decision making) that might not be the most ideal candidate to apply data-oriented design to (because it might not even show in a profiler) and find out what data-orientation means for it. It’s a learning experiment for me and while I have a clear idea what to do I am curious to see it in comparison to the more traditional implementation.

]]>
By: Christopher McArthur/2011/03/10/shocker-naive-object-oriented-behavior-tree-isnt-data-oriented/#comment-1590 Christopher McArthur Mon, 14 Mar 2011 18:47:28 +0000 Great insights, thank you for sharing them Jesse! Sounds pretty much like what I am working on, too. Hopefully my next posts will still be useful now - though they will contain lots of details and different implementation approaches. An additional part of my experiment is also a way to allow fast (interactive) iteration times and I'll reuse the oo idea for that - hint: the next post will have the title "Data-oriented streams spring from an object-oriented behavior tree" ;-) Great insights, thank you for sharing them Jesse! Sounds pretty much like what I am working on, too.

Hopefully my next posts will still be useful now – though they will contain lots of details and different implementation approaches.

An additional part of my experiment is also a way to allow fast (interactive) iteration times and I’ll reuse the oo idea for that – hint: the next post will have the title “Data-oriented streams spring from an object-oriented behavior tree” ;-)

]]>
By: Jesse Cluff/2011/03/10/shocker-naive-object-oriented-behavior-tree-isnt-data-oriented/#comment-1476 Jesse Cluff Thu, 10 Mar 2011 23:40:16 +0000