Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Free idea

10 views
Skip to first unread message

Andrew Plotkin

unread,
Sep 20, 1996, 3:00:00 AM9/20/96
to

Just had this thought, which I don't have time to toss into a game:

Sublocations within a room. Instead of "Drawing Room" being a single
location, or having "East side of Drawing Room" and "West side of Drawing
Room", have a "Drawing Room" room but also extra variables stating which
part the player is in.

> look
Drawing Room (west side)
You are standing by the fireplace of a richly appointed blah blah etc...
A chandelier hangs in the center of the room.

> touch chandelier
The chandelier is out of reach to the east.

> e
You step to the center of the room.

> touch chandelier
You stretch up and bop it with your fingertips.

> look
Drawing Room (center)
You are standing beneath a chandelier in the center of a richly appointed
blah blah etc... A fireplace dominates the west wall.

> ee
You walk to the east side of the room.

[First opening the dining room door]
You leave the drawing room.

Dining Room (west side)
...

Note the "ee", "nn", "ww", "ss" commands, which effectively repeat "e",
"n", "w", "s" until you cross a room boundary.

Note that moving within a room doesn't trigger a print room name / full
look event, but the room description does change slightly. (So "ee"
always produces a full look (assuming verbose code), and "e" does so
*sometimes*. If the last command input had been "e. e", the results would
have been identical.)

Perhaps the chandelier thing is a bad example. Constant micromaneuvering
is a nuisance, and we're not doing this just for nuisance value. Pretty
much every object (including takeable ones) will be in a sublocation, so...

> touch chandelier
[First stepping east to the center of the room]
You stretch up and bop it with your fingertips.

> take lamp
[First stepping west to the fireplace]
Taken.

This is a lot of work, of course. I would use it to implement a *small*
number of rooms that I wanted to present with unusually rich detail.

Why? (Other than unusually rich detail.) Hiding. Standing unnoticed in a
ballroom to eavesdrop. Strategic position in a fight scene (If you're far
from the door, you have enough time to shoot a sudden intruder. You can't
swordfight unless you're in the same sublocation.) Trap doors and hidden
pits in the floor.

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Matthew Daly

unread,
Sep 20, 1996, 3:00:00 AM9/20/96
to

erky...@netcom.com (Andrew Plotkin) writes:
>Just had this thought, which I don't have time to toss into a game:
>
>Sublocations within a room. Instead of "Drawing Room" being a single
>location, or having "East side of Drawing Room" and "West side of Drawing
>Room", have a "Drawing Room" room but also extra variables stating which
>part the player is in.

[example snipped]

I'm not sure that this would work well in a text game. However, this
is the sort of level of sophistication that would work very well in
a graphic game with a doom-ish interface -- like Ultima Underworld.

>Perhaps the chandelier thing is a bad example. Constant micromaneuvering
>is a nuisance, and we're not doing this just for nuisance value. Pretty
>much every object (including takeable ones) will be in a sublocation, so...
>
>> touch chandelier
>[First stepping east to the center of the room]
>You stretch up and bop it with your fingertips.
>
>> take lamp
>[First stepping west to the fireplace]
>Taken.
>
>This is a lot of work, of course. I would use it to implement a *small*
>number of rooms that I wanted to present with unusually rich detail.

The potential problem with this is that the user would be struck by
"The living room is a richly-detailed part of the universe, but the
hallway isn't." You would have to make it clear enough through the
interface which is which, because leaving the user to guess would cause
aggrivation, IMHO. Not that it couldn't be done, but it would take
caution.

>Why? (Other than unusually rich detail.) Hiding. Standing unnoticed in a
>ballroom to eavesdrop. Strategic position in a fight scene (If you're far
>from the door, you have enough time to shoot a sudden intruder. You can't
>swordfight unless you're in the same sublocation.) Trap doors and hidden
>pits in the floor.

How well does Suspect fulfill your thoughts here? The ballroom is
divided into nine locations, so that you can see characters if they
are in an adjacent location, but only hear their conversation if they
are in the same location. There is also the HIDE command in certain
locations.

-Matthew

--
Matthew Daly I don't buy everything I read ... I haven't
da...@ppd.kodak.com even read everything I've bought.

My opinions are not necessarily those of my employer, of course.

Andrew Plotkin

unread,
Sep 20, 1996, 3:00:00 AM9/20/96
to

Matthew Daly (da...@PPD.Kodak.COM) wrote:
> >This is a lot of work, of course. I would use it to implement a *small*
> >number of rooms that I wanted to present with unusually rich detail.

> The potential problem with this is that the user would be struck by
> "The living room is a richly-detailed part of the universe, but the
> hallway isn't." You would have to make it clear enough through the
> interface which is which, because leaving the user to guess would cause
> aggrivation, IMHO. Not that it couldn't be done, but it would take
> caution.

Oh, quite right. I didn't meant a small number of rooms in a larger game:
I meant a game with a small number of rooms.

A sublocation is pretty much of constant size: it's "arm's reach",
allowing you step move your feet a little. A small room with one
sublocation isn't a problem. A long hallway with one sublocation would
be; but splitting it into two or three would probably be pretty easy,
because you would already have written the code to handle the general
case. Players would tend to always use "ww" to go through the hall. But
people *do* go through hallways quickly and with little attention. You
could play off this by putting a subtle clue halfway down the hall, which
is only noticeable if the player stops there.

> >Why? (Other than unusually rich detail.) Hiding. Standing unnoticed in a
> >ballroom to eavesdrop. Strategic position in a fight scene (If you're far
> >from the door, you have enough time to shoot a sudden intruder. You can't
> >swordfight unless you're in the same sublocation.) Trap doors and hidden
> >pits in the floor.

> How well does Suspect fulfill your thoughts here? The ballroom is
> divided into nine locations, so that you can see characters if they
> are in an adjacent location, but only hear their conversation if they
> are in the same location. There is also the HIDE command in certain
> locations.

It's been years and years since I played Suspect. I don't remember this
at all. I just recall running into characters sometimes.

Julian Arnold

unread,
Sep 20, 1996, 3:00:00 AM9/20/96
to

In article <erkyrathD...@netcom.com>, Andrew Plotkin

<URL:mailto:erky...@netcom.com> wrote:
>
> Just had this thought, which I don't have time to toss into a game:
>
> Sublocations within a room. Instead of "Drawing Room" being a single
> location, or having "East side of Drawing Room" and "West side of Drawing
> Room", have a "Drawing Room" room but also extra variables stating which
> part the player is in.

I tried out a similar idea for one of my would-be competition games. I
my game the room was a barroom, and there were four NPCs who also moved
around the sublocations. It was quite fun watching them move around, as
their likelihood of moing to a particular sublocation depended, in part,
on their current sublocation, how long they had been their, and who they
were. For example, if Ned (the drunk) was currently propping up the bar
he would be unlikely to move. If he did, he would be more likely to sit
down at a table than to to go and stand by the hearth, and he would
almost never go over by the window. If he did fetch up by the window,
he would soon return to the bar. OTOH, the old man, call him Pete,
spent most of his time sitting at the table, but would sometimes go and
stare out the window, or contemplate the painting above the hearth.
Wherever he was, he would be unlikely to move for a good while.

> Note the "ee", "nn", "ww", "ss" commands, which effectively repeat "e",
> "n", "w", "s" until you cross a room boundary.

I didn't implement this, but rather the player could "go to the window,"
"go near the hearth," or "join ned at the bar."

> This is a lot of work, of course. I would use it to implement a *small*
> number of rooms that I wanted to present with unusually rich detail.
>

> Why? (Other than unusually rich detail.) Hiding. Standing unnoticed in a
> ballroom to eavesdrop. Strategic position in a fight scene (If you're far
> from the door, you have enough time to shoot a sudden intruder. You can't
> swordfight unless you're in the same sublocation.) Trap doors and hidden
> pits in the floor.

It *is* a lot of work, and I only did it for the one room (though
maneouvering 4 NPCs as well adds some difficulty!)

I used it
a) to add unusually rich detail, as the barroom was the main
room in the game, and
b) because when things started to happen, the player's precise
position was important, and also everyone else's position,
relative to the player, was also important.

Jools
--


John Wood

unread,
Sep 21, 1996, 3:00:00 AM9/21/96
to

Jools wrote,

>Andrew Plotkin <URL:mailto:erky...@netcom.com> wrote:
>>
>> Just had this thought, which I don't have time to toss into a game:
>>
>> Sublocations within a room. Instead of "Drawing Room" being a single
>> location, or having "East side of Drawing Room" and "West side of Drawing
>> Room", have a "Drawing Room" room but also extra variables stating which
>> part the player is in.
>
>I tried out a similar idea for one of my would-be competition games.

[Stuff about NPCs snipped]

Well, well. I was wondering about doing something similar in my '97
competition game too, and for much the same reason (it's at a party).

>> Note the "ee", "nn", "ww", "ss" commands, which effectively repeat "e",
>> "n", "w", "s" until you cross a room boundary.
>
>I didn't implement this, but rather the player could "go to the window,"
>"go near the hearth," or "join ned at the bar."

I hadn't thought of the "ee"-style commands or "join", but also had
"approach" (abbr "a"). I would suggest explaining about unusual
movement commands in the intro material, since it's so different from
what players are used to.

I think it's interesting that everyone considering this technique
(including, as Matthew points out, Infocom in Suspect) thinks of it in
conjunction with large numbers of NPCs (yes, four is a large number when
you have to code them!). Does it have (non-contrived) uses without
NPCs (I wouldn't say it's worth it *just* for trapdoors)?

John


Andrew Clover

unread,
Sep 22, 1996, 3:00:00 AM9/22/96
to

erky...@netcom.com (Andrew Plotkin) wrote:

> Sublocations within a room. Instead of "Drawing Room" being a single
> location, or having "East side of Drawing Room" and "West side of
> Drawing Room", have a "Drawing Room" room but also extra variables
> stating which part the player is in.

Curses and Hitch Hiker's have tried something like this, both limited to
one location. In my opinion, both were unsuccessful, and certainly I had to
look up the answers to both the puzzles in question (talking to Prosser as
Ford in HHGTTG and knowing where to dig in Curses), because it perverted my
normal expectations of how things work in adventures.

The way I would prefer to do it is have each location as a real separate
location (object), with the difference that you can see and/or hear things
from linked locations, by using the scope property. Thus you could examine
or listen to someone in the same room but in a different object, but
attempting to give something to them, or kiss or attack or whatever causes
either an error or an automatic move.

Ideally the way it *should* work is to extend Inform's idea of what is in
scope and when. All the grammar should be extended so that special scopes
for 'you can see it here', 'you can hear it here' and 'you can touch it
here' are used instead of the general 'noun' and 'multi' tokens. 'Phones,
sub-locations and soundproof glass screens would then all be easily
codeable.

I might be able to do it as a library extension... dunno... it's quite
complex. :-)

BCNU, AjC

Julian Arnold

unread,
Sep 22, 1996, 3:00:00 AM9/22/96
to

In article <155724...@elvw.demon.co.uk>, John Wood

<URL:mailto:jo...@elvw.demon.co.uk> wrote:
>
> Jools wrote,
> >Andrew Plotkin <URL:mailto:erky...@netcom.com> wrote:
> >>
> >> Just had this thought, which I don't have time to toss into a game:
> >>
> >> Sublocations within a room. Instead of "Drawing Room" being a single
> >> location, or having "East side of Drawing Room" and "West side of Drawing
> >> Room", have a "Drawing Room" room but also extra variables stating which
> >> part the player is in.
> >
> >I tried out a similar idea for one of my would-be competition games.
>
> [Stuff about NPCs snipped]

Oi, that was the best bit!

> I think it's interesting that everyone considering this technique
> (including, as Matthew points out, Infocom in Suspect) thinks of it in
> conjunction with large numbers of NPCs (yes, four is a large number when
> you have to code them!). Does it have (non-contrived) uses without
> NPCs (I wouldn't say it's worth it *just* for trapdoors)?

Hm, well my original gameplan had the floor of the inn collapsing (some
fool built it over an abandoned mineshaft-- yes, it's a bit silly).
Thus, the PC and the NPCs would fall to different places depending on
their sublocation in the barroom when the floor gave out. They had to
work together to escape. Obviously where they ended up relative to
eachother, had an effect on how they could help the others/themselves,
thus the problems posed in each game were subtly different (well, would
have been). This idea, if it would have worked, would also have worked
if there were no NPCs (not as well admittedly, and there'd be no working
together).

I can see other complex positional puzzles working where no NPCs were
involved, although I agree with others that an entire game (unless it
was very short) using this method would be incredibly irritating and
tedious.

I suspect the chief use of this would be in PC/NPC interaction.

Jools
--


Phil Goetz

unread,
Sep 30, 1996, 3:00:00 AM9/30/96
to

In article <erkyrathD...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>Just had this thought, which I don't have time to toss into a game:
>
>Sublocations within a room. Instead of "Drawing Room" being a single
>location, or having "East side of Drawing Room" and "West side of Drawing
>Room", have a "Drawing Room" room but also extra variables stating which
>part the player is in.
>
>> look
>Drawing Room (west side)
>You are standing by the fireplace of a richly appointed blah blah etc...
>A chandelier hangs in the center of the room.
>
>> touch chandelier
>The chandelier is out of reach to the east.
>
>Why? (Other than unusually rich detail.) Hiding. Standing unnoticed in a
>ballroom to eavesdrop. Strategic position in a fight scene (If you're far
>from the door, you have enough time to shoot a sudden intruder. You can't
>swordfight unless you're in the same sublocation.) Trap doors and hidden
>pits in the floor.

This is a good idea. I would want to implement it using ordinary locations,
but changing the rules that define what you can and cannot see from a location.
So if we assert that the connection between ballroomwest and ballroomeast
is a large connection, then in ballroomwest you can see all objects and
events in ballroomeast.

It's easy in Prolog...

Phil

0 new messages