In order to implement this game, we first need to think of what we need to communicate between the clients in a room.
In the case of a client-server implementation, the card distribution is simple; the server will simply send a message to each player informing them of the cards that they should start with. And when a player plays or discards a card in hand, the card will be moved to the bottom of the deck and a new card from the top of the deck will be sent to the player.
But in Pulse-based games, we need to control the distribution without the help of the custom central server logic. In order to implement the card distribution, we would need the help of the unique game state feature available in Pulse.
Unique game states are just like normal games states, but with a key. When any one player adds a game state with a key, no other player can add a game state with the same key. If a subsequent game state is added with the same key, the add operation will fail and the sender is notified. So even if two players add a game state with the same key at the same time, the Pulse server guarantees that only one will succeed and the other will receive an error.
Among the 35 cards, we need to make sure that in our multiplayer implementation a card is only at one place—either in the deck or with one of the players.
After we create the necessary card in card manager, we also shuffle the cards. Note that each client does this operation independently. So the order of the cards in the deck in each player will be different. At the start of the game, each player needs to start with three cards. To implement this, we use the unique game states. Note that, the ID of each card it represents is the same in all clients.
From the previous flow-chart, we can see that there are three entry points into getting three cards into player's hand. The first one is when the game is set to start. We get a card from the local deck and create a unique game state with the key set to the card ID. The card ID is unique and the ID that represents the card is the same on all the clients. However, after shuffling the initial deck, the order may be different within each client. Because of different orders on different clients, the conflict of two players getting the same card is also minimized. The top card of the deck is at index 0.
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.
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.
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!
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"/> </public> </class> <class name="HandCard" parent="GameState" classId="602" > <public> <property name="cardId" type="int"/> </public> </class> <class name="PlayerAction" parent="GameState" classId="603" > <public> <property name="cardId" type="int"/> <property name="discard" type="byte"/> </public> </class> <class name="Frog" parent="GameState" classId="604" > <public> <property name="frog" type="int"/> <property name="position" type="int"/> </public> </class> </ObjectSchema>
This needs to be in the root file of the game project folder along with the init batch file as shown below:
@ECHO OFF IF EXIST .srcjjfgsrcclient del .srcjjfgsrcclient*.as CALL "%GAMANTRA%"inPulseCodeGen.bat .Schema.xml jjf.gsrc .srcjjfgsrc IF NOT %ERRORLEVEL% == 0 GOTO ERROR ECHO Success! GOTO END :ERROR ECHO oops! :END Pause
The paths in the batch file may need to be modified as required on your local project folder structure.
Let us examine each of the game states defined in the schema file:
PlayerColoris used for assigning the color to the frog of each player at the start of the game. This game state is added as a unique game state.Frogis used to communicate each frog's initial position, 0 being the bottommost. All frogs start at spot zero. This game state is added as a normal game state. Property frog is the color of the frog. At the start of the game, the host adds one game state for each frog. This is how the frog positions are synchronized across all clients.HandCardgame state represents one of the cards. This game state is added by a player in order to acquire a card in hand. Note that this game state is used (added) as a unique game state.PlayerActionis a game state that is broadcast when the player plays or discards a card. This is used as a game state action in the game.