[IF Theory] Room descriptions
Steve Breslin
will be (naturally) room descriptions. Of course I don't have a great
"1-2-3, here's how it's done" type tutorial, but I'd like to go over a
few basics which everyone already knows. And especially I'd like to
hear responses.
So I'll list a few things quickly, not so much for the purposes of
tutorial (though I'm casting it as such), but to initiate a
discussion:
----
Listing exits:
One of the principle aims of a room description is to explain clearly
to the player where the PC can go from the current location.
This is a *major* problem, because: 1) a list is going to be boring;
2) also, since you're going to incorporate this information in every
room, the list is going to be boring and repetitive.
It is tempting to end a description with a statement like: "From here,
the path stretches east and west. To the north you see [...]."
But while the exits need to be clearly remarked by the room
description -- and this is indeed a mostly mechanical requirement of
the form -- the mechanism for listing the exits has to be as concealed
as possible.
So when you're describing the space of the room, incorporate
exit-listing remarks as subtly as possible, and not all in a row.
----
Exposing the space:
One of the main obstacles of describing a space in IF is that the
rooms (locations) are monadic: they're without real extension, and
don't blend into one another gradually like spaces do in 3D games for
example; each space is equally claustrophobic. So try to describe the
space of each room to give the illusion of what space you're trying to
model, be it a mountaintop or a closet.
The sentences of the room description are like the eyes of the player,
as the player looks around the room. You might think of a video-camera
looking around, or think like a movie-director, and present broad and
narrow images and scapes; whatever is appropriate to the space.
The sentences, the pacing of the sentences and their order -- this is
analogous to the PC looking around and noticing different things in
the room.
(It may be that short sentences are better for cramped spaces, and
long, elaborate sentences are better for spacious locations.)
----
Writing style:
It's easy for the player to notice if you're trying to write beyond
your comfort level. Faulty diction, i.e., a failed attempt at "purple
prose" -- this is a killer! Highly elaborate writing is great, but if
you don't handle the writing flawlessly, lush lyricism will do much
harm and no good.
A sentence will sound good if you spend time on it -- your writing has
what charm you put into it! --, and "purple prose" is just one style
of many. Be wary of the shortcut which finds you using language beyond
your comfort level, writing in an inauthentic or forced style.
----
All other points or suggestions/revisions are most welcome!
Rexx Magnus
> I'll be teaching an IF class next Fall, and one of the early "lessons"
> will be (naturally) room descriptions. Of course I don't have a great
> "1-2-3, here's how it's done" type tutorial, but I'd like to go over a
> few basics which everyone already knows. And especially I'd like to
> hear responses.
Rather than type in a list form, as this will be difficult for me to do,
I'll just add a few comments.
When writing my room description, I almost never put the exits in a list
at the end. The only time I will do this is, for example, if the exits
would be percieved as being arranged in an orderly manner, such as in a
corridor or other regular room, as opposed to an outdoor or natural
locale.
I'll pass over the area, giving a general feel - whatever might hit your
senses first - such as something describing the lighting level, the
temperature, any strong smells, then moving on to details in no particular
direction, but describing exits if they happen to be near those details.
I'd never make descriptive sentences short if the location was small, my
mind just doesn't work like that. I prefer to use other tricks such as
similies, metaphor, alliteration (sp?) and if it seems appropriate, short
or longer words, or even onomatopeias (is that how you spell those words
that sound like what they mean?). Shorter sentences just seem to suggest
less detail, rather than magnitude.
Bearing in mind that you sometimes have to force the player's emotional
state so that it fits the protagonist's, I'll often dwell on the
description of a location longer if it is one that the PC would enjoy in a
sensual aspect. If they don't enjoy it that much, the description will be
a little more functional rather than prosaic, in order to force the
feeling of the need to get a job done. That isn't to say that I would
always do it if it were to sacrifice atmosphere.
To email me, visit the site.
Kleinecke
> I'll be teaching an IF class next Fall, and one of the early "lessons"
> will be (naturally) room descriptions. Of course I don't have a great
> "1-2-3, here's how it's done" type tutorial, but I'd like to go over a
> few basics which everyone already knows. And especially I'd like to
> hear responses.
contribution. Anyway the subject is of great interest to me.
I apologize if everybody knows this, but the earliest level I can
recover of the grand-daddy of interactive fiction, Adventure, did not
use north, south, east, west movement commands. The very first thing
you saw was YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK
BUILDING. AROUND YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE
BUILDING AND DOWN A GULLY. and movement was controlled by selecting a
noun from room description - ROAD, BUILDING, FOREST or STREAM. The
west, east, north, south verbs were added later. This situation holds
for the first thirty or forty rooms. The imfamous maze is built on
north ... and may have been the motivation for the compass points (if
all the rooms have the same description you cannot use the original
technique).
I have never liked the compass points technique so I have experimented
with room descriptions that work in terms of left, right, ahead,
behind. This is not too hard to do in, for example, C. I use rooms
with intrinsic compass points and keep track of the direction the
actor is facing. Then I tailor the description
to the actor's direction. Generally I do not describe what is behind
the actor. The actor must "turn around" (or at least left or right) to
see that part of the
room description.
With this in mind the only direction I let the actor go is ahead.
Otherwise the actor must turn first. This works, in my small examples,
and feels somewhat like a first-person shooter. But I have no complete
game examples to offer.
In my biased opinion the compass point technique is holding
interactive fiction back. Non-gamers always seem to find it risible.
I am not at all sure that a class on IF would benefit from a
discussion of how not to use compass points (I have mentioned two ways
in this post) but I do think this is a subject the interactive fiction
community ought to consider.
Rexx Magnus
> With this in mind the only direction I let the actor go is ahead.
> Otherwise the actor must turn first. This works, in my small examples,
> and feels somewhat like a first-person shooter. But I have no complete
> game examples to offer.
>
> In my biased opinion the compass point technique is holding
> interactive fiction back. Non-gamers always seem to find it risible.
>
I guess it depends on which perspective the game is written in.
Personally, I'd never want to play a game in which I have to turn around
before moving (making at least two commands necessary instead of one).
Most IF is written in a sort of 3rd person, and as with many 3rd person
games and fiction, you never see only what the person sees. I've yet to
read a novel that describes solely what is in front of the protagonist.
Jayzee
> ver...@hotmail.com (Steve Breslin) wrote in message news:<f407dc2b.04062...@posting.google.com>...
>
>>I'll be teaching an IF class next Fall, and one of the early "lessons"
>>will be (naturally) room descriptions. Of course I don't have a great
>>"1-2-3, here's how it's done" type tutorial, but I'd like to go over a
>>few basics which everyone already knows. And especially I'd like to
>>hear responses.
>
[snip]
> I have never liked the compass points technique so I have experimented
> with room descriptions that work in terms of left, right, ahead,
> behind. This is not too hard to do in, for example, C. I use rooms
> with intrinsic compass points and keep track of the direction the
> actor is facing. Then I tailor the description
> to the actor's direction.
I'd say the compass-point travel system is least-worst rather than a
good solution, but relative directions, while they do make for better
descriptions imo, introduce other problems for the player. Have a look
on Roger Firth's site for a good overview.
http://www.firthworks.com/roger/informfaq/ww.html#10
> Generally I do not describe what is behind
> the actor. The actor must "turn around" (or at least left or right) to
> see that part of the
> room description.
>
I would disagree about making the player turn around. I've always
interpreted the look command as "look around"; i.e. the player is
rubbernecking: gawping at the majesty of the cathedral, drinking in the
view, or sneering at another character's taste in interior decoration
for example. IRL you can look at 99% of where you are without moving
your feet, and in IF it's 100% because there's no movement command
equivalent to "take a step to the left".
Obviously if the player is strapped into a poetry appreciation chair or
something then the situation is different.
> With this in mind the only direction I let the actor go is ahead.
> Otherwise the actor must turn first. This works, in my small examples,
> and feels somewhat like a first-person shooter. But I have no complete
> game examples to offer.
>
So travel is usually a two command sequence? (Turn left, go [ahead])
Or do you make either the turn or the go implied?
> In my biased opinion the compass point technique is holding
> interactive fiction back. Non-gamers always seem to find it risible.
>
You might find it interesting to have a look at "Hunt the Wumpus" which
uses relative directions and then see the author's comments on how the
travel requirements impacted on the design of the game and the map.
S
> movement was controlled by selecting a noun from room
> description - ROAD, BUILDING, FOREST or STREAM.
I consider this a superior system for "new-school" games. It allows for
shorter and less awkward room descriptions, and it removes the need to
explain why the protagonist has an innate compass sense. It may also help
free the designer from thinking "too geographically" about their game.
> Then I tailor the description to the actor's direction. Generally I
> do not describe what is behind the actor. The actor must "turn
> around" (or at least left or right) to see that part of the room
> description.
This places a big burden on the designer. They now must ensure that the
player is never confused by the change in direction (and hence the
disappearance of certain details). It also increases the complexity of the
source text and code.
From the player's perspective, using two commands to backtrack is an
un-feature.
S.
Kleinecke
> Kleinecke wrote:
> > have experimented with room descriptions that work in terms of left,
> > right, ahead, behind.
> So travel is usually a two command sequence? (Turn left, go [ahead])
> Or do you make either the turn or the go implied?
I have tried alll three approaches. Mind you, only in toy games.
Perhaps I have spent too many years playing first-person shooter games
(for example DOOM) to be a good test.
Generally I, by various means, put the actor into either a going or a
stopping mode. That is, if the actor is going, she/he continues going
until the player says stop. In going mode a turn is all that is
needed.
I am fairly firm about not wanting the actor to have eyes on the back
of her/his head so I don't like the mode where a turn automatically
goes. It seems to me that in real life (and I do a lot of walking in
real life) walking and stopping are really two different modes. If
this ever got to a serious game I would probably use two different
room descriptions - one for hurrying through and one for stopping and
looking (similar to, but different than the brief versus verbose
choice).
It seems to me that the key problem is how to impart urgency to the
player (to prevent stopping at every step and examining everything in
detail). Seeing things out of the corner of your eye while passing by
is a real life thing. I
don't like the pressure of a countdown clock but I have found no other
way to make the player experience urgency.
Default User
> Most IF is written in a sort of 3rd person, and as with many 3rd person
> games and fiction, you never see only what the person sees. I've yet to
> read a novel that describes solely what is in front of the protagonist.
Really? It's not my experience that many games do that. It's usually
pure second person, the room descriptions are what the player character
is experiencing at that moment. All the sights, sounds, tactiles are
same for both. What would be the reason for having things hidden from
the PC that are known to the player?
Brian Rodenborn
Kleinecke
> good solution, but relative directions, while they do make for better
> descriptions imo, introduce other problems for the player. Have a look
> on Roger Firth's site for a good overview.
>
> http://www.firthworks.com/roger/informfaq/ww.html#10
agree with all of it. I would not try to implement left-right
diections in any of the IF languages I have ever seen. That is why I
have not attempted any real games. My toy games are in C and, so far,
I am seen no easy way to write a real game in C.
The test game is cute but inconclusive. I conclude that much depends
on your experiences. If compass-point games fit comfortably into your
head you will prefer them. As I have stated my experience is deeply
colored by games which do use right-left directions (first-person
shooters like DOOM). Compass point games do not fit comfortably into
my mind.
If we want to recruit new people into interactive fiction we need to
know what feels best to people with NO computer gaming experience of
any kind. Until somebody (not me) makes such an experiment we can only
guess. In the computer
gaming world as a whole text games are a tiny niche. Perhaps the
people who are into first-person shooters know something.
Mike Roberts
> I have never liked the compass points technique so I have
> experimented with room descriptions that work in terms of
> left, right, ahead, behind.
This would be a good time for me to plug my game Rat in Control (on the IF
Archive under games/tads), which came out of some raif discussion last year
on the relative merits of various navigational systems - see, for example,
http://www.google.com/groups?threadm=b5ut2a%24un2%241%40slb6.atl.mindspring.net.
> In my biased opinion the compass point technique is holding
> interactive fiction back.
That seems to me a rather bold claim, even setting aside my own opinion that
compass directions are the most satisfactory system that's been demonstrated
so far.
--Mike
mjr underscore at hotmail dot com
Muffy St. Bernard
news:YUECc.50$Ab6...@news.oracle.com...
> "Kleinecke" <klei...@astound.net> wrote:
> > In my biased opinion the compass point technique is holding
> > interactive fiction back.
>
> That seems to me a rather bold claim, even setting aside my own opinion
that
> compass directions are the most satisfactory system that's been
demonstrated
> so far.
I agree...I think that, in a hypothetical list of reasons why more people
don't play IF, "compass directions" would be near the bottom...far below
(usually) a total lack of graphics or sound, a need to have relatively good
reading comprehension and a good imagination, controlling the player using
language as opposed to a joystick or predefined keys, very little illusion
of events being real-time, the need to (hopefully) solve puzzles more
complex or abstract than pushing certain buttons to open certain doors, no
multiplayer capability, inability to add mods, no marketing or advertising
budgets, and the fact that IF is very little like watching TV.
Your average game player -- in my opinion -- is going to stop at those
hurdles first, as opposed to being concerned with the style of movement in
the game itself.
I'm not saying that left/right movement isn't a good idea (in certain
situations it could be a fantastic idea if implemented properly), but I
can't imagine that it would be a technique resulting in a larger fan base
(if that's what you meant by not interactive fiction being "held back"...I
assume so, because in another message you said "Until somebody (not me)
makes such an experiment we can only guess. In the computer gaming world as
a whole text games are a tiny niche. Perhaps the people who are into
first-person shooters know something.")
Muffy
http://www.dazzled.com/dangermuff
Steve Breslin
>Most people have at one time or another had this feeling of being all
turned
>around, that they thought they were going one way but it turned out
they were
>going another.
That's my feeling about this thread.
I wish this discussion had something more directly to do with room
description style and technique.
D. R. Porterfield
> will be (naturally) room descriptions. Of course I don't have a great
> "1-2-3, here's how it's done" type tutorial, but I'd like to go over a
> few basics which everyone already knows. And especially I'd like to
> hear responses.
Before addressing your specific points, I'd like to make a more
general observation about room descriptions. I've found that they're a
lot like writing poetry -- not in terms of rhyme and meter, of course,
but in terms of condensation and distillation of language. The
challenge is to convey a clear, vivid sensory description of the PC's
surroundings as concisely and naturally as possible, so that the
player effectively "sees" and "hears" and "smells" (and perhaps also
"feels" and "tastes") her environment rather than merely reading words
on a screen. This is one of the two main parts of writing interactive
fiction that makes it an art (the other being elegant coding), and the
one most visible to the end user.
> Listing exits:
I think that whenever possible, exit listings should be woven into the
general room description rather than listed separately at the end.
Also, I personally find it easier to visualize a room when the
description follows the circle of compass directions in order, like a
camera doing a 360-degree pan, rather than jumping randomly around.
> Exposing the space:
In general, I try to avoid beginning room descriptions with "You are
in..." because the PC's presence in the room is self-evident, but this
is by no means a hard and fast rule. I'll refer to the major objects
in the room, but save most of the details of those objects for their
own individual descriptions, allowing the information to unfold as the
player examines the objects individually. If there's a great deal to
describe in the room, I'll often make the description more detailed
when the player first enters, but use a more abbreviated description
in subsequent visits to avoid the annoyance of reading a lengthy
description repeatedly. I don't think it's so much the length of the
sentences as the choice of words that creates a sense of the size of
the space involved.
> Writing style:
I'd say the most important aspect of style in IF is that the writing
not call undue attention to itself. The idea is to give the player a
"you are there" experience rather than a "reading words on the screen"
experience. Descriptions should be concise, but not so sparse that the
surroundings seem vague or muddled. I think a bigger temptation is to
overwrite descriptions -- "purple prose," as you say -- which can
easily destroy the sense of immersion, especially if the author is
overreaching and the writing sounds forced. Also, some players may be
discouraged by excessively long blocks of text.
The Inform Designer's Manual has an excellent section on room
descriptions that you might also be interested in reading:
http://www.inform-fiction.org/manual/html/s51.html
Hope this helps,
-- David
S
"Steve Breslin" <ver...@hotmail.com> wrote:
> I wish this discussion had something more directly to do with room
> description style and technique.
Well, you did make a 3-in-1 post. The discussion of exits is mostly
on-topic with one of your three talking points (describing exits does depend
on how exits work). Maybe you should post another thread (or two) about the
others?
S.
Rexx Magnus
Sorry, I was writing without thinking there. I mean to refer to most of
the 3d games I've played being in 3rd person, not IF. What I meant was
that the way that information reaches the player is similar to a 3rd
person 3d game, you see what is around the player all in one go (kind of)
rather than being presented with a field of vision. Of course, there are
some points that aren't exposed (as with a 3d game, you don't see the
entire area, but the things that are relevant to the character in that
area).
DragonSage
--
DragonSage
A.K.A. Robert DeFord
"D. R. Porterfield" <drpf...@measinc.com> wrote in message
news:a0425cbf.04062...@posting.google.com...
samwyse
> I guess this is as good a place as any for a lurker to make his first
> contribution. Anyway the subject is of great interest to me.
Great to have you join us!
> I apologize if everybody knows this, but the earliest level I can
> recover of the grand-daddy of interactive fiction, Adventure, did not
> use north, south, east, west movement commands. The very first thing
> you saw was YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK
> BUILDING. AROUND YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE
> BUILDING AND DOWN A GULLY. and movement was controlled by selecting a
> noun from room description - ROAD, BUILDING, FOREST or STREAM. The
> west, east, north, south verbs were added later. This situation holds
> for the first thirty or forty rooms. The imfamous maze is built on
> north ... and may have been the motivation for the compass points (if
> all the rooms have the same description you cannot use the original
> technique).
I'm not saying that you are wrong, but every version of Adventure that
I've ever seen allowed compass directions, it just didn't require you to
use them very much. My yellowing FORTRAN source allowed the use of
compass directions, or you could name a room and, assuming that it was
adjacent, you would go there. In fact, there was special code so that
the tenth time that you typed in "west", the game would tell you "IF YOU
PREFER, SIMPLY TYPE W RATHER THAN WEST."
I'm also at a loss to understand how, under the scheme you describe, you
would get to a room for the first time.
Still, my source dates from sometime between October, 1979, and
December, 1980. If you have something that is earlier than that, please
share it. Neither Crowther nor Woods kept the earliest versions and
they are widely believed to be lost.
samwyse
> I am fairly firm about not wanting the actor to have eyes on the back
> of her/his head so I don't like the mode where a turn automatically
> goes. It seems to me that in real life (and I do a lot of walking in
> real life) walking and stopping are really two different modes. If
> this ever got to a serious game I would probably use two different
> room descriptions - one for hurrying through and one for stopping and
> looking (similar to, but different than the brief versus verbose
> choice).
There have been games that experimented with modes similar to what you
describe. I know that I quoted the following text within the past six
months, but I feel the need to do so again.
From Graham Nelson's "The Inform Designer's Manual", 4th edition:
Another device, used in the spy thriller `Border Zone' (Marc Blank,
1987), is to respond to directions not with a description of the new
location but with a response about how you got there:
>east
You open the door and walk out into the passageway. You scan the
passageway, noting guards at either end, machine guns poised at their
sides. You don't remember them from the beginning of the trip, so you
can only suppose that security has been tightened in the search for the
American agent.
>look
Outside Your Compartment
You are standing in the passageway that runs along the length of the
car. At either end of the passageway, a guard is standing, machine gun
poised at his side. Right now, you're standing outside your own compartment.
L. Ross Raszewski
>I'd say the most important aspect of style in IF is that the writing
>not call undue attention to itself. The idea is to give the player a
>"you are there" experience rather than a "reading words on the screen"
>experience. Descriptions should be concise, but not so sparse that the
>surroundings seem vague or muddled. I think a bigger temptation is to
>overwrite descriptions -- "purple prose," as you say -- which can
>easily destroy the sense of immersion, especially if the author is
>overreaching and the writing sounds forced. Also, some players may be
>discouraged by excessively long blocks of text.
>
I'm inclined to believe that the natural inclination is to overwrite
the *first* room description, and under-write the *fiftieth*
(And, of course, IF Insurance Lawyers tend to underwrite everything.)
Jayzee
What if instead of the old amnesia cliche, the player has
foreknowlege of events - but only limited or intermittent control
of the PC? Might be fun - or totally unplayable if done wrong, of
course.
>
>
> Brian Rodenborn
non...@nowhere.com
Max
"Kleinecke" <klei...@astound.net> wrote in message
news:e545c6ce.04062...@posting.google.com...
[Kleinecke discussed three navigation systems...
1. Adventure-style: just type the name of the destination
2. Traditional: compass directions
3. Relative: left, right, forward, behind]
How about a combination? I think I could work out a system in TADS
which keeps track of current facing. Adventure-style isn't difficult,
and it would be made less clunky (I personally hated this system as
Adventure implemented it) with hyperlinks (a la HTML TADS).
Incomplete and badly done example code (TADS 3) (I think TADS might have
a way to do some of this properly in adv3 (take a look at travel.t):
sampleRoom: Room 'Sample Room'
"You are in a sample room. On every walls there are samples,
sorted by colour. On the << atNorth('wall') >> are red and pink
samples, opposite them are the green samples. The blue samples
are << toTheWest() >> and << toTheEast() >> are the most
important samples of all: octarine. Beneath the octarine
samples lies the door to the <A HREF='east'>boiler room</A>."
;
// I've been noticing it other peoples games (I don't find it
// incongruous, I just happened to notice it today) the use of
// lies: "the path lies to the west", "on the east lies a pretty meadow.
// I think maybe we over-use this word. Steve, be careful not to
// indoctrinate your students with ideas we are thoughtlessly
// following ourselves.
function atNorth(str) // returns str (a noun), with a "north" adjective
{
if (navigation.useCompassDirections)
return 'north ' + str;
else
{
switch (navigation.facing)
{
case North:
return str + ' in front of you';
case West:
return str + ' on your left';
case East:
return str + ' on your right';
case South
return str + ' behind you';
}
}
function toTheNorth() // return this direction as an adverbial phrase
{
if (navigation.useCompassDirections)
return 'to the north';
else
{
switch (navigation.facing)
{
case North:
return 'in front of you';
case West:
return 'to the left';
case East:
return 'to the right';
case South
return 'behind you';
}
}
Of course, I wouldn't implement such a system. It strikes me as
superfluous, and would have no idea where I was going (so I would have
to draw a map, but because there are no compass directions, drawing the
map would take twice as long as playing the game). I might, however, think
of including more hyperlinks on my exits, and I will try to avoid listing
exits at the end of the description.
BTW, someone said that standing still, one can see 99% of a room. I just
did a little experiment:
As I walked into my study, I could see the WHOLE room from the doorway.
From where I am sitting, I can see 90% of the room, and the few square
metres I can't see, I can infer (if I look over my left shoulder, I see
the last volumes of the encyclopedia, and looking over my right I can
see the first volumes; without even thinking about it, I assume that in
the few degrees I can't see lies the remainder of the encyclopedia; that
assumption is, of course, correct).
Sorry about the long-winded reply. I hope it was worth reading.
--Max
ems...@mindspring.com
> Listing exits:
>
> One of the principle aims of a room description is to explain clearly
> to the player where the PC can go from the current location.
>
> This is a *major* problem, because: 1) a list is going to be boring;
> 2) also, since you're going to incorporate this information in every
> room, the list is going to be boring and repetitive.
>
> It is tempting to end a description with a statement like: "From here,
> the path stretches east and west. To the north you see [...]."
>
> But while the exits need to be clearly remarked by the room
> description -- and this is indeed a mostly mechanical requirement of
> the form -- the mechanism for listing the exits has to be as concealed
> as possible.
I'm not sure this is true in all cases. If you take the exit listing
out of the room description entirely and put it on its own line
(either below the description or as a status line), then I suspect
people stop expecting it to blend with the prose at all, and see it as
a piece of the UI like the time/date/score/etc stuff in the status
line.
Also, I sometimes leave out directions from descriptions of rooms
where a) there is only one exit and b) the player has come there from
the outside. Either they'll remember the direction by which they came
in and reverse that, or they'll type OUT (which should, IM very bossy
opinion, always always work in an indoor location with only one exit
-- in some games I've added a default to the Room class such that all
rooms with only one exit will automatically map OUT to that exit).
This seems not to perturb anyone too much.
To address the compass/compassless question: I haven't really very
much liked the games I've played that discarded compass directions,
for the most part, because compass directions are a convenient
shorthand for understanding a layout of space in absolute terms.
(This suggests to me that the room descriptions do two related but not
identical things here: one is to tell the player where he can go, and
the other is to help the player understand, in general terms, how the
pieces of the geography relate to one another. This latter is
something Graham talks about in one of the iterations of Craft of
Adventure -- about rivers, cliffs, and other multi-room geographical
features helping orient the player. Off the top of my head, a few
other games do some interesting things with this -- Inevitable has a
large monument that you can see from multiple directions, which helps
give a sense of the absolute space, for instance.)
Anyway, though I wouldn't want to get rid of compass directions in the
majoring of cases, I have noticed from looking through logs of newbie
players that they do tend to type things like "go to the kitchen"
rather than "north". So I'm inclined to think that the ideal solution
for most IF, barring other considerations, is to leave in some kind of
absolute directional system but also allow GO TO [adjacent room] at
the very least. (Going to more distant rooms is obviously more of a
problem.)
>
> So when you're describing the space of the room, incorporate
> exit-listing remarks as subtly as possible, and not all in a row.
> ----
> Exposing the space:
>
> One of the main obstacles of describing a space in IF is that the
> rooms (locations) are monadic: they're without real extension, and
> don't blend into one another gradually like spaces do in 3D games for
> example; each space is equally claustrophobic. So try to describe the
> space of each room to give the illusion of what space you're trying to
> model, be it a mountaintop or a closet.
Yes, absolutely. "Craft of Adventure" has some neat stuff about how
to create the illusion of spatial continuity. I also commented on
this with "Fire Tower" from the most recent art show -- Jacqueline
does a great job of giving the sense that one space feeds into
another, by including views that you can look at from several
locations, providing transitional descriptions when you walk from one
room to another, and so on.
> The sentences, the pacing of the sentences and their order -- this is
> analogous to the PC looking around and noticing different things in
> the room.
>
> (It may be that short sentences are better for cramped spaces, and
> long, elaborate sentences are better for spacious locations.)
Hmm. This is an interesting proposition; I don't think I've heard
that argued (or even suggested) before.
Most of what I've read about room description prose has to do with
clarity -- making it clear to the player what objects in the room are
likely to respond to interaction. Long, elaborate sentences tend to
introduce a lot of nouns, and the problem with nouns is that, usually,
the player thinks that he ought to be able to do something with them.
See http://www.doggysoft.co.uk/inform/write/prose.html for a
particularly amusing example. I am not sure that I equate "beautiful
prose" with ornateness or length, as Gareth Rees seems to do in this
article, but he does point out
some good reasons why elaboration you don't need can be a bad thing
for a game. Along the same lines, I think the primary impression I
get from the length of a room description is not about the size of a
space, but about the amount of clutter in it. Too much stuff and I
become daunted by how much work I'm going to have to do, looking at it
all; too little, and I feel like I have no options.
I'd have to play some games with this specifically in mind to
determine whether I think longer descriptions are better suited to
larger spaces; from here it sounds like an interesting stylistic
conceit that might work in some cases but is hardly necessary
everywhere.
Jan Thorsby
<ems...@mindspring.com> skrev i melding
news:a69830de.04062...@posting.google.com...
> become daunted by how much work I'm going to have to do, looking at it
> all; too little, and I feel like I have no options.
One could highlight the stuff that it is possible to interact with. Then a
long description would not be daunting.
ems...@mindspring.com
One could. At that point, though, it stops feeling quite so much like
IF to me. I'm not crazy about games with highlighting and hypertext
in them.
I can think of a couple of games that do something like this. One is
the ADRIFT game "Black Sheep's Gold", and the highlighting provides
something of a workaround for ADRIFT's parser shortcomings, because
the UI is incredibly explicit about what you can and can't do. The
other that comes to mind is the conversation system in "The Adventures
of Helpfulman", which gets around the guess-the-noun aspect of
ASK/TELL by making all valid topics into hyperlinks in the text.
The effect is interesting and reasonably playable, but I find it also
makes me constantly aware of the guidance of author and interface, to
a degree that distances me from the game. There seems to be a
trade-off here between playability and immersion in the world, and I
at least find traditional formats sufficiently playable that I don't
want to make further sacrifices in order to get an easier game.
DragonSage
>Too much stuff and I
> become daunted by how much work I'm going to have to do, looking at it
> all; too little, and I feel like I have no options.
I agree with this statement, going so far as to say that it might be the a
significant element in the art of creating IF that engages the player.
However, I have a question for the folks on this list who know a lot more
about IF than I do.
Has anyone tried putting significant nouns in italics or bold to indicate
importance? Or, even making them hyperlinks to the "examine" text? Would
this make the game easier to play (i.e., eliminate the guessing)? Or, would
it detract from the game? Personally, I like to play IF as fast as possible
because I'm intently focused on sniffing out the plot and the puzzles, not
struggling with game mechanics. Consequently, I dislike "guess the verb"
looping, and "no-description" trial-and-error noun hunts. But, these things
seem to be part of the IF tradition, and they just might be part of its
charm.
--
DragonSage
A.K.A. Robert DeFord
<ems...@mindspring.com> wrote in message
news:a69830de.04062...@posting.google.com...
DragonSage
this great answer to my posted question.
--
DragonSage
A.K.A. Robert DeFord
<ems...@mindspring.com> wrote in message
news:a69830de.0406...@posting.google.com...
Rexx Magnus
> Anyway, though I wouldn't want to get rid of compass directions in the
> majoring of cases, I have noticed from looking through logs of newbie
> players that they do tend to type things like "go to the kitchen"
> rather than "north". So I'm inclined to think that the ideal solution
> for most IF, barring other considerations, is to leave in some kind of
> absolute directional system but also allow GO TO [adjacent room] at
> the very least. (Going to more distant rooms is obviously more of a
> problem.)
What's the simplest way of doing this in inform? (for adjacent locations)
Do you have to catch before[;go:;] for each location and pluck out the
possibilities by hand, or is there a more elegant solution to resolve it?
S
"Rexx Magnus" <tras...@uk2.net> wrote:
> What's the simplest way of doing this in inform? (for
> adjacent locations) Do you have to catch before[;go:;]
> for each location and pluck out the possibilities by hand,
> or is there a more elegant solution to resolve it?
With about a page or two of code you can handle the problem in the
general sense. Extend the "go" verb with a scope rule, and in that scope
rule, place in scope the rooms/routines listed in n_to, s_to, etc. Rooms
need their 'name' attributes defined so the player has a way to reference
them. There are a couple other wrinkles (PrintVerb, etc) but it's doable.
I know, because this is the extension I was asking about in my recent
thread on include order. :^) I'm just cleaning it up, then I'll publish it.
(Actually, it uses several properties to allow adjacent travel, travel to
distant-but-visible locations, and examination of adjacent and
distant-but-visible locations).
S.
ems...@mindspring.com
It's a little bit trickier than that because you need to set the
scoping up so that adjacent locations can be referred to in the GO
command, even if they're not otherwise in sight. Fortunately, there
are a couple of extensions that already exist for this kind of thing.
One is GoNeighbour.h by Alan Trewartha, which I used in Savoir Faire;
there's also, I think, Goto.zip by Toni Arnold, which sets up the map
so that the player can go to *any* room (and the game will plot out a
path). That one takes some extra set-up, and I've never tried to use
it myself.
A quick look through here
http://www.inform-fiction.org/extensions/map.html
will give you some idea of related extensions that might also be
useful.
-- Emily
YoMan
My answer may be wrong, for i have written only one game so far and
lack experience about this, though that game relied mainly on
atmosphere and descriptions. Also, since i am relatively new at
inform, i may tell things that would seem obvious to you.
1)
I thought that maybe the "perfect" object room description is no
description at all. The object "room" having just a title to set the
place and being an empty scenery shell.
Then that room would be filled with objects that would thread the room
description with their initial values. These initial values needs as a
consequence to be hierarchised and linked. There would be a resulting
part including static objects and another one non static ones.
Exists could be listed too via objects initial values.
2)
There is a tacit pact made between the player and the writer, either
graphic adventure of IF : in a room description, there's only
descriptions and "interactive" objects for :
a) essential things for the plot of the game
b) eventual red herrings
c) things that add atmosphere or singularise the room (which can be
considered be a) things) or far too obvious.
If you make a room which is supposed to describe a crowded street of
Paris, the player could be interressed in looking at the cars, the
people, the shops, and even scenery which is supposed to be seen from
everywhere (the effeil tower for example), but unless your player is
very new at playing IF, he won't type something like :
> X pavement
because he knows he is playing a game, and he is not only the main
actor of the IF, he is also a player accepting the rules and the limit
of the writing.
I thought of huge librairies which would collect all the word linked
to a certain type of room that would answer a "I see nothing special
about this" instead of "I don't see anything like that here" to
non-descripted but obvious objects, but i doubt it will change the
experience of playing the game.
JB (poor english because still sleepy)
Daniel Barkalow
> I'll be teaching an IF class next Fall, and one of the early "lessons"
> will be (naturally) room descriptions. Of course I don't have a great
> "1-2-3, here's how it's done" type tutorial, but I'd like to go over a
> few basics which everyone already knows. And especially I'd like to
> hear responses.
>
> So I'll list a few things quickly, not so much for the purposes of
> tutorial (though I'm casting it as such), but to initiate a
> discussion:
>
> ----
> Listing exits:
>
> One of the principle aims of a room description is to explain clearly
> to the player where the PC can go from the current location.
I tend to feel that the positions and descriptions of the exits are a
substantial portion of the description of the shape of the room, and are
therefore important to the text of the description as well as for getting
the player around. In order to get a good image of the space, I need to
know where the things are relative to each other. For example (from
Anchorhead):
Outside the Real Estate Office
A grim little cul-de-sac, tucked away in a corner of the claustrophobic
tangle of narrow, twisting avenues that largely constitute the older
portion of Anchorhead. Like most of the streets in this city, it is
ancient, shadowy, and leads essentially nowhere. The lane ends here at
the real estate agent's office, which lies to the east, and winds its
way back toward the center of town to the west. A narrow, garbage-choked
alley opens to the southeast.
From the last two sentences, I find that this street leads up to the
office, and that there's an alley next to it. The directions tell me that
the office isn't off to the side of the street, and that the alley is to
the right of the office and adjacent to it. Inside:
Office
Pallid gray light trickles in through the drawn blinds. The office is
deserted, papers still scattered across the top of the desk. The front
door lies west, and the file room lies east.
This implies that the file room is in the back, not to the side. Sure, the
description could say "When you are facing away from the front door, the
file room is in front of you." but that's actually longer than using a
compass. If you think of the exits as anchor points in your description of
the space, they actually help to fix the mental image, even aside from
being necessary for getting around.
> Exposing the space:
>
> One of the main obstacles of describing a space in IF is that the
> rooms (locations) are monadic: they're without real extension, and
> don't blend into one another gradually like spaces do in 3D games for
> example; each space is equally claustrophobic. So try to describe the
> space of each room to give the illusion of what space you're trying to
> model, be it a mountaintop or a closet.
I've actually thought for a while that adding loose connections between
locations would improve the IF world model substantially. You ought to be
able to see things on the mountainside from the mountaintop, things in the
yard from the porch, etc.
Of course, this is a trickier technical issue than you probably want to
give to new authors.
-Iabervon
*This .sig unintentionally changed*