even methods and fields. If you do so, these changes should be documented in updated UML diagrams. 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. Start a New Game 2. Load a Game 3. Quit When the user chooses to start a new game, two player names should be requested before starting a new game with those two players as first and second player, respectively. Should the user choose to load a game, the program should ask for a filename, load the game saved in that file, then continue from where that game left off. If a user chooses to quit, the program should close. When laying out the board before starting, note that the two center squares along the bottom row will be unplayable. This rule does not come from standard Othello, but keep in mind that such unplayable squares will be the same for every game, irrespective of starting position. When starting a new game, the user will be offered different starting positions. They will enter a number corresponding to one of these choices: Page 1 A2-Implementing Othello ID: 40212567 1. Four-by-Four Starting Position Figure 1: A non-standard, but still centered Othello starting position. 2. Standard Starting Positions Figure 2: 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: • If the current player cannot move, they may choose to save, concede the game or, if they cannot make a play to take an opponent’s pieces they may forfeit their turn • A player may choose to save, concede or make a move Games should be saved as a text file, with first, second and current player names on the first three lines, then all the characters in the board state on the last line. When a game is over, an appropriate message should be displayed indicating the current board state, who won. As per the diagrams, implement the classes Game, Board, Position and Player. A Game object should have a Board object and Players, but it’s not specified how the Board and Player classes are related to each other. The Position class should be abstract with two subclasses, PlayablePosition and UnplayablePosition, inheriting from it. The Position class should have a pure virtual method named ”canPlay()” that returns a boolean value indicating whether the position is playable or not. The return value should be ”true” for empty playable positions and ”false” for unplayable positions. The use of polymorphism is required and recommended in this design. There is some latitude on how one could approach the implementation, but one would want a play() method that loops. 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. Page 2 A2-Implementing Othello ID: 40212567 Classes should use Constructors that make clear how the life-cycle of the elements of the game (or their construction) will work. Consider the UML Notes when implenting, as there may be some guidance there. In particu