Trains.Com, a Plan
Assumptions
The development of a Trains tournament system rests on two assumptions. First, our company will run the server software on its (rented or owned) machines. Second, the participants (our customers) will run their own "AI" players, which run on the participants’ remote computers. Our company will also inject "house players" to even the odds. Additionally, our company will add visualization components so that it can observe the games and tournaments; it may eventually add external observers to generate advertisement dollars.
Functional Requirements
Software Components
The software system must address three principal aspects: the game logic of Trains, the communication layer, and (if it ever were to reach a certain size) a database. This course ignores the database components to reduce the prerequisite requirements and make the course accessible to middlers.
The description of Trains suggests the following software components for the game logic:
a player-referee interface (protocol) to which the creators of external players program
The player interface must spell out all phases of Trains: how to set up players initially; how to take turns; and how/whether to receive information about the end of a game and tournament. Given the goal, this must be formulated in both logical and communication terms.
a referee supervises an individual game after being handed a number of players
the referee sets up the players with a map and game pieces. It interacts with the players according to the interface protocol. It eliminates a player that cheats or otherwise misbehaves. When the game is over, it reports a ranking of all surviving players of the final game. During the game the referee may need to inform game observers of on-going actions.
a player implementation to validate the interface
Without some sample player, it is impossible to test the logic of the system or its communication behavior. The company is also considering running house players against the participants’ players.
a tournament manager that runs rounds of games
For dealing with an entire tournament of games, we will need to build a tournament manager. Its task is to assign players to games, create referees to run games, collect tournament statistics, inform tournament observers of on-going actions and players of the outcome of the tournament.
observers for games and tournament activities
Finally, the game logic calls for data representations of the basic game pieces: maps, segmented connections, colored cards, rails, cards, and destinations.
The player interface and these game pieces make up the common (logical) ontology that players and referees use to communicate.
Beyond the game logic, the system will also need a server component for dealing with remote-player communications. These components will be based on the logical interfaces. At the moment, we anticipate the use of JSON messages over TCP for the actual communication between the server and the clients.
The server will perform the communication-sign-ups for remote players but will leave the logical-sign-up to the tournament manager. You may wish to think of the communication sign-up as a “registration” step, which may result in actually being signed up or ending up on a wait list.
We will also develop clients that implement the ``physical'' communication-layer aspects of the server-client communication for the player components.
Non-functional Requirement
Neither interactions with players nor observers may bring down the system.
Building It
Our build plan consists of three phases, each yielding a prototype that illustrates the basics of our eventual product. The first two phases concern the logic, the last one with communication.
The goal of the first phase is to build a complete game implementation, including game observers and possibly GUI-based players. This phase will thus implement the core of the system, including house players.
the basic game pieces;
a rule checker, needed by the referee and possibly by the player;
the player interface and basic implementations; and
the referee.
Once we have a player interface, we could ask some early adopters to write an implementation in our language or we could outsource the task to a separate company.
The goal of the second phase is to construct the tournament management system, still in our chosen language. At this point, the company can demo the entire product on a single computer. Constructing this complete system in one language should allow us to debug the logic layer in a systematic manner, without interference from bugs in the communication layer.
The goal of the third and final phase is to break up this monolithic prototype into server and client pieces. The server will sign up clients and employ the manager to run tournaments. The client will connect the existing player components to the server. For this step, we will use the remote proxy pattern to "splice" in communication components and separate the logical components. If we have debugged the logic well enough, any bugs that show up now are mostly likely to be in the communication components.
At this point, we can demonstrate this system to our investors as the alpha release of our product.
Warning Like with all software projects, the co-CEOS may have to adapt this plan as experimentation with the prototypes suggests changes.