Assignment 2: Reflection
GUI Discussion
- In the GUI class
- The main JFrame of the GUI is initialised in the initialise method. Within this method the entire frame is composed. This is including a JPanel for the board, player cards (hand) and the dice. There is also a JSeparatorPane which splits the board from the other components.Also, there are several JButtons which roll the dice and end a player’s turn. We used JRadioButtons which would allow for the user to suggest or accuse. These JRadioButtons are grouped using a ButtonGroup. The JRadioButtons opens new JFrames which allow the users to input their suggestions or accusations into JTextFields. JButtons then dispose of these JFrames. At the top of the main JFrame, there is a JMenuBar consisting of JMenuBarItems. There are two components in this, the file and game tabs. In file the JMenuItems run the Junit tests and in the Game JMenuItem a player can start a new game (this opens up a new JFrame and calls the initGame method). Many JLabels are used throughout this class. JOptionPanes are used to show Dialogs when a player loses after a false acussation or if they win the game.
- A KeyListener is used for the move method when trying to move a player. This was added to the main JFrame. In the inherited KeyReleased method, every time “wasd” is pressed the move method is called.
- In all the JPanels, a paintComponent method is called using an anonymous class. This overrides the superclass. The appropriate methods are called. In the gamePanel, the redraw(g) method is called to draw the board and players. In the handPanel the drawHand(g) method is called. For the dice panels the drawDie methods are called, the corresponding ones for each panel. A separate redraw method gets called after these methods where it repaints the frame.
- The suggest and accuse methods both open new JFrames that have JTextFields for the user to input their answers. The JTextFields then have getter methods for them so that they can be got from the Main class. These variables and getter methods are static.
- In Main class
- The differences from Assignment 1 involve extending the GUI class. Which then gets the inherited methods. Some methods which were initially made in the main class for assignment one are called/made from the GUI. We made initGame, move, hasWinner, rollDice, endTurn, checkAccustion and all the drawing methods protected abstract methods in GUI. A notable difference is that we no longer use the playGame method, but this method is broken down into smaller methods, i.e. endTurn, move and hasWinner. This made it easier to implement the game logic into the GUI, e.g. the player whose turn it is can be incremented accordingly in the endTurn method, which is called by the button in the GUI.
- In terms of drawing the components, we used for each loops are used and each object gets drawn using its draw methods. These draw methods are also different from assignment 1.
Design Discussion
- The original code was done very well and provided a useful framework in order to design assignment 2. The objects were organised into appropriate classes and use hierarchy very well. This was important, especially when designing the cards. One draw method was added to the cards and using the instanceof method we could avoid class casting exceptions when drawing the cards. In the board and location classes a draw method was added for the board and also to draw the doors/rooms/hallways.
- We needed to change where our methods in the Main class were originally called. This is because the methods needed to be accessible to the GUI components. The GUI was also in a separate package from the main. This meant we need to make the methods protected and abstract the code for the methods needed to be written in the Main.
- The only thing that needs drastic change was our playGame method. This because the GUI would freeze as it would be in an endless game loop. This meant the logic needed to be done in a different way. The playGame method was broken down into smaller methods, which were also protected abstract method made in the GUI class, and this is how we avoided the loop issue. The game logic was now implemented using Buttons and other swing components in the GUI class. The game loop was now incremented using static fields which could also be accessed by the GUI when we needed to made restrictions to various components.
State Diagram Discussion
- Once the number of players is inputted, it transitions to the players turn state. The transition is to roll dice to the check how many moves left state. From here it takes a user input of wasd; if the input is not wasd, it will not accept it. This is a transition. The state it moves into moves player position and transition back into the previous state of check how many moves left and -1 from moves left in the transition.
- If no moves are left, then it can go to two different states check input via suggest or check input via accuse.
- If the transition is through suggest into check input state, there are two transitions. One then ends turn into the rotate to next player state. The other is the accuse transition which goes into the check input state.
- If the transition is through accuse into check input state, there are two transitions. One is into the player wins state. The second is the player loses and gets removed, which is the transition into the rotate to next player state.
- From the rotate to next player state, that state transitions back to the starting player turn state.