Containers as Rooms in Inform

5 views
Skip to first unread message

Daryl McCullough

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

I have been fooling around with the Inform and I had a difficult
time programming an automobile. The problem is that a car is
simultaneously two different things: a container, and a room.
I know that declaring an object to be "enterable" is supposed to
allow the player to enter it and exit it, but I didn't like the
results. The problem is that I want the interior of the car to
have a room description of its own. But it can't be an ordinary
room, because it can move around. And like a container, it should
be possible to put things into it and take things out of it.

The solution I hit upon was very complicated. I created a separate
room called "InsideCar" and *also* made an object called "Car" that
was a container (and enterable). I coded things so that entering "Car"
transported you automatically to the room "InsideCar", and exiting
"InsideCar" automatically transported you to the outside of "Car".
(Of course, there was a bunch of scope tricks needed so that you
could look out the window of "InsideCar" and see the surroundings of
"Car".)

Is there a better way to do this?

Daryl McCullough
CoGenTex, Inc.
Ithaca, NY

Julian Arnold

unread,
Jan 29, 1997, 3:00:00 AM1/29/97
to

In article <32EE21...@cogentex.com>, Daryl McCullough
<URL:mailto:da...@cogentex.com> wrote:
>
> [How to code a car]

This is what I did a while ago, and although it does require a fair
amount of code, the results are quite effective. Unfortunately my code
is now wiped.

Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me
from ever completing anything." -- Herman Melville, "Moby Dick"


Phil Goetz

unread,
Jan 30, 1997, 3:00:00 AM1/30/97
to

In article <32EE21...@cogentex.com>,

Rooms and objects should be the same thing.
Treating them as different things is, to my mind, possibly Inform's
biggest flaw. It could really get in the way if you tried to
create a more complicated physical model of the world, because you
would have to write separate rules for rooms and for objects.

In my (embryonic) system, every object can have an exterior and an
interior. If it is, say, a brick, you don't have to describe the
interior, and if it's a forest, you don't have to describe the
exterior, but if it's a car, you can describe both.
Put this on my wish list for Inform 7. :)

This separating of interior and exterior surfaces is not just to
get descriptions right, it is necessary to get lighting right.
If you are in a car and turn the interior light on, you should
be able to see the inside of the car, but if you then step outside
the internal light will (probably) not help you see the outside
of the car.

I'm not saying my way is the best, but I wanted to point out to
anybody who's designing an IF language that there is no need
to have separate classes for rooms and objects. (Nor for people
and objects. Maybe for doorways and objects, though.)
Keeping them separate is inevitably going to lead to hacks
whenever you have vehicles or nested locations.

Disclaimer: This is not an advertisement. :)

Phil Go...@cs.buffalo.edu

"Good fiction sets off a vivid and continuous dream in the reader's mind.
It does not play pointlessly subtle games in which storytelling is confused
with puzzle-making. It does not "test" the reader by demanding that he
bring with him some special knowledge without which the events make no sense."

John Gardner, _On Becoming a Novelist_

Reply all
Reply to author
Forward
0 new messages