[Reality] Exits

[Jp Calderone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 17 Jun 2002, Christopher Armstrong wrote:

>
> Here's the use case: we need to be able to have a ship (which is made of
> multiple rooms) enter a spaceport entirely and make its entrances available to
> people in the spaceport. The ship may have multiple entrances: one for the
> cockpit and one for the cargo bay, f.e.

  Other things that come to mind - temporary or permanant enclosures, such
as a tent Thing that could be carried around and then unpacked, set up,
and entered; ground vehicles; or "scenery" such as an oil drum.

>
> Two concepts here:
>   1) collection of rooms. We probable need an "Area" class or something.
>   2) "entrances". We need areas (or perhaps any object with an 'entrances'
>      attribute?) to be able to expose them to their current location.
>
> So here's what dash, exarkun, and I came up with:
>
>   We'll have an Area class. Probably every room will have a reference to the
>   area its in. Any exits that are created in a room 'bob' that lead to
>   'bob.area' (or perhaps a special constant OUTSIDE, which I think is more
>   readable) will send the player to bob.area.location. So, that was the easy
>   part: regular exits. Entrances will be similar, but instead of *leading* to
>   bob.area (or OUTSIDE), their *source* will be bob.area. This assumes two
>   things: that we have first class Exit objects that have both "source" and
>   "dest" properties, and that there is a hook bound to creating exits in a room
>   that checks whether or not exit.source == room.area. If it is, then add the
>   Exit object to areaObj.entrances.
>
>   So that's entrances and exits. Making the entrances available to
>   area.location would take nothing more than a hook inserted into the
>   "movement" event, to the new location to update its exits list.
>
> OK, so this doesn't seem like a very robust solution after some consideration
> (at least that entrances bit, anyway) - f.e., what happens if you change the
> source of the Exit object after it's created?
>
> Hrm, then again, we could just make the special Area-checking part of the Exit
> class, so that's no worry (i.e., add a set_source method that checks whether
> source is an area object, if it is, tell it to update its entrances).

  Yea, movement hooks would do most of it, then exit can track the rest.
Area should have an interface for adding/removing these exits (as well as
getting a list of them, of course).

  It would be nice if this didn't break the existing exit code.  I guess
these types of exits would only be accessable via a new ability?
Enter/leave or something like that.  Could this be folded into the
existing interface on Thing, perhaps with an option "of" or "on" parameter
to findDirection() that defaults to None?  Or maybe it makes sense to do
the access in a new method..

  Jp

- --
If the automobile had followed the same development as the computer, a
Rolls-Royce would today cost $100, get a million miles per per gallon,
and explode once a year killing everyone inside.
                -- Robert Cringely, InfoWorld
- --
 11:53am up 27 days, 12:35, 4 users, load average: 0.00, 0.00, 0.00

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

iD8DBQE9Dg4wedcO2BJA+4YRAma6AJ9cBvUeZlaaK1hvCSuMKCBYiZwHYgCgi1F2
HBS8EDjB04vm88ZN/CU010o=
=HUJm
-----END PGP SIGNATURE-----