I’m writing a multiplayer game with bullet physics and zay-es. I decided that I want to run the physics simulation both on the server and the client to increase the input responsiveness.
I have a PhyicsSystem that reads the positions of the rigid bodies and sets a PositionComponent on the entity. I manually sync the two physics simulations and I have a physicsstate on both the server and the client. Now the Problem is that the RemoteEntityData on the client is read-only but the PhysicsState has to write the position! I have thought of two solutions:
Extend RemotEntityData and allow writing of PositionComponents
Make a mutable PositionComponent
Both are a little bit hacky and i’m starting to think that i’m going in a totally wrong direction
This would be very hard to do right and is probably unnecessary.
In my own games, for real time state I have a separate component I use for that. It is mutable and handles its own multithreading. The server sets it and the network sync layer keeps it in sync on the client as the real time updates happen much faster and more efficiently than anything Zay-ES would want to do (not designed for it).
In your case, you could use it to push your local physics data in… and then somehow deal with the half-dozen types of paradoxes that come up in these systems. (teleporting versus tweening or whatever.)
The key with mutable components is that you no longer have thread safety so you have to many it yourself. And you no longer get the nice applyChanges() style update notifications… which usually in these cases is no big deal because it’s objects you iterate over every frame anyway.
Thanks for the response @pspeed!
I didn’t have much time lately but i have one more question:
I’ve read those valve articles you linked in some of your posts and I think interpolating is a better approach than extrapolating. The downside is that the network latency adds up to the interpolation time, which means that I have to implement some way of client side prediction. So I thought of local physics but now I realized that I would have to sync all forces, torques, etc as well. So is there a better way to implement client side prediction?
Yeah, don’t. I guess Valve gets away without using it.
Or at least, only do it minimally… it gets complicated whether you do it all or only minimally but for some things just let the player control them directly. For example, look direction should be instant no matter what. Movement in a physical object already tends to have a lag because of acceleration so you might already be ok. Else you could let the player move under local physics and collide with the local version of objects that only move under server physics. Occasionally tween to correct it with server physics for the player. Hope for the best that paradoxes don’t get too ugly.
Or let everything be controlled by the server and wait until you have problems and see what your options are. (But in any case, turning the player with the mouse should be instant or you will make people sick.)
