Project 3: Mazes on the Web

Random maze generation and solution using Partition and DFS

Version 09/17/18

Educational Objectives: After completing this assignment, the student should be able to accomplish the following:

Operational Objectives: Implement (1) a random maze generator as a client of fsu::Partition and (2) a maze solver using fsu::Path_DFS.

Deliverables:

ranmaze2t.cpp   # client program of Partition <> generating random mazes
ranmaze2w.cpp   # client program of Partition <> generating random mazes
solvemaze.cpp   # solves a maze problem conforming to the course maze technology
maze_demo       # contains maze demonstration
log.txt         # development and testing log, contains URL for maze_demo

Procedural Requirements

  1. The official development/testing/assessment environment is specified in the Course Organizer. Code should compile without warnings or errors.

  2. In order not to confuse the submit system, create and work within a separate subdirectory cop4531/proj3.

  3. Maintain your work log in the text file log.txt as documentation of effort, testing results, and development history. This file may also be used to report on any relevant issues encountered during project development.

  4. General requirement on genericity. Use generics whenever possible. For example:

    1. If you need to sort, use a generic sort algorithm or a container with built-in sorting.
    2. If a sort requires a specialized notion of order, create a function object that captures the desired order property.
    3. If you need a graph algorithm, use a component of the fsu graph library.
    4. In general, whenever a generic algorithm exists that can be deployed, do not circumvent that with specialized one-off code.
    5. Carefully choose all containers as the most appropriate for a particular purpose.

    In short: re-use components from LIB (or your own versions) whenever possible. Don't re-invent the wheels.

  5. Begin by copying all of the files from LIB/proj3 into your proj3 directory along with relevant executables from area51. You should see at least the following:

    deliverables.sh        # submission configuration file
    ranmaze2t_i.x          # sample executable
    ranmaze2w_i.x          # sample executable
    mazemaster_i.x         # maze analyzer
    solvemaze_i.x          # maze solver
    makefile               # makefile for project
    mazeprint.c            # C source code for "printmaze.x" (for demo)
    index.php              # index for demo
    mazegen.sh             # bash script for demo
    

    Execute ranmaze2w_i.x to generate maze files and mazemaster.x to analyze the resulting maze files. You will follow the same process in testing your own ranmaze and its resulting maze files. Also pay careful attention to the detailed I/O behavior of ranmaze, this is how your program should behave.

  6. Create the file ranmaze2t.cpp, a client of Partition<>. Using mazemaster2t.x, test thoroughly to be sure the mazes it generates are self-consistent and that the behavior mimics that of LIB/area51/ranmaze2t_i.x, including the file name extensions for output files.

  7. Create the file solvemaze.cpp, a client of Path_DFS<>. Test with smaller mazes against results from mazemaster.

  8. Activate your CS web space on ww2.cs.fsu.edu. Note this may require interaction with the system group.

  9. Create your web space directory http://ww2.cs.fsu.edu/~[your_user_name]/maze_demo

  10. Populate your demo directory with the files

    index.php
    mazegen.sh
    ranmaze2w.x
    solevemaze.x
    printmaze.x
    

  11. Set permissions for initial creation of output files (owned by apache), run one time, and then reset permissions to a safer level.

  12. Test the web demo (on web server) and the text-based system (on linprog).

  13. Follow these steps when you are ready to submit:

    1. Be sure that you have established the submit script LIB/scripts/submit.sh as a command in your ~/.bin directory. [We are currently using version 2.0.]
    2. Copy the submit configuration script LIB/proj3/deliverables.sh into your project directory. [This is an important step, as deliverables may have changed.]
    3. Submit the project using the command submit.sh while in your project directory and logged in to shell or quake. Pay attention to the screen, which will warn you about missing deliverables and incorrect login.
    4. Check your CS email for feedback. If Robocheck is active for this project, read the results from automated testing.

    Warning: Submit scripts do not work on the program and linprog servers. Use shell.cs.fsu.edu or quake.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.

Code Requirements and Specifications - ranmaze

  1. Output maze files according to the spec in the Union-Find notes Appendix: Maze Technology. Take care that all maze files are syntactically and semantically correct - mazemaster.x is helpful in testing your output.

  2. The maze file should have the start cell at the beginning (left-most cell) of the middle row and the goal at the end (right-most cell) of the same row.

  3. ranmaze should expect three command line arguments: number of rows, number of columns, and filename.

  4. ranmaze2t.x should output two versions of the random maze: (1) the first time goal is reachable from start, output the maze to the file "filename.[components]" where [components] is the actual number of components in the maze; and (2) after all cells are reachable from start, output the maze to the file "filename.1". ("2t" is for "text version using partition2.h".)

  5. ranmaze2w.x should output only the version of the random maze with all cells reachable from start (i.e., the maze graph is connected) and output file "filename.1". ("2w" is for "web version using partition2.h".)

  6. Take care that your mazes are correctly "random" in the sense that all walls that can be legally up/down have the same probability of being selected for inspection at each step. This is mostly a matter of judicious design, especially at boundary cases. For example: be sure that a cell face on an interior cell has the same chance of selection as a cell face of a boundary cell, where fewer faces are eligible.

Code Requirements and Specifications - solvemaze

  1. Input: a maze named "xxx"
    Output: a copy of xxx, with the solution appended, in file named "xxx.dfs".
    (Here, "xxx" stands for the name of any semantically correct maze file.)

  2. Use the utilities to full advantage to follow this processing model:

    1. Load maze file into directed graph
    2. Check digraph for symmetry (same as checking maze for consistency)
    3. Find path from start to goal
    4. Create output file name and open file for write
    5. Copy contents of input file to output file - first the documentation then the numbers
    6. Write solution as cell numbers (should be same as vertex numbers)

    Be ready to explain why applying Path_DFS(v,w) is more efficient than calling DFSurvey::Search(v).

Code Requirements and Specifications - web demo

  1. Behavior should mimic http://www.cs.fsu.edu/~lacher/courses/COP4531/maze_demo/.

  2. Be sure you have read and understand the scripting code in the supplied files

    index.php
    mazegen.sh
    

Hints - makefile

Hints - Ranmaze

Hints - Solvemaze

Hints - Visualization / demo