Author Archives: Tom Betts

Sir, Unity, Mecanim And The Trials Of Small Studio In-Game Animation

Posted on by

We thought it might be insightful for you guys to be able to read a bit more about the challenges we’ve faced in completely overhauling our animation system since the success of our Kickstarter. As we mentioned in that pitch, animation is one of the key challenges for the game, and we feel we need high quality character animation to really make the experience work. So that’s what we’ve been doing. However, it was not without complications.

During the time where we were working on the initial prototypes for Sir, we were lucky enough to get Frogames‘ Christophe Canon to produce some great character art and an early model for the main enemy NPC, the Hunter. At this point we didn’t have the resources or time to commission a full animation set for this character so we looked around for alternative quick solutions – something that Unity has in abundance.

IK And Smart Locomotion

Rune Johansen’s dynamic locomotion system for Unity was an obvious choice, because it does so much without us having to code very much into the game.

Runes system

Rune developed it for his Masters thesis and it’s a really smart piece of coding. It’s essentially a procedural animation blending system with foot inverse kinematics, or “IK”. This means that characters to which it is applied will walk realistically, placing their feet sensible on the terrain they traverse. We implemented it with a series of animations from Mixamo.com (an autorigging service that applies generic animations to any humanoid model).

Once we had our initial Hunter model and a set of animations we could use Rune’s system to blend them together. Rune explains how this works better than we can:

“The system uses a set of example motions primarily in the form of keyframed or motion-captured walk and run cycles. The system automatically analyzes each motion at design-time and extracts parameters such as impact and lift-off times for each foot as well as overall velocity. At runtime the system first blends the motions according to the current velocity and rotational velocity of the character, it then adjusts the movements of the bones in the legs by means of inverse kinematics to ensure that the feet step correctly on the ground.”

So for an attacking stance you might have the following animations (walk forwards, run forwards, strafe left, strafe right, walk backwards etc.) Rune’s code examines each of these animations and then can pace and crossfade the animations dynamically to match the characters movement. The system is also capable of aligning the characters feet to the surface between them and then cascading the bone changes up the transform chain (IK).

All of these features require some setting up and tweaking but can result in a genuinely dynamic and adaptable animation system. The net result is a character whose feet and legs remain solidly and realistically rooted the ground, bending and blending procedurally to create really believable connection to the floor, regardless of changes in movement vector. Of course the underlying movement is not Root-motion based (where the distance travelled in each animation loop is dictated by the animation loop itself), but constantly variable. The only disadvantage to this system is that it is (understandably) very complex and can be a significant performance hit if you intend to run multiple characters – which for Sir was a big problem…

Mecanim

When Unity4 introduced their Mecanim animation solution we were excited to try out the new system, hoping it would provide us with a similar system to what we had enjoyed with Rune’s work, but with less overhead. However it took quite a while to readjust our models, animations, and code to get a satisfying result.

Mecanim provides a “blend tree” system where animations can be crossfaded in realtime based on script-sent input values. For instance this could involve defining a series of blend states to mix between a walk and a run animation based on an passed speed value. This area of functionality is similar to the original blending functionality of the locomotion system we used before – in fact it offers far greater control of the process – but it involves more manual setup via the Mecanim ‘Animator’ tool. The Animator essentially allows you to minutely build and fine tune blend trees for your character’s animation. Where before Rune’s loco system did this on the fly, it was now down to us to rebuild the rules governing what anims to play with what blends at what time. No small task!

To Root or not to Root

Most Mecanim demonstrations use root motion based movement because blending animations generally works best when the animations are mixed at specific loop points (i.e. moving from a walk to a run works best when the ending of the first animation has the character’s feet in the same position as the start of the run). Root motion approaches often imply that once a character has begun a specific animation they can’t react until it has reached a convenient loop point (an example is in many games where an enemy will continue reloading even if staying in that pose exposes them to a rain of bullets). Our NPCs operate in a procedurally generated world and function much better if they can stop and alter their motion and behaviour mid cycle where necessary. So instead of converting all our code to work with root motion we decided to try and implement a mix of Rune’s procedural system and the new Mecanim blend trees.

As a result, each character in Sir has a script that tracks the velocity, turn speed, strafe speed, heading and other motion values. These values are then sent to whatever current Mecanim layer we have activated on the NPC (we have a layer for each behaviour; attacking, fleeing, hunting, searching, roaming etc.). The blend trees in that layer then resolve the final animation mix that is appropriate for the characters current behaviour. This can result in a few rare hiccups where an animation crossfade happens at a non-ideal cycle point, but with careful setup of the blend trees and clever animation design such instances can be minimised.

This approach also gets tricky when a character has the potential to execute a wide range of movements. It’s convenient to branch animation blend trees first by velocity, then by turn speed for example, however if a character can strafe, turn and walk/reverse the tree can quickly get complex (Of course this would also be true for a root motion based animator too). Finally, we can also control the overall animation speed of any layer (attack, flee etc) from the AI state itself, so we can easily speed up a particular behaviour and adjust the animation speed in the same script.

Compromises

The loss of the original IK system is a compromise we had to make. It felt like a big loss, but the advantages of another system were clear. The Mecanim solution is a lot more efficient and allows us to have more active NPCs in view at once, which is clearly more important to the game than exceptional foot placement. The majority of AAA games do without foot IK on models and however nice the original IK looked our NPC hunters are often knee deep in grass or peering over walls to shoot you, making believable leg movement pointless. You generally don’t have time to admire the enemy footwork while running for your life through the bracken, either.

Ultimately we think our experience with these two different approaches to implementing animation show the complexity of the choices faced by developers working in the kind of environments we are using to build Sir. It’s rare that one piece of tech or middleware will do exactly what you want, and that’s the reason why so many larger teams choose to write bespoke engines and code for their games. When you are a small team like us, it’s wiser to appraise the solutions available and then weigh the advantages: the system that is most efficient, and easiest for the designers to tweak, is almost always the winner.

If I May Speak Procedurally, Sir: Building The British Countryside Generator

Posted on by


We’re making our open-world game Sir, You Are Being Hunted using some procedural techniques. The most important of these generates the environment from raw scenery materials. This post details a little about how that process works.

The British Countryside Generator, as we’re calling it, is our procedural world engine for Sir You are Being Hunted. It’s plugged into Unity, which we are using as our overall development toolbox. It’s still a work in progress, but already delivers much of what we want for our game world, without us having to hand-place environmental features, as you might in traditional level editing. You can see some examples of the environments produced by our system here and here. (Continued below)
Continue reading →

On Structuring Things In Unity

Posted on by

Ok, so I’ve been using Unity to make games (and other interactive prototype work) for several years now. I’ve been the main coder on Fallen City (Our 15-month development for Channel4). Our audiovisual puzzler Avseq (which is en-route to Steam) was also rebuilt in Unity, and I’ve also coded a suite of android/iOS mobile games. Alongside these finished projects I spend a lot of time prototyping various procedural tech and other experiments, and of course working on our next game Sir, You Are Being Hunted.
Continue reading →

Building Hunted’s AI: Some Fundamental Elements

Posted on by

So Jim has been going on about how dynamic AI combat is the heart of Sir, You Are Being Hunted – let’s look at what that means from the perspective of the development work we are actually doing. I’ve illustrated this with a few shots from the AI testscenes build, which shows some of the “scene view” elements of Unity’s editor. Obviously the scenery and so forth is placeholdery and not actually intended to be seen as the sort of scale or density we’re expecting for a final game.


One of the key features we wanted in Hunted, was the ability for enemy AI to behave as autonomously as possible. Rather than groups of AI being introduced at scripted intervals and exisiting only to provide staged skirmishes for the player, we wanted to see them wandering about the landscape with their own objectives. This adds a significant level of complexity to any AI design.

The enemy NPCs in hunted come in several varieties. The main class are the mobile hunters – the red visored chaps you’ve seen in the first few screenshots – these guys patrol from one location in the world to another, and on arrival will rest, interact with one another and perhaps search the local area for tresspassers or loot. To facilitate this I designed a procedural generation system that places detailed areas of interest (hubs) across the world, connected by trails across the intervening terrain. The hunters move in squads of different factions and travel along these pathways between the hubs. Navigation is done via a nodebased a* network, which is created and stored at the same time as the world is generated. Hubs contain a much higher level of detail in terms of obstacles and waypoints. Hubs generally attract both the player and NPCs as they are generally the location of valuable resources and cover/safety. The wandering hunters have several states of behaviour, governed by a simple Finite State Machine manager. The states are:


Wander: NPCs move between hub locations based on various internal reasoning algorithmns, sometimes they will stop for a while and rest, or even loiter on roads outside of the settlements.

Alert/Search: If an NPC hears a nearby sound, or sees either the player or another NPC from a rival faction, they will switch into this state. In this state the hunter approaches locations close to the last heard sound or last sighting, their viewcone detection increases and they will continue exploring nearby areas until they encounter an enemy or eventually get bored and return to wandering.

Combat: If a hunter sees a target and can approach to within combat range (dependent on the range of their weapon etc), they will do so. In this state NPCs will reload and move to keep in range of their target and when losing sight of the target they will attempt to round appropriate corners to track them down.

Cover: Every time an NPC is injured they have a chance of switching to a cover-seeking state (more likely as they become more heavily wounded). When in this state they abandon all combat and run to the nearest cover location (essentially calculated from a list of locations that are out of sight of the enemy that is pursuing them). Once in cover they will constantly look around themselves to spot any chasing enemy. If found and attacked they will run on to another potential safe spot. If safe for long enough they will regain their courage and return to either a combat or search state.


When two opposing squads meet at a hub they react to each other in the same way as they would to the player, a skirmish occurs and one side will usually end up wiped out (though occasionally they may pass safely by each other or a few stragglers may escape to wander onwards). Debugging this sort of AI is a tricky task, as the character models don’t (currently) easily indicate what state they are in. To remedy this I draw a number of helpful indicators in the scene window. Icons above NPCs show their states, their HP and their faction. Viewcones, target lines, shot lines and sound lines are also available. The system is going to require Jim and James to spend a lot of time working on balancing, as we have to deal with situations where other players and NPCs also enter the fray (at the moment hunters that are infighting will only switch to the player if they are significantly closer and not already engaged).


Right now the framework for all this behaviour is in place, and we now need to start making it function as games usually do – with visual feedback that can understood in the context of the game, and the appropriate behaviours for a player to work out what is happening, and successfully interact with the AI. We’re hoping to have a “test village” up soon, and from there we’ll be able to show off some of the behaviour in motion – complete with some more tech bells and whistles that will make the factional battles believable and compelling.

In future we’ll talk in a bit more detail about combat behaviours, and also the way in which we intend to enable to hunters to actually track down the player.