1. Design Document Presentation

2. Review Quoridor – a board game played on a grid where players must advance tokens across a board to win. Our basic objective: Implement a computerized version of Quoridor.

3. Overview Design Goals Our Lifecycle Model User Interfaces Persistent Data Subsystems Hardware/Software Mapping Other design factors

4. Design Goals To provide an entertaining and enjoyable game- playing experience. To simplify the gameplay of the board game Quoridor. To provide an easy-to-use and aesthetically pleasing interface. To allow AI students to test their Quoridor AI modules. To allow players to compete remotely using multiple computers.

5. The Quoridor Lifecycle Model

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

7. Player Setup Screen  Three player types:  Local user  AI player  Remote user  Local User, or “Host” or controls setup  All settings and options are configured before the game starts.

9. Game Board Token = Player The target goal is indicated for each player by their token color (or pattern) Advance token by clicking and dragging –Legal moves are highlighted on board Place a wall by clicking wall and dragging onto board –If placement is illegal, wall will blink red, and game will not continue until placed properly

11. Major Subsystems Game ControlAI Network Interface

12. Interface Subsystem  User interaction  Collect information from user  Allows input of wall placement / token movement  Sends moves to Control subsystem  Receives moves from Control subsystem (from AI and/or remote players)

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

14. Network Subsystem  Handles details regarding play between multiple computers  The Host’s Network Subsystem sends out gameplay startup parameters to other computers  Each Client sends moves to the Host on their turn, then the Host sends the moves to all Clients

15. AI Subsystem  Handles all AI functionality  Game state is passed between Control and AI  AI’s can be created and inserted into the system  Our program will include 3 sample AI’s

16. Control Subsystem  Communication Hub  Determines current player’s turn  Passes moves/wall placements between Network subsystem  Passes board state to AI modules  Get moves from User Interface  Send moves to Game subsystem for validation

17. Hardware/Software Mapping Players may be on the same computer or on different computers For a game with multiple computers: –“network game” –“Host” sets up game –“Clients” connect to the Host instance

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

19. Hardware/Software Mapping

20. Any questions?