Game Data Design (Statistics and Settings)

[metaloph1l]

Design should contain model for statistics that are saved throughout several games, and specific (client-side) settings (e.g. resolution)

[lanoxx]

We should create a package named domain with the following domain objects (Classes):

• Player (name, points, piece)
• Piece (color, currentSquare, currentDirection {left, right, up, down})
• Square (wallType {wall-left, wall-top, wall-right, wall-bottom}, points, player)
• Game (players {list}, squares {list}

For the client settings (e.g. Resolution) I think we dont actually need a separate class, we can just save it in a properties file and read it during program startup.

[metaloph1l]

Imho it is not that simple. There is a little bit of a mixup between this issue and issue #1. I've already taken issue #1 and put some work in it.

Issue #1 contains the labyrinth itself (or playing field, whatever you prefer) and the pacmans. What I did already try to work out of the exercise description is the following:

• There are several pacmans with a distinct color (e.g. green, blue, red) -> class Pacman with either 3 subclasses or type variable (=enum) -> Issue #1
• A labyrinth is made up by certain elements -> class Labyrinth with Map<Coordinate,Element> -> Issue #1
• Element can either be a wall or a square. A pacman cannot move into a Wall (movable() == false). However, a pacman can move onto a Square (movable() == true). Additionally, a square has points in it. Therefore, methods for reset, hasPoints/takePoints are needed in the model. -> Issue #1
• If a pacman steps on a square, it eats the points on the square and the points are gone until the square is reset -> Issue #1

This issue:

• Each player has some specific statistics assigned to it. There are both the current game statistics and the statistics, that are safed throughout multiple games. Therefore we need a map Map<Player, Statistics> currentGameStatistics, obviously inside the current game, and another Map<Player, Statistics> globalStatistics outside of the current game.
• The active game has 3 players. Either use List<Player> or .entrySet()-method of next point.
• Each of the players in the active game has his current pacman and coordinates assigned to it. This can easily be achived by a PacmanWrapper class. The game would then have a Map<Player,PacmanWrapper> assigned -> This is very important because we need to switch between distinct states in the game. Otherwise we could have a inconsistent state where we have two players with the same color that meet each other. (State Pattern could be used here)
  • In this case switching could be realized by instantiating 3 new PacmanWrapper instances and create a new Map<Player,PacmanWrapper>. The distinct switch can then be made by the simple command: assigned = newMapping;
• Also the game has an instance of labyrinth which is the current playing field.
• I dont think we have any server-side settings. I guess we can just use the Settings class for all the settings the client has and instantiate it in the Client executable class.

[lanoxx]

Did you see the UML stuff I have uploaded to git? I used a little different terminology but it is still similar. Board would be Labyrinth and Piece would be Pacman

[metaloph1l]

Yeah, I just noticed it now and did have a slight look at it. Great job you did there. Other than the terminology it seems quite similar.

However I have noticed two things:

• Do we really need a link from the player to the board in the domain model? Imo it should suffice if the game has both a reference to all the players and the game state (tiles + colors of the players pacmans == Map<Player, PacmanWrapper)
• I don't think we should have link from player to piece/pacman and from piece/pacman to tile/square, because that can be quite tricky to update, especially when we want to have consistent state transitions. Again, I would rather suggest the usage of a map in the Game object (Map<Player, PacmanWrapper). I'm not sure how to map a Java Map in an uml diagram. If that is what you meant I agree with you.

[lanoxx]

I have uploaded a communication diagram outlining the design of player and square. I think the connection between player and board is useful to get the next square based on the current square and the direction, since the board is the expert for that. I have explained that in more detail in the UML.

[lanoxx]

As this issue is actually about settings and statistics, so I have updated the issue title. See Issue #1 for Domain Model discussion.