Cocktail -*- outline -*-

* What is it?
Cocktail is a platform on which multiplayer networked games may be
developed. The platform is (extremely) loosely based around the idea of a
cocktail party. For the most part, this just gives us a useful context
from which to choose names. The basic service of the Cocktail platform is
a simple information sharing mechanism based on the concept of distributed
objects. This layer is called "Cher" for reasons outlined in the Cher
design notes.

A distributed object has a set of subscribers. Whenever a modification is
made to that object, all of that object's subscribers are notified. This
has the beneficial effect of providing a framework in which to conceive a
distributed application based on who needs to know what. If information
need be shared among a set of clients, a distributed object can be created
to represent that information and those clients would subscribe. Then
modifications to that object (as well as simple notifications) can be
easily delivered to those clients and those clients only.

As one discovers after further use of the system, the distributed object
concept turns out to be a useful one for other reasons when designing
distributed applications (a subset of which are multiplayer networked
games). The distributed objects fit nicely as the model in the model,
view, controller pattern as well as into other useful patterns.

The primary value of the design is to bring the level of abstraction up
from network connections and packets, to objects and events.

** Getting the party started
Atop the distributed object layer, we further develop the concept of the
cocktail party. Parties tend to take place in rooms and be attended by
groups of people. This is the essence of the next layer of the system: a
framework for providing rooms, with occupants and mechanisms for the
people to move between those rooms. Within the rooms, we provide some
useful basic services like the ability to chat among the occupants of the
room, as well as some non-room-specific facilities like person to person
messaging from anywhere in the system and a location directory.

Not all games developed with the platform will want to use the room
concept, therefore we attempt at this layer and in all subsequent layers
to decouple our services as much as possible. This allows a game with
special needs or for whom our half-baked analogies don't apply, to
leverage some of the useful services without having to bend their design
in uncomfortable ways or hack up some additional interface to the services
we provide.

** Let's play
From here, we branch off into all sorts of interesting directions based on
the different kinds of games that are implemented with the system. We
provide matchmaking lobbies, an extension of the room concept to the game
room, on top of which is provided a framework for managing generic
turn-based games, and various other useful services. Again the philosophy
is to provide consistently designed, but decoupled services that can be
used within and along side whatever design works best for your game.