Tsuro.Com, a Plan
Goal
The goal is to develop a gaming framework for running Tsuro tournaments for "AI" players running on remote computers.
Let the best hacker win, and we cash in on it.
A tournament will pitch players against other players in several rounds, including knock-out rounds. Each game is supervised by a "referee" to ensure compliance with the rules. A rule-breaking or non-responsive player is immediately eliminated from the tournament.
Software Components
- A player interface to which the creators of external players program. The player interface must spell out all phases of Tsuro:
how to place an initial tile and colored token on the board;
how to take turns, i.e., the information a player needs to compute a turn and the information it uses to request an action;
how/whether to receive information about the end of a game.
As we work out this complex interface specification, we may need to develop additional concepts. Our team should implement at least one player to validate the interface.
A referee must supervise a game of players; it may assume nothing about players but the existing interface, that is, all interactions between referee and player components go through this interface.
The software framework needs components that represent the physical game pieces:
tiles and their internal graph
colored tokens, which belong to a specific player
boards with the desired number of separate squares
Together with the player interface these pieces make up the common ontology that players and referees use to communicate.
For dealing with rounds of games, we will need to build a tournament manager that runs rounds of games. The creator of the administrator must know the interface of referees and players; its contact with players should be limited to signing them up and connecting them to a referee for a game.
The human operators of the referees and players may wish to observe Tsuro games. To implement such viewings, we may need observer components for the players, the referees, or even the administrators.
Building It
Our build plan consists of two phases.
The goal of the first phase is to build a complete prototype in one language that we can demo for our angel investors.
The goal of the second phase is to break up this monolithic prototype so that we can connect the administrator to remote players. We will then be able to demonstrate this to our investors as the alpha release of our product.
the basic game pieces, tiles and colored tokes, because the player and the referee must use the exact same representation;
the game board;
the player interface;
the referee and the player;
a tournament manager.
For the second phase, we will use the remote proxy pattern to go from the monolithic prototype system to the distributed version. This will require the construction of
a remote proxy player
a remote proxy server
a communication layer (TCP for now; perhaps UDP for speed, HTML for web access).