Networking Physics Discussion

[Manmax75]

Good job on the Bullet Wrapper by the way. I was going to go down that route, but decided against it (for now).

I've seen that article too, great source of information. Especially in the comments section below the article itself, they begin to talk about alternative methods to Client-Side Prediction, since it's sort of an old system, and rewinding and replaying can be rather expensive to do for complex simulations.

[Tayrtahn]

If my understanding is correct, the Source engine doesn't do any sort of physics replay on the client. Instead, the clients are treated as though they exist slightly in the past (10 ms or so). This means that instead of having the extrapolate the position of where the object will be, the client can simply keep a buffer of positions where the object was (marked with timestamps) and interpolate where the object was 10 ms ago. Of course, having the clients "living in the past" no doubt creates its own set of issues, but it does seem to avoid the need to do physics extrapolation.

[Masaaki]

If my understanding is correct, the Source engine doesn't do any sort of physics replay on the client. Instead, the clients are treated as though they exist slightly in the past (10 ms or so). This means that instead of having the extrapolate the position of where the object will be, the client can simply keep a buffer of positions where the object was (marked with timestamps) and interpolate where the object was 10 ms ago. Of course, having the clients "living in the past" no doubt creates its own set of issues, but it does seem to avoid the need to do physics extrapolation.

It does no replay on objects that aren't completely under the player's control, but any object the player owns and controls (their player object, mainly, perhaps a vehicle they are riding, etc) does use physics replay. That "living in the past" bit is only for interpolating game state received from the server for objects the client doesn't directly control.

[Manmax75]

The server allows the client to handle collisions the player makes as part of its own prediction, if not then the client wouldn't predict properly in the first place, as the server would handle the collision but the client would keep moving. So in a way the client does *simulate* its own, yet very limited, version of physics. This simulated state of physics can be overwritten at any time of course by the server.

[speps]

I wanted to get my vehicle physics working but the Bullet API for vehicles is a complete mess and quite hard to ".NETize". I don't want to spend too much time on making that work. I think I'll try using another more simple physics engine, I just want nice networked vehicles

I released what I got so far on the Bullet plugin. Here is the code + Unity3D project : https://github.com/speps/UnityBullet
The project is only cubes because that's the only shape I did so far, if anyone wants to contribute I'll gladly accept pull requests.

On another note, here is an interesting document I found recently while reading a DOOM3 code review : http://fabiensanglard.net/doom3_documentation/The-DOOM-III-Network-Architecture.pdf

It seems like they interpolate/predict everything :

The system presented here uses prediction on all entities in the PVS of the client to both improve
the responsiveness and to present a smoothly changing environment. This includes prediction of
the player movement because the avatar controlled by the player is also an entity in the PVS of
the client.

It's quite well written and easy to understand, and the source code is under GPL : https://github.com/TTimo/doom3.gpl (check the network tab for more up to date forks)

[Manmax75]

Due to the increasingly high amount of issues brought about by Unity's lack of efficient networking for physics heavy games, I've unfortunately been forced to swap engines from Unity to UDK. The built-in networking in UDK is phenomenal, and the physics system provides an efficient and effective way of doing smooth interpolation and prediction of objects and players as well allowing for complex simulations that are interactable for the client. Luckily I was still in the prototyping stage for my game so it's not a great big deal doing this transition. It is unfortunate that it came to this, but I knew I would be spending at least well over a year to bring the networking up to a stage I was happy with, and that is time I just do not have.

Unity is a great engine, there is no doubt about that, and TNet is a fantastic solution for the sub-par inbuilt networking for Unity, I would certainly recommend it to anyone. I'd also like to thank Aren for all his help, as well as every other community member on this board. Feel free to use this thread as a hub of knowledge for complex networking

Because I will be no longer needing my scripts anymore, you can all have them. Feel free to upgrade them where you see fit, they're all heavily commented and work generally well.

NetworkTime.cs is my own networking time solution. It accurately syncs time across all connected clients, and automatically checks for clock drift at a set interval and updates where necessary. The logic of it is based on this article: http://www.mine-control.com/zack/timesync/timesync.html

SyncNetworkObject.cs is the script that you attach to any rigidbody you want to be networked. It will automatically update the position and rotation and physics data of your rigidbody or object over to all clients. It's primary function is to buffer changes over the ping time so it can smoothly interpolate effectively hiding lag.

Global.cs is just a global singleton class where I hold some variables that both scripts reference, not really important.

Good luck guys, if you have any questions feel free to ask!

[speps]

I've always said that Unity was great for prototyping but there are huge areas of the engine which lack professional finish. Networking is one, physics is another. Try to combine the two in a game and good luck ! It's also why the Asset Store is thriving...

Thanks for the scripts, they might come in handy

[bloodwalker]

Hello.

I am working on an arcade soccer game in Unity that Uses TNet for networking and so far so good. The only issue I have right now is how to get a ball that is moved by physics move the same way on both clients. All other elements move flawlessly but the ball that is ruled by physics does not work like I wanted.

Is there a simple solution for this issue without coding physics on the server side)?

[ArenMook]

The simple solution is to let physics do its thing. Send sync notifications from the object's owner when there is a collision, or periodically (1-4 times per second at most), and let each client do their own physics logic. That's what I did in the Multi-Purpose Game Starter Kit as well.

[danfoo]

The simple solution is to let physics do its thing. Send sync notifications from the object's owner when there is a collision, or periodically (1-4 times per second at most), and let each client do their own physics logic. That's what I did in the Multi-Purpose Game Starter Kit as well.

So your recommendation for use of physics with TNet is to let each client run the full physics simulation and correct inaccuracies periodically (where the host/server is authoritative)? Given the state of Unity's physics, is there a smooth way to correct positions of objects influenced by physics? I have gotten the impression that it can become jittery pretty quickly? Thanks in advance!

[pyscho2day]

Use lerps and slerps when there are discrepancies between host and client else. Plus make sure to update the position every so often.  I use tno.send 1 time a second and tno.sendquickly 4 times a second to sync the position.  My team has people all over the world and any lag seen is very negligible.  one thing to note with the sendquickly is to time stamp the position so just in case a earlier position come in after a newer one you don't bounce backwards.

[ArenMook]

So your recommendation for use of physics with TNet is to let each client run the full physics simulation and correct inaccuracies periodically (where the host/server is authoritative)? Given the state of Unity's physics, is there a smooth way to correct positions of objects influenced by physics? I have gotten the impression that it can become jittery pretty quickly? Thanks in advance!

The key is to separate physics from rendering by putting the Renderer on a separate object set to follow its parent. I explained this concept quite a few times and used it on many occasions, including in the 2nd example that comes with TNet.

This way there will be jitter, but you won't notice it because it will be smoothly interpolated away.