All Categories

Prince of Persia (2008) Camera Analysis 01

4/9/2016

This camera system is relatively well-documented and gives a glimpse of Ubisoft's attempt to make a sustainable camera system for use on multiple projects. No further sources I found have indicated whether this system was actually used again after Prince of Persia (2008), or if that was an ideal vision that did not come to pass.

As a result, my analysis is based on my experience of the game as viewed through a lens that is heavily influenced by Jonathan Bard's talk "Directing the Prince Of Persia." I attempt to provide information to fill in the holes left by this presentation, but some details may be inaccurate.

Camera Mechanics

The first six of 17 camera mechanics are described in the talk. I will list them, but refer you to the link above for more details. The ones that follow were observed during my playthrough of the game and are accompanied by screenshots from the 2016 WR Speedrun by samabam14.

1. Fixed camera
2. Spline Camera
3. Free-Roaming Camera
4. Animated Free-Roaming Camera
5. Movement Compensation Camera
6. Dueling/Boss Camera

6 Comments

Camera Experiment 2A: Flexibility in Camera Behaviour Trees

12/6/2016

7 Comments

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.

7 Comments

Camera Experiment 1B: Behaviour Trees for Gameplay Cameras

11/6/2016

4 Comments

Notice the (aborts self) and (inversed) properties which are critical to the functionality of this Behavior Tree. The Selector is also required.

While revisiting this experiment, I found the quality of results are greatly improved by removing the BTService_SenseContextOverride and creating new Tasks instead. The "Act" functionality is elegantly replaced by StableCamera and PhysicsCamera nodes that also avoid the unwanted jitter from the previous implementation.

The StableCamera Task sets Physics Camera Disabled to true, while the PhysicsCamera Task (not pictured) sets that key value false.

4 Comments

Camera Experiment 1A: Behaviour Trees for Gameplay Cameras

14/5/2016

268 Comments

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.

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.

268 Comments

<<Previous

Forward>>

Telling stories through captivating gameplay.

Prince of Persia (2008) Camera Analysis 01

Camera Mechanics

Camera Experiment 2A: Flexibility in Camera Behaviour Trees

Camera Experiment 1B: Behaviour Trees for Gameplay Cameras

Camera Experiment 1A: Behaviour Trees for Gameplay Cameras

James Dodge

Categories

Archives