I'm trying to create a first person shooter and I'm lost on what's a good, efficient methodology to implement the whole weapon handling animation system.

Now, I know that I could have a unique animation for every weapon, but this sounds very expensive. Do people use IK to modify hand positions so that they can reuse the same animations for similar weapons?

Also, How does recoil work? Is it baked into the animation? Or is it applied via script? In counterstrike it looks like it's baked into the animation (since they use hip firing), however, in COD it looks like

Id really appreciate any opinions because I am lost!

Thank you

  • 1
    \$\begingroup\$ I feel like there is no specific standard for this, and it would be entirely left to the developers own discretion for how complex they want it to be. You could use IK, or you could animate the hands fully. You could add recoil in the animation, or you could manipulate the model's root transform in code. \$\endgroup\$ – Yattabyte Jan 19 '19 at 18:23

There is a wide range of ways to handle this, starting from the obsolete use of sprites up to fully rigged bodies with inverse kinematics and everything in between.

So, to begin with, you can have textures. Recoil and reload animations are of course 2D animations. They can even be made to look good in a modern setting by having high resolution and using prerendered deph buffer... however that is likely not worth the effort in modern games.

For good while, weapons in first person view where designed only to look good from that first person view (could even have partial geometry and not be fully textured), and if hands where visible, they would be just floating there... in fact, there would be no body in first person view... if you were to hack the camera position you would only see some hands and a gun floating around.

This makes it very easy to animate recoil, reload, even having the weapon lag behind the direction you aim, adding shake and other effects. In fact, good animation will also include walking animation that serve as a form of character expression.

You can figure out if you have no body in a first person shooter game very easily: look down. Where are your feets? Can you find them by turning around? What if you go to a corner? If they are not there, the game does not have a body for the player in first person.

That of course is only true for the player in first person, not for enemies, nor for other players connecting via network or couch multiplayer.

I would suggest to start here if you are working on a single player first person shooter game. Mainly because the situations where you would need to worry about the first person view of another character or the third person view of the player avatar would be scarse.

Next step up is to use the same animations for single player and multiplayer. Old implementations would turn the head of the avatar in first person view invisible to avoid accidental clipping (some would use other tricks like make it small or turn out of view). That is only really needed if the game will run in platform that may not handle face culling properly, however these kind of tricks are still in use when they are needed for only a brief moment, often in cutscene.

Games of this age would often rely on turning the torso of the avatar to follow the cursor. It is a very distintive animation look were the avatar have a fluid walk cycle, their torso turns randomly, and their hands and head are very stiff.

For a multiplayer game, I would suggest to start with this approach, you can then upgrade if you have the means to. Just using the third person animations for first person view will allow you to prototype faster.

Games from this last decade has been able to fluidly animate arms and head to adapt to the direction where the player is pointing. That can be done with a large library of animations※ with parametric adjustments, or with a good inverse kinematic system.

※: keyframe and interpolations, either for rigged skeletons or for morph targets, either recorded from mocap and tweaked, procedurally generated, or designed by animators.

With this approach you can have all the flexibility you want without swapping models depending on whatever or not the character is in first person. However, as you can imagine, it is much more expensive.

It can sound odd given how expensive good inverse kinematic systems can be, however: inverse kinematics is the cheap option. Doing a lot of mocap having distinct and expressive animations for each character is the expensive option... yes, I know you cannot possible record the character aming at every angle, however it is possible to tweak animations in runtime, or, well, if you invested in mocap, you might aswell add inverse kinematics. However, if you only use inverse kinematics then every character will move the same way, with mocap it is possible to do better than that.

About recoil et. al. by using rigged skeletons, the character can always be a physics entity that react to external forces that offset it and springs back to target position dictated by the skeleton. So, you can have actual recoil as an applied force on the body, and your inverse kinematics will solve the rest. Ragdoll also becomes simply disabling those systems instead of switching gears, because the ragdoll is actually always there.

By the way, remember to use placeholders. Is is better that development does not have to wait on assets and animations, and often it is not clear how much polish you will be able to get with whatever budged you have. Also, the quiker you can start testing the better.

  • \$\begingroup\$ Hey Theraot, First of all, thank you for a very detailed response! \$\endgroup\$ – Sebastian King Jan 19 '19 at 3:29
  • \$\begingroup\$ Whoops, Fortunately, I am just doing a single player FPS so I will probably be using the floating arms method you suggested. I wont have to worry about any torso movement or head movement :) Based on what you've said, I'll probably go ahead with using IK as it does sound very useful. If I understood what you said, I should be able to reuse the same generic animations for different weapons (like say a automatic rifle animation) and running an IK pass over the hands... Does this sound correct? \$\endgroup\$ – Sebastian King Jan 19 '19 at 3:36
  • 1
    \$\begingroup\$ @SebastianKing Sure, you can reuse the same animation for similar weapons. I suppose that is useful if you have a very large set of unique weapon grips. For your consideration: Many games will just have a fixed set of possible grip positions and pick animation based on the grips of the weapon (say weapnon grip type A, type B, type C, etc... and then there are animations for each type). It is a tradeoff on realism, have a look at the grip of shields in dark souls. There is only one grip and only works for small shields. You don't hold large shields like that. Most people don't notice/care. \$\endgroup\$ – Theraot Jan 19 '19 at 3:54
  • \$\begingroup\$ Oh okay I think I see what you mean... So your weapons would have to have similar dimensions so that a particular animation can work for all of them? If so, unfortunately I'll be using downloaded assets so I might not have that freedom :,D \$\endgroup\$ – Sebastian King Jan 19 '19 at 4:26
  • \$\begingroup\$ regardless I have a much better understanding now so thank you so much. \$\endgroup\$ – Sebastian King Jan 19 '19 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.