Game Development Reference
In-Depth Information
One of the events may happen after the client requests to add a unique game
stateā€”it may either succeed or fail. If it fails, then it means that another player has
already added the card to his or her hand; in this case, the client requesting will get
an error message via onGameStateError . We simply move the card with the ID to
the other's array and we check if we have the three cards in the myHand array. If not,
we get a card from the deck and attempt to add the unique game state. If we receive
onNewGameState , we first check if the sender of this is self. If so, it means that the
client successfully added the game state and the card now belongs to his or her hand.
If the sender was not self, then we add it to the other's array.
Frog position
It is required that all the frogs start at position 0. But how do we make sure that all
frogs are at the same position in all the clients? To do this, we let the host determine
the starting position of the frogs. Upon starting the game, the client who is the game
host will send out the position information to all the players in the room and each
clients will then move or add the frog to that position.
Assigning player color
Before the game can begin, each player must get a frog with a color. There are only
five colors and no two players can get the same color. There are two ways to do this:
one is having the host assign colors to everyone and the other is similar to how we
distribute the hand cards. In this implementation, we have chosen to implement it
the same way as the hand-card distribution.
Now the game is ready to begin!
Schema
In order to achieve all the above implementation, we first need to define the
necessary game states in the schema file.
Here is the schema file for the game:
<ObjectSchema>
<import>
<client import="pulse.gsrc.client.*" />
</import>
<class name="PlayerColor" parent="GameState" classId="601" >
<public>
<property name="color" type="int"/>
 
Search WWH ::




Custom Search