Remote Game Design Notes

Charter Statement

To design a game playing framework that will allow players to find or schedule a game and an opponent over the internet. The framework should ultimately support multiple games with multiple players although it will be focussed much more tightly than that initially. It should not assume there will be enough players waiting for a game to be able to link someone up quickly. Consequently it should provide support for scheduling games between interested parties. This could include messenging support and even ultimately some kind of ranking. Here is an initial cut at a release sequence:

  1. Latrunculi variants only
  2. Any compatible two player board game
  3. Autoranking
  4. Addition of spectators
  5. Multiplayer games

Proposed RMI Pattern

This pattern is a variant of the remote calculator demonstrated in the link Fundamentals of RMI and (elaborated on slightly in mpbl's RMI Tips)

Here is the class diagram for the calculator.

 

Here is a full duplex version of the above pattern with the language adapted for gaming so that the client becaomes a player and the server has a gaming framework.

Both class diagrams reflects the relationships once full communications has been established and the skeletons and stubs are in place.

The interface is classic Model-View (Observer) using callbacks. It focuses purely on the problem of finding a game and an opponent, not on playing the game. Even so, the interface proposed is quite preliminary. However, one design decision is clear: because the communications channel is over the internet the single callback proposed so far, getListChange(), reports only changes. While this distribution of responsibility lowers bandwidth (and more important, latency problems) it puts a lot more onus on both ends. Player objects have to maintain their own copy of the list while the framework has to keep track of what changes it has sent out to whom.

Since quite a lot of information will be required in the list (e.g., potential opponents, games they are interested in, times they are available, expertise rating), it requires a separate interface of its own, ListChange().

Technological Risk

As the class diagram shows, it is anticipated that the client will be an applet, while the server (and the registry, represented here by the java.rmi.Naming class) will run as separate applications on the server. This schema has not been tested and thus constitutes a technological risk. Not because it can't be done but because I don't know if it can be done/how exactly to do it. Thus, a preliminary version of the schema must be hoisted as soon as possible