In the first post related to flexibility in behaviour trees I argued that behaviour trees and state machines can accomplish similar things, and that there were certain benefits to using each implementation method. I recently watched a GDC 2017 talk by Bobby Anguelov that redefined my perspective on these issues.
The picture is a limited access link to video of "AI Arborist: Proper Cultivation and Care for Your Behavior Trees" Bobby starts at 20 min.
Much of what I proposed in previous camera experiments models cyclic behaviour on cameras with behaviour trees, and I did not know why that should not be done until watching this talk. In fact, he suggests state machines are clearly better than behaviour trees at high level decision making. He provides examples where the acyclic data structure of behaviour trees complicate implementation and make it inefficient. However, Bobby does not think behaviour trees are all bad.
The main takeaway from his talk is to use behaviour trees only after high level decisions have already been made, where their ability for parallel execution of tasks can supplement the cyclic logic of state machines. The rest of this post describes how his approach would integrate with previous camera implementations I have discussed, and applies this new knowledge to guidance of future experiments with behaviour trees on cameras.
The main takeaway from his talk is to use behaviour trees only after high level decisions have already been made, where their ability for parallel execution of tasks can supplement the cyclic logic of state machines. The rest of this post describes how his approach would integrate with previous camera implementations I have discussed, and applies this new knowledge to guidance of future experiments with behaviour trees on cameras.
From the beginning, my experiments emphasized behaviour trees over the other implementation strategies. Let's recap the three experiments:
One model I emphasized in previous posts was "Sense, Think, Act" with the heavy implication that Unreal Engine 4's BehaviorTree should be used primarily for the decision-making "Think" processes. In contrast, Bobby Anguelov proposes State Machines are better suited for "Think", whereas BehaviorTree do their best work as a separate step between "Think" and "Act".
- Experiment 1: Testing ease of use for creation of a simple BehaviorTree that swaps between a reactive, physics driven "landing" and default cameras
- Experiment 2: Comparing efficiency of making an addition to a State Machine versus making an addition to a BehaviorTree
- Experiment 3 (unpublished): Testing viability of EQS on Camera BehaviorTrees
One model I emphasized in previous posts was "Sense, Think, Act" with the heavy implication that Unreal Engine 4's BehaviorTree should be used primarily for the decision-making "Think" processes. In contrast, Bobby Anguelov proposes State Machines are better suited for "Think", whereas BehaviorTree do their best work as a separate step between "Think" and "Act".
The first experiment includes a BehaviorTree that reads a Blackboard Key and makes a binary decision between two camera states. A real world example with all the complexity of modern day games would be represented more efficiently with a State Machine, or another cyclic data structure. The landing camera and the default camera would transition on that graph, and BehaviorTrees could handle execution of smaller tasks for these individual cameras.
In the second experiment, I took steps towards understanding the value of State Machines but I ultimately failed to evaluate them correctly and see past my own bias towards behaviour trees. This follow-up comes as a correction for those errors.
However, the third experiment actually has a lot of promise by proposing the use of Environment Querying System to modify logic during the "Act" phase. One example is using it for pre-emptive collision avoidance, where the camera decides to move (actually, it is the player who performs the "Think" operation in this case) but its BehaviorTree modifies the input before colliding with objects. The "Sense" activity performed by the EQS system communicates directly with the BehaviorTree, and modifies the resulting behaviour instead of choosing a new one.
In conclusion, my progress was headed in the wrong direction but this information came at an opportune time for me. Now I will have the ability to redirect the third experiment to a more sensible course.
My first step will be to create camera behaviours with a State Machine, and then use BehaviorTrees for each of the camera states to modify the respective behaviours for collision avoidance. Player input will create changes in the State Machine only, and each BehaviorTree will read Blackboard values derived from EQS and values set by camera states in the State Machine. It may take a bit of unorthodox Unreal hackery to get this to work, but if I have learned one thing from working with proprietary game engines it is that you should never the tools define how you think about the optimal workflow. Unreal Engine 4 is a mainstream product, but that doesn't mean its' out of the box development approaches are best practices.
RSS Feed