From ae3891a62de50262bd3882447709a3c3585742d2 Mon Sep 17 00:00:00 2001 From: Daniele Parravicini Date: Thu, 5 Jul 2018 19:59:47 +0200 Subject: [PATCH 1/2] Update README.md Clarify some staments about multi game support --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 58744cf..c3e7461 100644 --- a/README.md +++ b/README.md @@ -125,9 +125,9 @@ Sun's Glory ``` ### Multi game support -When a player connects to the game, he will be connected to an already existing game waiting for players to start, if this exist, otherwise, a new game is created on the same server. While the games are on going, both of them are managed by the same server and other new games could be added meanwhile. To keep references to every game hosted, a Map exist, which saves both the reference of the GameController and its unique ID. When the game finishes, the game is removed from this Map, and players can connect again to a new game using the same nickname, since that does not exist anymore on the server. Since no registration and login are required to connect, when the game finishes, is possible for another person to join a game using a nickname used by one of the players who just finished, making it impossible to anyone else, also the person who just used it, to join using it. +When a player connects to the game, he will be connected to an already existing game waiting for players to start, if this exist, otherwise, a new game is created on the same server. While the games are on going, both of them are managed by the same server and other new games could be added meanwhile. To keep references to every game hosted, a Map exist, which saves both the reference of the GameController and a unique identifier. When the game finishes, the game is removed from this Map. Since no registration and login are required to connect, when the game finishes and has been removed, is possible for another person to join a game using a nickname used by one of the players who just finished, making it impossible to anyone else, also the person who just used it, to join using it. -Let's make an example to make it clear: let's suppose a player Alice is playing in a game with the nickname MyNameIsTheBest and that, while the game is on going, Bob tries to connect to a game using the same nickname. In this case, Bob is notified that the nickname already exists on the server and that he must choose another name. But, if the match played by Alice finishes and Bob tries to connect once again using the nickname MyNameIsTheBest, his connection will be accepted and he will connect to a game using that name. This means that, if Alice tries to play again with the same nickname, her connection will be refused and she will be notified that the nickname she has chosen already exists on the server. +Let's make an example to make it clear: let's suppose a player Alice is playing in a game with the nickname MyNameIsTheBest and that, while the game is on going, Bob tries to connect to a game using the same nickname. In this case, Bob is notified that the nickname already exists on the server and that he must choose another name. But, if the match played by Alice finishes and Bob tries immediately to connect once again using the nickname MyNameIsTheBest, his connection will be accepted and he will connect to a game using that name. This means that, if Alice tries to play again with the same nickname, her connection will be refused and she will be notified that the nickname she has chosen already exists on the server. Player connection and usage of the game ID will be explained better lately in the section [*Connection and Reconnection*](#Conn-Reconn). @@ -136,7 +136,7 @@ Player connection and usage of the game ID will be explained better lately in th ### ToolCards limitations -- All the ToolCards implying the player to move one or more dice have been implemented by taking the dice chosen by the player from its board and, one by one, in the same order the player chose them, he is asked to place them again. This implementation allow us to permit players to swap 2 dice in their board. However, it does not allow players to move dice in cascade: let's suppose a player placed only 2 dice. If he plays a toolcard to move both of them, he can't choose a die, place it near the other one and move the second one. The dice are taken at the same time and then placed one by one. If taking the 2 dice chosen leaves the board clear (no dice are left on the board) then the player must place the first die on the edge of the board, just as if it were its first die in the game. +- All the ToolCards implying the player to move one or more dice have been implemented by taking the dice chosen by the player from its board and, one by one, in the same order the player chose them, he is asked to place them again. This implementation allow players to swap 2 dice in their board. However, it does not allow players to move dice in cascade: let's suppose a player placed only 2 dice. If he plays a toolcard to move both of them, he can't choose a die, place it near the other one and move the second one. The dice are taken at the same time and then placed one by one. If taking the 2 dice chosen leaves the board clear (no dice are left on the board) then the player must place the first die on the edge of the board, just as if it were its first die in the game. The toolcards affected by this limitation are: - Lathekin - Tap Wheel @@ -164,9 +164,9 @@ Searching online we got in touch with DejaVuSansMono (https://github.com/powerli Here is an example of usage of UTF-8 and ANSI:
-- Since we needed to interrupt user's actions when its timer expires, we built a pre-emptive method to get input which makes use of a BufferedReader. This is useful because, thanks to a buffer, we can know when the user input is ready and we can read it only in that case, leaving the active thread free to listen and react to an interrupt. +- Since we needed to interrupt user's actions when its timer expires, we built a pre-emptive method to get input which makes use of a BufferedReader. This is useful because, thanks to a buffer, we can know when the user input is ready and we can read it only in that case, leaving the active thread free to react to an interrupt. - Due to that buffer, however, when the program is launched in some terminals (for example on Windows PowerShell), the user can't read its input until he press Return to confirm the input. We tested the program on both Windows and MacOS. While on Windows this problem exists, on MacOS terminal users can see their input while they are writing it. + Due to that buffer, however, when the program is launched in some terminals (e.g Windows PowerShell), the user can experience some trouble reading its input. However the string written appears immediately as he press Return to confirm the input. We tested the program on both Windows and MacOS. While on Windows this problem exists, on MacOS terminal users can see their input while they are writing it. 6. Design Choices --------------------------- From 6eb7dd7aa667bca0d184b99450ad271bf4f0d404 Mon Sep 17 00:00:00 2001 From: Daniele Parravicini Date: Thu, 5 Jul 2018 20:12:32 +0200 Subject: [PATCH 2/2] Update README.md simplification on controller --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index c3e7461..0e52c1c 100644 --- a/README.md +++ b/README.md @@ -176,11 +176,11 @@ Searching online we got in touch with DejaVuSansMono (https://github.com/powerli To let client and server communicate each other, we implemented, as requested, a MVC pattern, with some differences from the plain one. -On the client there is player's view, which contains a reference to the remote controller (if the client connected through RMI) or to a controller proxy (if the client connected through socket). If a player wants to perform any action which involves a change on the model, he must ask for it to the controller. Actually, the client has a copy of the model available, but, even if he is able to modify it using a custom client, the change won't affect the game, because it has effect only on the local copy of the player and the shared model (which is only on the server) is unchanged. +On the client there is player's view, which contains a reference to the remote controller (if the client connected through RMI) or to a controller proxy (if the client connected through socket). If a player wants to perform any action which involves a change on the model, he must ask for it to the controller. Actually, the client has a copy of the model available, but, even if he is able to modify it using a custom client, the change won't affect the game, because it has effect only on the local copy of the player. The shared model (which resides only on the server) remains unchanged. -The model is divided into more classes, to let every class represent a single object and to separate methods and attributes according to their context. A central class, called GameModel, is used to integrate every class of the model and let them interact each other. This class is also responsible for the game flow proceed: it sends events to every player connected to the match. In particular, every time the model state changes, it sends a ModelChangedEvent, to let players save an up-to-date copy of the model. +The model is divided into more classes, to let every class represent a single object and to separate methods and attributes according to their context. A central class, called GameModel, is used to integrate every class of the model and let them interact each other. This class is also responsible for the game flow management by sending events to connected player. In particular, every time the model state changes, it sends a ModelChangedEvent, to let players save an up-to-date copy of the model. -The controller is divided into 2 different entities: there is a GameController, which is responsible for checking that the action has been asked from the player who must play its turn and, before delegate the request to the Model, this controller checks if the timeout is already expired. In these cases the controller won't ask the model to perform any action and will return to the client an exception, explaining what happened. +The controller is divided into 2 different entities: there is a GameController, which is responsible of thread synchronization and checks the legitimacy of the requested action, for example discarding requests from players non-current player. Its duties include also timeout handling. After these checks it delegate the request to the Model. On the other hand if any of these validations fails the controller won't ask the model to perform any action and an exception will be returned to the client explaining what happened. The second part of the controller is called PlayerController. Each player is associated with its own PlayerController. This controller is used to avoid spoofing by other players: every request to the server is done by passing as a parameter also the name of the player itself. If a player A (using a custom client) tries to perform any action pretending to be player B, player A's PlayerController, who knows the name of the player associated, delegates the request to the GameController with the real name of the player. This way, if the player who asked for an action is not the current player, the GameController will return to him an Exception.