If a player chooses to quit, the program should close. If the player chooses to load a game, the program

should prompt for a filename. After loading the game, play will continue from where it left off. The

format for saving and loading games will be provided in the subsequent assignment. If the player chooses

to start a new game, the program will ask for the names of two players, and the game will begin.

Please note that some squares on the board may be unplayable, and this rule is not part of the stan$-$

dard Othello game. However, the unplayable squares will remain the same in every game in the final

implementation. will select one by entering a number corresponding to the desired choice:

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

A non$-$standard, offset starting position.

A non$-$standard, offset starting position.

A non$-$standard, offset starting position.

A non$-$standard, offset starting position.

Four$-$by$-$Four Starting Position

Figure $3$: A non$-$standard, but still centered Othello starting position.

Regardless of whether the game is started from a new game or loaded from an existing game, the current

player will have the following options:

A player may choose to save, concede or make a move

At the end of the game, the Board should record the outcome of the game, including the identity of the

losing or whether the game ended in a tie. An appropriate message should be displayed.

Please create a UML class diagram that includes the classes Game, Board, Position, Piece, and Player.

A Game should have a Board and Players. The Position class should be a parent class of Unplayable$-$

Position. Position should have a virtual method canPlay$()$:boolean, with the return value being true for

playable positions that are empty. Polymorphism must $($and should$)$ be used. There is some flexibility in the design approach, but the play$()$ method should loop, and the Board class

should store its pieces internally. The design should include methods to save the game, a static method

to load the game, a makeMove method to make a move, and methods to determine if a move converts

any pieces. Additionally, a method to check if there are any valid moves left is also necessary. Consider

the game rules and problem when including any additional methods, being mindful of which methods

should be public or private.

The classes should have constructors to provide an overview of the life$-$cycle of the elements of the game

or their construction.

UML Notes

Make use of UML Notes! It is acceptable to indicate in a UML Note that accessor$/$mutator methods

are not shown or can be interpreted based on fields. Use UML Notes to clarify important decisions and

provide additional information that is not well$-$communicated through the diagram itself. Generally, if

a note would be helpful for someone trying to implement the game based on the design, it is probably

a good note. The note should not describe implementation details but should instead explain how the

elements in the diagram fit together clearly.

Breaking up Diagrams

In some cases, a UML diagram may become too complex or difficult to understand in its entirety. In

these situations, it may be helpful to break the diagram into smaller, more manageable diagrams. This

can make the information easier to understand and give a clearer picture of the relationships between

the classes and their interactions.

When breaking down a UML diagram, it's important to keep the relationships between classes consistent

in each of the smaller diagrams. For example, if two classes have a relationship in one diagram, they

must have the same relationship in another diagram, even if they are only represented as stubs.

Breaking down a UML diagram can also make it easier to focus on specific aspects of the design and

make it easier to identify any potential issues. However, it's important to balance the need for detail

and simplicity, as too many smaller diagrams may become confusing and difficult to understand as well.