UNet = easy physics sync?

Unity Engine
,
1

So I know enough about multiplayer gaming issues to know that keeping physics based games in sync is a huge part of the challenge. Mostly just wondering if UNet has made this really simple to get working well, or if they just went the simple route of “it’s kind of accurate and you can do tons of work yourself if you want it really accurate” :slight_smile: Don’t mean that in a bad way, since either way it’s still a totally valuable tool.

For example: https://www.assetstore.unity3d.com/en/#!/content/46213 – if you play that enough over a not so good connection, would you find times where things get out of sync, and some players think they hit you, but you didn’t see a hit on your screen?

I just started looking over the code tonight, but so far I’m not seeing any of the complex calculations I’d expect to see in this type of game. So either those magic attributes (ClientCallback, SyncVar) really work well, or they just work “under good conditions” or “well enough”. Just trying to figure out which one it is, and if they really do work really well, then I’d love to know more about how/why they work so well.

2

No, it’s not easy physics sync. You still have to deal with that. The automatic network transform doesn’t do a good job of it.

3

There is a lot to Physics sycing. The UNet tools are nice for most stuff, but for physics you may need to code a lot of your own network syncing depending on how you are doing your physics. But UNet gives you the tools to do this with commands, rpcs, and syncvars.

For example.
-For explosions that create an impulse the explosion is applied to all server objects on the server, but applied to the player character on each client. So any RPC (or similar) needs to be sent to each client showing the explosion force. The explosion force is only applied on the client that owns the object (otherwise the explosion may move an object, and then it may snap back due to latency when the owner “corrects” the position).
-Friction and such slows characters down in-between updates. So in my case syncing position/rotation/velocity isn’t sufficient. I needed to sync postion/rotation/velocity AND commanded velocity, so that on every client the objects accelerate/decelerate to the commanded velocity in-between network updates.
-For persistent forces (such as wind) the wind object must be spawned on all clients and the force applied on all clients.