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.

Check out this, it may have some guidance for you - this is a Physics controlled ball in multiplayer
https://forums.unrealengine.com/community/community-content-tools-and-tutorials/106824-assets-replication-and-networking-tutorial-project-blueprint

I explained this in your other thread on the same issue (also, please don’t duplicate topics)
https://forums.unrealengine.com/deve…th-medium-ping

Your goal really isn’t that simple.

Client-Side prediction cannot be done for a single object in a physics scene. Physics systems work by integrating all the objects in the scene at once. You can’t simulate just a single object on it’s own which means client-prediction and reconciliation is not possible without duplicating the entire scene, saving it’s state and replaying it for corrections.

This is an unsolvable problem and always has been, it doesn’t matter if the objects are player-controlled or not. Even if you manage to do replay for an entire scene (which is what Rocket League does, and that is very similar to your request) - you still can’t easily solve the case of two latent clients simulating at different framerates and colliding with the same object. Watch the talk about how Rocket League does it’s best to handle it.

There are a lot of GDC talks aout there about how games solved it for their specific use-cases but there is not a one-size-fits-all solution.

The only solution to this problem is deterministic lockstep, which isn’t really used anymore outside of online fighting games because a) no physics engine is determistic accross different platforms or framerates and b) it creates issues with input lag.

That’s crazy. I never would have imagined I wouldn’t be able to have a pushable box in multiplayer with Unreal Engine.

is correct. Your problem is the physics simulation portion. To accurately play back corrections, you need to store the physics state of the entire physics scene each frame, warp to that point in time, apply all the corrections you have for that frame, and then continue forward.

Ideally you’d do that by storing playing input or forces for each cube, etc.

The NetherRealms guys did a good talk on what this takes:

Well. I tried storing all of the data for the cube every frame in an array with a timestamp (velocity, location, angVelocity rotation, timeStampMS) and the server would send updates to the client with the same data (velocity, location, angVelocity rotation, timeStampMS). When the client receives the server update, he looks back in time (the array) using the server’s timestamp, and compares where his cube was versus the server update. Then the difference in velocity is applied to the cube.

However, this method doesn’t work very well and it produces resistance when the player tries pushing the cube.

Basically, from what I have gathered, I should give up on even trying to get a simple box to simulate on the client and the server. I can’t believe Unreal doesn’t support this. Surely there is a solution without determinism

@ @Let me ask you this.

Let’s say that I only simulate physics on the server and replicate the transforms to the clients. The issue with this (besides the input delay, which I might just have to deal with) is the fact that the client has trouble pushing the box. I assume this is because only the server version of the client’s character is able to move the box. Therefore the client is unable to move into the box, resulting in a push. Is there a way to fix this specific problem so that the end result is working physics with a high latency?

If the server is authoritative over everything, then it becomes simpler because, as you said, then it’s just replicating the movement of the cube. There should be no problem with the server pushing it as long as your character is telling the server to push the cube (applying the force of the player velocity to the cube on the server, or whatever method you have for moving it).

There would be a small delay between the client’s character pushing the cube and it actually moving, but you could hide that delay with an animation on the client end (character puts his shoulder against the cube, etc).

Maybe I am misunderstanding, but the issue that I get with that is that the client player is unable to push physics objects (or he pushes them very slowly) because on the client he tries to push it, but it doesn’t move (because physics is only simulated on the server), which means his velocity is zero pushing against it, which means on the server is velocity is zero, therefore the cube won’t be pushed forward.

Basically there is no way for him to push into the cube when the cube is being set to the servers position, because the server is always behind the client’s actions. Client pushes cube, can’t do it so his velocity becomes zero, zero velocity on the server results in the cube not being pushed.

Hmm, I’m not sure that I explained that well. The client can’t directly move objects on it’s own because the physics isn’t simulated on the client. The objects can only be moved if the server’s version of the client character collides with them. That means that when the client pushes a physics object, it won’t move until the server says the client’s character has pushed it. Which means on the client, his velocity becomes zero when pushing the cube because it won’t budge, and then his velocity and position get’s replicated to the server, which then only moves the cube a little bit if any. The client would have to move into the cube for the cube to really move. Hopefully that is a more clear way of explaining it

One solution is to have the player click a button which then pushes the cube a set amount. This would solve the problem of the player not being able to push physics objects. Although, it’s not optimal game play wise

I’d suggest taking some time and going through the Character Movement component and how it handles packing client moves. You should be able to piggy back on that data (you could simply add an input vector which is from the client stick + whatever) and apply that server side when you go to read the client’s movements and validate them.

All I’m really saying is that it’s not an engine-specific problem, you’ll run into the same issues regardless of the toolset you use. Nothing multiplayer is ever easy, unfortunately…

You honestly might not need to do anything though. Characters can push physics objects out-of-the-box, and are treated as kinematic by the physics engine. Both the client and Server will move the physics box, and if replicating movement from the server, then the client will receive authoritative updates. There shouldn’t be any issue with you pushing a physics box with a setup like that.

If the clients’ ping is low enough it may be acceptable enough for your use-case. There is a relatively new physics replication system which smooths replicated physics objects a little, and that can help with micro-jitter over small distances. Prediction is just another kettle of fish entirely.

Does this physics replication system have to be enabled?
At 150 ping (which is the most I plan on supporting) the default replication system causes stutters when pushing around cubes.