Revamping Player… well, everything
by Daniel Buckmaster · 04/07/2009 (2:10 pm) · 10 comments
It’s been a while since I promised a resource of my code for my custom Player animation system. Sorry I haven’t got around to doing that yet. I also started working on spring-based Player movement, so you could avoid the unnatural-looking bounding box collision with the ground. Also no resource – again, sorry. But both of those things have merged in my codebase into something much bigger and far more beautiful.
Beware: long post. I’ll try to make it interesting.
What I’ve been working on since then is a totally revised Player movement system. First, I merged Player and AIPlayer into a new class called Actor – it’s much simpler, really. I haven’t tested it in depth, but I’ve played around with giving an Actor I control move orders. The next step, of course, is forcing the Actor to obey those, even if it is still being controlled by a client.
But about that movement system. What I really wanted was freedom. Freedom of movement, mainly, and freedom from coding constraints that limit the things characters can do in-game – like current Players being confined to rotation around the world z axis. So after quaternionifying Players, which I did get around to making a resource on, I took a good look at what my ‘freedom of movement’ ideal really entailed. And yes, it’s more than just being able to fly. (Ooh.)
Fig. 1. Freedom of movement.
The first order of business was to get mantling working. Now, this is something I feel guilty about making into a resource. Well, I probably shouldn’t. The way I did it worked satisfactorily within that paradigm – the standard Torque Player, with z-axis constrained rotation and a fast movement speed. When I started to make other changes, like free rotation, the wheels kind of fell off the code. But no worries! I fixed the problems… only to realize that I was about to make demands of the system that my code really couldn’t take.
See, I’m a first-person purist. Therefore, one of the most important things in the way characters move is that it is smooth, so it looks good from a first-person perspective. In third-person, you can fudge it, because you probably won’t notice if the character’s head is bopped around a bit, as long as the overall motion looks good. However, through the character’s eyes, every jolt where the movement system aligns to a new environment is too noticeable. So I couldn’t easily use my ‘stock’ solution, which, like the stepping code, just bumps the Player up a certain distance to get on top of an obstacle. This is fine-ish with smaller steps, but even with an animation, it was too jarring when you were leaping up half the character’s height.
Fig. 2. Jarring.
There were also unresolved issues when you could mantle, but for some reason failed – and you ended up mantling out of the ground like an incredibly eager zombie. The other thing I wanted was a way for characters to vault over things, as opposed to just mantling onto them. This entails that the Actor keeps moving while in the animation, or I’d have trouble with realigning the character after the vault animation completed. That in itself isn’t so hard – but I was stumped. The movement code for mantling and stepping just doesn’t work that way – you make the change all at once, and then once your bounding box has been knocked up a metre or so, you can keep moving on the new surface.
Fig. 3. Vaulting.
Now, take a step back and look at another requirement I had. Stances are too common a feature today for them to be omitted – and I wanted them in for gameplay reasons, not just ‘because everyone else can do it’. It’s pretty simple to do in Torque – there’s a great resource to get you up and running with the basics. But again, just like with my own resources, I wanted more from the system, wanted more freedom. I eventually realised that with all the features I wanted, a linear progression of stances wasn’t enough – and I had to get my mind around the fact that a ‘stance’ shouldn’t just represent a physical posture, but a way of moving. So, while before characters would climb ladders in the ‘stand’ stance, now there is an entire stance for climbing movement. This gives me a major simplification – less movement variables in the Player datablock. Also, I’m planning to use a stance for ‘narrow’ surface movement – where the character is on top of something, but their legs are not touching the ground (because they’re standing on, for example, a pipe).
Fig. 4. I’ve got a pipe between my legs.
In the end, I worked up a system of stances defined by their transitions – like the ShapeBaseImage state system. I rolled these stances into the ‘helper’ object that was formerly providing my dynamic animation lookup table, since animations and stances go hand-in-hand most of the time. Now that object has become the ‘BodyData’ for an Actor: it stores information about the Actor’s physicality – what stances lead into which others, and which animations are played when. The ActorData itself provides specifics: the exact sequence for each animation, the exact movement values in each stance.
But underlying all these needs was the fundamental thought that the bounding box was not good enough. I had already acknowledged this, ad tried to fix it with my box-and-spring Player: the lower portion of the Player’s bounding box was cut off in updatePos, and collision was managed below the knees with two raycasts used to add vertical spring forces to the Player. I never got around to adding the correct animations, but the idea was that if the surface below the Player was uneven, one of the springs would contract and that leg would animate, making it look as if the Player were adjusting their footing to actually stand on the ground. It worked, to a degree.
When I realised that these springs did all the work I needed for stepping as well, the entire solution started coming to me. Because the thing was, when you ran onto a ledge, the bounding box didn’t collide with it – but suddenly your springs were compressed, and they readjusted to bump the Player up to the correct height. This was slightly unintended, but it worked perfectly – and looked good, too (nice and smooth in first-person!).
Fig. 5. The first person.
So just as I originally used the stepping method to do mantling – I’ve decided on using springs to mantle. In this case, we’re not talking about leg springs, but arm springs. It’s a simple case of casting rays along a vector that’s slightly in front of the player, so it catches plateaus you’re about to hit.
But while I was on this tangent (well, it wasn’t really a tangent), I figured that it would be a lot more difficult to get the control I wanted over the system without adding lots more datablock parameters (yay!). So I switched to a completely art-based system, where node transforms are used to define the limb ‘springs’.
This not-so-tangential line of thought brought me to my final conclusion – I really needed to get rid of the bounding box. Actually, I didn’t go straight there. I was happy with using springs for limbs, and the bounding box to collide against when the character’s limbs for some reason failed (that can’t be a good thing). However, that would mean a very reduced-in-size bounding box. Which is a no-go. Because when you reduce the size of your bounding box and try to do a Kong vault over a shrubbery, the camera tends to leave the bounding box, and your character tends to stop animating. Which, as you might imagine, is supremely jarring.
Fig. 6. A supreme jar.
So… what? I got around this problem when trying to answer another difficult question – namely, the inaccuracy of a bounding box in representing a human, and the inflexibility of current Player collisions. As you may have imagined, I want Players to be able to be very free with their movement – do crazy things like vault over railings or leap through open windows. They will not be able to do this with a big huge bounding box following them around – if even the tiniest corner of the box swats the edge of the window frame, there goes your dramatic entry. I had been attempting to solve this with patterned movement – animate your character to do what’s necessary, then get the bounding box to catch up once you’re past the tricky bit.
Fig. 7. The tricky bit.
I realised the solution was much easier. First, replace the bounding box with a collision hull. Second, instead of performing the soulless, calculating collision move that Players currently use, which tries its utmost to make sure the Player never penetrates a surface (otherwise, you’re borked), use Vehicle-style collision impulses where the hull overlaps geometry. This way, you’ve got a little leeway in collisions.
All of which means, the bounding box is free to do whatever it wants! So now, it can be just that – a bounding box, not a collision box. Since it doesn’t collide, you can make it as big as you like, so the camera never leaves the area, and so you’re not forgoing the Player’s render when you really shouldn’t be (another problem with making the box smaller).
So after all this rambling, what have I actually done in terms of a system?
1. Actors collide using penetration-penalty impulses against an artist-defined convex collision mesh
2. Artist-defined springs keep the Actor out of movement surfaces and provide mantling/vaulting
3. A script-defined animation lookup table lets you define different types of animations per stance for different character types
4. Script-defined stances are fully integrated into the animation and character movement system
5. At each stance, the Actor can move with 3 different speed settings
Well, that’s quite enough for one blog. For those of you who’ve read this far and haven’t just looked at the pictures, congratulations, sucker… ;)
And for those of you who did look at the pictures… all I can say is, *sorry, programmer art!*
Beware: long post. I’ll try to make it interesting.
What I’ve been working on since then is a totally revised Player movement system. First, I merged Player and AIPlayer into a new class called Actor – it’s much simpler, really. I haven’t tested it in depth, but I’ve played around with giving an Actor I control move orders. The next step, of course, is forcing the Actor to obey those, even if it is still being controlled by a client.
But about that movement system. What I really wanted was freedom. Freedom of movement, mainly, and freedom from coding constraints that limit the things characters can do in-game – like current Players being confined to rotation around the world z axis. So after quaternionifying Players, which I did get around to making a resource on, I took a good look at what my ‘freedom of movement’ ideal really entailed. And yes, it’s more than just being able to fly. (Ooh.)
Fig. 1. Freedom of movement.
The first order of business was to get mantling working. Now, this is something I feel guilty about making into a resource. Well, I probably shouldn’t. The way I did it worked satisfactorily within that paradigm – the standard Torque Player, with z-axis constrained rotation and a fast movement speed. When I started to make other changes, like free rotation, the wheels kind of fell off the code. But no worries! I fixed the problems… only to realize that I was about to make demands of the system that my code really couldn’t take.
See, I’m a first-person purist. Therefore, one of the most important things in the way characters move is that it is smooth, so it looks good from a first-person perspective. In third-person, you can fudge it, because you probably won’t notice if the character’s head is bopped around a bit, as long as the overall motion looks good. However, through the character’s eyes, every jolt where the movement system aligns to a new environment is too noticeable. So I couldn’t easily use my ‘stock’ solution, which, like the stepping code, just bumps the Player up a certain distance to get on top of an obstacle. This is fine-ish with smaller steps, but even with an animation, it was too jarring when you were leaping up half the character’s height.
Fig. 2. Jarring.
There were also unresolved issues when you could mantle, but for some reason failed – and you ended up mantling out of the ground like an incredibly eager zombie. The other thing I wanted was a way for characters to vault over things, as opposed to just mantling onto them. This entails that the Actor keeps moving while in the animation, or I’d have trouble with realigning the character after the vault animation completed. That in itself isn’t so hard – but I was stumped. The movement code for mantling and stepping just doesn’t work that way – you make the change all at once, and then once your bounding box has been knocked up a metre or so, you can keep moving on the new surface.
Fig. 3. Vaulting.
Now, take a step back and look at another requirement I had. Stances are too common a feature today for them to be omitted – and I wanted them in for gameplay reasons, not just ‘because everyone else can do it’. It’s pretty simple to do in Torque – there’s a great resource to get you up and running with the basics. But again, just like with my own resources, I wanted more from the system, wanted more freedom. I eventually realised that with all the features I wanted, a linear progression of stances wasn’t enough – and I had to get my mind around the fact that a ‘stance’ shouldn’t just represent a physical posture, but a way of moving. So, while before characters would climb ladders in the ‘stand’ stance, now there is an entire stance for climbing movement. This gives me a major simplification – less movement variables in the Player datablock. Also, I’m planning to use a stance for ‘narrow’ surface movement – where the character is on top of something, but their legs are not touching the ground (because they’re standing on, for example, a pipe).
Fig. 4. I’ve got a pipe between my legs.
In the end, I worked up a system of stances defined by their transitions – like the ShapeBaseImage state system. I rolled these stances into the ‘helper’ object that was formerly providing my dynamic animation lookup table, since animations and stances go hand-in-hand most of the time. Now that object has become the ‘BodyData’ for an Actor: it stores information about the Actor’s physicality – what stances lead into which others, and which animations are played when. The ActorData itself provides specifics: the exact sequence for each animation, the exact movement values in each stance.
But underlying all these needs was the fundamental thought that the bounding box was not good enough. I had already acknowledged this, ad tried to fix it with my box-and-spring Player: the lower portion of the Player’s bounding box was cut off in updatePos, and collision was managed below the knees with two raycasts used to add vertical spring forces to the Player. I never got around to adding the correct animations, but the idea was that if the surface below the Player was uneven, one of the springs would contract and that leg would animate, making it look as if the Player were adjusting their footing to actually stand on the ground. It worked, to a degree.
When I realised that these springs did all the work I needed for stepping as well, the entire solution started coming to me. Because the thing was, when you ran onto a ledge, the bounding box didn’t collide with it – but suddenly your springs were compressed, and they readjusted to bump the Player up to the correct height. This was slightly unintended, but it worked perfectly – and looked good, too (nice and smooth in first-person!).
Fig. 5. The first person.
So just as I originally used the stepping method to do mantling – I’ve decided on using springs to mantle. In this case, we’re not talking about leg springs, but arm springs. It’s a simple case of casting rays along a vector that’s slightly in front of the player, so it catches plateaus you’re about to hit.
But while I was on this tangent (well, it wasn’t really a tangent), I figured that it would be a lot more difficult to get the control I wanted over the system without adding lots more datablock parameters (yay!). So I switched to a completely art-based system, where node transforms are used to define the limb ‘springs’.
This not-so-tangential line of thought brought me to my final conclusion – I really needed to get rid of the bounding box. Actually, I didn’t go straight there. I was happy with using springs for limbs, and the bounding box to collide against when the character’s limbs for some reason failed (that can’t be a good thing). However, that would mean a very reduced-in-size bounding box. Which is a no-go. Because when you reduce the size of your bounding box and try to do a Kong vault over a shrubbery, the camera tends to leave the bounding box, and your character tends to stop animating. Which, as you might imagine, is supremely jarring.
Fig. 6. A supreme jar.
So… what? I got around this problem when trying to answer another difficult question – namely, the inaccuracy of a bounding box in representing a human, and the inflexibility of current Player collisions. As you may have imagined, I want Players to be able to be very free with their movement – do crazy things like vault over railings or leap through open windows. They will not be able to do this with a big huge bounding box following them around – if even the tiniest corner of the box swats the edge of the window frame, there goes your dramatic entry. I had been attempting to solve this with patterned movement – animate your character to do what’s necessary, then get the bounding box to catch up once you’re past the tricky bit.
Fig. 7. The tricky bit.
I realised the solution was much easier. First, replace the bounding box with a collision hull. Second, instead of performing the soulless, calculating collision move that Players currently use, which tries its utmost to make sure the Player never penetrates a surface (otherwise, you’re borked), use Vehicle-style collision impulses where the hull overlaps geometry. This way, you’ve got a little leeway in collisions.
All of which means, the bounding box is free to do whatever it wants! So now, it can be just that – a bounding box, not a collision box. Since it doesn’t collide, you can make it as big as you like, so the camera never leaves the area, and so you’re not forgoing the Player’s render when you really shouldn’t be (another problem with making the box smaller).
So after all this rambling, what have I actually done in terms of a system?
1. Actors collide using penetration-penalty impulses against an artist-defined convex collision mesh
2. Artist-defined springs keep the Actor out of movement surfaces and provide mantling/vaulting
3. A script-defined animation lookup table lets you define different types of animations per stance for different character types
4. Script-defined stances are fully integrated into the animation and character movement system
5. At each stance, the Actor can move with 3 different speed settings
Well, that’s quite enough for one blog. For those of you who’ve read this far and haven’t just looked at the pictures, congratulations, sucker… ;)
And for those of you who did look at the pictures… all I can say is, *sorry, programmer art!*
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#3
04/07/2009 (4:17 pm)
Interesting stuff Daniel.. Not sure I understand it all, but I do like the direction you are going. 
#4
04/07/2009 (4:24 pm)
Sounds great, but got to see it in action! 
#5
It's great to see someone not just try to fudge around the way things are being handled in the engine right now, but really see a way to drastically improve (even if that means replacing a bunch of classes) and come up with something that just works better for them.
I, unfortunately, am largely guilty of the prior where I tried SO hard to not "mess with" the TGEA source for so long when first working with it...
04/07/2009 (4:47 pm)
This is just a fantastic post.It's great to see someone not just try to fudge around the way things are being handled in the engine right now, but really see a way to drastically improve (even if that means replacing a bunch of classes) and come up with something that just works better for them.
I, unfortunately, am largely guilty of the prior where I tried SO hard to not "mess with" the TGEA source for so long when first working with it...
#6
04/07/2009 (6:02 pm)
Awesome stuff man! I'd have to echo a want for a video to better understand everything that you've implemented. Sounds freakin' sweet though and looking forward to more about it. 
#7
04/07/2009 (10:13 pm)
Sounding good Daniel! Keep it up.
#8
Steve - performance is something I'm going to be looking at in detail. In terms of code efficiency... updateMove has ballooned to something like 500 lines (though only some of it will ever be executed in one go), while updatePos has been significantly shortened.
Bryan - yes, that was sort of the big epiphany that galvanised me into this path. It was time to stop just modding Torque, and actually design a solution from the ground up.
04/07/2009 (11:56 pm)
Thanks for all the responses! A video is something I'll definitely be doing soon. I've basically finished all the code for the system, but the problem is I can't use Kork to test with, since I need to add lots of stuff to the character model. I've been busy modding the Orange Guy for my purposes, but it's taking time. (There's a *lot* of animations to create :P.) Until then, I can't actually test my code to any great extent ;P.Steve - performance is something I'm going to be looking at in detail. In terms of code efficiency... updateMove has ballooned to something like 500 lines (though only some of it will ever be executed in one go), while updatePos has been significantly shortened.
Bryan - yes, that was sort of the big epiphany that galvanised me into this path. It was time to stop just modding Torque, and actually design a solution from the ground up.
#10
And the springs still need quite a bit of work - at the moment, the movement is altogether far too springy. I mean, it's sort of nice, but when using springs for mantling, the forces are often too great. The arms' spring constant has to be set fairly high if you want the player to be moved at all, but if you start mantling at near total compression, this generates a huge force and the player goes shooting upwards like a champagne cork. Need some damping...
...and also some more damping on the leg springs. The effect of slowing the player's downward velocity on impact with the ground is very pleasing, but when you pop back upwards at an equal velocity, it tends to look a little silly.
04/13/2009 (1:40 pm)
Well, the preliminary coding is finished... and working-ish. I'm actually really proud of just how well it is working, given I've taken about a week to completely gut one of Torque's systems and replace it with something that does give results. The collisions against the hull are a little rough, thanks to my fudging the collision/contact resolution maths.And the springs still need quite a bit of work - at the moment, the movement is altogether far too springy. I mean, it's sort of nice, but when using springs for mantling, the forces are often too great. The arms' spring constant has to be set fairly high if you want the player to be moved at all, but if you start mantling at near total compression, this generates a huge force and the player goes shooting upwards like a champagne cork. Need some damping...
...and also some more damping on the leg springs. The effect of slowing the player's downward velocity on impact with the ground is very pleasing, but when you pop back upwards at an equal velocity, it tends to look a little silly.
Associate Tom Eastman (Eastbeast314)