The final project for CS $2401$ is a single large project to be submitted in three stages counting as three projects. For this project we will be implementing the game Boop, with the final product being a program that can play an "intelligent" game of Boop against a human opponent.

This game must be derived from the files I have given you $($a game class written by the author of a textbook we used to use for this course$).$ The files are game.h and game.cc$.$ I have also included a file called colors.h which was created by a former student who has given us permission to use it$.$ It allows you to adjust the colors of the terminal screen during a text$-$based console or ssh session. I have altered the play function in the game class slightly by adding three different sections of code that you will need for each part of this project. Make sure that you are using the correct version of the play function for each part or the program will not work correctly.

The game class creates a map for us in how the project is developed, and at the end we will find that most of the $$AI$$ has already been written for us in this parent class. If you look at game.h$,$ you will see that there are virtual functions that must be overridden and some that may optionally be overridden. Eventually you will write a child version for all the mandatory overrides, but you probably do not need to override many of the optional ones.

The rules of this game are fully outlined in the Boop$\_$Rules.pdf document included with the assignment. Basically, the game consists of two players that each start with $8$kitten$$ pieces. You can upgrade $$kitten$$ pieces to $$cat$$ pieces with the goal of the game being to get three $$cat$$ pieces in a row $($horizontal$,$ vertical, or diagonal$).$ The catch is that whenever a piece is added to the board, other pieces may need to move. When placing a $$kitten$$ piece, any adjacent kitten pieces get $$booped$$ one space away from the newly placed piece if there is an empty spot in that direction. When placing a $$cat$$ piece, all adjacent cats and kittens get booped.

The first stage is the design stage. In this part you decide how you will represent the pieces and how you will display the board. Good grades are given for the quality of the design, the attractiveness of the board, and the ease of the user interface. Your project should be derived from the game class. You will create a child class called Boop, which needs to have a way of storing the board. The board should be a $6$x$6$ two$-$dimensional array of spaces where the spaces are another class which you must write $($I would suggest using a static const for the size of the board so that you can use it later when checking boundaries$).$ This board becomes the principle private member of the Boop class. The Boop class will also need counters for how many cat and kitten pieces each player has available to them. The spaces class should be able to store all the attributes that a space might have $$ emptiness, color$/$owner$,$ piece type, as well as mutator and accessor functions to transform a piece$/$space from one state to another. At any point, you can add any additional attributes or functions to the Boop class that you find to be useful.

You must design your own characters. I suggest using a single line character and a $3$ line character, but you can do whatever you like. You may not use the same characters from my example game. Your junior character $($the kitten equivalent$)$ needs to be distinctly different so that they are easy to tell apart when they are on the board together.

You should then implement your design to the stage where I can see the board displayed and be allowed to make one initial move.

The first step in doing this is to write your space class, which will be a standalone class $($not derived from anything$).$ You can choose to represent the state of the space in many ways, so this design decision is left up to you.

Then, when you write your Boop class, which will be derived from the game class, the best first step, after declaring your board, is to create stubs for all the game class$$s purely virtual functions. $($A stub is a function with an empty implementation, which exists merely to validate a call, or to allow the program to compile.$)$ For this stage you must write a real implementation for restart, display$\_$status and a very simplified make$\_$move, and is$\_$legal. These functions should do the following:

restart: set the initial piece counters to the correct number $(8$ junior pieces for each player and $0$ senior pieces for each player$),$ set the status of every space on the board to empty, and call the game::restart$()$ function to reset the move counter.

display$\_$status: show the current state of the board. You will need to use nested loops for this to walk through each row column by column and output some representation of what piece on on that space.

make$\_$move: set the status of the space at the row and column given by the move string to whatever type of piece and player