Does 4.8 support root motion replication for multiplayer games?
All the searching I’ve done on this has turned up posts from ages ago, nothing more recent. The documentation is quite vague on this too.
I have tried to get it working in the most simple fashion using the third person template. I have an animation blueprint set to root motion on everything and all the animations have root motion enabled. If I run the project the character moves around fine with root motion controlling it. If I set the number of players to 2 then the character is Ok on the server but not on the client, the best I’ve managed to get on the client is the animations playing but the the character does not move.
I’m close to tearing out what little hair I have remaining!
I have the exact same problem with Generic shooter. Switched to root motion animations, works fine with one player. When I switch to two I cannot get the animations to replicate or the character to move forward. It is then replicating in place on the local machine and does nothing on the secondary players view port. Anybody help on this? Is there a specific setting for root motion replication that needs to be enabled?
Hello MrMrC, I’ve replied to your post in the Generic Shooter thread, seems like we’re both in the same boat here.
I’m hoping someone from Epic can get back to us on this, if root motion is simply not supported for character movement in networked games then it would be a huge help to know for sure. Save wasting a lot of time working on root motion anim graphs & controllers that will never be of use.
Thanks a lot for the info, just to clarify, you’ve unhooked both Input Axis inputs from the Add Movement Input nodes, is that right? Then you’re using those inputs to create speed and direction variables for the anim graph and you’re replicating them with Rep Notify events?
I created new input nodes (WSDA) each of them impact the Y scale or X scale (variables). I.e. walk forward sets Y scale to 0.6 run forward sets Y scale to 1. Then the blend space and animations controls the actual movement.
I’m starting to think that we may be being a bit naive over how this will perform in a real networked environment. I’ve been doing a lot of reading on the networking side of things (new area for me!) and the page in the docs that describes the CharacterMovementComponent highlights the complexity of this stuff, particularly all the predication and correction it does behind the scenes.
This approach of just replicating a couple of variables may appear to work now but in a full game? I’m not so sure. I’ve certainly noticed the odd little glitch with only four players, and that’s in a level with nothing else going on.
I really wish someone from Epic (or anyone!) could chime in here, if any of the forum mods are reading this and they know someone at Epic could you give them a gentle prod please?
Also found this in the 4.6 Release notes on Root Motion from Everything:
Note: The original system (now labelled “Root Motion from Montages Only”) was designed with network games in mind, which is the reason for its more restricted functionality. Because “Root Motion from Everything” is designed to be complete unrestricted, we recommend using it only in games where animation isn’t replicated over the network.
So unless this has changed in 4.7 or 4.8 (has it?) it seems we have a choice, use Root Motion and not have networking support in our games or make a networked game without Root Motion animation.
Well as an opinion as to our work in progress there are a lot of disadvantages to using Root Motion in a networked game as to predictability. The player movement component on the other hand is designed for network play but there is no reason not to have both if the RM animation is viewed as just another data set available based on the need in hand.
In our case the animations are authored as RM as it makes life easier for the animator not having to back key say a ladder climb but once imported the movement data is stripped off and and the player model bound to the PMC and the RM data used to correct the movement behavior as a imputed sample.
Root Motion is great as it is easy but the real question should be what would happen on a server with 100 players all using Root Motion?
Root motion is a fire and forget weapon with little or no error correction like the PMC has so if the network code hiccups the player model on your client could be going one way while your player model on the other end going another.
Sorry I was just sending a link to this topic to someone and have only just seen your replies, thank you.
I’ve decided to go ahead with root motion for my game despite the concerns, as an ex-animator the look is more important to me at the moment Hopefully if I ever finish it root motion will be properly supported by then, worst case is that I’ll need to re-do the anim graph and add all the hacky stuff to prevent foot sliding!
The main issue is there is just not enough practical data as to what is a more advanced means of producing hyper active player control as compared to a more traditional means of control when co-op or network needs is also a need. The movement component (aka bounding box) has always been used since day one and over the years has become “trusted” if all you need is a predictable result so our coders would rather go with what works rather than experimenting with what could be a much better form of animation control that takes to being data driven as a duck to water.
The question though is Root Motion as a system something worth investing what amounts to R&D that may or may not produced the required result?
Personally this is time I’m willing to spend but our coders are not so to future proof the design we are authoring all of our animations using root motion but the coder put in a function to strip off the root transform data making them all in place bound to the movement component. This way if RM becomes the way to go then it’s a flip of a switch.
As a personal opinion State Machines must die and with RM and layer blending there is no need to use them but needs a lot more proof as to implementation and predictability.