Making the Believable Horses of 'Red Dead Redemption II'

Hi and welcome to making the believable horses of Red Dead Redemption 2. My name is Tobias Cleanthus and I'm a lead AI gameplay programmer at Rockstar Games. I'm based at Rockstar North where I look after a team based at Rockstar North and Rockstar India that focuses on core locomotion and movement in our video games. And today I want to talk about one such example which is the horses of Red Dead 2. So let's have a little look at what we're going to talk about today. Uh I'd like to discuss where we started out at first and what our goals were with the horses of Red Dead 2. We'll then go into talking about freedom of movement and how this was critical to delivering the behavior of our horses in Red Dead. We'll follow on with some discussion about gates and speed and their impact and responsiveness of the horses in the game. We'll then look at riders and how we synchronize their movement with horses. Following that, we'll discuss the environmental awareness of our horses and how we cope with such varied

terrain. We'll also talk about the personalities of our horses and the differences in breeds before wrapping up at the end. So, starting out with Red Dead 2. So, we had a lot to follow on from the first Red Dead Redemption. We knew we had a big task following on from people's memories of John Masten's story. We knew we wanted to make sure that the horse was going to be a best supporting character for Arthur Morgan and not simply like a vehicle or mode of transport. We also knew this was Rockstar's biggest game world so far and there was going to be huge variation in the terrain and that would become very important to sell a grounded experience players. We also wanted to make sure that throughout the game the player was left with an emotional attachment to their horse through a story and beyond into Red Dead Online. So coming from GTA 5, we had a big revamp of a lot of different code systems. One of which was our locomotion

systems which we attempted to unify several disparate systems for animal, human, and horse movement into one. We also knew that we were going to change things to be a lot more grounded compared to the world of GTA 5. Red Dead's world is a much slower pace and so we focus quite early on bringing in our horses into this new technology. So I want to have a look at a first example of where we got the first couple of months. So just having a look at this I think we'll see a few ranges of gates of movement. So, walking and canering, trotting, we'll also see some of the transitions from idling and stopping. And looking at this, I think it'd be fair to ask, what's wrong with this? And why didn't we just ship it at this state? And I think there's quite a few different points that we looked at when we were evaluating it early on. It definitely was very functional, but we had some problems with a very discreet range of speeds. There was no range nor

variation. something that would become critical as we worked on things such as the gang gang riding together with Dutch and the gang. We also knew there was a very limited range of movement at this point. We simply had some turning animations and some transitions to go with. We also found that the turns were quite stiff with the quadripeds. We found the body would be posing in a C-shape as it turned left and right. So, as we combined those assets together, we had to slow them down, reducing responsiveness so that they could blend together acceptably. And generally a lot of our transitions were very discreet. So they're quite lumpy and inconsistent. And this is definitely something we wanted to solve the ship. So looking at this, we went back and wanted to understand what the problems we were seeing were. It's definitely functional, but missing something. And I think as I said when we started out, we wanted to make sure that the horse was more than just a mode of transport for a we wanted to see if we could get a livelier performance. And we wanted to see if there was a large amount of behavioral implications that we could

get from vastly expanding the amount of movement. So to look at how we could introduce this kind of believability to the horse, we started to look at capturing footage of real horses moving here in Scotland. So I want to just show an example of something that we caught which very early on became incredibly important to us. And this is a case where a horse is turning but using a lot of lateral movement to initially do it. So, this is really exaggerated because we wanted to capture an example of it that really showed it off, but I just want to run through and show what I'm talking about. So, initially, as the horse goes into a turn, you'll see it keeps its body oriented forward. As it starts to turn, it's going to side step before it peels into the turn. So straight away capturing this, we realized that adding that extra degree of freedom of movement to the game was going to be incredibly important. And so this leads me to talking about freedom of movement and how we added this to the horse.

So the lateral movement that we saw in that video, something that became incredibly important when we decided that we were going to use this to assist the movement without having to have very slow blends to avoid those kind of weird shapes blending left and right assets together. We also wondered with this whether we could use it to deliver something that would in in effect give a large amount of character to our horses in game. So could we give an indirect kind of notion of control by giving a responsive movement direction but lagging behind their orientation? It turned out to be one of the most integral features that we developed for the horse but it was also one of the most difficult. So I just want to show an example of what we actually had in our first outline bringing back movement into the horses. So we quite rapidly added these into our blend trees. We would have assets blending on X and they would work with our turn assets and our forward assets. And initially gave us the idea, but it was a little bit slippery to look at.

So why was that? For us quite early on we found that we had significant problems with the usage of blend trees in our tech. So, we're all kind of familiar with these arrangements of blending animations together. Um, they're incredibly useful, quite liberating for animators, but for us, they came with a significant amount of problems when we were trying to integrate this kind of movement on our horses. So, for one, our structures were very much explicitly put together. They didn't actually automatically pick up features from our animations, which meant as soon as we wanted to change them and add more, we would have to make more complicated graphs. If we wanted a different style of movement, we would have to make another graph. And overall, this is kind of explicit manipulation of them became very very complicated for us. So we looked forward to automating extraction of our features and what we could do to move away from using these bone trees and arrange 3D spaces of our

assets that would automatically extract root motion or movement of individual bones and combine our assets without any human intervention. This meant that we could then move away from having programmers or animators having to put together graphs every time they wanted to add a new movement. But it also meant that we could vastly improve the accuracy of what we were adding in. So I just want to have a look at what I'm talking about when I say adding in these 3D spaces and go over the different dimensions we were looking at. So for our 1D dimension, we were looking at the angular velocity. This is pretty much what we had to begin with. Um by improving the automation on this, then we get a more accurate result, but we still don't get rid of that problem of blending left and right masses together. Then we introduced uh linear velocity onto that just on XY. That gives us some speed control, gets rid of our problems with discrete speeds I was talking about earlier. But again, it doesn't help us with those problems with turning. And so lastly, what we need to add on is that

lateral velocity that I talked about earlier, which is effectively strafing for our horses. So what we would do put together the groups of assets required for something like a caner cycle set up the system to automatically extract our root motion on x and y plus our angular velocity and this will then arrange those assets together. The great thing about this though was that even for similar gates of movement we could choose how many assets we would put in there and not have to go and explicitly create a structure every time. So we could have more detail in certain places and less in others. So with that in play, let's go back and have a look at another example with a real life horse. So talking about the lateral movement and what that actually enables a horse to do, I wanted to look at an example with horse actually pivoting around its front feet. This kind of movement is something that became really important to us in the game and a feature we actually added in. So, as we get got this horse to turn in a tight circle,

hopefully you can see the vast majority of the movement is kind of pivoting around the front feet rather than typically as we might do in a video game with some kind of route underneath the torso. And there's not actually very much forward velocity here at all. It's almost all entirely on X or lateral velocity which allows us to do this turn in place. So this was something that we ended up calling drift. So drift added into Red Dead straight away enabled us to deliver this notion of indirect control of our horses because immediately we have some freedom of movement which gives us the ability to control the movement direction of a player or AI's horse accurately without having to snap them into the orientation immediately. We can then give really consistent control on that movement direction, but choose to lag the orientation for lots of different purposes. And again, that gives us that

notion that the riders not totally in control of the horse. You're not steering a car with an immediate response. The horse is trying to interpret your input. So, one thing that is missing from this I haven't brought up is what we did at zero. Now with left and right assets combined, there's a position at the zero velocity, zero angular velocity whereby you basically need some stepping on the spot. And with the horse, this was something that we decided we could make a bit of a moment with. So this is a a dress move that's typically referred to as PF that we added in. And we caught some of this in Mocha and found that it had a huge amount of character. So we wanted to replicate this and have this available for us across all of our gates on our horses. So here's the example in the game. Now with this added in, this also means that across all of our gates from a horse can countering to a horse walking or trottting, they can go all the way up to their top speed in that gate and all the way down to zero, which gives us a

great deal of flexibility and gets rid of those discreet ranges I mentioned earlier. So, breaking it down, I just wanted to go over the um sort of breakdown of what drift actually is for us in Red Dead. So, with all of our horses, we always have a zone roughly in front of them where we don't much care about adjusting their orientation. We'll respond to movement directions, but we'll very loosely adjust the orientation as you move along. As a horse commits into a turn, then we'll start to expand that region and gradually turn closer towards the movement direction. And then as we can persist with that using all of this free movement we've got available now, we can also make the horse over steer. So we do another thing to introduce that idea of indirect control making the horse over steer because they don't know when you're going to peel out of it. And this gives us an effect this kind of drifting move of skidding out and back into straight movement. And so here's an

example of that first working al together um in red during development. So hopefully you can see here as we go into the over steer then we gradually straighten up but the movement direction stays consistent here we can see that we could then exploit the strafing a lateral movement and then gradually peel back into turning again. Here it is working on cancer as well. So with all of those together, we have a great deal of freedom of movement. And I wanted to then talk about gates and speeds come with this. So I don't want to make any assumptions um about what people know about horse gates. But let's compare this to looking at how a biped moves, which hopefully we'll be familiar with. So typically we'd look in a game of having something like walk, jog, run, and sprint for a bipedal movement. With the horses, we

had walk, trot, very much similar kind of gates. And then we had caner and gallop. Now these gates were very different. Um they're what are known as three beat gates, which means they have a kind of syncopated pair of first footsteps before the back end comes back down. And this is something I'll talk about a little bit later because this introduces some complexity for us. Now, looking at the gates, what we wanted to make sure we were doing was allowing an overlapping range of motion for them so that we could use the gates to represent effort, but we could cater for a wider range of speeds within any individual gate. So, if you have a look at the graph that's on screen at the moment, you should see in red, we're showing the kind of minimum ranges that our gates can cover. They're not ideal, not where we would generally want to be in, but we can run them. We then have a yellow range which is the ideal best looking region for that particular gate and then we have a green range where they can overlap with the next one. This then gets rid of that idea of discrete speeds and enables us now to

continuously control the movement of the horse almost deterministically through those different gates. However, there's one problem that does come with this and that's transitions which didn't have this setup. So, our transitions in Red Dead 2, initially in development, were one shots bit like in the initial video I showed. Um, in isolation, these look really great. You can play them and get a really nicely authored movement every time. However, they do introduce problems for us when we're talking about trying to be deterministic. So, it was difficult to control the speed of them, meaning that we would have to produce a large amount of them if we wanted them to overlap with all of our gates. The foot cycle would define how the transition behaved. So we couldn't exactly control the duration that a transition would occur because it would be dependent on whether a foot was down or lifting or mid-strike. And that also leads into that idea of them being unpredictable because now we

have some deterministic range of velocities that we can use whilst in a gate and then we go into a transition which only picks a fixed range. uh we now suddenly can't control where we're going from or to. So initially we tried this idea of unrolling these and by unrolling them what I mean is we would look at the mean velocity through these and figure out frame to frame how we could adjust the playback. Um in principle [clears throat] this is really quite a simple thing to do. Um but it didn't look too great. Um we still needed a large volume of assets for them to not look like they were playing super speed or slow-mo. They obviously in a lot of cases looked slow-mo or super speed because we were otherwise speeding up or slowing down an asset to achieve a speed. And again, they were still kind of unpredictable because we still had a dependency on hitting the right foot strike whenever we played them. So what we wanted to look at I'm going to go over in the next slide, which is continuous kind of control of us moving through gates. So we'll start off in

this example looking at going from a trot to a caner. So, we're gradually speeding up throughout, trying to keep a kind of deterministic acceleration as we go. What will happen in here is we'll go through the ideal range, gradually get into an uncomfortable maximum range that the horse can handle, and whilst we're in there, we'll look for the opportune moment to continue into the caner gate. So, as you can see in this example, suddenly we've gone from having quite a fixed speed at the start and end to having a very smooth progression throughout. And this is something that became really important for us when you look at the rides with Dutch and the gang where all of the gang could be loosely speeding up or slowing down between each other. And the last thing we wanted to get into was stuck oscillating between fixed transitions as we had to pull different members of the group forwards and backwards.

So what's the actual breakdown of these cycles that we're using in this case? Rather than using one shots, we decided to introduce the idea of continuous acceleration and deceleration. So the idea would be we would use overlapping cycles that could represent the notion of acceleration on the horse or the deceleration and deliver a similar kind of posing for us. With these being cycles, it means that we could introduce whenever that we wanted them to come in um independent necessarily of foot strikes. It also means we could control the timing really precisely of them because all [clears throat] the way throughout we can accelerate the horse or decelerate the horse at whatever rate we want to. We can also vary the duration of them dependent on what reason we've decided to speed up or slow down. So suddenly we're not just talking about a fixed gate, so going from walk to caner or galloping to walk. But we're talking about being able to make changes such as slowing down for a corner and using these acceleration or deceleration cycles on top.

Now with that in mind, I just wanted to go over actually what the posing of these look like and how we get the animation team happy with them. So hopefully these will actually look a little bit intuitive as we go through them, but there's a breakdown of our basic poses. So we've got a cancer on the left hand side. We've got our acceleration posing on the right hand side and in the middle we've got the deceleration posing. So kind of intuitively like for a human as we decelerate we find that the horse collects its feet back together to slow down and catch some of the inertia and the head goes up and back. It's a little bit like if you can imagine sprinting along and trying to stop before a curbside. And then for our counter acceleration pose, the footfall is extended and the head is down and forwards. And again, this is probably like the example of if you could imagine walking along and trying to catch a bus as it's leaving a bus stop, sprinting along to get it.

So the great thing with these as well was that we could then replace them for different purposes. So in the case of the acceleration and deceleration, we also had a mode of skidding in the game whereby when the player unlocks bonding level with Arthur's force, they now have this new move that is highly maneuverable where they could skid the horse and then accelerate back out of it. What's great about this is that this just became some changes in our locomotion controllers where we could slow down or speed up in a slightly different way and then we would just condition slightly differently which of the acceleration or deceleration cycles we would play with it working so fantastically for us for the gates. We then kind of got to the point where we started to look at our stop transitions and our stat transitions going from moving to idling, idling to moving. Suddenly these start to feel very lumpy as well in a similar fashion. The question with this was whether we could introduce this concept there. So we decided to approach it

looking at the idea of never stopping moving with a horse. And principle I don't mean necessarily never stopping moving. But what we wanted to do was make sure that we could allow the player or an AI to let go of control of the horse, almost come to a standstill and then change their mind almost instantaneously and speed back up out of it all the while without going through lots of lumpy or clicky kind of different transitions. So we ended up using these deceleration cycles and specializing them for stopping. So then as we detected that an character is going to come to a halt, we would introduce the deceleration cycle for it. But again, if there's stick input or a decision to run off in another direction, the cycle can stand up again with an acceleration and we don't lose control of the character with a discrete transition. So the great thing about this for us is it's supporting these ideas of the indecision of control of the horse. We want to make sure that it looks like you're not necessarily 100% control in it. It's doing its best to respond to you.

So going through that just want to follow on now with a little bit of a overview how we handled the riders. So just beforehand I talked a little bit about the idea of countering and galloping being three beat gates and this introduced some difficulties for us in terms of how we synchronize the assets together for these. Like I was saying these have a syncopated footfall on the front legs with a third strike coming down at the back. So we knew quite early on with this that we couldn't actually sync it on the foot phase which is something that we might typically do on bipedal move. So we started to introduce additional tags that we would be able to map up things like we would call sync. So the idea with syncopy is that we would be looking at the extension and compression of the pose rather than a particular footall. The idea with this would it would actually save us having to exactly match the footall across all of our assets, but it would also stop the mush happening when we had large intervals between them. So, just to have a look at

this example, here's the tagging we've got. So, we've got the right foot tagged up here and then we've got the left foot tagged up here. So, we still keep those marked up so that we can pass them on to our audio teams or whoever might be interested, but then we're looking at the compressed power sync beat and the extension. So, with those in play, that then meant we could have a number of different cycles. We weren't so dependent on the interval between the footballs. So, we're adding this in for the riders. Our riders were actually supported by additional programmers and animators. And what we would use for them is additional layers on the horse's locomotion dedicated to a rider and a passenger. These would be put together so that they could define the styling

that matched whatever the horse might be doing at the time. What's also quite important with these is that the horse would then tell the rider or the passenger what to do as we went through different movements. So, as we hit a stat transition on the horse, the horse then tells the rider and the passenger a stat motion is coming in and gives them the assets to play back. As we hit the cycles, the horse tells the rider and passenger the cycles are playing and gives them the data. And as we transition to stopping, the same thing happens there as well. to pro to get these working together properly. What we would end up doing is taking the dominant assets of the horse and providing these to the passenger and the rider to synchronize them to it. And this is where the tagging becomes even more important. Alongside this, the rider was actually free to interpolate the locomotion controllers values as it saw fit. So we didn't have to have a onetoone dependency on what they were doing, whether it be the same angular velocity at a given time or not. Um, also we didn't have to have a onetoone map of the assets on the rider and passenger

with what the horse provided. So they could be decoupled. For example, adding more loops onto a cycle or playing back different kinds of fidgets on the rider compared to the horse. And when they sync nicely, we also get our moments like our clip stopping. So looking at what we talked about before, we had the sync beat tags on the horse, but what we also added in was a separate set of tracks which we call rhythm for synchronizing between the horse and the rider. Now the extension and compression of the legs is really important for the horse assets to work together, but it's not necessarily important for what the rider is looking for. With the rider, what we found we were looking for was the points where we were at our lowest or our highest in any given cycle. So, we added an idea of a track called rhythm. And again, we tagged those up separately for both characters. Now, with these tags shared between them, one thing that's great is that we didn't have to have the same number of cycles between them because we weren't dependent [clears throat] on a phase of an animation. We can suddenly have a

simplistic loop for a rider that doesn't contain anywhere near as much detail as the horse or vice versa. What we would do is take the dominant assets that are playing from the horse, provide them to the rider for synchronization, and map those two tracks together. So, just to show them side by side with each other, you can see high points and low points on the horse and rider simultaneously. Okay. What I'd like to look at next is the environmental awareness and how we implemented this on the horses in Red Dead 2. So, as I said earlier, the world that we introduced in Red Dead 2 was Rockstar's biggest in a game so far. The terrain was incredibly varied, and we wanted to make sure that you felt grounded on your horse in that world. So, what were we going to try and achieve? Trying to make it feel like the terrain was difficult to navigate and it would take its toll on your horse. We wanted to make sure that we were selling with the visuals of the horse and the rider that difficulty that was introduced in the app. With our horses, they moved roughly around 18

meters a second at their top speed. So that's incredibly fast, around 40 miles an hour, and that leaves a lot of room for things to go wrong. So we had to look at how we could have used the freedom of movement we introduced earlier to help you navigate around the terrain successfully. And those responses of the horse to the terrain is another example of where we wanted to show the horse as an independent AI. It's thinking for itself, responding to the world independently of the player. So initially early on we were looking at the responses to pitching in the terrain. Uh early examples of this we actually looked at capsule adjustments and IK solutions to adjust as we went along them. So in this example we've got a horse that's just adjusting its feet in capsule to the terrain. Not doing anything particularly special. kind of looks a little bit odd in isolation because the rider is just pointing out of the world's kind of normal on the ground.

With the IK solutions, we weren't really happy with the results. So, what we decided to do was add even more dimensions to our blends. With those added, we would then have the ability to control the pitch of the horse and the rider independently of the speeds. But adding four dimensions uh to our blends suddenly introduced some new problems to deal with. So I mentioned earlier how we were extracting this information automatically. With 4D we're suddenly adding a large amount of complexity if we want to do the maths properly. So we kind of decided we wanted to cheat our way around that. Rather than using the exact maths as it was we would coarsely bin our assets automatically by looking at the incline or decline on them. We would then use K means clustering on them to actually group them together into multiple 3D spaces. So looking at them separately that meant that we would have end 3D spaces in this example just three where we would then

be able to go okay these look like they're going down these look like they're going up and these look like they're going flat. The accuracy of this fourth dimension wasn't incredibly important to us. So if there was some slight deviation is something that we could afford to ignore. But the XY and angular velocities are all still very accurate. When it comes to then finding an asset to play back or a combination of it at runtime, it just becomes a simple lookup again for us. We provided all the velocities we wanted plus the pitch and that then becomes the weighted blend of two 3D spaces. But we didn't think that four four dimensions was enough for some of the things we wanted to do particularly with countering. So with canering, we're looking at the fact that actually the horses that we saw and captured footage of were using a leading foot on the turns when they were going left or right. And then we also researched this and found that there were preferences for horses to be left

or right footed, which seemed like an interesting thing to add to the game. So with this in mind, we started to then bin this as a fifth dimension looking at the assets as to what's the actual foroot in them and then again bending them into a left leading or a right leading space. Similarly again this is then a 2D K means clustering we bin them into the 3D spaces and then we're able to put them together to have some simple lookups. Um, now what was great for us with this as well meant that similarly with the cycle, what we did with the cycles, we could then control the blending between being left and right footed. So we could find an opportune moment to do it, but we could also control the speed at which it did it. So that we could get little moments like you see in the video where it actually looks like the front feet kind of hop slightly as the foot changes. Now with all the detail in the environment, one thing that we had to spend a lot of time on was analyzing the terrain. We actually implemented a

system with a blackboard whereby we could post all sorts of information that we find on our way. So what we would do is look at the forward integration of our locomotion controller and using a combination of nav mesh and physics casts we would validate positions on the terrain, the inclines that we saw coming up ahead, but we would also look at even sort of finer details from our graphics systems such as the depth of surfaces or water features that were coming up, the swarms of bugs ahead in the future. um alongside actual weather conditions uh like the wind velocity depending on where we are in the world. With these posted together, we then had a large amount of data that we could then use to dynamically switch in and out different styles. And this kind of leads me to talking a little bit about what we actually did to our locomotion system coming from five. So coming from five, we decided to break down our locomotion system into a different structure. What we wanted to move away from was these typical kind of manually authored state graphs. We

weren't keen on it and I think as we talked about earlier, we found that then extending these became unnecessarily complicated for us. So we looked at the idea of introducing atomic moves which we would call motions. These would be simple movements on a full body or a layer just to achieve one thing. A collection of these together is what we would call a motion type. And a motion type would represent one given style. So in the case of a horse, this might be something like wing through water or going through deep snow. What we could do with these is inherit from other motion types and combine them together to actually create new variations. So for example, as going through snow got deeper, we could then gradually replace certain assets. The selection of these was datadriven with the information that we put on the blackboard. So we would have large collections of motion types that were conditioned on data such as the depth of the snow or the incline that we were seeing ahead or even whether it was windy in a particular direction.

Uh in total this was used across all of our locomotion in Red Dead 2, not just on the horses. So we had a breakdown of this which looked something like around 6,300 different motions across the game. uh making up something like 2 and a half thousand different motion types. Um across that then we would break these down into what we called archetypes which would represent certain kinds of characters or animals such as whether it be Dutch or a certain kind of horse. And then we had our data driven conditions numbering somewhere close to 2,00. So just looking at an example here um what we would post to the blackboard for a snow motion type. So initially as we go along we would actually get the information out to tell us the name of the material that we're walking through. We would be able to find the depth based on any tread through before us. And then for example if we decided it was incredibly cold and we wanted to respond

to that we could do something like push through a tail shake to select the movement for that on a layer. We'll then be able to author these conditions independently of the game code and let the system actually select them for us on the flight. So then in this case you can see then that we would be getting these shakes getting timed off regularly because of the cold weather. Even as adjustments to reach an adjusted hat would be based on things like the wind speed or the direction of the wind. So often as you turn into the wind in a blizzard like you might see early on in the game which is very much focused on wintry weather a would respond to that accurately but again we didn't have to code that. It was data driven. So another thing I mentioned earlier was the speed of the horse and the difficulty of navigating through the terrain. And one thing that we wanted to try and do was to use the extensive mobility that we'd added to the walks to try and help you avoid annoying

obstacles like trees and large outcrops of rock. So we hoped that this could introduce this idea of self-preservation by actually increasing the mobility of the horse and its response to not wanting to actually run straight into a tree across the AI and players. We introduced different solutions. So with the player, we actually looked initially at whether we could get this information out of naves and then ultimately actually settled on things like marking up large groups of rocks or trees that we wanted to avoid. We could then cast into the world based on forward integrated locom motion to then decide whether we should be moving left, right, or stopping against these. For the AI characters, we would have velocity obstacles implemented which would then push these shapes in there as well and use the nav mesh. And in practice, this worked pretty well for us most of the time. What we would be able to do is respond ahead of time and use our lateral velocity to shift the horse sideways and then allow the player to straighten back up. So then we

would try and minimize the amount of time that we were actually interfering with your control. And by the end of it, the response of this was really, really good. that actually what we got asked to do was to make sure that if you held a stick towards the tree and mashed away galloping, you definitely hit the tree. Now, I've talked a lot of points through this about how important adding the range of speed was to our horses. We really did want to get away from discrete kind of notchy feeling across gates. But the other thing that this enabled us to do as we added more detailed terrain is to actually more gradually control the speed of the character as they encounter more difficult terrain. Whether that be depth of snow, whether that be going up and down a hill, or whether that be going through bodies of water. Um, so using this then we apply these ideas of what we would call speed penalties into the game. And the idea with speed penalties is there different factors that could

affect the horse which we would post onto our blackboard. We could then manipulate their incoming desired movement based on that factor and reduce it nonlinearly. So let's have a look at an example here of the horse moving through the water. So initially here's a horse canering through the water. Um no speed penalties being applied. So it's just a fixed speed the whole way. Now, what I want to show is an example of this afterwards. So, as the effort actually increases, what we do with the speed penalties on the water is that we actually further increase how much we take off. So, we more dramatically slow you down the faster you want to go. The idea here being then that we show how much effort's going into it so that you see a significant acceleration and deceleration based on your input and the depth of the water. Let's have a look with the speed penalty applied. Same kind of input. But again, we're dramatically slowing the horse down now. And as the depth

gets shallower, we rapidly speed them back up. And here they are side by side, just to give an example. So leading on from that, I wanted to talk about one of the features for terrain awareness that we added to the game, which I think is one of my favorite, and that's our clifftoping. So, the cliff stopping kind of goes against everything I've said about speed and control of the horse uh throughout. Um rather than wanting to give you this indirect and soft control of the horse, whether it's a nail or a player, we wanted to actually make sure that we definitely got this moment every time and it was accurate. So what we looked at was this tech that we introduced into the game which we called stop matching. Uh the idea with this is something you've probably seen before. But what we

would look at doing with this is extracting a few tracks of animation data from the root or from tags such as our foot tracks. So initially we would be looking at the translation to a goal. We would also then look at our foot or beat cycle depending on the movement. And in this example, it's looking pretty flat, but we would also look at the orientation left to the goal position. So with this system, what we would look at trying to do is feeding in the information about where we wanted to be and what the current state was and looking to find the closest match at any given point in time. We'd actually go through these bits of data um seeking the best time that had the lowest possible error for each of these. But alongside this, we also had a significant amount of markup across the world. So actually a lot of our cliffs across the world were manually marked up by our AT team to actually show us these steep drops coming up. Um this is definitely something in the future that we would like to reduce the need for. So let's have a look at this working in an example.

So as I'm canering along the terrain the forward integrated locomotion will be queried to see that we're actually coming up to one of these cliff planes. So as we see that we then know that we've got to take some evasive action. So in this case we realize that actually based on the size of the horse and the assets that we have available there is an ideal stopping position ahead of it. We can then look at the assets to see how they end. And then using the information in that graph that I showed before, we can look at finding the frame with the least possible error where we would actually then be able to trigger our stop and play it out to hit that position with minimal slide and minimal error. So as we continue to go forward, we find the entry position. As we get there, we play the stop through. And for us, what was really great with this is that this also meant that we didn't have to rely on synchronization from our cycles into our stops. We would

rely on the output of the stop matching to come back with the best possible match that would reduce that error completely. So then we could just go ahead and play it straight away. And any alignment in the world was minimal because again, we'd found the exact entry position that we wanted to play it from. And again, just like the trees, uh this almost worked 100% of the time and never went wrong. [screaming] Okay, what I want to talk about now is the personalities of the horses and actually what we did to introduce these in the game. Um, this is a section I find kind of amusing because actually reflecting back on what we did for Red Dead 2, a lot of what we did to introduce personality for the the horse and the players perspective was actually to add negatives in, leaving much of the positive association with the horse actually coming out of the player's experience playing the game. So simple things like slapping the horse and getting kicked off a cliff, it's a memorable moment. What we introduced was the idea of the

concepts of agitation and unruliness. Now these are sort of features of a horse whereby they react negatively to different stimuli in the world or from the player. So in the example video that's playing now, you'll see how I'm actually making the horse agitated by shooting my gun and riding them really badly. uh as this builds up and up and up and up and up, the horse gets progressively more agitated until they just try and get rid of the biter completely. This was actually implemented in a basic utility system that we called motivations. So what we would do is take in these different stimuli in the world and apply some increase in the motivation for agitation throughout. As the agitation increase, we could then differentiate the assets as we go. So in this example, I'm manually increasing the agitation motivation on the horse. And as it gets bigger and bigger, we actually gradually differentiate more and more of the motion type that we're playing on the horse. So we actually would have then motion types for low agitation and motion types of medium and

high. And what happens as we go through the different agitation states is that we gradually replace different assets and introduce more impediments to the control for the player. All these assets were then able to synchronize back to the rider. So we could have transitions between the states and we could reflect the difficulty in controlling them as they changed and on the way up as on as they go on the way down when doing things like camming your horse by giving it a pat. Um, not only did we have agitation motivations, but we also had across all of our animals toilet motivation, which as that increases to one result in horses or animals doing a poop. So, let's have a look at some of the features of the agitation and the movement put together. I just wanted to show an example of a bear attack where the agitation gradually increases and what happens to the player. So, as we head towards where there's going to be a bear attack, the horse's agitation actually starts to increase, usually before the player would be aware

that there's a predator coming up. As the agitation increases, the horse gets more and more agitated and reflects that in its animations. When we get to a certain threshold, the horse actually decides to stop and makes use of this path motion that we talked about before to jostle around on the spot spot and give you a bit of a moment to actually back away from this encounter. If you don't, then the horse will actually use that notion of self-preservation and try and escape the scene, leaving you behind by booking you off the horse. [groaning] See there? Get thrown off. And then this gives us a pretty stressful encounter with a bear can fight off. And again, I think like I said earlier, you know, a lot of the ways that we introduced personality into a horse was reflecting negative states for the player and letting them fill in the positive moments. So, as you did things like work your horse until it ran out of stamina, we would then reflect that with

changes in our motion types. As the health went down, we would also reflect that in changes of our motion types as well. Again, these were all bits of information posted to the blackboard that was then used to select this motion type automatically. What would also come with this is then impairments to their performance. So that hopefully we would discourage you from running your horse into the ground because as the stamina reduces, they're more likely to throw you off or they're unable to move just as fast as they could in the world because we would introduce speed penalties like we did the water based on their stamina. Finally, I just want to have a look at some of the differentiation we actually added for breeds. So, when we actually looked at what we had for a baseline horse in Red Dead, we were looking for somewhere we were looking at somewhere around 3,000 different animations across 23 unique movement styles or motion types in the game. At which point, that's already a particularly big chunk of our budget. So, we knew as we wanted to introduce more variations in terms of our breeds

that we were going to have to think of something simpler. So, Red Dead 2 actually shipped with 19 different breeds of horse and these were coarsely categorized into heavy horses like Adens's uh race horses maybe like a thoroughbred elites which were usually like our Arabian horses and standard horses things like American standard. Now to differentiate them what we actually started looking at was how we could change their responses with their locomotion controllers. So we had a wide variety of speeds that we could make use of because we had all these continuous gates available to us. So we could modify the ideal low and high speeds within an individual gate whether whether it was a large horse or a small horse. We could also control how they accelerated and decelerated deterministically. So for example, our larger horses like an Adens could have a much slower acceleration and deceleration up to a top speed, but maybe might get a similar top speed to a

much smaller horse. We could then also impact their angular responses. So when we were looking at the drift examples before where we added this notion of indirect control. Again, we can make lighter horses seem more nimble by them reacting quicker to your changes when they're over steering and straightening back up much more rapidly compared to a heavier horse that might take a lot longer to do it. Alongside this, we could then manipulate the speed penalties penalties we had in the game. So, for example, the strength of a horse whilst carrying the carcass of a deer that you've been hunting might actually impact how they slow down for it. So a heavier horse might be less impacted by carrying more stuff. Alongside this, we also had the equipment variation, which is less to do with breed. And with all of this, what we did try to do was ensure that there was no one single best horse, that there were trade-offs between them, so that a player could go out there, try various different breeds, and pick the one they were most attached to to run through the story. And what I want to just show before we

wrap up on this is having a look at a number of our kind of standard different types of forces in their different locomotion controllers and how they behave with the same input. So it's the same recorded input but different locomotion controllers applied across each breed. So hopefully on the right hand side you can see the heavy and the elite horses and they're probably the ones that going to show up the biggest difference where our heavy horses are quite kind of almost lazy looking in how they straighten back up or turn whereas the elite horses look a lot more agile and nimble in the way that they do it. There's also the differentiation and the acceleration and deceleration play there. And also their top speeds and low end speeds vary significantly. And so with that, I'd like to wrap up. So generally, I think what we found was that a lot of these approaches came together really well for us. We spent a

lot of time working on compositional and automated approaches for the horses. And initially we had some skepticism among the team as to whether this would work. But by the end of development, we were so settled on it that a lot of these concepts actually got introduced back onto other characters such as Ather and the other humans in the game. What we did find throughout though was that a lot of what we'd produced had a really steep technical learning curve. So even for programmers and technical animators, this could be a lot of difficulties and reliance on a lot of experts within the company to help assist in different areas. The technical approaches like I said on the horse informed everything else that we did in the game and we did find massive success with the large scale datadriven locomotion system that we added. We didn't go into much detail about it but it made it extremely easy for us to add a lot of variation and style throughout the game as well as introducing a few crises throughout development where it was very easy for us to blow the animation budget. And what was most pleasing of all for me

it was just seeing things recognized publicly like people noticing the dress moves and analyzing them for accuracy. People being massively concerned about how much their horse pooped and people loving their big stupid horses that got in everyone's way. So looking to the future, what kind of things do we want to learn from this and take forward into Rockstar's future games? Well, we're pretty convinced that the compositional approaches that we used for putting together locomotion worked incredibly well, and we want to keep pushing forward with that. The determinism of movement is something that's incredibly important to us. And I think that we want to make sure that the responsiveness of our characters in our game, whether they be AI or player controlled, significantly improves. We'd like to introduce wider degrees, wider varieties of movement. So, more styles across more varied terrain. And I think as well one thing that's worth highlighting is that actually in some cases we didn't achieve parity between AI and player controlled characters. So even though they were using the same fundamental systems in

many cases the player would be able to actually execute moves in a more satisfying manner than what we could deliver on the AI characters. And this is something we really want to improve for the future. Alongside this we're also looking at machine learning approaches to improve our locomotion and animation. But there's not something I can talk about in depth today. And if any of this kind of thing sounds like something that'd be interested to you, then we are hiring. So, thanks very much for listening.