Realizing Responsive High Fidelity Character Movement in Just Cause 3

[Music] hi everyone let's get started before we actually start we just need to send you a reminder to switch off any cell phones and please remember to fill out the evaluation Thanks right let's get started welcome to our presentation finding balance realizing responsive high fidelity character movement in Just Cause 3 my name is Alex Crowhurst lead animator Avalanche Studios and I'm here to teach ruff also lead character programmer at Avalanche Studios we're super excited to be here today as we have a rare opportunity to show you some of our feature work currently in progress and before the game is released so it goes without saying what you see here today is very much work in progress and it's going to continue to be worked on by the team until the day of release so before we dig deep into the presentation I think it's important to briefly frame the overall experience of

the Just Cause franchise so let's start with the three main pillars that are the backbone of the series at the heart of the franchise lies an open-world sandbox experience when a player can have complete freedom to play around with the world and its systems and just causing havoc and fun everywhere the second being fast-paced combat where player responsiveness is key to be able to move fluidity in through high pressure combat situations and finally vertical gameplay our character has the freedom to move from the land sea and skies seamlessly in any way that they choose so coming off from Just Cause 2 we wanted to push these pillars even further and take it to a next-gen experience and for Just Cause 3 the overall direction was to ensure we keep all the insane and crazy stuff you could do but grounded in a more realistic style and with that in mind one of our key components we wanted to

build on was a realization of characters most notably our main character Rico who you can see here in this image but the back of him at least from a design perspective there were two main goals we needed to achieve Rico must be highly responsive to player input the player needs to feel fully in control and should never have to wait for an animation to finish playing to make their next maneuver secondly we needed to maintain the fluidity of combat this means that Rico must maintain the ability to perform combat actions like aiming shooting and shooting even when transitioning between complex mechanics and states which results in seamless combat now neither of these were easy tasks by any stretch of the imagination on the realization end of things our main character our main character can do an awful lot in the world he has a full range of on foot locomotion set supporting many different kinds of weapons he also had uses his grapple hook in many different ways and in any

situation he can now stun and traverse on top of many different vehicles in any yeah in any and interact with him as well he can freefall he can parachute he can now wingsuit and that's just the tip of the iceberg of what seems an endless amount of mechanics we needed a way to help save us time and cleverly share as much content as we could across all these features secondly having such a responsive character is always going to fight against the realisation needed to give a character believable way to motion so for animation it's a bit like trying to fit a square block into a triangle hole it just won't fit so now that I've given you some background behind the challenges of jessica's 3 let's take a look at some ways some of the ways we attacked these issues alright so in this first section let's look at how we update the motion of our characters and I'd like to start by talking about the different character

movement models so first we have game driven movement in this case the game logic evaluates the motion of the character which is then fed into the physic system which moves the physical representation of the character in most cases this information is also fed into the animation system which selects and plays an animation to match the movement of the character if the game controller wishes to move the character forward at a certain speed depending on the sea depending on the speed a forward moving walk or run animation may be selected and played by the animation system the key point is that animation does not control or dictate the motion in any way the animations could be thought of as well authored on spot using this has some advantages it provides us with the maximum level of flexibility as it drives the character independent of the animation motion as well remains highly responsive as we're completely in control alternatively some games use

animation driven movement and you guessed it in this case the motion of the character is driven completely by the animation motion itself is also is also authored as part of the animation so we do this through the use of a reference node in ours in our system we refer to this as the root node and it sits in the highest point in the skeleton hierarchy the root node is an independent bone and represents the displacement and rotation of the character's motion during the animation the animation itself will contain the transform data for this bone for every single frame just like it would for any other bone we generally place this under the hips of the character throughout the animation and it can be hand authored by the animator so in order to move the character in the game we need to extract this root motion data out and then apply it to the character so in a simple example of a walk every frame we simply update the animation and read the Delta

displacement of rotations for the root which then basically moves the character in the game and we refer to this sort of extraction as the extracted motion of the animation animation driven movement certainly has some advantages our characters now look the best since the movement is updated exactly as it was authored the visual representation of the character now matches one-to-one with the motion and it maintains the intentions of the authored content a lot of games have now moved over to use this approach in the last few years and while it's improved the visual aspects of gameplay there's some costs our characters now start to feel a little bit unresponsive both in terms of performing and controlling an action we're now tied sort of to the animation and don't get me wrong some games can totally get away with this if they're slow-paced enough and precision and responsiveness isn't

that big of an issue so in our case we're after the fidelity of animation driven movement but to maintain character responsiveness our character can't always be fully animation driven in addition heavily using animation driven movement would mean that we need a lot of animation coverage to account for all the varying use cases that we encounter in a game like Just Cause 3 so here we're looking for the balance between these two worlds and what we want to do is we want to use the best of both of them together so let's quickly dive into representing motion here's a frame of a back pedal animation the red arrow here shows the facing direction of the character in world space the yellow arrow here shows the moving direction of the character since this is a backpedal they're opposite and finally we come to speed the speed in which the character moves or rotates will result in the change in displacement displacement or orientation of the character as you can

see in this video as he's backpedaling backwards in our system we can independently update each of these components using different combinations of these movement models often midway through the animation we also often found that any given use case required its own combination of updating these components in sort of slightly different ways so to do this one of the techniques we heavily rely on is what we call motion correction when updating any of the components of motion each of our States and even animations within them can decide which of these components will be either fully driven by the animations extracted motion which of them will be adjusted or corrected or which of them will be completely overridden by the game itself this is what we mean by motion correction a fundamental point we

rely on is the importance of decoupling the animations extracted motion from the animations pose update in other words instead of directly updating physics with the animations motion when it's updated we need to separate the two and then do this independently now this enables us to modify the extracted motion independent of the animation and then correct it in order for us in order for it to suit our game specific need all right so you may think well if we're already adjusting we're already overriding the motion then why use the extracted motion to correct it and why can't we just control the character and the key reason here is we want to limit these adjustments and corrections to be based on the extracted motion as much as possible and this will help us preserve the integrity of that original content we use these motion correction techniques not only to maintain animation fidelity but also to increase animation coverage and keep our motion responsive so here's an example

of one of our simpler character updates and I say typical because it's not always the case but generally speaking the first thing we'll do is gather input we do a little bit of motion evaluation to determine what's what's exactly required and then we decouple this we sample the animation separately and we extract the motion separately after that based on your evaluation an additional step is performed to either adjust and correct the extracted motion based on that evaluation if we need to do so we can then push that over to physics and if no adjustment or correction is made you can think that the character is being fully animation driven if we ignore all the extracted motion and simply move the character ourselves and the characters fully game driven now as I mentioned this is a rather typical character update we're not limited to doing these corrections before physics by any means we have cases where we apply motion correction in various

stages of the character frame including post physics for things like interacting with the moving object but just to get the point across this is an example of one of our simpler character updates alright so in this next section I'd like to go over how we use these ideas to realize our players on ground movement looking at some of the typical use cases like starting to move stopping and interrupting and maintaining movement it's also worth mentioning that for the purpose of this presentation we're going to focus on ground movement however these techniques are not limited to just that we use these techniques throughout realizing a lot of our other character feature sets as well let's start off by talking about starting to move in the case of starting to move we use transition animations as a way to move the player from an idle stance now the reasons for this are obvious if you see in the video animations like this play a big role in

visually conveying energy anticipation and acceleration that are needed to get a character to move from idle stance however we still need to support moving in 360 degrees of in terms of direction and to vert towards varying target speeds so from a gameplay perspective we also want this input that the player would provide to feel very immediate and precise one way to tackle the visual concerns would be to simply drive each component speed displacement and orientation of the character completely animation driven we tried this approach and things quickly got sluggish and unresponsive as we became bound by the physicality of our content especially accelerating to something like your top target speed is going to take time and that was too slow for the game also a given start animation can only rotate the character by a fixed amount this

made it feel like the character wasn't going in the direction we wanted especially if the pad input didn't match up with that authored animation in addition while the animation is still finishing we feel this you know feeling of being stuck in that direction in this case you can you can try to add more start animations to cover more and and then you need to account for all the different weapons different speeds and then your content starts to grow another approach could be trying to blend all these animations together to create more coverage here we've got a decent starting to run in the zero Degree direction start to run forward and here's another animation that starts the character to run at a 90 degrees to the left now on their own both these animations look fairly decent when we blend them together to get additional coverage see f45 things start to look a little funky now this is clearly an exaggeration but

too often we use this idea of persistently blending animations together for ground-based movement and that comes with a set of limitations if you've ever worked with animation you know that each animation includes a wide range of subtlety and body movement and stride which is the distance between each step when you move in order to ensure that these animations blend well usually you know you have to make your animator really unhappy and have him or her heavily dampened or eliminate all these subtleties in some cases the animations need to be authored with the same number of foot steps which limits us both from a stylistic and a motion-capture perspective so this is something we wanted to limit for our hour on ground movement especially because footsteps weight and movement are so tied together so here's the technique we use it revolves around combining these movement models and using motion correction all within the

same animation so the first thing we do is identify these key segments of our animation so here's an example of the start going from an idle to a run in 180 degrees if we step frame by frame we can see that the first part of the animation includes the character actually turning to face the direction that he wants to go in and we can looking at this we can basically say okay well this is our turning to face segment if we sit back a bit we can also see that around mid weight through this segment the character is pushing off his right foot and he's starting to move and he continues to do this all the way until the end of the animation is this is a start to move so we can refer to this as our moving section so there's a couple of things that are going on in this one start animation finally as this as a start again he's also accelerating to get up to that target speed and the idea we use is

during each of these segments we can update the components of motion differently to help alleviate some of the issues we mentioned before so the first thing to look at is creating more coverage and giving the player sense of control without having to sort of persistently blend those animations together to do this during the turning to face segments we can correct the facing angle of the character first we extract the rotation out of the animation and then we correct that rotation to give us the target direction we need and this is this is done by performing a fixed adjustment to the rotation after the animations rotation is extracted every frame so let's see an example of how this works at the beginning of our turning to face segment we've got a character facing forward at the end he's rotated an entire 180 degrees as authored well what if the player doesn't want to go directly behind and he or she chooses to move the

character uttering 150 degrees instead all right well using the same animation we just need to account for the Delta between the rotation amount for the from the extracted motion and the intended target direction to account for this Delta you can either add or subtract it out from the extracted rotation over the course of the turning to face segment while keeping that movement target fixed so in this case since the extracted rotation is going to overshoot we need to subtract this Delta out it's important to split this Delta into even rotational Corrections over the course of this segment to limit any slide or adjustment that the player might notice so on each frame we extract the animation rotation be corrected by that fixed adjustment that's been calculated and is now evenly being distributed on each frame to account for the overall Delta we keep doing this and by the end of the rotation segment since we have evenly

corrected out that Delta the character will end up facing the direction of his or her intention even though the extracted rotation was a full 180 degrees and this takes care of the facing angle or the facing direction of the character during the turning to face segment well what about the moving direction during the turning to face segment we can see that there is a little bit of a moving portion that overlaps between the turning to face segment and then it continues all the way after like we noticed when we when we saw the animation be played frame by frame well during this overlap we simply override the moving direction to be the same of the target pad at the time of playing to start now this means we don't have to worry about the compensation we're doing for curve or we don't have to worry about compensating for the correction we're doing in the facing direction by updating the facing and moving directions independently we can start to move the character sooner in

the direction we want even if he hasn't fully rotated to face that direction yet and we'll see an instance of this a little bit later well after the turn to face segment is done the start isn't finished yet the character still needs to continue to ramp up to get up to that moving target speed during this time we still need to update the facing and moving directions of the character since there's no more rotation that's coming out of the extracted motion the character is displacing in the direction he's facing for the remainder of the animation to control this we simply override the facing and moving directions to now be fully game driven to match that of the target direction so as the player decides to move the pad in another direction we procedurally override the facing angle and implicitly the moving direction to match that of the intended direction of the pad now we don't want to override this instantly as this would be visually jarring and unrealistic so we smoothly drive the current

phasing direction to match that of the target and we do this by defining a range of author acceleration angular acceleration rates these rates define how fast this current orientation will become that of the requested pad direction these these rates that I talked about are meant simply to match the responsive responsiveness needs as well as keep things consistent across all ground movement but you can use different rates to match different situations in the game for example if you're just moving about you can use a rather responsive sort of curve or rate and if you're doing something like laning from your parachute and then going into a run we can reduce the responsiveness to better match up with that of the animation you can also choose to use whatever smoothening algorithm you want in these situations overall this Gove's this gives us a better better responsiveness and control as we can continue to steer the character in the direction we want without having to interrupt the start

early and this allows the start to visually settle into movement which is what you know sometimes you reach the end and you're like let's just cut everything to make it responsive and want to prevent that now this brings us to our last point the responsiveness and displacement is going to be linked to how fast the character can be displaced as you can see in this slide in the original authored animation the character isn't really moving for a good chunk of time in the beginning well what we really want to do is we want to translate the character sooner you want to extend out this translation or displacement segment this will alleviate the feelings of being sluggish but still content but but still allow us to control when this can actually happen since we're already managing the direction of moving during and after that sort of turning to face segment we know exactly where we want to translate the character now it's also important to note that you don't want to extend this moving segment too far out beyond or you

know sooner than the turning to face segment and the reason for this is you want to kind of piggyback off the animations visual movement to hide the fact that we're starting to move the character sooner than what the animation actually intends so to do this we need to control the rate of movement that is the speed of the character in this case for our starts we do this by overriding the speed of the character via the game and evaluate the speed using author bullock seller ation curves as opposed to that of the animation so here we have an acceleration curve from the start animation it's just an example and we can see that the animation begins to move the character with a little bit of a delay it might be turning to face it might be doing whatever it needs to do and also it only reaches a target speed of roughly three point four meters per second all right well let's say our in game run speed is four four point meters per second we now author an acceleration curve that moves the character one

faster to get responsiveness and also better match up to the target speed which is going to be variable and change over the course of your project you can't keep on reshooting and reworking your content these curves are live tunable and are often based on the animations authored acceleration curve to begin with to limit inconsistency that the player again might notice since we're overriding the speed from the animation during the start surprisingly we were able to hide this adjustment since the animation that's playing is still conveying the visual intention of the character to further help with that fact you know the the fact that we're moving the character faster or slower than the animation depending on whatever this game curve decides we apply a technique to visually match the animations pose to hide this difference this is done by correcting the animations playback rate to match the difference in speed now since the pose and motion updates are completely independent we can do

this without it affecting the displacement when we apply this visual speed correction we need to use a reference speed that determines how much to scale the playback rate of the animation in the case of starts the target speed of each authored animation becomes the reference speed so this goes back to that idea of using your animations extracted motion and the way it's authored to influence you're gonna correct it this reference speed now becomes the base for how we're actually going to correct the storks in this case since the target speed is higher than that of the authored start animation we simply play the animation that much faster here the playback rate is going to be adjusted to be one point one seven times and this is done again to be within an acceptable range to ensure that the animation doesn't look too sped up or to slowed down so here we have it all put together in game you'll

notice the player pad input being displayed on the top right corner along with the pad target direction in yellow and the current orientation of the character shown in red you can kind of see that while he's playing these transition animations and starts he's still pretty responsive and you can still see you know good visual intention good animation of him moving in the direction he wants here's a closer look and to quickly recap we're updating the orientation direction of our character using animation and motion correcting the rotation while the displacement Direction remains game driven after which both directions switch to being game driven and speed is completely game driven using visual speed correction we're able to get 360 degrees of coverage using just five animations a 0 to 90 s and two 180s and on the NPC side we're able to get away with just using three it's important to note that we

also drive all our plant in turn animations as well as all our rotate on spots using these techniques with slightly different combinations and variations and you're not limited to just using this fixed adjustment either you we use dynamic adjustment to deal with aligning to a moving target for example or you're not limited to using this adjustment to just rotation we use adjustments like this that are split across the entire animation to fix up translation or displacement as well to end up on a very specific spot for example all right talking about stopping or landing on a spot in this next section we'll turn our attention to inter options and stops the motivation for stop realization the game is very similar to that of the starts you know stops will give us the will give the player immediate feedback of releasing the pad and will communicate the deceleration and the character's intention especially when moving at a high speed now in Just Cause 3 the need to stop responsibly and with extra

precision was uber important the design of our world is extremely vertical and the gameplay sort of is is based around that so we need Rico to stop on a dime when the player decides to release this pad even from a run primarily we want to do this to ensure that the player doesn't unintentionally get in a situation where he falls off things especially in combat which can be over frustrating so as Alex will attest you stopping on a dime is an animators nightmare it's both physically unrealistic and visually unnatural if you're using motion capture data you know and you want to capture this deceleration the data will always have significant motion in it in addition to all these issues we need to deal with stopping from various speeds differences in pose and turning while stopping as well so in the case of stopping instantly our first approach was to ignore all the extracted motion from the animation while this ensured that the

character would insta stop it just felt pretty visually jarring kind of pops so what we ended up doing was updating the moving direction and speed to be driven via the animation which includes a very harsh deceleration curve to convey the change in momentum and we could have done this in the game as well but it would have been buried you know pretty much the same thing because we're trying to you know get the character to stop very quickly since we didn't want to add extra coverage for all the slight differences in speed we play the same stop animation from a general speed range and account for any differences by using the visual speed correction similar to the starts in this case though we correct the animations playback rate to match up with the urgency of the current speed against the initial speed of the star fanimation which now becomes our reference speed so in the case of the starts we're using the the authored starts target speed as a reference speed

but in the case of stops we're using the stop authored initial speed as a reference speed finally the facing direction of the character was corrected similar to the starts using the fixed adjustment and this was necessary when we need Rico to stop and turn at the same time and he needs to maintain aiming at a target for example while stopping I'm updating the character this way we began to encounter some blending issues there are worth noting now these blending issues aren't limited to just the stop case they affect all situations where we're relying on the animations extracted motion to be used as a basis for correction or analysis so the issue is this that when we transition from one state to another and we're using a transition blend the roots transform data begins to blend as well since we just treat it like a regular bone so in this case we really want to exclude this blended displacement of the root of the previous cycle as it

continues to blend out otherwise the character still displaces forward as we're using animation driven movement here and that's not what we want we want him to stop on the spot so this could be fixed by simply setting to blend time to zero from the movement cycle to the stop however a transition blend of zero again something animators hate would pop the pose and look jarring which is again what we're trying to avoid in the first place the decoupling of the pose and motion extraction comes to our rescue again here we extend the idea to blend the animation poses and the extracted motion separately using different blend rates so we blend the pose of the movement cycle with the stop animation as we normally would but we do not blend any

of the extracted motions of movement cycle on evaluation or update and we call this pose only blending now this helps create the illusion of deceleration and it alleviates the visual harshness of the sudden transition you can also extend this idea to poor bone blending where you're using different blend rates for different bone masks creating the illusion of motion lag to say blend the upper body and lower body at different rates another key problem we had and I'm sure most of you have encountered is dealing with the mismatch of poses that occurs when interrupting and transitioning from animation States so in the case of our stops we had to deal with the scissoring of feet that occurs when we have to play a stop animation off fades and since we can't wait to play that stop animation we need to interrupt the cycle at any point to play the stop you can see the sort of scissoring that will occur in

the feet when that happens so you can solve this problem by adding more stop coverage more animations to best match up with that all those differences in pose but we handle these problems through the use of a technique called pose matching so instead of blending animations based on elapsed time we blend the two animations based on pose in most moving animations the pose can be defined by what we call movement phase as the foot goes from being planted to going into an upswing and then all the way back down to being planted again we can think of the foot as being in a swing cycle from plant to plant we do this for both feet the movement phase of a foot is then defined as the time where the foot is within its it within its swing cycle between zero and one and now we can use this information to know where in the we're in the next animation we should blend into so we can match up the poses for both these transitions now this

allows us to have an uneven number of steps within all our movement animations with that said for any given set of animations that you want to use this technique you need to define your face to be based on the feature that you're actually trying to match so for example if you're building some kind of punch animation and the swing would the phase would not be where you are in your kind of arm swing this phase information is generated offline and is stored as metadata which keeps our runtime calculations to a minimum states can also define whether to apply pose matching when they blend in and also when they blend out and looping animations for instance will do this they'll pose match on both sort of situations because they have all the phase match data they need for both left and right feet certain transition transition animations however they only want to pose match when transitioning in or when transitioning out and this is necessary because you don't want your pose match to skip the most important parts of your animation so now when we

apply pose matching we're able to interrupt and transition seamlessly into the stop animation in addition we can save on additional coverage simply by adding an extra step in that original animation and then just let pose matching blender sing alright since we've talked about transition animations to death let's turn our attention to maintaining movement unsurprisingly our core movement animations are authored or looping animations where the start and end frames are identical to allow us to play these animations again and again continuously now our character needs to be able to accelerate and decelerate and best match the movement to the magnitude of the thumbstick since the speed of displacement in these animations is fixed as well we need to find a way to vary our movement speed one way to tackle this is to drive the speed of our

character using animation driven movement map input to animations and then blend these animations together to create the in-between coverage we need and we all know how we feel about persistent blending so also in addition mapping input directly to these animations sometimes can result in that slow-mo walk or an extremely sped up run if the player is moving the stick in this analog fashion and then you're mapping that directly to animation so in Just Cause 3 our player character can either walk or run when moving on ground and the first thing we choose to do is use discrete target speeds of movement what this means is that for given ranges within our pad between zero and one the character moves that a set target speed for example if the pad input is between zero and point three say something like point two then this maps to a fixed target speed of one point five meters per second which is our walk between

point three and one for example we set a fixed target speed of five point five meters per second which is our run now the key reason for doing this is that in these kind of maintaining movement cases we don't need our character to move with the control of the pad in an analogue way in most games you rarely need this the target speeds we pick are also the speeds we want to support game play we can then go off and build animations specifically for this or shoot motion capture for these specific speeds by ensuring that our characters always targeting a core movement speed we're trying to ensure that we always get the best visual result these target speeds now also become our reference speeds which I'll talk about a little bit later even though you're always targeting a core movement speed our character still needs to accelerate and decelerate between these speeds to do this we update the speed of translation via the game and not animation this speed is

evaluated using author Abel acceleration and deceleration curves similar to how we described in the starts nears a an example of the curve in our in-game editor we then match up animation using speed ranges and we apply correction to them so here you can see our target speed set up at one point meters per second and five point five meters per second now no matter where you are on the pad our character will be targeting either one of these core speeds so we go off we'll get our animations in this case we have a walk and a run and now we define speed ranges each speed range is associated with the core movement animation in this example we set up a range between 0 and 3.5 to be associated with our walk a range between 2.5 and 5.5 is now associated with our run if our player was previously walking and now jams his pad forward wanting to run based on our acceleration curve our character would

begin to accelerate and pass from one speed range into another if the character needs to move at a speed that's inside say the walk range and we simply play the animation that's associated with that range would then apply visual speed correction again to correct the playback rate to match the speed of the character that's being driven by the game the reference the reference speeds that I talked about are these core target speeds now in this case so here we would slightly speed up the playback rate of the walk to match the fact that the character is going a little bit faster in the case where he's in the run range we would slightly slow down the run to match the fact that we're moving a little bit slower in game now since this is again strictly visual we can adjust the reference speed as we see fit in game to make sure that it doesn't scale the animations to be too slow or too fast to smoothly transition between the two ranges and prevent either animation from doing that from

being played too fast or too slow we allow the ranges to overlap to handle the transition between the walk and the run and only during this overlap while the animations are being visually corrected we allow the animations to blend together now since we're always targeting a core movement speed the character is never allowed to stay inside this blend or add even be in a situation where the animation has to be visually speed corrected for too long we can take this idea a little bit further we're in situations where we're aiming or shooting and the animations themselves are actually pretty different like a walk or a run or a relaxed walk and then a run where we have different steps and style once we reach that section of overlap we just allow the character to transition from from that walk to a run and skip the blend altogether and this transition animation can be you know corrected the exact same way like we've been doing with the starts and the stops to keep things

super responsive and maintained that sort of high fidelity so let's not forget about our facing and moving directions while maintaining movement their game driven the same way we correct the facing and moving directions for the starts after that turn to face segment based on those angular acceleration rates we just need to make sure that the animations route needs to be animated in a way where we minimize the curvature within its displacement all that means is you kind of want to keep the animal the character moving sort of like this in a linear fashion that doesn't mean that the character model can actually come off the route a little bit but you want to minimize sort of that way these stuff because we're actually going to be procedurally correcting that in game finally to top things off we add a procedural lean to show off the momentum change that's necessary for turning the character in game this leaning is linked to how fast

the characters turning and is also clamped and stabilized to prevent it from going out of control we've noticed if this sometimes can go unchecked in games your character starts to feel kind of drunk as he's kind of oscillating back and forth as he's leaning about alright so solving responsiveness in movement was one thing but we also needed to make sure that combat was responsive and seamless as well right so combining actions being able to combine actions together is a vital way to ensure combat could flow between features I think this image pretty much sums out to a tee Rico's in midair really in two most likely what is an enemy helicopter whilst at the same time firing at a crazy rocket launcher and he can do this all throughout the whole of this sequence so if this doesn't if this

doesn't give you an essence of how insane Rico is I don't know what will what this means though is that we still need the animation coverage to support all of these actions the way we choose to solve this problem is to use animation masking this allows us to split our base content into building block chunks which are created which are created at compile time through the use of bone masks we then reassemble these animation masks with our base state machine to build up the poses we need adding no additional cost to runtime in addition animation masking allows us to be memory efficient data that can be shared is exported out as a mask only once this mask can then be reused as needed we can think of our final animation pose as being built at runtime from a combination of these bone masks so let's dig a little deeper into the air into the example let's imagine this image is

an unarmed idle animation it has no other dependency so it can be a full-body animation so all bones are included in this set however as we build our content to hold weapons such as rifles we realize that we can probably share some data we can reuse a lower body part of the animation but we want to adjust adjust the upper body because if he's standing in idle pose we'll need to adjust the spine and the arms to really match up to hold a rifle so as long as the the animation is in sync with the lower body we should be able to maintain all the nice motion coming through from the original idle we can then base all of our weapons sets off this animation so how do we do this we firstly masked the original animation into to a lower body mask in an upper body mask we then share the lower body mask with a new upper body rifle idle animation to combine and complete our

rifle wielding Idol so what if a designer comes up to us and says we now want to add rocket launches into the game we realize that we can probably share the head and torso of the rifle of the rifle upper body animation as the overall stance is pretty similar to that however we'll bring an RPG using the rifle arms is going to mean that the RPG is going to start cutting through Rico's body so we further separate the masks to reuse their rifle head and torso by creating an armless upper body mask we can then create a unique RPG arms only animation in red to complete our RPG wielding Idol this account's there are two different weapon types we need coverage for so what we what we end up with is a lower body animation that can be shared across all these cases and unarmed upper body animation that needs to be its own content a head torso

animation that can be shared across all weapon types and specific arm only animations meant for individual weapons splitting up and combining these masks allows us to minimize animation memory and eliminates a need for creating a lot of unique full-body animations and it's also completely up to the animator to decide the level of granularity we need so here's a here's the result of applying this technique on Rico in-game you can see that the master I just talked about all building up to create the final animation of the character so our masking system is pretty robust and flexible but we also need a way to overlap all our animations so we use animation layering to tackle this problem our animation system allows our characters to include multiple layers the first layer includes our base animation content by masking this we're ensuring that the data here is only

or into the memory once in other instances we need to be able to perform additional actions that can overlap overlap multiple states to do this we add another layer on top of the base layer to play overlapping animations that have also that also have no major dependencies on that base content so it's ideal for such things like reload animations they can be masked on top of the arms or three-cone can move through any transition animation in the base layer we then include another layer to handle additive animations that need to be synced with our base actions and this is used for something like aiming up and down vertically and finally we can add a layer to handle additives that can also overlap multiple states this helps us to give texture to our characters performance in this example let's say Rico is moving across the top of a jet stunting or whatever and the jet is obviously moving at a fast speed so we

can enhance this feeling by bringing in an animation additive that makes Rico's clothes and buckles moves and react to the wind these layers are then sequentially updated at runtime of each pose being passed through into the following layer finally creating the final character's pose in-game so to wrap things up techniques combining movement models and correcting motion give us the responsiveness and coverage we need without killing the fidelity of our animation using masking and layering to combine actions gives us the ability to share and reuse animation content and further minimize the amount of authoring we need to do well we hope this was an insightful look into our techniques and systems and we hope to share our aiming movement and other feature set solutions with you at a later time hopefully post launch but for now we cannot wait for you to play this game

and push on / experiment of our mechanics so thank you very much and we can invite the room for questions [Applause] hi going back to your phase matching portion you're talking about you identify phases in the animation where the foots planted or in full swing I was just curious how you guys do that is it automated by a script or do the animators actually manually identify those moments so what we do is uh so the question was how do we actually figure out how to generate the phase matching data and currently basically we have the animators add a key on all plants and then we have a script that basically runs and looks at the height between plants to kind of decide what the swing is actually going to be so are things like walks and runs we use different

height values to kind of know what the max swing will be and then for now because all our walk and run content is roughly of the same height that script kind of gives us good enough phase match data and it doesn't have to be perfect because we're actually blending as well but it's good enough and you could you know make that as complicated as you need it to be but this was good enough for us that sounds thank you great talk I was curious how you guys handled interruptions of transition animations if you need to change your mind mid transition how'd you deal with that sure the question was how do we deal with transition animations to interrupt sets of movement I guess and I mean we just play the animation right so basic and using kind of these segments we can kind of define interruption segments as well hey when is it okay to start interrupting this animation and you want to you don't want to kind of push that interruption segment to be too far out because then you're fighting with responsiveness again but say something like a start you know I kind of hinted

to it and then the video it had some planet in terms that were also playing so say for example you're playing a start and suddenly you decide to go in the other direction we play a plant in turn animation to get you out of the start and then while you're doing that you're doing the exact same movement correction on that plant and turn to now correct it in whatever direction you wanted to go and start steer to plant and turn itself so you have that coverage to allow you to interrupt animations and then use the exact same techniques on all that content to give you the responsibility were you continually adjusting the rotation angular rotation throughout the transition animation that's a good point we don't we don't want to do that all the time in some cases we do but when it comes to starts and plants you kind of want a little bit of time where the character actually isn't being kind of spun in a different direction because then again you're going to break the animation believability like if I'm turning this way a night the game certainly makes me go that way it's

going to break so you kind of want to wait at least until it's a good time to do that and then either plant off this foot and then allow correction using these kind of data-driven segments that I talked about cool thank you hi did you guys have for your start animations did you have like stand to walk animations yes you did how did you handle like if the player moves to a run speed in the middle of the start animation right so I mean based on that padding but that I talked about if the target speed actually happens to just be a walk and you happen to be in an idle we just play a start to walk start and are those not long enough that the player can't try to go into a run in the middle of the start exactly so while I'm playing that walk start if I happen to jam my stick again I can either play a transition if I want to or I can just allow that to blend the kind of same way we we talked about but actually in the case of if you're already playing an

animation like a start a transition animation you want to just interrupt it with another kind of start to run transition that would be better than actually blending it because it'll look weird if you blend the transition to a cycle okay thank you the I love just cause to thinks one of the cool things is very organic environments you can do a lot is there like a maximum angle that the character can run up and what at what point do you just kick him to a slide as opposed to letting in free nav up every surface are you are you sorry the question was what is the max angle that the character can run up and down yeah yeah I mean we want to definitely have not exactly sure the design thing is I mean we try to get the character to support as much movement as possible especially going up and down and we you know especially in this game we're using techniques like a and stuff like that to help extend that range further but we the locomotion system would handle that to allow you to

basically move up a slope as well as go down right hi my question is about network so you guys develop a lot of solutions how much of these solutions worked on a network with multiple players on a network we haven't tried that yet like in about the mocap system and how do you guys measure that it's five point five miles an hour or one point three is you know a treadmill or do you guys I ballin I mean one yeah I mean I mean we went through an iterative process of trying to find out what speed would work really well for for our character first of all we had in sprinting around the world and it was just way too fast and we actually needed to slow him down quite a bit to be up to be able to be quite responsive so you know we took that to the motion capture data we kind of found that data that was good to play and we set out like yeah we

need it to be this speed but luckily the tech allows us to be able to like manipulate it within those realms so you know it's good in that way okay so you fudge it a little bit the mocap to get to the right speed yes yes thanks all right everyone thank you [Applause]