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 through multiple computers. In addition, AI students will be able to test their AI modules by loading them into the game as Dynamic Linked Libraries (DLL).

1.2) Design Goals

1.3) Lifecycle

Our lifecycle does not fit any one exact model. During the “Requirements and Design” phase of the project, one part of our team works on requirements while the other begins the design phase. Then, while parts of the team work on the Design Document, other team members begin working on their parts of the prototype. This lifecycle is similar to the Sashimi lifecycle presented in class. 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 subsystems, and each subsystem will be developed in parallel. Finally, after the subsystems come together to produce a working application, the team will use the Evolutionary model to add any extra or optional features that are nice to have in the system.

2.) Proposed System Architecture

2.1) Overview

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

In-Game and Game Board Interfaces

The physical game board will be represented on a screen similar to the one shown below.

In this example, there are two players, each token representing a player. The target goal for each player is marked on each edge of the board with a colored zone. For example, the player controlling the red token will win if he can advance to the red goal opposite where the player started. At the top of the screen is the game menu. A human player can access the help menu, or they can save or 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 dragging a wall into the desired position.

A player’s turn involves either moving a token or placing a wall. To move, a human player clicks on his/her token and drags it to a desired square. Legal token placements will be highlighted during a user turn. If a user selects to place a wall, the wall will appear in the position the user selected. If the wall is not playable at a selected position, the game will indicate this is an illegal placement. After a wall placement or a token movement, the player’s turn is over, and the next player’s turn begins.

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 on the next page.

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

2.2) Persistent Data Management

Data will be stored to a file that will contain the status of a game so that the file may be later read to continue a saved game. 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 following subsystems:

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 placement. This subsystem will interact with the Control subsystem. The moves a user makes will be sent to the Control subsystem from the Interface subsystem. The Control subsystem will send validated moves to the Interface subsystem to be displayed to the user. The Interface layer will also receive moves made by remote players and AI modules from the Control subsystem and display these to the user. The Interface subsystem will interact only with the Control subsystem.

Game:

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

Network:

The Network subsystem will handle the implementation of sending data between games that are played on two or more computers. The game host will wait for players to connect to the game after the user has begun to set up a network game. The Network subsystem of the host will send each client the setup parameters to begin a game (i.e. board size, player information, etc). The Network subsystem of each client will send a player’s moves from the client to the host. The host will send these moves out to each of the other clients (if any) through the Network subsystem. The Network subsystem will interact only with the Control subsystem and other Network subsystems.

AI:

The AI subsystem will handle all functionality in regards to communicating between the Quoridor application and the AI modules. Quoridor will include three AI modules the user can play against, and other AI modules can be developed to interact with the system. The AI subsystem will pass the game state to the AI modules and receive information back from the AI modules on the AI module’s turn. The AI subsystem will send this information to the Control subsystem.

Control:

The Control subsystem will control the flow of communication between all the other subsystems. The Control subsystem will be responsible for determining the current player’s turn. This subsystem will interact with all the other subsystems. This subsystem will pass moves and wall placements to and from the Network subsystem. This subsystem will send the board state to the AI subsystem and receive moves from the AI modules. This system will also send updates to and receive moves from the user interface. It will also send moves and wall placements to the Game subsystem for validation and updates.

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.

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.

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.

2.8) Testing

Each subsystem will be thoroughly unit tested to ensure it is stable and robust by itself. Each subsystem will then be combined with other subsystems and together, integration tested to ensure that the whole system will work as one system.

3.) Glossary

AI (Artificial Intelligence) – refers to an algorithm module 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.

DLL (Dynamic Linked Library) – A file containing function calls to be used in another program.

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.

LAN (Local Area Network) – a group of computers connected within a local area through an internal networking system.

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.

RAM (Random Access Memory) – computer storage space required for program.

read-only – only able to be run, not altered.

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:

Todd Astroth – Sections 1, 2.1, 3, proofreading and editing, grammar check

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

Aaron O’Banion – Extensive proofreading and editing

Chris Cobb – Extensive proofreading and editing

Matt Stowe – Screen Shots, Extensive proofreading and editing

Prototype:

Matt Stowe

Website and Poster:

Chris Cobb

Presentation:

Todd Astroth

Contract:

Aaron O’Banion

Chris Cobb