Why newcomers struggle with IF.
Risujin
these comments are from my recent first-hand experience. :)
Also, these complaints are generally aimed at Inform as I've only played
one TADS game which IIRC is marginally less anal than Inform.
1. Rooms, rooms, rooms, and more rooms.
The first IF game I tried playing was Zork. The first thing I noticed
about Zork was how large it was. The irony here being that I never
solved a single puzzle in the game. Every room I encountered made little
or no impression on me and thus I was wandering around in confusion
almost right off the bat. Not being a particularly enjoyable experience,
I quit the game not long afterwards.
Just because your forest is large doesn't mean you need 300 identical
rooms to describe it. Make one and write "You are in a large forest."
Learning to navigate via cardinal directions (NSEW) around a maze of
mostly meaningless rooms is an acquired skill. If you play enough IF or
MUDs you will one day get the hang of it. However, for new players this
is one the largest turn-offs for IF.
This kind of navigation system is understandably useful in mazes and if
you're in general trying to confuse the player, but is it really
necessary everywhere?
When we walk around our own home we dont think in cardinal directions.
We dont think "I'll go west to the hallway now," just "I'll go to the
hallway." Nobody walks around with a compass ingrained in their head.
Moreover, another interesting argument is that spatial consistency is
not a requirement for IF. I think authors wish their games to make sense
when laid out on a two-dimensional map, but if a player needs to do this
in the first place, then the system is a design mistake. People can make
logical connections without an exact spatial order. A person can know
that from the hallway one can go to the bathroom, kitchen,
first/second/master bedrooms without knowing their exact cardinal
directions or exactly which room is where. Usually their placement is
not important, and if it is, you could easily add it to the description
as a subtle hint.
The second IF game I ever played, and the first I finished is one I
absolutely adore. Andrew Plotkin's Shade is a perfect example of
friendly IF. The game has three rooms, yet their navigation is
irrelevant. You can move by entering "go to bathroom" or "go to kitchen"
but you don't even have to! You can simply mention an object from either
nook and the game will take you there without hassle.
Lastly, another convenient thing that could be done here, is to be able
to enter >GO TO BATHROOM when two or three rooms away and be walked
there automatically. When you dispose of cardinal directions, this kind
of automatic navigation becomes very logical.
2. Are we playing or programming?
>PUT DINOSAUR IN DUMPSTER
You need to be holding the dinosaur before you can put it in something else!
... or you could just pick it up for me?
The parser *knows* that you need to take the object first, but decides
to simply tell you so instead of obliging you and saving some extra
typing. Even if you couldn't pick up the object, the game could still
attempt it and display the results.
To the great frustration of IF newcomers, IF time flows in discrete
turns which, with few exceptions, must be taken one by one. There is no
advantage to this. As far as I know, this is because Inform cannot take
more than one turn per prompt (unless hacked by the author to do so).
3. Saving should not be a skill.
4. If I want a maze I'll ask for one.
Mercifully, the heyday of the die-happy and map-the-maze IF is long
over. However, these games are still around to remind us of just how
easy it is to get the player to leave.
Well that's all for now. I'd be interested in seeing what everyone has
to say, and also examples of good/bad games.
John W. Kennedy
> When we walk around our own home we dont think in cardinal directions.
> We dont think "I'll go west to the hallway now," just "I'll go to the
> hallway." Nobody walks around with a compass ingrained in their head.
Yes and no. Most people navigate by a temporary local compass, (e.g.,
"front of house", "back of house"), which is almost impossible to handle
textually without both verbosity and confusion. Note, however, the
traditional use (dating back to "Starcross") of "f", "aft", "p", "sb"
aboard vessels.
--
John W. Kennedy
If Bill Gates believes in "intelligent design", why can't he apply it to
Windows?
Kevin Forchione
news:iTIPe.56360$3S5....@tornado.rdc-kc.rr.com...
> Well that's all for now. I'd be interested in seeing what everyone has to
> say, and also examples of good/bad games.
The rules for interfacing with any game, especially computer games, are
typically a big turn-off for new players. Whether you need to type NSEW or
some combination of keys on the keyboard (even arrow keys), learning to
navigate, investigate, and manipulate the world of the game is usually
fairly time-consuming. Nothing about computer gaming is "intuitively
obvious", but merely a matter of convention and experience.
But the comparison of the text-based versus graphics-based gaming experience
is somewhat analogous to that of chess versus checkers. In a text-based
game, more is demanded of the player, and there is a steeper learning curve.
They're not everyone's cup-of-tea. On the other hand, most players of
text-based games find the experience rewarding and satisfying in ways that
graphics-based games are not.
Most graphics games attempt to ameliorate this pain by providing a sandbox
or a tutorial period (hopefully integrated into the game's storyline, but
sometimes not). I suspect that an equivalent for IF would be viewed as
juvenile, although it might be interesting to develop a generic IF sandbox
for new players - something that could be plugged into any game. It might
also be possible using the parser to detect and evaluate the blunders of the
new player, and provide them with an opportunity to go to the sandbox for
training.
--Kevin
J. Robinson Wheeler
Risujin wrote:
> To the great frustration of IF newcomers, IF time flows in discrete
> turns which, with few exceptions, must be taken one by one.
Yes...
> There is no advantage to this. As far as I know, this is because Inform
> cannot take more than one turn per prompt (unless hacked by the
> author to do so).
Huh? What are you objecting to? What are you complaining that it
doesn't do instead?
--
J. Robinson Wheeler Games: http://raddial.com/if/
JRW Digital Media Movie: http://thekroneexperiment.com/
Ross Presser
> When we walk around our own home we dont think in cardinal directions.
> We dont think "I'll go west to the hallway now," just "I'll go to the
> hallway." Nobody walks around with a compass ingrained in their head.
In our own homes, perhaps not. However when you are outdoors, or especially
driving, you may very well constantly have a general idea of which
direction you are going.
Risujin
> Huh? What are you objecting to? What are you complaining that it
> doesn't do instead?
The complaint is that if the parser is smart enough to know that an item
must be picked up before it can be manipulated, it shouldn't tell me it
should just do it and save me some typing. :)
This is just part of a larger design paradigm:
A. Force the player to do each action individually (Inform).
-- or --
B. Infer what sequence of actions the player intended and perform these
automatically.
I think TADS actually follows more of the second way. IIRC in Glowgrass,
you could say "go to x" and if you were several rooms away from x, you
would go through them automatically. I'm not certain if this is a
feature of the TADS language or if the author coded this explicitly.
Kevin Forchione
> J. Robinson Wheeler wrote:
>> Huh? What are you objecting to? What are you complaining that it
>> doesn't do instead?
>
> The complaint is that if the parser is smart enough to know that an item
> must be picked up before it can be manipulated, it shouldn't tell me it
> should just do it and save me some typing. :)
>
> This is just part of a larger design paradigm:
> A. Force the player to do each action individually (Inform).
> -- or --
> B. Infer what sequence of actions the player intended and perform these
> automatically.
>
> I think TADS actually follows more of the second way.
Both TADS and Inform can process "implicit" actions or not, as the author
pleases. There *are* times when implicit actions are not desirable. This is
not a flaw of the parser, but is a matter of the discretion or indiscretion
of the author.
>IIRC in Glowgrass, you could say "go to x" and if you were several rooms
>away from x, you would go through them automatically. I'm not certain if
>this is a feature of the TADS language or if the author coded this
>explicitly.
This is not a feature of the TADS language, or the basic library. These
kinds of effects are achieved by library extension, either publicly
available or privately implemented.
--Kevin
lumi...@hotmail.com
> to enter >GO TO BATHROOM when two or three rooms away and be walked
> there automatically. When you dispose of cardinal directions, this kind
> of automatic navigation becomes very logical.
That might be perfectly acceptable when you're only dealing with a few
rooms, but in even an average sized games I think I'd quickly get tired
of typing >GO TO anywhere. Even if it was just the room name, >KITCHEN
or whatever, the single keystroke required for compass directions is so
much faster. I know I can't speak for everyone, but for me at least
it's become intuitive. I don't even have to think about typing >N when
I navigate, I just hit it automatically the same way you might hit an
arrow key in another game.
xex...@gmail.com
IF - the first one, based, I suspect, on early Dungeons and Dragons
type games, is as you describe - move from room to room, battle
monster, gain gold, win game. As the Zork series defined IF, this way
of implementing and playing games (N, S, E, W, U, D x object, mazes,
puzzles) has stuck, even though IF authors don't play Dungeons and
Dragons any more (well, they might, but that's not what a modern
reader/player would expect from a story/game if they came to it without
any knowledge of the history).
The second type of IF focuses more on actual fiction, and the player's
experience of the story that develops. IF is a naturally interesting
form of narrative, not least because of the games you can play with the
narrator and perspective. I've also enjoyed Andrew Plotkin's games,
but my favourite IF author is undoubtedly Adam Cadre
(http://adamcadre.ac/) - Photopia actually moved me, probably because
my wife and I had just had a child when I played it. I think you'll
like it (if you haven't tried it already) - try typing '>east' when
you're in a house - this addresses the problem you raise above.
It strikes me that part of the enjoyment of IF may come from this
tension between the two types of games (and the confusing nomenclature
- is it a 'game' or 'story', are we 'reading' or 'playing', or all
these things?) Inform must be flexible if 'Shade', 'Photopia' or
'Varicella' are even possible.
Poster
>
>
>>To the great frustration of IF newcomers, IF time flows in discrete
>>turns which, with few exceptions, must be taken one by one.
>
>
> Yes...
>
>
>>There is no advantage to this. As far as I know, this is because Inform
>>cannot take more than one turn per prompt (unless hacked by the
>>author to do so).
>
I come from an RPG background (specifically D&D), and the turn-based
system makes plenty of sense to me. Sure, it's an abstraction (as any
game is an abstraction), but I find it much preferable to games like
Icewind Dale, where you have to fight in real time. Geez. You blow your
nose and your character is dead! Mess that! :S
-- Poster
www.intaligo.com/ -^-^-^- Inform libraries and extensions!
www.intaligo.com/building/ *- B U I L D I N G -* Dark IF.
Risujin
> The second type of IF focuses more on actual fiction, and the player's
> experience of the story that develops. IF is a naturally interesting
> form of narrative, not least because of the games you can play with the
> narrator and perspective. I've also enjoyed Andrew Plotkin's games,
> but my favourite IF author is undoubtedly Adam Cadre
> (http://adamcadre.ac/) - Photopia actually moved me, probably because
> my wife and I had just had a child when I played it. I think you'll
> like it (if you haven't tried it already) - try typing '>east' when
> you're in a house - this addresses the problem you raise above.
I have played it and I faintly remember what you're referring to. You
have to actually tell it to leave the house IIRC. Another interesting
thing about it is during the Mars scene, whichever cardinal directions
you choose to take you will traverse the scene areas in exactly the same
order. The game "creates" the arrangement of areas as you go along
rather than fixing it beforehand.
> It strikes me that part of the enjoyment of IF may come from this
> tension between the two types of games (and the confusing nomenclature
> - is it a 'game' or 'story', are we 'reading' or 'playing', or all
> these things?) Inform must be flexible if 'Shade', 'Photopia' or
> 'Varicella' are even possible.
Yes, there is no doubt that Inform is flexible. What worries me most,
however, is that Inform was not designed for the second type of IF you
mention. Saying Inform is flexible enough for any IF is almost like
saying C is flexible enough for any IF. Both are technically true, but
if the author must reinvent the wheel with every game or rely on engine
hacks to make features work, the usefulness of the language for creating
such work is greatly diminished and will likely scare away many authors.
Code languages might not limit what is technically *possible* to create
with them, but each language has a natural use for which conveniences
are provided. Defying a language's natural use takes time and effort
which many authors are either unwilling or unable to spend.
Like you say, Inform was created for the D&D crowd and works most
naturally when used for their needs. TADS, it seems, largely follows in
Inform's footsteps. Perhaps a new language or a add-on library focused
on narrative fiction is needed?
--
Risujin
David Whyld
>
> I come from an RPG background (specifically D&D), and the turn-based
> system makes plenty of sense to me. Sure, it's an abstraction (as any
> game is an abstraction), but I find it much preferable to games like
> Icewind Dale, where you have to fight in real time. Geez. You blow your
> nose and your character is dead! Mess that! :S
>
> -- Poster
>
Kind of off topic, but you *do* realise you can always pause the game,
blow your game, and then continue? So a sneeze doesn't necessarily mean
instant death.
Andrew Plotkin
> "Risujin" <ris...@fastmail.fm> wrote in message
> news:PsLPe.56662$3S5....@tornado.rdc-kc.rr.com...
> >
> > A. Force the player to do each action individually (Inform).
> > -- or --
> > B. Infer what sequence of actions the player intended and perform these
> > automatically.
> >
> > I think TADS actually follows more of the second way.
>
> Both TADS and Inform can process "implicit" actions or not, as the author
> pleases. There *are* times when implicit actions are not desirable. This is
> not a flaw of the parser, but is a matter of the discretion or indiscretion
> of the author.
Inform has some implicit actions built in, and it's not too hard to
add more. It would be nice if it were easier, but most Inform games
use implicit actions where they're needed the most. So I think the
facility is generally good enough.
However, there is a *particular* case where Inform (and nearly all
Inform games) fall down: "put X in Y" where you are not holding X.
Because of the way the parser is structured, there is no implicit
"take" there. Adding it would cause more problems than it solves. This
is unfortunate, but it doesn't represent an overall design philosophy.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
David Whyld
David Whyld wrote:
> Kind of off topic, but you *do* realise you can always pause the game,
> blow your game, and then continue? So a sneeze doesn't necessarily mean
> instant death.
That of course should have read "blow your *nose*".
I think I need someone to betatest my posts. :(
Kevin Venzke
> Like you say, Inform was created for the D&D crowd and works most naturally
> when used for their needs. TADS, it seems, largely follows in Inform's
> footsteps. Perhaps a new language or a add-on library focused on narrative
> fiction is needed?
If you can specify what exactly you want, then it should be very easy to
write an add-on library.
For example, if you want to do without cardinal directions and just use
"go to kitchen," all you would have to do is not use cardinal directions,
and perhaps define a class that represents nothing but an exit to an
adjacent room.
If you want "go to kitchen" to work even when you're in your car,
parked in the driveway, it would be harder. I know that path-finding
code has already been written, though.
Kevin Venzke
Kevin Forchione
news:deqbkc$n65$1...@reader2.panix.com...
> However, there is a *particular* case where Inform (and nearly all
> Inform games) fall down: "put X in Y" where you are not holding X.
> Because of the way the parser is structured, there is no implicit
> "take" there. Adding it would cause more problems than it solves. This
> is unfortunate, but it doesn't represent an overall design philosophy.
Hopefully this is something Inform 7 addresses.
--Kevin
Risujin
> Inform has some implicit actions built in, and it's not too hard to
> add more. It would be nice if it were easier, but most Inform games
> use implicit actions where they're needed the most. So I think the
> facility is generally good enough.
I still end up tripping over them all the time, it seems like such a
silly thing for the parser to do. Like I'm going to change my mind about
what I want to do just because I forgot some intermediate step...
> However, there is a *particular* case where Inform (and nearly all
> Inform games) fall down: "put X in Y" where you are not holding X.
> Because of the way the parser is structured, there is no implicit
> "take" there. Adding it would cause more problems than it solves. This
> is unfortunate, but it doesn't represent an overall design philosophy.
As a player I'm pretty familiar with the results Inform serves up but
naively innocent to Inform's innards. I'm curious why that would cause
problems. If take fails, print an appropriate error message and don't go
through with moving the object (I wouldn't even use up a player turn).
Why does this cause problems?
P.S.
I'm a big fan of your work! :3
--
Risujin
ris...@fastmail.fm
d...@ingeni.us
> Learning to navigate via cardinal directions (NSEW) around a maze of
> mostly meaningless rooms is an acquired skill. If you play enough IF or
> MUDs you will one day get the hang of it. However, for new players this
> is one the largest turn-offs for IF.
On the other hand, integrating the cardinal directions into the fabric of
the game makes it possible to map the game while playing with relative
ease. You don't have to wonder whether the building you just entered is on
the north or the south side of the road; whether the living room is at the
north (front) or south (back) side of the house, etc.
Also, it's considerably easier to type 'n' and 's' than 'hallway' or
'kitchen' from a number-of-keystrokes point of view.
All of the above said, it's absolutely possible to design games the way you
suggest, or at least similarly; it's just more work for the author.
-dan
Risujin
> On the other hand, integrating the cardinal directions into the fabric of
> the game makes it possible to map the game while playing with relative
> ease. You don't have to wonder whether the building you just entered is on
> the north or the south side of the road; whether the living room is at the
> north (front) or south (back) side of the house, etc.
Cardinal directions are a tradition within IF, but their roots lie in
mazes and thats really the only place they are strictly necessary.
I couldn't tell you which side the north side of my own house is,
moreover it doesn't always matter. All you need to know is where can you
get to from where and as long as it's logical there should be no
problems. Of course, it's one thing to sit here and talk about it and
another to actually see a working example.
As for mapping cardinal directions offer no assistance. I once played a
MUD (obviously with cardinal directions) where the *distances* you would
travel in any direction varied, so mapping was impossible (without a
large eraser). It was incredibly frustrating.
A node tree will map any game with or without cardinal directions. In
all honesty, though, IF should not have to be mapped. If one is needed,
provide one, don't waste players' time! :-\
I don't complain against cardinal directions alone, I'm also against the
situations which necessitate them: mazes and large numbers of indistinct
rooms. If you had 300 rooms you'd confuse your novice players regardless
of how you had them get around.
> Also, it's considerably easier to type 'n' and 's' than 'hallway' or
> 'kitchen' from a number-of-keystrokes point of view.
Can't really argue with that one. :)
> All of the above said, it's absolutely possible to design games the
way you
> suggest, or at least similarly; it's just more work for the author.
It shouldn't have to be... :-\
--
Risujin
ris...@fastmail.fm
Andrew Plotkin
> Andrew Plotkin wrote:
>
> > However, there is a *particular* case where Inform (and nearly all
> > Inform games) fall down: "put X in Y" where you are not holding X.
> > Because of the way the parser is structured, there is no implicit
> > "take" there. Adding it would cause more problems than it solves. This
> > is unfortunate, but it doesn't represent an overall design philosophy.
>
> As a player I'm pretty familiar with the results Inform serves up but
> naively innocent to Inform's innards. I'm curious why that would cause
> problems. If take fails, print an appropriate error message and don't go
> through with moving the object (I wouldn't even use up a player turn).
> Why does this cause problems?
That part doesn't. The problem is at parse time.
Sorry to drop into Inform technicalities, but: The grammar line (for
this case) is
'put'
* multiexcept 'in'/'inside'/'into' noun -> Insert
* multiexcept 'on'/'onto' noun -> PutOn
The "multiexcept" token is customized for locating a collection of
objects which can be moved somewhere. The rules it uses work well for
most cases involving moving a bunch of objects from your inventory.
They stop working well when the problem space encompasses the whole
room.
I'm afraid I don't remember the situation in more detail -- it's been
too long since I first tried to fix this (and gave up). Basically, a
verb which accepts multiple objects is hard to get right, and a verb
which handles implicit take is hard to get right. The Inform library
has built-in hacks to do both, but not at the same time.
There's always the Platypus library.
Kevin Forchione
> naturally when used for their needs. TADS, it seems, largely follows in
> Inform's footsteps. Perhaps a new language or a add-on library focused on
> narrative fiction is needed?
I would suggest that TADS came before Inform and that Inform was created to
facilitate the development of Infocom-caliber interactive fiction -- by that
I mean parser, command execution, and world model sophistication.
Surprisingly little D&D or RPG games have been written using Inform.
I would also suggest that there is some confusion in this discussion between
"language" and "library". Both TADS and Inform, as well as Hugo Alan are
excellent languages for developing Interactive Fiction. Their libraries
implement varying degrees of parser and world model sophistication and
extensibility.
But such features as alternate means of game navigation, etc., are hardly
reasons for new language development, unless you're suggesting new
mechanisms for string handling or new datastructures. And they're probably
not adequate reasons for library replacements.... since much of the parser
and world model would remain untouched by these "cutting-edge" features.
--Kevin
Rikard Peterson
"Risujin" wrote in news:DT5Qe.16525$mb4....@tornado.rdc-kc.rr.com:
> I couldn't tell you which side the north side of my own house is,
> moreover it doesn't always matter.
As you say, which side of your house is to the north is not important.
What is important is that you know that south is the opposite direction
to north, and that if you're facing north you have east to your right
and west to your left. It's a set of eight directions which are both
universally familiar and easily abbreviated (using common
abbreviations).
It doesn't matter if what I call north is the actual north, the
magnetic north, north by north-west or even south! As long as I'm
consistent, I have a good and simple way of describing directions. It's
not simply tradition. It's a navigational system that works. You
usually have to move somehow, and I never found it strange.
In addition, I like the sense of exploration you can get from some
games which is made stronger by this kind of navigation. (But I'm
absolutely not defending that 300 indistinct rooms situation you
describe. That's a different problem, but not one I've met yet. I still
consider myself mostly a newbie when it comes to IF, so I've only heard
about those beasts and never actually seen them.)
Rikard
Kevin Forchione
> d...@ingeni.us wrote:
>> On the other hand, integrating the cardinal directions into the fabric of
>> the game makes it possible to map the game while playing with relative
>> ease. You don't have to wonder whether the building you just entered is
>> on
>> the north or the south side of the road; whether the living room is at
>> the
>> north (front) or south (back) side of the house, etc.
>
> Cardinal directions are a tradition within IF, but their roots lie in
> mazes and thats really the only place they are strictly necessary.
No.... their roots lie in navigating in the real world in any area that is
unfamiliar territory to the traveler.
> I couldn't tell you which side the north side of my own house is, moreover
> it doesn't always matter. All you need to know is where can you get to
> from where and as long as it's logical there should be no problems.
You're facing three problems when you eliminate cardinal directions.
The first is that *some* equivalent nomenclature will have to describe
movement in unknown territory. Unless we're to assume that (1) novices are
never to play games in which unknown territory needs to be explored; and (2)
game systems should be developed to cater strictly to novices.
The second is that this nomenclature will have to be able to describe 8
possible directional movements within a location (as well as up, down, in,
and out) unless we are to limit our movements to 4 ("front", "left",
"right", "back" or equivalent). In the real world we don't move about our
houses as though we are giving commands to a player character either. In an
unknown residence I wouldn't say to myself, "move to the door to the left
ahead of me", which is about as clear as we could get if we were exploring
the room through a third-party, say, via walkie-talkie. Once you've
developed a nomenclature for such movement you'd simply have a functional
equivalent of the cardinal directions, or a subset of them.
The third is that while you may not navigate your own home via cardinal
directions, the architects and builders who constructed it made use of them.
And game designers using a relativistic system for player travel would also
need to use a non-relativistic system for coding the game world itself
(perhaps this assertion can be shown to be false?) Game authors would need
to translate between 2 systems of navigation rather than one, which can't
possibly make their coding tasks easier.
> Of course, it's one thing to sit here and talk about it and another to
> actually see a working example.
Of course. Interactive Fiction game systems weren't designed by old fogies
merely imitating what their predecessors had done. They were/are developed
by intelligent individuals who enjoy playing and writing interactive fiction
games and wanted their systems to be used by the broadest possible user base
of the community.
The "big three" systems do not cater to the needs of novices alone, nor to
the tastes of any particular "avante garde" or gaming style believed by some
to be the future of IF. Rather they attempt to provide basic support for an
author to develop whatever game s/he wants while adhering to the conventions
of the community. An author who wishes to abandon mazes is free to do so; an
author who wishes to abandon cardinal directions is free to do so; and so
too, an author who wishes to tweak elements of the parser will find it
doable.
If novices find such games as those of the Infocom classics daunting, well,
they should. Those games were meant to be daunting. Perhaps what is really
lacking is more guidance toward which games are considered novice-friendly,
and which ones are considered for experienced players.
--Kevin
Victor Gijsbers
> Like you say, Inform was created for the D&D crowd and works most
> naturally when used for their needs. TADS, it seems, largely follows in
> Inform's footsteps. Perhaps a new language or a add-on library focused
> on narrative fiction is needed?
The links between Interactive Fiction and RPGs are, I think, very
interesting and a topic for discussion that has hardly been touched
upon. But I do not think that there is a close correspondence between
D&D and Inform, or at least that if there is, this correspondence has
not been identified in this thread.
Most of the precious posts seem to have gone on about using cradinal
directions to navigate, instead of using the names of places; this has
nothing to do with D&D or any other roleplaying game I know of. A player
in D&D is vastly more likely to state "I enter the cathedral." that he
would be to state "I go north."
Other important features of D&D (emphasis on combat and combat
effectiveness; experience, and increased effectiveness as a reward for
guts and smartness; specific character roles; party-based adventuring)
are not reflected in Inform at all. As someone already said, Inform is
based on the old Infocoms games much, much more than it has been based
on D&D. (Or any other roleplaying game, for that matter.)
Victor
PS. I'd say that an important link between Inform and its companions on
the one hand, and D&D and the vast majority of RPGs on the other, is
that both have focussed on modelling small spatiotemporal actions,
instead of social actions or dramatic conflicts. You can always say "put
the bottle on the table", but almost never "beg her to marry me" and
certainly not "choose duty over love". But is quite tangential to the
issue under discussion here.
L. Ross Raszewski
>d...@ingeni.us wrote:
>> On the other hand, integrating the cardinal directions into the fabric of
>> the game makes it possible to map the game while playing with relative
>> ease. You don't have to wonder whether the building you just entered is on
>> the north or the south side of the road; whether the living room is at the
>> north (front) or south (back) side of the house, etc.
>
>Cardinal directions are a tradition within IF, but their roots lie in
>mazes and thats really the only place they are strictly necessary.
>
>I couldn't tell you which side the north side of my own house is,
>moreover it doesn't always matter. All you need to know is where can you
>get to from where and as long as it's logical there should be no
>problems. Of course, it's one thing to sit here and talk about it and
>another to actually see a working example.
>
"Yes, but..."
The thing is that we really *do* navigate most places by cardinal
direction. Maybe you couldn't tell which side of your house is
"north", but in navigating from one room to another, you don't
actually take into account which way you're facing, which way you
entered from, or anything like that.
The trouble is that we don't have a strong language for describing
this; I can't tell you which side of my house is north (actually, I
can, because I live in a city where the streets are approximately
arranged to cardinal directions), but I can tell you which side is
"that way". We call it "north" in IF not just because it's customary,
but also because we don't have a better name for it.
The north side of *my* house is the wall directly behind me from where
I am seated on my couch. But if I were implementing my house in a
game, I'd be strongly inclined to dub the direction toward the back of
my house (which is really east) "north", because when I imagine the
floor plan of my house, the street is at the bottom, and the alley is
at the top. And, the Society of Cartographers for Social Equality
notwithstanding, my inherent notion is that the top of a map is north
and the bottom is south.
It's actually a parallel case to the other classic IF command
"INVENTORY" -- inventory isn't a *verb* (Well, okay, maybe it is, but
as a verb, it doesn't mean what it means in IF), we say it because
there's no good single word for "take stock of my possessions".
The key thing is that, no, we're not really assuming that "north"
aligns to any compass sense of northness; we're just recognizing that
if you drew a map, it'd be at the top.
Ben Rudiak-Gould
> The first IF game I tried playing was Zork. The first thing I noticed
> about Zork was how large it was. The irony here being that I never
> solved a single puzzle in the game. Every room I encountered made little
> or no impression on me and thus I was wandering around in confusion
> almost right off the bat. Not being a particularly enjoyable experience,
> I quit the game not long afterwards.
I have the same problem; if the map gets big enough or complicated enough
(strange connectivity) that I can't keep track of it in my head, I generally
just stop playing. I never got very far in The Dreamhold for this reason. In
the case of Zork, which I first played quite recently, I found a map online
and used that.
An exception was Anchorhead, for which I actually drew a paper map (the
first time in years that I'd done so) because by the time I realized how big
the map was, the game had gotten too interesting to quit.
> When we walk around our own home we dont think in cardinal directions.
> We dont think "I'll go west to the hallway now," just "I'll go to the
> hallway." Nobody walks around with a compass ingrained in their head.
I do. If I'm in a familiar location I can always point out which way is
north. My real-life navigation is usually based on an internal map where
"north is up".
> Moreover, another interesting argument is that spatial consistency is
> not a requirement for IF. [...] A person can know
> that from the hallway one can go to the bathroom, kitchen,
> first/second/master bedrooms without knowing their exact cardinal
> directions or exactly which room is where. [...]
> Lastly, another convenient thing that could be done here, is to be able
> to enter >GO TO BATHROOM when two or three rooms away and be walked
> there automatically. When you dispose of cardinal directions, this kind
> of automatic navigation becomes very logical.
You should take a look at Narcolepsy, which does this universally. I thought
it worked very well; I never had trouble navigating, and the extra typing
didn't bother me. *But*, I never got a good sense of space in that game. My
memories of it are of a bunch of disconnected locations floating in a void.
This was probably deliberate (actually I'm sure it was deliberate -- Adam
Cadre is too clever by half with this sort of thing), but it's not an
impression that one wants to create in every game.
When I'm moving around in a game which uses cardinal directions, I'm not
thinking "N.E.S.E...", any more than when I'm touch typing I'm thinking
"left index finger above its home position". Whatever part of my unconscious
mind handles navigation in the real world seems to handle it in games also.
-- Ben
lumi...@hotmail.com
Actually, you can pause the game (click the glass globe in the bottom
left hand corner) at any time and issue commands to everyone in your
party, so battles can be played as turn-based if you want...really
that's the only way to win them. If you tried playing the whole game in
real time I imagine you didn't get very far; Icewind Dale is a tactical
game, it's not like Diablo or something where you just wade in and
start bashing monsters.
Poster
> David Whyld wrote:
>
>>Poster wrote:
>>
>>>I come from an RPG background (specifically D&D), and the turn-based
>>>system makes plenty of sense to me. Sure, it's an abstraction (as any
>>>game is an abstraction), but I find it much preferable to games like
>>>Icewind Dale, where you have to fight in real time. Geez. You blow your
>>>nose and your character is dead! Mess that! :S
>>>
>>>-- Poster
>>>
>>
>>
>>Kind of off topic, but you *do* realise you can always pause the game,
>>blow your game, and then continue? So a sneeze doesn't necessarily mean
>>instant death.
>
It's been a while since I've played, but the annoyances of a
non-turn-based system were too much for me. Sure, there are workarounds,
as others have stated. Ok, pause, do stuff, pause, do stuff, pause, do
stuff. And even that's not entirely true, because some things you can't
do while the game is paused. (Maybe that was altered after the original
Balder's Gate? I don't know, but I sure didn't stick around to find
out). So all I can say is that my experiences were frustrating and that
the game didn't appeal to me. I went and played something else and had
more fun.
All of which is to say that a turn-based system is not inherently
annoying to everyone who plays IF.
there...@yahoo.com
Same here, and the funny bit? Boy Scouts *didn't* have this effect. I
was just shy of Eagle Scout when I quit, so of course I must have
goofed off with compasses from time to time (enough to learn, they
mostly don't work.) But Scouts didn't make me care about compass
directions. ZORK made me care. Nowadays I'm generally quite aware
where I'm at on the compass, and that's because of the Infocom games.
~JD
there...@yahoo.com
>Mercifully, the heyday of the die-happy and map-the-maze IF is long over.
It is? Who said? When did we vote, 'cause no one told me? Yes, I
know most IF writers today would rather express their deepest, most
precious feelings than entertain a player . . . but I can't be the only
one who would enjoy a game that combined the ineffability of Zork with
the humor of Bureaucracy. Commercial games, as I recall. People like
me PAID to play games that required mapping, moving through
transitional rooms, and dying repeatedly. (Zork was the first IF I
played -- without a shred of documentation -- and though I never
finished without hints, true, I did become fascinated with the form,
quite unlike your generic "newcomer". And no, I was not a D&Der.)
>I couldn't tell you which side the north side of my own house is [snip]
I could. 'Salright if I go ahead and feel a bit superior? 'Cause I
do. I've found that, say, when someone give you directions over the
phone, you're much less likely to get lost if you make them stop and
think "Does he go east or west on I-30", rather than letting her say
"You go left", when she forgot to consider you'd be facing the other
way from her. The compass damn well does matter in my daily living,
and as I said elsewhere, IF helped me with this more than Boy Scouts
did.
>IF should not have to be mapped. If one is needed, provide one, don't waste players' time!
Good God, here I've got three pads of graph paper, and the Committee's
gone and voted to abolish mapping, too? How come I never got to vote?
I'm beta-testing a small game right now, and I drew a map. Twice.
I re-drew my SORCERER map three times, just to get it lookin' nice. I
was excited when STATIONFALL moved into the village, not included in
the game package's blueprints.
I LIKE MAPPING! I also like programming music without an instrument
controller, and kinkier things too, and I'll admit these things
probably have roots in my childhood issues. But still and all, it's
legal fun, so why shouldn't I have it?
I don't complain about the Cadre-type stuff -- I adored Shrapnel, where
the game just unfolds exactly as the writer wants it to, regardless of
the player's focus. How wonderfully satisfying for the author it must
be, and since most IF players today are probably authors too, I don't
see a problem. But some of us ENJOY challenges and frustrations,
puzzles that wake us up early on our days off, ideas scribbled down in
the middle of the night, games that CAN'T be finished in two hours,
IFcomp be damned. We're not trying to take away your "literature"
(indeed, some of us don't draw a clear line between lit and games), but
you seem to be saying . . . what the heck ARE ya sayin'?
>I don't complain against cardinal directions alone, I'm also against the situations which necessitate them [snip]
Ah. Okay. Now I've got it: WHINER. Are you opposed to algebra and
lettuce, too?
Nobody makes you play any particular game, so if you don't like the
world model, don't play it. Seems as if you'd like to *abolish* the
kind of game you don't like. If I've misread you, good, but you're
making a lot of grand statements, and asking few questions, about what
people like.
~JD
there...@yahoo.com
"Indistinct" is the key word there, by which I agree with you. But a
"useless" or transitional room that is well-described -- and by that I
don't mean six paragraphs long, just interesting -- can add greatly to
the atmosphere of a game. I thought the opening rooms of Zork II (a
generally inferior game) were well-written. You do nothing but move
through them, but they're kinda nice.
Since Zork is getting criticized a bit in this thread, I'd like to
mention that it could be worse -- the original mainframe version is
atrocious, map-wise. Rooms leading east to themselves, west to Room 2,
but you had to go west again to get to Room 1, not east. Practically
EVERYTHING was connected by a Twisty Little Passage. *That*, and not
the commercial version, is what I consider "unfinishable" without a map
or a walkthrough.
~JD
Esa A E Peuha
> I have the same problem; if the map gets big enough or complicated enough
> (strange connectivity) that I can't keep track of it in my head, I generally
> just stop playing. I never got very far in The Dreamhold for this reason.
Strange. I never had any problems with keeping the map of Dreamhold in
my head. Well, of course there are the odd locations which can't be
reached by standard movement commands, but there's not much reason to
map them anyway; the more usual locations are quite easy to map.
--
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/
xex...@gmail.com
> Risujin wrote:
>
> The links between Interactive Fiction and RPGs are, I think, very
> interesting and a topic for discussion that has hardly been touched
> upon. But I do not think that there is a close correspondence between
> D&D and Inform, or at least that if there is, this correspondence has
> not been identified in this thread.
Well, this is from an interview with Dave Lebling:
I had been playing D&D a lot [at the time of developing Zork], and was
really enjoying it and thinking about creating D&D scenarios, so I was
primed for interactive fiction.
(http://www.brasslantern.org/community/interviews/lebling.html)
My own experience of D&D and RPGs was that they started as tactical
games with an emphasis on puzzle solving, maps of underground
complexes, magic items and combat (as you state). I remember that it
was common to push little metal figures around a grid. North, South,
East, West etc. strikes me as a perfectly sensible navigation system
for this milieu - and players would state "let's head north along the
passage". When was Zork begun - around 1977? I think D&D was
published in 1974 and would have still been in quite a 'rudimentary'
state when Zork was being written. In Zork you fight a troll with a
magic sword, explore an underground world etc. etc. - the similarities
are explicit. Of course, Infocom games soon developed into more
'rounded' stories (Hitchhiker's Guide etc.) - and there's an
interesting parallel with RPGs here - but the rules of interacting with
the world remained the same; move north, examine objects more closely
etc.
> PS. I'd say that an important link between Inform and its companions on
> the one hand, and D&D and the vast majority of RPGs on the other, is
> that both have focussed on modelling small spatiotemporal actions,
> instead of social actions or dramatic conflicts. You can always say "put
> the bottle on the table", but almost never "beg her to marry me" and
> certainly not "choose duty over love". But is quite tangential to the
> issue under discussion here.
That's exactly the point, I think. There's a tension between this
emphasis on manipulating objects (early D&D was all about collecting
magic items and using them in certain ways) and trying to tell an
interesting story.
Adam Thornton
<there...@yahoo.com> wrote:
>Since Zork is getting criticized a bit in this thread, I'd like to
>mention that it could be worse -- the original mainframe version is
>atrocious, map-wise. Rooms leading east to themselves, west to Room 2,
>but you had to go west again to get to Room 1, not east. Practically
>EVERYTHING was connected by a Twisty Little Passage. *That*, and not
>the commercial version, is what I consider "unfinishable" without a map
>or a walkthrough.
I'd like to point out that most actual caves behave that way. Very few
straight-line passages. The adventure genre started as Crowther's
caving simulator, and the fantasy elements in _Adventure_ were largely
Don Woods' additions.
Adam
Victor Gijsbers
> That's exactly the point, I think. There's a tension between this
> emphasis on manipulating objects (early D&D was all about collecting
> magic items and using them in certain ways) and trying to tell an
> interesting story.
You know, the tension is not so much between letting the player
manipulate objects and telling an interesting story; the tension is
between letting the player manipulate objects and letting her decisions
be about the story.
D&D3E is all about killing monsters in interesting, tactical ways. Fine.
Between the fights, the GM can be telling a hell of a story; it's just
that the players are not actively involved in that part of the game, or
if they are, this is not thanks to the D&D rules.
Contrast that with one of the new 'narrativist' indie rpgs like Polaris,
The Mountain Witch, Dogs in the Vineyard or Primetime Adventures, and
you see rules that actually ensure that the players' creativity is the
main engine behind the story.
And that is where IF still has a lot of potential to grow, I think.
There are many great IF stories, but there are very, very few pieces
where the player has a meaningful influence on the story. (And 'multiple
endings', although a step in this direction, is a small step.)
Greetings,
Victor
The Wanderer
easily ignored.)
L. Ross Raszewski wrote:
> It's actually a parallel case to the other classic IF command
> "INVENTORY" -- inventory isn't a *verb* (Well, okay, maybe it is, but
> as a verb, it doesn't mean what it means in IF), we say it because
> there's no good single word for "take stock of my possessions".
...actually, the verb "inventory" (according to my quickly consulted
dictionary, that being gcide) expands to "take inventory of" and does
mean almost exactly that - it's only the "my possessions" part which is
implied by the IF context, the rest of it is the natural meaning of the
verb.
It would in theory be sensical to write a game in which the verb
"INVENTORY" could be applied to anything capable of containing objects,
and would return a list of the known contents of that thing; give the
verb a default target of "myself", and it would behave like a slightly
extended version of the command so long familiar. (In fact, I'm suddenly
finding myself liking the idea; if I ever write anything more than an
utterly trivial piece of IF, I'll probably have to include just such a
feature.)
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
A government exists to serve its citizens, not to control them.
Andrew Plotkin
It looks like you're conflating two or three different points here,
and they're not really pointing in the same direction.
The classic Adventure model *was* very much about manipulating
objects. That model was killed (although not everybody noticed) in
1982 or 1983 -- let's say, _Deadline_ and _Infidel_. Everything in IF
since then has been about story. The objects are still there, and the
player manipulates them, but these actions *are* about the story. Yes,
even when the verb is PUSH and the noun is BUTTON.
The comparison with paper-and-pencil RPGs is, I think, just not very
sustainable. The mechanics of RPGs are so different from the mechanics
of IF that I don't see a useful comparison. (The elements of D&D which
bore comparison to IF *were* the parts -- not in the D&D rules, as you
note -- which were about story rather than combat mechanics. Ignoring
that troll-fight in Zork 1. Which was never a good idea anyhow.)
Mind you, I think "Dogs in the Vineyard" is *really cool*. But if you
want to make use of it in IF, you're going to have to explain how.
The third element you're invoking is the distinction between a story
which is entirely created by the game designer, and a story which the
player helps invent. This is a long-running discussion, of course. I
think we've generally come around to the agreement that a player's
*control* over the story is a separate element from the player's
*complicity* in the story. Moreover, control happens at many levels;
the player's control over actions on a move-by-move basis is separable
from his control over the outcome of a "chapter", which is separable
from his control over the ultimate ending. The author can choose
different amounts of freedom at each of these levels.
I agree that IF has not explored much in the realm of player-
controlled story (beyond the move-by-move level). I also agree that
what exploration we've done is in the style of "multiple endings" or
"choose one of the following N outcomes" -- a style which I find
deeply unsatisfying in any format. (See, CYOA books.)
On the other hand, I do *not* see this as a scale (or even multiple
levels of scales) where one end is labelled "old-fashioned, immature,
author controls story" and the other end is "modern, player controls
story". It's not a race to one end of the scale, I mean.
samwyse
> "Risujin" <ris...@fastmail.fm> wrote in message
> news:DT5Qe.16525$mb4....@tornado.rdc-kc.rr.com...
>
>>mazes and thats really the only place they are strictly necessary.
>
> No.... their roots lie in navigating in the real world in any area that is
> unfamiliar territory to the traveler.
Their roots in IF lie in the mazes. Except for the mazes, the original
(FORTRAN) version of Adventure can be played without using compass
directions. Each room has a name, and the names can be used to move
from place to place. (Of course, finding out what those names are
without using compass directions is a bit tricky. Back in the day, I
used de-compilation.)
Andrew Plotkin
> Kevin Forchione wrote:
> > "Risujin" <ris...@fastmail.fm> wrote in message
> > news:DT5Qe.16525$mb4....@tornado.rdc-kc.rr.com...
> >
> >>Cardinal directions are a tradition within IF, but their roots lie in
> >>mazes and thats really the only place they are strictly necessary.
> >
> > No.... their roots lie in navigating in the real world in any area that is
> > unfamiliar territory to the traveler.
>
> Their roots in IF lie in the mazes. Except for the mazes, the original
> (FORTRAN) version of Adventure can be played without using compass
> directions. Each room has a name, and the names can be used to move
> from place to place.
That doesn't demonstrate the claim. When I first played Adventure
(that being my first IF experience) I used the compass directions
right away, long before I got to the mazes. The compass directions
were in the room descriptions. It seemed clear that *that* was the
natural mode of movement, and the room-name commands were an
alternative -- one which didn't work out. (Tellingly, the crop of
Adventure imitators dropped them and kept the compass.)
I would actually say that the compass convention doesn't *directly*
come from how people navigate. People navigate by a mix of landmarks,
node-and-link graphs, and a relative directional sense (but tracked as
relative to *the world*, not to the person's current facing). The
compass system (when combined with easily-visible room names) provides
a good approximation of all of these. Close enough that we can learn
to see it as the same thing.
Graphical adventure games *do* let you navigate exactly as you do in
real life -- well, except for your inner-ear sense of motion -- and
that's a reason why they have a wider audience.
Kevin Forchione
> Graphical adventure games *do* let you navigate exactly as you do in
> real life -- well, except for your inner-ear sense of motion -- and
> that's a reason why they have a wider audience.
Once you learn to map the movement of the joypad, joystick, mouse, or
keyboard to the movement of the character, that is. Some of those graphical
games have adjustments that allow upward joystick movements to direct the
movement downward, or by toggling the setting, to direct the movement
upward. The fact that this difference is available seems to indicate that
the mapping is learned in the same fashion that it is for text-based
games -- except that command lines require an extra level of conversion from
impulse to symbol to action.
But suppose we did capture keystrokes and used them for directional
commands, such as is sometimes used on the pc numberpad. We could do that in
TADS.... But you're still going to have to provide textual symbols to
indicate that a room leads to other rooms. And without cardinal directions
the nomenclature for movement is diminished, and so are the choices for
movement.
I suppose you *could* give every room a name, even the unknown ones, and
forget all about travel commands. You might have a room description such as
this.
Kitchen
A lovely little room, sparsely kitted out.
Exits: MysteryRoom-01, MysteryRoom-02, LivingRoom, Backyard.
That wouldn't be hard to do, but it seems juvenile. It wouldn't work very
well trying to fit it into any kind of room description narrative either.
Directional commands do give a room some feeling of dimension and do provide
the mind with some kind of imaginal perspective in the game. Once you
abandon the cardinal directions and even the relativistic and limited
directions of port, starboard, etc., or left, right, etc., you've lost any
impression of motion and spatial relation. Up? Down? In? Out? Let's not dumb
the whole thing down or interactive fiction will begin to feel flat, like a
card game.
My suggestion is that the imagination makes something out of commands such
as "north", "southeast" and "up" and "down".
--Kevin
Andrew Plotkin
> "Andrew Plotkin" <erky...@eblong.com> wrote in message
> news:df0it6$c4e$1...@reader2.panix.com...
> > Graphical adventure games *do* let you navigate exactly as you do in
> > real life -- well, except for your inner-ear sense of motion -- and
> > that's a reason why they have a wider audience.
>
> Once you learn to map the movement of the joypad, joystick, mouse, or
> keyboard to the movement of the character, that is.
Granted.
Of course text games *also* require you to learn the mapping of
keyboard movements to commands. Everyone here learned touch-typing on
text IF, right? :) There's always a layer of abstraction there
somewhere.
Note that I was *not* claiming that text games should imitate
graphical adventure input mechanics.
xex...@gmail.com
> Contrast that with one of the new 'narrativist' indie rpgs like Polaris,
> The Mountain Witch, Dogs in the Vineyard or Primetime Adventures, and
> you see rules that actually ensure that the players' creativity is the
> main engine behind the story.
I haven't been near RPGs for about 13 years, but I'll have a look as
I'm sure it'll be interesting to see how they've come on. I remember
that our group ended up with rule-free games (just as E Gary Gygax, the
founder of D&D, did) - one referee would just ask us to 'roll the dice'
at certain exciting junctures. I know that the outcome wasn't affected
by the result, but we still needed to roll the dice. Quite an odd
pastime, I suppose.
> And that is where IF still has a lot of potential to grow, I think.
> There are many great IF stories, but there are very, very few pieces
> where the player has a meaningful influence on the story. (And 'multiple
> endings', although a step in this direction, is a small step.)
I'm not sure if I want to influence the story. I remember
multiple-choice adventure books being sold along the lines of 'have you
ever wondered what would have happened if your favourite character had
decided not to wear the ring of Goobargamon?', to which I always felt
the answer was 'no, not really.' I like the *illusion* of control that
IF gives you; the process of manipulating things in the text in order
to read the author's next piece of prose. I guess my original point
was that this process can be quite a jarring one when the rules of the
game are based on moving north and pushing the button. But maybe not.
Cheers,
Leon
dgen...@hotmail.com
15 different locations; all but two of which have uniquely different
descriptions? The author creates the illusion of a much larger space
by means of the map layout, and certain word choices. This illusion
would not have been achieved with a single room description that read
"You're in a really big forest (type "'enter house' to leave)".
Are you familiar with the standard list of verbs which these games
accept? Verbs like 'open' and 'close', 'examine', 'look
in' and so forth? In Zork I, you get into the house by typing
"open window". When I was a kid (some 20 years ago) we played
pirated copies of this game, so no one had read the instruction manual
and, yeah, we had some trouble thinking of "open window". But now
that the games are in public domain (and the instruction manuals also)
you have no excuse.
And now on to my rant about so-called "puzzleless" IF. If there
are truly no puzzles to solve ("Fire Tower", for example) then
there is no incentive for the player to immerse themselves in the
descriptions. The writing in "Zork I" was terse and Sophomoric,
but I remember the games atmosphere quite vividly, because I had to
re-read each description carefully for detail, and supplemented what
the author didn't write with my own imagination. In contrast "Fire
Tower" is better written, but I hardly noticed because I was in a
rush to get to the top of the mountain. Once I got there, I decided
the game was over and turned it off.
A game without puzzles is a game without interactivity.
Dave
Kevin Forchione
news:1125413795.3...@z14g2000cwz.googlegroups.com...
> And now on to my rant about so-called "puzzleless" IF. If there
> are truly no puzzles to solve ("Fire Tower", for example) then
> there is no incentive for the player to immerse themselves in the
> descriptions. The writing in "Zork I" was terse and Sophomoric,
> but I remember the games atmosphere quite vividly, because I had to
> re-read each description carefully for detail, and supplemented what
> the author didn't write with my own imagination. In contrast "Fire
> Tower" is better written, but I hardly noticed because I was in a
> rush to get to the top of the mountain. Once I got there, I decided
> the game was over and turned it off.
This appeal is probably best summarized by Infocom's statement in their New
Zork Times newsletter as quoted in NickMountfort's Twisty Little Passages:
"Although our games are interactive fiction, they are more than just
stories:
they are also a series of puzzles. It is these puzzles that transform our
text from an hour's worth of reading, to many, many hours worth of thinking
... The value of our games is that they will provide many, many hours of
stimulating mental exercise. (Infocom, Inc. 1984)"
--Kevin
Default User
> Are you familiar with the standard list of verbs which these games
> accept? Verbs like 'open' and 'close', 'examine', 'look
> in' and so forth? In Zork I, you get into the house by typing
> "open window". When I was a kid (some 20 years ago) we played
> pirated copies of this game, so no one had read the instruction manual
> and, yeah, we had some trouble thinking of "open window". But now
> that the games are in public domain (and the instruction manuals also)
> you have no excuse.
I don't believe the Zork games are public domain. There was a period of
time where Activision (the inheritors of Infocom) were allowing free
downloads, but never gave up copyright.
Brian
James Mitchelhill
<snip description of space in zork>
> And now on to my rant about so-called "puzzleless" IF. If there
> are truly no puzzles to solve ("Fire Tower", for example) then
> there is no incentive for the player to immerse themselves in the
> descriptions. The writing in "Zork I" was terse and Sophomoric,
> but I remember the games atmosphere quite vividly, because I had to
> re-read each description carefully for detail, and supplemented what
> the author didn't write with my own imagination. In contrast "Fire
> Tower" is better written, but I hardly noticed because I was in a
> rush to get to the top of the mountain. Once I got there, I decided
> the game was over and turned it off.
Of course, people who enjoy puzzleless IF don't actually need any
incentive to immerse themselves in the descriptions, because the writing
and depth is, in fact, what they are playing for.
For what it's worth, I quite enjoyed The Fire Tower, although I'd have
preferred a deeper implementation. It may also have been a misjudgement to
make the fire tower itself such an anticlimax.
> A game without puzzles is a game without interactivity.
Not true.
--
James Mitchelhill
ja...@disorderfeed.net
http://disorderfeed.net
Victor Gijsbers
> A game without puzzles is a game without interactivity.
That would be the case if puzzles were the only way to have (meaningful)
interaction with an IF story. Surely, though, this is not the case? In
"Slouching towards Bedlam", there are some puzzles, but the most
meaningful interaction the reader has with the piece is when she decides
which of the (basically two, although one of them can be achieved in
different ways) possible outcomes she wants the story to have.
That is interactivity; it is not a puzzle, because there are no right
and no wrong choices.
Perhaps we could say that a puzzle is:
* a meaningful choice for the player
* where only a subset of the alternatives is succesfull
* and where the player must use wits, intelligence, creativity, and so
forth to find at least one member of this subset.
But that leaves open the possibility that there are meaningful choices
in which *all* of the alternatives are good, and the author has not
stipulated that you have to choose one of them.
Of course, even IF pieces without meaningful interaction can be quite
enjoyable (I at least have enjoyed such highly linear 'puzzle-less'
pieces as Photopia and Shade). But giving up puzzles does not yet mean
giving up interactivity.
Greetings,
Victor
Victor Gijsbers
I think we are mostly in agreement.
There is one thing in your post I do not quite understand, so maybe you
can clear it up for me. You say that since 1982/1983, 'everything in IF
has been about story'. This is open to multiple interpretations. If your
point is that in the vast majority of games, if the player has to type
"push button", then pushing the button is a significant event in the
story (is embedded in the setting and the plot, and so forth), I agree
with you. (As far as my very non-encyclopedic knowledge of IF allows me
to agree with such a sweeping statement, at least.)
The point I was trying to make, though, was more about the player's
reason for choosing to type something. If the player pushes the button
because he has deduced, after some experimentation, that it is the only
action that will allow him to explore the rest of the piece, then his
reasons for typing it are not that he thinks it is a good addition to
the story, or the beginning of an interesting path the story can take.
The reason is that he wants to go on playing, and is probably excited
about having solved the puzzle. In the respect of grounds for action on
the part of the player, then, the action of pushing the button is not
connected to the story in a significant sense.
So maybe you could say a bit more about what you mean with everything in
recent IF having been about story.
As for RPGs, I'm not very interested in the causal historical relations
between D&D and IF, and am willing to drop any claim I may have made. It
are merely the structural relations I am interested in. A very good
point you make, though, is that 'small spatial action' have, in IF, been
much more embedded into the narrative than they have been in RPGs. This
is, of course, due to the nature of the medium, but it makes my easy
comparison a bit misleading.
The medium of IF and that of RPGs are so different that the techinques
that work in one certainly cannot just be transported to the other. I
hope I have not given the impression that one could write a "Dogs in the
Vineyard- the IF story!"-piece, because one cannot. I certainly do not
advocate basing pieces of IF on RPG rulesets. (Although, who knows what
one could do with gtalk.h and Polaris' keyphrases... hmmm... but never
mind. :) )
I think that what might be learned by IF authors from some of the new
indie RPGs is not so much actual rules, but rather different ways of
structuring interaction. We could talk about that, but this is going
very much offtopic. I'm not familiar with newsgroup etiquette concerning
threads that go offtopic (in fora, where I often come, it is generally
discouraged), but maybe it would be better to continue this discussion
in a new thread.
> On the other hand, I do *not* see this as a scale (or even multiple
> levels of scales) where one end is labelled "old-fashioned, immature,
> author controls story" and the other end is "modern, player controls
> story". It's not a race to one end of the scale, I mean.
I could not agree more. Please, let no one read my posts as trying to
pass negative judgement over some sections of IF.
Greetings,
Victor
Ben Rudiak-Gould
> And now on to my rant about so-called "puzzleless" IF. If there
> are truly no puzzles to solve ("Fire Tower", for example) then
> there is no incentive for the player to immerse themselves in the
The problem with your rant is that the whole notion that puzzleless IF can
be judged from first principles makes no sense. Perhaps it would make sense
if it were something that writers liked but players universally disliked (as
seems to be the case with old-school mazes), but it isn't. I do like
puzzleless IF. I like games that are over in half an hour. I like the
two-minute puzzleless dream sequences in Narcolepsy. It doesn't bother me
that you don't like these things -- why should it? What does bother me is
that you seem to believe that I'm not truly enjoying my chosen hobby, and
would get more fulfillment out of it if I were more like you.
I've actually seen quite a lot of this in the IF community, mainly in the
idea that people who use hints or walkthroughs are "cheating" and should be
discouraged from doing this and scolded if they do so anyway. I don't
disagree with this so much as find it faintly bizarre, like saying that
people who take milk in their tea should be ashamed of themselves.
-- Ben
Andrew Plotkin
> can clear it up for me. You say that since 1982/1983, 'everything in IF
> has been about story'. This is open to multiple interpretations. If your
> point is that in the vast majority of games, if the player has to type
> "push button", then pushing the button is a significant event in the
> story (is embedded in the setting and the plot, and so forth), I agree
> with you. (As far as my very non-encyclopedic knowledge of IF allows me
> to agree with such a sweeping statement, at least.)
>
> The point I was trying to make, though, was more about the player's
> reason for choosing to type something. If the player pushes the button
> because he has deduced, after some experimentation, that it is the only
> action that will allow him to explore the rest of the piece, then his
> reasons for typing it are not that he thinks it is a good addition to
> the story, or the beginning of an interesting path the story can take.
> The reason is that he wants to go on playing, and is probably excited
> about having solved the puzzle.
What I mean is this: the advances we've made in IF technique are to
make all of those motivations *the same*, for a given situation. So
the player has deduced which button to push (or whatever) not by
considering an abstract logic puzzle, but by taking the point of view
of the character. At the moment he types the command, he's not
thinking *any* of the above; he's thinking "Holy crap, I can save the
city after all! We're going to make it!" Thus -- taking part in the
story. Not necessarily helping to *create* the story; but rather
helping to create the *future*, as the protagonist in any story does,
with the reader as silent support. The difference is that in IF, the
reader gets to be *active* support.
There are of course IF games (including some of mine, and going back
to Infidel, as I said) that play off this, by separating the
character's motivation from the player's, and thus developing irony or
tragedy. That's a secondary technique, derived from the above.
Kevin Forchione
That's true. But the advances in technique don't have a whole lot to do with
the language or even the world model advancement. They are facilitated by
them, but probably could have been developed just as easily in ZIL. One of
the aspects of this thread has been a proclamations for a new
language/library/development system, when in fact the advancements in IF
technique that have been argued for are rather independent of the technical
advancements of say TADS 3.
--Kevin
Andrew Plotkin
> news:dfb1q5$7ip$1...@reader1.panix.com...
> >
> > make all of those motivations *the same*, for a given situation. So
> > the player has deduced which button to push (or whatever) not by
> > considering an abstract logic puzzle, but by taking the point of view
> > of the character. At the moment he types the command, he's not
> > thinking *any* of the above; he's thinking "Holy crap, I can save the
> > city after all! We're going to make it!" Thus -- taking part in the
> > story. Not necessarily helping to *create* the story; but rather
> > helping to create the *future*, as the protagonist in any story does,
> > with the reader as silent support. The difference is that in IF, the
> > reader gets to be *active* support.
>
> That's true. But the advances in technique don't have a whole lot to
> do with the language or even the world model advancement. They are
> facilitated by them, but probably could have been developed just as
> easily in ZIL.
I agree with this. (Well, probably it would have been a constant factor
more difficult.)
I don't remember enough of the history of the thread to know whether I
implied disagreeing with it in the past. :)
> One of the aspects of this thread has been a proclamations for a new
> language/library/development system, when in fact the advancements
> in IF technique that have been argued for are rather independent of
> the technical advancements of say TADS 3.
There's nothing wrong with a constant factor, of course.
Kevin Forchione
> There's nothing wrong with a constant factor, of course.
I totally agree.
--Kevin
Kevin Forchione
news:smdSe.565$ua1...@newssvr21.news.prodigy.com...
But it does rather put the onus on the game writer, rather than the library
developer. One could hardly credit the word processor for new trends in
literature.
If authors want games that focus less on object manipulation and more on
drama, or games that don't rely on cardinal direction navigation, they can
hardly fault the current game development systems for their lack of
invention.
It *may* be that parts of a library would have to be replaced to accommodate
a more generalized approach: certain aspects of the parsing process may need
redesign to make it easier to modify, for instance, or a new model of NPC
conversation may need to be supported. Certainly such enhancements make it
easier for authors to move in *these* new directions (once they fully
understand the mechanisms of the enhanced libraries). And some would argue
that to a certain extend the libraries themselves then codify the new
enhancements into convention. It remains to be seen whether the libraries of
the future actually diminish an author's ability to move in new and radical
directions due to (a) the learning curve required to thoroughly master the
new library; (b) the amount of labor required to change the infrastructure
to accommodate a new gaming paradigm.
But it also remains to be seen whether *any* paradigm would lessen the
struggle of newcomers with IF. Certainly, IF can follow (ironically) in the
footsteps of gaming trends established by its graphical brothers, but I
suggest that when the game has been developed that finally does incorporate
all the story elements and interactive styles of the competition the
newcomer will still struggle with IF, simply because of its textual nature.
The plight of the newcomer should not dictate the direction of IF, though
game authors may choose to sometimes lend an ear.
--Kevin
Risujin
> I've actually seen quite a lot of this in the IF community, mainly in
> the idea that people who use hints or walkthroughs are "cheating" and
> should be discouraged from doing this and scolded if they do so anyway.
> I don't disagree with this so much as find it faintly bizarre, like
> saying that people who take milk in their tea should be ashamed of
> themselves.
Completely off-topic, but there is actually a reasonable argument
against hints.
First off, I personally like them. An author can't be expected to
perfectly setup a puzzle so that everyone gets it, authors make
mistakes. However, especially with puzzle-centric games (I recently
played Brian Uri's Augmented Fourth, a good example) you really can't
play the game unless you're "in the mood."
There was many a time when I simply had been playing too long and just
wanted to get it over with (and reached for the walkthrough too early).
At times like these, you need to control yourself and just set the game
down and come back when you're feeling up to it again. The author should
also take some measures to make sure the player is genuinely stuck
before revealing the answers because, unlike other mediums, it really is
easy to spoil a puzzle and ruin the game for yourself.
This is kind of why I have a special liking for 2-hour IFComp games, you
finish the game before you enter the frustrated "get-it-over-with"
phase and don't need to make the call of when to put it down and come
back later (self-restraint).
It's not a judgmental matter of "people who use hints suck," it's about
protecting people from themselves. :)
--
Risujin
ris...@fastmail.fm
Risujin
> But it does rather put the onus on the game writer, rather than the library
> developer. One could hardly credit the word processor for new trends in
> literature.
>
> If authors want games that focus less on object manipulation and more on
> drama, or games that don't rely on cardinal direction navigation, they can
> hardly fault the current game development systems for their lack of
> invention.
I couldn't have said it better myself.
> It *may* be that parts of a library would have to be replaced to accommodate
> a more generalized approach: certain aspects of the parsing process may need
> redesign to make it easier to modify, for instance, or a new model of NPC
> conversation may need to be supported. Certainly such enhancements make it
> easier for authors to move in *these* new directions (once they fully
> understand the mechanisms of the enhanced libraries). And some would argue
> that to a certain extend the libraries themselves then codify the new
> enhancements into convention. It remains to be seen whether the libraries of
> the future actually diminish an author's ability to move in new and radical
> directions due to (a) the learning curve required to thoroughly master the
> new library; (b) the amount of labor required to change the infrastructure
> to accommodate a new gaming paradigm.
Now this is the meat of my argument. You're thinking along the same line
as I am but there is more I want to add.
As an analogy, let me ask the question of why we would choose to program
in Inform (or Lisp or C or using a library, you name it) rather than
assembler/machine code?
There is no argument that lower level language will allow for more
control, superior (faster, less memory) execution, etc. Assembler will
allow you to do things that higher level languages simply will not.
However, the reverse is true more often than not. Why is this? Read on.
Programming in assembler is an exercise of tedious labor. Even the best
assembler programmers spend MORE TIME for EQUIVALENT RESULTS. The truth
is, no one has all the time in the world. If we did, we would be writing
interactive fiction in machine code which would marvel the world with
its flexibility--something we're obviously not doing.
A higher level language allows you to take common shortcuts. The idea is
that there are many logical structures which need not be reinvented
every time (memory management, file access, math, etc). You lose control
when you use these "black box" solutions, yet it saves the most crucial
resource--time. Because you can do more quantitatively in an equal
period of time using a higher level language, you are enabled to create
more than you could with a lower level language given a time constraint.
I believe this to be the case with interactive fiction today. For the
current state of IF development, Inform and TADS seem to be (while not
as extreme as assembler) fairly low level languages. They try to appease
every use from puzzles to parser-abuse, and in multiple languages
(Spanish IF anyone?). This paradigm of low level flexibility makes many
things more difficult than they otherwise could be had the system been
more narrowly oriented.
> But it also remains to be seen whether *any* paradigm would lessen the
> struggle of newcomers with IF. Certainly, IF can follow (ironically) in the
> footsteps of gaming trends established by its graphical brothers, but I
> suggest that when the game has been developed that finally does incorporate
> all the story elements and interactive styles of the competition the
> newcomer will still struggle with IF, simply because of its textual nature.
As for a new paradigm, allow me to make a proposal.
The cardinal paradigm, as I'd phrase it, should be to increase the
number of potential authors and players. If IF can be made more
accessible, easier, and less time consuming to create, more people can
potentially write IF. More authors will translate into better and more
varied fiction. Making IF easier to play will broaden the potential
audience. IF will remain vibrant and grow.
While "make IF easier" is a task we'd all like to see accomplished, this
is obviously a tall order. I don't claim to know exactly how this ought
to be done, but I do have some ideas:
1. Sacrifice Flexibility
------------------------
Because if I really wanted to play Tetris, I wouldn't play it on my IF
parser.
The language does not need to have a standard library. It should *be*
the standard library. The parser does not need to be written in the
language, it should literally be *in* the language.
Flexibility should not trump ease of use.
2. Speak English
----------------
Inform/TADS use an ugly pattern matching scheme which puts a large part
of the burden of recognition on the author. The use of English grammar
structures and English vocabulary available to the author is weak.
This is wrong.
The parser and language need to thoroughly implement a larger array of
English grammatical structures. Prepositions, adverbs, and synonyms
exist in English for a reason.
The burden of this should NOT lie on the author. While the author must
be free to add his or her own nouns/verbs/adverbs/prepositions/etc, the
grammatical parsing should not have to be done by the author.
Here is a subtle, but telling example (from Inform's Grammar.h):
Verb 'switch'
* noun -> Switchon
* noun 'on' -> Switchon
* noun 'off' -> Switchoff
* 'on' noun -> Switchon
* 'off' noun -> Switchoff;
Inform does not have a provision for adpositions "off" and "on", thus a
template with all possible permutations is necessary. Authors should not
have to worry about these things.
While it may seem that focusing on English locks out foreign IF, this is
not so. The IF language should be "ported" to other spoken languages
rather than having to support multiple languages in one codebase. This
ensures that it fits properly with any new grammar.
3. Spell Check
--------------
Spell checking algorithms have been around since the beginning of time,
there is no reason why we can't implement one into the parser.
The game knows what words are valid and what words are not. This is a
small, limited dictionary from which most spelling mistakes can be
easily disambiguated without the need to endlessly reprompt the player.
4. Speaking of Disambiguation...
--------------------------------
Disambiguation has long been the measuring stick by which IF languages
are judged. Unfortunately, most languages do quite poorly in this
respect (see the interactive garden, Flowers for a parser
comparison--anyone have a link?).
Actions which cause logic errors should not be part of the
disambiguation tree.
From Augmented Fourth (an otherwise enjoyable game):
|
| > enter house
|
| Did you mean the black house or the black house plaque?
|
Yes, I'm obviously trying to enter a plaque!
Now I'm not just full of hot air, I have an actual implementation idea
for this one.
One way this could be done is to have the parser actually evaluate every
possible action within said parse tree via a hypothetical memory space
for each (storing write changes to the world separately that is), and
retaining only those which would cause no problems and would have been
logical selections for the player.
Now before we have complaints about what such a ludicrous suggestion
would do to processor usage and memory consumption...
5. Forget Processor Usage and Memory Consumption
------------------------------------------------
Because a fast processor costs less than $100.
And no, nobody cares if you want to run modern IF on your 1980s pile of
junk, thats your problem. Run Zork like everyone else did in the 80s.
6. Implicit Actions
-------------------
If the parser is smart enough to tell me what I need to do before I do
something else, couldn't it just do it for me?
This topic should not be taken lightly however. The player should have
this convenience, but not at the expense of the author.
Whether an elegant way to do this exists or not, an author should be
able to specify under what conditions his verbs work and under what
conditions they don't and which conditions can be implicitly met. The
parser should then have the ability to make these conditions happen
automatically.
7. C Standard
-------------
There is a reason why so many programming languages mimic C syntax. C
syntax has become the English of programming. By making up goofy new
language grammar (Array --> 1) for your new language, you're not making
it more "user friendly," you're shooting yourself in the foot.
That's all for now, although I'm sure there are many more out there.
To do this paradigm justice, a new language would really need to be
designed. A library hack to hack a hacked language is just too hacky.
> The plight of the newcomer should not dictate the direction of IF, though
> game authors may choose to sometimes lend an ear.
The plight of the newcomer MUST dictate the direction of IF in order for
IF to remain alive (creatively evolving). Remember what newcomers said
about DOS?
Please read the *very* relevant article on this by veteran game designer
Chris Crawford, "Games are Dead":
http://www.erasmatazz.com/library/JCGD_Volume_9/Games_are_Dead.html
As he writes, market-driven (i.e. experienced gamer driven) game
development stifles creativity, rendering the industry "technically
alive but dead in every meaningful dimension."
In the case of IF, thats every one of you "I have a compass ingrained in
my brain," maze-loving, save-restart-cycle, Infocom IF gamers who feel
everything is fine and dandy.
But don't troll me about it. If you really feel everything is fine and
dandy, this thread is not for you--there's plenty of IF and IF languages
out there for your liking already.
Nor am I suggesting we scrap everything we already have, but rather that
we need a new direction for the further evolution and growth of IF (if
there's anyone interested in that...).
--
Risujin
ris...@fastmail.fm
James Mitchelhill
<snip - introducing a new paradigm for if>
> 1. Sacrifice Flexibility
> ------------------------
>
> Because if I really wanted to play Tetris, I wouldn't play it on my IF
> parser.
>
> The language does not need to have a standard library. It should *be*
> the standard library. The parser does not need to be written in the
> language, it should literally be *in* the language.
>
> Flexibility should not trump ease of use.
From an author's point of view, flexibility is often synonymous with ease
of use. If I want my game to do something the author of the library didn't
imagine it should not make it any harder than possible. Say, for example,
my PC is part of team, all of whom can communicate via radio at any time.
I don't want to go with an ugly solution of:
> switch radio to Sergeant Mayhem
You change the radio to Sergeant Mayhem's frequency. It crackles with
static.
> ask radio about the bomb
You speak into the radio.
"There's a freaking BOMB there?!" screams Mayhem, "Get the hell out of
there you fool!"
...
Instead, I want the PC to be able to talk to his team members wherever
they are, a la:
> ask sergeant mayhem about the bomb
...
By default this won't work as Mayhem is not in the same location. So I'm
probably going to have to do some hairy parser hacking to get it to work.
This is where flexibility is a virtue. If I can simply replace one
function in the handling of AskVerb (its scope) then I'm going to spend a
lot less time implementing this functionality.
> 2. Speak English
> ----------------
>
> Inform/TADS use an ugly pattern matching scheme which puts a large part
> of the burden of recognition on the author. The use of English grammar
> structures and English vocabulary available to the author is weak.
>
> This is wrong.
>
> The parser and language need to thoroughly implement a larger array of
> English grammatical structures. Prepositions, adverbs, and synonyms
> exist in English for a reason.
>
> The burden of this should NOT lie on the author. While the author must
> be free to add his or her own nouns/verbs/adverbs/prepositions/etc, the
> grammatical parsing should not have to be done by the author.
...
I agree with this strongly. I'm currently developing a parser that works
something like this. It does get somewhat complicated, though. It's
unfortunate that parsing for IF lies somewhere between parsing natural
language and parsing programming languages (after all, the player's
command is in many respects a program). There seems to be a lack of
information on this, but maybe I didn't look hard enough.
> While it may seem that focusing on English locks out foreign IF, this is
> not so. The IF language should be "ported" to other spoken languages
> rather than having to support multiple languages in one codebase. This
> ensures that it fits properly with any new grammar.
I'm not entirely certain if it's possible to write a description of a
language which could then plug into a general parser. I did briefly look
at this, but my head hurt.
<snip>
> 4. Speaking of Disambiguation...
> --------------------------------
>
> Disambiguation has long been the measuring stick by which IF languages
> are judged. Unfortunately, most languages do quite poorly in this
> respect (see the interactive garden, Flowers for a parser
> comparison--anyone have a link?).
>
> Actions which cause logic errors should not be part of the
> disambiguation tree.
>
> From Augmented Fourth (an otherwise enjoyable game):
> |
> | > enter house
> |
> | Did you mean the black house or the black house plaque?
> |
> |
> Yes, I'm obviously trying to enter a plaque!
>
> Now I'm not just full of hot air, I have an actual implementation idea
> for this one.
I can do better than that. I almost have an actual implementation of this.
> One way this could be done is to have the parser actually evaluate every
> possible action within said parse tree via a hypothetical memory space
> for each (storing write changes to the world separately that is), and
> retaining only those which would cause no problems and would have been
> logical selections for the player.
The way I work this is by splitting my parser into three parts.
1. Parse the command's grammar into a list of possible interpretations of
the command.
2. Map these interpretations to possible actions within the game. Check if
the tokens the player typed map to actual objects within the game. Discard
those interpretations that don't.
3. Interface with the world to find out which objects are actually
available to the player using the verb in the sentence, reducing the list
of possible objects to those which it is possible to apply that verb to.
Remove interpretations that don't make have all the objects they need.
Possible we still need to disambiguate, but this shouldn't happen as
often.
This a) handles ambiguity well and b) reduces disambiguation.
<snip>
> 7. C Standard
> -------------
>
> There is a reason why so many programming languages mimic C syntax. C
> syntax has become the English of programming. By making up goofy new
> language grammar (Array --> 1) for your new language, you're not making
> it more "user friendly," you're shooting yourself in the foot.
I find it kind of odd how you say a lot about high level languages and
then suggest that C syntax is a good idea. Especially given that C isn't
object oriented and IF does tend to be (in more than one sense).
I don't think you should have to learn a new language to program IF.
The language I'm using for my library is Python, which has several
advantages. It's easy to learn, widely used, available (and often
installed by default) for most platforms, and has an excellent standard
library.
There's a couple of ugly hacks needed to make it work as an IF language,
but these will be handled by the library.
<snip>
> Nor am I suggesting we scrap everything we already have, but rather that
> we need a new direction for the further evolution and growth of IF (if
> there's anyone interested in that...).
(there is).
Andrew Plotkin
> 1. Sacrifice Flexibility
> ------------------------
>
> Because if I really wanted to play Tetris, I wouldn't play it on my IF
> parser.
Everyone brings this up, and it's a *really bad* example. You know
what language facilities you need to write Tetris? Arrays and
for-loops. Are you arguing that an IF language should not support
arrays or for-loops?
> Actions which cause logic errors should not be part of the
> disambiguation tree.
Be careful with this one. You *don't* want:
>EXAMINE MOUNTAIN
It's tall, pointy, and twenty miles away.
>TAKE MOUNTAIN
I don't see any such thing!
(Because taking the mountain is a logic error, right? Wrong -- it's a
command which should fail. Commands which should fail are an integral
part of puzzle design.)
> But don't troll me about it. If you really feel everything is fine and
> dandy, this thread is not for you--there's plenty of IF and IF languages
> out there for your liking already.
This part is flamebait.
James Mitchelhill
> Here, Risujin <ris...@fastmail.fm> wrote:
>> Actions which cause logic errors should not be part of the
>> disambiguation tree.
>
> Be careful with this one. You *don't* want:
>
>>EXAMINE MOUNTAIN
> It's tall, pointy, and twenty miles away.
>>TAKE MOUNTAIN
> I don't see any such thing!
>
> (Because taking the mountain is a logic error, right? Wrong -- it's a
> command which should fail. Commands which should fail are an integral
> part of puzzle design.)
There is a difference. But consider:
>EXAMINE BIRD
Do you mean the seagull flying in the distance, or the crow?
>SEAGULL
It circles high above.
> EXAMINE CROW
It is on the table in front of you.
> TAKE BIRD
The crow caws and hops away.
> TAKE SEAGULL
It's too far away.
The principle is that ambiguous commands should default to the object that
responds successfully. This still has some implications for puzzle design,
(e.g puzzles where there are many similar objects, only one of which
responds to a certain command), but flagging something to not
automatically disambiguate should be enough to get past that, I think.
Or are there good reasons this won't work?
Andrew Plotkin
> On Sat, 03 Sep 2005 23:51:43 +0000, Andrew Plotkin wrote:
>
> > Here, Risujin <ris...@fastmail.fm> wrote:
> >> Actions which cause logic errors should not be part of the
> >> disambiguation tree.
> >
> > Be careful with this one. You *don't* want:
> >
> >>EXAMINE MOUNTAIN
> > It's tall, pointy, and twenty miles away.
> >>TAKE MOUNTAIN
> > I don't see any such thing!
> >
> > (Because taking the mountain is a logic error, right? Wrong -- it's a
> > command which should fail. Commands which should fail are an integral
> > part of puzzle design.)
>
> The principle is that ambiguous commands should default to the object that
> responds successfully. This still has some implications for puzzle design,
> (e.g puzzles where there are many similar objects, only one of which
> responds to a certain command), but flagging something to not
> automatically disambiguate should be enough to get past that, I think.
>
> Or are there good reasons this won't work?
I think it can work, but you'll need a clear separation between scope
(what you can refer to) and disambiguation (which option to choose of
the things that were referred to). Sticking a flag in may not be smart
enough.
(Inform gets this separation wrong sometimes, which leads to bugs --
fortunately, rare ones. E.g., "TAKE X FROM Y" can return "You see no
such thing" instead of the more correct "The X isn't in the Y.")
I also worry that the simple binary division of "logical" vs
"illogical" will break down into multiple layers of desirability.
That's what happens to most simple binary divisions in IF language
design. :)
Kevin Forchione
> Here, Risujin <ris...@fastmail.fm> wrote:
>> But don't troll me about it. If you really feel everything is fine and
>> dandy, this thread is not for you--there's plenty of IF and IF languages
>> out there for your liking already.
>
> This part is flamebait.
Deja vu?
--Kevin
Peter Mattsson
> 5. Forget Processor Usage and Memory Consumption
> ------------------------------------------------
>
> Because a fast processor costs less than $100.
>
> And no, nobody cares if you want to run modern IF on your 1980s pile of
> junk, thats your problem. Run Zork like everyone else did in the 80s.
>
What about all the people who play IF on their PDAs? The ability to play
it on a PDA or mobile phone is, to my mind, one of IF's great strengths,
and it would be a shame to sacrifice that. Some of today's games are
already unplayable on a PDA (notably Wumpus 2000, which takes about a
minute per move) without making matters worse!
Peter
Kevin Forchione
news:dff4rg$n0t$1...@news.e7even.com...
The "nobody cares" is the real sticking point. Obviously the Interactive
Fiction Community *does* care, while perhaps the statement is true of the
non-playing world at large.
Every few years or so we seem to come across a third set of people....
people who for any number of reasons aren't satisfied with the current state
of affairs in the IF community and begin a zealous campaign for change.
Rather than building and developing their proposals, they first attempt to
persuade others that their ideas are right, but eventually they're going
around in circles trying to defend their ideas until they end up condemning
the community as a bunch of closed-minded anachronists.
But there are two truths in the IF community: the first is that there will
always be room enough for those who enjoy writing and playing any style of
Interactive Fiction -- though they may only have a fringe following; the
second is that in a very real sense, if you want to earn the respect of the
community you have to be one of its Implementers (i.e. you have to actually
create something, not just argue about the merits of your brand of
RAIF-POOL).
If you believe in it, build it, if you build it, they will come... and if
they don't come, well, you've at least proven your point to be true or
false.
--Kevin
Risujin
> On Sat, 03 Sep 2005 22:10:15 +0000, Risujin wrote:
>
> <snip - introducing a new paradigm for if>
Thanks for taking the time to read an overly long post and answering so
thoroughly. :)
> From an author's point of view, flexibility is often synonymous with ease
> of use. If I want my game to do something the author of the library didn't
> imagine it should not make it any harder than possible. ...
What I meant by sacrificing flexibility, is sacrificing having many
possible things to code to make the things which are coded more often
easier to write. This actually isn't such a picky point because you can
always provide maximum flexibility and also create shortcuts for common
things, but the common structures should have precedence in development.
> ... Say, for example,
> my PC is part of team, all of whom can communicate via radio at any time.
> I don't want to go with an ugly solution of:
>
>>switch radio to Sergeant Mayhem
>
> You change the radio to Sergeant Mayhem's frequency. It crackles with
> static.
>
>>ask radio about the bomb
>
> You speak into the radio.
>
> "There's a freaking BOMB there?!" screams Mayhem, "Get the hell out of
> there you fool!"
>
> ...
>
> Instead, I want the PC to be able to talk to his team members wherever
> they are, a la:
>
>>ask sergeant mayhem about the bomb
>
> ...
>
> By default this won't work as Mayhem is not in the same location. So I'm
> probably going to have to do some hairy parser hacking to get it to work.
> This is where flexibility is a virtue. If I can simply replace one
> function in the handling of AskVerb (its scope) then I'm going to spend a
> lot less time implementing this functionality.
Its a good thing you mentioned that. The easy over flexible paradigm is
all too easy to take to extremes. I would make the point a bit more mild
and say that making an easy to use language should be a high priority
during development, but that maximum flexibility is still a long term goal.
It doesn't take much thinking on the topic to realize what a bad idea it
is. The computer should never generate language from a generic
structure, it would never sound right (without a large amount of
specific work for each language--largely defeating the purpose).
There are a number of complications when implicit actions are added into
the mix. Its difficult to tell whether or not a particular
interpretation will work out or not unless you let the author's code
have a good look at it.
> <snip>
>
>>7. C Standard
>>-------------
>>
>>There is a reason why so many programming languages mimic C syntax. C
>>syntax has become the English of programming. By making up goofy new
>>language grammar (Array --> 1) for your new language, you're not making
>>it more "user friendly," you're shooting yourself in the foot.
>
> I find it kind of odd how you say a lot about high level languages and
> then suggest that C syntax is a good idea. Especially given that C isn't
> object oriented and IF does tend to be (in more than one sense).
>
> I don't think you should have to learn a new language to program IF.
>
> The language I'm using for my library is Python, which has several
> advantages. It's easy to learn, widely used, available (and often
> installed by default) for most platforms, and has an excellent standard
> library.
>
> There's a couple of ugly hacks needed to make it work as an IF language,
> but these will be handled by the library.
I wasn't referring to strict C, but more of the C-derived family of
languages. I wish I knew a better name for them but Im basically
referring to C/C++/Java/Perl style languages which have a lot of similar
syntax between them.
You will definitely have a hard time designing an easy to use language
out of C syntax alone. You must add language structures as needed (as
you mentioned, OOP) but there is no need to replace a lot of the basic
syntax (like using C style arrays: array[index] = value; rather than
Inform style).
> <snip>
>
>>Nor am I suggesting we scrap everything we already have, but rather that
>>we need a new direction for the further evolution and growth of IF (if
>>there's anyone interested in that...).
>
> (there is).
Good to know. :)
Post a link once your parser is ready for testing!
--
Risujin
ris...@fastmail.fm
Risujin
This is exactly what I meant, thanks for the clarification. :)
There is also other ways of getting around the puzzle design problems.
One example:
>PUSH BUTTON
Which button, the green button or the red button?
>RED
Its seems to be stuck!
>PUSH BUTTON
As you push the green button, the machine hums to life.
Here we don't assume that the player doesn't want to do things that he
could logically try, but doesn't know won't work. Once the player is
aware that it doesn't work, there is no need to keep it within the
disambiguation tree.
Depending on the circumstances, any on these methods could cause
problems. The author needs to have an intuitive but powerful way of
controlling the process.
--
Risujin
ris...@fastmail.fm
Mike Roberts
> Here we don't assume that the player doesn't want to do things that he
> could logically try, but doesn't know won't work. Once the player is aware
> that it doesn't work, there is no need to keep it within the
> disambiguation tree.
I've noticed that you seem to be spending a lot of time thinking about this
problem, so you might not be aware that it's been worked out in fair detail
in some of the existing systems. Check out, for example,
http://www.tads.org/howto/t3res.htm - see the "verification" stage in
particular.
--Mike
mjr underscore at hotmail dot com
Risujin
> "Peter Mattsson" <pe...@XYZZYmattssons.e7even.com> wrote in message
> news:dff4rg$n0t$1...@news.e7even.com...
>
>>Risujin wrote:
>>
>>>5. Forget Processor Usage and Memory Consumption
>>>------------------------------------------------
>>>
>>>Because a fast processor costs less than $100.
>>>
>>>And no, nobody cares if you want to run modern IF on your 1980s pile of
>>>junk, thats your problem. Run Zork like everyone else did in the 80s.
>>>
>>
>>What about all the people who play IF on their PDAs? The ability to play
>>it on a PDA or mobile phone is, to my mind, one of IF's great strengths,
>>and it would be a shame to sacrifice that. Some of today's games are
>>already unplayable on a PDA (notably Wumpus 2000, which takes about a
>>minute per move) without making matters worse!
>
> The "nobody cares" is the real sticking point. Obviously the Interactive
> Fiction Community *does* care, while perhaps the statement is true of the
> non-playing world at large.
The "nobody cares" is more style than substance, people care of course
and rightly so.
However, sorry to say, but PDAs are included. As for why I would promote
such heinous ignorance, allow me to explain.
My argument is that, we shouldn't constrain new software because some
people want to play IF on PDAs. The resulting new parser or language may
not run on older machines or portable computers but may be an
implementation of a creative new idea which may otherwise never see the
light of day.
When designing new technology with innovation in mind (parser or
language in this case), while moderate restrain is within reason, it
wouldn't be right to take it to an extreme. It may just be the case that
PDAs today simply don't have the processing power for a new, complex
parser, but it doesn't mean such a parser should not be developed.
> Every few years or so we seem to come across a third set of people....
> people who for any number of reasons aren't satisfied with the current state
> of affairs in the IF community and begin a zealous campaign for change.
> Rather than building and developing their proposals, they first attempt to
> persuade others that their ideas are right, but eventually they're going
> around in circles trying to defend their ideas until they end up condemning
> the community as a bunch of closed-minded anachronists.
Heh, I hope you're not talking about me. :)
I don't want to sound like I'm championing change, as I don't feel that
I am--that is, it's not my goal. It's more of an open proposal to
whoever may be interested. Mostly, I just wanted to get my own ideas
organized and air them out to others' opinions.
> But there are two truths in the IF community: the first is that there will
> always be room enough for those who enjoy writing and playing any style of
> Interactive Fiction -- though they may only have a fringe following; the
> second is that in a very real sense, if you want to earn the respect of the
> community you have to be one of its Implementers (i.e. you have to actually
> create something, not just argue about the merits of your brand of
> RAIF-POOL).
>
> If you believe in it, build it, if you build it, they will come... and if
> they don't come, well, you've at least proven your point to be true or
> false.
>
> --Kevin
Well it's not always that simple.
I intend to try and develop a language that would implement as many of
the ideas I outlined as is possible, but there are countless reasons for
why I may not be able to do so. It's a thin thread of hope, but even if
it turns out that I've got a lot to say and nothing to show for it, my
ideas might still spark some discussion in the IF community.
--
Risujin
ris...@fastmail.fm
James Mitchelhill
> Thanks for taking the time to read an overly long post and answering so
> thoroughly. :)
No thanks needed - I saved the post as a reminder of things to consider in
my own system. So, replying was useful to me as it helped me clarify a few
things in my design.
<snip>
> Its a good thing you mentioned that. The easy over flexible paradigm is
> all too easy to take to extremes. I would make the point a bit more mild
> and say that making an easy to use language should be a high priority
> during development, but that maximum flexibility is still a long term
> goal.
I see this in reverse (although I get the feeling we're talking about the
same thing, really). Flexibility is paramount, because it makes
implementing ease-of-use features much easier. Especially if you don't
necessarily know what features need to be included at the outset.
>> I'm not entirely certain if it's possible to write a description of a
>> language which could then plug into a general parser. I did briefly
>> look at this, but my head hurt.
>
> It doesn't take much thinking on the topic to realize what a bad idea it
> is. The computer should never generate language from a generic
> structure, it would never sound right (without a large amount of
> specific work for each language--largely defeating the purpose).
I was actually thinking about the parsing of the language rather than
responding in it. i.e. a general parser would take a description of
grammar structures in a language and would use this to parse the player's
input into a command. I'm sure it's possible, but I doubt it would be easy.
<snip my description of my parser design allowing for ambiguity and
multiple interpretation>
> There are a number of complications when implicit actions are added into
> the mix. Its difficult to tell whether or not a particular
> interpretation will work out or not unless you let the author's code
> have a good look at it.
I've thought about this and I don't think it's a major problem. The verb
has to generate an appropriate error message anyway, so it will understand
the situation well enough to generate an appropriate implicit action.
> Post a link once your parser is ready for testing!
I'm planning an initial alpha release once I have a a system that can
implement Cloak of Darkness.
It's nice to know I'm not working in a vacuum. :)
David Alex Lamb
Risujin <ris...@fastmail.fm> wrote:
>3. Spell Check
>--------------
>
>Spell checking algorithms have been around since the beginning of time,
>there is no reason why we can't implement one into the parser.
>
>The game knows what words are valid and what words are not. This is a
>small, limited dictionary from which most spelling mistakes can be
>easily disambiguated without the need to endlessly reprompt the player.
If you limit mistakes to the standard typographical errors
(insert/delete/replace one letter, or invert two adjacent letters), with a
not-too-long list of allowed words, it's pretty easy; the algorithm is about
30 years old. I suspect there may be better algorithms by now.
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/ qucis->cs to reply (it's a long story...)