The Components🔗

Assumptions🔗

The development of a Bazaar game management system rests on two assumptions. First, our company will run the server software on its rented machines. Second, the participants—our customers—will run their own “AI” players on their own computers. That is, the game management system and the players will connect over the ’net.

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.

Software Components🔗

Functional Requirements

The software system must address three major aspects: the game logic of Bazaar, 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 Bazaar suggests the following software components for the game logic:

a player-referee interface to which the creators of external players program

The player interface must spell out all phases of Bazaar: 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 a 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 the game pieces. It interacts with the players according to the interface. 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 integration-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 so that bazaar.com can sell ads while people watch in sports bars

Finally, the game logic calls for data representations of the basic game pieces: the equations, the bank, the player’s pebbles, and so on.

These game pieces make up the common (logical) ontology that players and referees use to communicate over the player interface.

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.

Non-functional Requirement

Neither interactions with players nor observers may bring down the system of servers and referees. The server and the referee represents essential components; the players and the observers are inessential ones.