In this problem, you will use C++ classes to implement the game of Flood It, a one player
game. You can play a graphical version of the game at http://floodit.appspot.com/.
An instance of Flood It consists of an nxn-grid of cells, each of which can be in one of 5
2. (a) In this problem, you will use C++ classes to implement the game of Flood It, a one player
game. You can play a graphical version of the game at http://floodit.appspot.com/.
An instance of Flood It consists of an nxn-grid of cells, each of which can be in one of 5
states, 0, 1, 2, 3, or 4 (with the default state being 0). These states can be thought of as
colors with the mapping 0(White), 1(Black), 2(Red), 3(Green) and 4(Blue). Before the
game begins, we specify an initial conffguration of the state of cells. Once the cells are
conffgured, the player repeatedly changes the state of the top-left (0,0) cell. In response
all neighbouring cells (to the north, south, east, and west) switch state if they were in
the same state as a neighbouring cell which changed states. The object of the game is
to have all cells in the grid be in the same state before running out of moves.
To implement the game, you will use the following classes:
Cell - implements a single cell in the grid (see provided cell.h)
Game - contains the grid of cells and implements the game logic (see game.h)
View - abstract class to provide the interface for any display (see view.h)
TextDisplay - responsible for displaying the text version of the grid. TextDisplay
\is a" View (see textdisplay.h)
Controller - responsible for getting user input and communicates the input to the
Game. The controller also receives updates from Game and is responsible for com-
municating updates to the View accordingly (see controller.h and controller.cc)
A main.cc is also provided.
Your solution to this problem must employ the Model-View-Controller (MVC) pattern
for its implementation. MVC is a combination design pattern employing the Observer
pattern as part of its implementation. The basic idea behind MVC is to break the
application into three parts:
Model : The Model is the data, which in this case is the game state and consists of the
Cell and Game classes.
View : The View is the display, which in this case consists of the TextDisplay and
GraphicDisplay (see part b) classes.
Controller : The Controller receives user input and is responsible for mediating be-
tween the Model and View. The Model and View should not directly communicate,
which facilitates designing reusable Model and View classes. For this question,
we have provided you with an almost complete implementation of the
controller (see controller.h and controller.cc).
The Game contains a grid of Cells. Each Cell is an observer of its neighbours (that
means that class Cell is its own observer)1. Game can call Cell::notify on a given
Cell and ask it to change state. Note that because of the way the game is played, it only
makes sense for Game to call Cell::notify on the (0,0) cell with a single parameter,
the new state of the cell. The notiffed cell must then call a notify method on each of its
neighbours (each cell is told who its neighbours are when the grid is initialized). In this
notiffcation, you might ffnd it useful to send the Cell's current and previous states as
parameters. Each time a Cell changes state, it must notify Game of its new state.
The Model does not know about the View or Controller. However, other objects
can ask the Model to send them notiffcations when the Model is updated. In our
implementation, the Game class (part of the Model) sends notiffcations by using a
GameNotification object. Any object of type GameNotification, i.e. any object that
\is a" GameNotification, can register with a Game in order to be informed whenever a
Game's state is updated. Speciffcally, GameNotification is a simple abstract class that
provides a known interface for the Game object to send notiffcations. Every time the
state of a Cell is updated, it sends an update to the Game which sends an update to the
registered object. Note, we have provided you the GameNotification class.
For this question, the Controller should register with the Game to be the GameNotification
object. Hence, the Controller \is a" GameNotification. When the Game notiffes the
Controller of an update, the Controller will then communicate these updates to the
appropriate View (i.e., TextDisplay and/or GraphicDisplay).
The View class declares a pure virtual print method. Calling TextDisplay::print
prints the grid to the screen (see example below).
When you run your program, it will listen on stdin for commands. The program accepts
the following commands:
new n Creates a new n x n grid, where n nak 2. If there was already an active grid,
that grid is destroyed and replaced with the new one.
init Enters initialization mode. Subsequently, reads triples of integers r c s and
sets the cell at row r, column c to state s. The top-left corner is row 0, column 0.
The coordinates -1 -1 end initialization mode. It is possible to enter initialization
mode more than once, and even while the game is running. If the triple r c s refers
to invalid co-ordinates, the triple is ignored. When initialization mode ends, the
board should be displayed.
include f The ffle f is a list of cell initializations of the same format of initialization
from init. Reading from f will end either when end-of-ffle is reached or a -1 -1 is
read. Include is called independently of init.
game g Once the board has been initialized, this command starts a new game, with
a commitment to solve the game in g moves or fewer (g > 0). game and new cannot
be called once a game has been started.
switch sWithin a game, switches the top-left (0,0) cell to s, changes all appropriate
neighbours, and then redisplays the grid.
The program ends when the input stream is exhausted or when the game is won or lost.
The game is lost if the board is not in one state within g moves. You may assume that
inputs are valid.
If the game is won, the program should display Won to stdout before terminating; if the
game is lost, it should display Lost. If input was exhausted before the game was won
or lost, it should display nothing.
Note: notice that most of the above has already been implemented in con-
troller.cc. There are a few features left for you to implement. These are clearly marked
in controller.cc with TODO comments.
A sample interaction follows (responses from the program are underlined):
new 4
init
0 0 4
0 2 3
0 3 2
1 1 1
1 3 3
2 0 4
2 2 2
2 3 1
3 1 2
3 3 3
-1 -1
4032
0103
4021
0203
game 4
4 moves left
switch 0
0032
0103
4021
0203
3 moves left
switch 4
4432
4103
4021
0203
2 moves left
switch 0
0032
0103
0021
0203
1 move left
switch 2
2232
2103
2221
2203
0 moves left
Lost
Note: Your program should be well documented and employ proper programming style.
It should not be overly inesocient and should not leak memory. Markers will be checking
for these things.
Note: Provided ffles: main.cc cell.h controller.h controller.cc game.h view.h textdis-
play.h
Due on Due Date 1: NO TEST CASES ARE NEEDED FOR THIS QUESTION.
However, you might still want to create test cases as it is considered good practice.
Create and submit a UML diagram for the program you are asked to create for Due
Date 2. All information needed to create this diagram is available in the ffles provided
above. You need not include main.cc in your UML. Name the ffle q2UML.pdf.
Due on Due Date 2: Submit your solution. You must include a Makeffle, such that
issuing the command make will build your program calling the executable flood.
(b) In this problem, you will adapt your solution from problem 2 to produce a graphical
display. The solution to Problem 2 part (a) could be executed as:
./flood
In part (b), the program can take an optional parameter, a string -graphics
./flood -graphics
This should produce a graphical display for the game (the game is still controlled through
the keyboard). Note that if your solution to part (b) is executed without the command
line argument, it should have the exact same behaviour as your solution to part (a).
You are provided with a class Xwindow (ffles window.h and window.cc), to handle the
mechanics of getting graphics to display. Declaring an Xwindow object (e.g., Xwindow
xw;) causes a window to appear. When the object goes out of scope, the window will
disappear (thanks to the destructor). The class supports methods for drawing rectangles
and printing text in divterent colours. For this assignment, you need white, black, red,
green, and blue rectangles which correspond to the states 0, 1, 2, 3, and 4 respectively.
The one additional class you will need to create is:
GraphicDisplay - responsible for displaying the graphical version of the grid using
XWindows (see graphicdisplay.h). GraphicDisplay \is a" View and will therefore
inherit the notify and print pure virtual methods. Note that since this class will
implement a graphical display for the game, the print method need not do anything
(but still needs to be implemented for the class to be concrete).
To make your solution graphical, you should carry out the following tasks:
Alter you main function to accept the command line argument (see comment in
main.cc)
add a ffeld to the Controller class representing the pointer to a GraphicDisplay
object, so that it can be updated when the game state changes. Some hints on where
to make changes are given in the controller.cc ffle.
create the GraphicDisplay class. GraphicDisplay should accept update notiffca-
tions about each cell in its display and update the corresponding rectangle of the
display (based on the coordinates and colour) accordingly.
the GraphicDisplay class should have a pointer to the Xwindow class so it can draw
to the display.
When Controller is notiffed of an update, it should send a corresponding notiffca-
tion to GraphicDisplay.
The program should accept the additional command ? which prints out
White: 0
Black: 1
Red: 2
Green: 3
Blue: 4
which is the encoding between the text version and graphics version.
The window you create should be of size 500x500, which is the default for the Xwindow
class. The larger the grid you create, the smaller the individual squares will be.
Note: to compile this program, you need to pass the option -lX11 to the compiler. For
example:
g++ *.cc -o flood -lX11
Note: Your program should be well documented and employ proper programming style.
It should not leak memory (note, however, that the given XWindow class leaks a small
amount of memory; this is a known issue). Markers will be checking for these things.
Note: Additional ffles provided: window.h window.cc graphicsdemo.cc
Due on Due Date 2: Submit your solution. You must include a Makeffle, such that
issuing the command make will build your program calling the executable flood.