When is enough enough?
J. Robinson Wheeler
As an IF author, do I really have to make sure every last "scrape parrot"
example is handled? When do I get to quit and say "Okay, I've trapped
enough peculiarities -- enough's enough," and move on to the next bit?
Or, better yet, call the game done?
Let me return to my rope problem one last time (actually, it's not a problem,
it's sort of a case-closed by now, which is the point of this post) as an
example. The code allows it to be generally tied to anything with a 'noun'
property, although in the game, you really only need to tie it to one
particular thing and then you don't need to carry it around any more.
In fact, the room where you tie it is found soon after the rope is found --
at least, if the player were doing a confident, efficient walkthrough. It
is occurring to me that there are a lot of players who will find the rope
and then carry it around all over the place, tying it to everything in
sight and perhaps getting weird responses. (At one point, a shaft of light
appeared, and naturally you were able to tie the rope to it. And when it
disappeared, the rope still claimed to be "(tied to the shaft of light)."
Sigghhhh.)
My other hangup, and this has made my code swell to probably twice the size
it need be, is that I feel compelled to put in decorative objects all over
the place just so that the parser recognizes the significant words of a
room's long description. I probably feel like this because I like to find
the game to be relatively "smart" about what it's describing when I'm playing.
At some point, though, it just gets tiring -- as does making sure every
last weird rope-tie-to case makes perfect, logical sense and won't mislead
the player into thinking it's got more game-uses than it really does, which
is only one.
This seems to be a judgment call for every IF author. Curses, for example,
makes sure to handle multiple uses of objects (where they fairly logically
could be used -- for example, opening the pill bottle, or whatever that was),
but doesn't give a fig about giving you the vocabulary to refer to things
that are in the ornate room descriptions, which can be frustrating. It
can also be something of a help, in that you know exactly what isn't any
use to solving the game. However, it also makes you assume that everything
that you can refer to is useful (which is not necessarily true, and sometimes
dreadfully misleading), because in Curses, some rooms did contain decorative
objects -- the parser knew them, but they had no real use, and there was no
puzzle to be solved by manipulating them. The lack of consistency in this
regard fooled me into thinking I was "stuck" when really there wasn't a
puzzle. Do you realize how much brainpower a player can apply to a non-
puzzle in an attempt to solve it? It gets rather frightening, actually.
I guess what I'm going for is that one at least has to keep up whatever
pattern that one establishes early on in the game, even if it's a pain
in the neck to code. Or -- is there a real point of diminishing returns,
and consistency can get stuffed after that point?
Thoughts?
Rob Wheeler - COMING SOON -
whe...@moontower.com "Working Title"
Will Grzanich
In article <wheeler.1...@newshost.cc.utexas.edu>,
whe...@moontower.com says...
>Let me return to my rope problem one last time (actually, it's not a
problem,
>it's sort of a case-closed by now, which is the point of this post) as
an
>example. The code allows it to be generally tied to anything with a
'noun'
>property, although in the game, you really only need to tie it to one
>particular thing and then you don't need to carry it around any more.
The rope problem seems to get to you...why not give the rope a property
which only allows it to be tied to a few things? Most players probably
won't get angry because you won't let them tie a rope to everything
vaguely post-like...
-Will
--
"All you need is love." | Check out my piece-o'-crap web page at
-John Lennon | http://www.cen.uiuc.edu/~grzanich!
| FDA approved!!
Linards Ticmanis
J. Robinson Wheeler wrote:
>
> As an IF author, do I really have to make sure every last "scrape parrot"
> example is handled? When do I get to quit and say "Okay, I've trapped
> enough peculiarities -- enough's enough," and move on to the next bit?
> Or, better yet, call the game done?
Well, being able to do odd stuff might be fun, though. I remember that
in "So Far" I tried to throw the box into the open hatch of the west
pillar while the weight was coming down (trying to crush it) and sadly
it didn't work, although the game, judging by its sheer size, probably
does quite a lot of by-work.
Often just giving a smart response indicating that you thought of the
possibility, but aren't going to allow it, might be a good idea.
--
Linards Ticmanis
The Master said, "The business of laying on the colors follows the
preparation of the plain ground."
FReDRiK RaMSBeRG (WILdcARD)
whe...@moontower.com (J. Robinson Wheeler) writes:
>As an IF author, do I really have to make sure every last "scrape parrot"
>example is handled? When do I get to quit and say "Okay, I've trapped
>enough peculiarities -- enough's enough," and move on to the next bit?
>Or, better yet, call the game done?
Start by coding the 'core', what is needed to play the game from start to end.
As you code it, you will probably come to think of numerous potential misuses.
If they are simple and you feel like it, code it right off. Otherwise, write it
down and get back to it when the core is done, or you just suddenly feel like
doing that kind of coding. When you are fairly sure that the major alternative
uses for things are covered, hand it to the beta-testers. If they are good,
they will uncover the last 99% of what players may want to do with your
objects...
It's the philosophy I use, and it works for me.
/Fredrik
--
Fredrik Ramsberg, d91f...@und.ida.liu.se, http://www-und.ida.liu.se/~d91frera
------------------------------------------------------------------------------
I want to make it perfectly clear that I can't say I don't think people who
aren't avoiding using too many negations aren't putting things clearly enough.
J. Robinson Wheeler
In Article <5finf8$8...@vixen.cso.uiuc.edu>, grza...@uiuc.edu (Will>>Let me return to my rope problem one last time...
>
>The rope problem seems to get to you...why not give the rope a property
>which only allows it to be tied to a few things? Most players probably
>won't get angry because you won't let them tie a rope to everything
>vaguely post-like...
The rope problem turns out to be a real test of an IF author's mettle,
moreso than I realized. Someone kindly pointed me to a web page full of
IF posts, and one of them was about the difficulty of rope problems, and
how one is generally better off not writing a rope into one's game.
Considering what was said in that article, I feel much better about my
solution and how well (so far) it seems to work. I also feel less
sheepish about bringing it up on this group so many times.
(It is mainly an excuse to post regularly, for a few weeks, before
my game is released -- a motive transparent to many, I'm sure.)
Rob Wheeler
whe...@moontower.com
Mary K. Kuhner
whe...@moontower.com (J. Robinson Wheeler) writes:
>As an IF author, do I really have to make sure every last "scrape parrot"
>example is handled? When do I get to quit and say "Okay, I've trapped
>enough peculiarities -- enough's enough," and move on to the next bit?
>Or, better yet, call the game done?
You have to balance the need to finish the game against that nasty lurch
the player will feel when s/he has a brilliant and apparently sensible
idea, and the game totally fails to cope with it. (I crashed one of the
competition games with "tie rope to me", a command that seemed quite
reasonable at the time.) Playtesters are probably the ones to tell
you if you're there yet.
>It is occurring to me that there are a lot of players who will find the rope
>and then carry it around all over the place, tying it to everything in
>sight and perhaps getting weird responses.
A rope is such a damnably useful object that it is natural for the
player to apply it willy-nilly, and it's really hard to see why "tie
rope to bedpost" should fail. I'd be inclined to try to part the player
from the rope ASAP, or else give the rope a second use. Objects which
seem really useful but only do one thing exasperate me as a player.
The classical answer to ropes is to use them to climb down and then be
unable to untie them, like the one in Sherbet. Or you could break them,
though even a bit of rope might be a pest.
>My other hangup, and this has made my code swell to probably twice the size
>it need be, is that I feel compelled to put in decorative objects all over
>the place just so that the parser recognizes the significant words of a
>room's long description. I probably feel like this because I like to find
>the game to be relatively "smart" about what it's describing when I'm playing.
I'm fairly happy with "You don't need to refer to that" which in Inform
is programmatically easy and doesn't need separate objects for each bit of
scenery. I really dislike a room full of scenery none of which is even
known to the parser; getting "I don't see any X here" repeatedly as I
try to find the one real object spoils the game illusion.
On the other hand, to my tastes movable bits of useless stuff stop being
desirable quite quickly. I don't want dishes, ashtrays, etc. as real
objects just because they'd be in the house. A couple of red herrings
is plenty. (I'm an implacable foe of inventory-management issues in
IF.)
>I guess what I'm going for is that one at least has to keep up whatever
>pattern that one establishes early on in the game, even if it's a pain
>in the neck to code. Or -- is there a real point of diminishing returns,
>and consistency can get stuffed after that point?
Most games I've played sluff a bit towards the end. Perhaps for related
reasons, most IF games are anticlimatic--the best material is near
the beginning. (Look at the XYXXY awards for "Best single puzzle.")
I think if one part has to be weak, the end is not the best choice,
though it's better than the beginning. (On the other hand, a lovely
first two rooms followed by an average game is likely to really
frustrate players, whose expectations by that point are impossibly
high; so lavishing everything on the beginning isn't a good answer either.)
From the player's point of view, of course, the answer is "Lavish detail
on everything." It's possible to have too many rooms or objects, but
I've never seen a game with too much detail work in programming
responses to actions. But then the game never gets finished. Sigh....
Mary Kuhner mkku...@genetics.washington.edu
Kathleen Fischer
Mary K. Kuhner wrote:
> I'm fairly happy with "You don't need to refer to that" which in
> Inform is programmatically easy and doesn't need separate objects for
> each bit of scenery. I really dislike a room full of scenery none of
> which is even known to the parser; getting "I don't see any X here"
> repeatedly as I try to find the one real object spoils the game
> illusion.
I don't like "You don't need to refer to that/That's just scenery" at
all. I want to know WHY I can't refer to it. I have created some base
classes in Inform to handle common reasons that an item can't be used.
One of my favorites is the faraway class. It's great for trees on
mountain sides and snow on the peaks and rivers in the valley. Just
make one of those objects and add all the faraway items in its name.
That way, when the player tries to get the snow it says "That's too far
away." and when you try to eat it it says "You can't reach that from
here.". If you try to examine it closely it says "That's too far away
to see clearly." something like that. Makes the world seem much bigger
at the cost of just one little object per room. Another useful class is
the clepto class. You know, when the user tries to swipe something from
the store that you don't want them taking, or tries to remove the ash
tray from the restraunt.
Anyway, a few such classes can really give you a lot of bang for your
programming buck :) I do try to keep the responses bland enough to
keep the player from thinking there is a puzzle there when there really
isn't. For example, it would be cruel to say "That's just out of reach"
which implies that it's something that could be fixed.
Kathleen
--
*******************************************************************
* Kathleen M. Fischer
* kfischer@x_greenhouse.llnl.gov (Remove the 'x_' before replying)
** "Don't stop to stomp ants while the elephants are stampeding" **
Julian Arnold
In article <wheeler.1...@newshost.cc.utexas.edu>, J. Robinson Wheeler
<URL:mailto:whe...@moontower.com> wrote:
>
> As an IF author, do I really have to make sure every last "scrape parrot"
> example is handled? When do I get to quit and say "Okay, I've trapped
> enough peculiarities -- enough's enough," and move on to the next bit?
> Or, better yet, call the game done?
That's up to you. Generally players like intelligent, witty,
individualized responses to everything they try, no matter how obscure,
otherwise they get frenzied about "broken mimesis." OTOH, a game I'm
writing from time to time is deliberately sparse in this respect. It's
based around a series of obvious puzzles (in that their existence is
obvious, but not necessarily their solutions), and basically only those
objects vital to the puzzles, and a few scenery objects, are fully
implemented. All else is sketched in. There is still a definite
story/plot to the game.
For other games though, I would try to allow for all that sillyness.
> Let me return to my rope problem one last time (actually, it's not a problem,
> it's sort of a case-closed by now, which is the point of this post) as an
> example. The code allows it to be generally tied to anything with a 'noun'
> property, although in the game, you really only need to tie it to one
> particular thing and then you don't need to carry it around any more.
>
> In fact, the room where you tie it is found soon after the rope is found --
> at least, if the player were doing a confident, efficient walkthrough. It
> is occurring to me that there are a lot of players who will find the rope
> and then carry it around all over the place, tying it to everything in
> sight and perhaps getting weird responses. (At one point, a shaft of light
> appeared, and naturally you were able to tie the rope to it. And when it
> disappeared, the rope still claimed to be "(tied to the shaft of light)."
> Sigghhhh.)
Put in a check that will only allow the rope to be tied to specific
objects (ISTR you're using Inform):
before [;
Tie:
if (second has tieable) {
print "You tie the rope to ", (the) second, ".^";
[...rope tying code...]
return false;
}
else
"You can't tie the rope to that.";
],
> My other hangup, and this has made my code swell to probably twice the size
> it need be, is that I feel compelled to put in decorative objects all over
> the place just so that the parser recognizes the significant words of a
> room's long description. I probably feel like this because I like to find
> the game to be relatively "smart" about what it's describing when I'm playing.
Well, you could use the "You don't need to refer to that" trick.
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me
from ever completing anything." -- Herman Melville, "Moby Dick"
Adam Cadre
Mary K. Kuhner wrote:
>
> On the other hand, to my tastes movable bits of useless stuff stop
> being desirable quite quickly. I don't want dishes, ashtrays, etc.
> as real objects just because they'd be in the house. A couple of red
> herrings is plenty.
See, I'm just the opposite. I've never liked the fact that in a lot
of IF you end up grabbing everything in sight because you know that
if it weren't useful at some point it wouldn't have been implemented.
That's why I made sure 90% of the objects in "I-0" had no use other
than to make players laugh when they examined them, and made the game
perfectly "winnable" without carrying around a single thing.
-----
Adam Cadre, Durham, NC
http://www.duke.edu/~adamc
Aapo Haapanen
Will Grzanich <grza...@uiuc.edu> wrote:
: The rope problem seems to get to you...why not give the rope a property
: vaguely post-like...
I would get angry. I like to tie ropes to everything.
Matthew T. Russotto
In article <wheeler.1...@newshost.cc.utexas.edu>,
J. Robinson Wheeler <whe...@moontower.com> wrote:
}In Article <5finf8$8...@vixen.cso.uiuc.edu>, grza...@uiuc.edu (Will
}Grzanich) wrote:
}>In article <wheeler.1...@newshost.cc.utexas.edu>,
}>whe...@moontower.com says...
}>
}>
}>The rope problem seems to get to you...why not give the rope a property
}>which only allows it to be tied to a few things? Most players probably
}>won't get angry because you won't let them tie a rope to everything
}>vaguely post-like...
}
}
}moreso than I realized. Someone kindly pointed me to a web page full of
}IF posts, and one of them was about the difficulty of rope problems, and
}how one is generally better off not writing a rope into one's game.
Yes. The fact that the rope in Sherbet worked well was a big tipoff
that the author was an experienced IF writer (though I'm afraid I
didn't make the leap to "Graham Nelson"... then again, I used
brute-force guessing to solve the "Marie Swelldon" puzzle, so I guess
I'm just not any good at anagrams).
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Gerry Kevin Wilson
Someone wrote this, and I'm jiggered if I know who:
}The rope problem turns out to be a real test of an IF author's mettle,
}moreso than I realized. Someone kindly pointed me to a web page full of
}IF posts, and one of them was about the difficulty of rope problems, and
}how one is generally better off not writing a rope into one's game.
I know I've written something like that in the past. Don't remember if I
ever posted it up anywhere. If I recall, it was more a caution against
multi-purpose items than rope specifically. ("Oh look, a can of kerosene.
I wonder if I can burn that white house down...") Exponential growth
being a hassle and all that.
Of course, you could try to implement everything in your game and join me
in the land of vaporware. Yes, that's it Luke, feel the pull of the dark
side. Yes, Luke, I am your cousin's accountant's brother's bookie.
<Sounds of someone breathing through a coffee filter.>
Lots of detail makes for a long development time. If you find youself
wondering just how to program tying different knots into a piece of yarn,
it's probably time to finish the game and push it out the door.
"This brief bout of silliness brought to you by a man who has no idea what
he's talking about."
--
My new email address is: whiz...@pobox.com.
If that's too long for you, try g...@pobox.com.
David Glasser
In article <wheeler.1...@newshost.cc.utexas.edu>,
whe...@moontower.com (J. Robinson Wheeler) wrote:
> This seems to be a judgment call for every IF author. Curses, for example,
> makes sure to handle multiple uses of objects (where they fairly logically
> could be used -- for example, opening the pill bottle, or whatever that was),
> but doesn't give a fig
Sure it does. Right in the Maiden card.
> about giving you the vocabulary to refer to things
> that are in the ornate room descriptions, which can be frustrating.
>
> Thoughts?
>
>
>
> Rob Wheeler - COMING SOON -
> whe...@moontower.com "Working Title"
dsgl...@hotmail.com
http://www.geocities.com/SoHo/6028/
J. Robinson Wheeler
Mary K. Kuhner <mkku...@phylo.genetics.washington.edu> wrote:
>Most games I've played sluff a bit towards the end. Perhaps for related
>reasons, most IF games are anticlimatic--the best material is near
>the beginning. (Look at the XYXXY awards for "Best single puzzle.")
>I think if one part has to be weak, the end is not the best choice,
>though it's better than the beginning. (On the other hand, a lovely
>first two rooms followed by an average game is likely to really
>frustrate players, whose expectations by that point are impossibly
>high; so lavishing everything on the beginning isn't a good answer either.)
>
>From the player's point of view, of course, the answer is "Lavish detail
>on everything." It's possible to have too many rooms or objects, but
>I've never seen a game with too much detail work in programming
>responses to actions. But then the game never gets finished. Sigh....
I think one of the things that has helped me keep a consistent amount
of detail that doesn't slough as the game (writing) progresses is that
I took a year off after writing 2/3ds of the code. When I came back
to it, I noticed that I'd started sloughing off and (with renewed vigor)
put in all the details I'd omitted.
--
I am curious, though, about how my game will fare on your first point:
will it be anticlimactic? I think, actually, that the best thing about
my game is that it's fairly nicely plotted, and has a definite beginning
and ending, and one large goal that stretches through the whole thing
(and is finally completed at the resolution of the story). The middle
is somewhat less defined, with puzzles that can be completed in basically
any order, once discovered, and my big fear is that players will lose
sense of the overall mission (or even be unable to see the point of
completing the middle tasks).
--
I planned the story and puzzles before I started following this newsgroup
regularly. One of the first things that this group did was open my eyes
to IF cliches that I'd put into my game, and conventional wisdom was quite
clear on what people liked to play and what they were bored with. I was
partly taken aback and partly emboldened to push ahead with my game
anyway, figuring that though it had cliches, it had its merits, too.
I compromised on a couple of issues rather than completely rewriting or
reinventing what I'd plotted. After a while, I rationalized this by
saying, "Hey -- if it's my first game, I have some license to get stuff
out of my system." Which is to say, most first-time IF authors have
had ten years or more of experience playing IF, loving IF, and coming
up with various ideas for IF. Some of them go back pretty far, but
are the first to rise to the surface when one sits down to "finally
write one."
I apologize for putting a maze into my game, but for the above reason
I felt like I had to keep it in there. Can't I at least write ONE game
with a maze in it? (Yes, I answered myself -- so long as you don't do
it again, unless in a frighteningly original way.) My compromise was
to put an object in the game that will lead you through the maze in
ten easy steps, and the object will let you know that it can do this
if you're holding it when you encounter the maze.
Which brings up the second point, which is about red herring objects.
One of my favorite puzzles is a deliberately cornucopic assortment of
red herrings, in among which are some useful items. I began to think
recently that this was going to be one of the most infuriating parts of
the game rather than one of the more delightful parts (which is what
I wanted it to be). My compromise was to put an object in the game
that knows how to tell a red herring from a useful obejct -- breaking,
to some extent, the "fourth wall" in a way that the game doesn't do
at any other point. However, I found a reasonable way to introduce
it, I think, that explains the inconsistency.
Now the puzzle will be: can the player figure out where to find and
how to use these objects -- and will they find them at the right point
in the story to keep the momentum going?
I have more to say about this, and about the story plotting, but it'd
spoil a game that hasn't been played yet, so I guess I'll shut up.
--
I hope I can finish this thing soon. I'm more interested in talking
about issues of writing it than it having people play it and tell me
whether they liked it or not. That is to say, I'm interested in having
other if-authors play it and talk about what they liked about it
in terms of if-authorship, rather than as if-players.
Which is why it seems amazing to me that this newsgroup exists at all.
What a good thing, isn't it?
- COMING SOON -
Rob Wheeler A new TADS adventure
whe...@moontower.com pretty good for a first
time IF author
John Wood
whiz...@uclink.berkeley.edu (Gerry Kevin Wilson) writes:
> I know I've written something like that in the past. Don't remember if I
> ever posted it up anywhere. If I recall, it was more a caution against
> multi-purpose items than rope specifically. ("Oh look, a can of kerosene.
> I wonder if I can burn that white house down...") Exponential growth
> being a hassle and all that.
Yup, Whizzard's Guide. Ropes and zippo lighters ("The cat burns feebly for
a moment, then flickers out") specifically, but also:
> Avoid using general purpose tools to solve puzzles like axes, explosives,
> and other stuff, like sledgehammers. These devices have so many uses
> that you will bog yourself down trying to cover them all. If you try to
> do a cop-out, and don't allow the player to say, beat down a locked door
> with a sledgehammer, you'll just annoy the player, so don't do it.
Which is good advice that I'm (partly) ignoring in my chapter of the Silly
Game... 8-P
John