Idea for movement system, take 2...

6 views
Skip to first unread message

George Caswell

unread,
Nov 16, 1996, 3:00:00 AM11/16/96
to

[Warning! Danger, Will Robinson! Long post on pre-planning of an IF system!]

Hi. Some of you may remember a while back I posted an idea for a new
movement system, which would describe rooms in 'real' space-- distances,
positions, orientations, etc. would all exist within the room... I think my
example then was a little crude and very misdirecting-- (In it all movement
was in commands like 'half right' or 'forward by 3 meters'...)

Well, I'm working on pre-planning for an I-F game, and one technical note
I'm spending a lot of time on is movement-- I think the N/S/E/W system is
generally not preferable, despite tradition... so I've returned to this old
idea. I'm throwing it out here in its current form to try and get an idea of
what kinds of issues I'll be dealing with, and such...

The idea I'm running with right now is this- the map is split up into
'sectors' rather than 'rooms'. The general rule would be that any object
inside a given sector is in a position that would be visible from any other
point in the same 'sector'. For the system, scope would, be default, include
'close' parts of any adjacent sector- For example, if you're in a junction
with three corridors branching out from it, you would be able to see just
about everything in the junction, and a short distance into the corridors (by
the default look action.) Sectors, so far, are split into three types..

'point' sector- Most like a traditional 'room'. Anything within this
sector is in immediate reach, and any movement within the sector leads either
to a wall or an exit.
'line' sector- Some sort of corridor- not necessarily actually 'linear'
(it could be made curved by changing the scope rules within the corridor-
that any object more than x meters away is around a corner, or something..)
Not everything inside one of these sectors is in immediate reach--
everything, including the player, is positioned at an exact point within the
length of the corridor. Objects are on the floor or ceiling, or left or right
walls, at that point in the corridor.
And, the most complex, the 'planar' sector, which is used to describe
anything not describable by lines or points... large rooms or open spaces
mostly. Implementation for these would be rather tricky, I think..
especially calculating relative directions and distances in systems that
usually don't have trig or square roots... The current plan is that planar
sectors have a wall whose shape is arbitrary (and really only necessary to
keep the player from moving into an area which, clearly, could not be a part
of the sector). Objects have 3-d coordinates, generally (or maybe just 2-d,
probably don't need 'height' much...)

Movement is usually done directly (IE 'you see, up ahead, a fork in the
road.' >Go to the fork.) to visible exits or objects. With objects, 'look at'
would be distinguished from 'examine'- 'look at' would look from where you
are, and 'examine' would require you to go there first... interacting with
objects would require similar movement. When necessary, the player could also
turn and move the character by relative direction (turn left, go forward,
etc.)

Scoping, as I said, would be multi-sector a lot of the time. By default,
the player would have multiple zones of view depending on where they're
facing, to determine how much they can see. (Objects behind would still be
mentioned, for the player's sake, but not described unless they turn to the
object or try to interact with it directly, which would cause them to turn
and..)

Here's a sketchy example. Parts in [] are my comments.

MUNCHKIN LAND: [plain location name. May be shared by multiple sectors]

[Regular per-sector description, including things that will never move.]
You are in a sort of a town square. All around you are short people,
identifying themselves as representatives of various confectionary and
nocturnal guilds and leagues. Who would have thought these wonderful things
would be the diminutive man's bureaucracy?

[Start describing things in terms of directions. This could be done as part
of the previous description, just dynamically... for this example it's not
necessary. This area can basically just be a point-sector.]
Behind you is your humble Kansas home, which, you are told, landed on a witch
as the tornado landed you here. On the ground is a type of a spiral pattern
in gold, which swings out ahead of you to meet the start of a broad
yellow-brick road.

>Look at the house.
[It's in secondary scope, so we just look 'from here']
Your Kansas home. It was picked up by a twister with you in it, and landed on
a witch in this wacky place.

>Examine house.
You turn to look at the house in greater detail. It's a rather ugly little
structure, and the twister didn't help much. It's a wooden structure, sort of
squarish, with a sickly coat of white paint over it.

>Go to yellow brick road. [Or follow spiral, or maybe 'follow the yellow
brick road!', or turn around. Forward... but that's so dull..]

The Yellow Brick Road
Ahead of you stretches the yellow brick road those midgets kept yammering
about. [dynamic stuff begins- directions, mostly. The rest can be static.]
Behind you a short distance is the town square, from which you can hear the
midgets cheering you on, asking you if you're interested in the new
homemade-confectionaries unions or the dream/daydream coalition, newly formed.
Ahead lies a vast stretch of yellow brick road. [The 'vast stretch' would
probably be split into smaller sections of yellow brick road, to simplify
scoping and make it work properly.. Actually, the 'vast stretch' itself is
probably a way of describing another section of road.] Ahead and to your left
is a farm infested with crows.

>Examine crows.
You approach the farm. Despite your presence, and the presence of a
hay-stuffed scarecrow, the crows are happy to continue stealing food from the
farmer.

And so on. Note this isn't all planned out exactly- I'm not, in fact,
going to be making a Wizard of Oz game, and the movement system is in early
enough stage of planning that I can't say for sure just what exactly the
descriptions will need to be like-- but for human eyes the 'real distances'
will most certainly be approximated to general directions and approximate
distances (yonder, way yonder, and way the f**k yonder). I expect there will
be problems with the descriptions, scoping will be fairly complex, but let's
review the good points--

1: N/S/E/W is unnecessary.
2: Implementing things you can't reach, things you can't see or access
because you're stuck in position, etc. are implemented just as you'd think
they would be- To access something you need to go to it, so if you can't
move, you can't go to something and so can't access it except by actual
'look's. Part of the plan also includes the ability of objects in a sector to
prevent you from accessing parts of a sector- For example, a guard keeping
you from reaching half a large room or one end of a corridor. (or even a
single door.)
3: Implementing wide open spaces would be less artificial. A huge desert
could be described as a near-infinite planar sector, for example, rather than
multiple 'rooms'.
4: There has been some discussion of implementing a party floor- a large
room filled with people (most of whom don't block your way) with points of
interest at various locations... This situation would be fairly trivial with
a functioning library for the movement I describe.
5: In places where compass points are inappropriate (space, or anywhere you
don't have a compass) they're unnecessary.

What I'd like for feedback on this idea are any concerns or major points of
difficulty in implementing the text for the rooms, (artificial-sound concerns)
and any major problems you see implementing it.
One major problem I see is that the complexity I need may not be -possible-
in a Z-machine-- All this stuff would eat up a lot of variables, and that's
just no fun at all. So I would need to come up with a better system (maybe
TADS or something, I'd really hate to have to invent my own language for
this.)
I hope to make this system work, and then go on to make the first full-game
to use it. So any insights from more experienced implementors will be
welcomed.
________________________________________________
______________ _/> ____ | George Caswell, WPI CS 1999. Member L+L and |
<___ _________// _/<_ / | SOMA. Sometimes artist, writer, builder. Admin |
// <> ___ < > / _/ | of ADAMANT, a Linux box for the creative and |
// /> / / _/ / / <____ | productive members of the computer world. For |
// </ <<</ < _/ <______/ |_more info see http://www.wpi.edu/~timbuktu.____|
</ </


Brad O`Donnell

unread,
Nov 16, 1996, 3:00:00 AM11/16/96
to timb...@wpi.edu

George Caswell wrote:
>
> [Warning! Danger, Will Robinson! Long post on pre-planning of an IF system!]
>
> Hi. Some of you may remember a while back I posted an idea for a new
> movement system, which would describe rooms in 'real' space-- distances,
> positions, orientations, etc. would all exist within the room... I think my
> example then was a little crude and very misdirecting-- (In it all movement
> was in commands like 'half right' or 'forward by 3 meters'...)
>
> Well, I'm working on pre-planning for an I-F game, and one technical note
> I'm spending a lot of time on is movement-- I think the N/S/E/W system is
> generally not preferable, despite tradition...

I agree. Playing in IF game is a little like reading a novel where
every
third paragraph contains the words North, south, east and West... (I
prefer
Scott Adams type exits, myself: "Exits: North South" (But if you wanted
to see
how I think an IF game should be, search back on DejaNews for "Look vs
Examine
and Search" in rgi-f) )

> Objects have 3-d coordinates, generally (or maybe just 2-d,
> probably don't need 'height' much...)

Stuff on High Shelves, Stuff in Pits, and Cliffs would benefit from
the 3rd-D.

>
> Movement is usually done directly (IE 'you see, up ahead, a fork in the
> road.' >Go to the fork.) to visible exits or objects. With objects, 'look at'
> would be distinguished from 'examine'- 'look at' would look from where you
> are, and 'examine' would require you to go there first... interacting with
> objects would require similar movement. When necessary, the player could also
> turn and move the character by relative direction (turn left, go forward,
> etc.)


The need to be near objects is okay, just as long as it's done
implicitly
most of the time...I get tired of EAT APPLE responding with "But you're
not
holding that." It's failure response should be "But you can't reach
that."

>
> Scoping, as I said, would be multi-sector a lot of the time. By default,
> the player would have multiple zones of view depending on where they're
> facing, to determine how much they can see. (Objects behind would still be
> mentioned, for the player's sake, but not described unless they turn to the
> object or try to interact with it directly, which would cause them to turn
> and..)

[SNIPPED COOL WIZARD OF OZ EXAMPLE]

> I expect there will
> be problems with the descriptions, scoping will be fairly complex, but let's
> review the good points--
>
> 1: N/S/E/W is unnecessary.

The only problem I can think of about not having cardinal directions
is that
it would make a large game almost impossible to map. On the other
hand,
small games (meaning few locations) would benefit from a greater sense
of
"place," as it were... Hmmm.

> 2: Implementing things you can't reach, things you can't see or access
> because you're stuck in position, etc. are implemented just as you'd think
> they would be- To access something you need to go to it, so if you can't
> move, you can't go to something and so can't access it except by actual
> 'look's. Part of the plan also includes the ability of objects in a sector to
> prevent you from accessing parts of a sector- For example, a guard keeping
> you from reaching half a large room or one end of a corridor. (or even a
> single door.)

Perhaps, also, sneaking past the guard could be put in terms of where
the guard
is in a given sector (if he's far enough away from you, no matter where
you
were, you could pass through)...That idea, I like.

> 3: Implementing wide open spaces would be less artificial. A huge desert
> could be described as a near-infinite planar sector, for example, rather than
> multiple 'rooms'.

***SPECIAL REQUEST

This desert thing: I would really like to see an example (in
"IF-sketch" of
course.) It's fuzzy in my mind how such a thing should work. In fact,
the whole
'planar' thing has got me

> 4: There has been some discussion of implementing a party floor- a large
> room filled with people (most of whom don't block your way) with points of
> interest at various locations... This situation would be fairly trivial with
> a functioning library for the movement I describe.

Catch-22 :) What language were you planning on using? I can think of a
few
things that could help in Inform, but I'm sure that TADS is equally able
to
handle such things.

> 5: In places where compass points are inappropriate (space, or anywhere you
> don't have a compass) they're unnecessary.
>
> What I'd like for feedback on this idea are any concerns or major points of
> difficulty in implementing the text for the rooms, (artificial-sound concerns)
> and any major problems you see implementing it.

Well, one of the major problems with the text is that the parts that
are
generated by the library are likely to be rather repetitive and
artificial
sounding... What spurious bulk you lose in "Norths, Souths, E,W etc,"
Could
possibly be gained back (and more some) by "You turn to face,.. an
object way
yonder...At point 2,4 in the desert.."

> One major problem I see is that the complexity I need may not be -possible-
> in a Z-machine-- All this stuff would eat up a lot of variables, and that's
> just no fun at all. So I would need to come up with a better system (maybe
> TADS or something, I'd really hate to have to invent my own language for
> this.

> I hope to make this system work, and then go on to make the first full-game


> to use it. So any insights from more experienced implementors will be
> welcomed.

Since I'm not an "experienced" implementor, I'll give it some time
before I
tell of the (possibly lame) ideas I have that could help your system.
("Near" and "Near-parent" properties, for instance, which could be
followed
like a doubly-linked list through a pile of objects such that If One of
those
objects is in scope, the rest of them are, too.)


--
Brad O'Donnell

null...@aol.com

unread,
Nov 17, 1996, 3:00:00 AM11/17/96
to

> [Start describing things in terms of directions. This could be done as
part
> of the previous description, just dynamically... for this example it's
not
> necessary. This area can basically just be a point-sector.]
> Behind you is your humble Kansas home, which, you are told, landed on a
witch
> as the tornado landed you here. On the ground is a type of a spiral
pattern
> in gold, which swings out ahead of you to meet the start of a broad
> yellow-brick road.
>
> >Look at the house.
> [It's in secondary scope, so we just look 'from here']
> Your Kansas home. It was picked up by a twister with you in it, and
landed on
> a witch in this wacky place.

But then do you get:

>Look


Behind you is your humble Kansas home, which, you are told, landed on a
witch
as the tornado landed you here. On the ground is a type of a spiral
pattern
in gold, which swings out ahead of you to meet the start of a broad
yellow-brick road.

Or do you have a flag to remember which way the player is facing, so the
house is now "In front of you...", and the road "behind you..."?

There's one good reason for compass directions -- they're not relative.
Given how easily people get confused by non-reversible paths ("But I went
*north* on the Curvy Path, and now I have to go *east* to get back?!?!?"),
left-right-before-behind is a potential nightmare.

Neil
---------------------------------------------------------
Neil deMause ne...@echonyc.com
http://www.echonyc.com/~wham/neild.html
---------------------------------------------------------

George Caswell

unread,
Nov 18, 1996, 3:00:00 AM11/18/96
to

On 17 Nov 1996 null...@aol.com wrote:

> But then do you get:
>
> >Look
> Behind you is your humble Kansas home, which, you are told, landed on a
> witch
> as the tornado landed you here. On the ground is a type of a spiral
> pattern
> in gold, which swings out ahead of you to meet the start of a broad
> yellow-brick road.
>
> Or do you have a flag to remember which way the player is facing, so the
> house is now "In front of you...", and the road "behind you..."?
>

The idea is that in every type of sector every object has variables marking
its location and orientation- In some sector types the location is partly or
wholly ignored... But, yes, the description of what's ahead, to the sides,
and behind you is dynamic and expressed based on the player's facing
direction.

> There's one good reason for compass directions -- they're not relative.
> Given how easily people get confused by non-reversible paths ("But I went
> *north* on the Curvy Path, and now I have to go *east* to get back?!?!?"),
> left-right-before-behind is a potential nightmare.
>

I expect as much. My goal is to make the system never, or at least almost
never rely on the use of explicit relative movements-- If some of you
remember my first posting about such a system, that was the biggest flaw in
the example-- Throughout that, much earlier example the player was typing
commands like 'turn half right' or 'forward 3 meters'. My hope is to make all
the location-to-location movement by location or exit name, or by some other
such... The fairly detailed information on complex sectors that I want to
implement is not for player consumption and interaction except as backup or in
special circumstances- The reason I want to implement all this information is
to 1: make movement better (or fail trying) and 2: give implementation of
certain problems- can't reach something, etc. a basis in the game space. So
far, of course, it's just an idea.

Jason B Dyer

unread,
Nov 18, 1996, 3:00:00 AM11/18/96
to

George Caswell (timb...@adamant.res.wpi.edu) wrote:
: I expect as much. My goal is to make the system never, or at least almost

: never rely on the use of explicit relative movements--
: My hope is to make all

: the location-to-location movement by
: location or exit name, or by some other such...

The only problem is this gets quite tedious after a while. N/S/E/W
is really just a convention so that IF players don't go crazy
just trying to move around.

Also, this would require exits that were all different. If you
have a room with multiple doors, all that look the same, things will
get quite confusing. Authors would have to resort to something even
more artificial like making a "green door" and a "blue door" and
so on.

Another problem:

+--+ +--+ +--+ +--+
|A |-| |-| |-|B |
+--+ +--+ +--+ +--+

To get from point A to point B the player would have to type three
different commands as opposed to E. E. E. You could give each
room/sector a name and simply type the name to travel there,
but the command can only be used if the player has actually been there,
and of course if there are room names that are similar...

Jason Dyer
jd...@u.arizona.edu

Andrew Plotkin

unread,
Nov 18, 1996, 3:00:00 AM11/18/96
to

George Caswell (timb...@adamant.res.wpi.edu) wrote:
> One major problem I see is that the complexity I need may not be -possible-
> in a Z-machine-- All this stuff would eat up a lot of variables, and that's
> just no fun at all. So I would need to come up with a better system (maybe
> TADS or something, I'd really hate to have to invent my own language for
> this.)

I suspect it wouldn't be much of a problem. The Z-machine is limited in
the number of variables, but not the number or size of arrays or object
properties. Most of the info for any OO system winds up in the objects.

--Z

--

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

Cardinal Teulbachs

unread,
Nov 18, 1996, 3:00:00 AM11/18/96
to

George Caswell <timb...@adamant.res.wpi.edu> wrote:

>My hope is to make all
>the location-to-location movement by location or exit name, or by some other
>such...

And here is what I don't understand. Movement in i-f is done in
discrete chunks because of the command line interface, but you're
proposing a scoping system based on a continuum: distance. Where doth
the twain meet? I can see that in a continuous-movement game like a
video game (say, Doom), a continuum-based scoping system is
preferable. In fact, Doom's success has everything to do with its
having one. But in an environment where movement is accomplished in
discrete chunks (say, Myst or i-f), what is there to be gained by it?
I can do what you're proposing with my current system. If I tie a
scope-handling routine to the "walk to idol" action (or whatever),
I've done effectively the same thing as you're talking about, haven't
I? The only thing I can't handle is the continuum in between--and this
is what it appears you're trying to do, but I can't see that you'll
have really accomplished much unless you allow for movement in a
continuum by going with the dreaded "walk forward x meters" and "turn
x degrees left" command style.

And if you do that you'll simply be trying to simulate in text what 3d
video games do much better, won't you?

--Cardinal T

I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan

Isn't this .sig a little long? I hope *I* never
contribute to such a tremendous waste of bandwidth.
--Jools the Whiney

Are there any text games prominently featuring dinosaurs?
If not, does anyone besides me think it would be cool?
--Matthew Amster-Burton

"Cyber-Babushka"
--Bonni Mierzejewska


George Caswell

unread,
Nov 19, 1996, 3:00:00 AM11/19/96
to

On Tue, 19 Nov 1996, Trevor Barrie wrote:

> Brad O`Donnell <s7...@romulus.sun.csd.unb.ca> wrote:
>
> >> Objects have 3-d coordinates, generally (or maybe just 2-d,
> >> probably don't need 'height' much...)
> >
> > Stuff on High Shelves, Stuff in Pits, and Cliffs would benefit from
> >the 3rd-D.
>

> It seems to me that these can be handled by having objects be 'on', 'under'
> or 'in' other objects, as Worldclass currently handles it (and I assume
> other languages and libraries have something equivalent). I don't think
> having a third coordinate is generally useful enough to bother with, though
> it would certainly be neat to be able to do an underwater scene with full
> mobility.
>
Well, I think possibly how including positions and orientations of objects
could be most useful is by giving the player some sense of locations of
objects within rooms, and implementing various 'out of reach' scenarios in a
comprehensive way. The first point could be quite important if the use of
cardinal directions is removed. The second would help avoid excessive
limitations in what players could use, for example, to stand on to reach
something. If the author wanted the player to stand on a ladder, but there's
a chair that's tall enough, too... (could be solved through playtesting, but
this way still makes the actual tests easier, I think)

> >> 1: N/S/E/W is unnecessary.
> >
> > The only problem I can think of about not having cardinal directions
> >is that it would make a large game almost impossible to map. On the other
> >hand, small games (meaning few locations) would benefit from a greater sense
> >of "place," as it were... Hmmm.
>

> As an aside, I don't see any reason why cardinal directions couldn't still
> be supported as an option.
>
Very true. The main reason I don't want to use them is that I don't -like-
them most of the time. I imagine it would be fairly easy to implement a
'northdirection' in any of the sectors...

George Caswell

unread,
Nov 19, 1996, 3:00:00 AM11/19/96
to

On Mon, 18 Nov 1996, Cardinal Teulbachs wrote:

> George Caswell <timb...@adamant.res.wpi.edu> wrote:
>
> >My hope is to make all
> >the location-to-location movement by location or exit name, or by some other
> >such...
>
> And here is what I don't understand. Movement in i-f is done in
> discrete chunks because of the command line interface, but you're
> proposing a scoping system based on a continuum: distance. Where doth
> the twain meet? I can see that in a continuous-movement game like a

Sectors! A sector is the basic unit of space in the proposed system. The
intent is that the vast majority of sectors would be points or lines- Lines
existing in part to convey a sense of the distance you're travelling. Scoping
would be done on a sector as a whole (for the most part) and objects from
-additional- sectors added based on distance and such- possibly also changing
object descriptions slightly based on how immediately close they are in a
sector. The desert example (scoping based on direction) is a very special
case-- there the area the player is in --is-- a continuum, splitting it up
would be artificial for a uniform desert.

> video game (say, Doom), a continuum-based scoping system is
> preferable. In fact, Doom's success has everything to do with its
> having one. But in an environment where movement is accomplished in
> discrete chunks (say, Myst or i-f), what is there to be gained by it?

The current theory is that it would help illustrate to the player the world
they're playing in without splitting the world into artificial chunks, like
'rooms', and that it would make an actual representation of the cause of
certain game challenges- for example, you can't reach a ceiling fan because
it's on the ceiling. If you were taller, or stood on something tall enough,
you could reach the ceiling and so reach the fan... that part done without
much special coding, in theory.

> I can do what you're proposing with my current system. If I tie a
> scope-handling routine to the "walk to idol" action (or whatever),
> I've done effectively the same thing as you're talking about, haven't
> I? The only thing I can't handle is the continuum in between--and this

Have you? What is your current system? From what I've seen both TADS and
Inform are quite thoroughly split into their individual rooms, and generally
there's no way to learn anything about a location you're not in. If you 'walk
to' an object that has no real location of any sort within a room, how do you
know you're not next to some other objects, or farther away from some others?
(Well, I suppose you could group them together if they're close...) I guess I
can see your point-- the decision for adding locations within locations for
objects is somewhat arbitrary. But my hope is to have scope follow the player
in parts of a sector and between sectors. That can be done if every sector is
a spaceless void and nothing has a location, but then every object not only in
your sector but in adjacent sectors will be all too visible. The idea is that
by facing or approaching an object, you turn verbosity on for that object, and
that focus to adjacent sectors increases -gradually- whenever possible.

> is what it appears you're trying to do, but I can't see that you'll
> have really accomplished much unless you allow for movement in a
> continuum by going with the dreaded "walk forward x meters" and "turn
> x degrees left" command style.
>

Movement by location name, dropping the artificial '12 directions'
(including only 4, up, down, in, out), scoping that includes adjacent rooms
without flooding the screen with crap,

> And if you do that you'll simply be trying to simulate in text what 3d
> video games do much better, won't you?
>

If I -were- trying for that, then yes, I would be. Exactly why my original
first example, now long dead and buried, should be forgotten.
And in a way, unconditionally yes-- but I'm not trying for an exact
representation of the world-- just a little extra resolution to add to
description and interface. Unlike the 3-D games I wouldn't need to represent
walls (except in the planar sectors which, for a great many reasons are NOT
meant for extensive use, just the special cases where they would be useful to
have), check (most) collisions, or anything like that, so it's not as if I'm
re-implementing Doom with a text interface...

Cardinal Teulbachs

unread,
Nov 19, 1996, 3:00:00 AM11/19/96
to

George Caswell <timb...@adamant.res.wpi.edu> wrote:

> Sectors! A sector is the basic unit of space in the proposed system. The
>intent is that the vast majority of sectors would be points or lines- Lines
>existing in part to convey a sense of the distance you're travelling. Scoping
>would be done on a sector as a whole (for the most part) and objects from
>-additional- sectors added based on distance and such- possibly also changing
>object descriptions slightly based on how immediately close they are in a
>sector. The desert example (scoping based on direction) is a very special
>case-- there the area the player is in --is-- a continuum, splitting it up
>would be artificial for a uniform desert.

I think I see what you're getting at. But aren't you just in fact
dividing rooms into smaller rooms and changing the scope-checking
behavior? Why can't a person do that now, by making a notional room
consist of nine actual rooms and then modifying the scope rules? I'm
not suggesting that your project isn't worth the effort or anything of
the sort; I'm just trying to get a handle on what you're doing. Are
you simply saying that you'd like to have a system that's designed to
operate in this way so a person doesn't have to do it him or herself,
or are you aiming to do something that can't be done at all in
existing systems?

> The current theory is that it would help illustrate to the player the world
>they're playing in without splitting the world into artificial chunks, like
>'rooms',

But you are, aren't you? The chunks are just smaller. The player is
still moving around in fits and starts to certain allowable locations;
he can't just move to any arbitrary position within a room (or sector
or whatever). Right? If so, then the world is still split into
artificial chunks.

>and that it would make an actual representation of the cause of
>certain game challenges- for example, you can't reach a ceiling fan because
>it's on the ceiling. If you were taller, or stood on something tall enough,
>you could reach the ceiling and so reach the fan... that part done without
>much special coding, in theory.

This can be done already. Again, a system like you're talking about
would no doubt make it easier, but it's already doable. Hugo, for
instance, has a routine that can be called to check to see whether a
thing is within the player's reach or not. You just have to tell it
what's within reach and what not at any given time (which, in
practice, is easier than it sounds).

>> I can do what you're proposing with my current system. If I tie a
>> scope-handling routine to the "walk to idol" action (or whatever),
>> I've done effectively the same thing as you're talking about, haven't
>> I? The only thing I can't handle is the continuum in between--and this

> Have you? What is your current system? From what I've seen both TADS and
>Inform are quite thoroughly split into their individual rooms, and generally
>there's no way to learn anything about a location you're not in.

I use Hugo and it, like TADS and Inform, is thoroughly split into its
individual rooms. But you're talking about the systems' default
behavior. I'm suggesting that it's not such a huge chore to change the
default behavior (at least in Hugo) and get done what you want to get
done. Well, I take that back--at least partly. It *could* be a huge
chore, depending upon the situation, but there's no reason in
principle why a person couldn't write the code necessary to do the
things you're talking about. It would just require conditionals; e.g.
*if* the player is standing near the idol then put objects x,y,z out
of scope and bring objects a,b,c into scope. How do I know the player
is standing near the idol? Because he issued the "walk to idol"
command (or whatever).

>If you 'walk
>to' an object that has no real location of any sort within a room, how do you
>know you're not next to some other objects, or farther away from some others?

You have to tell the player in your room/object/event descriptions.
There's no other way. Even with your system, if I'm understanding it
correctly, that doesn't change. Unless the player has some real,
concrete, distance-based way of moving (i.e. "walk x meters forward"),
she will still have no way of knowing her relative position within an
area unless you tell her. But you could do that right now in Inform by
simply running an event every time the player moves telling her where
she is, what's close by, what's not, etc.

>(Well, I suppose you could group them together if they're close...) I guess I
>can see your point-- the decision for adding locations within locations for
>objects is somewhat arbitrary. But my hope is to have scope follow the player
>in parts of a sector and between sectors. That can be done if every sector is
>a spaceless void and nothing has a location, but then every object not only in
>your sector but in adjacent sectors will be all too visible. The idea is that
>by facing or approaching an object, you turn verbosity on for that object, and
>that focus to adjacent sectors increases -gradually- whenever possible.

I can see that having a system that handles scoping in this way would
make things easier for the author, if this is in fact the kind of
scoping system an author wants to have. No argument there. He wouldn't
have to manually do all the hiding and unhiding of objects, etc.
Moreover, I expect one could devise something like a Doom level editor
to lay out a game environment with CAD and then output primitive
sector and object definitions to a shell source file, which would be
kinda neat.

> Movement by location name, dropping the artificial '12 directions'
>(including only 4, up, down, in, out), scoping that includes adjacent rooms
>without flooding the screen with crap,

This isn't an English sentence :)

>> And if you do that you'll simply be trying to simulate in text what 3d
>> video games do much better, won't you?
>>
> If I -were- trying for that, then yes, I would be. Exactly why my original
>first example, now long dead and buried, should be forgotten.
> And in a way, unconditionally yes-- but I'm not trying for an exact
>representation of the world-- just a little extra resolution to add to
>description and interface. Unlike the 3-D games I wouldn't need to represent
>walls (except in the planar sectors which, for a great many reasons are NOT
>meant for extensive use, just the special cases where they would be useful to
>have), check (most) collisions, or anything like that, so it's not as if I'm
>re-implementing Doom with a text interface...

Right. I see that's not what you're attempting, but it just seems to
me that most of your hard work will have been unnecessary if you're
sticking with discrete movement as opposed to continous. You can, I
believe, just modify Inform to behave the way you want (it's been
awhile since I used Inform, though; I know you could do it with Hugo).
A crude example off the top of my miter:

Let an Inform room be actually what you're calling a sector. Then, to
create a "room", you would simply create however many sectors were in
it--let's say nine. Now, modify the scope rules so that sectors
(rooms, to Inform) adjacent to the occupied one are in scope. How do
you do that? Give each sector/room a property that lists the sectors
adjacent to it and check the list from your scoping routine. Not that
difficult. But what about line-of-sight problems? What if there's a
vase behind an in-scope idol that the player shouldn't be able to see
from where he's standing? Well, there are, in fact, no such
line-of-sight problems, since the player can never occupy an arbitrary
position within a sector. He is always notionally wherever the author
intends him to be. Hence, the author always knows what the player can
see or not see at any given time (this is what I've been trying to get
at with my talk about continuous movement--if movement is discrete,
much of what you're talking about seems to be wasted effort). You
don't need the system to figure out whether the vase can be seen or
not, since you know it can't; so just put it out of scope until the
player moves.

Granting the limit on the number of rooms available for use, which,
using this method (there are others), presents a problem for big
games, isn't this possible and isn't this essentially the same as
you're trying to do?

Trevor Barrie

unread,
Nov 19, 1996, 3:00:00 AM11/19/96
to

Brad O`Donnell <s7...@romulus.sun.csd.unb.ca> wrote:

>> Objects have 3-d coordinates, generally (or maybe just 2-d,
>> probably don't need 'height' much...)
>
> Stuff on High Shelves, Stuff in Pits, and Cliffs would benefit from
>the 3rd-D.

It seems to me that these can be handled by having objects be 'on', 'under'


or 'in' other objects, as Worldclass currently handles it (and I assume
other languages and libraries have something equivalent). I don't think
having a third coordinate is generally useful enough to bother with, though
it would certainly be neat to be able to do an underwater scene with full
mobility.

> The need to be near objects is okay, just as long as it's done


>implicitly most of the time...I get tired of EAT APPLE responding with "But you're
>not holding that." It's failure response should be "But you can't reach
>that."

Damn right.

>> 1: N/S/E/W is unnecessary.
>
> The only problem I can think of about not having cardinal directions
>is that it would make a large game almost impossible to map. On the other
>hand, small games (meaning few locations) would benefit from a greater sense
>of "place," as it were... Hmmm.

As an aside, I don't see any reason why cardinal directions couldn't still

George Caswell

unread,
Nov 20, 1996, 3:00:00 AM11/20/96
to

On Tue, 19 Nov 1996, Cardinal Teulbachs wrote:

> George Caswell <timb...@adamant.res.wpi.edu> wrote:
>
> > Sectors! A sector is the basic unit of space in the proposed system. The
> >intent is that the vast majority of sectors would be points or lines- Lines
> >existing in part to convey a sense of the distance you're travelling. Scoping
> >would be done on a sector as a whole (for the most part) and objects from
> >-additional- sectors added based on distance and such- possibly also changing
> >object descriptions slightly based on how immediately close they are in a
> >sector. The desert example (scoping based on direction) is a very special
> >case-- there the area the player is in --is-- a continuum, splitting it up
> >would be artificial for a uniform desert.

> not suggesting that your project isn't worth the effort or anything of


> the sort; I'm just trying to get a handle on what you're doing. Are

Excellent. This is exactly the sort of stuff I need, then. These sorts of
questions will also help -me- figure out exactly why I do or don't want any
feature I discussed, and so refine the design spec...

> I think I see what you're getting at. But aren't you just in fact
> dividing rooms into smaller rooms and changing the scope-checking
> behavior? Why can't a person do that now, by making a notional room
> consist of nine actual rooms and then modifying the scope rules? I'm

The visible scoping rules alone could be done that way. The idea about
widening scope as I see it isn't to make individual rooms smaller, but to
leave most rooms the way they are and allow the player to see things they
wouldn't be able to see otherwise from their current position. For example,
if a player is on one point of a street, why wouldn't he be able to get at
least a basic idea of what is east or west from his point on the (east-west)
street? If the player's in a hallway of a college building, why wouldn't he
be able to see what's in any of the rooms without entering them? All of this
can be done with the current systems with careful programming and condition
checking-- My system as currently sketched out would make this behavior no
easier to refine, but the behavior would at least be available by default.
And the system I'm trying to work out here includes new scoping, new movement,
new implementation of 'can't reach it' scenarios (meaning that the cause of
being unable to reach something would be implemented) and implementation of
areas normal movement systems have trouble with. (line and planar sectors.
Line sectors will probably be included if/when I make the system-- if not
then the system will be basically modified scope rules, trivial position data,
and the removal of most compass points. Planar sectors I'm really not sure
about-- They're meant only to implement the odd case where something can't be
appropriately expressed as other sector types-- the vast sparse desert, for
example... relative movement within them would be very difficult except in
special cases (IE the player is given a map to follow, in which case the
relative movements will have exact meaning to the player)

> you simply saying that you'd like to have a system that's designed to
> operate in this way so a person doesn't have to do it him or herself,
> or are you aiming to do something that can't be done at all in
> existing systems?
>

(Do you mean person as in player or programmer...?) The system is mainly
designed for me and my games-- but if/when it is implemented, and after my
first game with it is produced, I would share with anyone who wants to use it.
There are features of my planned system that I don't think would work very
well in traditional systems.

> > The current theory is that it would help illustrate to the player the world
> >they're playing in without splitting the world into artificial chunks, like
> >'rooms',
>
> But you are, aren't you? The chunks are just smaller. The player is
> still moving around in fits and starts to certain allowable locations;
> he can't just move to any arbitrary position within a room (or sector
> or whatever). Right? If so, then the world is still split into
> artificial chunks.
>

The chunks are no smaller, they just aren't as absolute. In most I-F, no
matter how close you are to a location, without being there, you can't find
out anything about it-- not even what sort of location it is, something that
should be readily obvious. The player -can- move within sectors, most often
by 'moving toward' (or away from?) an object-- the focus follows them. In
point sectors this would be completely meaningless- there's nowhere to go
except out. In linear sectors this does mean something. If you're at one end
of a hall you can see whatever there is to see there, and somewhat less of
what there is to see at the other end. (My original design spec says that
anything within a sector is something you can see or know is there, except in
special cases.. the sparse desert example is one, which is in the example
implemented as a single huge sector to save the work of implementing many
smaller sectors (worthless effort, if the player can't tell when he passes
from one to another)) The artificial chunks are still there, but hopefully
more convincing artificial chunks- and, of course, you can see what's near
you. Specific movements within all sectors (where applicable) would be
supported-- but very very much not recommended, since the interface for that
is crap in text interface. (Except, as I said, in special cases- sparse
desert following a map, for a planar example... in linear sectors it might
not be too useful- the only example I've come up with for that is something
that may be in my game-- a long row of bed-like things, occupied. Due to
specific circumstances in the game it wouldn't be artificial for the beds to
be numbered or named, so relative movements still wouldn't be necessary)

> >and that it would make an actual representation of the cause of
> >certain game challenges- for example, you can't reach a ceiling fan because
> >it's on the ceiling. If you were taller, or stood on something tall enough,
> >you could reach the ceiling and so reach the fan... that part done without
> >much special coding, in theory.
>
> This can be done already. Again, a system like you're talking about
> would no doubt make it easier, but it's already doable. Hugo, for
> instance, has a routine that can be called to check to see whether a
> thing is within the player's reach or not. You just have to tell it
> what's within reach and what not at any given time (which, in
> practice, is easier than it sounds).
>

But does the programmer still need to special-case every object the player
could stand on to reach the goal? -- Disclaimer- This argument concerns
what I would probably make a tertiary design goal of the system, so nothing
can be totally resolved just yet...

> >> I can do what you're proposing with my current system. If I tie a
> >> scope-handling routine to the "walk to idol" action (or whatever),
> >> I've done effectively the same thing as you're talking about, haven't
> >> I? The only thing I can't handle is the continuum in between--and this
>
> > Have you? What is your current system? From what I've seen both TADS and
> >Inform are quite thoroughly split into their individual rooms, and generally
> >there's no way to learn anything about a location you're not in.
>
> I use Hugo and it, like TADS and Inform, is thoroughly split into its
> individual rooms. But you're talking about the systems' default
> behavior. I'm suggesting that it's not such a huge chore to change the
> default behavior (at least in Hugo) and get done what you want to get
> done. Well, I take that back--at least partly. It *could* be a huge
> chore, depending upon the situation, but there's no reason in
> principle why a person couldn't write the code necessary to do the
> things you're talking about. It would just require conditionals; e.g.
> *if* the player is standing near the idol then put objects x,y,z out
> of scope and bring objects a,b,c into scope. How do I know the player
> is standing near the idol? Because he issued the "walk to idol"
> command (or whatever).
>

Well, as I said, in the original design spec I said that anything in one
single sector is always in scope and in some peripheral vision. (player being
assumed to have seen everything coming in, and remember what's behind them,
and probably look at anything that enters) I think the method you describe
could work-- but it would be a different style of goal, I think, just
slightly. If you expanded scope rules to include parts or major details of
adjacent rooms, 'grouped' all objects into a room into groups of objects that
are close together, and assume everything else is not close to any objects in
the group, it would work... Any examples I could really come up with to
suggest this is inadequate would be very contrived and academic, sort of like
the whole 3 object verb situation, because my system hasn't been implemented
yet, so no one (I dare say) knows what games would be like under the
'Sector-system'. It's going to be an experiment, obviously, to try to make my
first game under this (still just roughly sketched out) system... And my hope
is that, by providing certain features in text games that no one ever missed
(not having had them) someone will stand up and say 'this is NEAT!'

> >If you 'walk
> >to' an object that has no real location of any sort within a room, how do you
> >know you're not next to some other objects, or farther away from some others?
>
> You have to tell the player in your room/object/event descriptions.

(But how can the game tell them if it doesn't know?)

> There's no other way. Even with your system, if I'm understanding it
> correctly, that doesn't change. Unless the player has some real,
> concrete, distance-based way of moving (i.e. "walk x meters forward"),

They would. It's just not a very friendly way of moving, so it's not to be
used much. (Except, as I said, in very special circumstances. If Captain
Hookworm says the treasure's 50 paces toward the crocodile rock, then 28 paces
toward the tar pin, then come hell or high water that's where I'm a-gonna go!)
The original decision to include 'measured' locations and distances in certain
types of rooms came from some specific needs in my game, and the possible
bonuses I saw for it. (measuring 'closeness', better(?) implementation of
'out of reach' scenarios, and possibly (hopefully) giving the player a better
representation (and so, a better idea) of the environment they're in.)

> she will still have no way of knowing her relative position within an
> area unless you tell her. But you could do that right now in Inform by
> simply running an event every time the player moves telling her where
> she is, what's close by, what's not, etc.
>

As I said.. I think that would work, but it's a different goal than mine..

> I can see that having a system that handles scoping in this way would
> make things easier for the author, if this is in fact the kind of
> scoping system an author wants to have. No argument there. He wouldn't
> have to manually do all the hiding and unhiding of objects, etc.

I can't readily come up with much in the way of -serious- problems wih
using a 'smooth' moving focus based in part on position and orientation.. or
of redefining sight, reach, and grasp to use the characteristics of position
I've already decided I probably want to include...

> Moreover, I expect one could devise something like a Doom level editor
> to lay out a game environment with CAD and then output primitive
> sector and object definitions to a shell source file, which would be
> kinda neat.
>

Well, I don't think bringing CAD into this would be worthwhile, really,
unless you want to provide the user with a complete detailed map (something I
have considered).. the game world -still- wouldn't be defined exactly (with
good reason) so one would still have to make sure that the editor understands
that, even if something is just a point or a line in the game, on the visual
map it should look like a corridor junction or a hallway or whatever..

> > Movement by location name, dropping the artificial '12 directions'
> >(including only 4, up, down, in, out), scoping that includes adjacent rooms
> >without flooding the screen with crap,
>
> This isn't an English sentence :)
>

...But don't you just have to love its (not it's) homespun charm??

> Right. I see that's not what you're attempting, but it just seems to
> me that most of your hard work will have been unnecessary if you're
> sticking with discrete movement as opposed to continous. You can, I

Perhaps. I guess I need to evaluate the usefulness of having relative
positions of everything already defined.

-
What does it say about my dorm room to know that from where I am, my desk
and two computers are in front of me, the exit is ahead and to the left, my
low bookshelf and stereo are to my right, my refrigerator to the left, and
that my bed, closet, and window are somewhere behind me?
Or that, if standing in front of the refrigerator, the closet is ahead and
to the left, the exit is to the right, the window is to the left, and that my
desk, bed, and low bookshelf are behind me?
Or that, if standing on the bed, looking at the door, my refrigerator is
in front of me, my desk is ahead and to the right, my closet and window are
ahead and to the left, my low bookshelf is ahead and to the right..?

I guess it's my hope that seeing the same room from multiple points would
help the player understand the sort of room he's in.

> believe, just modify Inform to behave the way you want (it's been
> awhile since I used Inform, though; I know you could do it with Hugo).
> A crude example off the top of my miter:
>
> Let an Inform room be actually what you're calling a sector. Then, to
> create a "room", you would simply create however many sectors were in
> it--let's say nine. Now, modify the scope rules so that sectors
> (rooms, to Inform) adjacent to the occupied one are in scope. How do
> you do that? Give each sector/room a property that lists the sectors
> adjacent to it and check the list from your scoping routine. Not that
> difficult. But what about line-of-sight problems? What if there's a
> vase behind an in-scope idol that the player shouldn't be able to see
> from where he's standing? Well, there are, in fact, no such
> line-of-sight problems, since the player can never occupy an arbitrary

I don't intend to implement line-of-sight problems except (possibly) crude
ones between rooms- for example, if looking from one large room to another,
you can only see to the other room in a limited set of directions... Line of
sight problems that merely involve large objects in the way should probably be
special cases-- (but then again, wouldn't be much of a special case, since we
could make the large object declare exactly what areas it would be blocking...
but it's not a major concern at this point)

> position within a sector. He is always notionally wherever the author
> intends him to be. Hence, the author always knows what the player can
> see or not see at any given time (this is what I've been trying to get
> at with my talk about continuous movement--if movement is discrete,
> much of what you're talking about seems to be wasted effort). You

Possibly. Like I said, I believe some of this will only be really determined
through experimentation.

It should also be noted that, if you took what you just talked about, only
made the number of adjacent sectors arbitrary and made movement happen mostly
by 'go to' object or location name, you would basically have my proposed
system without planar or linear sectors. (and without any exact distances
implemented, but distance implementation is trivial for between points, it may
as well be included/includable..)

> Granting the limit on the number of rooms available for use, which,
> using this method (there are others), presents a problem for big
> games, isn't this possible and isn't this essentially the same as
> you're trying to do?
>

In some ways it is exactly what I'm planning to do- even down to the
specific implementation. In other ways, it's not. I think you've put
forward what could be a better way to think about large rooms than planar
sectors.

George Caswell

unread,
Nov 20, 1996, 3:00:00 AM11/20/96
to

On 18 Nov 1996, Jason B Dyer wrote:

> George Caswell (timb...@adamant.res.wpi.edu) wrote:
> : I expect as much. My goal is to make the system never, or at least almost
> : never rely on the use of explicit relative movements--

> : My hope is to make all


> : the location-to-location movement by
> : location or exit name, or by some other such...
>

> The only problem is this gets quite tedious after a while. N/S/E/W
> is really just a convention so that IF players don't go crazy
> just trying to move around.
>

...Which is why I'm thinking of including some sort of auto-navigation that
would allow the player to go to location by name without going step by step.
Declaring that reaching certain points from each other is a trivial action is
another way this could be handled in many cases- something that could be done
with any movement system currently in use...

> Also, this would require exits that were all different. If you
> have a room with multiple doors, all that look the same, things will

Actually, it would require that either the exits or the locations the exits
-lead- to are distinct.

> Another problem:
>
> +--+ +--+ +--+ +--+
> |A |-| |-| |-|B |
> +--+ +--+ +--+ +--+
>
> To get from point A to point B the player would have to type three
> different commands as opposed to E. E. E. You could give each

This situation clearly depends on what is in between points A and B- that
would change how the situation would be implemented. (If it's a hallway or
some such, as it appears it might be, they could all be in the same sector...)
And if any room has only two exits, there would be a default verb to go to the
-other- one than the one you just entered in... And in the general case, the
'forward' direction is opposite the direction you're coming from, so moving
from A in this particular situation would only require you to use a single
action to reach the first corridor space- from there you could either do
'forward' the next two turns or use the 'default' verb, whatever I can come up
with for that.

Granted, quick motion through large areas of maze would be more tedious, so
I see the problem. I can't make real solutions for a vague problem, however-
There are certain things my system would do better than the traditional (much
better, I hope) and certain things it won't. In context, your problem might
not be a problem- the specific conditions of the implemented locations might
not require four separate locations.

Greg Falcon

unread,
Nov 20, 1996, 3:00:00 AM11/20/96
to

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

>I suspect it wouldn't be much of a problem. The Z-machine is limited in
>the number of variables, but not the number or size of arrays or object
>properties. Most of the info for any OO system winds up in the objects.

The spec says that objects can only have 64 properties and that object
property data can not be more than 64 bytes per property. (I'm
talking about "The Z-machine", not Inform... I know Mr. Nelson made a
lot of changes and I haven't learned them all yet.)

12.4.2 In Versions 4 and later, a property block instead has the form

<size and number> <the actual property data>
--1 or 2 bytes--- --between 1 and 64 bytes--

The property number occupies the bottom 6 bits of the first
size byte.

2^6=64, thus only 64 property numbers, thus...

[End Peanut Gallery Mode]
Greg

--
This space for rent.


Andrew Plotkin

unread,
Nov 20, 1996, 3:00:00 AM11/20/96
to

Greg Falcon (professo...@pnx.com) wrote:
> erky...@netcom.com (Andrew Plotkin) wrote:

> >I suspect it wouldn't be much of a problem. The Z-machine is limited in
> >the number of variables, but not the number or size of arrays or object
> >properties. Most of the info for any OO system winds up in the objects.

> The spec says that objects can only have 64 properties and that object
> property data can not be more than 64 bytes per property. (I'm
> talking about "The Z-machine", not Inform... I know Mr. Nelson made a
> lot of changes and I haven't learned them all yet.)

Fine, I'll rephrase: "Inform is limited in the number of variables, but
not the number or size of arrays or object properties. Therefore, you can
use Inform for this programming project, and it will work on the
Z-machine."

(Actually I'm not quite sure that private properties can be of unlimited
size.)

Cardinal Teulbachs

unread,
Nov 20, 1996, 3:00:00 AM11/20/96
to

George Caswell <timb...@adamant.res.wpi.edu> wrote:

I'm gonna bump something you say later on up here to the front, since
it might be the key to the whole "dispute":

>The Cardinal speaks:


>> There's no other way. Even with your system, if I'm understanding it
>> correctly, that doesn't change. Unless the player has some real,
>> concrete, distance-based way of moving (i.e. "walk x meters forward"),

>George replies:


>They would. It's just not a very friendly way of moving, so it's not to be
>used much. (Except, as I said, in very special circumstances. If Captain
>Hookworm says the treasure's 50 paces toward the crocodile rock, then 28 paces
>toward the tar pin, then come hell or high water that's where I'm a-gonna go!)
>The original decision to include 'measured' locations and distances in certain
>types of rooms came from some specific needs in my game, and the possible
>bonuses I saw for it. (measuring 'closeness', better(?) implementation of
>'out of reach' scenarios, and possibly (hopefully) giving the player a better
>representation (and so, a better idea) of the environment they're in.)

I think I must have totally misunderstood you. You seem to be saying
here that both the continuous type of movement (basically, freedom of
movement in any direction and to any distance) *and* the discrete or
relative, "walk to idol"-type movement will be implemented? If so,
then I'm arguing about nothing. I thought you had dumped the "walk x
meters forward" mode completely. If you're still going to have it
available for use, then I can't see any way *but* the one you're
proposing to do it.

Nevertheless, I shall blunder on as if you hadn't said this...

>> I think I see what you're getting at. But aren't you just in fact
>> dividing rooms into smaller rooms and changing the scope-checking
>> behavior? Why can't a person do that now, by making a notional room
>> consist of nine actual rooms and then modifying the scope rules? I'm

> The visible scoping rules alone could be done that way. The idea about
>widening scope as I see it isn't to make individual rooms smaller, but to
>leave most rooms the way they are and allow the player to see things they
>wouldn't be able to see otherwise from their current position.

Well, let's be clear what we mean when we talk about "smaller" rooms.
Rooms have no definite size. A single room can be used to represent a
vast desert or the tiny head of a pin, so when I say you're dividing
rooms into smaller rooms I don't mean they're smaller in the sense of
absolute size, but rather with respect to the scoping rules. Now,
given that scope extends by default in current systems to whatever's
in the same room with you, the new system you're talking about is
really only a way of dividing a room into x number of "smaller" rooms
such that the "smaller" room is the basic "unit of scope". You might
then extend the range to encompass adjoining rooms depending upon the
situation, but you will always have your fundamental unit of scope as
a baseline. My point has been that this is no different from what we
have now, and that instead of dividing up a room to get your "unit of
scope" the way you now propose, one could alternatively multiply a
room in an existing system so that it was several "units of scope"
large and accomplish the same thing.

>For example,
>if a player is on one point of a street, why wouldn't he be able to get at
>least a basic idea of what is east or west from his point on the (east-west)
>street? If the player's in a hallway of a college building, why wouldn't he
>be able to see what's in any of the rooms without entering them? All of this
>can be done with the current systems with careful programming and condition
>checking-- My system as currently sketched out would make this behavior no
>easier to refine, but the behavior would at least be available by default.

Ok. No small point. Like I said, having this kind of scoping behavior
built in would definitely take a load off the programmer's (yours or
whomever's) workbench.

>And the system I'm trying to work out here includes new scoping, new movement,
>new implementation of 'can't reach it' scenarios (meaning that the cause of
>being unable to reach something would be implemented)

What does it mean, exactly, that this would be implemented? I've
understood you to be saying that you'd use something like a Cartesian
coordinate system to locate everything within the game environment. If
so, then I guess things would have specific heights and that when you
say it "would be implemented" you mean that the system would
automatically calculate whether something was reachable or not at the
time the reach attempt was made without the game author having to
figure everything out manually beforehand?

>and implementation of
>areas normal movement systems have trouble with. (line and planar sectors.
>Line sectors will probably be included if/when I make the system-- if not
>then the system will be basically modified scope rules, trivial position data,
>and the removal of most compass points. Planar sectors I'm really not sure
>about-- They're meant only to implement the odd case where something can't be
>appropriately expressed as other sector types-- the vast sparse desert, for
>example... relative movement within them would be very difficult except in
>special cases (IE the player is given a map to follow, in which case the
>relative movements will have exact meaning to the player)

George, this is weird. You mean you actually want to implement a
desert in which the player wanders around aimlessly until she deletes
your game off her hard-drive?

>> you simply saying that you'd like to have a system that's designed to
>> operate in this way so a person doesn't have to do it him or herself,
>> or are you aiming to do something that can't be done at all in
>> existing systems?
>>
> (Do you mean person as in player or programmer...?)

Programmer, but I've got the answer to this one now.

>> But you are, aren't you? The chunks are just smaller. The player is
>> still moving around in fits and starts to certain allowable locations;
>> he can't just move to any arbitrary position within a room (or sector
>> or whatever). Right? If so, then the world is still split into
>> artificial chunks.
>>
> The chunks are no smaller, they just aren't as absolute. In most I-F, no
>matter how close you are to a location, without being there, you can't find
>out anything about it-- not even what sort of location it is, something that
>should be readily obvious.

This is true in one sense and not true in another, I think. It's true
that if you stick to the beginner's, gold-skull or marzipan-cone,
level of programming, then the locations will likely be as chopped up
as you describe. There's nothing to keep you from fuzzing up room
boundaries, though, in existing systems by making objects present in
two locations at once (or duplicating them) and by providing multiple
room/object descriptions (and etc.).

>The player -can- move within sectors, most often
>by 'moving toward' (or away from?) an object-- the focus follows them. In
>point sectors this would be completely meaningless- there's nowhere to go
>except out. In linear sectors this does mean something. If you're at one end
>of a hall you can see whatever there is to see there, and somewhat less of
>what there is to see at the other end. (My original design spec says that
>anything within a sector is something you can see or know is there, except in
>special cases.. the sparse desert example is one, which is in the example
>implemented as a single huge sector to save the work of implementing many
>smaller sectors (worthless effort, if the player can't tell when he passes
>from one to another))

Have one sector represent many sectors; i.e. when the player exits a
sector that only leads off into the desolate infinite, increment a
counter or something to keep track of his notional location and put
him right back in the same sector. I've used single rooms in both
Inform and Hugo this way to represent just the sort of wide-open
spaces you're talking about. You just have to do some object-looping
to remove dropped objects and put 'em back and so on.

>> This can be done already. Again, a system like you're talking about
>> would no doubt make it easier, but it's already doable. Hugo, for
>> instance, has a routine that can be called to check to see whether a
>> thing is within the player's reach or not. You just have to tell it
>> what's within reach and what not at any given time (which, in
>> practice, is easier than it sounds).
>>
> But does the programmer still need to special-case every object the player
>could stand on to reach the goal?

Yes. Not fun if there's gonna be a whole lotta ceiling-fan-reachin'
going on. At the same time, there's no reason why I couldn't give all
my objects a "height" property and then include a routine that does a
height check whenever some notionally high-up object is acted upon.

> Well, as I said, in the original design spec I said that anything in one
>single sector is always in scope and in some peripheral vision. (player being
>assumed to have seen everything coming in, and remember what's behind them,
>and probably look at anything that enters) I think the method you describe
>could work-- but it would be a different style of goal, I think, just
>slightly.

I know it works. I'm using it right now :) You're right, though, that
the goal is different. I have no intention of simulating real-space,
whereas that seems to be what you're aiming to do. Everything in my
game exists just where I imagine it, and only there. A player can't go
dropping his dadburned ceiling fan just anywhere; he can only drop it
where I say he can drop it--by which I mean he can't drop it "three
meters northeast of the table"; he can drop it on the table or on the
floor, and in either case there's a specific imaginary location that
it occupies within the room. There are lots of reasons for this, not
the least of which is that I'm telling a story. You appear to be
tilting toward the game or "experience" side of things.

>If you expanded scope rules to include parts or major details of
>adjacent rooms, 'grouped' all objects into a room into groups of objects that
>are close together, and assume everything else is not close to any objects in
>the group, it would work...

Right. But the grouping is all imaginary. I know what the player can
see and can't see at any given time, so I know which objects should be
in scope and which not. I don't have to assume anything.

>Any examples I could really come up with to
>suggest this is inadequate would be very contrived and academic, sort of like
>the whole 3 object verb situation, because my system hasn't been implemented
>yet, so no one (I dare say) knows what games would be like under the
>'Sector-system'.

Well, let me help you then :) It's already been pointed out by us both
that, even if I can do what you're talking about, it's still work.
It's not something that's provided for in terms of default behavior in
any existing system (that I know of). Thus, those systems are
inadequate in that sense at least. But then I think that that kind of
determination finally has to be measured against the kind of i-f one
is wanting to write. I think your system will not be particularly
suitable for storytelling, but will be very suitable for gaming.
Storytelling is by its nature linear, but "gaming" or "experiencing"
tends to favor a more wide-open approach.

>It's going to be an experiment, obviously, to try to make my
>first game under this (still just roughly sketched out) system... And my hope
>is that, by providing certain features in text games that no one ever missed
>(not having had them) someone will stand up and say 'this is NEAT!'

Well, I certainly will, but that will probably be more directly
determined by how well you use the system you create than it will by
the system's brute functionality.

>> >If you 'walk
>> >to' an object that has no real location of any sort within a room, how do you
>> >know you're not next to some other objects, or farther away from some others?
>>
>> You have to tell the player in your room/object/event descriptions.

> (But how can the game tell them if it doesn't know?)

This perfectly displays our different perspectives. I don't need or
want the game to tell the player these things because *I'm* the one in
charge. I'm writing the story. I know where the player is at all
times; I know the possible range of his actions; I know what I will
allow and won't allow. You, on the other hand, want to be rid of that
responsibility. You want to let him explore more or less where he will
and have a preprogrammed engine keep track of him and what he can see,
etc.

Follow what I'm saying? It's true enough that you as the author will
still write all the object descriptions and whatnot, but you're doing
it with the player's freedom of movement in mind. I'm not. I don't
want the player roaming all over the place. I only want him to be
where I want him to be. I tell him what he can see and what he can't
because I know what he can see and what he can't and I know these
things because I happen, as the game god, to know the precise spot
he's standing in.

>> Moreover, I expect one could devise something like a Doom level editor
>> to lay out a game environment with CAD and then output primitive
>> sector and object definitions to a shell source file, which would be
>> kinda neat.
>>
> Well, I don't think bringing CAD into this would be worthwhile, really,
>unless you want to provide the user with a complete detailed map (something I
>have considered).. the game world -still- wouldn't be defined exactly (with
>good reason) so one would still have to make sure that the editor understands
>that, even if something is just a point or a line in the game, on the visual
>map it should look like a corridor junction or a hallway or whatever..

I wasn't thinking of mapping for the player, but only of laying out
the game map and generating a source file when designing. This is on
the supposition that you're using some kind of coordinate system to
give everything an absolute location. If not, CAD couldn't do anything
for you.

> What does it say about my dorm room to know that from where I am, my desk
>and two computers are in front of me, the exit is ahead and to the left, my
>low bookshelf and stereo are to my right, my refrigerator to the left, and
>that my bed, closet, and window are somewhere behind me?
> Or that, if standing in front of the refrigerator, the closet is ahead and
>to the left, the exit is to the right, the window is to the left, and that my
>desk, bed, and low bookshelf are behind me?
> Or that, if standing on the bed, looking at the door, my refrigerator is
>in front of me, my desk is ahead and to the right, my closet and window are
>ahead and to the left, my low bookshelf is ahead and to the right..?

It says that your dorm room has all the charm of a carburetor repair
manual. Honestly, you lost me at "the exit is ahead and to the left."
I never, ever, want that kind of tedious detail unless it's necessary
for some reason. I want a vivid but general sense of what your dorm
room looks like, and mention only of objects in it that for whatever
reason seem worthy of note. I don't care to know, for instance, that a
dirty t-shirt lies slightly to the left of and behind your writing
desk unless a) the dirty t-shirt has some significance, or b) you're
using it to imply what a poor housekeeper you are, and in either case
I don't need to know more than that it's on the floor.

And no, I haven't been spying on you :)

> It should also be noted that, if you took what you just talked about, only
>made the number of adjacent sectors arbitrary and made movement happen mostly
>by 'go to' object or location name, you would basically have my proposed
>system without planar or linear sectors. (and without any exact distances
>implemented, but distance implementation is trivial for between points, it may
>as well be included/includable..)

Yep. That was my point, and even though you mention making the number
of adjacent sectors arbitrary, you still haven't evaded my grasp. Your
rooms are still of some definite size, so they can be duplicated with
my "cheat".

--Cardinal T

I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan

Are there any text games prominently featuring dinosaurs?
If not, does anyone besides me think it would be cool?
--Matthew Amster-Burton

"Cyber-Babushka"
--Bonni Mierzejewska

"Bathroom? Yeah. Go through that door, on the end
of the hall, on your left." "Pardon?" "South twice,
than east." "Ah."
--Clyde Sloniker


Greg Ewing

unread,
Nov 21, 1996, 3:00:00 AM11/21/96
to

Cardinal Teulbachs wrote:
>
> Why can't a person do that now, by making a notional room
> consist of nine actual rooms and then modifying the scope rules?

This wouldn't necessarily give quite the same result. A
geometry-based scope system could easily describe situations
such that, for example, when you are standing by the door
you can reach the door, the light switch and the dresser, when you
are standing by the dresser you can reach the light switch and
the bed but not the door, and when you are standing by the bed
you can reach the dresser and the bedlamp but not the light
switch, etc; while at the same time you can see anything in
the room from any position.

It would be possible to implement this using traditional
rooms and scoping techniques, but it would be tedious and
bug-prone. With a geometrical system it would all fall out
automatically.

Greg

Cardinal Teulbachs

unread,
Nov 21, 1996, 3:00:00 AM11/21/96
to

Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:

>Cardinal Teulbachs wrote:
>>
>> Why can't a person do that now, by making a notional room
>> consist of nine actual rooms and then modifying the scope rules?

>This wouldn't necessarily give quite the same result.

Yes, it would, as I think you admit later on:

>It would be possible to implement this using traditional
>rooms and scoping techniques, but it would be tedious and
>bug-prone. With a geometrical system it would all fall out
>automatically.

Righto. We are in complete agreement.

I think the only point in dispute now (and I don't even know for sure
that it's a point of dispute) is whether the kind of real-space
environment George is talking about is suitable for i-f--well, not
that really. It's whether that environment is well suited to the
literary variety of storytelling. I say it's not.

--Cardinal T

I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan

Are there any text games prominently featuring dinosaurs?
If not, does anyone besides me think it would be cool?
--Matthew Amster-Burton

"Cyber-Babushka"
--Bonni Mierzejewska


"Bathroom? Yeah. Go through that door, on the end
of the hall, on your left." "Pardon?" "South twice,
than east." "Ah."

--Clyde "Fred" Sloniker


George Caswell

unread,
Nov 22, 1996, 3:00:00 AM11/22/96
to

On Thu, 21 Nov 1996, Cardinal Teulbachs wrote:

> I think the only point in dispute now (and I don't even know for sure
> that it's a point of dispute) is whether the kind of real-space

First let me say I have no intention of implementing a real-space
environment. My intention in the context of expressing dimension within the
sector system was in small part specific to my game, but also for giving the
game world some dynamic but consistent detail. Not full detail, and certainly
not all of what detail is implemented would be shared with the player- but
some detail. Whether or not that is a good idea, whether or not it will work
right, make descriptions artificial, be totally necessary, etc. is completely
academic, since I don't know if I would actually make it a part of the sector
system.

> environment George is talking about is suitable for i-f--well, not
> that really. It's whether that environment is well suited to the
> literary variety of storytelling. I say it's not.
>

It could very well be a bad idea, in which case I'm open to suggestions. I
hope I don't need to remind anyone (myself included) that this isn't meant to
be any sort of argumentative process.. (except, possibly, on the point that
movement and scoping might be better after steps in the directions I
propose... the planar sector idea was, from the beginning of 'take 2',
considered bug-prone, hard to implement, and more or less not worthwhile...)
As I've said, planar sectors are not a main feature of the sector system-
just something that might be used in cases where a place can't be
well-represented otherwise.
As for whether the level of detail I propose to -record- belongs in IF, I
would say it certainly does not-- another reason my original 'take 1' example
was terrible. But I think -recording- the data and allowing the program to
use it can be beneficial. Clearly, except in very, very special
circumstances, the player need know nothing about actual game-world distances-
But I tend to think that making descriptions more dynamic and comprehensive of
the world around the player (esp. focus outside of current location) is a good
thing, and I still think that the basic idea I'm running with here is the
right approach.
Just as I'm not ready to totally dismiss the system's reliance on
'move-by-name' with relative direction as backup (planned in the hope of
eliminating most compass points) I'm not ready to totally dismiss the possible
good that can come from planar sectors in the system- But for now the
negative still outweighs the positive. About the best I can come up with
-right now- for the use of a planar sector in your basic indoor environment
would basically be the plane (as always) with multiple points within the plane
as places objects or the player character can be within the room. Scoping may
still take distance into account (or not)- basically it would be like the
multi-room description of 'sectors', except only one room would be used, and
scoping wouldn't need to follow links between rooms to figure out what you can
see. This, too, is a sketchy idea, not necessary, not necessarily to be used,
but a thought.
I think what -really- should be the discussion of 'take 2' are the -basic-
ideas. It does no one any good to argue over -hypothetical- features of the
sector system- and planar sectors have been, and continue to be very
hypothetical. What about the basic concepts? I've heard how some people feel
about eliminating absolute compass points, and some strong argument against
trying to do step-by-step move-by-name... (Which led to thought of a learning
autonav... which is not a complete solution) So it's quite possible I'll
need to profane my system with absolute direction until a better idea comes
along...
The sector system represents a number of ideas I've had about what I-F
could be, stuck rather confusingly together into a single system.
Unfortunately I think we've been discussing a little too long and hard about
'fringe' features, things that could become added bonuses of implementing
sectors in the ways I thought about, or features, like 1 and 2 dimensional
sectors, I included because I saw them as the best solutions to various
problems... Hm. Anyway, thoughts welcomed, just keep that in mind- Even the
concept of the system is definately not complete, so don't waste too much time
criticizing 2 and 3 dimensional representations, planar sectors, distance,
obscurity, or light representation, relative direction and object orientation,
etc., etc., etc., not for now, anyway. Consider such features hypothetical
extensions for the time being- discuss them as what they are right now--
possibilities. For now it might be better to stick to the basics- Sectors,
focus between them with and without accounting for orientation or distance,
relative, absolute, and 'by name' movement, any other movement you can
recommend, etc... Thanks for the help.

Carl Muckenhoupt

unread,
Nov 22, 1996, 3:00:00 AM11/22/96
to

card...@earthlink.net (Cardinal Teulbachs) writes:

>I think the only point in dispute now (and I don't even know for sure
>that it's a point of dispute) is whether the kind of real-space

>environment George is talking about is suitable for i-f--well, not
>that really. It's whether that environment is well suited to the
>literary variety of storytelling. I say it's not.

But then, neither is the traditional Infocomesque system, with its heavy
reliance on object manipulation and limited interaction with characters.

Game mechanics affect the kind of story you tell. A detailed combat
system makes for stories about fighting. Sophisticated character
interaction produces character-based stories. A movement system like
the one proposed will produce stories where movement and position are
very important. It's up to the author to come up with a plot where this
is appropriate. I can think of a couple of possibilities offhand.
A prison escape, for example, where you want to remain out of sight and
out of reach whenever possible. Or an Indiana Jones-ish thing, where
it can matter a great deal exactly where you're standing when you pick
up the golden idol. Or a baseball game (presumably as part of a larger
story in which baseball is important.)

--
Carl Muckenhoupt | Text Adventures are not dead!
b...@tiac.net | Read rec.[arts|games].int-fiction to see
http://www.tiac.net/users/baf | what you're missing!

George Caswell

unread,
Nov 22, 1996, 3:00:00 AM11/22/96
to

On 22 Nov 1996, Carl Muckenhoupt wrote:

> card...@earthlink.net (Cardinal Teulbachs) writes:
>
> >I think the only point in dispute now (and I don't even know for sure
> >that it's a point of dispute) is whether the kind of real-space
> >environment George is talking about is suitable for i-f--well, not
> >that really. It's whether that environment is well suited to the
> >literary variety of storytelling. I say it's not.
>
> But then, neither is the traditional Infocomesque system, with its heavy
> reliance on object manipulation and limited interaction with characters.
>
> Game mechanics affect the kind of story you tell. A detailed combat
> system makes for stories about fighting. Sophisticated character
> interaction produces character-based stories. A movement system like
> the one proposed will produce stories where movement and position are

> very important. It's up to the author to come up with a plot where this

Actually, I would hope that this would be true for the sector system no
more than it is for the regular Infocom-ish system. (Clearly, the system
needs work, or some major concessions in the area of absolute direction,
before this can be true.. but...) Hopefully it will not necessarily be a
higher or lower resolution situation, just one where you know a bit more about
your neighborhood and movement is of a different style.

Phil Goetz

unread,
Nov 23, 1996, 3:00:00 AM11/23/96
to

In article <5734ud$q...@uruguay.earthlink.net>,

Cardinal Teulbachs <card...@earthlink.net> wrote:
>
>I think the only point in dispute now (and I don't even know for sure
>that it's a point of dispute) is whether the kind of real-space
>environment George is talking about is suitable for i-f--well, not
>that really. It's whether that environment is well suited to the
>literary variety of storytelling. I say it's not.
>
>--Cardinal T

I want to develop my IF system to sit on top a graphics engine,
possibly RenderMan or Quake. I'm worried about this issue -- can IF
as we know it survive the marriage?

Phil Go...@cs.buffalo.edu

George Caswell

unread,
Nov 23, 1996, 3:00:00 AM11/23/96
to

On Thu, 21 Nov 1996, Greg Ewing wrote:

> Cardinal Teulbachs wrote:
> >
> > Why can't a person do that now, by making a notional room
> > consist of nine actual rooms and then modifying the scope rules?
>

> This wouldn't necessarily give quite the same result. A
> geometry-based scope system could easily describe situations
> such that, for example, when you are standing by the door
> you can reach the door, the light switch and the dresser, when you

Still possible with the use of 'rooms' as points within a room and
extending scope to nearby points... in other words, 'near the door' is one
'subroom' point, from which you can see everything there, outside the door,
and to any nearby points in the room...
The planar ('geometric') implementation would have the advantage of
flexibility (points within the room could be generated and eliminated
dynamically, moved about, obstacles that encompass multiple points within the
room would be trivial to implement and would work simply and logically, etc.)
and the advantage of using only one object for the room. It also might make
coding cleaner (or not) - rather than creating a 'group' object for the entire
room, individual points defined as rooms within it, and using that to decide
scoping within the room, positions within the room, etc, one would just create
the room and any objects within it- the object locations would become the
basic points on interest within the room and so, more than likely, the only
places the player would go... with implied 'approach' (go to) for most verbs,
this would be no more or less convenient to the player than implementing each
location in the room as an object.

Cardinal Teulbachs

unread,
Nov 23, 1996, 3:00:00 AM11/23/96
to

Ok. I think I've figured it out. Tell me if this is right:

A sector is your basic unit of scope. Scope always extends from the
player to at least the boundaries of the sector he's in. However, as
you have it planned, scope can also extend beyond the boundaries into
neighboring sectors, either completely or partially.

Now, the scope *focus* follows the player around in the same way that
the glow from a lamp follows a lamp, but it doesn't do so smoothly. At
some point, there's a jump where focus suddenly extends all the way
across an adjoining sector instead of only halfway into it (or
whatever). At least, I presume it's this way since you say you're not
interested in a real-world model, which would require a continuous
transition.

Nevertheless, the player can move around more or less continuously if
he chooses; he doesn't have to move in synch with the focus jumps.
Hence, the range of his vision will be the same, let's say, whether
he's two inches into a sector or two inches short of halfway. It's
only when he passes over the halfway mark (or whatever boundary you
set) that the scope changes.

Am I close so far?

--Cardinal T

I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan

Are there any text games prominently featuring dinosaurs?
If not, does anyone besides me think it would be cool?
--Matthew Amster-Burton

"Cyber-Babushka"
--Bonni Mierzejewska

Greg Falcon

unread,
Nov 23, 1996, 3:00:00 AM11/23/96
to

go...@cs.buffalo.edu (Phil Goetz) wrote:

>I want to develop my IF system to sit on top a graphics engine,
>possibly RenderMan or Quake. I'm worried about this issue -- can IF
>as we know it survive the marriage?

Of course it couldn't survive "as we know it". That's too radical a
change.

But don't be afraid to try it. Everybody is into IF for their own
reasons. My reason is to have fun... I won't be scared off by a 3d
graphics engine.

(You still have to have a good game, though.)

Look at Resident Evil for the playstation. It was mostly a huge
slaughterfest, but there were a few IF style puzzles in it. (Dumping
the chemical in the sprinkler system, or placing gems, or playing the
piano, or the emblem swapping, or...) I could imagine that a highly
graphical game could survive the transition if you didn't put 400
undead warriors in the game.

But it wouldn't be the same, and you would lose a portion of your
audience. And you would gain new members to your audience. I think
it sounds like it might have a future.

May I make one suggestion? Never remove the command line. Sierra
games were so much better when you TYPED what you want to do.

My $0.02
Greg

(I know that some of you are laughing at me because I've touched a
Playstation before. So be it.)

George Caswell

unread,
Nov 23, 1996, 3:00:00 AM11/23/96
to

On Sat, 23 Nov 1996, Cardinal Teulbachs wrote:

> Ok. I think I've figured it out. Tell me if this is right:
>
> A sector is your basic unit of scope. Scope always extends from the
> player to at least the boundaries of the sector he's in. However, as
> you have it planned, scope can also extend beyond the boundaries into
> neighboring sectors, either completely or partially.
>

Yes. Special cases to this rule have been considered (huge planar sectors)
but we can ignore them for now.

> Now, the scope *focus* follows the player around in the same way that
> the glow from a lamp follows a lamp, but it doesn't do so smoothly. At

It does so as smoothly as the implemented detail of the world will allow.
If I decide not to implement distances, large rooms would probably be a set of
'navigationally equivalent' points (from which scope extends to most or all of
the rest of the points) and scoping for exits and what lies beyond them is
done by some measure of distance - IE even if distances aren't implemented,
being in the point with the exit in it would yield the most information, the
rest would give less info. - and possibly by player orientation. (Even if
player orientation isn't manipulated directly, I think it's good to include
it.. but not essential.)

> some point, there's a jump where focus suddenly extends all the way
> across an adjoining sector instead of only halfway into it (or

Plans which include distances/positions as part of the implementation try
to make this gradual. But for point sectors you're correct.

> whatever). At least, I presume it's this way since you say you're not
> interested in a real-world model, which would require a continuous
> transition.
>

I'm not interested in an excessive amount of detail. I'm not terribly
interested, for the moment, in making large numbers of rooms which implement
two-dimensional floors. Since the player will only move in discrete intervals
-anyway- (it's not to be expected that a player would get much use out of
right/left/forward/back relative movements for real navigation) the transition
-can't- be fully continuous. My goal is a fairly good approximation.

> Nevertheless, the player can move around more or less continuously if
> he chooses; he doesn't have to move in synch with the focus jumps.
> Hence, the range of his vision will be the same, let's say, whether
> he's two inches into a sector or two inches short of halfway. It's
> only when he passes over the halfway mark (or whatever boundary you
> set) that the scope changes.
>

Well, more or less. Some of the precise details about focusing, like
everything else, aren't completely worked out. My goal is, supposing the
player moved one small distance each turn, that the result would be a more or
less natural progression, with nothing falling immediately completely in or
out of view.

> Am I close so far?
>

Your basic idea about the system seems right.. specifics don't match with
my ideas but given how much they're subject to change...

Cardinal Teulbachs

unread,
Nov 24, 1996, 3:00:00 AM11/24/96
to

go...@cs.buffalo.edu (Phil Goetz) wrote:

>I want to develop my IF system to sit on top a graphics engine,
>possibly RenderMan or Quake. I'm worried about this issue -- can IF
>as we know it survive the marriage?

Sure. It'll just be a different kind of IF. There are already 3d games
that have a plot, with distinctive characters that interact with you
(in a limited way) and so on. The only problem with them is that the
range of action is very limited due to the interface. There's no
command line and parser; just a few joystick buttons and hot keys.
I've always thought it would be cool (until voice command is
perfected, at least) to make a 3d game that uses both input
devices--the joystick for moving and, if called for, firing, and the
keyboard for typing in more complicated or specific commands:

- >general rama, what's your sign?

[no response--he didn't understand you]

- >general rama, go east

[no response--he's ignoring you]

- >general rama, put the lime in the coconut
(from your speakers): "Excellent idea. I'll do that." (and you
watch as he puts the lime in the coconut)

The only real difference between this kind of game and the text
variety is the text. In graphical games the emphasis is on direct
sensory experience--the implication is that this stuff is really
happening to you in a direct and immediate way because you're seeing
it with your own eyes. In text games, the mode is rather that of a
narrator telling you what something is like. Thus, if you think that
narration--the absence of direct sensory experience--is something
essential to IF, your graphical system won't be doing IF, but if you
think the opposite then it will.

Personally, I take the view that what we call IF spans a spectrum
between pure storytelling and pure "experience". On the storytelling
end is something entirely linear, with no interactive element. Every
event is completely determined because it's being presented as
history. Contrariwise, on the "experience", or "gaming", end is
complete freedom of action with nothing determined (this complete
freedom of action is only hypothetical, of course, since it can't be
achieved in practice, but that's what the attempt is being made to
simulate). IOW, on the one end we have a book that simply tells us
what happened, and on the other end we have a walk in the park in
which we see it for ourselves as it's happening.

I think that text adventures under current systems fall somewhere near
the middle of this spectrum. They're an uneasy blend of linear,
determinate storytelling and non-linear, immediate experience. But
what makes them text adventures is the text and narration, so that
they finally come down somewhere farther along the line toward the
"book" end. Something like George Caswell's system, on the other hand,
I see as coming down an equal distance from the middle, but in the
opposite direction. It's true that his system sticks with the text
interface and 3rd party narration, but the emphasis on freedom of
action and a more direct "experience" of the game environment seem to
me to drag it off in that other direction. Finally, your system I see
as falling considerably farther down the line toward "pure experience"
than George's, for obvious reasons.

Does this mean either your system or George's won't produce IF? No,
but it does mean they won't produce what we've historically thought of
as text adventures. Yours absolutely won't produce them, since there's
no text, and George's just won't produce them in the same way, with
the same character. It's all Interactive Fiction, though, in some
sense, since it all involves interaction by the player/reader and it
all concerns stuff that didn't ever happen (or isn't really
happening).

{The question in your subject line is an entirely different question
than the one you actually asked, btw) :)

--Cardinal T

I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan

Are there any text games prominently featuring dinosaurs?
If not, does anyone besides me think it would be cool?
--Matthew Amster-Burton

"Cyber-Babushka"
--Bonni Mierzejewska

Phil Goetz

unread,
Nov 24, 1996, 3:00:00 AM11/24/96
to

In article <577a2o$k...@news.dx.net>,

Greg Falcon <professo...@pnx.com> wrote:
>
>May I make one suggestion? Never remove the command line. Sierra
>games were so much better when you TYPED what you want to do.
>
> My $0.02
> Greg

I want to keep the command line. But when you have a command line
mixed with graphics, there is necessarily a level of planning
between what you type and what happens (unless you control the
actual finger/hand/leg manipulations). This is a problem.
It's nice to type

get the egg

and have the program walk back to your office, get the key off the wall,
unlock the trophy case, and take the egg. It's disturbing to type

stop the sheriff

and have your character whip out a gun and shoot him down. This is
the sort of thing that can happen with my current text system,
because when you issue a command, the character forms a plan to
execute it. I think this is the best way to deal with graphical worlds,
because you don't want to specify exactly how to accomplish things
in terms of X-Y coordinates and differential equations.
But I don't know how to draw the line that says "You can do these things
on your own initiative, but not these."

Phil Goetz

Bruce Stephens

unread,
Nov 25, 1996, 3:00:00 AM11/25/96
to

>>>>> "Greg" == Greg Falcon <professo...@pnx.com> writes:

> Look at Resident Evil for the playstation. It was mostly a huge
> slaughterfest, but there were a few IF style puzzles in it.
> (Dumping the chemical in the sprinkler system, or placing gems, or
> playing the piano, or the emblem swapping, or...)

Without wishing to turn this into a Playstation newsgroup, I think
Tomb Raider works nicely. It's not interactive fiction, I think,
because so far it seems very much find-the-objects, and all the
puzzles (apart from the jumping and things) are find the key, or find
the object and put it in the appropriate place, or push the block.
Hardly subtle literary stuff. On the other hand, the implementation
is beautiful, and the puzzles don't seem particularly out of place, so
the game is kept nicely interesting. And much of it is wonderfully
atmospheric and spectacular: jumping across the gap in a suspended
bridge across the Lost Valley; diving from a cliff into the pool at
the bottom of a waterfall.
--
Bruce Stephens | email: B.Ste...@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht, The Netherlands

Adam J. Thornton

unread,
Nov 25, 1996, 3:00:00 AM11/25/96
to

In article <wwahgme...@bommel.math.ruu.nl>,

Bruce Stephens <step...@math.ruu.nl> wrote:
>>>>>> "Greg" == Greg Falcon <professo...@pnx.com> writes:
>> Look at Resident Evil for the playstation. It was mostly a huge
>> slaughterfest, but there were a few IF style puzzles in it.
>Without wishing to turn this into a Playstation newsgroup, I think
>Tomb Raider works nicely. It's not interactive fiction, I think,

As long as we're on the Playstation theme:

Has anyone else noticed that Crash Bandicoot is largely written by our very
own Dave Baggett? And that for a game that's basically _Pitfall_ it really
kicks serious ass?

Adam
--
"I'd buy me a used car lot, and | ad...@princeton.edu | As B/4 | Save the choad!
I'd never sell any of 'em, just | "Skippy, you little fool, you are off on an-
drive me a different car every day | other of your senseless and retrograde
depending on how I feel.":Tom Waits| little journeys.": Thomas Pynchon | 64,928

Greg Falcon

unread,
Nov 25, 1996, 3:00:00 AM11/25/96
to

ad...@yuma.Princeton.EDU (Adam J. Thornton) wrote:

>As long as we're on the Playstation theme:

>Has anyone else noticed that Crash Bandicoot is largely written by our very
>own Dave Baggett? And that for a game that's basically _Pitfall_ it really
>kicks serious ass?

You're not trying to start up that "Killer Instinct 2 is basically
Space Invaders" thread again, are you?

Concerned,
Greg

Marnix Klooster

unread,
Nov 25, 1996, 3:00:00 AM11/25/96
to

go...@cs.buffalo.edu (Phil Goetz) wrote:

> I want to keep the command line. But when you have a command line
> mixed with graphics, there is necessarily a level of planning
> between what you type and what happens (unless you control the
> actual finger/hand/leg manipulations). This is a problem.
> It's nice to type
>
> get the egg
>
> and have the program walk back to your office, get the key off the wall,
> unlock the trophy case, and take the egg. It's disturbing to type
>
> stop the sheriff
>
> and have your character whip out a gun and shoot him down. This is
> the sort of thing that can happen with my current text system,
> because when you issue a command, the character forms a plan to
> execute it.

Previously, I only thought about planning as a way to get more
'intelligent' NPCs. But I agree that it can be very useful for
the user-controlled character commands to be treated similarly.
In a sense, this makes planning a generalization of parsing.

> I think this is the best way to deal with graphical worlds,
> because you don't want to specify exactly how to accomplish things
> in terms of X-Y coordinates and differential equations.
> But I don't know how to draw the line that says "You can do these things
> on your own initiative, but not these."

Don't you know *how* to draw the line, or *where* to draw it? I
haven't thought about the latter question, but the former doesn't
seem too difficult to me. It is a matter of how 'intelligent'
the planner algorithm is that the particular character uses.
Simply make the planner for user command less 'intelligent' than
an NPC's planner. Thus, typing "stop the sheriff" would simply
cause the planner to fail with "I can't make a plan for that."
(An NPCs planner might be made 'intelligent' enough to create a
plan in such a case.)

Note that this implies that there are three different kinds of
responses to user-typed commands:
- "I don't understand." Parser failure, e.g. "mjamble
somethingorother"
- "I don't know how to do that." Planner failure, e.g. "stop the
sheriff"
- "That's impossible." In-game failure, e.g. "get floor"

> Phil Goetz

Groetjes,

<><

Marnix
--
Marnix Klooster
mar...@worldonline.nl

Trevor Barrie

unread,
Nov 26, 1996, 3:00:00 AM11/26/96
to

ad...@yuma.Princeton.EDU (Adam J. Thornton) wrote:

>As long as we're on the Playstation theme:
>
>Has anyone else noticed that Crash Bandicoot is largely written by our very
>own Dave Baggett?

Are you serious? Why on Earth didn't they mention that in their ads?:) That
might actually pique some interest, unlike the crap they're showing. (Ooh,
it's better than Mario... big whoop, so is Pong.)


Fred the Wonder Worm

unread,
Nov 26, 1996, 3:00:00 AM11/26/96
to

In article <wwahgme...@bommel.math.ruu.nl>,
Bruce Stephens <step...@math.ruu.nl> wrote:
>>>>>> "Greg" == Greg Falcon <professo...@pnx.com> writes:
>
>> Look at Resident Evil for the playstation. It was mostly a huge
>> slaughterfest, but there were a few IF style puzzles in it.

>> (Dumping the chemical in the sprinkler system, or placing gems, or
>> playing the piano, or the emblem swapping, or...)
>

>Without wishing to turn this into a Playstation newsgroup, I think
>Tomb Raider works nicely. It's not interactive fiction, I think,

>because so far it seems very much find-the-objects, and all the
>puzzles (apart from the jumping and things) are find the key, or find
>the object and put it in the appropriate place, or push the block.
>Hardly subtle literary stuff. On the other hand, the implementation
>is beautiful, and the puzzles don't seem particularly out of place, so
>the game is kept nicely interesting. And much of it is wonderfully
>atmospheric and spectacular: jumping across the gap in a suspended
>bridge across the Lost Valley; diving from a cliff into the pool at
>the bottom of a waterfall.

To get away from the Playstations :), also check out Relentless (aka
Little Big Adventure). (Available for PCs from Electronic Arts.) I
don't want to attempt to describe it - there is a review
<A HREF=http://www.gamezilla.com/thrills/relentls.htm>here</A>. He
dwells a bit much on the graphics, but what makes the game for me is
the interactions with the characters. It takes a nice (IMHO) approach
to talking to people without requiring input from the user; the main
character (Twinsen) has a current interest which he asks people about.
Also for some characters he has a particular question because of previous
events.

Extremely minor spoilers ahead.

For example, at the start he walks up to people and says
'Uhh..how's it going?', and they may respond with useful information or
have nothing helpful to say. Later his wife (girlfriend? It's not clear)
is arrested and taken away. He then tells people 'I am looking for a
young girl. She is being escorted by two groboclones.' And some of them
may know something about that.

When he first meets Julia, she suggest that he talks to Beatrice. When
he then meets Beatrice, after his usual conversational gambit he says
'Julia talked a lot about you', and conversation ensues.

Basically, it's a great game - go play it. Then tell me whether or not
you think it is interactive fiction.

Cheers,
Geoff.

-------------------------------------------------------------------------------
Geoff Bailey (Fred the Wonder Worm) | Programmer by trade --
ft...@cs.su.oz.au | Gameplayer by vocation.
-------------------------------------------------------------------------------


Den of Iniquity

unread,
Nov 26, 1996, 3:00:00 AM11/26/96
to

On Sun, 24 Nov 1996, Cardinal Teulbachs wrote:

> - >general rama, put the lime in the coconut
> (from your speakers): "Excellent idea. I'll do that." (and you
> watch as he puts the lime in the coconut)

General Rama might be in for a nasty case of flipper-ache...


George Caswell

unread,
Nov 26, 1996, 3:00:00 AM11/26/96
to

Idano.. I kinda like the idea of someone going to NoA's gates with a
bullhorn and yelling 'Heeeey, plumberboy, moustache man...' until security
throws em out...

...In any case, as long as it's better than Sega's BUG (that whopping piece
of crap...)


________________________________________________
______________ _/> ____ | George Caswell, WPI CS 1999. Member L+L and |
<___ _________// _/<_ / | SOMA. Sometimes artist, writer, builder. Admin |
// <> ___ < > / _/ | of ADAMANT, a Linux box for the creative and |
// /> / / _/ / / <____ | productive members of the computer world. For |
// </ <<</ < _/ <______/ |_more info see http://www.wpi.edu/~timbuktu.____|

</ </ ---Contributing to chaos with off-topic posts!
YES!


-

unread,
Nov 27, 1996, 3:00:00 AM11/27/96
to

System Shock is a 3D Doom style game, with an actual plot, though the
plot _is_ developed using text (Diaries and messages you pick up on the
way)

Nicholas Daley
<mailto:dal...@ihug.co.nz>

John Hartnup

unread,
Nov 28, 1996, 3:00:00 AM11/28/96
to

Trevor Barrie (tba...@cycor.ca) wrote:
: ad...@yuma.Princeton.EDU (Adam J. Thornton) wrote:

: >As long as we're on the Playstation theme:
: >
: >Has anyone else noticed that Crash Bandicoot is largely written by our very
: >own Dave Baggett?

: Are you serious? Why on Earth didn't they mention that in their ads?:) That
: might actually pique some interest, unlike the crap they're showing. (Ooh,
: it's better than Mario... big whoop, so is Pong.)

Where do I find the credits? I want PROOF!

John
--
-----------------------------------------------------------
John Hartnup | You can drink your weak lemon drink
sl...@ladle.demon.co.uk| now, or you can save it 'til later.
-----------------------------------------------------------


Greg Ewing

unread,
Nov 29, 1996, 3:00:00 AM11/29/96
to

Phil Goetz wrote:
>
> But I don't know how to draw the line that says "You can do these things
> on your own initiative, but not these."

A good start would be to classify certain actions as "drastic"
(e.g. shooting people, breaking things) and not formulate any
automatic plan for the PC which includes a drastic action.

Greg

David Baggett

unread,
Dec 1, 1996, 3:00:00 AM12/1/96
to

In article <57cdgm$s...@cnn.Princeton.EDU>,

Adam J. Thornton <ad...@yuma.Princeton.EDU> wrote:

>Has anyone else noticed that Crash Bandicoot is largely written by our very
>own Dave Baggett?

Well that's a bit of an exaggeration, but it's true that I wrote lots of
code for it. Actually, there were two of us who wrote code for the
duration of the project, and a third who came in half way through. There
were 10 of us on the team, with lots of help from outside sources for
music, character design, etc.

>And that for a game that's basically _Pitfall_ it really kicks serious
>ass?

Aside from the compliment (thanks), you raise an interesting point here.
We've asked ourselves this question: is Pitfall the first game in this
genre? We couldn't come up with any predecessors... Donkey Kong, Pac-Land
and Lode Runner are other early games that trace their lineage back to
Pitfall.

As for 3D literature, I would advise any would-be author stick to plain
text unless he's got a staff of two dozen maniacally dedicated and creative
collaborators... It's a lot more work than it looks, just like movies.

One of the best things about fiction (IF included) is that a single person
can complete a full-sized work in a reasonable amount of time. That's just
not true of graphical adventures and movies any more. (I think one of the
Implementors commented on this as well, in a transcript I read several
years ago.)

Dave Baggett
__
d...@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)

Kenneth Fair

unread,
Dec 2, 1996, 3:00:00 AM12/2/96
to

In article <57r1kq$j...@life.ai.mit.edu>, d...@ai.mit.edu wrote:


>Aside from the compliment (thanks), you raise an interesting point here.
>We've asked ourselves this question: is Pitfall the first game in this
>genre? We couldn't come up with any predecessors... Donkey Kong, Pac-Land
>and Lode Runner are other early games that trace their lineage back to
>Pitfall.

[plumbing the pathways of those early 2600 memories...]

As far as I can remember, Pitfall is the prototype, although you might
be able to make an argument that Frogger is of the same genre.

--
KEN FAIR - U. Chicago Law | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?
Better not take a dog on the Space Shuttle, because if he sticks his
head out when you're coming home his face might burn up.

Phil Goetz

unread,
Dec 2, 1996, 3:00:00 AM12/2/96
to

In article <57r1kq$j...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:

>As for 3D literature, I would advise any would-be author stick to plain
>text unless he's got a staff of two dozen maniacally dedicated and creative
>collaborators... It's a lot more work than it looks, just like movies.

I think it could be made easier, if animation were more automatic, and
if one had a good library of rooms and objects to start with.
If I put effort into developing an authoring system,
I want it to have optional 3D graphics capability.

>We've asked ourselves this question: is Pitfall the first game in this
>genre? We couldn't come up with any predecessors... Donkey Kong, Pac-Land
>and Lode Runner are other early games that trace their lineage back to
>Pitfall.

Lode Runner is a direct descendant of Apple Panic, a Broderbund game from
about 1980.
I don't know when Pitfall was. 1981? I don't see how it's at all like Lode
Runner, either. There was an early Apple ][ platform game called Aztec,
from Datamost, by the guy who wrote Swashbuckler, which seemed more like
Pitfall. I can't remember when it came out, though. Probably later.
And I could say it descended from Castle Wolfenstein (1979)
as much as from Pitfall.

Phil

Matt Ackeret

unread,
Dec 2, 1996, 3:00:00 AM12/2/96
to

In article <57v1th$f...@prometheus.acsu.buffalo.edu>,

Phil Goetz <go...@cs.buffalo.edu> wrote:
>Lode Runner is a direct descendant of Apple Panic, a Broderbund game from
>about 1980.

And Apple Panic is a ripoff of Space Panic, an arcade game from around the
same time.
--
mat...@apple.com

Trevor Barrie

unread,
Dec 8, 1996, 3:00:00 AM12/8/96
to

d...@rice-chex.ai.mit.edu (David Baggett) wrote:

>>Has anyone else noticed that Crash Bandicoot is largely written by our very
>>own Dave Baggett?
>
>Well that's a bit of an exaggeration, but it's true that I wrote lots of
>code for it.

Oh - for some reason, when I read that I somehow got the impression that you
had written the _plot_ for it, which rather surprised me. Was my original
assumption that it doesn't have one in fact correct?


David Baggett

unread,
Dec 8, 1996, 3:00:00 AM12/8/96
to

In article <32a97f8c...@news.peinet.pe.ca>,
Trevor Barrie <tba...@cycor.ca> wrote:

>Oh - for some reason, when I read that I somehow got the impression that

>you had written the _plot_ for [Crash Bandicoot], which rather surprised


>me. Was my original assumption that it doesn't have one in fact correct?

Plot: save your girlfriend and defeat the evil supergenius Dr. Neo Cortex.

There are two principal tasks in video game creation: code and art.
They're about equally difficult, in my experience. Unless you're doing a
game like Full Throttle, you're not going to be doing much writing or
plotting, proportionally speaking.

Writing text-based interactive ficiton is a bit different, because the
programming part is so easy compared to the art (English) part. I imagine
most experienced programmers could write IF code in TADS, Inform, Alan,
etc. faster than maximum typing speed given full concentration. But I
doubt any skilled fiction authors would have any easier a time writing the
text for an IF game than for a novel.

Coding an IF development system from scratch for a game would even things
out, of course. Good thing we don't have too...

Reply all
Reply to author
Forward
0 new messages