Initial revision of cocktail multiplayer networked gaming platform. (Far

from complete.)


git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2 542714f4-19e9-0310-aa3c-eee0fc999fb1

docs/design.txt

@@ -0,0 +1,55 @@
+Cocktail Mk3 -*- 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.