Why the problem with N/S/E/W?
Jason B Dyer
Look, North/South/etc. are just conventions. When I'm going through
a piece of IF I certainly don't consider them literal directions,
merely ways to show how the rooms are connected.
Typing "Go to ___. Forward. Forward." instead of "E. E. E." seems more
like driving a car or programming Logo rather than walking around.
Also, I can't think of a single example where an IF world based
on a real world model would be easier to program than the standard
way. We've got the ceiling fan -- so easy it's a beginner's exercise.
What else?
On the other hand, how do you do real world models for: pendulums,
flying dragons, dust storms, vehicles, explosions, intangible
forms, forest fires, and iguanas that incessantly follow you around?
These could be termed "exceptions" and require special programming,
but from what I'm seeing the special programming would be much
harder with a real world model.
I'm not saying this track of thought is totally useless, but
at the moment the practical value eludes me.
Jason Dyer
jd...@u.arizona.edu
George Caswell
On 21 Nov 1996, Jason B Dyer wrote:
> Look, North/South/etc. are just conventions. When I'm going through
> a piece of IF I certainly don't consider them literal directions,
> merely ways to show how the rooms are connected.
>
Yes, well, I guess I regard it a lot like I regard the British system of
weights and measures, Microsoft OSes, and the like-- not the best systems out
there, but unfortunately (in my experience) the standard. It's a system which
often does not make sense or apply to the world being implemented.
> Typing "Go to ___. Forward. Forward." instead of "E. E. E." seems more
> like driving a car or programming Logo rather than walking around.
>
First, you should note this is -my- idea- It might have been more
appropriate to post this response under the thread I started than to post it
generally, especially since you'll probably find only agreement, apart from
me. Arguing the points you argued here to a general r.a.i-f audience is like
shooting fish in a barrel. And if you'd paid any attention, you'd understand
the system I'm working out is still in early planning. This is one detail
I've recognized, but not found a proper solution to.. yet. The -reason- I'm
looking for a way around absolute directions is because it's completely
inappropriate to my game. Absolute directions, as someone pointed out, could
still work in the movement system I'm planning out-- but if I find a better
way to move about I intend never to use them again.
So why implement the sector system if I fall back and use absolute
directions? The system in planning is the result of many various improvements
I want to see in I-F. One of the most important is the new focus treatment-
allowing users to see locations near their own and hopefully making the map
more continuous.
So why consider move-by-name or relative directions in the first place, if
they'll be less familiar, take longer to type, and relative directions, the
only part possibly capable of being abbreviated, would be prohibitively
difficult (IMHO) to use to follow a path on even a mapped environment? (Maybe
not prohibitively difficult, but probably not fun!) Well, it was my first
idea. I'm not completely ready to give up on it, but I can see it's time to
think of something better.
> Also, I can't think of a single example where an IF world based
> on a real world model would be easier to program than the standard
> way. We've got the ceiling fan -- so easy it's a beginner's exercise.
> What else?
>
A ceiling fan is simple. What if you want to make the player capable of
standing on top of a ladder to reach it for some reason? Fine, code a ladder,
and special case it to allow the player to reach things that are on the
ceiling. What if you decided there were other ceiling-based objects a player
-couldn't- reach, even if on the ladder? Fine, special case those, too. What
if other objects turn up in the course of game development which, sensibly,
could be used as something to stand on to reach the fan, but for whom this
isn't their primary use? Fine, a bit of playtesting to identify these, and
special case those, too. What about special casing all those new objects for
the items that may have been 'too high' to reach from the ladder?
Perhaps not the best example, but the idea is this- generating some form
of simple, consistent rule is one approach to avoiding large numbers of
unforseeable special cases. AND THIS IS FEATURE IS --NOT-- A PRIMARY DESIGN
GOAL OF MY MOVEMENT SYSTEM!
> On the other hand, how do you do real world models for: pendulums,
> flying dragons, dust storms, vehicles, explosions, intangible
> forms, forest fires, and iguanas that incessantly follow you around?
>
> These could be termed "exceptions" and require special programming,
> but from what I'm seeing the special programming would be much
> harder with a real world model.
>
How so? From where I stand it seems that they could be programmed almost
identically to the way they would with default libraries.
> I'm not saying this track of thought is totally useless, but
> at the moment the practical value eludes me.
>
There is no practical value to I-F. It's a game.
________________________________________________
______________ _/> ____ | 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.____|
</ </
Cardinal Teulbachs
jd...@kitts.u.arizona.edu (Jason B Dyer) wrote:
>Look, North/South/etc. are just conventions. When I'm going through
>a piece of IF I certainly don't consider them literal directions,
>merely ways to show how the rooms are connected.
I consider them a little more than that, but little more than that, if
you know what I mean.
No? Ok, I mean that I generally suppose the author intended them to
have some real relation to the game world, but that that directional
relationship is mostly unimportant. So, like you, I don't treat it as
if it were important in itself.
>Also, I can't think of a single example where an IF world based
>on a real world model would be easier to program than the standard
>way. We've got the ceiling fan -- so easy it's a beginner's exercise.
>What else?
I think the point is not so much whether one can easily code a ceiling
fan (with its implications for reach scope), but rather whether one
can easily code a ceiling fan in every room, with many potential
stepstools, etc. IOW, if you're going to lay out a physical
environment in minute detail, then it would be far preferable to use a
system that does such decision-making for you as a matter of policy.
But just saying this doesn't answer the more fundamental question: why
would someone want to have such an environment in the first place?
It seems to me that the real-space kind of environment is aimed at a
more direct sensory experience than is had in fiction. If you want a
real-space environment, it's because you want to be able to walk three
paces east of the idol and view it directly from there; then walk six
paces south-southwest and view it from that perspective as well--much
as in the game Doom. But literature isn't about that. It appeals to
the mind and the imagination rather than directly to the senses.
Moreover, it tells a story and so is by its nature linear. Thus, the
closer you get to real-space and complete freedom of action, the
further you get from storytelling and vice versa.
This is why I think the real-space idea is good for something, but not
i-f--except in the loosest possible sense.
>On the other hand, how do you do real world models for: pendulums,
>flying dragons, dust storms, vehicles, explosions, intangible
>forms, forest fires, and iguanas that incessantly follow you around?
>These could be termed "exceptions" and require special programming,
>but from what I'm seeing the special programming would be much
>harder with a real world model.
I don't see any inherent reason why these would be either easier or
harder in a real-space system than in current ones. It's not the
nature of the game objects that forms the crux of the issue; it's
whether the game objects are to be experienced directly by the player
or through the narration of a storyteller.
>I'm not saying this track of thought is totally useless, but
>at the moment the practical value eludes me.
If you mean in terms of i-f, then I pretty well agree with 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
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
Jason B Dyer
George Caswell (timb...@adamant.res.wpi.edu) wrote:
: shooting fish in a barrel. And if you'd paid any attention, you'd understand
: the system I'm working out is still in early planning. This is one detail
: I've recognized, but not found a proper solution to.. yet. The -reason- I'm
: looking for a way around absolute directions is because it's completely
: inappropriate to my game. Absolute directions, as someone pointed out, could
: still work in the movement system I'm planning out-- but if I find a better
: way to move about I intend never to use them again.
I understand this is all in planning stages, I was just pointing out that
we still need something better if we want to avoid absolute movement.
: Perhaps not the best example, but the idea is this- generating some form
: of simple, consistent rule is one approach to avoiding large numbers of
: unforseeable special cases. AND THIS IS FEATURE IS --NOT-- A PRIMARY DESIGN
: GOAL OF MY MOVEMENT SYSTEM!
Hmmm...I think a sample transcript might be good here.
: > On the other hand, how do you do real world models for: pendulums,
: > flying dragons, dust storms, vehicles, explosions, intangible
: > forms, forest fires, and iguanas that incessantly follow you around?
: > These could be termed "exceptions" and require special programming,
: > but from what I'm seeing the special programming would be much
: > harder with a real world model.
: How so? From where I stand it seems that they could be programmed almost
: identically to the way they would with default libraries.
In other words, these would be handled in the traditional way? Is this what
you mean? I was thinking above of the problems within defining dust storms
and such in terms of physical laws. Say, for example, someone is standing
on a swaying platform with an apple hanging above. At times the player
can reach it; other times he or she can't.
: > I'm not saying this track of thought is totally useless, but
: > at the moment the practical value eludes me.
: There is no practical value to I-F. It's a game.
I mean "it isn't quite usable yet to program with."
Oh, and people do make money with games. Selling interactive fiction may be
a bit tricky these days, but with some graphics to make the visual people
happy and a good dose of marketing it might be possible.
Jason Dyer
jd...@u.arizona.edu
George Caswell
On 22 Nov 1996, Jason B Dyer wrote:
> George Caswell (timb...@adamant.res.wpi.edu) wrote:
> : shooting fish in a barrel. And if you'd paid any attention, you'd understand
> : the system I'm working out is still in early planning. This is one detail
> : I've recognized, but not found a proper solution to.. yet. The -reason- I'm
> : looking for a way around absolute directions is because it's completely
> : inappropriate to my game. Absolute directions, as someone pointed out, could
> : still work in the movement system I'm planning out-- but if I find a better
> : way to move about I intend never to use them again.
>
> I understand this is all in planning stages, I was just pointing out that
> we still need something better if we want to avoid absolute movement.
>
That is agreed. The reason your post was a bit unwelcome the way you wrote
it was it seemed (to me) more criticism that constructive.
> : Perhaps not the best example, but the idea is this- generating some form
> : of simple, consistent rule is one approach to avoiding large numbers of
> : unforseeable special cases. AND THIS IS FEATURE IS --NOT-- A PRIMARY DESIGN
> : GOAL OF MY MOVEMENT SYSTEM!
>
> Hmmm...I think a sample transcript might be good here.
>
Transcript of what? The movement system without use of dimension?
> : > On the other hand, how do you do real world models for: pendulums,
> : > flying dragons, dust storms, vehicles, explosions, intangible
> : > forms, forest fires, and iguanas that incessantly follow you around?
> : > These could be termed "exceptions" and require special programming,
> : > but from what I'm seeing the special programming would be much
> : > harder with a real world model.
> : How so? From where I stand it seems that they could be programmed almost
> : identically to the way they would with default libraries.
>
> In other words, these would be handled in the traditional way? Is this what
> you mean? I was thinking above of the problems within defining dust storms
> and such in terms of physical laws. Say, for example, someone is standing
> on a swaying platform with an apple hanging above. At times the player
> can reach it; other times he or she can't.
>
Erm... well, if I wanted to write it as an 'actual movement' situation,
the swaying platform and apple would have actual positions relative to each
other, and the position of the platform would change frequently.. Pretty much
the same thing you'd do in default libraries for the problem, just there you'd
only write extra descriptions and prevent the user from reaching things at
parts of the swing. A swaying platform may not be something that would work
very well in I-F though.
> : > I'm not saying this track of thought is totally useless, but
> : > at the moment the practical value eludes me.
> : There is no practical value to I-F. It's a game.
>
> I mean "it isn't quite usable yet to program with."
>
Of course not... it (the sector system) is not done yet.
Phil Goetz
In the type of program I'm working on, N/S/E/W isn't an issue.
Once the player has found, say, the warehouse, then wherever he is
in a game, if he types "go warehouse", his character forms a plan
to move to the warehouse (even if this involves buying a ticket,
boarding trains, etc.) and goes to the warehouse.
Phil
George Caswell
Interesting. Were you the one who posted earlier about navigating the
locations tree between two rooms? I assume that buying tickets (and having
money to buy tickets) etc. wouldn't be major issues in your game... (A lot of
traditional I-F puzzles require the player to be in total control of each
individual movement-- the bridge that collapses if he crosses it too many
times, the riverbank that falls into the river if he stays too long, the money
of which there's only enough to buy two tickets, etc...)
How does your planned basic-nav system work? Is it also move-by-name, or
does it use the cardinal points? And does your auto-nav just flag visited
locations, then find an arbitrary path based on where the player wants to go?
I was thinking of a similar auto-nav system for my sector system-- But I
was thinking of making it either use a routing system (Some way that the
correct exit to reach one point from another would be dynamically
pre-calculated and recorded in a routing table of some sort-- probably not
too great for memory or computational constraints, but would be very
effective, especially if NPCs want to go somewhere specific, as mine will) or
a system that broke up groups of sectors into 'equivalence' groups, from which
any one place is directly accessible from any other place (for example, if
you'd broken into a warehouse, you could get to any other point in the
warehouse directly, without having to do any real auto-nav) or a combination
of the two... (routing between groups, equivalence within groups...)
Your system sounds interesting- I wish you luck with it and look forward
to hearing more.
George Caswell
On Mon, 25 Nov 1996, Greg Ewing wrote:
> Mr. Caswell,
>
> Let me see if I understand your proposal correctly.
'proposal' may be inaccurate. I propose nothing. This is a system I've
been toying with implementing, and wanted to get a better idea of the serious
problems I might face.
> The main difference between your "point" sectors
> (which have no internal coordinate space) and traditional
'point' sectors may have -minimal- internal space- player always being in
the center, and objects being in other directions from the player (most often
exits only.) But for the most part, yes.
> rooms is that, traditionally, scope is limited to a single room
> unless special provision is made, whereas in your system
> scope would routinely extend into some number of adjacent
> sectors.
>
...Usually all adjacent sectors to some point, even if just to the point of
seeing adjacent location names.
> It seems to me that, for this to be an improvement over
> the traditional structure from the programmer's point of
> view, calculation of how far the scope extends needs to
> be largely automatic, based on some kind of declarative
> information supplied by the programmer.
>
...Hence, one argument for including distance data.
> What sort of criteria do you have in mind for deciding
> on the scope, and what sort of information would the
> programmer need to supply so that the system could
> apply these criteria?
>
The general thought I'd had was direction the player faces (changable by
relative direction or by 'facing' an object or [something in?] another
sector...), distance, and possibly other factors- as default.
> To put it another way, what properties would sectors
> and objects have for the purpose of scope determination,
> and how would the system use these properties to
> determine scope?
>
> I think perhaps we need a concrete example or two of
> how your system would work in practice before we can
> make much more progress in this discussion.
>
I'm not sure of all these things myself. Perhaps the 'concrete examples'
can come after the system's written. As I said, however, my general line of
thought was that it would go something like this.
First- Except in special circumstances, directions within the player's
180-odd degree of vision would have the 'primary' focus, listed first and
given the most favor in focus decisions. further to the sides and back would
be listed later and in less detail.
Second- Distances, if implemented, would change how a room is listed
(according to routines in the room object itself)
Third- Any 'exceptions', mostly routines that are part of the room or
events which affect the room (One line of thought I'd been working on was
implementing sound propagating through halls- that, if implemented, would be
an example of an event that would affect the adjacent room-- more
specifically, affect you, but from that direction...)
Greg Ewing
Mr. Caswell,
Let me see if I understand your proposal correctly.
The main difference between your "point" sectors
(which have no internal coordinate space) and traditional
rooms is that, traditionally, scope is limited to a single room
unless special provision is made, whereas in your system
scope would routinely extend into some number of adjacent
sectors.
It seems to me that, for this to be an improvement over
the traditional structure from the programmer's point of
view, calculation of how far the scope extends needs to
be largely automatic, based on some kind of declarative
information supplied by the programmer.
What sort of criteria do you have in mind for deciding
on the scope, and what sort of information would the
programmer need to supply so that the system could
apply these criteria?
To put it another way, what properties would sectors
and objects have for the purpose of scope determination,
and how would the system use these properties to
determine scope?
I think perhaps we need a concrete example or two of
how your system would work in practice before we can
make much more progress in this discussion.
Greg
Trevor Barrie
jd...@kitts.u.arizona.edu (Jason B Dyer) wrote:
>Look, North/South/etc. are just conventions. When I'm going through
>a piece of IF I certainly don't consider them literal directions,
>merely ways to show how the rooms are connected.
>
>Typing "Go to ___. Forward. Forward." instead of "E. E. E." seems more
>like driving a car or programming Logo rather than walking around.
That objection seems to be even more true of "E. E. E", as far as I can
tell.
Gareth Rees
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
> The main difference between your "point" sectors (which have no
> internal coordinate space) and traditional rooms is that,
> traditionally, scope is limited to a single room unless special
> provision is made, whereas in your system scope would routinely extend
> into some number of adjacent sectors.
It ought to be possible to do this in Inform. One would supply each
room with a list of nearby rooms into which scope would be extended.
All rooms would belong to a class which would append the necessary "To
the north, you can see ..." information to the room description, and
which would do the appropriate scope extension. In GamePreRoutine one
would do something like this:
[ GamePreRoutine dir;
if (inp1 ~= 0 && noun notin Compass &&
~~IndirectlyContains(location,noun)) {
print "(Approaching ", (the) noun, " first.)^";
! find out which direction `noun' is in; set `dir' accordingly
<Go dir>;
if (IndirectlyContains(location,noun)) rfalse;
}
];
Obviously much more sophistication is needed: you have to consider
`second', and what to do if `noun' and `second' are in different rooms,
and perhaps some verbs don't actually cause this kind of motion, and
some objects might be in scope but not in the current location for other
reasons than scope extension (like the Compass directions), and you
might want to modify the output from the <Go> action, etc, etc. But I
believe that a fairly robust solution could be arrived at with some
work.
--
Gareth Rees
Greg Falcon
George Caswell <timb...@adamant.res.wpi.edu> wrote:
> First- Except in special circumstances, directions within the player's
>180-odd degree of vision would have the 'primary' focus, listed first and
>given the most favor in focus decisions. further to the sides and back would
>be listed later and in less detail.
First of all, let me say that I have been following the threads about
your system, and I think it has real promise.
Just curious about the scoping rules.
Let me go in and out of example script... I'll prefix my example with
#'s.
# You are in a dull white room, here for the purpose of example. The
# only thing worth noticing is a huge double door.
#
# >open door
#
# Opened.
Okay, say this door leads into a big hallway. Will opening the door
automatically tell the player what he sees behind the door? I think
this would be a nice effect. In traditional IF, you never see what's
behind a door until you go in it. This is not realistic, and is
obviously the kind of thing you're trying to take IF away from.
So...
# You open the door. Inside you see a long hallway which extends to a
# closed double door. Lit candles line the walls. [Maybe?]
Okay, here's my other question. Say that in the hallway hung above
the double door you just opened was a painting of Aunt Mae. In RL,
you would not see this painting when you walked in the hallway, and
you wouldn't notice it unless you looked around. Will your system
follow this logic?
# >go through the door
#
# Your footsteps echo heavily down the hallway.
#
# You are in the middle of a long hallway. At the end of the hall is
# a large double door, closed. Lit candles line the walls.
#
# >look around
#
# You are in the middle of a long hallway. Behind you is an open
# double door. Hung above it is a huge painting of Aunt Mae. At the
# end of the hall...
Just curious and intrigued.
Greg
--
This space for rent.
George Caswell
On Mon, 25 Nov 1996, Greg Falcon wrote:
> George Caswell <timb...@adamant.res.wpi.edu> wrote:
>
> > First- Except in special circumstances, directions within the player's
> >180-odd degree of vision would have the 'primary' focus, listed first and
> >given the most favor in focus decisions. further to the sides and back would
> >be listed later and in less detail.
>
> First of all, let me say that I have been following the threads about
> your system, and I think it has real promise.
>
Thank you.
> Just curious about the scoping rules.
>
I expect the scoping rules will have to be refined through playtesting of
sector-system interactive demos... There's really not much way to figure all
these things out ahead of time.
> Let me go in and out of example script... I'll prefix my example with
> #'s.
>
> # You are in a dull white room, here for the purpose of example. The
> # only thing worth noticing is a huge double door.
> #
> # >open door
> #
> # Opened.
>
> Okay, say this door leads into a big hallway. Will opening the door
> automatically tell the player what he sees behind the door? I think
Hmm.. hadn't thought of that..
> So...
>
> # You open the door. Inside you see a long hallway which extends to a
> # closed double door. Lit candles line the walls. [Maybe?]
>
Quite possible. Clearly the different levels of description are going to
have to be implemented in the 'secondary-focus' sector object... The level
and style of the room description will have to be decided by the game
author... Of course, the list of -objects- in the 'secondary-focus' area
-will- need to be dynamically generated-- but it's basically the same deal--
it will be up to the room objects and player object to decide what such
objects will be in the descriptions.
> Okay, here's my other question. Say that in the hallway hung above
> the double door you just opened was a painting of Aunt Mae. In RL,
> you would not see this painting when you walked in the hallway, and
> you wouldn't notice it unless you looked around. Will your system
> follow this logic?
>
There's no real way to implement this as a default... it -could- be done
as a 'real space' problem, but I wouldn't reccomend a 'real space'
implementation just for solving this problem-- besides which, there are too
many specifics about the door and the room and the object in this situation
that can't be represented by numbers. I think this case would call for
special coding-- But in most any case such a conspicuous item would probably
be seen as you -enter- the room.
> # >go through the door
> #
> # Your footsteps echo heavily down the hallway.
> #
> # You are in the middle of a long hallway. At the end of the hall is
> # a large double door, closed. Lit candles line the walls.
> #
> # >look around
> #
> # You are in the middle of a long hallway. Behind you is an open
> # double door. Hung above it is a huge painting of Aunt Mae. At the
> # end of the hall...
>
My thought was that all visible objects in a sector would always be
mentioned in room description-- starting with objects in primary view (ahead
and to the sides) and ending with the periperal and purely remembered view--
the theory being that we don't want to confuse players by having objects
appear and disappear from room descriptions, and that the player-character
glances around when entering an area and can remember what's behind them.
The extended focus would follow slightly different rules. Exits and
adjoining rooms would always be mentioned, one way or another, but exits ahead
would be the only ones mentioned in detail (probably).. Exits behind would
simply be mentioned as being present. (again, probably.) One planned
exception, to help players with navigation, is the exit the player -entered- a
room from- the direction of the exit (and perhaps, details about the room)
would be a part of the room descriptions. (So players would have a
navigational reference if they -did- have to resort to relative positioning)
And speaking of the idea of treating the way a player comes in as a
'special' reference point to a room, I've been thinking of using this as a way
of interfacing navigation to the player-- such as 'second door on the right'
(recently used as an example of directions the well-dressed adventurer doesn't
understand.. <g>) It could be abbreviated effectively, should be applicable
to all room types I've considered (point, linear, planar-- except in odd
circumstances, which I've forseen but can't be sure if they'd be real
situations...), and, once the player has an idea where they're going, it could
be rather effective.
Jay Walton
The MUSEUM example file might help, especially the room with the
huge mirror. Also, the way the room description is printed in
ADVENTURELAND might be useful as well. So something largely from
ADVENTURELAND and some from the Mirror Room in MUSEUM might work,
though it'll probably drive the player nuts seeing all the
descriptions of all those rooms.
Maybe something like this would be better:
Long Corridor
You are in a long corridor.
A large door stands wide open to the north.
>look through door
You can see:
Longer Corridor
Yet another long corridor.
Yet another large door stands to the north. It is locked
tight.
More streamlined, I suppose.