Quoridor is a board game in which players must traverse a board in order to win. Each player is also given a number “walls” in order to block his opponent, or use in facilitating his path. Players take turns, and the person who starts first is randomly selected, unless otherwise noted. On a player’s turn, he may either move his given token one space horizontally or vertically, or he may place a wall. The walls cover the groove between two spaces. More details about game play will be mentioned later in this document.

The program will have three different Artificial Intelligence (AI) scripts: one with random moves; one with simplistic moves; and one that plays more advanced moves. The program will also have the ability to host up to four players at one time or any combination of AI scripts or players. These AI’s will be written in C++ and will be selected from inside the game. This will gives AI students a good chance to test their modules.

1.2) Design Goals

1.3) Stakeholders

The members of Team Quoridor are the primary stakeholder, since the success of this project will be a key factor in the team’s progress in the Senior Project course. AI students will be another stakeholder, since this program would be helpful in aiding their education in programming AI modules. Professor Klein will also be a stakeholder in this project. He is the client, so he is dependent on Team Quoridor to successfully deliver a successful project.

2.) Current System

The current system is in the form of a board game. It is not computer based. We are not fixing an existing problem or updating a former system. Our objective is to design and implement a computerized version of Quoridor, the board game. Having a computerized version should help limit player confusion, by only allowing legal moves to be played.

3.) Functional Requirements

The basic function of our project is to provide the necessary procedure and interface for playing Quoridor on a computer. The specifics are governed by the rules for playing the classic version of Quoridor. When necessary, we will add or adjust rules to compensate for the computer platform specifications.

If one user is playing another using multiple computers, one user will have to be designated as a “host,” and the other(s) a “client.” The host will set up the game for all the players. The client will type in the networking information to link up with the host.

Game Start

Once a user launches the game, it will prompt him or her with an option screen asking if he would like to start a new game, continue a game in progress, or join a game set up by a host computer. If the user selects to continue a game, he will select the game from a dialog box that comes up, and the game board with the previous conditions and settings will come up. If the user selects to join a game, the user will then type in the IP address and port number of the host computer.

If the host selects “New Game,” another screen is going to come up and ask how many human players and/or computer players are going to be in the game. Also this is where the host can change the options of the game. Options include:

4The board size (default is 10x10 spaces; range is from 6x6 to 12x12 spaces);

4The number of walls each player starts with (can be 0 to 144 per player);

Then the host selects the status of each player. For up to 4 players, the following choices may be made: 1.) Human; 2.) AI. After these selections are made, then a game board should appear on the screen.

The board would start with the number of character tokens depending on how many players were selected. These tokens will not actually start on the board – they will be placed outside the desired or random edge of the board (see figure 3a). By default, the game will randomly choose a player to start the game.

Text Box:

Figure 3a - Placement of two player tokens at game start (6x6 board)

In-Game Flow

On a player’s turn, he may move one space or place a wall. After he does this, the next player continues this procedure, and so on. For the first move, the player may choose any space on his edge of the board to move. Once on the board, however, he may not move off the board except on the opposite side.

Option 1: Move Token

A player’s token may be moved either right, left, forward, or backward. A token may not be moved through a wall or on top of another token (see figure 3b).

In the case that there is a token in the way of the player, the player’s token may jump over the adjacent token and thus advancing 2 spaces. However, if there is a wall or another token behind or to the side of the adjacent token, that particular jump cannot be executed (see figure 3c).

Figure 3b - Illegal Moves Figure 3c - Examples of moves and jumps over tokens

Option 2: Place Wall

A player may place a wall anywhere on the board, on the grooves, blocking exactly two spaces. Also, walls may not overlap or cross (see figure 3d). Finally, a player may not place walls in such a manner that an opponent will have no way to get to the other side of the board.

This will not be an issue, however. Our program will only allow legal moves to be played. When a player decides to play a wall, he will drag a wall onto the board horizontally or vertically. The walls will automatically be snapped to a grid. Wall placements that cross other walls or prevent a player from reaching the other side will not be permitted by the game.

Figure 3d - Illegal wall placements

Game End

A game is terminated in one of three ways.

The game is terminated when one of the players reaches their opponent’s side off the edge with their token. At this point, the game ends and the player is given the choice to play another game or quit.

Another way to end a game is through choice. If the user selects the end game option, he is asked if he would like to save his progress then exit, or just exit.

The only other way that a user may terminate a game is through disconnection. If in any way the user is temporarily disconnected from the network, the game will wait for ten minutes for the player to return or else he forfeits. If the player forfeits, all other players will then be given the option to continue the game or start another game.

4.) Nonfunctional Requirements

4.1) Ability to Run on Windows

The program is expected to be run using the Windows operating environment. Since we are going to use Microsoft Visual Basic for implanting our program, operating on Windows is second nature.

4.2) Documentation

This RAD and upcoming documents describing the project will be used to specify the needs and constraints of the final product. These documents may be used by our client and manager to provide feedback or suggestions for improvements.

4.3) User Manual

We will provide a written user manual to help aid a user through the program. The manual will explain the basics of gameplay, how to use the interface, how to play over a network, and how to create and insert AI’s to be used as players.

4.4) Timely Gameplay

Algorithms and functions related to the game should run in an adequate amount of time, so that players do not have to wait for the computer to finish. Also, it is expected that players over a network will receive feedback from the opponent players with little time delay. The only delay should be the time to ponder moves and strategies and possibly network delay.

5.) Optional Features

The following is a list of features for our project that are extra, but not absolutely necessary. If the team finishes with extra time remaining at the end of the second semester, these features may be included.

4Time Clock – Limit each player’s turn to a fixed time to encourage quicker thinking.

4Help Menu – Display an overhead Help menu for use by a live player that will contain the gameplay rules, features, and interface instructions.

4Token Image Upload – Be able to upload one’s own picture file into their token.

4Interactive Help Box – Have a dialog box that can pop up explaining why a player may not place a token or wall in an illegal location.

6.) System Models

6.1) Sample Scenarios

Scenario Name: Start_1-livePlayer_Vs_1-AI_game

Actors: Brad – human player

Flow of Events:

1. Brad opens Quoridor on computer.

2. Brad selects “New Game.”

3. Brad selects “Human” on Player 1.

4. Brad selects “AI” on Player 2.

5. Brad finds and selects the file location of an AI module on the computer.

5. Brad clicks “Start Game” at the bottom. Tokens are chosen by default.

Scenario Name: Start_1-livePlayer_Vs_1-livePlayer_game

Actors: Sarah – advanced Quoridor player (host)

Brad – average Quoridor player (client)

Flow of Events:

1. Sarah opens Quoridor on computer.

2. Sarah selects “New Game.”

3. Brad opens Quoridor on another computer.

4. Brad selects “Join a game.”

5. Brad types in the IP address and port number of Sarah’s computer.

6. Sarah selects “Human” on Player 1.

7. Sarah selects “Client” on Player 2. A “Location” list box appears under it.

8. Sarah selects Brad’s computer from the “Location” list box (After Brad typed in the location of Sarah’s computer, Sarah’s computer updates that information dynamically, and Sarah can now select Brad’s computer as the location of Player 2).

9. Sarah clicks “Start Game” at the bottom.

10. The game board appears on both computers. Tokens are chosen by default.

Scenario Name: StartGameWith4_AIs

Actors: Drake – student in AI class

Flow of Events:

1. Drake opens Quoridor on computer.

2. Drake selects “New Game.”

3. Drake selects “AI” on Player 1.

4. Drake finds and selects the file location of one of his AI modules on the computer.

5. Drake repeats Steps 3 and 4 for Players 2 through 4.

6. Drake clicks “Start Game” at the bottom. Tokens are chosen by default.

Scenario Name: MoveToken

Actors: Brad – human player

Flow of Events:

1. It is Brad’s turn.

2. Brad clicks on his token.

3. Brad drags his token one square to the right.

4. Token is grayed out – He can’t move there due to obstruction of a wall.

5. Brad drags token forward and releases button.

6. Brad’s token has moved forward.

7. Brad’s turn is over.

Scenario Name: PlaceWall

Actors: Brad – human player

Flow of Events:

1. It is Brad’s turn.

2. Brad clicks on a wall in his inventory.

3. Brad drags the wall to a place on the board.

4. The groove he selects will not allow a wall to be placed.

5. Brad drags the wall to a different location.

6. Wall is legal and is set in place.

7. Brad’s turn is over.

Scenario Name: PlayAnotherOrQuit_1-livePlayer_Vs_1-livePlayer_game

Actors: Drake – student in AI class (host)

Brad – human player (client)

Flow of Events:

1. Drake wins the game.

2. The message “Would you like to play again?” appears on both computers.

3. Drake selects “Yes.”

4. Brad selects “No.”

5. Brad’s program closes.

6. Drake’s program displays “Client player has quit.”

7. Drake’s program returns to menu screen.

Scenario Name: TimeRunsOut

Actors: Brad – human player

Flow of Events:

1. Timer option is set to 30 seconds per turn.

2. It is Brad’s turn.

3. Brad’s time is down to 5 seconds.

4. Brad can’t decide on what to do.

5. Time reaches zero.

6. Brad’s turn is over.

7. Control switches to next player.

Scenario Name: Suspend Game

Actors: Kaz – Human player

Flow of Events:

1. Kaz (Player 1) wishes to stop the current game.

2. Kaz clicks on “Game” on the top in-game menu.

3. Kaz clicks “Suspend Game.”

4. A dialog box appears that says “Do you wish to suspend the game and play later?”

5. Kaz clicks “Yes.”

6. Kaz saves the current game in his desired file folder.

7. A message appears: “Game saved.”

8. The game is terminated for Kaz.

9. Dialog boxes appear on any live opponents’ computers that say “Player 1 has suspended the game.”

10. Live opponents do steps 6 though 8 on their computers.

6.2) Flow diagram

7.) Lifecycle

The Quoridor Model (Figure 7) does not fit any one exact model. During the “Requirements and Design” phase of the project, one part of our team works on gathering requirements while the other begins the design phase. While parts of the team work on the Design Document, other team members begin working on their parts of the prototype. This part of the lifecycle is similar to the Sashimi model. When the design is all finished, the team will code in a manner similar to the “Waterfall with Subprojects” model. Team members will be in charge of different subprojects, and each aspect will be developed in parallel. This will continue throughout three phases:

4Phase 1: We will complete all necessary functionality for playing a Hotseat game. This includes finishing and tidying up the interface, enforcing wall and token constraints (i.e. – Can’t place a wall on top of an existing wall), and allowing up to four players.

4Phase 2: We will add networking capabilities to our existing implementation. This will allow for several combinations of users to play over a network.

4Phase 3: AI functionality will be added. This includes inserting AI module into the program in a user-friendly environment to allow an AI to play the game.

8.) Proposed System Architecture

8.1) User Interface

Our proposed system will consist of three major screens. The first will simply be a title screen. The second screen will be a player setup screen that will allow a user to set up who will be playing each position in the game. The third screen is the playable game board where the actual live gameplay will take place. For “hotseat” gameplay (that is, all players are on the same computer), one computer will run one instance of the game. For network games there will be two to four instances of the Quoridor game running: One “host” and one to three “clients.” The host will set up the game using his program, while any clients will join the game set up by the host.

8.1.1 In-Game and Game Board Interfaces

The physical game board will be represented as shown in Figure 8.1.1.

Figure 8.1.1 - Screenshot of the game board screen (2 players)

As figure 8.1.1 demonstrates, there are two players: each token representing a player. Each player starts in a designated color zone on a side of the board. By default, player 1 starts on the bottom, player 2 on the top, player 3 on the left, and player 4 on the right. The target goal for each player is marked on each edge of the board with a colored zone. At the top of the screen is the game menu. A human player can access the help menu, or they can save and quit the current game. To the right of the board is the status of each player. The human players can view their remaining number of walls and choose to place a wall on the board by moving the cursor over the board.

A player’s turn involves either moving a token or placing a wall. To move, a human player clicks a space adjacent to the player’s token highlighted by the computer. If a user selects to place a wall, the wall will appear in the position the user selected. After a wall placement or a token movement, the player’s turn is over, and the next player’s turn begins.

When it is an AI’s turn, the AI will be given the current board state by the server and will be expected to return a legal move. If an AI produces an illegal move, then it automatically loses.

8.1.2 Game Setup Interfaces

After the title screen loads, a user will have three options to choose from: start a new game, continue a saved game, or join a game set up by a host. If the user clicks to continue a saved game, he will select a saved game from a dialog box. After a saved game is selected, the game will begin from the saved point. If the user selects to join a game, he will be prompted for connection information about the host game.

If the user selects to create a new game, a game setup screen will be shown to the user. This screen will allow the user to set up the number and location (local or remote) for each player. Each player will be either a local user, AI player, or a remote player. An example of this screen is shown in Figure 8.1.2.

In this example screen, two players have been selected to play. This is actually the default setting, since Quoridor requires a minimum of two players to begin the game. This example setup assumes there are two human players at one computer, competing against each other. At the bottom, the board size has been set to 6x6 (a 36-square board), and the number of walls for each player to use has been set to 10.

Figure 8.1.2 - Player Setup Screenshot

8.2) Persistent Data Management

Data will be stored to a text file that will contain the status of a game so that the file may be later read to continue a saved game. A game can only be saved when a player clicks “Save” from the “File” menu. This file will contain setup information of the game, information about each player, and the game state. Setup information will include the board size and the number of players. The type, name, and location (local or remote) will be saved for each player. For the game state, the position of all walls and players will be outputted to the file.

8.3) Subsystem Decomposition

Quoridor will be broken down into the subsystems shown in Figure 8.3.

Figure 8.3 - Subsystems in Quoridor

8.3.1 Interface

This subsystem will consist of all the interaction with the user. This subsystem will be responsible for collecting the information needed to start a game. Then it will begin the new or loaded game and display the game status to user. This subsystem will also allow the user to input moves or wall placements. This subsystem will interact with the Client subsystem. The moves a user makes will be validated by the Interface. Also, the Interface layer will calculate all possible valid moves for a given board state and player. The Interface layer will receive moves made by other players (remote, AI, and local) from the Client subsystem and display these to the user. The interface is responsible for updating its own stored board state with new board states. The Interface subsystem will interact with the Client.

8.3.2 Game

The Game subsystem will store the current board state and validate moves and wall placements that are sent to it via the Server subsystem. The Game subsystem will send messages back to the Server subsystem which will indicate that the move or wall placement is valid. This subsystem will also receive startup parameters from the Server subsystem to setup a new game (ex: board size, number of players, etc.). The stored board state in Game is final should the board states of the various Interfaces be conflicting. The Game subsystem will only interact with the Server.

8.3.3 Client

The Client subsystem represents a player and handles a connection to the Server and to the Interface of the local computer. The Client will connect to the Server when created. The Client serves as a gateway for moves being passed between the Server and the Interface both directions. The Client will know what player it is representing and will signal the Interface when it’s the Client’s turn. Up to four Clients may exist for one game and they are not necessarily on the same computer. If the Client receives a message from the Server saying that the move sent was an invalid move, it informs the Interface and asks the human player for another move. The Client interacts with the Server, and it interacts with the Interface of its local computer.

8.3.4 Server

The Server subsystem runs the game. When beginning a game, the Server sets the settings for the game and stores them in the Game subsystem. The Server will then listen for connections for the number of expected Clients (one Client represents one player, and may not necessarily be local). At this time, AI Modules may connect, and they are treated by the Server as if they were Clients. After the connections is established, the Server will send out the settings, what player numbers each is, the current board state (most often blank, but may differ if a game is loaded), and the current player’s turn. If the Server receives an invalid move, it will send a message telling that the last move was invalid. The Server receives moves from the Client, validates the move by Game, and then sends out the performed move to all Clients. At this time it will also tell whose turn it is and the current board state.

8.3.5 Artificial Intelligence (AI)

The AI subsystem represents the AI Module that may plug into Quoridor. The Quoridor team will provide the header file that is required for an AI Module to connect and interact with Quoridor. The AI Module will be passed the current board state when it is the AI’s turn and it is expected to return a valid move. If an invalid move is received (which is checked by Server), the Server will send the invalid message, and the AI Module in the header will send another message informing the Server that the AI has lost (due to sending an illegal move). This causes the AI’s token to be removed from the board. The AI Module header will only interact with the Server.

8.4) Hardware / Software Mapping

Quoridor may be played with two to four players all on the same computer. A game may also be played over a network. In the case of a network game, one instance of the Quoridor application (the host) will setup a new game while the other instances (the clients) connect to the host instance. Each client will run on a separate computer. In the case where there are four players all located on separate versions of Quoridor, one player would reside on each computer to produce a total of four instances of Quoridor. An example diagram of this is shown below in Figure 8.4.

Figure 8.4 - Clients connecting to the Server

8.5) Access Control

The Quoridor program will be able to be accessed by any one who is able to obtain the executable program or access an installed version of Quoridor game on a computer. No passwords or other security features will be used to control user access.

8.6) Global Software Control

The Quoridor program is an event-driven user interface game. The system interacts with users through a Graphical User Interface. The interface displays the board to the user and allows the user to input token movements or wall placements. The whole system will be developed in Visual Basic .NET. Visual Basic is used because of the Graphical User Interface abilities available. The system must have a visually pleasing and easy-to-use interface for the user to set up and play games. AI’s will use C++ as their programming language.

8.7) Boundary Conditions

Initialization: The system will initialize to the setup screen before beginning a game. Changes to the board size, number of players, and player type will be made here.

Termination: The system will be terminated when the user chooses to exit the program by clicking an X at the top right side of the screen or choosing to exit from the menu at the top of the screen.

Failure: When a failure occurs, the user will be given a message stating that a critical failure has occurred. The application will then exit, and the user may restart the application. Examples of a failure would be a memory access violation error should the program attempt to access data outside of the array.

9.) Hardware and Software Requirements

Expected hardware for the project will include a PC with the appropriate specifications to run a current version of Windows XP. Microsoft Visual Studio will be used for programming and designing our application. We will need access to a computer network for designing games between multiple computers.

10.) System Testing Plan

In this section, we traverse through the different types of testing we will use during the project. For all testing, we will use Visual Basic’s compiler and debugger to locate bugs and track the progress of the program.

10.1) Module Test (Interface subsystem)

10.1.1 Objective

We will test our Interface subsystem to ensure all visuals and graphics behave according to the requirements stated in the Requirements Analysis Document. We want to make sure the interface will allow us to perform the minimum functionality before we constrain the game with the rules of Quoridor (see Section 10.2).

10.1.2 Procedure

We will design scripts to test the various graphical user interface functions. These functions include placing walls on the game board, moving tokens across the board, changing a player’s turn by indication on the right side of the board, setting the board size, setting the number of players, taking players to the board after setup, etc..

A script consists of a list of step by step commands to be issued to the interface by a user. A different script will have to be developed to test gameplay on 3 different board sizes (the minimal 6x6, the default 10x10, and the max 12x12 boards). An example of a script would consist of both players moving their pieces to every square as well as players placing walls at specific spots. Illegal move validation is not incorporated at this module test, so this will not be tested nor performed in the script.

10.1.3 Example

Sample script testing to see if tokens will move across the board, space by space from the starting zone to the goal zone (assuming space highlighting and player turns are already implemented). This script tests if a player can move his or her token across the board, if a player can achieve a victory, and if a wall can be placed.

· Set the board to 6x6 board (one of the 3 sizes to be tested. This script tests this board size).

· Number of walls will be set to 3 per player in the set-up screen.

· Player 1 and Player 2 will be set to human, 3 and 4 will not be active.

· Begin the game by clicking “Start.”

· Move player 1’s token from the start bar to the 3^rd square from the left at the bottom of the board.

· Move player 2’s token from the start bar to the 4^th square from the left at the top of the board.

· Move player 1’s token one square up.

· Move player 2’s token one square down.

· Place a wall on the far right of the board.

· Move player 2’s token one square down.

· Repeat moving across the board for both players, until player 2 makes it to the edge of the board.

· Drag player 2’s token off the board.

10.2) Module Test (Interface subsystem with game validation)

10.2.1 Objective

We will test our Interface subsystem to ensure all visuals and graphics behave according to the requirements stated in the Requirements Analysis Document. We want to make sure the interface will allow us to perform the functionality of validation consistent with the rules of Quoridor.

10.2.2 Procedure

We will design scripts to test the various graphical user interface functions as well as ensuring that the illegal move checkers work correctly. These functions include placing walls on the game board, moving tokens across the board, changing a player’s turn by indication on the right side of the board, setting the board size, setting the number of players, taking players to the board after setup, and stopping players from performing illegal moves.

10.2.3 Example

· Set the board to 6x6 board (one of the 3 sizes to be tested. This script tests this board size).

· Number of walls will be set to 1 per player in the set-up screen.

· Player 1 and Player 2 will be set to human, 3 and 4 will not be active.

· Begin the game by clicking start.

· Move player 1’s token from the start bar to the 3^rd square from the left at the bottom of the board.

· Move player 2’s token from the start bar to the 4^th square from the left at the top of the board.

· Move player 1’s token one square up.

· Move player 2’s token one square down.

· Place a wall on the far right of the board.

· Place a wall on top of the previously placed wall (should be rejected).

· Place a wall so that the top of the wall overlaps with the previously placed wall’s bottom. (Should be rejected).

· Place a wall so that the bottom of the wall overlaps with the previously placed wall’s top (should be rejected).

· Move player 2’s token one square down (after all the rejections it should still be player 2’s turn).

· Move player 1’s token one square up.

· Move player 2’s token one square left. Should be rejected (Player 1 is in that location).

· Move player 2’s token one square down.

· Repeat moving across the board for both players, until player 2 makes it to the edge of the board.

· Drag player 2’s token off the board. He should be declared the winner.

10.3) Integration Tests (For each Phase)

10.3.1 Objective

Our system will be divided into three phases. In the first phase, we will test the Interface subsystem with all game validation functions. In the second phase, we add all functionality dealing with networking to the existing system tested in Phase 1. In Phase 3, we take the existing tested system from Phase 2 and integrate AI functionality.

10.3.2 Procedure

Modules will be grouped together for each phase. Once again, we will use scripts to test the various functionality added to each phase. For Phase 2, a human player should be able to play against an opponent human on another computer. In Phase 3, a user should be able to insert an AI into the game. In both Phases, the game should be fully functional for the given players.

10.3.3 Example

For the Interface plus Game Validation functionality (Phase 2), sample script testing to see if a very simple game of Quoridor can be played over a network.

· Start a game with a 6x6 board, 2 walls per player, and 2 player, one local and one remote (human).

· Player 1 moves his/her token to the third square from the left of the bottom row.

· Player 2 moves his/her token to the forth square from the left of the bottom row.

· Player 1 places a horizontal wall at the far left side of the board in the upper right corner.

· Player 2 places a horizontal wall at the same location (should be disallowed).

· Player 2 places a horizontal wall below the previous wall.

· Players 1 and 2 will continue to march down the board. Player 1 should make it to his/her goal first.

· Player 1 will move off the board. He should be declared the winner, and player 2 should not be allowed to move.

10.4) System Test

10.4.1 Objective

The system will be tested as a whole in an environment similar to that of the client’s.

10.4.2 Procedure

The only major difference between the System test and the Integration test for Phase 3 is that we will test the system by playing the game as an executable. All programming aspects will be “hidden” to ensure the user is separate from the implementation. We will combine functionality from scripts from previous tests to fully test the game. Emphasis will be on testing the requirements set by the client.

10.4.3 Example

In this example script, we are playing a game over a network using AI’s:

· Start the Quoridor program.

· Set Board size to 10x10.

· Set the wall limit to the maximum allowed.

· Player 2 is an AI. Set this up using the given AI file.

· Start the game.

· Each player (including the AI) should attempt to place walls until no more can be placed (The game should indicate that there are no more valid positions to play a wall).

· Each player should move their tokens to their goal zone, space by space, by moving forward if possible (The game will prevent going forward if there is a wall in the way). Otherwise, move left or right.

· When the first player reaches their goal, a message should appear saying they have won.

10.5) Acceptance Test

10.5.1 Objective

The system should meet all requirements of the client.

10.5.2 Procedure

The system will be tested at the client’s site using all functionality that he requested from the contract, which would be our client’s office computer. We will use the same scripts from the system test.

10.5.3 Example

See the example for System Test (section 10.4.3)

11.) Installation and Operation Plan

11.1) Installation

11.1.1 Responsibility

The development team – namely Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and Todd Astroth – will install the system at the client’s site.

11.1.2 Schedule

The installation of the system will occur on or before April 25, 2006.

11.1.3 Multiple-Site Considerations

Team Quoridor will be responsible for the installation of the system

at the client’s site only. The system may be distributed from that point forward as the client wishes.

11.2) Operation

11.2.1 Responsibility for Operation

The client will be responsible for all aspects of operating the software after it has been installed by the team.

11.2.2 Responsibility for Maintenance and Tuning

No maintenance or tuning will be provided for.

11.2.3 Duration of Responsibilities

The Quoridor team will be responsible for the software product until the client accepts the final product or until the end of the Spring semester 2006.

12.) Timeline

Figure 12a shows the timeline for the project in which all of these plans will take place. Figure 12b shows the basic plan for the next semester. We will spend a majority of the time testing the system and adding pseudo-requirements. The basic idea will follow our evolutionary lifecycle (see Section 7) with the three phases (Hotseat, Networking, and AI functionalities).

Figure 12a - CS 425 Timeline

Text Box: Phase 2
(Networking)

Figure 12b - Projected CS 499 Timeline (Orange = Phase 1, Yellow = Phase 2, Green = Phase 3)

13.) Team Organization Plan

In this section, we explain the roles of each team member. The organizational hierarchy explained in this section is represented in Figure 13.

Aaron O’Banion is the Project Manager and is responsible for organizing most aspects of the project. All questions and concerns will be forwarded to the group. In case of a stalemate, Aaron will make the final decisions for the project. Steven Klein is the main client contact. We will contact Mr. Klein if we would like to meet with the clients or if we have a question or suggestion. Dr. Bernard Waxman may also be contacted for questions regarding the project (NOTE: For CS 495 next semester, Dr. Daniel Dooly or Dr. Stephen Blythe will assume the role of Upper Management).

It should be noted that for each aspect and role in the project, no one person will do all of one thing. This way, each person is exposed to multiple aspects of the project.

Todd Astroth is the Lead Documenter. He is responsible for the basic writing and organization of all documentation during the project (see Section 18 of this document). Other team members will contribute to documentation by thoroughly proofreading and editing each document.

Mark Williams is the Lead Designer and is in charge of the Design phase of the project. The Lead Designer will communicate with other team members to analyze what is needed in the system.

Matt Stowe is the Lead Programmer and is responsible for assigning programming assignments to other team members. Matt will ensure that the project design is being followed and that the requirements for the project are being met with the programming that is done.

Chris Cobb is the Lead Tester and will be responsible for coordinating the testing of the system. See Section 10 of this document for more information on how we will do the necessary testing for the project.

Figure 13 - Basic Organization Chart

14.) Alterations to the System

This section explains how we will deal with changes to the system during the project.

14.1) Baselines

14.1.1 Problem Specification

This is defined in the Requirements Analysis Document.

14.1.2 Design Specification

This is defined in the System Design Document.

14.2) Proposing a Change

14.2.1 Who May Propose a Change

(a) Team Members:

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and Todd Astroth.

(b) Clients and Other Personnel:

Steve Klein, Bernard Waxman

14.3) Investigating a Proposed Change

14.3.1 Who, How, When

All team members will be in charge of investigating a proposed

change. Any major changes to the project structure will result in a version update of any documents involved.

14.3.2 Investigation Report

The team will analyze the change during meeting hours and design solutions to the change. Any discovered major changes will be updated in the applicable documents (RAD or SDD).

14.4) Change Management Board

14.4.1 Membership

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, Todd Astroth

14.4.2 When it Meets

The change management board will meet during the group’s regular meeting hours: 6pm to 9pm Monday and Wednesday in Dunham Hall 2009.

14.5) Implementing a Change

14.5.1 Approvals Needed

(a) Project Team:

The project team needs to form a general consensus among members. In the end, the Team Leader will make the final decisions.

(b) Client:

The client does not have to approve a change before it can be implemented, unless the change is considered to be outside the boundaries of the client’s scope.

14.5.2 Documenting the Change

Major changes will be updated in the applicable documents affected: namely, the RAD and SDD.

14.5.3 Scheduling the Change

The project will be rescheduled in the event that a major change has been implemented.

15.) Team Training Plan

This section provides what training will be needed for both internal and external sources. Internal sources include members of Team Quoridor, and external sources include the client and other spectators.

15.1) Internal Training

15.1.1 Coding Languages

Team members have used Visual Basic before, team members will need to recall their Visual Basic skills. Also, members need to learn how to use socket programming for manipulating networks

15.1.2 Interfacing With Other Subsystems

Team members will need to understand how to link subsystems together over a network in order for the system to function as a whole. We have decided that we will learn and implement socket programming in Visual Basic.

15.1.3 AI Modules

Team members are responsible for understanding how to implement basic Artificial Intelligence modules so that we can add this functionality to the system later. We should also be able to make this functionality as easy to use for our client and intended audience.

15.2) External Training

15.2.1 Installing the Software

The team will install the finished Quoridor project on the computer(s) of the client’s choice. The team will train the client if the situation is deemed necessary.

15.2.2 Using the System

Once again, the team may provide help to the client with the system if it is needed. We will provide a User Manual and a Help Menu for the system to help answer most user questions.

16.) Risk Management

The table below in Figure 16 summarizes the risks we have foreseen thus far and how to deal with the risk should it occur.

Risk	Description	Solution
Team Conflicts	Conflicts could arise between team members about the project or personal matters. This would slow the development process.	Private discussion with team leader or Upper Management.
Backtracking Difficulty	Upon development of certain features, such as the networking and AI issues, we may have to backtrack through design.	Team will redevelop design and proceed from there.
Team Member Lost	A team member may need to leave the team due to reasons beyond the team’s control. This would increase the work load for the remaining members.	The unfinished work will be redistributed amongst remaining team members.
Acceptance Issues	During review, our client Mr. Klein may inform us that an aspect of the system contradicts the view of his expected criteria.	We would refer back to the contract to clear up confusion. If there is an error on our part, we will fix the issue.
Late Finish	The project could drag out as a result of additional functionality becoming more complicated than expected.	Additional features will be left out and the basic system would still be functional.
Feature Creep	Adding extra features to the program could delay the development of more important functionality.	Save optional functionality for the very end and implement if time allows.
Networking Difficulties	Lack of knowledge of networking in VB could cause unforeseen difficulties in implementing the network.	We’ll spend time learning the networking before Phase 2 and set extra time and resources.
AI Functionality	Lack of knowledge of AI could cause unforeseen difficulties in coding the AI modules, and the AI functionality depends on the networking functionality.	We’ll spend time learning about AI’s before Phase 3 and set extra time and resources.

Figure 16 - Risks in the Quoridor Project

17.) Review and Reporting Plan

This section explains how we will review and report the group’s progress. Reviews and reports are generally formed on a regular basis. Written content can be found on our website. More information about written documentation can be found in Section 18.

17.1) Reviews

17.1.1 Documents

The team will create three major documents – namely the Requirements Analysis, Software Design, and Project Plan documents. These will be submitted to Upper Management to review.

17.1.2 PowerPoint Presentations

The team will create presentations to review what we have done so far. These presentations will take place at regular intervals during both semesters. The audience will mainly include other team members and Upper Management.

17.1.3 Client Acceptance

The team will contact the client when a major milestone has been completed or when a major question or concern has come up.

17.1.4 Upper Management Acceptance

In addition to reviewing the documentation mentioned in 17.1.1, Upper Management will provide verbal feedback about the status of the project and the team.

17.2) Reports

17.2.1 Individual Weekly Team Member Logs

Each team member will report what he does with regards to the project each week. These logs will be turned in as a means for Upper Management to assess Team Quoridor each week.

17.2.2 Meeting Notes

On occasion, the Lead Documenter will compile a list of important notes based on discussions from group meetings. These notes will generally be in a Word document.

18.) Required Documentation

This section maps out our plan for documentation involved in the project. Each major document will adhere to the guidelines set in this section. Major documents include:

§ Requirements Analysis Document

§ System Design Document

§ Project Plan Document

§ Weekly progress logs (for each team member)

§ User Manual

18.1 Preparation and Approval

Documents other than logs will be reviewed by Team Quoridor. If future changes are necessary to these documents, the changes will be executed through the System Alteration Plan (see Section 14). The Project Manager will make the final decision on the posting of version updates.

18.2 Typing

Each document will mainly be written and compiled by the Lead Documenter. Other the team members can contribute to typing as well. Once each section is completed, the document will be ready for proofreading and editing.

18.3 Proofreading and Editing

Documents other than the logs will be proofread by the team during regular team meetings. Once the entire document is proofread, the Lead Documenter will edit the document based on the requests of team members.

18.4 Distribution

The client may request any documentation at any time. All versions of the documentation will be kept with the Lead Documenter.

18.5 Electronic Storage

All documents will be available via the project website at: http://www.cs.siue.edu/SeniorProjects/f05g1/

19.) Glossary

AI (Artificial Intelligence) – refers to an algorithm that runs interactively to act as a logical sequence of actions as reflected by the actions of the human brain.

board – the square platform where tokens and walls are placed upon in Quoridor.

client – the designated players/computers that stand by as the host sets up and manages the game.

game – a session of play starting with tokens off the board and ending when any token reaches the other side of the board respective to its starting edge.

goal – colored zone on the edge of the board opposite from where a player starts. A player must reach this area to win the game.

groove – the “lines” that dissect the board, forming spaces.

host – the designated player(s)/computer that are responsible for setting up the game for all other players on different computers, referred to as “clients.”

hotseat – gameplay involving only one instance of a Quoridor game with 2 to 4 players.

jump – refers to the moving of a token past another token one unblocked space to any side of the other token.

local player – a player (human or AI) contained on a computer and not over the network.

move – a player moving from one square on the board to another square.

player – any entity interacting with the board game – can be a live person or an AI module.

remote player – a player (human or AI) contained on a computer over the network.

space – an individual square surrounded by grooves on the game board.

timer – refers to the timer that counts down the time left until the current player’s turn is over.

token – a game piece representing the player’s current position on the board.

turn – the procedure in which a player can move their token, place a wall, or pass their turn.

wall – a physical blockage which prevents players from moving across the groove where one is placed. Walls in Quoridor and in our implementation block two adjacent spaces in a line.

wall placement – placing of a wall in a valid location on the board.

20.) Contributions

RAD Version 1.0:

Aaron O’Banion – Typed/edited these sections: Introduction, Current System, Functional Requirements.

Todd Astroth – Typed/edited these sections: Functional Requirements, Non-Functional Requirements, Optional Features, System Models, Glossary.

Chris Cobb – Contributed ideas for how to display and implement the game board.

Matt Stowe – Contributed ideas for how to implement gameplay using a graphical user interface.

Mark Williams – Designed the organized structure of RAD.

RAD Version 2.0:

Aaron O’Banion – Reworded and edited all trouble areas indicated by instructor on earlier version.

Todd Astroth – Proofread the document reworded by Aaron, updated minor details that were changed during course of the class.

RAD Presentation:

Mark Williams

Matt Stowe

Design Document Version 1.0:

Todd Astroth – Wrote Sections 1, 2.1, 3, proofreading and editing

Mark Williams – Wrote Sections 2.2-2.7, Extensive proofreading and editing

Matt Stowe – Created screenshots, Extensive proofreading and editing

Aaron O’Banion – Extensive proofreading and editing

Chris Cobb – Extensive proofreading and editing

Design Document Version 2.0:

Chris Cobb – Rewrote entire document for new design, rewrote test plan (moved to Project Plan Document)

Todd Astroth – Proofread and edited revision by Chris, updated figures/diagrams

Mark Williams – Proofread and edited revision by Chris

Aaron O’Banion – Proofread and edited revision by Chris

Design Presentation:

Todd Astroth

Project Plan Version 1.0:

Todd Astroth – Rewrote and edited (all sections) of Project Plan Document, rewrote problem areas indicated by Dr. Waxman (mainly Testing Plan and Timeline).

Aaron O’Banion – Wrote basic outline of PPD, proofreading and editing of Project Plan Document

Chris Cobb – Designed the plan for the project, proofreading and editing of Project Plan Document, designed test cases

Matt Stowe – Designed the plan for the project, extensive proofreading and editing of Project Plan Document

Mark Williams – Designed the plan for the project, extensive proofreading and editing of Project Plan Document

Project Plan Version 2.0:

Todd Astroth – rewrote problem areas indicated by Dr. Waxman (mainly Testing Plan and Timeline)

Chris Cobb – proofread and edited version revision by Todd, re-rewriting of Testing Plan

Project Plan Presentation:

All team members are responsible for designing and presenting their respective speaking sections of this presentation.

Prototype:

Matt Stowe

Client Contract:

Aaron O’Banion

Chris Cobb

Website:

Chris Cobb

Posters:

Chris Cobb

Final Document:

Todd Astroth

Final Presentation:

Todd Astroth – Designed and compiled presentation. Edited content from previous presentations to put in final

Mark Williams – proofreading and editing

Matt Stowe – proofreading and editing

Aaron O’Banion – proofreading and editing

Chris Cobb – proofreading and editing