Today we are going to talk about the Crowfall character controller and character animations, where we are with these things and where we are going. Most of it is techno mumbo jumbo, but some of you who are more interested in the nuts and bolts might find it interesting.
The code that moves a player around the game is something called a character controller. While we are all familiar with the animated 3D character that appears on the screen, under the hood the character is represented as a much simpler shape. We affectionately call that simplified shape the ‘pill’ or ‘character pill’. We call it this because it looks like a pill. The character 3D model you all know and love is attached to the pill and essentially just follows the pill around. Yes all those years you have been playing games, you are just steering a pill!
If you look at the screenshot below, you can see the controller pill that the knight is attached to.
In many games the pill size is normalized across all characters; very small characters use the exact same pill as very large characters. We intend to scale our pill on a per archetype basis, which might lead to some advantages and disadvantages for various archetypes. There may even be areas that smaller characters can get to that larger ones don’t fit!
So what about the character controller? In the world of video games, there are typically two kinds of character controllers used, Kinematic and Dynamic. Kinematic controllers have full control over the character’s movement and any physics-like behavior is part of the controller code. In contrast, Dynamic controllers use the physics simulation for much of their behavior and control the character via forces within the simulation. Both controller types can have a wide range of character behavior and both approaches have advantages and disadvantages.
Kinematic controllers are, in many ways, simpler to build. The only things the character can do are the things the controller allows it to do. Most MMO’s use a Kinematic style controller that provide the instant ‘start, stop and turn on a dime’ behavior we have all gotten used to over the years. It is totally unrealistic, but we have all become very used to that behavior. If it doesn’t work that way, we tend to think something about moving the character feels weird.
Many action games take their Kinematic controllers a step farther and allow the character to mantle over obstacles or limit how fast the character can change direction. Adding even more complexity, many racing games use a Kinematic controller that emulates the way that a car drives.
The downside to Kinematic controllers is that you need to build EVERY part of character behavior into the controller. If you want your character to fall off things, you have to write that into the controller. If you want your character to push other characters around, you have to write that, too. If you want a boulder to push the character, that’s another part of the controller to write. If you have a physics simulation in your game and you want your Kinematic controller to behave the same way physics object do, you can spend a lot of time recreating the rules of the physics simulation.
Dynamic controllers try to minimize how much of a physics simulation you have to write by just putting the character into the game’s physics simulation. . This type of controller uses the application of force to make the pill move. Want the pill to move forward? Push the pill from the rear and it will start to move forward. Want the pill to keep moving forward? Keep applying that force. When you want the pill to come to a standstill, stop applying the force. This is great for games that want to leverage the fun and emergent behavior of their physics simulation as part of their character controller.
Sadly, there is no free lunch here. Once your character is being controlled by the physics simulation, you get everything that comes with that, some of which you may not want. For example, if your pill brushes against a wall, the simulation will apply friction that will slow you down. Another challenge is that when people say “physics simulation,” it’s shorthand for “rigid body physics simulation” (as opposed to “soft body”). A rigid body is an object that keeps its shape when forces are applied to it, like a pool ball. That simplifies the physics, but it isn’t the best approximation of how characters move. All in all, for many games, the work to ‘turn off’ the undesired parts of the physics simulation can be more effort than building the parts they do want.
What about Crowfall? Because we are trying to keep the character pill in the physics simulation all the time, we are currently using the Dynamic controller model. But, because the audience we are aiming for is PC MMO based, we are trying to make it behave like a typical MMO Kinematic controller when it comes to turning, starts and stops.
When I start talking this mumbo jumbo to people their eyes usually glaze over. So I like to describe theCrowfall characters as wearing a belt of rocket thrusters. When you press the W key to go forward, the character activates the rear rocket thruster and moves forward. When you take your finger off the W key, the thruster is turned off. In a physics simulation, this is going to cause some drift because things do not normally stop on a dime. To solve the sloppiness of the drift in a Dynamic controller, we use a counterbalancing thruster on the front of the rocket belt to bring the character to an instant stop.
While it feels great when you play the character, there is a downside to these sudden speed transitions: the animators have very little time to blend the animation of one speed to another. For example, going from a full speed run instantaneously to a full stop can lead to a pop in the animation. Our animators put in the extra effort to make sure these transitions look as awesome as possible.
Let’s add another wrinkle into the mix: the internet is between your machine and the servers.
Initially we tried a pure server-based character controller model. When you press the W key a message is sent to the server to tell your pill to start moving, and the server sends back a message to the client to tell the client that the pill has moved or is moving. Unfortunately, even in 2015, the best roundtrip from a client, through the servers and back to the client is about 150ms-250ms. Though it may not sound like a lot of time, this roundtrip time can make the controller feel mushy and unresponsive. When tested under lag conditions it was really noticeable, not that you can play most games if there are lag storms going on, but we want to account for the possibility.
We went with the server model initially to try and keep the pill in the exact spot it should be in the physics server at all times and just pass down updates to the client, which would have been great if it had given us the responsiveness we want.
We tried it, weren’t happy with it, and are planning on adjusting.
Post Combat Milestone 1, we will start building more traditional client prediction technology. (Most folks might have heard of this before because it is how most MMO’s - and games in general, for that matter - are set up.) What this means is that we will be moving the character on the player’s PC and sending the desired position to the server. This will allow the client to start moving the character the instant the W key is pressed and then the server will essentially follow and validate the movement commands coming from the player’s client. If anything gets wacky (speedhackers, etc) the server is still in charge and will warp that player back. We are still planning to keep using our version of a Dynamic controller that feels Kinematic to keep the pill in physics sim on the server, it just isn’t as precise as the pure server model.
Hope you enjoy the update!
Thomas Blair
Design Lead
The code that moves a player around the game is something called a character controller. While we are all familiar with the animated 3D character that appears on the screen, under the hood the character is represented as a much simpler shape. We affectionately call that simplified shape the ‘pill’ or ‘character pill’. We call it this because it looks like a pill. The character 3D model you all know and love is attached to the pill and essentially just follows the pill around. Yes all those years you have been playing games, you are just steering a pill!
If you look at the screenshot below, you can see the controller pill that the knight is attached to.
In many games the pill size is normalized across all characters; very small characters use the exact same pill as very large characters. We intend to scale our pill on a per archetype basis, which might lead to some advantages and disadvantages for various archetypes. There may even be areas that smaller characters can get to that larger ones don’t fit!
So what about the character controller? In the world of video games, there are typically two kinds of character controllers used, Kinematic and Dynamic. Kinematic controllers have full control over the character’s movement and any physics-like behavior is part of the controller code. In contrast, Dynamic controllers use the physics simulation for much of their behavior and control the character via forces within the simulation. Both controller types can have a wide range of character behavior and both approaches have advantages and disadvantages.
Kinematic controllers are, in many ways, simpler to build. The only things the character can do are the things the controller allows it to do. Most MMO’s use a Kinematic style controller that provide the instant ‘start, stop and turn on a dime’ behavior we have all gotten used to over the years. It is totally unrealistic, but we have all become very used to that behavior. If it doesn’t work that way, we tend to think something about moving the character feels weird.
Many action games take their Kinematic controllers a step farther and allow the character to mantle over obstacles or limit how fast the character can change direction. Adding even more complexity, many racing games use a Kinematic controller that emulates the way that a car drives.
The downside to Kinematic controllers is that you need to build EVERY part of character behavior into the controller. If you want your character to fall off things, you have to write that into the controller. If you want your character to push other characters around, you have to write that, too. If you want a boulder to push the character, that’s another part of the controller to write. If you have a physics simulation in your game and you want your Kinematic controller to behave the same way physics object do, you can spend a lot of time recreating the rules of the physics simulation.
Dynamic controllers try to minimize how much of a physics simulation you have to write by just putting the character into the game’s physics simulation. . This type of controller uses the application of force to make the pill move. Want the pill to move forward? Push the pill from the rear and it will start to move forward. Want the pill to keep moving forward? Keep applying that force. When you want the pill to come to a standstill, stop applying the force. This is great for games that want to leverage the fun and emergent behavior of their physics simulation as part of their character controller.
Sadly, there is no free lunch here. Once your character is being controlled by the physics simulation, you get everything that comes with that, some of which you may not want. For example, if your pill brushes against a wall, the simulation will apply friction that will slow you down. Another challenge is that when people say “physics simulation,” it’s shorthand for “rigid body physics simulation” (as opposed to “soft body”). A rigid body is an object that keeps its shape when forces are applied to it, like a pool ball. That simplifies the physics, but it isn’t the best approximation of how characters move. All in all, for many games, the work to ‘turn off’ the undesired parts of the physics simulation can be more effort than building the parts they do want.
What about Crowfall? Because we are trying to keep the character pill in the physics simulation all the time, we are currently using the Dynamic controller model. But, because the audience we are aiming for is PC MMO based, we are trying to make it behave like a typical MMO Kinematic controller when it comes to turning, starts and stops.
When I start talking this mumbo jumbo to people their eyes usually glaze over. So I like to describe theCrowfall characters as wearing a belt of rocket thrusters. When you press the W key to go forward, the character activates the rear rocket thruster and moves forward. When you take your finger off the W key, the thruster is turned off. In a physics simulation, this is going to cause some drift because things do not normally stop on a dime. To solve the sloppiness of the drift in a Dynamic controller, we use a counterbalancing thruster on the front of the rocket belt to bring the character to an instant stop.
While it feels great when you play the character, there is a downside to these sudden speed transitions: the animators have very little time to blend the animation of one speed to another. For example, going from a full speed run instantaneously to a full stop can lead to a pop in the animation. Our animators put in the extra effort to make sure these transitions look as awesome as possible.
Let’s add another wrinkle into the mix: the internet is between your machine and the servers.
Initially we tried a pure server-based character controller model. When you press the W key a message is sent to the server to tell your pill to start moving, and the server sends back a message to the client to tell the client that the pill has moved or is moving. Unfortunately, even in 2015, the best roundtrip from a client, through the servers and back to the client is about 150ms-250ms. Though it may not sound like a lot of time, this roundtrip time can make the controller feel mushy and unresponsive. When tested under lag conditions it was really noticeable, not that you can play most games if there are lag storms going on, but we want to account for the possibility.
We went with the server model initially to try and keep the pill in the exact spot it should be in the physics server at all times and just pass down updates to the client, which would have been great if it had given us the responsiveness we want.
We tried it, weren’t happy with it, and are planning on adjusting.
Post Combat Milestone 1, we will start building more traditional client prediction technology. (Most folks might have heard of this before because it is how most MMO’s - and games in general, for that matter - are set up.) What this means is that we will be moving the character on the player’s PC and sending the desired position to the server. This will allow the client to start moving the character the instant the W key is pressed and then the server will essentially follow and validate the movement commands coming from the player’s client. If anything gets wacky (speedhackers, etc) the server is still in charge and will warp that player back. We are still planning to keep using our version of a Dynamic controller that feels Kinematic to keep the pill in physics sim on the server, it just isn’t as precise as the pure server model.
Hope you enjoy the update!
Thomas Blair
Design Lead