Distributed Slap Jack

Transcription

1 Distributed Slap Jack Jim Boyles and Mary Creel Advanced Operating Systems February 6, 2003

2 1 I. INTRODUCTION Slap Jack is a card game with a simple strategy. There is no strategy. The game can be played with three to eight players using a standard deck of playing cards. All fifty-two cards are dealt. The players do not look at their cards but keep them in a stack, face down. A player s turn consists of turning over the top card on his/her stack. If the card is not a jack, the next player flips the top card in his/her stack. If the card is a jack, the players attempt to be the first to slap the jack. The player who succeeds in this endeavor picks up the cards played, adds them to their stack and reshuffles the stack. If a player slaps erroneously, a card is forfeited and given to the player who flipped the card. The objective is to acquire all fifty-two cards. If a player runs out of cards (not as the result of losing a slap), that player remains in the game and is eligible to slap the jack. If that player wins the next slap, he/she acquires those cards. Otherwise, that player is eliminated from the game. If a player without any cards slaps erroneously, he/she is eliminated. If a player quits the game, his/her cards are redistributed amongst the remaining players starting with the player to play next in the deal. Since it is likely that the cards will not distribute evenly, the last player to receive a card is noted and if another player quits the game then his/her cards are redistributed starting with the player following the player who received the last card from the previous quit. We will implement a distributed client-server version of Slap Jack using Java s RMI with multiple clients interacting with the server under strict time controls to ensure the fairest possible game. II. PROBLEM Slap Jack is a simple card game that presents some interesting complexities when implemented in a distributed computing environment. In the real game, the cards are dealt to the players face down, and then players take turns flipping cards face-up in a pile in the middle of the table. The goal is to accumulate all fifty-two cards. Cards are acquired by slapping the pile when a jack is flipped. To achieve this in a distributed system, the flipped card must be seen by all the players simultaneously. Otherwise, a player may gain an unfair advantage by seeing the card prior to the

3 2 other players. It should be assumed that in an attempt to gather all of the cards, when a jack is flipped, multiple players would slap at it. To achieve this in a distributed system, the actions of slapping, or pressing a key or clicking the mouse, must be accounted for in the actual order they occurred, otherwise, a player, perhaps on a faster machine, has an unfair advantage. The actions of slapping and flipping must also be coordinated since the slap can take effect prior to the card being flipped. Since all slaps must be accepted, the server must be able to match each slap to the card actually slapped. A slap that was delayed in reaching the server should not be interpreted as a slap for the next card flipped. Otherwise, it could have actually been the winning slap but processed as an invalid slap, which would result in a penalty. A player that has been eliminated should not be allowed to slap and a player that has quit should not be allowed to slap or flip a card. Other communication issues are asynchronous in nature. The server will start the game when it receives the start/ready command from each of the logged in players. The first play cannot be made until all the cards have been dealt to the players. This project is directly related to Advanced Operating Systems since it attempts to maintain mutual exclusion of a limited resource across a distributed system. I.E. when a jack pops up only a single player may slap it first. Essentially, we must denote the first slapper as the owner of the jack resource, and no other players may take ownership of that resource. It also must address timing issues across a distributed set of servers in order to flip cards simultaneously. Timing is a fundamental issue with synchronous distributed computing. III. STRATEGIC PLAN We have chosen to implement a client-server model of Slap Jack using RMI. Since portions of this project will be developed on different platforms including Windows, Linux and Unix, the portability of JAVA is a plus. The application can be divided into subsections as follows: the main game flipping a card slapping a card a player quitting a player running out of cards

4 3 a player being eliminated a player winning main game The main game section includes connecting players/clients to the game/server. When a player joins a game, a client process will be connected to the server. The client will provide the server with information about the player (player name, host name, address, player options ). The main game will also include the GUI to be used. The GUI will be used to login to a game. It will also display each play and any changes in player status that result. Communication between player/client and server will be accomplished through the GUI. The first player to login will spawn a new game. This player will indicate the number of players. When the last player has been logged in, the game will start. The server will shuffle and deal all fifty-two cards. player flips a card Once the cards have been dealt, the player starting the game will flip his/her top card. This card needs to be visible to all the players simultaneously. The player will send a message to the server requesting the topic card on his/her pile to be flipped. The server then sends this card (face down) to each player. The client and server clocks will be synchronized. The server will then send a flip card signal to each client at which time the valid slap period begins (time yet to be determined). The server will mark this card for removal from the appropriate player s pile. During the valid slap period, players will not be allowed to flip cards. Players will be notified when the slap period ends. The player scheduled to flip the next card will not be notified until the other players have acknowledged the end of the slap period. When the remaining player has been notified he/she can acknowledge by flipping the next card. player slaps When a player slaps (pressing the appropriate key or mouse click yet to be determined), the server will be notified by that player. Since multiple players may have slapped, the first player to slap must be determined. Once the server has received a slap request, players will not be allowed to flip cards until the slap has been completely processed. At the beginning of the valid slap period, the client clocks have been synchronized. When a player slaps, a timestamp will be

5 4 assigned and the method of slapping (key press or mouse click) will be disabled to prevent the player from sending a second slap. The server will use the timestamp to determine the winning slapper. Since the flip signal followed directly after a synchronization, the clock drift should be minimal. The server knows ahead of time if the card being flipped is a jack or not. Thus, the server already knows if the slaps for this card will be valid or invalid. If the slaps are invalid, then the server does not need to be concerned with the order of arrival, only duplicated and lost slaps. Any slap received with a timestamp after the end of the valid slap period will be invalid and subject to penalty. If the number of slaps the server receives is equal to the number of players and there are no duplicate message numbers, the server can process the slap immediately. However, the arrival of one or more slaps could be delayed. Therefore, an interval of time (beginning at the end of the valid slap period) during which the server can process the slaps must be determined. At the end of that time, the winning slapper (assuming a valid slap) will be determined and the server can process the slap. If the slap is invalid, the slapping player forfeits a card to the player who flipped the card. The server will mark the top card of the player s pile for removal and update the top of the pile. Therefore, on slaps, the cards held by a player changes. The server will be allocating and deallocating memory to accommodate and track these changes. After a slap, the server will also update the current status of each player and make any changes necessary (win, eliminated, no cards left). When the server has finished processing the slap, the OK to flip next card signal will be sent as in player flips card outlined above. player quits If a player quits while a game is in progress, the server will redistribute his/her cards to the remaining players. While this is occurring, the game is suspended while the server handles the change in the state of the game. If the cards are not evenly distributable, the last player to receive a card will be noted. If another player quits, start redistribution at player to the right/left (to be determined) of the player who received the last card on the previous quit. A player should not be allowed to flip a card until all the cards have been redistributed. The quitting player s

6 5 cards will be removed from his/her stack and the player will then be disconnected from the server. All remaining players will be notified of the change and will receive the OK to flip signal as in player flips card previously described. The stack of the player who quit will contain an empty, non-playing card. player runs out of cards A player is considered to have run out of cards only if flipping a card results in an empty card pile. This will be detected by the server when that player s last card has been flipped. The server will notify all remaining players by displaying the empty card pile as a non-playing card that has a circle on it. If a player runs out of cards during a game, he/she remains eligible to slap. The player continues to play without flipping until the next jack is played. If he/she wins the slap then he/she is still in the game. Otherwise, the player is eliminated. The player s status after the slap is determined by the server. (See player slaps) player eliminated If eliminated, the server will inform the remaining players by sending the player xxx has been eliminated signal to all players. The eliminated player s pile will contain a non-playing card that has an X. While the server is processing this change, players will not be allowed to flip cards. Once the server has completed this update, the OK to flip card signal will be sent as outlined in the player flips card section outlined above. An eliminated player has the option of remaining at the table (for next game) or leaving table (can join another game). This option is set at the beginning of the game. player wins A player may win a game only after executing a valid, winning slap that results in the acquisition of all remaining cards. This will be determined by the server as an update following a slap. The server change the display of all non-winning players to indicate they have been eliminated and will announce the winner to all players. The winning player s score will be updated accordingly. The score is also maintained by the server.

7 6 The players will then be given the option to start a new game. When all players have entered their choice, a new game will start provided there are at least two players to play the game. If a new game is started, the server will deal, simulating a change in dealer. If there is only one player to play the new game, the player can choose to quit or wait for additional players. IV. TACTICAL PLAN As Slap Jack is generally played with three to eight players, the first task to be accomplished is setting up the communication between the server and clients. Once the communication exists, procedures for playing and managing the game will be written and tested. The order of development will follow the sequence of events that occur during a game of Slap Jack. Logging players on, starting a game, and shuffling and dealing the cards must occur before the game may be played. Then the cards are flipped, and valid and invalid slaps are handled. Before dealing with the synchronous issues, the game will be developed as if all communication was asynchronous in nature, while keeping the synchronous issues in mind. This will allow us to develop the basic game algorithm and test it before dealing with the more complicated issue of synchronous communication. Procedures will be modified as needed to accommodate the necessary synchronization. Since the game can be played without a GUI, a basic GUI will be developed with the final GUI being developed along the way and tested with completed components of the game. V. REFERENCES The rules for Slap Jack may be found at Searches using and revealed no existing distributed versions of Slap Jack.