We began with the idea to use a random maze each time the game started. Using an idea we had heard from a earlier teacher, we set up the maze as a disjoint set with each cell being in its own set upon initialization. Walls were then randomly knocked down until the entry cell and exit cell were in the same set, meaning the maze had a valid solution. A maze abstract data type was used to create our OpenGL maze and since each cell in the maze was itself an ADT, it was easily adaptable to be displayed.

For the texture mapping portion of the assignment, there was much to be learned. The RedBook was fairly vague in its descriptions of how to set up such a mapping, so even understanding the calls that establish a texture map was a task that had to be undertaken. We had some mythical idea that implementing this portion of the assignment was going to be simple. However, as we soon learned, there are many things to take into consideration, such as the type of image that will be read in, how it will be read in, and how to map it to the modeling coordinates.

After looking around online for some textures and downloading a shareware image converter from download.com (ImagXpress ActiveX Image Converter), we were soon on our way reshaping and converting images. The converting software provides the option to convert images from other formats into ASCII .ppm files, and we decided this would probably be the easiest format to read in. The biggest problem at this point was a misunderstanding of the gluBuild2DMipMaps() function. Assuming that images of any power of two for both the width and height could be used for MIP-mapping, we were trying to create MIP-maps of the size 512 x 256. Thus, much time was spent tweaking the image reading code and staring at debugging variables when the problem was not pertaining to that code at all. Only when we altered OpenGL to use linear mapping did we realize that the images were being read in correctly, and that our problem was elsewhere.

Once an understanding of the mip-map building function was tackled, the project moved along fairly smoothly. We added a light that moved along with the player through the maze, and it was interesting to observe how local lighting is really implemented, since the lighting could be seen through the walls into surrounding rooms. After a little more trouble, we were able to blend in lighting for the textures on the walls and floor by blending their color values with the lighting values calculated for the white walls they were painted on.

After properly generating a random maze, finding a solution for it, applying texture maps to it, and lighting this maze, all that remained was the addition of lots of smaller features. For instance, we decided to add a mode in which the textures could be animated (wacky mode), and to add an arrow that slowly changed colors with the idle loop. These small features were very time-consuming, but they boosted our pride in the project, so they all seemed worthwhile.

Overall, I think the biggest lesson we learned was this: generating lighted texture maps is not a simple thing to do. Like many other concepts in graphics, it requires a fairly extensive knowledge and a little luck.