Absolutely love the Game Animation Sample Project (GASP) and the 5.5 update! I was super excited to hear that it now works with multiplayer! Awesome!
Well… Not really. If you add any amount of network latency to simulate a ‘real’ multiplayer environment (Editor Preferences → Level Editor - Play → Multiplayer Options → Enable Network Emulation), the client experiences pretty unsightly movement jitter and snapping when changing directions. Hosts/ListenServers also see others movement very jittery by default.
I have tried adjusting some settings (e.g. making the server correction more ‘forgiving’) but can’t seem to get this working. Anyone more knowledgeable with how this works able to get this working? Or is this a fundamental CMC/MotionMatching limitation in multiplayer?
I have also tried to use the ABP with the Mover Examples (using the new Mover 2.0 component) but also can’t get that to work!
I’ve noticed the same issue when simulating the network. I used 20 min 200 max latency for both in and outs. The jitters were not very good looking.
I decided to fixate the latency to 150 for both min and max for in and out again, thinking the jitters might be caused by the simulation(never used network simulation before so I wasn’t sure how it would act between 20 and 200 latency which is a big gap) but even with the constant latency I had some bad jitters from both server and client sides, even if it was less common to 20-200 gap.
As announced on the livestream by the legends that are Caleb Longmire (now at Epic) / Jose, this is a fundamental CMC issue (as I suspected to). They want to keep this a ‘BP Only’ project, and so with that limitation they have done what they can do.
…‘When Epic support good networking out of the box without code, that’s when we’ll update this Sample to do exactly that’
was the phrase used by Jose V. on the livestream. He is referring to replicating the trajectory ‘properly’.
The “multiplayer” will work OK for local clients (e.g. LAN / split screen) with ideal networking conditions. For True online multiplayer, you will need some way to replicate the trajectory for Motion Matching compatibility.
IMHO, they shouldn’t call it multiplayer-ready with this limitation, they should call it ‘local multiplayer / split-screen ready’, but that’s just me being grumpy.
Well, if I remember they also said it could be done better in C++ but we would need to do it ourselves.
I’m hoping someone in the community has enough experience to make a good networking solution for GASP. Or maybe there’s some plugin on FAB or something.
edit: today the download worked without any issues
There are various community C++ plugins that have replicated trajectory implementations. However, they all have their own quirks and shortcomings. The CMC is a ridiculously high bar for good optimised movement in a networked environment. Pick one at your own risk and be careful if you scale to more than 20 actors.
Or… You know… Epic could just release their version that they use to support Fortnight MM and we could shower them with love and unfinished games
If you would like my perfectly honest (personal) opinion - for my project that has a requirement for good looking humanoid movement that can reliably support 30 plus characters on the screen in a multiplayer context at any one point in time - I recommend not using motion matching and to stick with the default state machine “traditional” approach using purely CMC authored movement.
As amazing as motion matching is; the setup of it from my experience still required contextualising selectors and choosers based off the gameplay state of characters, which I feel takes away from the overall marketing of motion matching. A relatively similar end result can be achieved using traditional methods that do not introduce an additional layer of rather complex technical networking requirements. I also found myself personally struggling with getting motion matching results to get back up to the quality standard of traditional state machine, i.e. trying to ensure cycles completed fully and bugfixing “movement” artefacts.
To answer your question directly in terms of plugin support, the best candidate that I found was MotionReplicator and SmoothSync, which is a relatively close drag and drop support that would provide the additional replicated characteristics that the trajectory component relies on to produce its computed results. I leaned towards MR; the creator already made a “GASP + MR” pack which works reasonably well.
GASP + MR “Demo Project” by the creator Dexied - [Removed]
However, when doing some brief network profiling, I found that both added a significant additional bandwidth layer, which I’m unsure would scale well above 10 plus characters on a screen. all needed this. There was also a strange server tick requirement which affected some of the outputs. I haven’t myself delved too deeply in the engine source and exactly what network system they’re hooking into to enable this.
Thanks for the comprehensive answer, I appreciate you sharing your insights!
I decided to replace the aging ALSv4 in my project with MM/GASP, aware that it’s not feature complete yet and will have its quirks and shortcomings.
I think most of it can be worked out, but I agree with you, movement artifacts are a big problem.
There are a couple other problems that I hope can be worked around / fixed in the future (I have posted a few issues here in the forum).
I’m not sure if and how Epic will be going forward with the sample in the future, I was at the Unreal Fest Stockholm not long ago and I couldn’t get any qualified answers (any at all tbh) on how they plan to proceed with GASP in the future, from any Epic staff, even from a higher up project manager.
Anyway, for prototyping I’m kind of okay with what can be achieved with it in the current state, except the replication part really is hard to fix.
I could only test with a low single digit player count so far, but it’s actually mostly okay-ish with good ping, but as soon as a player starts sprinting, the character starts stuttering badly.
I’ll check out the network smoothing plugins you suggested and today I remembered the old ALS plugin (cpp version) has a custom CMC too. I looked into it and there are some network prediction functions in there - I’ll try to make that work with a GASP pawn and see if it helps.
I actually found the cause and a simple fix for the sprint stuttering. This fixes almost 99% of the problems with sprinting in multiplayer for me.
In the UpdateMovement_PreCMC calculations just add hard coded values for the sprinting state (”CalculateMaxAcceleration” and ”CalculateGroundFriction”). I can’t see any differences when playing so that solves the problem for me.
I made a video showing the problem and how to fix it:
