Now we’re at the 3rd stop from roadmap. I’ll talk about field of view, which means that different clients see the scene differently.
Changing Scene Inside Session
Before jumping to field of view, let’s first look at a related problem.
Notice when I click on the figure, a valid move range will be shown on map.
This is during a session, and the scene is changed. Is this a violation of the architecture? Not really.
Suppose this is happening on P1. The move range is used as a hint to P1. Other players shouldn’t see this move range.
In other words, we are changing the scene locally to help P1 make a decision. After the session we will restore the scene.
As a result, the decision is made, the scene not changed. That is a valid one.
Field of View
Due to the design of synchronization, the scene will always be the same across different clients, which is a good thing.
We have already seen we can temporarily make the scene different during session. But what if we want to keep the scene different throughout the whole game?
Why do we want to do this? There’re many cases we want to do so, especially for card games, for example DiXit.
The above is DiXit. Different players only see his/her hand card.
The key observation to this problem is that the scene is not really different across clients. It’s only the players see the scene differently.
From the game system’s side, all hand cards are hidden. To be exact, the card property is hidden in the data structure. And this holds true for all data structure on clients.
We only change the visual display for clients. That is to say, we send some instructions only to P1 to make P1 see the hand card of P1. We do the same for other players.
In the end, we get a synchronized data structure but visually different clients.
Notice: only do this for logically insignificant objects, or else you’ll mess up pretty soon.