Comp 2003 Tips for First-Time Entrants

12 views
Skip to first unread message

Jessica Knoch

unread,
May 4, 2003, 11:30:01 PM5/4/03
to
While the topic of "Amateur Annoyances" has come up, I thought I'd
mention my "IF Comp Primer" with 10 tips for authors of games for
the Annual Competition. It's geared mostly for first-time
entrants, although comments are welcomed from all. The article is
also found on my website at
http://www.strangebreezes.com/if/writings/compguide.htm

Note that these tips are specifically designed for increasing
your score in the comp; therefore, they are aimed at people
who want their score to be as high as possible. Keep that
in mind.

The distilled and condensed wisdom of numerous experienced
Interactive Fiction players, authors, comp entrants, and judges is
now available for all prospective Comp authors. If your goal is to
score well, place high in the competition, or just to have people
like and respect your work, then follow these suggestions. An
ultra-condensed "top ten" comes first, followed by thorough
explanations for those interested.

Rule One: Do not put mazes into competition games.

Rule Two: Competition judges are neither patient, forgiving, nor
thorough.

Rule Three: Do not impose an inventory limit for its own sake.

Rule Four: Do not include hunger or sleep puzzles.

Rule Five: Check your spelling. Check it again.

Rule Six: Hints are preferred. Walkthroughs are mandatory.

Rule Seven: Get beta-testers. Listen to them.

Rule Eight: Make sure the game can be finished in two hours.

Rule Nine: Do not include lots of empty locations.

Rule Ten: Do not put mazes into competition games.

And now, for more detail.

Rule One: Do not put mazes into competition games.

Why, you ask? They are tedious and not-fun. You will hear people
say, "Don't put in a maze unless it's really original and clever."
How clever does it have to be? To quote J. Robinson Wheeler, "If
you're going to put a maze into a Comp game, it had better be so
damn clever that you win a Best Puzzle XYZZY Award the following
spring. In other words, you have to be more clever than Andrew
Plotkin, because he already did it once and the bar is that much
higher." Trust me, you are better off leaving the maze out
completely.

If you must have a maze, if you really desire to program one, do
yourself a favor and put it in another game to be released outside
of the Comp. If your entry includes a maze, it will be marked
down. Ask yourself if your game is so good, so amazingly
wonderful, that it will score highly in spite of the maze. Ask
yourself if you'd like to make the whole competition thing as easy
and painless on yourself as possible, and if the answer is yes, you
will be better off without the maze. There is no reason to let
your game's score suffer because of a maze.

Rule Two: Competition judges are neither patient, forgiving, nor
thorough.

It's very important to avoid tedium in a Comp game. The easier you
make things for the judges, the higher your score will be. If a
judge is turned off by something in the first few minutes, it's
possible that they'll quit there and never come back to it, and
score the game only on the part they saw (which they didn't like!).
If you want to be sure judges see something you did which you
thought clever, mention it in an "about" text or in the help menu.

Rule Three: Do not impose an inventory limit for its own sake.

If possible, get rid of the inventory limit altogether. If your
game is more simulationist and you want a more "realistic"
approach, the best way to do this is to not have very many objects
in the game. If you include a "rucksack" object, one that stores
other objects to relieve the player's inventory, be sure that all
of the objects in the game fit in it. Also, if you must have an
inventory limit, be sure you make it clear to the player which
objects won't be necessary (perhaps by not allowing them to pick
the item up).

Ask yourself why you have an inventory limit in the first place.
If you want to make it part of a puzzle, such as not being too
loaded down when crossing a rickety bridge, then just do that, and
let the player carry around whatever he wants the rest of the time.
No one will mind if you let the player carry every single object in
the game, unless you're trying to have a realistic or simulationist
game.

Rule Four: Do not include hunger or sleep puzzles.

Unlike the inventory limit, which can be included when the proper
steps are taken, hunger and sleep puzzles have no place in modern
IF. Even if your game recreates the feel of "classic" IF, the
timed puzzles that require a player to eat or sleep (or use the
bathroom) every so often are better left out entirely. If they are
not easily solved, they are annoying and tedious. If they are
easily solved, they become pointless and even more annoying. Your
game will be docked for having puzzles like these. It's not worth
it. [If, on the other hand, your game revolves solely around
getting something to eat, well, my only suggestion is to have
reminders without actually killing the player. And good luck,
since you'll probably need it.]

Rule Five: Check your spelling. Check it again.

Even a wonderful, fun, original, and clever game will annoy and
disappoint if it is riddled with spelling or grammar mistakes. If
you are a capable speller, pay attention to the details and read
carefully through your own text and your beta-testers' transcripts.
If you aren't a good speller, find someone who is and let them read
a transcript, or use some kind of spell-checking program (in
Inform, compile with the -r switch to generate a game-text output
file as it compiles). It is worth a little extra time to avoid
typos.

Rule Six: Hints are preferred. Walkthroughs are mandatory.

As an author, surely you want the judges to play all the way
through the game you wrote. You want them to read your text, see
your objects and locations, and get to the end of the game. The
best way to make sure this happens, while preserving as much fun
and discovery for the player as possible, is to write hints.
Careful, thoughtful, and gentle hints, but most of all, HELPFUL
hints. Never insult a player who wants a hint: he is just trying
to play your game. This includes suggesting that the player
shouldn't need hints! Just make the hints available, whether in
game or as a separate file, and give the player the opportunity to
finish your game. Also, have the hints beta-tested along with
everything else. Testers can tell you what sorts of hints would be
most helpful.

Sure, you say, but hints take a long time, and I'm too busy taking
out the maze and checking my spelling. All right, no problem.
Hints are the best choice, but they are not the only choice. A
walkthrough is another thing you can supply judges with to enable
them to finish the game (of course, hints and a walkthrough both
are best!). Do not make your walkthrough in the form of a game
transcript, or else many judges won't see much point in continuing
to play when they can just read. Do make sure your walkthrough
works with the version of the game you enter! Play it through
yourself, using exactly the commands from your walkthrough, and
make sure you get the ending you want.

Finally, consider allowing your walkthrough to show the player the
best possible ending. That's the ending that's the most fun, and
most satisfying, and will probably earn your game the best score
from the judges. If you want a high score, this is probably the
way to go.

Rule Seven: Get beta-testers. Listen to them.

For your game to be its best, you absolutely must get an
experienced IF player to play through your game and offer her
comments. For best results, get three or more to assure different
styles of play and approaches. Even more important than getting
other people to play your game is listening to them and
implementing their suggestions. That means, if your tester says "I
tried to do something with this item and it didn't work," you
should add something to your game to take that into account, even
if it's just a customized response. Just explaining to them why
they can't do it isn't going to help! Change your game, and your
game will be better. Then it's off for another round of testing...

Rule Eight: Make sure the game can be finished in two hours.

One of the rules of the IF Comp is that judges must rate your game
based *only* on the first two hours of play. Ignore this rule at
your peril. Ask one of your beta-testers to see how far he can get
in two hours the first time he plays it, as a guide. There are
judges who grade down especially if they don't finish your game in
two hours, so err on the side of caution. If it only takes a judge
one hour to finish your game, that gives them plenty of time to go
back, try new things, explore your world, try your list of
"amusing" things to do, and other fun stuff.

Rule Nine: Do not include lots of empty locations.

Part of making sure the game can be finished in two hours is
cutting down on the number of locations in your game. If you have
drawn a map of your game, examine it carefully for extra locations.
If you can streamline the map, so much the better. If locations
exist just to add space between places (such as paths, staircases,
roads), see if you can remove them and just connect the two
locations on either end directly.

Rule Ten: Do not put mazes into competition games.

Seriously.

--
Jess K., remove the invalid part from my email address to send
mail.


Al

unread,
May 5, 2003, 9:29:27 AM5/5/03
to
> Jessica Knoch wrote:
>
> Rule Six: Hints are preferred. Walkthroughs are mandatory.
>

What about just supplying hints. And BTW I noticed that in most
of the Comps past that walkthrus were only included on some of the
games NOT all of them. I guess the authors wanted the players of the
game to figure it out themselves.

Just asking about this. A lot of judges who MAY be in hurry to get
thru the game will just use the walkthru with the script feature on
and not really "play" the game.


Ricardo SIGNES

unread,
May 5, 2003, 10:00:30 AM5/5/03
to
In article <3EB66736...@qadas.com>, Al wrote:
> Just asking about this. A lot of judges who MAY be in hurry to get
> thru the game will just use the walkthru with the script feature on
> and not really "play" the game.

Serious judges will not do this. If a judge is so lazy as to play like this,
supplying a walkthrough will only free them to judge badly for a different
reason. Do not use this argument to avoid providing a walkthrough.

--
rjbs

Al

unread,
May 5, 2003, 10:42:18 AM5/5/03
to
Ricardo SIGNES wrote:

>
>
> Serious judges will not do this. If a judge is so lazy as to play like this,
> supplying a walkthrough will only free them to judge badly for a different
> reason. Do not use this argument to avoid providing a walkthrough.
>
>

OK I'll supply a walkthru with the game that the player with have to use the
help menu to access. How about hints are they really necessary. The game
isn't that hard but the Commercial versn will be. Much harder and the
disk will have the complete walkthru and hints on it as well.

Al

Michael Coyne

unread,
May 5, 2003, 11:16:47 AM5/5/03
to

It's always nice to have hints, especially if you doubt the judges will
get through your game in time.

I would say use the feedback from your beta testers to decide if you
want hints or not. If all your beta testers talk about the game being
difficult, you might want to include some hints.


Michael

Ricardo SIGNES

unread,
May 5, 2003, 11:14:31 AM5/5/03
to

Hints are great, and I have my own little theories about good hints. I think
you can do without them for a comp game. Of course, including hints in a later
release would be nice.

--
rjbs

Neil Cerutti

unread,
May 5, 2003, 11:20:10 AM5/5/03
to
In article <ZUkta.10856$hT2.4...@news2.news.adelphia.net>,

Jessica Knoch wrote:
> Rule One: Do not put mazes into competition games.
>
> Why, you ask? They are tedious and not-fun. You will hear
> people say, "Don't put in a maze unless it's really original
> and clever." How clever does it have to be? To quote J.
> Robinson Wheeler, "If you're going to put a maze into a Comp
> game, it had better be so damn clever that you win a Best
> Puzzle XYZZY Award the following spring. In other words, you
> have to be more clever than Andrew Plotkin, because he already
> did it once and the bar is that much higher." Trust me, you
> are better off leaving the maze out completely.

And even then, there will be people that hate your maze anyway.


--
Neil Cerutti

Jessica Knoch

unread,
May 5, 2003, 11:53:04 AM5/5/03
to
"Al" wrote...

> OK I'll supply a walkthru with the game that the player with have to use
the
> help menu to access. How about hints are they really necessary. The game
> isn't that hard but the Commercial versn will be. Much harder and the
> disk will have the complete walkthru and hints on it as well.

I for one am a huge fan of hints for 95% of all games. Of course, there are
good sets of hints and then there are REALLY good sets of hints. The best
hints I've ever seen were Earth and Sky 2, from Comp 2002. Somehow,
they managed to lead me to the solution and make me feel like I had
solved the puzzle mostly on my own.

But this is another area where having a variety of beta-testers comes in
handy. Although you may think "the game isn't that hard," there are bound
to be players (and judges, if it's a Comp game) who disagree or are stuck
somewhere.

--
Jess K.


Jon Ingold

unread,
May 5, 2003, 12:31:22 PM5/5/03
to
> Hints are great, and I have my own little theories about good hints. I
think
> you can do without them for a comp game. Of course, including hints in a
later
> release would be nice.

A good comp game doesn't have hints, I always thought, but rather Good
Design.

Not sure anyone's ever written a "good" comp game by that standard, however,
myself included.

Jon


Kathleen Fischer

unread,
May 5, 2003, 12:38:00 PM5/5/03
to
"Michael Coyne" <coy...@mbDOT.sympaticoDOT.ca> wrote in message
news:_bvta.7640$NC4....@news1.mts.net

> It's always nice to have hints, especially if you doubt the judges
> will get through your game in time.

As a player, I prefer hints to walkthru's. Depending on the order you
progress through a game (assuming it's not on rails), then just FINDING
the right spot in the walkthru to get you over a rough area could
ruin great chunks of the game. Of course, entering a monsterous game
figuring the player can just use the walkthru to finish in 2 hours,
is probably a Bad Idea.

As an author, my two biggest gripes about INCLUDING hints/walkthrus are:

(1) Without player requests for hints/help, it's hard to know what areas
of your game succeeded/failed, what things worked and what things
should never, ever, be repeated again. Particularly because:

(2) Requests for help/hints is just about the only time I hear from
players - pro or con. Supplying a walkthru eliminates that, and thus,
while players might be "happier", the author get the long and
lonely sound of silence. Kinda hard to improve one's self that way.

... of course, remember that the original post was "How to get the
highest score possible", and I think she's pretty much right. If getting
the highest score possible isn't your overriding concern, then by
all means, throw in the maze and delete the hints/walkthru. Just don't
act surprised when players lob 3's at you. :)

> I would say use the feedback from your beta testers to decide if you
> want hints or not. If all your beta testers talk about the game being
> difficult, you might want to include some hints.

I would say if even one tester has a problem, you might want to include
some hints, even if only the subtle, in game sorts that would gently
lead the player to think "the right throughts".

Kathleen (just my $0.02)

-- Inevitable -
http://www.ifarchive.org/if-archive/games/zcode/Inevita.z5
-- and Masquerade (Comp00)(Mask.z5) and The Cove (ArtShow00)(Cove.z5)
-- Prized Possession (Comp01) .../games/competition2001/inform/possess
-- Coming soon: Redemption (ArtShow03)
-- Excuse me while I dance a little jig of despair


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Quintin Stone

unread,
May 5, 2003, 1:00:03 PM5/5/03
to
On Mon, 5 May 2003, Jon Ingold wrote:

> A good comp game doesn't have hints, I always thought, but rather Good
> Design.

Puzzleless IF rarely requires hints. Otherwise, you're going to come
across SOMEONE who needs them.

/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/

Kathleen Fischer

unread,
May 5, 2003, 1:15:24 PM5/5/03
to
"Jon Ingold" <jonnyingoldT...@netscape.netANDTHIS> wrote in
message news:b963ku$qfb$1...@newsg1.svr.pol.co.uk

> A good comp game doesn't have hints, I always thought, but rather Good
> Design.

A good comp game is like a good receipe - no matter how tasty it is,
there's always going to be someone who wants less salt, more butter,
and almonds instead of peanuts. :)

Actually, I agree with you in the case of a *story* comp game, a good
design should eliminate the need for hints. I don't think that applies
to the puzzle comp games.

Kathleen

Jon Ingold

unread,
May 5, 2003, 1:59:08 PM5/5/03
to
> Actually, I agree with you in the case of a *story* comp game, a good
> design should eliminate the need for hints. I don't think that applies
> to the puzzle comp games.

Well, in a good puzzle comp game, the player shouldn't feel the need to use
hints. He should ideally feel he's just a *smidgeon* away from a solution,
and continue plugging away just that little bit longer.

Jon


Jessica Knoch

unread,
May 5, 2003, 2:13:37 PM5/5/03
to
"Jon Ingold" wrote...

Ideally, yes... but when the two-hour limit is looming, judges feel less and
less like plugging away. Your theory is works great with the Mulldoon
Legacy though, which I am playing out-of-Comp.

--
Jess K.


Andrew Plotkin

unread,
May 5, 2003, 2:24:17 PM5/5/03
to
Here, Neil Cerutti <hor...@yahoo.com> wrote:
> In article <ZUkta.10856$hT2.4...@news2.news.adelphia.net>,
> Jessica Knoch wrote:
>> Rule One: Do not put mazes into competition games.
>>
>> Why, you ask? They are tedious and not-fun. You will hear
>> people say, "Don't put in a maze unless it's really original
>> and clever." How clever does it have to be? To quote J.
>> Robinson Wheeler, "If you're going to put a maze into a Comp
>> game, it had better be so damn clever that you win a Best
>> Puzzle XYZZY Award the following spring. In other words, you
>> have to be more clever than Andrew Plotkin, because he already
>> did it once and the bar is that much higher."

> And even then, there will be people that hate your maze anyway.

Note that even though _Hunter_ won that "best puzzle" award, it made
no better than eighth place in the IFComp standings. Many people said
specifically that the maze area turned them off, and lowered their
score for the game.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

Andrew Plotkin

unread,
May 5, 2003, 2:28:42 PM5/5/03
to
Here, Ricardo SIGNES <rjbs-...@public.manxome.org> wrote:
> In article <3EB66736...@qadas.com>, Al wrote:
>> Just asking about this. A lot of judges who MAY be in hurry to get
>> thru the game will just use the walkthru with the script feature on
>> and not really "play" the game.

> Serious judges will not do this. If a judge is so lazy as to play
> like this, supplying a walkthrough will only free them to judge
> badly for a different reason.

There is no requirement in the IFComp rules that judges be "serious"
(as you define it). And judging "badly" contributes to the game scores
just the same.

People sometimes play from the walkthrough. It happens in the IFComp
and it happens outside it. You can decide to take these people into
account or you can decide not to let them influence you.

Andrew Plotkin

unread,
May 5, 2003, 2:41:09 PM5/5/03
to
Here, Jessica Knoch <jessicakn...@mindspring.com> wrote:

> Note that these tips are specifically designed for increasing
> your score in the comp; therefore, they are aimed at people
> who want their score to be as high as possible. Keep that
> in mind.

I'm going to disagree somewhat. Most of your tips are valid for *all*
adventure games, no matter where they're released.

I will note exceptions as I go. :)

> Rule One: Do not put mazes into competition games.

> If you must have a maze, if you really desire to program one, do


> yourself a favor and put it in another game to be released outside
> of the Comp.

It's hardly doing yourself a favor... players are no more tolerant of
mazes in general-release games. You won't see a numeric markdown
outside of the IFComp, but that doesn't mean your players are happier.

(There is one distinction: IFComp games are not discussed before
voting. In a non-comp game (or a comp game after the comp is over),
word may get around that your maze puzzle *is* unusually clever. That
may make people less likely to jettison the game at the first whiff of
maziness. Or, on the other hand, it may not.)

> Rule Two: Competition judges are neither patient, forgiving, nor
> thorough.

And neither is anyone else.

> Rule Three: Do not impose an inventory limit for its own sake.
> Rule Four: Do not include hunger or sleep puzzles.
> Rule Five: Check your spelling. Check it again.

All just as true outside the IFComp.

> Rule Six: Hints are preferred. Walkthroughs are mandatory.

This *is* one way in which the IFComp is unique. Comp judges have a
two-hour deadline (in one sense), a six-week deadline (in another
sense), and three-four dozen games staring them in the face. Patience
becomes a highly rationed commodity.

> Rule Seven: Get beta-testers. Listen to them.

Anyone who releases a game already has this branded on their forehead.
If you don't, I've got the hot iron right here. Trust me. It won't
hurt a bit.

> Rule Eight: Make sure the game can be finished in two hours.

IFComp-specific, obviously.

> Rule Nine: Do not include lots of empty locations.

Important for everybody.

> Rule Ten: Do not put mazes into competition games.

See above.

Al

unread,
May 5, 2003, 3:06:27 PM5/5/03
to
Kathleen Fischer wrote:

> "
>
> As an author, my two biggest gripes about INCLUDING hints/walkthrus are:
>
> (1) Without player requests for hints/help, it's hard to know what areas
> of your game succeeded/failed, what things worked and what things
> should never, ever, be repeated again. Particularly because:
>
> (2) Requests for help/hints is just about the only time I hear from
> players - pro or con. Supplying a walkthru eliminates that, and thus,
> while players might be "happier", the author get the long and
> lonely sound of silence. Kinda hard to improve one's self that way.
>
> .

This now begs the question:
should your beta-testers have hints and a walkthru or should they
contact you when they get in trouble?

My understanding that beta-testing is MAINLY to get the bugs
out of the game.

You want input frm your testers as well on the aesthetics of the game
but shouldn't that be after the wringing out of trhe game has occured?

Michael Coyne

unread,
May 5, 2003, 3:22:28 PM5/5/03
to
Al wrote:

> This now begs the question:
> should your beta-testers have hints and a walkthru or should they
> contact you when they get in trouble?
>
> My understanding that beta-testing is MAINLY to get the bugs
> out of the game.
>
> You want input frm your testers as well on the aesthetics of the game
> but shouldn't that be after the wringing out of trhe game has occured?

My advice is take whatever suggestions your beta-testers are willing to
offer you. If they comment on the aesthetics of the game, then it means
whatever's in there now didn't work for them, so it should probably be
fixed.

Also, if games are written badly enough, it's sometimes difficult to
distinguish bugs from poor puzzle design, poor aesthetics, insipid
descriptions and so on.

If a puzzle is completely "bug-free", but no beta-testers can figure it
out because the objects in question are described poorly or
incompletely, that, arguably, turns it into a bug.

Bottom line: it's never too early to fix any part of the game that the
beta-testers think needs a little work.


Michael

Jon Ingold

unread,
May 5, 2003, 3:23:16 PM5/5/03
to
> > Well, in a good puzzle comp game, the player shouldn't feel the need to
> use
> > hints. He should ideally feel he's just a *smidgeon* away from a
solution,
> > and continue plugging away just that little bit longer.
> Ideally, yes... but when the two-hour limit is looming, judges feel less
and
> less like plugging away.

Hmm. Okay then, maybe Good Design in this context involves easy puzzles (to
snare the player's interest and coddle his ego a bit), a few tricky puzzles
in the middle (to show that you, the author, are in fact a genius), and then
some easy puzzles again at the end (because the judges, however much
adulation they may be feeling, are nearing the end of their allotted time).

This would be opposed to the classic game structure, which is pure
graduating difficulty, until you finish with whatever the text-game
equivalent is of the damn one-touch-kills-four-hundred-ammo-rounds
spider-thing from the end of Tomb Raider III.

(Not that any large puzzle games *do* finish that way. I forget how So Far
ends; Curses is quite gentle come the master game; Zork III's endgame as I
recall just doesn't make a lot of sense; Leather Goddess' was a bit of a let
down; Hitch-hiker's ... oh, the final puzzles were fairly hard I suppose
(Marvin's door and all); Sorcerer I can't remember either; Spellbreaker I
never finished... never mind, I've forgotten my point).

Jon


Papillon

unread,
May 5, 2003, 3:34:32 PM5/5/03
to
Al <rad...@qadas.com> wrote:


>This now begs the question:
>should your beta-testers have hints and a walkthru or should they
>contact you when they get in trouble?
>
>My understanding that beta-testing is MAINLY to get the bugs
>out of the game.

If you're lucky enough to have a loyal beta-tester who's willing to put in
the time for more than one go at a game, NOT giving them hints is more
important. You definitely want to know what they thought was going on at
each stage of the game, what they thought they needed to do, where they get
stuck, where they thought they should be able to do X in order to solve Y...
so that you can add content and subtle hints for redirection.

Your player is only 'fresh' once! After you've given them the walkthrough,
they'll never go back to not knowing the answers again. At *that* point you
want them to plug away at every little corner of the game, searching for
bugs, plot inconsistencies, etc. But that little player's-eye view of your
game world is incredibly valuable. :)

If you're in a desperate rush and just need to be sure your game's playable
and you've only got a few hours of one tester's time, then maybe a
walkthrough would be useful...

Jessica Knoch

unread,
May 5, 2003, 4:20:50 PM5/5/03
to
"Jon Ingold" wrote...
>
<snip>

>
> (Not that any large puzzle games *do* finish that way. I forget how So Far
> ends; Curses is quite gentle come the master game; Zork III's endgame as I
> recall just doesn't make a lot of sense; Leather Goddess' was a bit of a
let
> down; Hitch-hiker's ... oh, the final puzzles were fairly hard I suppose
> (Marvin's door and all); Sorcerer I can't remember either; Spellbreaker I
> never finished... never mind, I've forgotten my point).

:-) I think the point is, many text adventures don't end with a big,
memorable,
and fiendishly difficult finish. But I think you have a good point with the
design for a puzzle-y comp game: easy and engaging to start, your best
and most clever in the middle, and then a nice, smooth finish that goes
down easy. Hm, now that you mention it, what games *do* have big,
climactic finale?

--
Jess K.


Kathleen Fischer

unread,
May 5, 2003, 5:01:18 PM5/5/03
to
"Al" <rad...@qadas.com> wrote in message
news:3EB6B62E...@qadas.com

> This now begs the question:
> should your beta-testers have hints and a walkthru or should they
> contact you when they get in trouble?

Yes. :)

If your game has inline hints, then there isn't much you can do, though
asking what could have been done to make things more clear might help.

I probably wouldn't release the walkthru with the game at the start,
unless you are really pressed for time or it quickly becomes apparent
that your game is too hard or has an issue. Even then, I might
just send out hints/solution for that spot. Part of testing (in my
opinion) is to make sure the game "flows" and is playable, and that's
hard to judge if everyone is just following the script.

Of course, mailing out a walkthru with the second or third beta-test
release might be nice, as it alows testers to more quickly navigate to
problem areas. It also gives those who might be behind a chance to
catch up. :)

> My understanding that beta-testing is MAINLY to get the bugs
> out of the game.

I think it's key to get a mix of testers to cover at *all* aspects
of game play. (check Google rec.arts.int-fiction for GRAMMAR GURUS
for my take on it) The greater the variety of testers the better
tested your game will be.

Beta testers are the litmus paper for your game. Anything they find/try,
WILL be found/tried by at least one other person at some point (well,
except possibly that 'scrape parrot' thing).

> You want input frm your testers as well on the aesthetics of the game
> but shouldn't that be after the wringing out of trhe game has occured?

Doesn't really work that way, unless you have more than one round of
testing with more than one round of testers. A players initial response
to a game can only happen once. Repeated exposure either dulls the
impact, or brings in later knowledge allowing them to rationalize your
approach.

For the most part, testers want you to succeed while judges
are looking for reasons to eliminate you.*

Kathleen

* Well, at least that's how I judge: When faced with two *equally* good
games, the one with the fewest flaws wins.

Ricardo SIGNES

unread,
May 5, 2003, 5:50:18 PM5/5/03
to
In article <3EB6B62E...@qadas.com>, Al wrote:
>
> This now begs the question:
> should your beta-testers have hints and a walkthru or should they
> contact you when they get in trouble?

http://alt-usage-english.org/excerpts/fxbegthe.html

--
rjbs

L. Ross Raszewski

unread,
May 5, 2003, 6:17:04 PM5/5/03
to
On Mon, 5 May 2003 21:01:18 +0000 (UTC), Kathleen Fischer
<mfis...@aol.com> wrote:
>
>* Well, at least that's how I judge: When faced with two *equally* good
>games, the one with the fewest flaws wins.
>

But, surely, if one has fewer flaws than the other, they are *not*
equally good?

Kathleen Fischer

unread,
May 5, 2003, 7:11:51 PM5/5/03
to
"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:ApBta.274$Zb5...@nwrddc02.gnilink.net

No, as I don't measure goodness in units of Inverse Flaws.

Example: _August_ vs. _The Kissing Bandit_ from Smootchie comp.

_The Kissing Bandit_ was by far a technically superior game. I don't
remember a single flaw - not a typo, not a bug. It made me laugh, it
surprised me, it was a thoroughly enjoyable experience from beginning
to end. I can't think of a single thing that would have improved it,
and if you haven't played it, you should.

_August_, on the other hand, was a game with obvious technical "issues".
It wouldn't surprise me to learn it hadn't be touched by a betatester.
However, the story was absolutely marvelous and it gave me goose bumps
in the end, winning my heart by a smidgen of a Smootchie (10 vs. 9+,
I believe).

Had _The Kissing Bandit_ given me goose bumps, it would have won my
vote easily. But in my mind the games weren't quite equal, and so flaw
count never came into it.

Kathleen (note: in general, relying on Goosebumps to innoculate against
Buggy Game Revoltion is a Very Bad Idea)

MFischer5

unread,
May 5, 2003, 10:53:06 PM5/5/03
to
From: Andrew Plotkin erky...@eblong.com
>Here, Neil Cerutti <hor...@yahoo.com> wrote:
>> And even then, there will be people that hate your maze anyway.
>
>Note that even though _Hunter_ won that "best puzzle" award, it made
>no better than eighth place in the IFComp standings. Many people said
>specifically that the maze area turned them off, and lowered their
>score for the game.

I know of at least one person who stopped playing _Prized Possession_ because
they *thought* there was a maze up ahead.

Kathleen (there wasn't)

-- Inevitable (SpringComp03)
-- http://www.ifarchive.org/if-archive/games/zcode/Inevita.z5
-- and The Cove (ArtShow00)(Cove.z5) and Masquerade (Comp00)(Mask.z5)
-- plus Prized Posession (Comp01) .../games/competition2001/inform/possess

J. Robinson Wheeler

unread,
May 6, 2003, 1:02:27 AM5/6/03
to
Jessica Knoch wrote:

> "Al" wrote:
> > How about hints are they really necessary.
>

> I for one am a huge fan of hints for 95% of all games. Of course,
> there are good sets of hints and then there are REALLY good sets
> of hints.

This is an issue I kept waiting for someone else to raise, but since
they haven't, I will. In my experience, it is fairly difficult to design
good hints. Creating an in-game system that keeps up with the player's
progress and gives a clever hint is even trickier.

I guess most people aren't talking about doing that, and instead mean a
menu system of hints, in which all hints are available all the time, and
you leave it up to the player not to spoil things for themselves.

It's still not a trivial exercise. "Oh, I'll just throw some hints in
there when I'm done" is probably not a good idea. The hints should
probably go through some beta-testing, too. (Although, this is tricky,
because you kind of want to see if your testers can get by without
relying on the hints.)

The last comment I have to make about including hints is something that
was already said: as an author, you get zero feedback if you include
hints, because people don't need to post to the newsgroup to ask for
help. You end up having no idea whether anyone is actually playing your
game or not.

That's more of a general-release game problem. For the Comp, you know
people are playing it. (For one turn, at least...)

--
J. Robinson Wheeler Games: http://www.raddial.com/IF/
j...@jrwdigitalmedia.com Movie: http://thekroneexperiment.com/

Michael Coyne

unread,
May 6, 2003, 9:07:49 AM5/6/03
to

Hmmm, and I was proud of myself for refraining from correcting Al on
"begging the question".

I promised my wife I'd stop correcting people so much, but now I can
prove to her that if I don't do it, someone else will.

: )

Michael

Ricardo SIGNES

unread,
May 6, 2003, 9:15:03 AM5/6/03
to
In article <3pOta.8222$NC4....@news1.mts.net>, Michael Coyne wrote:
>
> I promised my wife I'd stop correcting people so much, but now I can
> prove to her that if I don't do it, someone else will.
>

Glad to help. I live to serve.

--
rjbs

Quintin Stone

unread,
May 6, 2003, 9:16:32 AM5/6/03
to
On 5 May 2003, J. Robinson Wheeler wrote:

> This is an issue I kept waiting for someone else to raise, but since
> they haven't, I will. In my experience, it is fairly difficult to design
> good hints. Creating an in-game system that keeps up with the player's
> progress and gives a clever hint is even trickier.

That's true, but with a little work it's certainly possible for most
games. After seeing the context-sensitive hints in Worlds Apart, I
decided to include them in my own work-in-progress.

Eytan Zweig

unread,
May 6, 2003, 12:46:49 PM5/6/03
to

"Michael Coyne" <coy...@mbDOT.sympaticoDOT.ca> wrote in message
news:3pOta.8222$NC4....@news1.mts.net...

> Ricardo SIGNES wrote:
> > In article <3EB6B62E...@qadas.com>, Al wrote:
> >
> >>This now begs the question:
> >>should your beta-testers have hints and a walkthru or should they
> >>contact you when they get in trouble?
> >
> >
> > http://alt-usage-english.org/excerpts/fxbegthe.html
> >
>
> Hmmm, and I was proud of myself for refraining from correcting Al on
> "begging the question".
>

Ok, quick (OT) question - in what way is the above post a correction
(other than the fact that it was intended as one?). Sure, it points to a
website that (accurately) shows that the phrase "beg the question" used to
mean something else. But as the final paragraph in that page admits, the
usage of the phrase seems to have widened, and Al's use of it has been
reported in some dictionaries since 1983, and the implication in the
webpage is that this is a growing trend.

Phrases and words acquiring new meanings is a matter of course for living
languages - do you go around correcting people who use the word "mouse" to
refer to a computer input device rather than a small furry rodent? As far
as I can see, all that this link teaches us is that Al's usage of the
phrase is a correct one, if not the original one.

Eytan


Ricardo SIGNES

unread,
May 6, 2003, 1:07:50 PM5/6/03
to
In article <rFRta.72$aX1....@typhoon.nyu.edu>, Eytan Zweig wrote:
> Ok, quick (OT) question - in what way is the above post a correction
> (other than the fact that it was intended as one?). Sure, it points to a
> website that (accurately) shows that the phrase "beg the question" used to
> mean something else. But as the final paragraph in that page admits, the
> usage of the phrase seems to have widened, and Al's use of it has been
> reported in some dictionaries since 1983, and the implication in the
> webpage is that this is a growing trend.

This is an example of misuse that does not introduce a new phrase, but subverts
an existing one while eliminating its meaning. Now, there is yet another way
to say "suggests the question" but no simpler way to say "is founded on
premesis with a need for proof equal to that of the original claim."

I think the web page's use of the phrase "suffered ... broadening" is quite
apt.

> Phrases and words acquiring new meanings is a matter of course for living
> languages - do you go around correcting people who use the word "mouse" to
> refer to a computer input device rather than a small furry rodent?

That's a false analogy; the use of "mouse" to refer to a pointer has supplied
an alternate meaning for use in a different context. Al's use of "beg the
question" supplants the meaning of an existing phrase in its existing context,
with no gain.

--
rjbs

Al

unread,
May 6, 2003, 1:39:42 PM5/6/03
to
Eytan Zweig wrote:

> Phrases and words acquiring new meanings is a matter of course for living
> languages - do you go around correcting people who use the word "mouse" to
> refer to a computer input device rather than a small furry rodent? As far
> as I can see, all that this link teaches us is that Al's usage of the
> phrase is a correct one, if not the original one.
>
>

Thank you Eytan.

Looks like I got something right ! ! !

:) :) :)

Al

Quintin Stone

unread,
May 6, 2003, 2:44:54 PM5/6/03
to
On Tue, 6 May 2003, Eytan Zweig wrote:

> Phrases and words acquiring new meanings is a matter of course for
> living languages - do you go around correcting people who use the word
> "mouse" to refer to a computer input device rather than a small furry
> rodent? As far as I can see, all that this link teaches us is that Al's
> usage of the phrase is a correct one, if not the original one.

People didn't start calling it a "mouse" out of confusion. A bit of a
difference. It's called a mouse because that's what someone decided to
name it.

What I get from the link is "generally accepted, but wrong."

Eytan Zweig

unread,
May 6, 2003, 10:15:12 PM5/6/03
to

"Quintin Stone" <st...@rps.net> wrote in message
news:Pine.LNX.4.44.03050...@yes.rps.net...

> On Tue, 6 May 2003, Eytan Zweig wrote:
>
> > Phrases and words acquiring new meanings is a matter of course for
> > living languages - do you go around correcting people who use the word
> > "mouse" to refer to a computer input device rather than a small furry
> > rodent? As far as I can see, all that this link teaches us is that
Al's
> > usage of the phrase is a correct one, if not the original one.
>
> People didn't start calling it a "mouse" out of confusion. A bit of a
> difference. It's called a mouse because that's what someone decided to
> name it.
>
> What I get from the link is "generally accepted, but wrong."
>

What I get from it is "generally accepted, but we don't like it." Which is
fine - but if a meaning of a phrase is generally accepted, it is a
possible use of that phrase - even if it's not a nice one. Remember that
the section under which the phrase is listed on the FAQ in question is
"phrase origins" - not "current phrase usage". Where the phrase came from,
and where it is now, are too different places. Like it or not, you can't
correct people who use a phrase in a way other people understand it just
because you don't like it - at most, you can censure them.

Eytan

Duncan Stevens

unread,
May 7, 2003, 12:29:37 AM5/7/03
to

"Jon Ingold" <jonnyingoldT...@netscape.netANDTHIS> wrote in
message news:b96dp3$r8t$1...@newsg3.svr.pol.co.uk...

> This would be opposed to the classic game structure, which is pure
> graduating difficulty, until you finish with whatever the text-game
> equivalent is of the damn one-touch-kills-four-hundred-ammo-rounds
> spider-thing from the end of Tomb Raider III.
>
> (Not that any large puzzle games *do* finish that way. I forget how So Far
> ends; Curses is quite gentle come the master game; Zork III's endgame as I
> recall just doesn't make a lot of sense; Leather Goddess' was a bit of a
let
> down; Hitch-hiker's ... oh, the final puzzles were fairly hard I suppose
> (Marvin's door and all); Sorcerer I can't remember either; Spellbreaker I
> never finished... never mind, I've forgotten my point).

It varies. So Far's ending was peculiar but not unduly fiendish.
Spellbreaker's endgame was, in fact, fairly challenging, as were those of
Legend Lives, Jigsaw and Zork II (and Advent, though I'd put that more in
the categorically of "annoyingly obscure"). Beyond Zork's, Sorcerer's and
Enchanter's were ridiculously easy, and Zork I didn't have an ending puzzle
as such. I think the point is that there isn't much of a convention; if you
have other sorts of fireworks going on (i.e., plot fireworks), the player
isn't necessarily disappointed if the final puzzle isn't grand and
climactic.

--Duncan
>
> Jon
>
>


Roger Carbol

unread,
May 7, 2003, 3:21:12 PM5/7/03
to
My suggestion for another rule:


* Finish your game. There are few things more irritating to a judge
than seeing a half-finished game that clearly requires much more
work, and yet was submitted anyway. If you've still got work to do
on your game, keep working on it and submit it next year (or the
year after.)


.. Roger Carbol ..

Gene Wirchenko

unread,
May 19, 2003, 1:47:49 PM5/19/03
to
Andrew Plotkin <erky...@eblong.com> wrote:

>Here, Jessica Knoch <jessicakn...@mindspring.com> wrote:

[snip]

>> Rule Seven: Get beta-testers. Listen to them.
>
>Anyone who releases a game already has this branded on their forehead.
>If you don't, I've got the hot iron right here. Trust me. It won't
>hurt a bit.

Rule 7A: When branding something on someone's forehead as a reminder
to that worthy, remember to supply a mirror.

Rule 7B: Consider having the reminder written in mirror script.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Edmund Kirwan

unread,
May 20, 2003, 5:40:17 PM5/20/03
to
Ricardo SIGNES <rjbs-...@public.manxome.org> wrote in message news:<slrnbbcvuk.c5...@humptydumpty.manxome.org>...
> In article <3EB67849...@qadas.com>, Al wrote:
> > Ricardo SIGNES wrote:
> Hints are great, and I have my own little theories about good hints. I think
> you can do without them for a comp game. Of course, including hints in a later
> release would be nice.

Concerning in-line hints (which I'm presuming here to mean some sort
of context-dependent help-command), why not just include the hint more
subtly within the game?

Instead of something like:
You are in an office. You can see a piece of cheese and a desk.
>Help
Wouldn't the cheese look better on the desk?

Why not have some janitor run in after a predetermined length of time,
and say something unbelievably subtle like ... ooooh, how about:
You are in an office. You can see a piece of cheese and a desk.
A janitor suddenly stumbles in through an undescribed door and
roars,
"Wouldn't the cheese look better on the desk?" before vanishing
again.

Is it possible that in-line hints can always be rendered unnecessary
by more clever plotting?

.ed

www.edmundkirwan.com

Eytan Zweig

unread,
May 21, 2003, 2:08:39 AM5/21/03
to

"Edmund Kirwan" <ade...@eircom.net> wrote in message
news:a80e1059.03052...@posting.google.com...

I very much doubt so. Sure, there are many examples where this can be
done - but many others where there will be no real way to introduce
in-game hints without it seeming really forced, or screwing up the
atmosphere. For example, if the game is trying to convey a sense of
helplessness to you, or in the case of intricate puzzles which involve
doing too many different things for help to occur naturally within the
game.

The advantage off off-line hints (in-game or out of it) is that they're
off-line - they spoil the game a bit, sure, but they don't directly
interact with its atmosphere, any more than taking a bathroom break in the
middle of the game breaks mimesis.

Also, in-game hints suffer from a balance problem - how do you give
players the right amount of information rather than giving too much or too
little? Especially since every player has his own approach to the game,
and what may be easy for someone may be difficult to someone else. Good
offline hints allow the player to control how much information he or she
gets - this can be done in certain situations in the game, but the
scenarios that support this are very limited (I believe).

In-game help is great - but it's not a substitute for a hint command or
walkthrough. Just as a designer must never rely on the availability of
hints/walkthrough to allow for insufficient information in-game,
sufficient in-game information is not something that should preclude
additional means of assistance.

Eytan

>
> www.edmundkirwan.com


Ricardo SIGNES

unread,
May 21, 2003, 7:36:39 AM5/21/03
to
In article <a80e1059.03052...@posting.google.com>, Edmund Kirwan wrote:
>
> Is it possible that in-line hints can always be rendered unnecessary
> by more clever plotting?
>

I don't believe that it is. At some level, I think that would make the in-game
information somewhat ridiculous -- unless the hints are kept small and subtle.
In my opinion, though, the hints should eventually give you the literal
solution.

Q: What's the cheese for?
A: Who leaves cheese on the floor, anyway?
A: Maybe you could just put it somewhere cleaner.
A: Like the dinette table.
A: Well, there's no dinette in this game, just an office.
A: So, how about the desk?
A: GET CHEESE THEN PUT IT ON DESK

By always providing a compelte solution, the hints ensure that no one is ever
totally stuck. Often it's overkill. If it isn't, just a few times, it was
worth it, IMHO.

--
rjbs

John Colagioia

unread,
May 23, 2003, 12:50:03 PM5/23/03
to
"Eytan Zweig" <eyt...@oook.cz> wrote in news:DIEya.115$aX1.11934
@typhoon.nyu.edu:

> "Edmund Kirwan" <ade...@eircom.net> wrote in message
> news:a80e1059.03052...@posting.google.com...
[...]

>> Is it possible that in-line hints can always be rendered unnecessary
>> by more clever plotting?
> I very much doubt so. Sure, there are many examples where this can be
> done - but many others where there will be no real way to introduce
> in-game hints without it seeming really forced, or screwing up the
> atmosphere.

I once read a programming book that, when discussing comments, had a
bit of wisdom something to the effect of, "if you think your code needs
a comment, perhaps you should rewrite the code."

I can't help but think that, if not a rule for this situation, it
should at least be something to consider: If your puzzle is too
obscure for a mere mortal to solve unaided, then just maybe the puzzle
could do with some changes.

[...]


> sufficient in-game information is not something that should preclude
> additional means of assistance.

This, of course, is also very, very true. The most carefully crafted
"newbie-friendly" puzzle will have the blatantly obvious solution
overlooked by quite intelligent people. These people will still need
hints.

...probably not from the author, though, I guess...

Quintin Stone

unread,
May 23, 2003, 1:33:37 PM5/23/03
to
On Fri, 23 May 2003, John Colagioia wrote:

> I once read a programming book that, when discussing comments, had a bit
> of wisdom something to the effect of, "if you think your code needs a
> comment, perhaps you should rewrite the code."

My advice is to burn said book. It's a good analogy, but a bad
programming practice.

Not that I write a lot of comments myself... :)

John Colagioia

unread,
May 23, 2003, 2:22:36 PM5/23/03
to
Quintin Stone <st...@rps.net> wrote in
news:Pine.LNX.4.44.03052...@yes.rps.net:
> On Fri, 23 May 2003, John Colagioia wrote:
>
>> I once read a programming book that, when discussing comments, had
>> a bit of wisdom something to the effect of, "if you think your code
>> needs a comment, perhaps you should rewrite the code."
> My advice is to burn said book. It's a good analogy, but a bad
> programming practice.

That depends, really. I see two reasons for the advice:

1) Your comments are on the order of (and I paraphrase from an actual
assignment I had submitted to me, a few years back):
x.value++; //Increments the value field of object x by 1
or (from my days as a course grader):
bob = dave + 5; //bob is the total and dave is the current value
The former was from a network (TCP/IP) programming course, and the
latter from the Intro to Programming class. Disney character names
may have been used rather than "bob" and "dave," though...

2) Your code is so convoluted and/or addled that it's
incomprehensible without comments. This is bad; except under very
specified conditions that no entry-level/student programmer will
ever face, you've almost certainly chosen the wrong algorithm.

These, by the way, are almost entirely representative of the comments
I have to put up with at work. They serve no purpose, and make the
code even harder to work with, since updating the code means updating
the lousy comments.

You'll note that it doesn't say "comments are bad," which would be a
very different issue.

> Not that I write a lot of comments myself... :)

I tend not to comment code, but rather design. "This function does
blah, blah, blah. Chosen because of such-and-such requirements, the
algorithm was cribbed from Knuth, pXXX" (since it's always from Knuth,
y'know...) is about the level. It basically says, (a) here's what the
block does, (b) here's why it's written that way, and (c) here's a
really good reference if you're not sure how it works, because I can't
stuff that into a comment without overshadowing the code.

Mileage, as they say, may vary, though.

Seebs

unread,
May 23, 2003, 7:54:18 PM5/23/03
to
In article <a80e1059.03052...@posting.google.com>,

Edmund Kirwan <ade...@eircom.net> wrote:
>Why not have some janitor run in after a predetermined length of time,
>and say something unbelievably subtle like ... ooooh, how about:
> You are in an office. You can see a piece of cheese and a desk.
> A janitor suddenly stumbles in through an undescribed door and
>roars,
> "Wouldn't the cheese look better on the desk?" before vanishing
>again.

>Is it possible that in-line hints can always be rendered unnecessary
>by more clever plotting?

Boy, if I ever want to redo Janitor, you've given me an idea for making it
much harder.

-s
--
Copyright 2003, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/

Eytan Zweig

unread,
May 24, 2003, 2:49:09 AM5/24/03
to

"John Colagioia" <JCola...@csi.com> wrote in message
news:691b16a485c0d73811c5eefce2e637df@TeraNews...

> "Eytan Zweig" <eyt...@oook.cz> wrote in news:DIEya.115$aX1.11934
> @typhoon.nyu.edu:
> > "Edmund Kirwan" <ade...@eircom.net> wrote in message
> > news:a80e1059.03052...@posting.google.com...
> [...]
> >> Is it possible that in-line hints can always be rendered unnecessary
> >> by more clever plotting?
> > I very much doubt so. Sure, there are many examples where this can be
> > done - but many others where there will be no real way to introduce
> > in-game hints without it seeming really forced, or screwing up the
> > atmosphere.
>
> I once read a programming book that, when discussing comments, had a
> bit of wisdom something to the effect of, "if you think your code needs
> a comment, perhaps you should rewrite the code."
>
> I can't help but think that, if not a rule for this situation, it
> should at least be something to consider: If your puzzle is too
> obscure for a mere mortal to solve unaided, then just maybe the puzzle
> could do with some changes.
>

(note - below, as previously in the conversation, I use the term
"offl-game hints" to mean any sort of hints that are not part of the game
world, even if they are built into the actual game and accessed by a
"hints" command)

That's not what I was talking about. The puzzle may be very easy - but it
still may be an end to how much help you can/want to give *in-game*. For
instance, if you're all alone in a dark room and are about to be eaten by
a grue, the right thing to do may be to strike a match - but you really
don't want a janitor popping into the room telling you "light a match,
won't you!". And sometimes, no matter how easy a puzzle is, players will
get stuck there for whatever reason - maybe the last game they played had
grues which weren't afraid of small match-sized lights, and this image
stuck in their minds - which you have no way of predicting.

As for more complex puzzles - being complex doesn't mean that it can't be
solved by a human being; imagine a puzzle where you need to learn to
decipher an alien alphabet. The puzzle could involve you collecting
several items with bi-lingual symbols on them and using them collectively
as a rosetta-stone - but the game will have no real way to know if you're
stuck in figuring out that the third symbol on the second clay tablet
means "no", or that the fourth symbol on the third clay tablet means
"cheese", *especially* if beta-testing showed that the puzzle itself is
moderatly easy and most people don't get stuck.

I'm not advocating, and never intended to do so, that people use off-game
hints and walkthroughs as an excuse for unsolvable puzzles. I'm just
saying that *if* you want to ensure that your game is fully experienced by
everyone, and don't want to make it puzzleless or trivial, then you can't
rely on the fact that your puzzles are well designed to mean that everyone
can solve them on their own - after all, every player is different and you
never know what they bring into the game experience. And you will often
find cases where there is no reasonable way to provide help in-game
without making the game seem ridiculous or spoiling the puzzle to
everyone, and therefore off-line hints and walkthroughs will be necessary.

To be honest, the mindset that thinks that off-line hints and walkthroughs
are a bad thing is totally undecipherable to me; the one exception being
cases where your are designing a game to be a challange to be overcome,
rather than a story to be experienced. But any plot-driven IF, or even
puzzle-driven IF designed to entertain rather than test its players, seems
to me to benefit immensly from offline help sources, above and beyond the
actual design of the game.

> [...]
> > sufficient in-game information is not something that should preclude
> > additional means of assistance.
>
> This, of course, is also very, very true. The most carefully crafted
> "newbie-friendly" puzzle will have the blatantly obvious solution
> overlooked by quite intelligent people. These people will still need
> hints.
>
> ...probably not from the author, though, I guess...

Well, the author is of course under no obligation to provide the help -
but he or she is often the best person suited to do so. I understand that
the author may not have the time to do so, or that it may no be high on
his or her list of priorities; in which case, if the game is good enough,
someone else will come along and do it for them. But one thing I can never
understand is those authors that provide hints/walkthroughs that are
available during the competition, then disable or remove them - if they
put the work into doing so, all they do is hurt their game by taking it
away later.

Eytan


J. J. Guest

unread,
May 24, 2003, 10:51:41 AM5/24/03
to
rca...@home.com (Roger Carbol) wrote in message news:<82675075.03050...@posting.google.com>...

This is absolutely right, of course, but I still can't shake the
(hopefully totally unfounded) fear that after working away on a game
for two years, I will emerge to find that interest in text adventures
has evaporated, and that there is no-one left who wants to play my
masterpiece...

Edmund Kirwan

unread,
May 24, 2003, 5:52:26 PM5/24/03
to
jason...@hotmail.com (J. J. Guest) wrote in message news:<2782876b.03052...@posting.google.com>...

> rca...@home.com (Roger Carbol) wrote in message news:<82675075.03050...@posting.google.com>...
> > My suggestion for another rule:
> >
> >
> > * Finish your game. There are few things more irritating to a judge
> This is absolutely right, of course, but I still can't shake the
> (hopefully totally unfounded) fear that after working away on a game
> for two years, I will emerge to find that interest in text adventures
> has evaporated, and that there is no-one left who wants to play my
> masterpiece...

2 years? Really? What's the game? Or were you speaking hypothetically?

.ed

www.edmundkirwan.com

John Colagioia

unread,
May 27, 2003, 9:17:11 AM5/27/03
to
"Eytan Zweig" <eyt...@oook.cz> wrote in
news:LCEza.118$aX1....@typhoon.nyu.edu:
> "John Colagioia" <JCola...@csi.com> wrote in message
> news:691b16a485c0d73811c5eefce2e637df@TeraNews...
[...]

>> I can't help but think that, if not a rule for this situation, it
>> should at least be something to consider: If your puzzle is too
>> obscure for a mere mortal to solve unaided, then just maybe the
>> puzzle could do with some changes.
[...]

> That's not what I was talking about. The puzzle may be very easy -
> but it still may be an end to how much help you can/want to give
> *in-game*.

I'd argue that if such a situation were to exist, it means that the
puzzle either is trivial or requires reading the author's mind.
Either way, it could probably do with a rewrite more than it can
hints.

Well, with one exception, which I don't think *any* author can
be expected to account for.

> For
> instance, if you're all alone in a dark room and are about to be
> eaten by a grue, the right thing to do may be to strike a match -
> but you really don't want a janitor popping into the room telling
> you "light a match, won't you!".

Well, no, you never want a hint like that. Even in a comedic game,
this would be transparently patronizing.

In this case, the "puzzle" is actually trivial, but there are still
in-game hints that can be added. Perhaps the player is wearing a
mystical necklace that briefly flashes light, spooking the grues, or
an electrical cable sparks.

This is where "show, don't tell" really comes into its own, I think.

> And sometimes, no matter how easy a puzzle is, players will
> get stuck there for whatever reason - maybe the last game they
> played had grues which weren't afraid of small match-sized lights,
> and this image stuck in their minds - which you have no way of
> predicting.

And, thus, any hint you provide, short of whacking the player upside
the head with the solution, will be useless.

As you say, the author can't predict it, so how can you reasonably
expect him to provide usable hints for it? Chances are, he didn't
even think it *was* a puzzle.

[...]


> I'm not advocating, and never intended to do so, that people use
> off-game hints and walkthroughs as an excuse for unsolvable puzzles.
> I'm just saying that *if* you want to ensure that your game is fully
> experienced by everyone, and don't want to make it puzzleless or
> trivial,

Short of providing a walkthrough or (perhaps preferably, saving them
the effort of typing) a transcript would be better in such cases. I
mean, really, why would you want to have "obstacles" if everyone who
touches your game is supposed to get past them? "Congratulations!
You've done what...well, what any higher primate should be able to
do, actually."

> then you can't
> rely on the fact that your puzzles are well designed to mean that
> everyone can solve them on their own - after all, every player is
> different and you never know what they bring into the game
> experience.

Again, this says to me, "the game author shouldn't be writing the
hints." It's like documenting software: You *could* let the
programmer do it, but he'll likely just chat about features, and most
likely ordered by how hard they were to implement; little time, if
any, will be spent on what people might actually want to *do* with the
software.

Heh...I learned that one the hard way at my last couple of jobs...

> And you will often
> find cases where there is no reasonable way to provide help in-game
> without making the game seem ridiculous or spoiling the puzzle to
> everyone, and therefore off-line hints and walkthroughs will be
> necessary.

Again, I don't see that situation. Well, I do, but it's likely the
puzzle will stand out like a sore thumb, anyway (the the Zork II
"diamond" comes to mind).

I mean, I do understand what you're saying--don't get me wrong.
However, I think that I'm just seeing a slightly different problem
than you are.

> To be honest, the mindset that thinks that off-line hints and
> walkthroughs are a bad thing is totally undecipherable to me;

Well, yes. That's, to say the least, highly obsessive behavior.

> the one exception being
> cases where your are designing a game to be a challange to be
> overcome, rather than a story to be experienced. But any plot-driven
> IF, or even puzzle-driven IF designed to entertain rather than test
> its players, seems to me to benefit immensly from offline help
> sources, above and beyond the actual design of the game.

But, I'll think you'll note, that probably none of those offline
sources (except in the form of feelies or documentation, which are
highly special cases) were created by the game author, but rather
"some poor slob" who got caught at the same point(s) you did.

[...]


> Well, the author is of course under no obligation to provide the
> help - but he or she is often the best person suited to do so.

I disagree, mostly for reasons above, but also for one more, very
simple reason: What makes you think that the author is holding
anything back? If the author has created a puzzle that he thinks is
"good," and has worked it into the plot, added all the nifty in-game
hints (again, none of that, "hey, why don't you just try *this*, you
twit"), surely the author believes that (a) he's done everything he
can, and (b) that the puzzle has probably already been rendered
trivial.

The only case where I can see it is if the author intentionally
withheld relevant information required for solving the puzzle. I
would tend to doubt that such an author would produce a game really
worth playing, though, to be honest. "Trick" mazes seem like a good
example of this.

[...]


> But one thing I can never
> understand is those authors that provide hints/walkthroughs that are
> available during the competition, then disable or remove them - if
> they put the work into doing so, all they do is hurt their game by
> taking it away later.

I would also imagine that such a removal probably leaves behind more
than a few bugs in its place, as well, which can't be good.

J. J. Guest

unread,
May 27, 2003, 11:59:35 AM5/27/03
to
ade...@eircom.net (Edmund Kirwan) wrote in message news:<a80e1059.0305...@posting.google.com>...

I was speaking hypothetically. Actually 2 years feels like a
reasonable estimate of how long my present game will take me. I
started it in ADRIFT about 6 months ago, switched to TADS last month
and re-coded everything which didn't take nearly as long as I feared,
but no matter how quickly I code it I can't get away from the fact
that I am totally, totally stuck on a plot point.

Al

unread,
May 27, 2003, 1:17:01 PM5/27/03
to
I've taken the liberty of placing a "Game Instructions Sign"
in the player's starting location so that he/she will be remineded
to read the instructions.

I believe for all players, newbies and experienced, this is a good thing
since many people may overlook the banner telling them to read the instructions
before playing.

If you disagree please state why.

Thanks


Adam Biltcliffe

unread,
May 27, 2003, 4:57:43 PM5/27/03
to
In article <3ED39D8B...@qadas.com>, rad...@qadas.com says...

It depends on the tone you want to set, I guess. While undoubtedly
making the probability that the player will remember to read the
instructions greater, it could also be argued that it disrupts mimesis a
bit to have such a reminder be a permanent physical part of the game
world. I guess it comes down to what you're focusing on in the game: if
you're going to great lengths to create an atmosphere and setting it
would seem a bit counterproductive to that effort to then drop a meta-
game sign in the middle of it, but if you feel it's necessary for
puzzle-solving reasons then you could certainly do so.


Adam

Al

unread,
May 27, 2003, 6:55:28 PM5/27/03
to
Adam Biltcliffe wrote:

>
>
> It depends on the tone you want to set, I guess. While undoubtedly
> making the probability that the player will remember to read the
> instructions greater, it could also be argued that it disrupts mimesis a
> bit to have such a reminder be a permanent physical part of the game
> world. I guess it comes down to what you're focusing on in the game: if
> you're going to great lengths to create an atmosphere and setting it
> would seem a bit counterproductive to that effort to then drop a meta-
> game sign in the middle of it, but if you feel it's necessary for
> puzzle-solving reasons then you could certainly do so.
>
>

The reason I suggested this is that Ricardo who was the first beta-tester of the
game
failed to look at the directions which led to him dis-asssembling the program. I
've
learned since that dis-assembly is one of the things that beta-testers do. I was
totally
unaware of this and felt he was trying to cut corners. That having been said. I
feel
that all players should read the instructions since there may be items within
that
are essential to the game.

The sign is placed at the beginnng and merely gives a warning to the player
that
reading the instructions are necessary before the player leaves that first
location.
he can only return there by doing a certain activity which I don't forsee
happening
but I placed it in the game anyway as kind of an easter egg.

Al


Ben A L Jemmett

unread,
May 27, 2003, 6:59:18 PM5/27/03
to
"Al" <rad...@qadas.com> wrote in message
news:3ED3ECDF...@qadas.com...

> That having been said. I
> feel
> that all players should read the instructions since there may be items
within
> that
> are essential to the game.

As a player, I very rarely read the help until I get completely and utterly
stuck -- most of the time, IME, the help consists of little more than an
introduction to playing IF and a list of credits; neither of which I feel
particularly compelled to read, since I'm playing the game mainly because I
have an hour spare and want to have some fun.

Just a data point, nothing more.

--
Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)


Al

unread,
May 27, 2003, 7:12:37 PM5/27/03
to
Ben A L Jemmett wrote:

>
>
> As a player, I very rarely read the help until I get completely and utterly
> stuck -- most of the time, IME, the help consists of little more than an
> introduction to playing IF and a list of credits; neither of which I feel
> particularly compelled to read, since I'm playing the game mainly because I
> have an hour spare and want to have some fun.
>
> Just a data point, nothing more.
>
>

The only reason I brought this up is because within my help section
there IS information critical to completing the game and achieving
all the points.

Another poster thought that putting the sign in the first location breaks
mimesis.
The player-judges of the comp game will have the walkthru however to refer
to if they get stuck. I will bring up th is point with my tester and see what
his
take on it is.

Steve Evans

unread,
May 27, 2003, 8:29:36 PM5/27/03
to
Al <rad...@qadas.com> wrote in message news:<3ED39D8B...@qadas.com>...

Al, for most styles of games such a sign would represent a blatant
break of mimesis, and has the potential to piss off those players who
have already read your game instructions as their initial action.

It would be better if your game was set up to identify actions that
suggest that the player hasn't read the instructions, and to then
provide a gentle reminder to type "INFO", or whatever. Alternatively
you could add a daemon that cuts in after certain number of turns at
the first point where the player is likely to be floundering if they
haven't read the instructions. Your message could be along the lines
of "Typing INFO will provide important information about playing this
game, you may wish to do so if you haven't already."

In short, I don't think that beating your players over the head with a
mimesis breaking sign is a good way to start your game.

Steve

Al

unread,
May 27, 2003, 11:13:41 PM5/27/03
to
>
>
>
>
> In short, I don't think that beating your players over the head with a
> mimesis breaking sign is a good way to start your game.
>
>

The sign will be removed. I still feel it is the player's obligation
to read the instructions especially since they contain info important
to the game. I do not want to break mimesis.

Al


Christos Dimitrakakis

unread,
May 28, 2003, 4:13:52 AM5/28/03
to

I think it is sufficient to add another ''read the instructions'' line at
the end of your introduction. The one you had in your first public beta
did not make it clear that it was necessary to read them, as it was the
standard line that appears in most inform games.

John Colagioia

unread,
May 28, 2003, 8:19:01 AM5/28/03
to
Al <rad...@qadas.com> wrote in news:3ED39D8B...@qadas.com:

I might have a strange outlook, here, but I'm generally guided by the
maxim (admittedly ironic regarding IF), "people don't read." In the
software world, this means that your UI has failed if the user (sorry,
"participant"; I've been informed that us--participants think the word
"user" sounds like they're doing drugs...) *needs* to read the
directions to accomplish common things, because they won't unless you
hold a gun to their heads (on average).

In IF, it's not so much a lack of desire, of course, but a certain
jaded attitude we&