NetworkRigidbody - Is this supposed to work like this?

[Seon]

I have a game scenario where 2+ players can drive around inside a game arena and push around rigidbody boxes (RBB's).

All RBB's are Network.Instantiated from the server, and spawn correctly on the server and clients.

Each RBB has a NetworkRigidbody script attatched to it and a networkView that is looking at the NetworkRigidbody script with Reliable Delta Compressed set.

Each RBB also has a script that turns OFF the NetworkRigidbody script on the server version of RBB (based on networkView.isMine) and makes sure the NetworkRigidbody script is on on the client versions (clones).

Everyone still with me?

Ok, so this is the result...

On the server, I can drive into the RBB's and they bounce around after impact and all clients reflect the movement and all is good!

On ALL client machines, the cars drive into the RBB's and they can hardly even nudge the RBB's like the RBB's have a mass of 10000.

This is consistent on ALL clients (Mac or PC), no matter who is the server.

So...

To me it looks like the networkView sync is going one way only, and that any updates on the server is reflected, but any updates on the clients are kinda not happening because the server version of the RBB hasn't moved and the clients are syncing with the server position/status.

So to me it's looking like a one way synchronization.

So, how am I supposed to setup a box with a collider and rigidbody in my scene to be able to be pushed around by any player at any time and have it updated correctly for all players?

[Seon]

Anyone from UT around that can answer this please? So far, both Jon and I are stumped as to how this can be setup to work properly.

[Mr. Animator]

This sounds like the behavior I would expect honestly - when it comes to networking, objects can really only be effected directly by the peer who 'owns' them. In this case, your server owns all of the rigidbodies, and the clients are only recieving information from the server regarding their transform information.

In theory, your state-synchronized clients are moving around on the server the same way each client is controlling them locally. Therefore you might expect the server to then 'see' the clients' effect on your rigidbodies and then broadcast that effect to the clients. The reality though is that raw state synchronization won't really accurately reproduce the velocity of your client's characters. All you're getting is their position in space updated 15 times a second (or whatever you have your send rate set to). As such, the clients are merely popping forward in tiny increments, which may appear smooth, but will not produce accurate collision with rigidbodies, such as ramming a box as you've described.

I think the results you're looking for will require some tricky business, such as fairly accurate prediction of your clients velocity (for accurate physics reactions).

EDIT: On second thought, there's also the issue that while your client may ram a box locally, it won't really react because the server is constantly resetting the position of the box, since its the only authority on sending information about it...

Here's an idea, perhaps you can have two rigidbodies... one that is the 'real' one, and one that is evaluated locally and doesn't render. Under normal circumstances, the local, invisible version is merely snapping to the server controlled 'master' version. However, on impact with one of the clients, the invisible one begins evaluating instead, and the client ignores the server's input for a half second or so. During this half second window, the client manipulates the box as it would normally, and after that brief window ends it sends an RPC to the server telling it where the box should now be and its current velocity/torque and so forth.

Hopefully that made a little bit of sense.

[Seon]

Ok, but if that is correct (as it looks to be) then how could you ever REALLY invent a game where to networked players can both effect the same object?

There must be a method where the state can syncronised 2-way based on player interactivity on each local machine.

Network updates are not fast enough to ensure that all the "client" colliders & rigidbodies being tracked on the "server" player are accurate enough to reflect exactly what the client did... for example...

My local car rams into a box on my local machine, and the clone of my car also rams into the box on the server machine, but due to lag and interpolation, on my machine where the box should have gone flying forward as I slammed sideways into it, the server machine (due to lag and int.) shoves the box half the distance and slightly the wrong way.

So in this instance, though the box movement will be syncronised between all clients, the physical reaction I would expect to see based on my collision looks wrong.

There must be a way for 2-way syncronisation.. UT?

[larus]

If a car (client owned) crashes into a rigid body box (server owned). The cars movement is sent from client to server so the crash will happen on the server as well, just as if the car was actually locally controlled. The NetworkRidigBody script (from the networking example project), does synchronize position, velicoty, rotation and angular velocity with a 100 ms play back delay. I'll mention that again below but first ...

If the server and client views of the world are exactly the same the client should interact with the box exactly as the server would. This is a sort of prediction as the client really isn't in control of the box in a world state sense only locally, he must bow to any network updates which control its position. He might hit the box causing some reaction, this reaction might not be identical on the server but the network updates should correct all errors. A script on the client side might apply network update the box in a controlled manner so the client side doesn't see the box skip around as errors are corrected. This is similar to what is done in the TPS-Auth scene in the networking example project.

Are you setting isKinematic on the box by any chance on the clients? That changes the scenario as the client no longer sees the world exactly like the server. He sees the box as an unmovable obstacle and is reliant on getting updates on the box from the server, based on his local actions as played back on the server. Now the latency on the clients movement being played back on the server could be messing things up. So the client runs into the box and completely stops, the server sees the client just nudging the box as he was stopped immediately by the isKinematic property he is seeing locally. He doesn't see the car run into the box and continue going. This is especially bad when using the NetworkRigidBody script. The script is playing back the boxes movements with a 100 ms delay on the client, but it is "played back" in real time on the server.

This is a bit tricky to understand and to solve efficiently (if it is the root of your problem). Its easiest to just not set isKinematic on the clients, keeping the clients view exactly like the servers view. Another solution is to play everything back with a 100 ms delay, including local changes, but that would make the local car seem unresponsive on the client side and pretty uncontrollable.

[Seon]

Hi Larus,

No, we are not using isKinematic anywhere. All clients see the same as the server and the difference in resulting hit between the client and the server is HUGE.

The server car can push the boxes around like that are a mass of 5, and the client cars hit the boxes and hardly move them like they are a mass of 1000.

The idea of the game is that players need to push their colour boxes onto the return bases the quickest. But right now all clients can hardly even move their boxes let along push them anywhere.

I will send you a build offline with instructions to re-produce the issue.

[spawrks]

Seon,

please post back what you find out. I am extremely curious about the ability of Unity to deliver physics networked play.

[Seon]

Sure will... I am currently working with Larus off forum to get it all working and will post my results once I have them.

[Orion]

Any news on this?

[Seon]

Since starting this thread, I have not found any workable solution to this problem.

The machine that OWNS the object in question (networkView.isMine) can interact with the object as you would expect with rigidbody physics reactions, but any other machine (client) that interacts with the object gets strange and useless results, definitely not you would expect from a rigid body interaction.

i too am still waiting for a solution to this.

[Proton]

I've only managed to get nice physics with with an authoritative server.

I am going to be experimenting with the NetworkRigidbody script a bit, since my cars are acting crazy when they hit eachother.

I think that turning off interpolation, by just setting m_InterpolationBackTime to 0, then replacing the following extrapolation line:

[shaun]

Hi Seon,

Networked Physics is not an easy one, and by the sound of things, you're hitting some similar problems we had a before. For us, each client takes responsibility for solving the physics simulation and the server runs the deterministic simulation that sends out a heartbeat to resync clients that get too off course. We thought that sending the same collision data to the clients, given the same simulation configuration would yield a predictable output, but PhysX appears to be non-deterministic, so that failed. Our heartbeat from the server holds things together - keeping the snapping to a minimum is a bit of work. Ideally we'd like to run the simulation separately from the visual output, so we can just interpolate the meshes toward their colliders - Tommy (touming) has worked a lot in this, I'm sure he'd be ok if you ask him a couple of questions - he may have a solution for two player controlled objects to affect a single rigidbody.

Also, have you had a look at this article? I found it cleared up a lot of questions for me.
http://www.gaffer.org/archives/gdc-slides-released#more-83

[Tubeliar]

I've tried a different approach that you might like. I've started toying around with the cars scene from the networking example, and wanted to add RBB's just to see if i could. In the cars example every player instantiates their own car, so they own and control it. But the network rigid body script makes sure that the car's clone on the server reacts like a rigid body too.

I handle the boxes differently. Where the cars' authorities are distributed, the server has authority over all the boxes, so it instantiates all of them just like you do. Now the difference is that i don't use the rigid body interpolation script, but just the network transform interpolation one (used in the castle example i think). Additionally, i derived a different network initialization script on the box prefab.

On the server the boxes are initialized just like the cars are, just the same as the original car init script. But on the client it destroys the collider and rigidbody components. This will turn them into 'dumb' boxes of course, but that is the idea. The server version still is a proper rigid body, and because of the transform synchronization, the dumb local version will move just as the server's real rigid body does! See, the local version doesn't need to be a rigid body, as long as it moves as if it were one

So why destroy the collider? Because if we don't the server will keep resetting the box at the moment of impact because of latency, and the car will crash into it as if it were a brick wall - just like in your original problem! We can safely remove the local collider because the remote car is still a proper rigid body as is the remote box, so they'll collide as they should and the box' movement will be sent to the client by the transform updates.

So why destory the rigid body component? Because now the box has no collider anymore, and if the rigid body component remains, it will keep trying to fall through the floor and everything else! You could of course disable the use of gravity, but as i said the local box doesn't need to be a real rigid body. Alternatively you could also keep the component around and try to use it for client side prediction.

So there's my solution. A couple of peculiarities though... The authority is a bit strange, since it's distributed for the cars and server authoritative for the boxes. A side effect is that you'll see your car drive into (but really into, as in they'll occupy the same space) your cube until it responds after the latency time. It will respond okay, just a little late. On another note, in this way your boxes won't exert force on the client cars. You'll have to fake it by maybe changing the local collider into a trigger instead of deleting it, and adding a force on the car locally. And make sure the server car acts the same! On the plus side, you can drive boxes into other boxes and they'll react precisely as you'd expect

[dreamora]

Problem with your solution is that with higher latency you basically risk that the game becomes unplayable / jumpy on the client as the user input no longer has the control authority, its the server instead and if it has to correct things on a regular base the player experience suffers drastically

Normally you would have both sides doing their job and only enforce corrections from the server if the data are outside of a given error threshold.
I guess you didn't use the network time for your checks to ensure that "latency based error corrections" are not enforced on the client?

[Tubeliar]

Actually, in the cars example scene you will never become jumpy locally since you have authority over your own car. If you connection is bad, then you will appear jumpy on the server and all the other clients, and all the boxes will be jumpy to you. But yes, this could lead to strange things like your car showing up in an unexpected place after a delayed update finally arrives. But then again, any game will become choppy when you have high latency. It's unavoidable, isn't it? It's just a matter of how you deal with it.

Both sides doing their job does sound like the best way, but as Shaun pointed out, the physics engine isn't deterministic. So you'll have to correct at least right after each and every collision.

As for the rest, i'm not doing anything fancy here. This is just the simplest thing i could come up with that looks okay with up to a couple of players locally, so it seems to be an adequate solution to Seon's problem. Even if there's a lot of room for improvement like client side prediction. I don't know how it holds up in a real situation though. I've only toyed with Unity's network simulation, and that was still playable (although not very smooth) with the server at dial-up speed.