Michael Bayne
a372ebd342
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@66 542714f4-19e9-0310-aa3c-eee0fc999fb1
56 lines
3.0 KiB
Plaintext
56 lines
3.0 KiB
Plaintext
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.
|