Michael Bayne
543f977475
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@367 542714f4-19e9-0310-aa3c-eee0fc999fb1
49 lines
2.3 KiB
Plaintext
49 lines
2.3 KiB
Plaintext
Whirled Design -*- mode: outline -*-
|
|
|
|
* Overview
|
|
Whirled builds on top of the Cocktail platform and provides a framework
|
|
for building a virtual world made up of a node network of individual
|
|
scenes. In the abstract, scenes contain only exits to other scenes and the
|
|
world is one big directed graph. This is not unlike the structure of MUDs
|
|
where one classically thinks of rooms and exits. We've chosen the term
|
|
scene to avoid implying that we're indoors.
|
|
|
|
Whirled provides a means by which clients can move from scene to scene,
|
|
and to different locations within the scene (though restricting clients to
|
|
movement only to a pre-defined list of locations within the scene is
|
|
optional).
|
|
|
|
The scene information needed by the client may differ from that needed by
|
|
the server. Specifically, the server may need only know about exits to
|
|
other scenes, whereas the client will need to know how to render a scene
|
|
which may involve substantially more information (tile lists for top-down
|
|
and isometric renderings or a 3D scene model). To this end, Whirled
|
|
provides services for building static scene bundles that can be included
|
|
with the client and then updated over the wire if the client enters a
|
|
particular scene and needs updated scene information. Using these
|
|
services, the world can change and evolve and the client can be sure to
|
|
always have the correct scene information. Excessive downloading can be
|
|
avoided by seeding the client's scene database with a snapshot of the
|
|
system at the time the client is delivered, and subsequent snapshots can
|
|
be provided periodically to bring all clients into sync with the runtime
|
|
scene database, from which they can then continue to mirror updates as
|
|
needed.
|
|
|
|
* Notes
|
|
Scene provider needs to do the right thing when a client requests an out
|
|
of date scene. Presently it doesn't handle sending the client the updated
|
|
scene data.
|
|
|
|
Scene manager registers a timer when it becomes empty and flushes itself
|
|
from memory after timeout period.
|
|
|
|
Client should avoid unsubscribing from scene objects straight away so that
|
|
it can avoid resubscribing if they bounce back and forth between scenes.
|
|
|
|
We'll want the scenes to adhere to some sort of hierarchy so that we can
|
|
associate properties files with classes of scenes which will be used to
|
|
configure the scene managers when they are initialized.
|
|
|
|
Add code to flush scenes from the client scene manager cache.
|
|
|