Dynamic objects

[kayhhh]

Networked dynamic physics objects.
I see two approaches.

1. P2P Object Ownership

This is the approach that I believe VRChat uses. When someone grabs an object they become the owner of the object, acting as a source of truth for it's location. Can be easily spoofed - letting them put the object anywhere - but should work fine enough.

2. Central Authority

We could have the host server act as the source of truth for object locations. This is more expensive for the server. How much the server validates player input could vary - from a hands-off full trust approach, to running a physics instance of the world, checking the movement of objects, player movements, and more to determine whether they are "cheating".

Thoughts

I like that the first approach imposes no cost on the server. I was interested in the central authority approach, but upon further reflection I'm not sure of any immediate use cases that would require it. Main thing I think of is some competitive game involving physics, whether objects or player movement, but it would take such an advanced setup to work effectively that I don't think its worth planning for now. Other competitive games, for example battleship, could still potentially run logic on the server (not sure yet, still need to figure out scripting), without the overhead of a full physics simulation.

[kayhhh]

Hm a central authority could be good for enforcing "restricted areas", like preventing players from flying through walls or entering a certain room. I do like the idea of being able to enforce more privacy / access control levels, having rooms you can't enter or load the models for unless given access. This isn't just dynamic objects thing but a broader multiplayer architecture.

[Misterblue]

This topic can be a complex as you want to make it!
Systems like Eve Online and Open Cobalt use a synchronization protocol to allow "distributed computation" of object position. These solutions are somewhere between your two given possibilities with either client or server computing the position and there be later synchronization. (See info on the TeaTime protocol in Open Cobalt Wikipedia entry ) .
If you're not going to do some sort of state synchronization implementation, I'd think that central authority is your only option (given how good griefers are these days).