Why I does what I does
The Grim Reaper
start a new topic here. Namely, how do we tell the player what he's doing
here (in the game, anyway... I'm not sure how much i-f can help out with what
we're doing in a real life), and how do we make sure the player knows at least
some of what the charater knows. Also, how do we establish what the player's
goal is in the game? I see a couple choices, but I'm not real sure about any
of them. Anyone have a better suggestion?
- I could just include a short text file with the game, telling the player
who he is and what's he's trying to do here.
- I could have an NPC pop in at the beginning of the game, and explain things
(Hopefully in a believable fashion, ie "Lord King, as you recall, the
goblins to the north...")
- I could do a little flashback sequence at the start. This is my personal
favorite so far, but what if the player doesn't want to follow his memory
the way it should work?
- I could just pull the Amnesia routine, and give the player a really spotty
memory of what's gone on. But IMO, this seems really fake, usuall.
- I could let the player type in "What is ..." questions, ala Balances. This
seems rather tricky to code, though, and it seems difficult to let the
player know what to ask about.
Anyone else?
+----------------------------------------------------------+
| One .sig to rule them all, one .sig to find them... |
| One .sig to bring them all and in the darkness bind them |
+----------------------------------------------------------+
| The Grim Reaper (Reaper of Souls, Stealer of .sigs) |
| scy...@u.washington.edu |
+----------------------------------------------------------+
Jamieson Norrish
(The Grim Reaper) writes:
- I could just include a short text file with the game, telling the
player who he is and what's he's trying to do here.
Clearly different solutions will suit different games, but this one
seems to me to be the best of the ones you mentioned. While it perhaps
has the disadvantage of being a block of text with no interactivity in
it, I don't think that is too bad a thing. In most cases I doubt it
has to be long - just enough to give the general idea. Like:
"Life really hasn't been kind to you. Born to parents who had little
of anything, including time for their only child, you now have even
less than they did. You wear filthy old clothes, live in bus shelters
and in cardboard boxes, and eat at food banks. But perhaps now things
are finally looking up. In front of you is a house, and it looks
deserted. Maybe appearances are deceptive, but it's worth a shot -
being a squatter in a house is better than being a squatter in a box."
That's shorter than many room descriptions, and gives a fair idea of
the character's backgrounds, and a starting point for the game.
For more complicated backgrounds, where a lot of information needs to
be given to the player, I don't think this would work so well. Perhaps
some pre-game should be put in, so that the text is broken up, with
some interactive elements. I don't know, as I said, it seems to me to
be highly case specific.
Jamie
Andrew C. Plotkin
does The Grim Rea...@u.washin (1769)
> Namely, how do we tell the player what he's doing here (in the game,
> anyway... I'm not sure how much i-f can help out with what we're doing
> in a real life), and how do we make sure the player knows at least some
> of what the charater knows. Also, how do we establish what the player's
> goal is in the game? I see a couple choices, but I'm not real sure
> about any of them. Anyone have a better suggestion?
I'm not sure whether this will help, but I've always wanted to see a
standardized "recall" or "remember" command. "recall X" just displays
what your character knows about X from the past.
A silver knife appears from nowhere and falls point-first into the table
next to your hand.
> x knife
It's curved and glittering-sharp, with the name "Fistopopil" engraved on
the blade.
> recall Fistopopil
You reach back into the mist of your third-grade theology lessons....
Fistopopil was the Yethermin god of Getting Off Your Butt And Saving The
Princess.
(Pardon the silly example.) This is a nice way to provide a lot of
background information without starting the game with a huge intro
screen or providing an accompanying booklet. It's more, well,
interactive.
As usual, it should not be overused. I rather dislike games where it is
necessary to obsessively examine every object to find details. I would
hate for it to become necessary to example *and* recall every word you
see in the game.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
S.P.Harvey
[ a really good, intriguing intro paragraph which I cruelly deleted]
: That's shorter than many room descriptions, and gives a fair idea of
: the character's backgrounds, and a starting point for the game.
What I've done in my work-in-progress is to combine an intro paragraph
with a few beginning objects. The intro text refers to the items in
question, which can then be examined for further detail.
For the sake of grace and elegance, I'll probably tinker the object
description code to add a few lines the first time the object is looked
at, after which we just give the standard description.
In the plot, it's the items which have propelled the player into action,
so it seems natural those items will be brought along on the adventure.
Scott
--
----------------------| S.P. Harvey |--------------------------
"If my answers frighten you, Vincent,
you should cease asking scary questions."
- Jules, "Pulp Fiction"
----------------------| sha...@interaccess.com |--------------------------
Felix Lee
>I think introductory text should be as short as possible. When I start
>up a new interactive fiction, I want to get on with exploring the game;
>I have no motivation to read large wodges of introductory text, unless
>the author's prose style is really gripping.
same here, but for slightly different reasons. I want startup time
for a game to be as short as possible, for repeat play purposes. When
I continue a game the next day, I generally don't want to sit through
the same introduction sequence.
I think the intro should just set the scene and establish an initial
goal. In-depth background can be provided in written docs or in help
menus.
my rule of thumb is: anything that gets repeated often should be short
and simple.
--
Andrew C. Plotkin
Addition@netcom.c (882)
> Pardon me for simplifying things, but is there really any difference
> between this and simply using footnotes? They're simple to implement,
> remove the guesswork, and are a lot less contrived than having a command.
The guard blocks your way. "State your name."
> Recall Name
> You suddenly remember that you're Monty Haul.
> I think it's better if a player isn't required to start a game with
> Alzheimer's.
Well, you'd have most things integrated better; you don't "suddenly
remember" your name, you just read "Your name is Monty Haul." The idea
is not to give the player amnesia, but to give access to all the
information (realistically, a lot) which your character should possess
but doesn't go around thinking about all day.
I find footnotes to be very contrived, actually. They break my immersion
in the story, by acting like direct comments from the author.
Excerpts from netnews.rec.arts.int-fiction: 26-Oct-94 Re: Why I does
what I does Jamieson Norrish@akeake. (1197)
> The problem with this, as I see it, is that the player needs to know
> when "recall" will work. If you don't want to have the player use
> "recall" all the time, regardless of how often the author has
> implemented it, then there should be some marker for the player to
> recognise. I guess that's easily solved by a "This seems vaguely
> familiar" type of message, but I know that would really bug me after a
> few uses.
True, and true.
Introductory and background information, as I've seen it done, appears
in three ways:
- A block of text at the start of the game. (Very good if it's short,
very bad if it's too long. So there's a limit on how much you can convey
this way. Trinity and Curses are the standard examples of lots of
background imparted by a single well-written paragraph -- BUT both start
out in the real world, and so rely largely on *your* background
knowledge. It's much harder to do this in fantasy or SF games, unless
you rely on fantasy/SF cliche, and I'd hate to have to do that.)
- Books or lectures that you come across near the beginning of the game.
(Works well, but slightly unrealistic. Common. Maybe too common. I'm
looking for alternatives.)
- Sudden recall triggered by objects you examine. "EXAMINE KNIFE: This
is the silver knife of Woopidoodle, which was used by the great god
to..." (Kind of contrived, and it gets annoying to read the history
every time you examine the object. Or you could only have the history
appear once, but then the player can only read it once, which is silly
for background information.)
So I'm trying to split up the last alternative into orthogonal bits;
what the object looks like and what you know about it.
Gareth Rees
> [the introductory text problem]
I think introductory text should be as short as possible. When I start
up a new interactive fiction, I want to get on with exploring the game;
I have no motivation to read large wodges of introductory text, unless
the author's prose style is really gripping.
A good solution is to give the minimum of information in the opening
text, but integrate the rest of the text into the game - for example, in
the text of a letter being carried by the player, or it could be related
to the player by an NPC. Often it's useful to have a prologue where the
object is to find out what the object of the main part of the game will
be.
--
Gareth Rees
Jamieson Norrish
<ap...@andrew.cmu.edu> writes:
I'm not sure whether this will help, but I've always wanted to see
a standardized "recall" or "remember" command. "recall X" just
displays what your character knows about X from the past.
[Example deleted.]
As usual, it should not be overused. I rather dislike games where
it is necessary to obsessively examine every object to find
details. I would hate for it to become necessary to example *and*
recall every word you see in the game.
The problem with this, as I see it, is that the player needs to know
when "recall" will work. If you don't want to have the player use
"recall" all the time, regardless of how often the author has
implemented it, then there should be some marker for the player to
recognise. I guess that's easily solved by a "This seems vaguely
familiar" type of message, but I know that would really bug me after a
few uses.
I think, in some ways, I would prefer a booklet or some such if there
was an abundance of "memorised" information. Or better yet, have a
hypertext interface - then "recall" becomes the click of a button (or
whatever).
Jamie
Andrew C. Plotkin
what I does Jamieson Norrish@akeake. (1779)
> Well, you could do this by using a command very similar to "recall" -
> a command which acts like examine, but returns the physical
> information the character might have which is relevant to the item.
> So, you could "examine dagger" to get its physical description, and
> then type "recall dagger" to get all the information the character
> knows about the item.
> [...] I don't know whether this would work very well though,
> unless you did it as I suggested above, and combined both sections of
> information for the first examination of the object, and then split
> them subsequently. How does that sound?
Plausible.
Especially if the second (shorter) "examine" command added a comment
"[To recall what you know about the knife, type 'recall knife'.]" The
experienced player could switch to an expert mode that skipped the
prompt. There is a lot of room for this sort of thing, actually. The
"can't find the right command" complaints could be reduced by strategic
command prompting in novice mode.
Jamieson Norrish
<ap...@andrew.cmu.edu> writes:
Introductory and background information, as I've seen it done,
appears in three ways:
[First two deleted.]
- Sudden recall triggered by objects you examine. "EXAMINE KNIFE:
This is the silver knife of Woopidoodle, which was used by the
great god to..." (Kind of contrived, and it gets annoying to read
the history every time you examine the object. Or you could only
have the history appear once, but then the player can only read it
once, which is silly for background information.)
Well, how about combining this idea with the use of "recall". That
way, you get the information the first time you look at it, but that
information is not lost, but also isn't displayed on every examination
of the object.
So I'm trying to split up the last alternative into orthogonal
bits; what the object looks like and what you know about it.
Well, you could do this by using a command very similar to "recall" -
a command which acts like examine, but returns the physical
information the character might have which is relevant to the item.
So, you could "examine dagger" to get its physical description, and
then type "recall dagger" to get all the information the character
knows about the item.
I guess that this is really back where we started, isn't it? Only it's
slightly more general, and possibly less annoying, since the command
is attached to actual objects rather than to words inside another
description. I don't know whether this would work very well though,
unless you did it as I suggested above, and combined both sections of
information for the first examination of the object, and then split
them subsequently. How does that sound?
Jamie
Greg Ewing
In article <JAMIE.94O...@akeake.its.vuw.ac.nz>, ja...@akeake.its.vuw.ac.nz (Jamieson Norrish) writes:
|> what are people's views
|> on room names? Should they exist to the player?
It's not a "name" so much as a "very short description" which
I think is clearly necessary to avoid having to repeat the
whole description every time the room is entered.
It could be argued that it is not necessary to present both
descriptions the first time the room is entered, which perhaps
is what you meant.
|> Jamie
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+
Derek S Felton
: Well folks, greetings. As the subject of the message suggests, I'd like to
: start a new topic here. Namely, how do we tell the player what he's doing
: here (in the game, anyway... I'm not sure how much i-f can help out with what
: we're doing in a real life), and how do we make sure the player knows at least
: some of what the charater knows. Also, how do we establish what the player's
: goal is in the game? I see a couple choices, but I'm not real sure about any
: of them. Anyone have a better suggestion?
As always, IMHO:
I've always liked short blocks of text to open a game, then
to get slowly and subtly drawn into the story as I go.
Think of movies and books: except in stories that absolutely
*must* establish a lot of historical information--info that can't
be revealed in the normal course of the plot--the wordy prologue
gets irritating fast. Even in those special cases, be careful...
a cinematic example of this is the "long version" of DUNE, which be-
gins with a lengthy lesson on the politics, culture, and technol-
ogy of the Frank Herbert's universe. OK... maybe that information
was necessary, but cheesy drawings were used as the visual backdrops
for several minutes of narration. Those pictures cheapened the
entire movie for me.
My advice would be to look to books for revelation of politics/
culture/geography/etc. Good sci-fi/fantasy books (like DUNE) *don't*
rely on separate "history modes" and "story modes." These books
show that it's possible to introduce completely alien environments
by weaving history, etc. into conversation and descriptions.
Abilities that the user possesses are different... they shouldn't
wait. Say the player's character can use magic. You can simply list
on command all the spells he/she can cast, OR you can work such info
into the story.
Hasty, silly, badly-written example:
----------------------------------------------------------------------
Mage guild, training chamber
----------------------------
You watch as your fellow student Torgo casts his attempt at a
fireball. His halting voice imperfectly forms the power word
"Menthos." Only smoke and sparks result, nonetheless burning
the hapless Torgo's hand. You are smug in the knowledge that
you can do better.
Torgo's bizarre, heavy-kneed gait is comical as he steps out
of the casting glyph.
----------------------------------------------------------------------
(Apologies to non-MST3K watchers... :-) )
Anyway, that's the idea: work everything possible into the story,
but remember that no one method is best for every situation or story.
--- Derek Felton
de...@esu.edu
The Essential Addition
Jamieson Norrish <ja...@akeake.its.vuw.ac.nz> wrote:
>Perhaps if there was the capacity for players to rename locations with
>their own name, the "problem" would be solved, since I do agree that
>having a short form might be good. I just object to names which are
>blatantly interpretive, rather than based on the physical description
>only - that's fine for the players to do for themselves, but not for
>the author to do for them.
Sometimes I can't believe the nitpicking complaints which appear on this
newsgroup. Are you actually complaining because the author has the GALL
to name the rooms he creates?
What, for example, would you call a room with a long oak table,
candlesticks, and a number of chairs encircling it? I would call it a
dining room. A room with a lot of test tubes lying around? That's a
lab. The number of rooms which are so unique that they can not be
immediately identified is so incredibly small that I can't see a reason to
complain about it.
Any person of reasonable intelligence who was ACTUALLY wandering around
in a house would know what each room would be "named." A forest is a
forest, a field is a field, a hallway is a hallway. Give me a few actual
examples where the short names provided for locations in a game
PERSISTENTLY interfere with game play or proves to be too exceptionally
interpretive.
But naming them yourself? Come on. You're nitpicking about trivialities.
The "Long Table with Candlesticks Room" is still a Dining Room, any way
you look at it. If you've got better names, then I'd suggest you pick up
your text editor and write one yourself.
--
/ I said you wouldn't understand -- The Essential Addition \
| You kill what you fear |
\ rbr...@netcom.com -- And you fear what you don't understand /
Jamieson Norrish
<ap...@andrew.cmu.edu> writes:
Excerpts from netnews.rec.arts.int-fiction: 27-Oct-94 Re: Why I
does what I does Jamieson Norrish@akeake. (1779)
> Well, you could do this by using a command very similar to
> "recall" - a command which acts like examine, but returns the
> physical information the character might have which is relevant
^^^^^^^^
This of course should read "non-physical". Oops.
Especially if the second (shorter) "examine" command added a
comment "[To recall what you know about the knife, type 'recall
knife'.]" The experienced player could switch to an expert mode
that skipped the prompt. There is a lot of room for this sort of
thing, actually. The "can't find the right command" complaints
could be reduced by strategic command prompting in novice mode.
True; in fact, this sort of ability to customise the interface is
something which I think should be applied more generally to IF games.
While it means a lot of extra, non-game related coding, it should be
possible for "standard" sets of interfaces to be coded just once, and
then used much as TADS or Inform are used as programming languages.
So for example, things like status lines could be customised to be
what the individual player wished.
Which indirectly leads me to something else - what are people's views
on room names? Should they exist to the player? When entering a room,
should it say, for example:
The Wardrobe
This room is a bare wardrobe. There is a bar across its width, with
several coat-hangers on it, but no clothes. The only other interesting
feature is the lack of a handle on the inside - possibly somewhat
dangerous, given that you could easily fit in the wardrobe with the
door closed.
Or leave it just as the description? I personally prefer it without -
after all, there are no signposts around.
Jamie
Jamieson Norrish
gr...@cosc.canterbury.ac.nz (Greg Ewing) writes:
It's not a "name" so much as a "very short description" which
I think is clearly necessary to avoid having to repeat the
whole description every time the room is entered.
Well, I guess that's a charitable view of it - lots of room names seem
to me to bear little or no resemblence to any physical characteristics
of the room at all. Also, it might just be my background, but I don't
have any problem whatsoever with getting the whole room description
each time I enter the room. I don't often read it each time, but it
doesn't bother me at all. Whereas just having a name makes it seem so
functional and bare.
Perhaps if there was the capacity for players to rename locations with
their own name, the "problem" would be solved, since I do agree that
having a short form might be good. I just object to names which are
blatantly interpretive, rather than based on the physical description
only - that's fine for the players to do for themselves, but not for
the author to do for them.
Also, as you say, removing the name from the long description would be
much less irritating to me.
Jamie
Will Chose
> Well, you could do this by using a command very similar to "recall" -
> a command which acts like examine, but returns the physical
> information the character might have which is relevant to the item.
> So, you could "examine dagger" to get its physical description, and
> then type "recall dagger" to get all the information the character
> knows about the item.
>
out by Mastertronic a few years back, but it is a really excellent game,
and I always thought that they came up with a rather good solution similar
to the one described above.
In the game, you could type "THINK ABOUT x", and it would often give you
background information. One of the neater ones was your dog, Sam, who
follows you around during the game. If, for example, you typed, "EXAMINE
SAM" it said something like "Sam is your lovable dog, black with a white
crest on his chest, and ears three times too big for his head." But if
you typed "THINK ABOUT SAM", it related some of your memories of getting
Sam as a puppy, watching him grow up, and attempts at training him. This
last informs you that you managed to train Sam to "FETCH", "COME HERE (if
he's in another location)", etc. What does everyone think about this
method? I found it rather intriguing myself :)
--
***********************----------------------------------------------
*Will Chose * Things you'll never hear said on Star Trek
*wch...@opie.bgsu.edu * ------------------------------------------
*********************** Spock: "As always, your logic is impeccable,
Captain."
McCoy: "He's alive, Jim!"
Andrew C. Plotkin
what I does Greg Ew...@cosc.canterbu (797)
> It's not a "name" so much as a "very short description" which
> I think is clearly necessary to avoid having to repeat the
> whole description every time the room is entered.
> It could be argued that it is not necessary to present both
> descriptions the first time the room is entered, which perhaps
> is what you meant.
But then you have the danger that the player might not know what name
the author is going to use. "What is this, I just walked into 'The Green
Room'? Huh? Oh, I see, I thought it was the 'glowing' room." If you
present both the first time, the player won't be confused. (And he has a
right to not be confused -- his *character* certainly won't make this
mistake. Unless two rooms are identical, in which case the room names
will be the same.)
If you want to get theoretical, the room name is not a signpost, it's
the on-screen representation of the character's familiarity with the
room. (The memory which allows him to recognize it the next time he
walks in.) So it *should* be presented the first time he sees it.
It would be more realistic if the player had to enter the name himself.
Rooms originally have no room name; when the player types "call this
room the glowing room" the name is recorded; thereafter it appears in
the title bar and so forth. However, this would get very tiresome very
quickly, I'm sure.
Damien P. Neil
Will Chose <wch...@opie.bgsu.edu> wrote:
>In the game, you could type "THINK ABOUT x", and it would often give you
>background information.
Just another data point: In Mindshadow, a game by EA(?) that I played on
the C64, you started the game as an amnesiac. As the game progressed, you
could type `REMEMBER foo' to bring up memories about things you find. To
finish the game, you had to remember enough to be able to recall your
past.
- Damien
Mike Threepoint
=> Mage guild, training chamber
=> ----------------------------
=> You watch as your fellow student Torgo casts his attempt at a
=> fireball. His halting voice imperfectly forms the power word
=> "Menthos." Only smoke and sparks result, nonetheless burning
=> the hapless Torgo's hand. You are smug in the knowledge that
=> you can do better.
=> Torgo's bizarre, heavy-kneed gait is comical as he steps out
=> of the casting glyph.
A scene from "Menthos: The Hands of Flame", no doubt? :-)
Scene: Torgo and his vivacious young friends are walking across a busy
street, but Torgo is shuffling along so slowly, he lags behind.
Suddenly, an expensive car zips up right in front of Torgo, cutting
him off. The driver, a handsome executive with perfectly coiffured
hair, continues talking on his car phone without interest or remorse.
Angered, Torgo pulls out a roll of Menthos, pops one in his mouth,
then stammers out the name. Kaboom! The car bursts into flame, the
executive writhing in agony as blazing polyester sears his elite flesh.
Torgo's friends gape and stare as Torgo waddles around the vehicle.
Finally, he looks up, flashes a grin, and holds up the roll of Menthos
in his fist. Everybody laughs.
Freeze frame with the slogan-- "Menthos: The Flame-maker!"