G51PGP: Software Paradigms. Object Oriented Coursework 4

Transcription

1 G51PGP: Software Paradigms Object Oriented Coursework 4 You must complete this coursework on your own, rather than working with anybody else. To complete the coursework you must create a working two-player version of a Reversi game ( along with class and object diagrams to explain your chosen design. This coursework is harder than the others that you have had so far, and I will not spell out the steps to achieve what you need to do in the same detail. You have a lot longer to do it, and will use a lot of the knowledge that you have gained from the other courseworks. You must complete this coursework on your own rather than working with anybody else. This coursework is worth 7.5% of the module mark. The first three OO courseworks were together worth 5% of the module mark, making 12.5% total. The FP courseworks also added up to 12.5%. You should try to complete this coursework in your own time and use the labs as an opportunity to get questions answered. The lab helpers can help you to understand concepts but will not help you to actually complete the coursework itself. Be aware that this coursework deliberately gives you less of a walk-through than the previous courseworks, and involves applying what you have done so far in a new situation.

2 Coursework requirements: Consider the program requirements in this document: Produce a Java program for a Reversi game which meets the program requirements specified in this document. Identify and use appropriate classes in your program. Use interfaces and sub-classing appropriately in your program. Use anonymous inner classes if/where appropriate to do so. Use standard Swing classes, any other standard class library classes, any classes that I have given you already, and your own classes (which may be subclasses of Swing classes), where appropriate. Draw a class diagram to represent your solution, including your own classes, any immediate superclasses for your classes. Include aggregation and inheritance relationships where they exist. Include all attributes and operations. You can draw this by hand or using any software package that you wish to use. It must be clear and unambiguous. Draw an object diagram, showing all of the objects that you create and the relationships between them. You do not need to show attributes and operations. You can draw this by hand or using any software package that you wish to use. It must be clear and unambiguous. In summary: your finished program should look like the display below, should allow players to place pieces when it is their turn, should automatically change the colour of pieces which are taken, and should detect when a player wins: Please also see the start of lecture OO-11 for a demo of a running version of this program.

3 Program requirements: 1. You must have two frames which display the board, with a label at the top and a button at the bottom, as shown above. You need to display the board on each, where one shows the board upside down from the other (actually a 180 degree rotation, see example below). Think of each as representing a player and the players sitting at opposite ends of the table, so that they see the board upside down compared with the other player. 2. Create a class to draw and handle a square on the board. Consider what I did previously in ColorLabel and ColorButton and do something appropriate for the board square. 3. You need to maintain a board state, which should represent an 8x8 grid of squares, as shown above. Each square can contain a white piece, a black piece or be empty. You should put four initial pieces in the centre as show above. 4. When a piece is played, any pieces between it and another piece of colour in a straight line up to the first piece of your colour in that direction are captured. One way to do this for every time a piece is played, search vertically, horizontally and diagonally (8 directions in total): If you find an empty square or the edge of the board then stop no pieces can be captured in that direction. If you find a piece of the opposing colour then continue in that direction. If you find a piece of your own colour then stop and capture all of the pieces of the opposing colour between it and the piece you just played. 5. Players take it in turns to play. The active player should be obvious to the player(s) and should be indicated in the label along the top of the screen, as shown in the earlier pictures (where it was white s turn) and below (where it is black s turn). A potential position after the first move by white

4 6. A player can only play a piece if it is their turn and playing the piece will capture at least one piece owned by the other player. There are only four initial places for white to play, which will be horizontally or vertically next to a black piece, as illustrated above. The black player can then play in a choice of three places. After that things get more complex. 7. White should play first. A potential position after the first move by black (after the move by white) A game in progress

5 8. Include a simple greedy AI, so that when a player presses the AI button and it is their turn the computer takes their turn for them. When the player presses the button, the program should check each space, calculate how many pieces will be taken if a piece is placed in that space and choose one of the space which take the most pieces. Note: If there are multiple places which take the same pieces then I don t mind which you choose I chose randomly but you can choose the first or last such position if you wish. This is called a greedy algorithm because it always makes the best move it can think of at the time without thinking about later consequences. The end of the game 9. When neither player can play a piece then the game ends (this will usually be when the board is full). At this point the player(s) should be presented with a message telling them then who won (who had the most pieces) and how many pieces of each colour there were at the time the game ended. Final message

6 Submission: It is intended that this coursework will be marked in the labs and that nothing will be submitted. When you have completed your coursework, please ask one of the markers to mark it. They will ask you to demo it and ask you various questions to understand how you did things and to test your understanding of what you did. They will then give you a mark. You will receive immediate verbal feedback so will know what mark you got and why. Marking criteria (total 30 marks): The mark breakdown is shown below, since I am aware that sometimes students use this to strategically decide what to do if time becomes short: 10 marks: Class diagram and object diagram are correct and model/design used for this program is appropriate. Appropriate classes were used. Diagrams are correct. Relationships between objects are appropriate and shown correctly in the diagrams. 8 marks: Board appears correctly: in two frames, showing pieces correctly, initial pieces are placed, labels show current player, board state is displayed, one board is upside down from the other, everything updates correctly. The class for the board square is appropriate and works correctly. At the end the number of pieces is correctly calculated and the winner is announced appropriately. 4 marks: Board state is maintained and updated correctly, counts of pieces taken are accurate, pieces are actually captured correctly. 4 marks: Game logic works correctly, passing control between players appropriately, allowing correct player to play, players can only play in valid locations, play alternates between players, play moves to other player when player cannot play a piece, etc. 4 marks: AI works correctly, correctly working out how many pieces will be taken if playing in each location, and choosing one of the best greedy moves when button is pressed.

7 Hints: Counting the pieces taken: If you create a function which counts how many pieces will be taken if you play in a location, you will find that you can use this function in multiple places. If the value is 0 for all directions then you can t play there. If you call the function mentioned above for every square you can work out whether a player can play at all. You can also work out what the best greedy move is (i.e. the one which takes the most pieces). Checking in multiple directions: If you want to check multiple directions, you could use a loop of offsets and recursion. E.g. continuously adding -1x,-1y to a position moves diagonally, whereas adding 0x,1y to a position moves vertically. I used two loops: e.g. for (xoffset=-1; xoffset<=1;xoffset++) and similarly for y, and skipped the case for 0,0. Using this offset I checked all 8 directions without me having to hardcode multiple directions. (If this doesn t make sense to you then just hardcode the directions, but it is not as quick to code it that way, so you ll need to write more code.) You can use iteration to keep moving to the edge, but I found that recursion gave me an easier function to create in this case. You may find iteration easier until you fully understand recursion though the comments from the FP lectures about different cases also apply to recursive functions in Java. How do I display a message? The JOptionPane class has a static function (the equivalent of a global function in C) which will display a message box for you if you wish. Just create the string to display and pass it to the function. E.g.: String st = "My message"; JOptionPane.showMessageDialog(null,st); Where to start? You can choose your own starting point, either starting from the diagrams and working to the code, or doing both in combination. If you are really stuck for a starting point then I suggest starting with the user interface, since the concepts are very similar to those that you have already used in the earlier courseworks. This will allow you to make some progress. I also suggest considering an MVC approach (see Lecture 11) if it seems appropriate. Next decide how to store your data, how you will work out which pieces are taken (or could be taken) and how you will ensure that changes made to one frame are seen in the other. I tend to think about what data I need to maintain as well (i.e. what member variables do you need in each object), and what each object needs to do. Thinking about the collaborations and responsibilities of objects may help you. Think also about how you will record whose turn it is as well, and how you will ensure that a player can only play a piece on their own turn.