(LOGO HERE)

Requirements Analysis Document

Version 1.0

Group 1 - Quoridor

Todd Astroth

Chris Cobb

Matt Stowe

Mark Williams

Aaron O’Banion

Table of Contents

1.) Introduction – Pg. 3

2.) Current System – Pg. 3

3.) Functional Requirements – Pg. 3

4.) Nonfunctional Requirements – Pg. 7

4.1) User interface and human factors

4.2) Documentation

4.3) Performance characteristics

4.4) Error handling and extreme conditions

4.5) Physical environment and resources

5.) Optional Features – Pg. 8

6.) System models – Pg. 9

6.1) Scenarios – Pg. 9

6.2) Flow diagram – Pg. 12

7.) Glossary – Pg. 13

8.) Contributions – Pg. 14

1.) Introduction

The purpose of our project is to create and develop a computer program that hosts a game of Quoridor on a single computer or over a Local Area Network (LAN). The project will be facilitated by our client, Mr. Steve Klein.

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 gameplay will be mentioned later in this document.

The program will have three different Artificial Intelligence (AI) scripts and also the ability to host four players at one time or any combination of AI scripts or players. These AI’s will be written in the form of Dynamically Linked Libraries (DLL’s) that can be loaded into the game via the user interface. This gives AI students a good chance to test their modules.

In this project, we will be removing some of the current rules and adding some different ones that do not exist in the original game. The basic strategy of the game does not change in our project, rather just some of the optional rules.

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 actions and thus reducing ambiguity.

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.

It should be noted that due to copyright purposes, we will only allow permitted users to use our program. Also, of these users, if one user is playing another over a LAN (using two computers), one will have to be designated as a “host,” which will make the other a “client.” The host will have the ability to set up the game from his point of view.

Game Start

Once a permitted host launches the game, it will prompt him 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 clicks on “Continue 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 “Join a Host” is selected, the user will then type in the IP address and port number of the host computer.

If the player 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. The options include:

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

4the number of walls each player starts with (user can specify limited or unlimited);

4the time that the game will last (user can specify a numerical limit or no limit);

4the token graphic to be used (chosen from a selection of pictures, or he may upload his own – but the tokens must be distinct).

Then the host selects the status of each player. For up to 4 players, the following choices may be made: 1.) Human Host; 2.) Human Client; 3.) AI Host; 4.) AI Client. 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 1). By default, the game will randomly choose a player to start the game. This option may be changed by the host if players wish to begin at their choosing.

Player 2

Player 1

Figure 1

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 (in selected order) continues this procedure, and so on. The player may choose any space on his edge of the board to move to when he moves on. Once on the board, however, he may NOT move off the board except on the opposite site (to win).

Option 1: Move Token

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

In the case that there is a token in the way of the player, the player’s token can “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 3).

Figure 2

Illegal moves

Figure 3

Examples of moves and “jumps” over tokens (for red, blue, and black)

Option 2: Place Wall

A player may place a wall anywhere on the board, on the grooves, and blocking exactly two spaces. The walls do not block in any other fashion. Also, walls may not overlap, or cross. And finally, a player may NOT place walls in such a manner that an opponent player will have no way to get to the other side of the board (see figure 4).

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 from his inventory onto the board. Diagonal placement and placement off the grooves will not be an issue – the program automatically jumps from groove to groove. Wall placements that cross other walls or prevent a player from reaching the other side will highlight the wall placement red. This means the wall can not be placed in that location.

Figure 4

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 pawn. At this point the game ends and the player is given the choice to play another 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) User interface and human factors

Our user interface will be designed using Microsoft Visual Basic. The board will be represented visually on the screen with the status of players on the sides. Each player will be able to see whose turn it is and each player’s number of walls. The current player’s turn will be denoted by a highlighting or outlining of their edge of the screen containing their information. Also included are the start screens, which help guide the player through the game setup.

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 or manager to provide feedback or suggestions for improvements. Our client specified that our project would not be commercially distributed upon its completion, so the documentation needn’t be further updated post-mortem.

4.3) Performance characteristics

The system will be able to operate over a LAN with the backend of the system being Visual Basic. It is expected that the live players will receive feedback from the opponent players with little time delay. The only delay should be the time to ponder moves and strategies.

4.4) Error handling and extreme conditions

Visual Basic will perform various tests to determine infinite loops or how to handle errors. Most errors, as mentioned in the functional requirements, will be prevented by constraining the freedom of actions on the user interface. Besides errors due to external sources (such as hardware, networks, etc.), foreseeable errors include: AI’s stuck in repeating patterns; two or more picture files containing the same filename or image; and no executable options on a player’s turn but to pass (no more walls to place or no place to play walls, and nowhere to move – see figure 5).

4.5) Physical environment and resources

The computers must include a mouse, monitor, and some RAM. Most newer models will be equipped with these features. If a player wishes to play an opponent on another computer, the computers must also be connected to a local network. The final product will be a read-only executable program, as not to have the structure changed.

Red Goal

Drawing modified due to transformation to HTML. See RADV1 for unmodified drawing

			Green Goal

Figure 5

An unlikely, but possible deadlock situation for Blue

Blue Goal

5.) Optional Features

The following is a list of features for our project that are extra, but not absolutely necessary. Unless otherwise later noted, due to time constraints, these features will be included.

4Game Logs – Keep a text record of all the moves played during a game by all players.

4AI Upload – A person can create and test their own AI program against another player by uploading their AI system as a DLL into the game.

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

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

6.) System Models

6.1) Scenarios

Scenario Name: Start_1-livePlayer_Vs_1-AI_game

Actors: Brad – average everyday game player

Flow of Events:

1. Brad opens Quoridor on computer.

2. Brad selects “New Game.”

3. Brad selects “Human Host” on Player 1.

4. Brad selects “AI Host” on Player 2.

5. Brad finds and selects the file location of an AI dll 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: Drake – computer AI prodigy (host)

Brad – average everyday game player (client)

Flow of Events:

1. Drake opens Quoridor on computer.

2. Drake 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 Drake’s computer.

6. Drake selects “Human Host” on Player 1.

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

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

9. Drake 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 – computer AI prodigy

Flow of Events:

1. Drake opens Quoridor on computer.

2. Drake selects “New Game.”

3. Drake selects “Host AI” on Player 1.

4. Drake finds and selects the file location of one of his AI dll’s 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 – average everyday game 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 – average everyday game 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 place he selects is highlighted red – He can’t place a wall there.

5. Brad drags the wall to a different location and releases button.

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 – computer AI prodigy (host)

Brad – average everyday game 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: EndGameEarly

Actors: Zak – average player who is very tired

Flow of Events:

1. Zak wishes to stop the current game.

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

3. Zak clicks “End Game.”

4. A dialog box appears that says “Are you sure you wish to quit?”

5. Zak clicks “Yes.”

6. The game is terminated for Zak (Zak does not win).

Scenario Name: SuspendGame

Actors: Kaz – average player who is very tired

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.) 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 or rectangular 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 a program pattern 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.

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

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.

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.

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.

8.) Contributions

RAD:

Todd Astroth – Functional Requirements, Non-Functional Requirements, Optional Features, System Models, Glossary

Chris Cobb – Visual board design and layout

Matt Stowe – Ideas for structure and flow of gameplay

Mark Williams – structured design of RAD

Aaron O’Banion – Introduction, Current System, Functional Requirements

Website:

Chris Cobb

Presentation:

Aaron O’Banion