Educational Objectives: Experience using the ADT Queue to perform breadth-first search; experience using ADT Stack to reverse a sequence; solving problems with bitwise computations; more large project experience
Operational Objectives: Design and implement a simulation that receives as input a rectangular 2-dimensional maze along with "begin" and "goal" locations in the maze and produces a path through the maze from "begin" to "goal" using breadth-first search.
Deliverables: Five (5) files: maze.h, maze.cpp, ratpack.cpp, makefile, and mymaze.
A maze file is designed to describe a maze problem as defined above. The file consists of unsigned integers that may be in any format in the file but are typically arranged to mimic the actual arrangement of cells in the maze problem. Your program should read maze data from an external file, assuming the following file format:
numrows numcols (first row of codes) (second row of codes) ... (last row of codes) start goal [optional documentation or other data may be placed here]
We will refer to such a file as a maze file. (Note that the actual format is optional, for human readability. The file is syntactically correct as long as there are the correct number of (uncorrupted) unsigned integer entries.)
A maze file is interpreted as follows:
numrows and numcols are the number of rows and columns, respectively, in the maze.
Each entry in a row of codes (after numrows and numcols but before start and goal) is a decimal integer code in the range [0..15]. The code is interpreted as giving the "walls" in the cell. We will refer to this as a walls code. A specific walls code is interpreted by looking at the binary representation of the code, with 1's bit = North wall, 2's bit = East wall, 4's bit = South wall, and 8's bit = West wall. (Interpret "up" as North when drawing pictures.) A bit value of 1 means the wall exists. A bit value of 0 means the wall does not exist. For example walls code 13 means a cell with North, South, and West walls but no East wall, because (13)10 = 8 + 4 + 1 = (1101)2 (no 2's bit).
Cells are numbered consequtively from left to right and top to bottom, beginning with cell 0 at the upper left. (Thus, a 4x6 maze has cells 0,1,2,...,23.) We refer to these as cell numbers. start and goal are cell numbers (NOT walls codes). They inform where the maze starting location is and where the goal lies.
The optional data following goal is treated as file documentation (i.e., ignored).
Work files. Work within your subdirectory cop4530/proj3. The usual COP 4530 rules apply, as explained in Chapter 1 of the Lecture Notes.
From the course library directory LIB, copy the following files into your project directory:
LIB/submitscripts/proj3submit.sh LIB/proj3/maze.h LIB/proj3/ratpack.cpp LIB/proj3/mazetest.cpp LIB/proj3/maze? LIB/proj3/badmaze?
Create the files makefile, maze.h, maze.cpp, and mymaze adhering to the requirements and specifications below.
Turn in files maze.h, maze.cpp, ratpack.cpp, makefile, and mymaze using the submit script submitscripts/proj3submit.sh.
Warning: Submit scripts do not work on the program and linprog servers. Use shell.cs.fsu.edu to submit projects. If you do not receive the second confirmation with the contents of your project, there has been a malfunction.
Solution design. Your solution should be based on the framework distributed in the file proj3/maze.h. This framework consists of two classes, Maze and Cell.
Interface (Maze public member functions)
Internal representation
A Maze object can hold one internal maze representation, read from a maze file. Class Maze is designed to be a singleton: only one Maze object exists in a given execution environment. Use of a copy constructor and assignment operator by client is prohibited. Maze data is as follows:
private: // data unsigned int numrows, numcols; Cell * start; Cell * goal; fsu::TVector < Cell > cellVector; // cell inventory fsu::CQueue < Cell* , fsu::TDeque < Cell* > > conQueue; // control queue fsu::CStack < Cell* , fsu::TVector < Cell* > > solStack; // solution stack
numrows and numcols store the dimensions of the maze.
cellVector is used to store actual Cell objects that make up a maze. Cell objects should not be copied.
start and goal point to the start and goal cells (in the cell inventory).
conQueue is the principal control queue for the maze solver algorithm. Note that conQueue stores pointers to Cell objects, which reside in the cell inventory.
solStack is the place where the final solution is stored immediately prior to output.
No data members may be added to class Maze.
Class Cell is a subsidiary class for Maze, tightly coupled by granting friend status to class Maze. A Cell object represents one square cell in a 2-dimensional maze, used by Maze to represent rectangular mazes of square cells. The constructors and assignment operator of Cell are public, to facilitate storing Cell objects in container classes. All other methods and data are private, hence accessible only by the friend class Maze. Cell data is as follows:
private: // data unsigned int id; int visited; Cell * backtrack; fsu::TList < Cell* > neighborList;
id is the name (cell number) of the cell
visited is a flag indicating whether a cell has been visited
backtrack is a pointer to the predecessor cell computed by BFS
neighborList is a list of (pointers to) cells that are adjacent to this cell in the maze
No data members may be added to class Cell
Internal functionality
int Maze::Initialize(char*)
Reads data from a maze file and sets up the internal representation of the maze problem. The complete internal representation of a maze problem is established, including the maze dimensions, cell inventory (with neighborlists for each cell), and start/goal. Checks the maze file syntax while reading. Returns true when read is successful. The following should be checked as the file is read:
int Maze::Consistent() const
Checks the internal representation of a maze (previously established by Initialize()), detecting and reporting situations where the representation is not self-consistent. Returns true when no inconsistencies are found. The following logic errors should be caught ([R] = required, [O] = optional):
void Maze::Solve()
Uses breadth-first-search (facilitated by conQueue) to find a solution to the internally represented maze problem. Once problem is solved, uses solStack to store (forward) solution path and outputs the solution.
void Maze::ShowMaze(std::ostream&) const
Produces a graphic of the maze using the internal representation.
void Cell::AddNeighbor (Cell * N)
Adds a (pointer to) a new neighbor cell of this cell.
Cell* Cell::GetNextNeighbor () const
Returns (pointer to) this cell's next unvisited neighbor. Returns 0 if
this has no unvisited neighbors.
int Cell::IsNeighbor (const Cell * N) const
Returns 1 if N is a neighbor of this cell.
Various data accessors and manipulators
Recommended to be used for safe programming practice when implementing
Maze methods.
Required elements.
No data members may be added to class Maze or class Cell.
Do not use recursion.
Private methods may be added to Maze as desired, but no methods should be added to Cell.
A minimum functioning solution consists of methods Initialize() and Solve() operating correctly on correct maze files. (This is the 80 point level.)
An advanced solution also implements method Consistent() and operates correctly on both correct maze files and improperly configured maze files. (This is the full 100 point level.)
Up to 20 extra credit project points may be earned for implementation of method ShowMaze(). Note: To get the full 20 points extra credit for ShowMaze(), you have to do something more creative than is illustrated in ratpack.x. If you do that exactly, you can get 15 extra credit points.
One maze file mymaze of your own creation is required. (That is, it should not be based on any distributed files and should not be obtained from another source). mymaze should be a (correctly configured) representation of a maze problem with at least 6 rows and 5 columns with a solution at least 20 steps in length.
The test harness distributed as proj3/ratpack.cpp should be modified only by commenting out the functionality you are not implementing and submitted as part of the project.
Review of deliverables:
maze.h and maze.cpp define and implement classes Maze and Cell
ratpack.cpp tests the functionality you
implement for Maze
makefile creates an executable called
ratpack.x using the above three files
mymaze is a maze file of your own creation
Begin the project by creating a few maze files. Recommended practice: put an ascii graphic of the maze in the maze file, following the maze file data. Use LIB/area54/ratpack.x or LIB/area54/mazetest.x to check out your maze files.
Recommended order of implementation of methods:
Think of the cell vector as a master inventory of cells. All other references to cells point into this inventory (rather than making copies of cells). "Point" with pointers, not indices.
Assuming that number, row, col are unsigned int, the
number of a cell is obtainable from its row, col indices as
number = row * numcols + col;
Similarly, if you know the cell
number then you can find it's row, col indices from the cell
number as
row = number / numcols; col = number % numcols;
Now ask yourself: what are the numbers of the neighbors to the North, East,
South, and West?
A walls code of a cell is easily converted to see which neighbor cells are accessible. For example, to see whether cellVector[number] has an accessible neighbor to the West, do something like
if ((0 < col) && ((walls & 0x08) == 0))
{//add the West neighbor to the neighbor list}
Sample executables ratpack.x and mazetest.x will be available in area54.
Dont forget: You will be graded on what you submit that works. If your submission doesn't compile, or if you don't compile a particular functionality, you will be graded accordingly.