Actually in this demo, as it was just a very quick (2 hours) I’ve decided not to do any simulation on the server.
So clients do all physics. Server is only exchange point.
Each physical box has an owner, usually it is person who created the box. The owner (client) will periodically send data to server of that object, which immediately will be published to everyone, and every other client will rudely snap object to data been provided.
While they all simulate it as well, so it is “extrapolation” out of the box.
There are few cos and pros in such approach:
no intensive calculations on server so computation is spread between clients.
cheating - in order to prevent one owner of deciding things, there should be “shared ownership” and server should validate their data for consistency.
latency implications - as there is no centralised computation node, different latency might result in inconsistent positioning of objects. To prevent this “rude snapping” should be prevented, and data from owners should be used only to smoothly correct simulation.
This was just a proof of concept.
In fact server code in this example is about 80 lines of code.
For most games where players are kinetic, and physics has only visual purpose, this is perfect solution.
Event WebRTC can be used in order to sync the physics in p2p manner (as optional feature of game engine), so clients without WebRTC will simulate physics but not in sync mode.
To keep things simple, I do not want to implement full physics on server side… just simple bullet collision (which on flat world is line intersections), and simple players physics (circle intersections), and path finding (own algorithm based on line intersections again).
For the core of top-down shooter, that should be enough/