[Reality] Exits

[Glyph Lefkowitz]

----Security_Multipart(Tue_Jun_18_02:56:02_2002_435)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From: David Sturgis <dave@dcit.com>
Subject: Re: [Reality] Exits
Date: Mon, 17 Jun 2002 13:00:39 -0500

The legend returns :-)

> One idea that had been the source of much consternation in the original Java
> Reality was the idea of a room/container/location type thing that wasn't
> immediately obvious... If something was sitting in the bottom of an oil drum,
> it probably shouldn't be immediately obvious to people in the room (unless
> they implicity examine/look at/climb into the drum).

> Did we ever find a decent way to handle this in python Reality? A lot of the
> objects being described here (tents, etc.) are the sort of things that you'd
> probably have to look into (or at least focus on more directly) to see inside
> of.

These are slightly different concerns, although you're right in thinking they'd
be essentially the same class of objects.  One is the way of limiting
propogated information from containers to their surroundings.  I am pretty sure
we've got a good set of "special" characteristics of objects in the Python TR
which effectively limit propogation.  The one additional thing necessary on
this front is separating aggregation of broadcast targets and target handling.
(Your perspective should be able to decide whether you're really supposed to
get an event, as well as the object broadcasting the event ought to be able to
decide whether your perspective should receive it.)

The other problem is that you have to be able to control where people are going
when they move.  This sounds like yet *another* problem that will be solved by
the intent/action dispatch separation that I described in a previous email.  If
you knew "the player wants to moveTo(string [, object])", you could have the
room and the target object decide what to do with that, in order.

Then there's the issue of how to get the exits from a room.  My initial feeling
is that there should be some more general mechanism for retrieving a hierarchy
of the room, and getting state updates for it -- parallel simulations on the
client & server, a-la Beyond, rather than a client that simply responds to
"update" events -- but I haven't done enough thought on this to say exactly
how.

> And it's really cool to hear people talking about Reality stuff again.  ;-)  

Glad you think so.  It's certainly cool to hear _you_ talking about it ;-)

> The spaceship and docking system is interesting... I had a similar idea for
> ships (i.e. the floating on water kind) and docks, but I had never figured
> out a good way for handling perspective from the boat at sea... You'd have to
> do some weird things to the descriptions of all the rooms on the deck, sort
> of the interactive text equivalent of a skybox in a 3D engine, to reflect the
> weather and other nearby objects (other boats, disgruntled albino whales,
> islands, etc.). With spacecraft, you usually have a more appliance-like
> screen/monitor/periscope device that you implicity look into to see what's
> going on outside.

Hmm.  What's a "skybox"?  This sounds really cool.

-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer   |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |

----Security_Multipart(Tue_Jun_18_02:56:02_2002_435)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9DueUvVGR4uSOE2wRAkYbAKCCTT5SBpsz1TIm46YbXIWHmmfT0wCfYaqs
fMFZUWBs8rTOFyFHaBZUeWI=
=NmFU
-----END PGP SIGNATURE-----

----Security_Multipart(Tue_Jun_18_02:56:02_2002_435)----