Authority | Authority transfer | Network Commands
In a networked game, an object's logic is always run by one node on the network, whether it's a Client or a Server (which we call a Simulator in coherence). We say that the node "has authority" on the network entity.
There are cases where it makes sense to transfer authority, like it happens in this project with objects that can be picked up. When the player grabs an object, the Client performing it requests authority over the network entity. Once it gets authority it starts running its scripts and has full control over it. This is a very good way to go when only one player can interact with a certain object at a given time.
For more info, check the lesson about transferring authority in the First Steps project.
However, there are cases when we don't want to change who has authority on an entity. In the case of an object that many players can interact with at the same time, it wouldn't make sense to continuously move authority between nodes.
The interaction with such remote entities then needs to happen entirely through Network Commands.
In this project, it is the case of the chairs placed in the scene. The first Client or Simulator to connect will take authority over them, and it will keep it until they disconnect.
When a player wants to sit down on a chair, they inform the Authority that they are doing so. The client holding authority will then set the chair as busy, which prevents other players from sitting on it next time they try.
However, for the sake of simplicity and to illustrate the point, we intentionally left this interaction a bit flaky. Can you guess why? What could go wrong with this setup?
The action originates in SitAction.cs:
SitAction checks if the isBusy property of the chair is set to true (by the authority, of course). If so, it means someone else is already sat on the chair. If false, we can sit. So it invokes Chair.Occupy().
You will find the code of chairs in Chair.cs, located in 📁Scripts/Objects. Looking into it, we find the property used as a gate:
And further down, the essence of the interaction:
So both when occupying a chair (Occupy()) or standing up (Free()), the player executing the action invokes the ChangeState method, either directly or as a Network Command - depending if they are the one with authority.
So one way or the other, ChangeState gets executed on the authority, who sets the isBusy property to its new value. On the next coherence update, the property will be sent to the other Clients.
The answer: Clients are using the isBusy property as a check for whether they can sit or not. It is possible that two players will approach a chair at the same time, check if isBusy is false (and yes, it will be false), at which point they will inform the authority that want to sit down on it.
The authority performs no additional checks, so you will see both players successfully sitting on the chair, overlapping on each other.
Thankfully we also coded the rest of the interaction so that this doesn't break the game. So while this incidence and the consequences for this interaction are low-risk, if you're looking to create a more robust system it could make sense to implement a check on the authority, and have the Client wait for an answer before they sit down.
We do this in other parts of the demo, like when chopping a tree or when picking up an object. Check the following section on chopping trees to explore this similar but more complex use case.
