FPS Character Controller movement - Any value in reverse engineering movement formulas?

Question

From what I know character movement in popular FPS games tend to be non-linear, but the easing curves change between games as each has its own signature formula.

Typically I imagine the physics engine would provide the feel by adding acceleration, deceleration and attrition.

Most basic games have a simple linear start-stop movement.

Is there any value in reverse engineering the "signature" formulas for these games, or are these openly known and available to everyone?

Also if these are well known where can I read upon the different implementations by these AAA FPS games?

Answer 1

---

Head bobbing

Stylized

Starting from a position in the world and then picking an animation based on that position and movement makes sense from a software engineering stand point. After all, the animation is – mostly – just a visual concern.

This approach will allow for more freedom in animation. And that is good if you want stylized – not so realistic – animation, useful to convey character personality, which is something you want in order to have multiple distinct characters that remain recognizable even in first person.

With this approach, you implement head bobbing by moving the camera (sometimes even independently of the body animation), the animator will come up with some motion curves for that. That is one think to tweak! Head bobbing, plus some sound effects will convey that the character is calm or agitated, for example.

Many tutorials will have you start with a capsule collider with a camera attached to it ✳cough✳ Unity ✳cough✳, and then animation is attached afterwards. That means that the camera is not attached to the animation, which leads well to this approach.

A drawback of imposing head bobbing this way is that it is hard to get right. In fact, it can even be a bad gaming experience if the animation affects your aim. You can stabilize it by rotating to whatever object the player is aiming at (so that head bobbing does not make the player aim to something else). However, that is one more thing to tweak! Do not stabilize the aim for a character that does not have much experience with weapons, for example.

References:

• Overwatch

  • Animation Bootcamp: The First Person Animation of 'Overwatch'

  • How Overwatch Conveys Character in First Person - New Frame Plus

---

Realistic

On the second approach you attach the camera to an animated model, which ideally comes from motion capture. That is what you want if you are going for realism.

The first problem you encounter is that the animation – even if they are from motion capture – will move the head around too much to feel right. In this case you need to start thinking of camera stabilization. The first thing to get right is turning the camera to compensate the rotation of the head (just like we can rotate the eyes to compensate the rotation of the head), in such way that it locks on where the player is aiming. The second part is translation, and that would be done by imposing inverse kinematics on the model.

References:

• Star Citizen

  • Star Citizen: Around The Verse 3.8 – DE

---

Animation selection

Realistic

The state of the art is skeletal animation with a blend-space. Usually a the blend-space is 2D, sometimes 1D, 3D is possible but not common. On it, certain points are mapped to certain animations at animator discretion... and each axis of the blend-space are mapped some variables. For example, you can have horizontal and vertical speed for movement, and different points in the blend-space are for walking, running, walking side ways, walking backwards, etc...

There can then be a weighted blend of these blend-spaces a cross the skeleton. For example one blend-space handles legs for walking and running, and another blend-space handles the arms for aiming.

Finally on top of that inverse kinematics tweaks the positions, for example making sure the foot contact the ground, and that the weapon aims where the players wants to, and – as mentioned above – stabilizing the head.

References:

• CRYSIS 2

  • CRYSIS 2: Getting More Interactivity out of Animation-Data

• Unreal Engine

  • BP 3rd Person Game: Blend Spaces | 07 | v4.8 Tutorial Series | Unreal Engine

---

Stilyzed

The alternative to skeletal animation, would be to use key-frame morph target animation. There you animate by picking the next key-frame and interpolating... that is about it.

Inverse kinematic is completely different here. Instead of trying to work out how to move the non existing bones, it is about picking key-frames depending on the surrounding and squash and stretch.

Speaking of squash and stretch, morph target animation is what you want for a cartoon like look, which is hard to get with skeletal animation. Which also means that it is likely that you won't be caring too much about precision of the animation.

---

References:

• Overgrowth

  • Animation Bootcamp: An Indie Approach to Procedural Animation

    Note: Overgrowth uses skeletal animation, however it demostrate animation selection by keyframes

• Jak & Daxter:

  • The Animation of Jak & Daxter - #1 - SQUASH & STRETCH

  • The Animation of Jak & Daxter - #2 - Faces & Blend Shapes

  • How Did They Do That - Jak & Daxter's Facial Animation

---

Extra: On the Animation of DOOM (2016): Bringing Hell to Life: AI and Full Body Animation in 'DOOM'

Answer 2

Is there any value in reverse engineering the "signature" formulas for these games

Fine-tuning the easing curves and such used in a game is often a highly iterative process that's fairly specific to the particular game being developed and how the creators want it to "feel."

The precise formula used for one game make not make sense for another, even if you are trying to emulate the feel of the first game for the second, because the feel of the camera control (et cetera) comes from more than just some the coefficients on some damping function. The way the camera (3rd person) or character (1st person) slides around collision objects, the nature of the collision geometry, the filtering applied to the sticks or mouse input before it reaches the camera system, the animations triggered in response... all of those (and more) impact that final sensation of control, sometimes in fairly subtle ways.

Consequently, I would argue that it's not worth the time reverse-engineering the particular formulas used by other games. They're probably not even particularly clever or magical. Further, the time and effort you'd spend doing so, if you take the simple and obvious approach, is essentially going to be the same as just trying to fine-tune your own curves and control systems.

I would advocate that you try to emulate a particular feel if you like, but focus on iterating towards and playtesting that feel. Don't focus on extracting a particular algebraic formula used somewhere in some other game's code. Focus on your game's camera and the context in which it operates.

or are these openly known and available to everyone?

The general family of such functions is fairly well known, and if you're interested in a good place to browse the broad-strokes options, you can check out easings.net.