droverbuild / chessgame Goto Github PK

To the EndOfGameData class, add ArrayList<Player> waitingRoom as a private data field. You will need to get the playerManager.getWaitingRoom() players and add it to every EndOfGameData object prepared.

This class is the implementation of the AbstractClient class. Handles all incoming/outgoing data.

You will need these receive methods:

• receiveAvailableMoves(AvailableMovesData data): This is received after we've sent a piece selection, after the server determines the available moves, and once the server sends that list of locations back. When this happens, show each location on the board.
• receiveNextTurn(NextTurnData data): This is received when either player makes a move, and the other player's turn begins. In this method we need to check if the current turn is the current user. If so, notify the user and allow them to select a piece. Otherwise, just update the board.
• receiveEndOfGame(EndOfGameData data): This is received when either player makes a move ending the game, or if one player abandons the game. Transition player to the waiting room when this is received.

And these send methods:

• sendPieceSelection(PIeceSelectionData data): Send whenever it's the player's turn, and they have clicked on one of their pieces that they wish to move.
• sendPieceMove(PieceMoveData data): Send after the player has clicked on an available move.

This class will need to do all of these:

• Keep track of all logged in players
• Keep track of players in the waiting room, when players leave, and when they come in
• Handle when clients connect, communicate with the Database class to authenticate, create new user, etc.
• Calculate and update players' xp, wins, and losses as a game ends

This is the main class. Extension of JFrame. Loads controllers for all three screens, and transitions between screens.

• Refactor Game to server.gamelogic package.
• Create GameData with appropriate private data fields that the client might need—including board.
• Introduce .data() method that copies needed private data fields to new GameData.
• Refactor all other data classes to send GameData instead of Game

These receive methods:

• receiveWaitingRoom(WaitingRoomData data): This will be called whenever an update to the waiting room needs to be made: A player joins the waiting room, leaves, etc. Contains complete list of players and their statistical data.
• receivePlayerChallenge(PlayerChallengeData data): Called whenever another player has challenged this player.
• receivePlayerChallengeResponse(PlayerChallengeResponse data): Called whenever the other player has declined this player's challenge.
• receiveStartOfGame(StartOfGameData data): Called after either player accepts a challenge. When this is received, transition into the game view.

These send methods

• sendPlayerChallenge(PlayerChallengeData data): Send whenever the player selects another player and challenges them.
• sendPlayerChallengeResponse(PlayerChallengeResponse data): Send whenever the player responds to another player's challenge.

This class contains the methods to send and receive data regarding the login and creation of accounts (See UML). It'll talk to PlayerManager, which in turn will talk to the Database class.

Think about these communication classes as doing these four tasks really well:

• Receive a request
• Delegate a different class to process this request
• Prepare the results of that class's operations
• Send back a response to the client with given data

You can see this in the already implemented GameCommunication, in methods such as receivePieceMove(), where a move is received from the client, GameCommunication sends that move data to that game, which makes the move. After that GameCommunication takes the game, and decides to prepare either a NextTurnData or EndOfGameData depending on the state of the game, then sends that data to both players.

You will probably want a private data field for PlayerManager in order to call PlayerManager methods from this class.

Upon startup, the client will attempt to establish a connection with the server. Of course, the server accepting the connection has already been implemented in OCSF, so we don't need to do anything extra here. The important thing is to listen for one of two types of data:

PlayerLoginData, upon which ServerCommunication will call receivePlayerLogin(), which should call playerManager.clientLoggedIn(). This method will return true if it was successful. In this case, move the player to the waiting room using playerManager.movePlayerToWaitingRoom(), then call waitingRoomCommunication.sendWaitingRoomToAll(), which will refresh the players in the waiting room all at once. If the login is not successful (meaning it returned false), call sendLoginUnsuccessful().

CreateAccountData, upon which ServerCommunication will call receiveCreateAccount(), which calls playerManager.accountCreated(), which, similar to above, will return true if successful. In this case, we will want to call sendCreateAccountSuccessful(). This is new; we neglected to add it to the UML diagram, so we will need to create a new class CreateAccountSuccessfulData. If the creation of the account is unsuccessful, call sendCreateAccountUnsuccessful().

In sendLoginUnsuccessful(), create a new ErrorData object with the message "Invalid username or password" and send it to the client.

In sendCreateAccountUnsuccessful(), create a new ErrorData object with the message "Username already in use" and send it to the client.

This is the implementation of the AbstractServer. This class will listen for incoming data, and call the listen functions in either the PlayerLoginCommunication class, the WaitingRoomCommunication class, or GameCommunication class, depending on the class of the received data (See UML diagram).

This class will handle all incoming and outgoing data regarding the waiting room (See UML diagram). It'll talk to the PlayerManager, as it is keeping track of the waiting room and challenges.

Think about these communication classes as doing these four tasks really well:

• Receive a request
• Delegate a different class to process this request
• Prepare the results of that class's operations
• Send back a response to the client with given data

You can see this in the already implemented GameCommunication, in methods such as receivePieceMove(), where a move is received from the client, GameCommunication sends that move data to that game, which makes the move. After that GameCommunication takes the game, and decides to prepare either a NextTurnData or EndOfGameData depending on the state of the game, then sends that data to both players.

Methods in WaitingRoomCommunication

• receivePlayerChallenge(): Called when PlayerChallengeData is received. This method will call playerManager.playerChallenged(), then call sendPlayerChallenge().
• receivePlayerChallengeResponse(): Called when a player has responded to a challenge and a PlayerChallengeResponseData object is received. This method will call playerManager.playerResponded(). Then, if the player declined the challenge, call sendPlayerChallengeResponse() to the .from player. This class will not be responsible for starting the new game. That is up to PlayerManager.
• sendWaitingRoomToAll(): Sends waiting room data to all players in the given list. Called when a user successfully logs in, joins a game, or leaves a game after it ends or by abandoning the game. If a player joins the waiting room, tell everyone. If a player leaves the waiting room, tell everyone else still in the waiting room. This is meant to update the waiting room for all players in the waiting room.
• sendPlayerChallenge(): Sends a message to the player linked to in PlayerChallengeData.to. Called whenever PlayerChallengeData.from challenges the player.
• sendPlayerChallengeResponse(): Updates the player linked to in PlayerChallengeResponseData.from that .to player has denied the request. Only called if the .to player has denied the request (if .to accepted, a new game would have been started by PlayerManager, so there is no need to do anything.

Note changes from the UML

• Added sendPlayerChallengeResponse(): because initially I did not consider the case of a challenge being denied
• receivePlayerAcceptChallenge() changed to receivePlayerChallengeResponse() because again, I only thought accepting a challenge would be necessary.
• Removed sendWaitingRoom() removed because I don't see any cases where a single player would need to update their waiting room.

• AbandonGameData will need to have two private data fields: and integer for game id, and a player for the player who abandoned the game.
• When receiving an AbandonGameData object, the server will call the game's playerAbandonedGame() method, passing in data.getPlayer() as the player parameter.
• Call sendEndOfGame(game).

• receiveError(ErrorData data): Received when creating an account is unsuccessful. Show an error message above the form if this happens.
• receiveCreateAccountSuccessful(CreateAccountSuccessfulData data): Called after user has created an account and it is successful. Move back to log in screen with message saying the create new account was successful.
• sendCreateAccount(CreateAccountData data): Send when user clicks "create account"

These receive methods:

• receiveError(ErrorData data): Received when either logging in is unsuccessful. Show an error message above the form if this happens.
• receiveWaitingRoom(WaitingRoomData data): Called whenever login is successful. Transition to waiting room screen with this data if received.

These send methods:

• sendPlayerLogin(PlayerLoginData data): Send when user clicks "log in"