Download

How to make actor physics replication work with medium ping

Client side prediction.

That is the solution. However, after spending weeks trying to implement it, I am turning to the forums.
What my game needs to do is so basic, I can’t believe that Unreal doesn’t support it by default.

Basically, the only physics my game consists of is pushing around cubes. It’s a multiplayer game in which players need to be able to push around cubes that simulate physics. That’s it. Sounds basic? If only it were so. I can’t believe that Unreal doesn’t support net code to push around replicated cubes smoothly.

Using the default replicate movement causes major teleportation and glitches above 50 ping.
I want to be able to support 100 ping without major game play errors.

I can go into more detail about the client side prediction code I have written. It basically stores client information such as the transform and velocity of each cube in an array every frame, and the server sends the client the correct information for the cube every so often. The client then must nudge the velocity of the cube by comparing it’s past information to the server information sent to it.

I just want to get some ideas from anyone out there. My goal is seems quite simple. Maybe there is something that I am missing.

Not only am I shocked that there is no support by the engine for this. I am shocked that there is no plugin for sale for this. Crazy.

You would probably have to go into further detail what is happening vs what you want to happen.

Out of the box UE4 offers physics actor replication. This already does what you said you wrote, position and velocity are shared from the Server and clients replicate this. There will be a choppy movement when the information from the server is unexpectedly different from what the client predicts. You will get desynchronization when physics actors are gonna get pushed around in one client/the server but is not replicated properly.

Are you replicating the events of the physics actors getting pushed around properly?

Out of the box physics replication is horrible when you get past 50 ping. Especially around 100.

What I want to happen is simple. I want players to be able to push around a box (imagine the default first person template) in multiplayer without teleportation at medium ping. I want the game to be playable up to 150 ping.

The system I wrote is pretty simple. It simulates physics on the client and server.
The server sends correction data to the client about the cube such as location and velocity, with a timestamp (I synced the client and server clocks). So the client may receive a correction from the server that says “The cube had location(100, 50, 20), velocity(50, 0, 10) at the time of 1075ms”.

Every frame, the client cube stores the same information in an array (velocity, location, time).
When the client receives a correction from the server, it looks in the array for the data with the same timestamp as the server correction data. At this point, we have the server correction data at whatever time (let’s say 2000ms) and the client cube data that was at the same time.

I then apply an impulse correction to the cube using this calculation :

Mesh->AddImpulse((ServerVel - PastClientVel) * VelocityFactor + (ServerPos - PastClientPos) * PositionFactor);

I can adjust velocity factor and position factor to determine the strength of influence they have on the correction.

This solution in theory sounds great, but in practice it doesn’t work well. There are several problems that I haven’t been able to solve through adjusting the factors:

  1. The cube sometimes goes flying when the impulse is too great
  2. The cube’s constant correction towards the server position makes it harder for the client to push the cube
  3. The cube sometimes moves very slowly towards it’s intended goal.

I can provide a video of the problem and the full code solution if you want. It’s not very much code.

The problem sounds simple but it’s difficult to solve. I’m not sure your solution can work. Your client simulates/predicts in the present but you only correct the position towards the past. After correction the client needs to catch up to the present again (server reconciliation). The way to do this is to fast forward the physx scene.

I think the reason there’s no plugin for this is because it’s impossible to do in a proper way without engine modification. For the best results you need fixed timestep (requires engine modification) and determinism (requires replacing physx with bullet physics).

Depending on your gameplay another way could be to disable client-side prediction entirely.

TL;DR, it’s an unsolvable problem. You can’t do client-side prediction in a physics engine easily, there isn’t a one-size-fits-all solution for this which is why it doesn’t exist in the engine nor on marketplace.

The modern “solution” is to give the client-authority over the object they are controlling, and use anti-cheat detection and verification on the Server. That’s the only way you can give a smooth experience to the client. Even a deterministic physics engine won’t save you from input lag or desync. All of the objects within the physics scene can affect one another. Even Character Movement Component (which is a tightly controlled simulation) has trouble resolving when two player characters are running into each other.

Even Fortnite uses client-authoritive physics for it’s vehicle - and given that it’s probably the most popular game in the world, you should be able to get away with it too. Naturally, nobody is going to disclose how their anti-cheat works.

There are plugins on the marketplace that claim to do physics prediction - they are all talking rubbish. Any claimed “solution” I’ve seen so far is either completely unscalable, bespoke to the problem it’s trying to solve, suffers terrible performance and/or still falls apart when objects collide with each other. Take it from someone who has dealt with this for years - accept that client authority is the only way and integrate some decent anti-cheat that fits for your scenario.

Also a note: people love to throw “rocket league” out there as an example of client-predicted physics. Once again, the have a very specific and deterministic physics simulation, and use a completely bespoke solution that works for them. They only have a maximum of 9 physics objects to worry about, often fewer. It’s not a problem for that scenario.

The game I am working on requires that every object be in the same position for everyone. A max player count of 10, and a max object count at any given time of around 10-20. It is a sort of hide and seek type game, and it wouldn’t be fair if you thought that you were hiding behind a box when in reality the box was at a different location on the other seeker client.

I understand that you can use client authoritative for player controlled objects. But that wouldn’t work for physics objects in which everybody can move, would it? I don’t see how two clients could have authority over the same physics object (in my case, a box).

@TheJamsh

James, out of curiosity since you’re re-designing the physics movement in your own hover tank game right now, are you already building-in anti-cheat from the start? If so, what kinds of things are you thinking about at least. Systems to prevent vehicle speed cheats and stop cheaters shooting through walls etc?

I’ll try not to hijack the thread as I still have things to try and I’ll probably make a post with my findings/approach later, but the StorySoFar™:

Started with kinematic vehicles (similar setup to character movement), worked great for server-auth, responsiveness etc. but was really difficult to resolve collision. Required engine changes to sweep skeletal meshes properly, had to rotate bodies (think turrets) with animation nodes which means no animation optimisations etc. Overall quickly became expensive and doesn’t scale after 10-20 objects. Also hard for remote clients to do extrapolation, and resolving collision is extremely difficult. Acceptable for hovering vehicles, but less so for objects in constant contact with something (think wheels, walkers etc.)

I switched to physics-simulating vehicles and disabled the server corrections. I still send input and transform information to the server (input is used for server-simulation and also replicated to remote clients for extrapolation/visual FX between updates) - and the server does some very simple distance-checks for cheat detection at the moment, as well as detecting illegal inputs. That’s pretty much the extent of it when it comes to anti-cheat for movement. Could pretty easily be bypassed.

The key to anti-cheat is that other gameplay meahcnics can’t rely on client transforms. In my case, weapons and other items always use the server transform for spawning. For this to feel good I added client prediction for projectiles which was an experience in and of itself. TL;DR you can no longer rely on the client for any transform info, so you have to workaround that with other complex systems and learn to live with any inaccuracies.

I have also planned to try spooling up an “immediatte-mode” PhysX scene on the server for each connected client, duplicate all static geometry into it, and simulate client movement in that scene on the server - sending back corrections which the client will also simulate in an immediatte-mode scene and then apply to the main scene. This won’t handle the case where two players are colliding with each other all that nicely, but that’s a generally unsolvable problem anyway until we have quantum internet.

The problem is that going between a regular scene and an immediatte-mode scene is stupidly difficult, requires massive amounts of data duplication and one look at the engines rigid-body anim node (which uses immediatte-mode physx) put me off completely. It’s also way harder than it should be to copy rigid body information between PhysX scenes. They really didn’t make it easy.

One major issue with Physics is that it just does not play nicely with characters (which are kinematic and so treated as infinite-mass by the physics engine). I still feel as though kinematic vehicles are the answer, but they need to scale better and collision needs to be easier to resolve nicely - and the ridiculous amount of code that translates between PhysX and UE4 makes it hard to make that performant.


I’m now essentially waiting for Chaos and the newish Network Prediction Plugin from Epic. The former, I hope, will reduce complexity when it comes to translating between UE4 scenes and Physics scenes - and I hope will be more of a “utility” I can use to resolve collision nicely.

The Network Prediction Plugin isn’t much different to what I have already for my existing kinematic vehicles (shared netcode, separated simulation with input/output buffer etc.) - but it’ll be more refined and, I hope, also be more widely applicable to other gameplay concepts.

I’m trying to make Gmod/Source-style physics objects for a multiplayer game. I’m wondering if now that we’re in 2020, has anything changed on this coding battlefront? I can’t believe Source pulled it off so effortlessly all those years ago yet UE4 still doesn’t even have any plugins, features or fixes for it.

Source didn’t pull it off years ago. The engine can simulate physics objects on the network without issues, but like every other engine before it, it doesn’t do complex prediction or reconciliation out of the box.

I want to be absolutely clear - predicted physics for player-controlled objects in a multiplayer game is an unsolvable problem, largely due to the way physics engines work. This is unless you have a very specific, very tightly controlled game loop and can afford to rewind/resimulate the entire physics scene state - for example, Rocket League.

I wasted years on this by the way, I have the scars to prove it - if you guys want to go all in feel free, but from this guys position the general consensus (from everybody I’ve spoken to too), is that it cannot be done on a “general” level.

Epic are currently investigating a deeper physics integration with their new network prediction plugin. I’m watching this with a keen eye, as whether this will amount to anything I’m not sure.

@TheJamsh I’m a bit confused. My question is a bit different from the OPs. I’d like to make bullet collision feel responsive to the client. If, from their point of view and barring some exceptional lag, they hit an enemy, the hit should count.

It seems like you’re saying that accomplishing this can only be done via a client-authoritative model with independent, server-side cheat detection. That makes sense, but you also say not to trust the client’s transforms. I’m not sure how to reconcile those two things. Actually, as I think about it a bit more, it seems even worse: that I’d have to essentially have the client say whether they hit another player and the server simply trust that message. Am I missing something?

I don’t suppose you’d consider showing off something simple like a basic tutorial on how you’d do something like the ball from rocket league? I know a lot of people learn better from a functioning example they can mess around with and change to learn how it actually works.

I can’t really front the time to build anything that comprehensive as it’s really not that simple, but the video mentioned is here where they go into quite a lot of detail:https://youtube.com/watch?v=ueEmiDM94IE
A simple client-auth vehicle is relatively straightforward though.

Since this thread has been temporarily revived, are there any improvements to the physics networking in Chaos that are worth mentioning as it relates to this thread?

Well Chaos has a “Rewind” API now which definitely makes building those tight-knit small simulations far easier.

Epic are/have been working on an integration between it and the network prediction plugin for some time - though there haven’t been any public updates for a while. The latest version is in 4.26 I believe.