The hassle of FPS animations
While developing our VR FPS project, we came across a thorny problem: How to manage character animations in the first person?
The question seems trivial at first glance. In fact, is it not enough to have a 3D model of arms and hands in the foreground, which reads this or that animation according to the current player action ?
Well ... not really.
In fact the problem is posed by the need to have a coherent structure of the code.
I give you an example: suppose our player has a Winchester 1892 and a Glock 17 in his inventory. When reloading the Winchester, the hands have to read the specific animation for the reload of that weapon. In the same way, when reloading the Glock, the hands must play the specific and unique animation associated with the Glock.
The problem here is that the hands object plays a specific animation to the Glock object. To do this properly, there are two possibilities:
- Either the Glock object contains all the information related to its animation and transmits it to the hands so that it plays it.
An elegant solution, but one that poses a problem, especially in a game that is in the early stages of development. This solution works only if you do not change too much the way the hands are animated during the development of the game. If that happens, then all the weapons already created in the game do not work anymore and it will be necessary to go back on each one of them. it so they can all be compatible with the new animation system.
- Either the main object contains all the possibly playable animations and the Glock tells him to play one in particular
This solution seems a little counter-intuitive because it is not normally handy to contain information that is specific to an object. That said, we think it is the most durable solution because a modification of the animation system involves only a modification on the hands. The weapons do not change because they only refer to the name of the animation.
That's why we chose the second option at the moment on the Terminus Project.
Consulter plus d'articles de Dev Diaries