40169981 A1-Designing Othello 2022
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
A1-Designing Othello
2022
Introduction
This assignment is worth 5% of your grade. This is an individual assignment (so individual, I put your student ID on it) and you should not share your assignment with anyone else. The assignment is
due July 12th at Midnight, Montreal time.
All submissions must go through EAS: https://fis.encs.concordia.ca/eas/
After you submit, go back to check EAS to confirm that you just uploaded your assignment!
Q1) Designing Othello
Your assignment is to create design diagrams for a variant of the game Othello: https://www.worldothello.org/about/about-othello/othello-rules/official-rules/english
This assignment describes an overall problem, but the assignment’s goal is only to include information that makes sense to put into a UML Class Diagram to help in a later implementation assignment. The correctness of diagrams and their completeness are significant considerations for evaluation in this assignment. Clear diagrams and the inclusion of concise supplemental information to communicate design intentions will also count. There is no implementation submission for this assignment. The next assignment will provide a design to implement. However, the design provided and the problem may differ from the result of this assignment (someone else may get it!). Focus on the design described, not the planned implementation.
In this variant of Othello, some positions on the board will be unplayable. The starting position may vary, and the rules for flipping pieces may be adjusted.
The program should draw the board using ASCII characters on the screen. Positional labelling along the top and side will allow the input of movement coordinates via keyboard. Messages detailing the result of moves and instructions for how the current player may take their turn will be output by the program at the start of every turn. This assignment description shows traditional Othello disks, but the actual implementation would show ASCII characters.
When a game starts a menu will be shown, with numeric options given:
1. Quit
2. Load a Game
3. Start a New Game
If a user chooses to quit, the program should close. Suppose the user Chooses to load a game. In that case, the program should ask for a filename. After loading the game, the program would continue from where it left off. The next assignment will show the File format for saving/loading. If the user chooses to start a new game, two player names are requested, and a game will start.
When laying out the board before starting, note that some squares are unplayable. This rule does not come from standard Othello, but keep in mind that such unplayable squares will be the same for every game in the final implementation.
When starting a new game, the user will be offered different starting positions. They will enter a number corresponding to one of these choices:
1. An offset starting position, the user will be subsequently asked to choose a number between 1 and
4 to indicate one of the following options
1) A non-standard, offset starting position. 2) A non-standard, offset starting position.
3) A non-standard, offset starting position. 4) A non-standard, offset starting position.
2. Standard Starting Positions
Figure 3: The standard Othello starting position.
Whether through starting a new game or loading an existing game, the current player will be given options to play:
The options for the current player are as follows:
• A player may choose to save, concede or make a move
When a game is over, the Board should explicitly record (in variables) the the number of each player’s pieces played at the time the game ended and whether the game ended through forfeit. An appropriate message should be displayed.
Create a UML class diagram that includes Game, Board, Position, Piece and Player. A Game should have a Board and Players. The Position class should be a parent class of PlayablePosition. Position should have a virtual method canPlay():boolean, with the return value being true for playable positions that are empty, with the initial implementation in Position returning false as it represents an Unplayable Position. Polymorphism must (and should) be used.
There is some latitude on how one could approach the design, but one would want a play() method that loops and Board will want to store its pieces internally. Based on where the program stores information in the resulting design, a save method should exist, as should a static load method. A makeMove method and methods to determine whether a move converts any pieces will be needed. A method to check if there are any valid moves left will be needed. Think about the game problem and rules and include any additional methods, mindful of what should be public and private.
Classes should showcConstructors to communicate, at a high level, how the life-cycle of the elements of the game (or their construction) will work.
Use UML Notes! It is ok to indicate via UML Note that access/mutator methods are not shown/can be interpreted based on fields. Use UML Notes to provide clarifications on salient decisions. Generally, if a note would be helpful for someone trying to implement based on this design, then it is probably a good note. A note should not describe implementation details. A note should explain how things in the diagram fit together clearly, filling in details that are not well-communicated through simple box-line diagrams.
A UML diagram may be split into simpler diagrams, identifying stub classes via UML note indicating a detailed version elsewhere. Splitting up a UML diagram can make a complex diagram easier to read. Suppose two classes have a relation in one diagram. In that case, they must have the same relation in another diagram, even if they are stubs.
Note that the next assignment will be an implementation assignment based on a diagram that meets the requirements of a variant on this assignment. However, it may not correspond to this assignment (it will likely be the solution for someone else’s assignment).
2022-07-12