The purpose of this project is to create a computer game based on the board game Quoridor. Players of the game will be able to compete against each other on one computer or over multiple computers. In addition, AI students will be able to test their AI modules by loading them into the game.

1.2) Design Goals

1.3) Lifecycle

The Quoridor Model (Figure 1.3) 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. In the first phase, we will complete all functionality required to play a complete hotseat game. In the second phase, we will add all networking functionality to be able to play on multiple computers. And finally, in the last phase, we will add AI functionality so that AI modules may be inserted.

2.) Proposed System Architecture

2.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.

2.1.1 In-Game and Game Board Interfaces

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

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

As figure 2.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.

2.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 2.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 2.1.2 - Player Setup Screenshot

2.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.

2.3) Subsystem Decomposition

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

Figure 2.3 - Subsystems in Quoridor

2.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.

2.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.

2.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.

2.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.

2.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.

2.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 2.4.

Figure 2.4 - Clients connecting to the Server

2.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.

2.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.

2.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.

2.8) Testing

Our program will be tested at various times during the course of the project. We will test the Interface subsystem separately first. This test will not include any validation of legal game moves. Then, we will test the interface with the game validation included. Then, we will test the modules in groups for each phase in the project. Once module groups have been tested, the system will be tested as a whole with all subsystems. Finally, the system will be tested wholly again, but at the site of the client. A more detailed explanation of our testing plan can be found in Section 4 of the Project Plan Document.

3.) 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.

4.) Contributions

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

Aaron O’Banion – Extensive proofreading and editing

Chris Cobb – Extensive proofreading and editing

Matt Stowe – Created screenshots, 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

Design Poster:

Chris Cobb

Website:

Chris Cobb

Prototype:

Matt Stowe

Client Contract:

Aaron O’Banion

Chris Cobb