Hey everyone, Hamish the programmer here, back with another exciting journey into one of our technical systems - this time, how we handle quadrupedal movement in a first and third person game. I first designed the system just after our Wave 2 demo a year ago, but it should still be relevant and interesting for anyone curious about why Littlepip moves the way she does, and especially to anyone looking to create a similar sort of pony game.
First off, why is this post even a thing at all? What is it about quadrupeds that makes them unusual and difficult to work with? Quite simply it’s their shape. A humanoid character stands upright, which means their shape can be approximated by an upright 'capsule', as shown below. We call this shape a ‘collider’, because it’s what actually interacts physically with the environment and other objects.
This makes the job of the programmer quite straightforward, because no matter how you move or what surface you’re on, the shape and orientation of the capsule stays the same; it just needs to be moved at the right speed and kept on the ground. Furthermore, since turning the body would be physically quick to do, the character can simply move in the direction they’re looking right away.
Because it’s such a popular and straightforward configuration, Unity provides a component to handle all this for you, called CharacterController.
A quadruped, on the other hand, doesn’t fit this shape exactly. Our early prototypes would simply force it to fit the upright capsule shape by using a big sphere, like so:
This isn’t ideal though, because it means using a collider which is much larger than the object it’s supposed to represent. Ponies wouldn’t be able to stand close together or fit through narrow gaps. And if we made the radius any smaller, it wouldn't cover the entire model, so other objects would ‘clip’ through at both ends. So we made a custom mesh that more closely matches the shape of the pony, with an angled underside to allow it to move over small obstacles.
Using a low-poly, convex mesh like this is much faster to use in physics simulations than one that exactly matches the body shape.
We can’t use the CharacterController anymore, but it’s not too difficult to write some code that will move the body manually. The real issues come when we introduce head movement. We could turn just the body and leave the head looking straight forward, but that’s obviously not ideal. It would control okay, but the animation would look pretty stiff and clunky. We need to move and animate the head separately, which involves keeping the body, and its collider, at a different orientation than the view direction. (We call this 'tank-like movement')
Of course, we only do this up to 90 degrees in either direction, after which we turn the whole body.
So the question now becomes, in which direction do we move when the player presses the 'W' key: in the view direction, or in the body direction? In our first major refactoring of the movement code, we decided on the latter, as we believed it would make for more realistic movement. The pony would move initially forward, then turn their body over time such that they eventually face the right direction.
There are two problems with this: firstly, you end up not quite moving in the path you’re expecting, and secondly it feels more than a little unresponsive to the player, especially in first person, because you can’t see the body orientation. Compounding the problem was the decision to mount the camera on the head bone, while driving movement from the body, which is ‘realistic’ but caused a sense of disconnection to the player. This caused a lot of complaints in our Wave 1 and 2 demos; in fact it was easily the most common topic in our feedback form.
We made some adjustments in Wave 2, but they were really just band-aids over that fundamental flaw. So we scrapped the whole thing and started again, this time with the aim of making the player feel as connected to the character as possible, and trying to emulate the traditional FPS control feel.
This effort was guided by one principle: on no account should the camera move any differently than if the character was a biped. The player should be able to move in the direction they expect to move and look in the direction they expect to look - unless there is a specific gameplay reason why this isn't the case (such as a wall, or a force pushing you back). That being said, our characters are fairly unique, and we wanted them to retain the personality and movement style that a pony should have - at least from a visual perspective.
In the new system, the camera isn't attached to the head. Instead it’s controlled independently, circling the body’s pivot point by the feet. The head model is rotated separately to point in the direction the camera is looking. Similarly, we move the character in the view direction right away, turning the body over time but keeping the move direction constant.
The feedback from our QA team, and from the public in our later demos, was that this was a huge improvement.
There’s a couple more things I should explain. First is how we handle strafing (or more accurately, movement input in a direction that isn't directly forward or backward); currently we change the desired body angle based on the input direction, as the diagram below shows.
It's worth pointing out that, unlike in many other FPS games, you are able to run and sprint while 'strafing' as fast as while moving forward. As a quadruped, your aim will be just as steady regardless of the direction you're moving in, so we didn't think it made sense to limit your speed as a result. Later on we may implement specific strafe animations to be used when a character is moving slowly in combat, which gives a tactical advantage as less of your body is exposed to the enemy.
Finally we have slope angles. With a biped all we’d need to do is change the angle of the feet, which the player wouldn’t even notice unless they looked in third person, but for a quadruped we need to rotate the entire body appropriately. To do this we measure the distance between the front and back feet and the ground, and calculate the difference between our current angle on this axis, and the desired one. We then rotate the body smoothly over time, but quick enough to react to sharp changes in terrain.
Note that in this case, the position of the head and thus the camera changes. As a biped, this wouldn't happen because the width of the body is the same as the width of the head, but as a pony, when the gradient changes sharply downward there will be a small but noticeable shift in the viewing position. It's a minor issue, but one we have not yet found a solution for.
And that just about covers it! I hope you found this more in-depth article useful or interesting in some way, and let us know if you'd like to see more of them. Check out our latest demo if you’d like to see these concepts in action, and I'll hopefully be back with another post soon!