Quoridor Team official website
In my Senior Project class, each student could choose from several projects to develop. My high interest in video games influenced me to choose the Quoridor project. Quoridor is a board game created by Gigamic Games (based in France) in which two to four players advance tokens across a board in order to get to the other side. Players move one space at a time on a square grid, while utilizing "walls" that can be used to block an opponent to facilitate one's own progress. Learning to play the game is simple, but the fun lies in mastering the game strategically. Our group's job was to create a computer version of Quoridor that would also allow AI and network players to play, if so desired. (Please note: Due to potential copyright issues, the game executable file will not be posted.) If you wish to see a demonstration of the game, please contact me.)
User Manual
During the middle stages of the project, our client and manager both requested that we produce a user manual for an intended user to read. The user manual explains the game from start to finish - how to install the program, how to play the basic game, how to play a network game, how to use the logs to track game progress, and how to create AI modules for the game. Except for some technical details involving AI modules, I wrote the majority of the user manual for Quoridor. The document underwent several revisions, as the program evolved from a simple local (Hotseat) player game into a multi-option network and AI player game. For consistency, I also included the text from the user manual in the Help menu in the Quoridor game. I also included a glossary at the end to familiarize the users with the new terminology - both Quoridor-related and computer-related. Our target audience was basically our client (a college instructor) and any computer science students using it for learning purposes. I wanted to design the document so that each option and phase of the program would be explained separately. Therefore, if someone just wanted to play the game on their own computer, they would not need to read about AI modules or networking functionality. I am fortunate that I was given the opportunity to compose such a well-organized document.
Requirements Analysis
Requirements Analysis Document (RAD) (.doc)
Requirements Analysis Document (RAD) (.html)
The first document to write for the project was the Requirements Analysis Document. Basically, we were to learn everything about the board game Quoridor and decide with the group and our client how to approach designing the program. The RAD covers the basics of the board game, the functional and non-functional requirements, optional features, and the intended basic flow of the program. The low-level components of the program are covered in the next document, the System Design Document. We also defined the terminology of the game in a glossary section at the end. Basically, the purpose of this document was to define what the existing product functionality was and what the the new intended functionality will accomplish.
Quoridor Final Presentation
I designed PowerPoint slides for our final presentation. I specifically organized the slides by sections. I used different clear color windows to indirectly represent who would present each slide. The combination of the colored windows, bright lines and black chain background make the presentation very unique, colorful, efficient, and professional. I spent a lot of time rearrangng the slides to better suit the overall flow of the presentation topics. Overall, I really enjoyed making this interesting presentation.
Project Plan
Project Plan Document (PPD) (.doc)
Project Plan Document (PPD) (.html)
The Project Plan covers all the aspects of the Quoridor Project in general. Items covered include the project timelines, risk management, team structure, coding and testing plans, and other plans. The most important part of this document for our manager and client was the project timeline. Setting realistic goals and staying on track were their primary concerns. The project did evolve over time, so we had to make several adjustments to the timeline plan as we went along.
System Design
System Design Document (SDD) (.doc)
System Design Document (SDD) (.html)
In the System Design document, the team's design goals, lifecycle model, and system architecture are defined and explained. As the project evolved, so did this document. Several subsystem mappings had to be redesigned, as more functionality was added to the program. Though one of the smaller documents, the system design set the guidelines for the major technical aspects of the program.