Server Authoritative Movement

[CorneliusCornbread]

Summary

As a 3D environment protocol, we are fundamentally faced with the challenge of how a user's position should be handled. In a discussion between @TheButlah and I we have decided (at least until another explanation or alternative solution presents itself) to require clients to respect server authoritative position data. This does not mean that client authoritative positioning in applications is not possible, rather servers optionally have the authority to tell a client its state is wrong.

Philosophy of Design

Fundamentally what this means is that a server can both simply act as a proxy, aggregating user position data about a client to all relevant clients, and as an authority, validating client position data via reasonable means (full-blown physics simulation, or simply position validation via physics checks). This has two technical implications which are very important to understand:

1. At the protocol level we must support some way of explicitly teleporting (not interpolating) a client to a given position. This is because of the requirement to allow servers to reconcile an invalid player position. See the section on drawbacks on specifically some problems posed by this decision.
2. For normal operation we need a way of specifying that a new client position should be interpolated. This would be an explicit protocol message that has the player's position. It was also discussed that these messages could optionally include extra information such as player velocity and input data (likely in the form of a vector).

Drawbacks/Blockers

Advanced reconciliation is a topic of debate yet. In applications where the server is doing advanced physics simulation (think Boneworks but as a Nexus application with full server authority done via physics simulation) how state desynchronization should be reconciled is not yet decided upon. I suggested that for these advanced applications, they would have to implement their own reconciliation and client prediction via WASM scripting (see #82 for further discussion). @TheButlah expressed concerns as to the use of WASM due to performance limitations and difficulty of implementation. In theory, however, the protocol would allow for applications to send a custom payload to a scripting system which could contain arbitrary information needed to properly reconcile state in these scenarios, see #80. Offloading this technical headache to the applications wanting to achieve such an advanced application, not monkeys, not our circus style.

[TheButlah]

Just as a warning for future readers, I have since pivoted completely and am doing a distributed authority scheme, like in the gafferongames article.