How do I do clientside reconciliation on a rigidbody? Theres not much about it on google for unity. Any help is appreciated
There is no such facility built in. Look into motion prediction / correction in a multiplayer context. It’s a large field of study and any choices you make will knock-on implications in visuals, animation, and general all around feel of the game.
I did some research and unity did this with their multiplayer FPS sample, but I’m having trouble finding out exactly how they did it.
Should I try to create my own solution? Or am I probably going to fail?
Here’s what I’m planning on doing:
1.) Have a headless low profile “scene” running in the background
2.) Player receives input from server, telling him his last verified location (obviously a few steps behind the client)
3.) Client loads rigidbody into “headless scene” with last confirmed location, then uses physics.simulate to catch up to where the client currently is.
4.) “Headless scene” gives main scene the new information about the rigidbody, new position etc. and lerps to it (shouldn’t be a problem right since the physics should only be a few thousand decimal places off?)
Would love feedback pointing me in the right direction.
I would only do physics on my local character, and I would just take it as read all the other networked players.
They would have colliders so they would block you and interact as normal, but they would only have physics done on the machine that is controlling them.
So only leave one rigidbody in the scene on the main character locally, so physics.simulate only has 1 thing to update?
We solved it by doing distributed physics. The client that owns the item will do the physics. We also have a system in place that works recursive so if your item bumps into another item you take ownership.
Like here the door is owned by me, the items in front are not. When I bump the door I take owenership of them all even though the door is not touching all items
Edit: on the server we have copies of all colliders that we rollback to lag comp.
Here a dummy is being shot at, simulated 100 ms lag with clumsy app. They sync sub centimeter
1 Like
I think this is how I was trying to say it above… well-described MDA!
1 Like
So you say to only perform physics rollbacks on the client, or whatever the client is controlling (say a car). What if I have multiple cars per scene and all of them need rigidbodies. How would I only rollback and perform physics on the single car that the player is controlling and not all of them? Since physics.simulate, simulates ALL rigidbodies on the scene?
Should I just turn those rigidbodies (The ones that the player is NOT controlling) to kinematic ONLY while the re-simulation is happening? And then turn them back to dynamic after it’s done?
Why leave the rigidbodies on cars that players aren’t controlling? Obviously cars move at very high speeds, and rigidbodies have their own built in extrapolation function to guess where the rigidbody will be, so it doesn’t just look like it’s lagging along, since the server is the only one who can update it’s position. Please let me know if this is the wrong way to approach this.
Rollback has todo with lag comp its not directly related to the physics side. Rollback doesn’t care about ownership or physics. Rollback just records all collider states on the server and it knows the client lag so when a client shoots the server rollbacks collider states to this position.
Yes all none owner items are iskinemetic. This way you can bump in to them and it works is pretty well.
1 Like
So in my case, would I leave rigidbodies kinematic UNTIL a player enters a car, and then make it dynamic until he leaves? Or like I said in the previous example, leave them dynamic and ONLY turn them kinematic when the re-simulation is happening, and then convert it back to dynamic. The second example would be for the cars that a player is NOT controlling.
This is really the last question that I’m stuck on
In our game the server owns all world items from start and physics are simulated on the server for these items. Though they will probably be sleeping. The moment a player interacts with a server item for example throw a item at a door the player will take ownership of the door and is now calculating physics, he sends a message to the server asking for ownership, but he starts local physics right away so there is not lag. If two slow connection players throw a item at the same door at the same time one of them will loose but he will own it localy for a while so the door might behave a bit strange for a moment before he gets the packages from the owner and the door get its final rotation.
This way is the only way to get smooth physics. If you have played Dayz or arma you know how unsmooth it feels when server always owns objects
And lastly to clarify, the way to do physics rollback is something like this?:
FixedUpdate() {
if update was received from the server {
teleport player back to last confirmed position by the server
for loop every client input from that position until now {
execute the client input for that frame
physics.simulate
}
}
}
Sorry cant really write code on my phone, its much easier to do that way. Let me know if I’m wrong on the logic at all
We do it the other way around if the server thinks the player position is bogus we teleport it to last none bogus location. Zero lag this way.
How far off should the bogus value be? Because the physics engine is always different, so the server will only be like a thousandth of a decimal off right?
Ah no we do a running avarage of the player and if it’s outside of what he can move we will move him back. It’s not perfect but it works for us and means zero lag. It it’s not 100 procent cheater proof.
Btw it sounds that you are talking about rollback netcode, it’s basicly the netcode is hardwired into the physics engine. This is not possible in unity, maybe if you use DOTS physics.
There was a discussion about fighting games and rollback netcode a while back.
Though for Shooters this is overkill. And in shooters you have much more fine detailed control over the camera.
All I’m trying to do is do client-side prediction, and then with each packet received by the client, make him go to the last valid position and run physics.simulate using data from past frames to help rebuild it all in one frame, so I can have smooth predicted movement that stays in-sync with the server.
This is possible with unity, right?
And is my example from 2 messages ago the right way to do it?
Client side prediction? Don’t you mean lag compensation?
Client side prediction is when you do something locally without asking server first. For example we do this when we take ownership of items. We send ownership request to server but we also take local control of the item right away and start sending sync packages to the server. Server might deny this request and client will start receive packets for this item and it will be teleported to were ever the server / owner client think the item should be.
This is done with zero physics on the server.
Lag compensation, then we rollback all colliders to compensate for latency in networking between server and client. In my first post I posted a picture of a dummy that we use to test lagcomp it’s moving from left to right at 5 m/s and then we simulate latency using a application called clumsy. Physics aren’t really involved here either since we use trigger colliders that we move before we raycast against them.
Well im using rigidbodies for my main player. but for lag comp you would need to teleport back to last verified spot and then do a bunch of physics simulations in one frame for client player to catch up to the verified spot + the clientside inputs already made right? Thats what im asking about