Game Development Reference
In-Depth Information
•
Unique game states
: These are one of a kind in the game, and in order to
ensure uniqueness, these game states have an associated key. The lives of
unique game states are similar to that of normal game states. An example
where this is useful is when two or more players claim on something in
the game and where only one player will be allowed to have it. A player
claiming to have won the race or a player claiming to have picked an item on
the ground are some of the examples where we would use unique game state
to implement.
•
Actions game state or actions
: These are different from others in terms of
how long they live. Unlike all the other game states, an action game state is
not persisted, but the server quickly passes the game state to the rest of the
players. Actions are useful to implement when a player fires a bullet. When
a player sends this kind of action, it is received by all the players and could
animate the action in their own screens. This is also great for implementing
emoticons such as waving or saying hello to another player in a 2D/3D
virtual world kind of game.
If an audience or a player joins a game that already has started, all the initial, unique,
and normal game states are pushed to the player entering the room so that the player
can get up to speed with the current state of the game. After this the newly arrived
client/player will send and receive game states like the rest of the players who were
already in the game. The newly entered player does not receive any game state
actions that were exchanged before the player entered the game.
As we learned in Chapter 4, a room can exist in two states,
waiting
or
playing
. From
the previous figure, we observe that when the room is in the waiting state, only the
game host is allowed to add game states and these game states must be marked as
initial. Any other game state types that are attempted to be added will be rejected
by the server.
