Final Presentation – CS 425 Aaron O'Banion Todd Astroth Chris Cobb Matt Stowe Mark Williams

Team Quoridor Mission Statement  Our project is to produce a software version of the board game Quoridor  With network support  With some AI components

Quoridor Basics  2-4 Players  6x6 to 12x12 square grid  Variable number of blocking walls for each player Objective: First player to reach opposite side wins

Quoridor Rules  Tokens can only be moved to spaces not blocked by walls  Walls must never block any player from finishing the game

End Users  Primarily Professor Klein and his players  Students and teachers of AI course  Anyone that wants to play the game that understands all the rules.

Functional Requirements  Variable board size  Number of walls each player starts with  Start zones and Goal zones of each player  Wall placement and Movement constraints  The logs for keeping track of the moves  Ability to play over a network  Ability to play three built-in AI’s  Ability to plug in AI modules

Non-Functional Requirements  Run on Windows  Documentation  User Manual  Timely gameplay

Optional Features  More competitive AI’s  Token Image upload  Time clock  Interactive help box explaining why a desired illegal move is illegal

Design Goals To provide an entertaining and enjoyable game-playing experience. To provide an easy-to-use and aesthetically pleasing interface. To allow players to compete remotely using a network. To allow AI’s to be inserted into Quoridor

The Quoridor Lifecycle Model

Phase 1: InterfaceGame  User Interface  Hotseat gameplay (one computer)  Gameplay constraints Phase 1: Game Functionality

 Gameplay over a network  Server and Clients Phase 2: Networking Phase 2: Interface Client Game Remote Interface Server Client Host Client

 Allow users to plug in AI’s  Include three sample AI’s Phase 3: Inserting AI’s Phase 3: Interface Client AI Game Remote Interface Server Client Host Client

Major Subsystems  Interface  Game  Client  Server  Artificial Intelligence

Interface Subsystem  User interaction  Collect information from user  Allows input of wall placement / token movement  Sends moves to Client  Updates board state using information received from Client

Game Subsystem  Stores the current board state  Validates moves / wall placements and sends results to Server  Receives parameters of game setup from Server

networking Subsystems  Client  Connects to the Server through sockets (BSD)  Gateway for moves between Server and Interface  Represents a player  Server  Compiles and stores settings in Game subsystem  Receives moves from Clients and AI’s, validates moves using Game subsystem, and sends validation back to client

AI Subsystem  AI’s can be created and inserted into the system  We will provide a C++ header file that allows connection of modules to Quoridor  Receives current board state from Server  Passes AI’s moves to Server  If illegal moves are received by Server, Server will discontinue AI, and that player loses the game

User Interface Mockups  Three Major Screens: Title screen Player Setup screen Gameplay screen (game board)

Player Setup Screen  Three player types: Local user AI player Remote user  Host controls setup  All settings and options are configured before the game starts Sample setup screen

Game Board  The target goal is indicated for each player by their token color  Advance token by clicking a space –Legal moves are highlighted on board  Place a wall by clicking a groove –Legal wall placements are indicated in yellow  Player starting locations: 1↓, 2↑, 3←, 4→ Sample game board

Persistent Data  We will allow a game in progress to be saved and continued at a later time  Data to store in a text file: –Setup information –Player information –Current Game state

Next Semester Timeline Phase 1 (Hotseat) Phase 2 (Networking) Phase 3 (AI’s)

Team Organization Steve Klein Main client Bernard Waxman Upper Management

Risk Management  Backtracking Difficulty  Acceptance Issues  Late Finish  Feature Creep  Network Difficulties  AI Functionality

System Testing Plan Interface Stand-Alone without Validation  Interface Stand-Alone with Validation  Network Connection  Server to 1 Client  Server to Many Clients  Integration  AI Integration

Alterations to the System  Baselines  Proposing a Change  Investigating a Proposed Change  Change Management Board  Implementing a Change

Team Training Plan  Internal Training  Visual Basic  Socket Programming (VB)  AI Modules (C++)  External Training  User Manual  Help Menu

Installation and Operation Plan  Installation –Responsibility First Copy – Us Rest – Client –Before April 25 th  Operation –Before final Installation - Quoridor Team –After final Installation - Client

AND NOW, the Prototype… Quoridor Prototype