Michael Bayne
c66efeb511
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2236 542714f4-19e9-0310-aa3c-eee0fc999fb1
68 lines
3.1 KiB
Plaintext
68 lines
3.1 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.
|
|
|
|
* Zone Management
|
|
The scene universe can be divided into zones.
|
|
|
|
Zones contain a set of scenes and are traversed by a special mechanism
|
|
(separate from scene to scene traversal).
|
|
|
|
Zones provide scene summary for the scenes in the zone which can be used
|
|
on the client to generate a map of the zone.
|
|
|
|
Zones are identified by an integer of which the upper 8 bits is a zone
|
|
type identifier and the lower 24 bits are the zone identifier.
|
|
|
|
* 1/28/2003
|
|
** Spot revamp
|
|
- Eliminate locations
|
|
- Dynamically create clusters around stationary scene occupants
|
|
- "Station" objects will have an associated location at which a scene
|
|
occupant would stand rather than being associated with a location
|