This example of a state machine for animations is copied from the Unreal Editor 4 documentation. Click the picture to open that website.
Animators who use Unreal Editor 4 are already familiar with state machines. Why can't those be used for cameras too? State machines' other benefits include:
- The player avatar actions are most likely controlled by state machines as well, allowing straightforward communication between camera logic and avatar logic
- The animation state machine systems are intended for seamless transitions unlike Behavior Tree which is intended for discrete and immediate AI changes
- The implementation of state machines in Unreal Editor 4 has high usability, with many user interface features that provide relevant information at a glance
- Unlike Behavior Tree's which either go to the Root or the next sibling in a Sequence, State Machines are capable of transitioning between any two states
A BlendTree-style state machine defining avatar movement (not animations) in Battlefield: Bad Company. Click to see original context.
When it comes to gameplay cameras, the quick answer to why to choose behaviour trees over state machines is flexibility. Flexibility, in turn, allows the underlying systems to be reusable across multiple projects - and therefore provides more sustainable development practices.
There are practical limitations to using the animation state machines for any camera system that allows real time control by the player. While it would be possible to rip apart the state machine graphical display elements and make their code work with camera behaviours, vanilla Unreal Editor 4 state machines are only compatible with skeletal meshes. This is a common limitation of state machine visual scripting modules because they are often streamlined for animation. As a result, we see similar limitations when using Unity's Mecanim: it is built for blending and transitions between animations that have exact definitions where cameras require adaptive behaviours to address their "fuzzy" constraints.
Let's put the implementation of state machine modules aside and look for proof that behaviour trees bestow more flexibility for camera behaviours than any ideal state machines. The purpose of this experiment is to use nonfunctional examples to compare Unreal's implementation of Behavior Trees and State Machines for similar camera behaviours. The "Sense" and "Act" aspects of behaviours were not created.
Our starting point for this experiment is any project with Animation Starter Pack, which can be added to your project for free from Epic Games in the Marketplace.
There are practical limitations to using the animation state machines for any camera system that allows real time control by the player. While it would be possible to rip apart the state machine graphical display elements and make their code work with camera behaviours, vanilla Unreal Editor 4 state machines are only compatible with skeletal meshes. This is a common limitation of state machine visual scripting modules because they are often streamlined for animation. As a result, we see similar limitations when using Unity's Mecanim: it is built for blending and transitions between animations that have exact definitions where cameras require adaptive behaviours to address their "fuzzy" constraints.
Let's put the implementation of state machine modules aside and look for proof that behaviour trees bestow more flexibility for camera behaviours than any ideal state machines. The purpose of this experiment is to use nonfunctional examples to compare Unreal's implementation of Behavior Trees and State Machines for similar camera behaviours. The "Sense" and "Act" aspects of behaviours were not created.
Our starting point for this experiment is any project with Animation Starter Pack, which can be added to your project for free from Epic Games in the Marketplace.
RSS Feed