FrankieV
June 14, 2015, 10:39pm
10
Well from adding another opinion perspective this is the response I made when the question that the use of root motion in first person games was not ideal or considered best practice on our private message boards.
I don’t know where this idea that root motion is not suitable for first person shooters comes from except for an opinion based on personal experiences and my experience so far says that root motion in Unreal 4, and not an opinion based on some other engine, offers the advantage of matching animations with code where in place is difficult for the animator to match the movement system to the game speed and physics.
With my research the solution to the problem is to make the movement system 100% data driven wrapping all of the movements into a 8-way blend spaces which becomes an absolute value as to movement changes instead of using state machines which decides by an argument when and at what time the movement can exit a state.
The advantages to the coder is the “data” is exposed and at anytime can change movement dynamics that is limited to a single blend space block, keeping the plays feet on the ground, or increase/decrease the animation scale of a single clip, once again keeping the players feet on the ground. With in-place it becomes difficult to sync game speeds and velocity as it lacks a data set that is root motion to extract corrective measures to something as simple as climbing up a ladder.
Gets better.
Most games I’ve seen tends to cheat by using one set of animations inputs that binds the 1st and 3rd person together as a single player control that demands that both are limited by the arguments needed to get into and out of a state machine that generally translates to a latency.
This is where my experiences with <insert past game name> comes in as the 1st and 3rd person animations are not synced and uses two different animation pathways and the timing between the two do not match with the illusion that the game speed is snappy and not lagged based on the needs of the 3rd person model to at least have some level of weighting to look smooth (realistic).
In other words it’s a magic trick where the viewer does not know how it’s done and once again the 1st person animations will be 100% data driven using blend spaces and reacts to a key being pressed with out having to wait for a state machine to decided when it can come out of a state by argument.
My conclusion is root motion and blend spaces is good state machines and in-place are bad as they are not compatible with the demands of code being able to take 100% control over the movement system that is just as buggy to the 3rd person as as it is to the 1st with out looking at the fact that animations is nothing more than another data set being poorly implemented. In other words a rookie mistake.
With that said animation is not what you see but the result of keyframed variables created and changed over space and time and would be simpler to ignore the XYZ information placed on the single root if in place is needed and in turn future proofing as to any design changes and additions that might come along during the iteration process.