The development of a Maze game management 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.
Additionally, our company may inject “house players” to even the odds; it may add visualization components so that it can observe the games; and it may eventually add a protocol for external observers to generate advertisement dollars.
The software system must address three major aspects: the game logic of Maze, 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 material accessible to middlers.
The description of Maze 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 Maze: how to set up players initially; how to take turns; and how/whether to receive information about the end of a game. Given the goal, this must be formulated in both logical terms and eventually in terms of communication layer.
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 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.
observers for game activities
Finally, the game logic calls for data representations of the basic game pieces: the tiles; the treasures; the board; plus the players’ castles and avatars.
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 a game 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 communication-layer aspects of the server-client communication for the player components.
Neither interactions with players nor observers may bring down the system.