The program This project asks you to build a graphical user interface that implements the same Othello game as the previous project. As before, the user will begin by selecting a set of options that configure how the game will be played; the game will then be played by asking users to make moves in a graphical window, continuing untli the game is complete, at which point the game has ended and the window can be dismissed. Some details about the GUI-based version of Othello Your GUI-based version of Othello will begin by asking users to make the same choices as in the previous project. You have some leeway in how you design the part of the GUI that asks these questions, but the input will need to be provided in a reasonable, convenient way in the GUI, not via the console; the look and feel is up to you, but try to provide something that would be convenient for a user.
How many rows are on the board, an even integer between 4 and 16 inclusive
How many columns are on the board, an even integer between 4 and 16 inclusive, which does not have to be the same as the number of rows
Which player — black or white — will move first
The arrangement of the four discs in the center of the grid at the beginning of the game — black in the upper-left of the four cells with discs, or white?
Whether the game will be won by the player with more discs or fewer discs (one or the other, but not both)
Once the game begins, the GUI should display the current score (i.e., how many discs of each color are on the board), a clean representation of the game board as a grid with discs colored either black or white, and an indication of whose turn it is to move (black or white). The user is permitted to make a move by clicking one of the squares on the grid, though the move will only be allowed if it is valid; once a valid move is made, the board is updated to reflect the necessary changes (i.e., which discs are flipped, etc.). Your GUI will also need to prominently display which set of rules is in effect. (Recall from the previous project that you had your choice about either a full or simplified set of Othello rules; you have the same choice here.) To make things easier on us when we’re grading your project, you must either display the word FULL or the word SIMPLE somewhere in your GUI, so that we can easily see which rules are in effect. When the game is over, display three things in the GUI: the score, the final game board, and who the winner is. Be sure to handle the case where there is no winner (i.e., the number of discs on the board for both players is equal at the end of the game). At this point, you can simply wait for the user to dismiss the window, or you can optionally offer the user the choice to play another game.
Approaching the problem Reusing your game logic If you have a complete set of game logic from the previous project, you’ll find that your task this time is primary one of visualization and taking input. Your game logic, if designed appropriately before, should be usable without modification. In some ways, it may not (e.g., if your game logic makes assumptions about the presence of a console user interface instead of a graphical one), and in these areas lie learning opportunities. Reflect on what changes you had to make and why, and understand how you could have avoided making those changes. Note, too, that you can use either the full or simplified version of Othello from your previous project, and that you are eligible for up to full credit on this project either way — in other words, there is no penalty for the simplified rules this time. What to do if you didn’t complete your game logic previously If you did not complete either version of the game logic previously, you will need to complete it now, and I would suggest focusing your energy on the simplified version described in the previous project, since it will be a lot easier to implement than the full rules. Since implementing even the simplified rules leaves open the possibility of receiving full credit on this project (i.e., there are no deductions for not implementing more than this, and there are no bonuses for implementing everything), there’s no benefit — from a grade perspective — in implementing the full rules (though, of course, you’re welcome to do so, if you’d like). It should go without saying — but prior experience has shown otherwise — that you are required to submit your own game logic in this project, not someone else’s. It’s certainly true that the focus of this project is on building a graphical user interface, but one of the learning objectives here is becoming accustomed to reusing your own code to satisfy new requirements, so you can determine which parts of your own design worked well in the new context, which ones didn’t, and reflect on why. Module design As before, you are required to keep the code that implements the game logic entirely separate from the code that implements your GUI. To that end, you will be required to submit at least two modules: one that implements your game logic and another that implements your GUI. You’re welcome to break these two modules up further if you find it beneficial, but the requirement is to keep these two parts of your program — the logic and the user interface — separate. At least one of your modules should be executable (i.e., should contain an if __name__ == ‘__main__’: block), namely the one that you would execute if you wanted to launch your GUI and play your game. Using classes to implement your GUI Because your event handlers will need access to the game’s current state, your GUI should be implemented as one or more classes, in the style we’ve been discussing in recent lectures, with (at least) an object representing the application; you may also find it useful to have additional kinds of objects that represent parts of your GUI, but this is up to you to decide and is not a requirement. Drawing the game board and resizing the GUI’s root window You are not permitted to represent the game board using built-in widgets like buttons. Instead, you’ll need to draw it on a Canvas widget programmatically. Additionally, your GUI’s root window must support resizing, and resizing it must cause the area in which the board is drawn to change size correspondingly, with the game board redrawn to fill the available space, so the user can decide how large of a window he or she would like to play the game on.