a little bit of background info first:
Currently I am extending an IF system (ADL) with vehicles.
So I got to the problem of putting the player object into another object.
Normally the player is only in a ‘room’. So I looked around
to see if there’ll be any problems with the player in a ‘non-room’,
just to find out that this IF system has no rooms, rooms are just normal
objects. So I looked into the DM4 to see how inform6 handles
this: no rooms either, unless I misunderstood completely.
Now to the question:
Are there other systems differentiating rooms and objects?
Or is this a general consensus among IF systems?
And if yes, why?
From time to time I am also working on my own
system and there I thought I’ll differentiate rooms and ‘normal’ objects
in order to facilitate reasoning about movement, scope
and things like that. So I am a bit worried about my design
decision and that it might lead to problems later.
Thanks for any thoughts / hints,
I don’t know, although in Z-machine rooms are normal objects, and in OASYS rooms are normal objects, and in TADS rooms are normal objects. However, it may be possible to still tell the difference by various ways, such as a flag on an object or the range of object numbers assigned to rooms and other things; in OASYS each object has a class (mainly used to determine what words refer to it) which you can check if it is a room or not too. Using this you may be able to reuse property slots for meaning different things in rooms han it does for non-rooms.
The Inform 6 model is that a room is any top-level object – that is, an object not contained in any other object. Furthermore, if I recall correctly, a closed opaque container is also treated as a room if the player is inside it, on the theory that if you can’t see out, it might as well be a room.
This is a clear distinction, just not one based on object class. (And why is it done this way? Because Inform 5 and earlier versions worked that way, and they didn’t have a class structure! Classes were added in Inform 6.)
The I6 model leads to some weird behavior. Most obviously, if you’re in a crate with the door open, that’s a container; but if you close the door, it becomes a room. If your code moves a room into another object, it stops being a room. This is occasionally useful, but not worth the confusion. (The “description” property of a room is used for “look”, but the “description” property of a non-room is used for “examine”. So when an object changes state, it probably behaves wrong anyhow.)
I7 drops the whole mess and defines “room” as a class.
Thanks a lot.
Thanks for the info about OASYS and TADS. For the VM level
I have expected it. Everything gets compiled to general all-purpose
Thanks for the explanation of the I6 model.
The details are explained in DM4 chapter 21 “visibility ceiling”
and in chapter 32 “Scope…” but the consequences are hard
to understand (I completely missed “room = top level object”
So in I7 a “room” is something where the player can be?
Is there a standard way to handle this situation in I7?
I’ll try to find this in the documentation for I7.
In I7 the player can be in a room, or in an enterable container or supporter which is in a room.
If you try to move the player outside of any room, the library gets confused and starts displaying error messages. (So don’t do that.)