Comment on page
Remote interactions: Chairs
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.
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.
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
public void Sit(Chair chairComponent)
SitActionchecks if the
isBusyproperty 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
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:
[Sync] public bool isBusy;
And further down, the essence of the interaction:
public void Occupy()
if (sync.HasStateAuthority) ChangeState(true);
else sync.SendCommand<Chair>(nameof(ChangeState), MessageTarget.AuthorityOnly, true);
public void Free()
if (sync.HasStateAuthority) ChangeState(false);
else sync.SendCommand<Chair>(nameof(ChangeState), MessageTarget.AuthorityOnly, false);
[Command(defaultRouting = MessageTarget.AuthorityOnly)]
public void ChangeState(bool newBusyState)
isBusy = newBusyState;
// Deactivates the collider so the chair can't be even selected
So both when occupying a chair (
Occupy()) or standing up (
Free()), the player executing the action invokes the
ChangeStatemethod, either directly or as a Network Command - depending if they are the one with authority.
So one way or the other,
ChangeStategets executed on the authority, who sets the
isBusyproperty to its new value. On the next coherence update, the property will be sent to the other Clients.
The answer: Clients are using the
isBusyproperty 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
isBusyis 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.