A simple behaviour tree from my Archery Tag AI The first question I must address here: Why would anyone put a behaviour* tree on a camera?
Behaviour trees are a powerful tool that allows designers and artists to visualize logic flow. It is easier for a non-technical person to learn and interact with a visual system that describes the states, than one where they must infer the states. The quick wins of behaviour trees over Blueprint include less rules to understand, clearer visual connections and flow, and nodes can be renamed to disambiguate them from other nodes (all of which help first-time users too).
The video above is part of a playlist showing how to implement behaviour trees in Unreal, and is recommended viewing for anyone who wants to have a practical understanding of the features tested in this experiment. Note that we implement very basic triggers with behaviour trees in this experiment, however, these triggers are simple examples and might be better off implemented at the C++ level. Ideally, the process used in this experiment would be applied to empowering camera artists through control of camera behaviours in cases where performance costs are considered less important than giving artists a greater degree of autonomy.
Behaviour trees are a powerful tool that allows designers and artists to visualize logic flow. It is easier for a non-technical person to learn and interact with a visual system that describes the states, than one where they must infer the states. The quick wins of behaviour trees over Blueprint include less rules to understand, clearer visual connections and flow, and nodes can be renamed to disambiguate them from other nodes (all of which help first-time users too).
The video above is part of a playlist showing how to implement behaviour trees in Unreal, and is recommended viewing for anyone who wants to have a practical understanding of the features tested in this experiment. Note that we implement very basic triggers with behaviour trees in this experiment, however, these triggers are simple examples and might be better off implemented at the C++ level. Ideally, the process used in this experiment would be applied to empowering camera artists through control of camera behaviours in cases where performance costs are considered less important than giving artists a greater degree of autonomy.
This graph represents the triggering tools for camera artists on Prince of Persia. Click this picture to watch Jonathan Bard's GDC talk.
This experiment begins where Real Time Cameras in Unreal Editor 4 - Part 12 ends. Also in that article, I mentioned a GDC talk where Jonathan Bard from Ubisoft explains why they implemented a system like this for Prince of Persia. In that game, camera artists were given control of " thinking" for the camera using behaviour trees but camera senses and actions were implemented by engineers. My use of Unreal's Behavior Tree mimics the Decision Graph employed by camera artists for triggering behaviours, but I applied Blueprint for engineering tasks like scripting the camera.
*The answer to the second question is yes, I will insist on spelling behaviour in the Canadian/UK fashion whenever possible. I'll keep Unreal's spelling for their tools.
*The answer to the second question is yes, I will insist on spelling behaviour in the Canadian/UK fashion whenever possible. I'll keep Unreal's spelling for their tools.
Experiment: Ease of use and Visual feedback
What is the goal for the subject in this experiment?
The subject (me) will create a behaviour tree that swaps the default camera for another camera when a button on the keyboard is held down. They will start with all of the "Sense" and "Act" functionality created ahead of time, and must apply them using only the Behavior Tree window to create the "Think" functionality that decides what behaviours the gameplay camera should be doing in specific conditions.
Use case: the camera artist wants the default shake camera replaced with a camera locked on the player's origin when the player holds the 'S' key for a soft landing.
The subject (me) will create a behaviour tree that swaps the default camera for another camera when a button on the keyboard is held down. They will start with all of the "Sense" and "Act" functionality created ahead of time, and must apply them using only the Behavior Tree window to create the "Think" functionality that decides what behaviours the gameplay camera should be doing in specific conditions.
Use case: the camera artist wants the default shake camera replaced with a camera locked on the player's origin when the player holds the 'S' key for a soft landing.
This final result demonstrates a valid solution for triggering camera state changes but has unresponsive input (0.5 second wait nodes)
How are we evaluating ease of use?
1. How fast can this be done by a first-time implementer? The longer the time, the less ease of use. We are ignoring that the subject is the one who implemented the system, because they have not played with Unreal's Behavior Trees in the last year.
2. Is any special knowledge required to implement the use case? The "Sense" and "Act" functionality for this behaviour tree have already been scripted, and the names of the required actions are provided. All extra information required and actions taken will be listed, with each item indicating reduced ease of use for this workflow.
3. What is the minimum number of clicks required to create the behaviour tree? Clearly, a higher number of clicks is inversely proportional to the ease of use.
4. Can the subject complete the test without using anything other than official Unreal Engine 4 support documentation? If the test cannot be completed with these restrictions then it indicates low ease of use. All helpful links will be documented.
What visual feedback is provided?
All of the feedback during authoring and debugging will be provided to show the benefits of this approach for the end user. In addition, the quality will be assessed.
1. How fast can this be done by a first-time implementer? The longer the time, the less ease of use. We are ignoring that the subject is the one who implemented the system, because they have not played with Unreal's Behavior Trees in the last year.
2. Is any special knowledge required to implement the use case? The "Sense" and "Act" functionality for this behaviour tree have already been scripted, and the names of the required actions are provided. All extra information required and actions taken will be listed, with each item indicating reduced ease of use for this workflow.
3. What is the minimum number of clicks required to create the behaviour tree? Clearly, a higher number of clicks is inversely proportional to the ease of use.
4. Can the subject complete the test without using anything other than official Unreal Engine 4 support documentation? If the test cannot be completed with these restrictions then it indicates low ease of use. All helpful links will be documented.
What visual feedback is provided?
All of the feedback during authoring and debugging will be provided to show the benefits of this approach for the end user. In addition, the quality will be assessed.
Results: Ease of use
Key_PhysicsCameraDisabled must be initialized here 1. This test took roughly 30 minutes to complete, including 2 times where I thought the engineering functionality was busted and almost quit, and a hard crash where Unreal Engine forced my computer to restart, which I thankfully could not repeat.
2. There were a few general Behaviour Tree implementation rules that I had to relearn in order to get a successful result, including:
4. I did not use any references to complete the test but here is the official guide:
https://docs.unrealengine.com/latest/INT/Engine/AI/BehaviorTrees/index.html
2. There were a few general Behaviour Tree implementation rules that I had to relearn in order to get a successful result, including:
- The user must right click on the nodes to add decorators or services to nodes
- Services (for setting Blackboard values) can only be added to composite nodes
- Services have properties that must be initialized from the default window
- Sequences halt when a child's condition check returns false. They are more useful for this test than selectors, which halt when condition checks returns true.
4. I did not use any references to complete the test but here is the official guide:
https://docs.unrealengine.com/latest/INT/Engine/AI/BehaviorTrees/index.html
This example shows how hovering over the child node indicator, all siblings appear red so you can see the logical heirarchy more clearly
Results: Visual feedback
This discussion distinguishes between feedback given while the user is authoring, especially before the game runs, and debugging, when the game is running.
Authoring feedback includes highlighting functional areas when the mouse hovers over each node. This is quite helpful to show the user where they can click and drag to create a new connection. Dragging and hovering over an invalid connection informs the user why the node cannot be connected. As seen in Blueprint, dragging to an empty space creates a new node. There are less node options available in a Behavior Tree in comparison to Blueprint, making it less intimidating for new users.
Right clicking allows the user to add services or decorators to an existing node, but this is one of the less user-friendly features because the information is hidden until they right click on a node. Also, they must search through a list of up to ten actions to find the one they want to perform.
When a composite node has multiple children, a grey numbered circle appears indicating the order in which the children will be evaluated. Hovering over the numbered circle turns all that nodes siblings red.
Authoring feedback includes highlighting functional areas when the mouse hovers over each node. This is quite helpful to show the user where they can click and drag to create a new connection. Dragging and hovering over an invalid connection informs the user why the node cannot be connected. As seen in Blueprint, dragging to an empty space creates a new node. There are less node options available in a Behavior Tree in comparison to Blueprint, making it less intimidating for new users.
Right clicking allows the user to add services or decorators to an existing node, but this is one of the less user-friendly features because the information is hidden until they right click on a node. Also, they must search through a list of up to ten actions to find the one they want to perform.
When a composite node has multiple children, a grey numbered circle appears indicating the order in which the children will be evaluated. Hovering over the numbered circle turns all that nodes siblings red.
Similar to Blueprint debugging or Unity's Mecanim tool, debugging feedback for Behavior Trees shows the flow and current state of the graph during run-time. This makes it possible to get visual feedback on AI states, so the user can determine if the logic is operating as expected. This increased clarity of feedback makes troubleshooting implementation problems more approachable for a camera artist.
During the test, I found this particularly useful when the camera was jumping between two states rapidly, which could have been caused by errors in the Blueprint controlling the movement of the camera. However, I could see that the states were flickering rapidly too while running the game with the Behavior Tree open. I was able to discover at a glance that the issue causing the flickering was in the "Think" rather than the "Act" functionality.
Visual quality of results:
The final product of this test has some inadequacies including noticeable and abrupt transitions between cameras, a 0.5 second cooldown interval after holding for 0.5 seconds, and the lack of communication between character and camera states. The "Think" functionality was actually easier to implement in Blueprint alone, although it required more nodes and a more in-depth understanding of how to get references from other scripts. Overall, the results demonstrate a modest advantage which I believe will be improved after iterating on the methods and implementation.
During the test, I found this particularly useful when the camera was jumping between two states rapidly, which could have been caused by errors in the Blueprint controlling the movement of the camera. However, I could see that the states were flickering rapidly too while running the game with the Behavior Tree open. I was able to discover at a glance that the issue causing the flickering was in the "Think" rather than the "Act" functionality.
Visual quality of results:
The final product of this test has some inadequacies including noticeable and abrupt transitions between cameras, a 0.5 second cooldown interval after holding for 0.5 seconds, and the lack of communication between character and camera states. The "Think" functionality was actually easier to implement in Blueprint alone, although it required more nodes and a more in-depth understanding of how to get references from other scripts. Overall, the results demonstrate a modest advantage which I believe will be improved after iterating on the methods and implementation.
This is a wide perspective on the Blueprints for "Act" functionality, here it demonstrates how cluttered and incomprehensible they can get
Conclusion: Why not use Blueprint only?
Gameplay cameras have many behaviours, many of which have similar fine detail controls which result in lots of child states with similar names. This can be confusing because users often cannot be sure at a glance which "camera transition from synchronized animation camera" state the character is currently in. The main advantages of Unreal's Behavior Trees over Blueprint is they allow users to rename commonly used nodes to provide sensible names and promote arranging the nodes into discrete branches that can be visually inspected at a glance. This helps when developers must work with implementations created by someone else. Blueprints require very strict guidelines for scripters as well as thousands of comment boxes and node comments to achieve a similar result. Unfortunately, the final visual result will always be less approachable to new users than behaviour trees because of the higher text to node ratio and increased number of connections between nodes.
Blueprints are a powerful tool for empowering content creators in Unreal Editor 4, but developers should search for and be aware of areas like camera behaviours where other approaches may be more accessible, provide better feedback, and promote developers to create implementations that others can readily comprehend.
Blueprints are a powerful tool for empowering content creators in Unreal Editor 4, but developers should search for and be aware of areas like camera behaviours where other approaches may be more accessible, provide better feedback, and promote developers to create implementations that others can readily comprehend.
Bonus Content:
Method: Blueprint to support my behaviour tree
Newly added Blackboard and Behavior Tree 1. We have a Character Controller but our experiment also needs a Blackboard and a Behavior Tree, so let's add both of those.
2a. Our Side Scroller Character should run Camera Decision Graph with Event BeginPlay activating RunBehaviorTree (failed approach). Compiler Result: RunBehaviorTree's Target property can only reference an object of type "AI Controller" which means I have to try a new approach. Now I know a Camera Director object of type Pawn is required.
2a. Our Side Scroller Character should run Camera Decision Graph with Event BeginPlay activating RunBehaviorTree (failed approach). Compiler Result: RunBehaviorTree's Target property can only reference an object of type "AI Controller" which means I have to try a new approach. Now I know a Camera Director object of type Pawn is required.
Whenever the Side Scroller Character is spawned, it will create an Camera Director Pawn to choose which camera behaviours to display
A new folder containing AI Controller, Pawn, and other AI objects. 2b. Our Side Scroller Character should make a Camera Director to run Camera Decision Graph with Event BeginPlay activating SpawnAIFromClass.
3a. Create a Boolean key in Camera Blackboard to switch between cameras.
3b. Set Camera Director's default AI Controller to the intended one (missed step).
3c. Set Camera Decision Graph's Blackboard to Camera Blackboard (missed step).
4a. Initialize the PhysicsCameraEnabled key from the Side Scroller Character with SetValueAsBool for Camera AI Controller on Event BeginPlay (failed approach)
Runtime result: SetValueAsBool couldn't access Blackboard, variable out of scope. Also I found a typo in a MakeLiteralName, causing the node to always return false.
4b. Initialize the PhysicsCameraDisabled key from the Camera AI Controller with SetValueAsBool on Event BeginPlay. Requires steps 3b and 3c.
3a. Create a Boolean key in Camera Blackboard to switch between cameras.
3b. Set Camera Director's default AI Controller to the intended one (missed step).
3c. Set Camera Decision Graph's Blackboard to Camera Blackboard (missed step).
4a. Initialize the PhysicsCameraEnabled key from the Side Scroller Character with SetValueAsBool for Camera AI Controller on Event BeginPlay (failed approach)
Runtime result: SetValueAsBool couldn't access Blackboard, variable out of scope. Also I found a typo in a MakeLiteralName, causing the node to always return false.
4b. Initialize the PhysicsCameraDisabled key from the Camera AI Controller with SetValueAsBool on Event BeginPlay. Requires steps 3b and 3c.
On opening a Blackboard, we can create new keys and view properties for existing keys like the PhysicsCameraDisabled Boolean key
If MakeLiteralName's value matches the key name, the key value is set for any Blackboard on this object that contains the intended key.
5. Create "Act" functionality with GetValueAsBool for Camera AI Controller toggling a SelectTransform that returns Physics Camera when false, else Default Camera.
I kept the camera interpolation from the last article, but now we must get a reference to the Camera AI Controller's Camera Blackboard
AI "action" is implemented as a SelectTranform that causes the camera to interpolate to either Physics Camera or Default Camera
A BlackboardKeySelector provides a reference to the PhysicsCameraDisabled key, so we can store its value and override it temporarily
6. Create "Sense" functionality as a Service to be used on Behavior Tree nodes, using the Context Override pattern to set a value true on entry and false on exit.
7. Create "Sense" functionality as a Decorator to be used on Behavior Tree nodes, overriding its inherited PerformConditionCheckAI function to return useful values.
Note: We are using a key press as a proxy for less simple changes in game states.
7. Create "Sense" functionality as a Decorator to be used on Behavior Tree nodes, overriding its inherited PerformConditionCheckAI function to return useful values.
Note: We are using a key press as a proxy for less simple changes in game states.
This function has a return node that toggles a Boolean return value based on the state of the 'S' key, when pressed down it returns true
Caveat: There are undoubtedly better ways to implement "sensing, thinking, and acting" on cameras in Unreal Engine 4, and I will continue to post improvements to the methods and implementations in this test as Camera Experiment 1B, 1C, etc.
RSS Feed