Michael Bayne
d35f2894c1
manner of happiness and joy). git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@615 542714f4-19e9-0310-aa3c-eee0fc999fb1
49 lines
2.4 KiB
Plaintext
49 lines
2.4 KiB
Plaintext
Whirled Design -*- mode: outline -*-
|
|
|
|
* Overview
|
|
Whirled builds on top of the Presents and Crowd packages 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 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.
|
|
|
|
We need some mechanism for the scene registry to know which SceneManager
|
|
derived class to instantiate. Probably something like
|
|
Scene.getManagerClassName() which can be implemented by an application
|
|
when it creates its Scene implementation.
|