Comp 2003 Tips for First-Time Entrants
Jessica Knoch
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
>
> 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
> 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
>
>
> 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
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
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
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
> 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
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
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
> 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
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
> 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
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
> 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
> 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
> 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
> "
>
> 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
> 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
> 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
>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
>
<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
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
>
> 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
<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
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
>> 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
> "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
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
>
> 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
> 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
> 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
> 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
> rep