Root Motion for Multiplayer

MrMrC · June 1, 2015, 1:13am

I keep on hearing that root motion is not a good candidate for multiplayer games? Is this a valid point? What are the main drawbacks?

C

FrankieV · June 1, 2015, 1:55am

the documentation

Nothing there as to network concerns.

There is this though.

At this time, root motion is replicated across the server. However the AnimMontage is not. That means that users utilizing root motion will need to make sure they are replicating the state of the AnimMontage across the network. (Position, play rate, etc.).

Followed by this

Early versions of the engine (Versions previous to 4.5) required the use of a AnimMontage (Please see the AnimMontage documentation for more information).

Since version 4.6, Root Motion is now handled per animation and can be toggled on/off in the animation�s properties in Persona. To fully utilize Root Motion, your character will need an Animation Blueprint (More information can be found in the Animation Blueprint documentation ). Within the characters Animation Blueprint properties, the �Root Motion� section allows you to set which type of animations will have Root Motion applied to them. Please note that at the time of writing that you still need to use an AnimMontage for your Root Motion to be applied successfully.

So old news mixing in with new info that root motion does not need to use a Montage in newer version of the engine while I’m still assuming a Montage still has network issues so it’s unclear if there is issues still relating to root motion

P.S. Just did a quick test. Works fine in local mode but does not work using dedicated server. It wants to go but looks like the bounding box is holding it back. Our coder says he can get it to move as he is doing 100% of the game code in C++.

Definitely needs to be cleared up and will be a question I’ll be asking during the twitch release party for 4.8

MrMrC · June 1, 2015, 3:41am

Thanks for details. Might stay away from it for a few releases.

FrankieV · June 1, 2015, 3:47am

Yeah good call as to date Epic has not even said that it’s a known issue and will be fixed or due to network problems will never be implemented over network. (unless someone knows different)

JohnMakesGames · June 11, 2015, 7:48pm

Now that 4.8 is out, has anyone heard anything? It would be nice to have root motion in multiplayer games, but I can see it being an issue if every single bone in the character has to be replicated over the network or something like that.

Jezcentral · June 12, 2015, 8:08am

It’s not that it is no good for multiplayer games; it’s because it is no good for first-person games, which multiplayer shooters usually are.

In third person, if you run, then stop, your character will only stop when a foot goes onto the ground. This is to preserve “realism” and is why turning 180 degrees is so slow. As a result, you get a lag between what you are telling your character to do, and what it actually does. This would be unacceptable to the person controlling it, in a first person game.

Without root motion, your location reacts to your mouse/keyboard/controller input instantly.

Remember, the third person avatars you are playing against are not third persons (people), they are first person avatars, just being controlled by different people.

If your game is a third person multiplayer shooter, however, go for it!

EDIT: Two examples off the top of my head are: the new Unreal Tournament (first-person shooter, no root motion, incredibly fast paced) and Star Wars: The Old Republic (third-person MMORPG, uses root motion, slow with auto-aim).

JohnMakesGames · June 12, 2015, 6:49pm

That’s not entirely for all motions in 1st person though. Root motion can be enabled per animation- So you can have your standard locomotion animations normally, but then you want to do some special attack or whatnot where you momentarily lose control of your character while the root motioned animation plays. I believe Skyrim and/or Oblivion does this(power attacks) and it’s perfectly acceptable.
If you try to do it by programmatically nudging the character, you 1) don’t capture the complex movement of the character, and 2) you are going to have all kinds of issues with feet sliding trying to synchronize the movement to the animation.

FrankieV · June 13, 2015, 1:36am

As well you can fork your animations to cover both 1st and 3rd person. A fast 180 though can be done either way.

iniside · June 14, 2015, 7:58am

I doubt SWTOR uses Root Motion (and for that matter I doubt most MMO, use root motion).
Last time I played I could turn around character in matter 0.x to 0.0x seconds, depending on my mouse sensitivity settings. The same goes for Guild Wars 2, WoW, Guild Wars, etc.
I don’t see delay, when I turn character turn, when I stop, character stop (it’s not to say there no out animation, it just can be interruped at any time, without playing to end).
I personally can’t imagine playing 3rd person game with root motion which is unresponsive.
And actually the same thing goes for special things, like attacks. I just can’t get over with root motion here. Yes it’s cool, but loosing controll over my character just make me mad. And if I can’t interrupt animation, I’m about to start throwing mouse/controller/keyboard to walls. But that’s just me :D.

I rather see people use advanced IK system and procedural generation on the fly to smooth out animations, like it is done in Assassin’s Creed series.

FrankieV · June 14, 2015, 10:39pm

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.