[CONTEST] Planning for 1997, take 2.
Gerry Kevin Wilson
Okay, to paraphrase the solid rules:
1. Under 2 hours in length. More will not be rated by judges.
2. Your own creation.
3. Freeware or public domain.
4. Specific text format walkthrough named WALKTHRU.TXT.
Here are the two rules I am working on:
5. Your game must not have your name listed anywhere in it, or its
accompanying package. You must contact me to get an author registration
number, which you will then use in the copyright notice like "Copyright
1997 by I-F Competition Committee, Author #001-001. For identity
verification, I can be reached at: blahblah."
6. Authors of a competition entry may not discuss the entries in a public
Internet forum during the voting period. (i.e. you may not post about the
entries to an Internet newsgroup.)
That's the rough draft of them. I believe #5 to be legally sound, but if
you know otherwise, you should let me know. I'll come up with some legal
gumbo about copyrights reverting to original owners after the voting
deadline, and the Committee being unable to reprint the game in any manner
without the express permission of the registered author.
Most of the other stuff for the contest that I'm thinking about is stuff
like including a few sample scoring methods with the 'How to Vote' file,
and specifics on how to submit games for betatesting or voting.
The only bad part I can see about the new rules is that the 'original
form' directory like we have for the 1995 Contest may not be possible
without a great deal of work. Mind you, I'm not going to strain too hard
to make sure future generations will be able to ogle the buggy first
releases of the entries. ;)
Ah well, I'm for bed.
And, just so everyone knows, I never make a rule unless I've had trouble
with that area in the past. These new rules are intended to patch up
problems that I have seen thus far with this year's competition. Being
the ONE RULE kind of guy that I am, I don't make rules for rules' sake, as
some might believe.
--
"Ha. Made ya look!"
Nulldogma
> Okay, to paraphrase the solid rules:
>
> 1. Under 2 hours in length. More will not be rated by judges.
> 2. Your own creation.
> 3. Freeware or public domain.
> 4. Specific text format walkthrough named WALKTHRU.TXT.
Isn't "not previously released" a current rule, too? Seems it should be
maintained.
Neil
---------------------------------------------------------
Neil deMause ne...@echonyc.com
http://www.echonyc.com/~wham/neild.html
---------------------------------------------------------
Gerry Kevin Wilson
Ok, here's how I'm dealing with randomness in walkthroughs. All games
that have elements of chance must include a non-determinate(is that
right?) mode that forces random numbers generated to change to 1. When
you program your game, be sure that any random event needed for the
completition of the game will occur on a 1. Then, write a walkthrough for
the non-random mode of the game. (Note that this is a trivial programming
problem, and Dave Baggett has something like it somewhere, possibly
WorldClass?)
--
"Cheese. It's not just for aliens anymore."
Greg Falcon
n...@vcn.bc.ca (Neil K. Guy) wrote:
>Gerry Kevin Wilson (whiz...@uclink.berkeley.edu) wrote:
>: Ok, here's how I'm dealing with randomness in walkthroughs. All games
>: that have elements of chance must include a non-determinate(is that
>: right?) mode that forces random numbers generated to change to 1. [...]
Always 1? That would make for pretty boring random scenery and such.
Why not just rule that all games with chance elements must include a
mode that forces the random numbers generated to follow a predictable
pattern?
> Well, this is very easy for those authoring systems (like TADS) which
>allow the game author to seed the random number generator. (TADS' random
>number generator always generates the same random numbers in sequence
>unless you use the randomize() function to reset the seed to something
>unknowable - taken from whatever the system clock happens to be at the
>time, I think.)
> Is that what you were thinking? To make it easier for beginning authors
>maybe sample code for the most common authoring systems could be posted
>explaining the easiest way to conform with this rule.
As far as Inform is concerned with this:
The Z-machine spec does allow for seeding the random number generator
to create predictable strings of numbers; however, there is nothing
that guarantees that the predictable strings generated will be the
same on all interpreters.
Luckily, Inform allows for "built in" functions like Random(x) to be
Replace'd as if they were part of the library. Sooo... something like
this:
Global RandomCount;
Global RandomFlag;
Replace Random;
[ Random n ;
if (RandomFlag == 0)
{@random n -> sp;
@ret sp;
}
RandomCount = (RandomCount+1)%1000; ! Simple fixed random number
return (RandomCount%n+1); ! algorithm gleefully swiped
]; ! from z-spec
would serve our purpose quite nicely. Random(n) would work just as it
always did UNTIL something in the code set RandomFlag to a non-zero
value. Then Random would spew out predictable numbers.
(The algorithm I used to generate a fixed pattern makes for fairly
predictable sequences. Something better should be generated if
randomness is really important.)
Hope I haven't reinvented the wheel here. ;-)
Greg
---
___ ___ ___ ___ Greg Falcon (professo...@pnx.com)
/ __\ / __\ / __\ / __\
( ( ( ( ( ( ( ( MEMBER S.S.S.S.
\ \ \ \ \ \ \ \ (Society to Stop Sizeable .SIGs)
\ \ \ \ \ \ \ \
___) ) ___) ) ___) ) ___) ) (With heartfelt apologies to people with
\___/ * \___/ * \___/ * \___/ * proportional fonts or no sense of humor)
Neil K. Guy
Gerry Kevin Wilson (whiz...@uclink.berkeley.edu) wrote:
: Ok, here's how I'm dealing with randomness in walkthroughs. All games
: that have elements of chance must include a non-determinate(is that
: right?) mode that forces random numbers generated to change to 1. [...]
Well, this is very easy for those authoring systems (like TADS) which
allow the game author to seed the random number generator. (TADS' random
number generator always generates the same random numbers in sequence
unless you use the randomize() function to reset the seed to something
unknowable - taken from whatever the system clock happens to be at the
time, I think.)
It could be kind of a pain for systems that don't work like that,
though. Unless you did something like this every time: (in pseudocode)
x =
{
if ( some random flag is true )
then x = random number
else
x = 1
}
Is that what you were thinking? To make it easier for beginning authors
maybe sample code for the most common authoring systems could be posted
explaining the easiest way to conform with this rule.
- Neil K. Guy
--
the Vancouver CommunityNet * http://www.vcn.bc.ca/
(formerly the Vancouver Regional FreeNet)
Steven Howard
In <55r9hl$7...@agate.berkeley.edu>, whiz...@uclink.berkeley.edu (Gerry Kevin Wilson) writes:
>
>Ok, here's how I'm dealing with randomness in walkthroughs. All games
>that have elements of chance must include a non-determinate(is that
>you program your game, be sure that any random event needed for the
>completition of the game will occur on a 1. Then, write a walkthrough for
>the non-random mode of the game. (Note that this is a trivial programming
>problem, and Dave Baggett has something like it somewhere, possibly
>WorldClass?)
At this point I can't help but wonder if this "cure" isn't worse than the
"disease." Refresh my memory: what's the problem that we're trying to
solve by requiring a walkthrough?
========
Steven Howard
bl...@ibm.net
What's a nice word like "euphemism" doing in a sentence like this?
David Baggett
In article <55rof1$7...@news.dx.net>,
Greg Falcon <professo...@pnx.com> wrote:
>Always 1? That would make for pretty boring random scenery and such.
>Why not just rule that all games with chance elements must include a
>mode that forces the random numbers generated to follow a predictable
>pattern?
In practice, this makes developing walkthroughs that won't break when you
add things to your game much harder. If you must have nicely random
scenery messages when regression testing, you're probably better off making
a separate random number wrapper like rndscenery(n) for die rolls whose
results cannot affect game state.
Consider the alternative: you're almost done your game and you've got a
walkthrough that solves it. Then you add a single call to the random
number generator somewhere in the code. Now you have broken your
walkthrough, because it relies on a particular sequence of (phony) random
results, which you have just permuted.
>Hope I haven't reinvented the wheel here. ;-)
Watch out for potholes...
Dave Baggett
__
d...@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)
David Baggett
>At this point I can't help but wonder if this "cure" isn't worse than the
>"disease." Refresh my memory: what's the problem that we're trying to
>solve by requiring a walkthrough?
When you're developing a game, it's useful to have a script that solves the
whole game, so that you can tell if some change you've made to the code has
broken the game. The alternative is to play through the game by hand,
which gets really old really quickly.
Andrew Plotkin
Andrew Plotkin (erky...@netcom.com) wrote:
> Put
> random(-1);
> as the first line of Initialise(). That will produce a deterministic
> sequence of "random" numbers on any to-spec interpreter.
Just ignore that, please. It produces a predictable sequence on any given
machine, but there's no guarantee it will be the same on different
machines (especially if they're different OSes.) So it's no good for a
fixed walkthrough.
I just made my saved throw vs. thinking.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Marnix Klooster
whiz...@uclink.berkeley.edu (Gerry Kevin Wilson) wrote:
[solid rules snipped]
> Here are the two rules I am working on:
>
> 5. Your game must not have your name listed anywhere in it, or its
> accompanying package. You must contact me to get an author registration
> number, which you will then use in the copyright notice like "Copyright
> 1997 by I-F Competition Committee, Author #001-001. For identity
> verification, I can be reached at: blahblah."
Here I am, writing fiction. And I'm being assigned a *number*?
I'd prefer a real name, or a real pseudonym at least. Why not
let the author choose one? Or you, Kevin?
I realize that numbers are safer: somebody knowing an author
better might recognize his or her pseudonym. Idea: choose a name
that is in some way related to the story.
[rule about authors discussing entries snipped]
> That's the rough draft of them. I believe #5 to be legally sound, but if
> you know otherwise, you should let me know. I'll come up with some legal
> gumbo about copyrights reverting to original owners after the voting
> deadline, and the Committee being unable to reprint the game in any manner
> without the express permission of the registered author.
Wouldn't it be simpler to just say something like "Copyright 1997
by P.S. Eudo-Nym; contact the I-F Competition Committee Chairman
for more information."? Or does that have legal problems?
Groetjes,
<><
Marnix
--
Marnix Klooster
mar...@worldonline.nl
Greg Falcon
d...@xbar.ai.mit.edu (David Baggett) wrote:
>In article <55rof1$7...@news.dx.net>,
>Greg Falcon <professo...@pnx.com> wrote:
>>Always 1? That would make for pretty boring random scenery and such.
>>Why not just rule that all games with chance elements must include a
>>mode that forces the random numbers generated to follow a predictable
>>pattern?
>In practice, this makes developing walkthroughs that won't break when you
>add things to your game much harder. If you must have nicely random
>scenery messages when regression testing, you're probably better off making
>a separate random number wrapper like rndscenery(n) for die rolls whose
>results cannot affect game state.
Oh, yeah, I never even thought of that. :-P
In that case, I would probably just make a separate function,
MaybeRandom(n) that would return a random integer from 1 to n if
RandomFlag was 0, and 1 otherwise.
>>Hope I haven't reinvented the wheel here. ;-)
>Watch out for potholes...
Yeah... yeah... for a second there, I thought I had contributed
something useful. Sigh. Sheesh. ;-)
Greg
PS. I don't think the rules should have to say a single thing about
randomness. Just specify that the walkthrough must be a simple list
of commands that always works. (In other words, no "wait for this to
happen, then do this" lines in the walkthrough.) This makes
predictable "random" numbers required without having to mention
randomness in the rules.
Roger Carbol
As I mentioned much earlier in this discussion, there is still nothing
preventing someone from implementing a special command and having the
walkthrough consist of:
>WIN GAME
You win the game!
Would you like to RESTARE, RESTORE,QUIT, or PLAY GAME FOR REAL THIS TIME?
Roger Carbol .. r...@col.ca .. where there's a will
Dan Shiovitz
In article <32819bd7...@news.worldonline.nl>,
Marnix Klooster <mar...@worldonline.nl> wrote:
>whiz...@uclink.berkeley.edu (Gerry Kevin Wilson) wrote:
>> Here are the two rules I am working on:
>>
>> 5. Your game must not have your name listed anywhere in it, or its
>> accompanying package. You must contact me to get an author registration
>> number, which you will then use in the copyright notice like "Copyright
>> 1997 by I-F Competition Committee, Author #001-001. For identity
>> verification, I can be reached at: blahblah."
>
>Here I am, writing fiction. And I'm being assigned a *number*?
>I'd prefer a real name, or a real pseudonym at least. Why not
>let the author choose one? Or you, Kevin?
>
>I realize that numbers are safer: somebody knowing an author
>better might recognize his or her pseudonym. Idea: choose a name
>that is in some way related to the story.
Or we could take the silly game approach, and have people on this newsgroup
suggest pseudonyms to be put into a pool and randomly assigned to authors.
Of course, this has the downside that someone will almost certainly
end up with "Kunkel".
[..]
>> That's the rough draft of them. I believe #5 to be legally sound, but if
>> you know otherwise, you should let me know. I'll come up with some legal
>> gumbo about copyrights reverting to original owners after the voting
>> deadline, and the Committee being unable to reprint the game in any manner
>> without the express permission of the registered author.
>
>Wouldn't it be simpler to just say something like "Copyright 1997
>by P.S. Eudo-Nym; contact the I-F Competition Committee Chairman
>for more information."? Or does that have legal problems?
Nobody seems exactly sure. Or, rather, there are many people who are
sure but they aren't all sure in the same direction. Personally, I think
the point of the "Copyright 1997 by foo" is to make sure that anyone
using it sees that it is under copyright, and therefore can't make the
"oh, I didn't know" excuse in court.
>Marnix
>--
>Marnix Klooster
>mar...@worldonline.nl
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more
sensible people ... remember to speak up for freedom because no one else
will do it for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Gerry Kevin Wilson
Re: Win Game. You Win!
There is one thing that will discourage this. I will eat anyone who does
it. No really, I'm serious.
Steven Howard
In <55thu5$p...@life.ai.mit.edu>, d...@xbar.ai.mit.edu (David Baggett) writes:
>In article <55sv1o$k7i$1...@news-s01.ca.us.ibm.net>, Steven Howard <bl...@ibm.net> wrote:
>
>>At this point I can't help but wonder if this "cure" isn't worse than the
>>"disease." Refresh my memory: what's the problem that we're trying to
>>solve by requiring a walkthrough?
>
>When you're developing a game, it's useful to have a script that solves the
>whole game, so that you can tell if some change you've made to the code has
>broken the game. The alternative is to play through the game by hand,
>which gets really old really quickly.
You mistake my meaning. I wasn't asking whether having a walkthrough was
a good idea. I was asking why contest authors are required to submit a
walkthrough along with their game.
Carl Muckenhoupt
I had planned to enter next year's contest. The more requirements
and restrictions are placed on me, the less likely this becomes.
Of course, I had also planned to enter *this* year's contest...
--
Carl Muckenhoupt | Text Adventures are not dead!
b...@tiac.net | Read rec.[arts|games].int-fiction to see
http://www.tiac.net/users/baf | what you're missing!
Eli The Bearded
Roger Carbol <r...@col.ca> wrote:
>As I mentioned much earlier in this discussion, there is still nothing
>preventing someone from implementing a special command and having the
>walkthrough consist of:
>
>>WIN GAME
>You win the game!
>Would you like to RESTARE, RESTORE,QUIT, or PLAY GAME FOR REAL THIS TIME?
The game I am working on now, and for the last eight - nine months
with a lot of work left, has a very simple goal to win the game.
How convoluted a path you take to get to that goal will determine
your score, but you can technically win in about a dozen moves.
Essentially I am just taking the idea of multiple endings to an
extreme.
Elijah
------
wondering if determinist random number generators default to stay
deterministic between saves (even requiring the same interpreter)
John Wood
It's a minor thing, but I tend to put as many competition games as
possible in one directory (for various reasons). How would people
feel about this being called GAMENAME.WLK or somesuch? Just to
save me a little extra effort... ;-)
John
Phil Goetz
In article <55t8jn$6...@agate.berkeley.edu>,
Gerry Kevin Wilson <whiz...@uclink.berkeley.edu> wrote:
>In article <55sv1o$k7i$1...@news-s01.ca.us.ibm.net>,
>Steven Howard <bl...@ibm.net> wrote:
>>
>>At this point I can't help but wonder if this "cure" isn't worse than the
>>"disease." Refresh my memory: what's the problem that we're trying to
>>solve by requiring a walkthrough?
>
>to everyone's program.
>
>The walkthrough is a safety net for new authors. It not only ensures that
>their games will be posted in a winnable format, but it ensures that even
>if their game is too hard, some folks will use portions of the walkthrough
>in order to see the end of the game, which might be very well written, and
>so the game will not suffer as much as it might otherwise. It is very
>difficult for a new author to judge how hard their puzzles are. The
>contest is primarily designed to draw in new authors. QED, the rules are
>geared towards new authors. Everyone else just has to suffer along for
>the cause.
If it's for their own good, then why make it a rule?
Make it a suggestion, and if they break it, be it on their own head.
Phil
Phil Goetz
In article <55tmc1$e...@news.dx.net>,
Greg Falcon <professo...@pnx.com> wrote:
>PS. I don't think the rules should have to say a single thing about
>randomness. Just specify that the walkthrough must be a simple list
>of commands that always works. (In other words, no "wait for this to
>happen, then do this" lines in the walkthrough.)
Why not allow such lines?
I would rather just require the walkthrough to work,
assuming the reader has intelligence great enough to download the program.
Phil
Andrew Plotkin
> to everyone's program.
Deterministic random events is a little more than that, though; it
affects the feel of a game, and potentially makes it harder to debug. (I
mean, turning randomness back on at the end of the contest may unleash a
slew of bugs that happened to never get triggered in the contest version.)
> The walkthrough is a safety net for new authors. It not only ensures that
> their games will be posted in a winnable format, but it ensures that even
> if their game is too hard, some folks will use portions of the walkthrough
> in order to see the end of the game, which might be very well written, and
> so the game will not suffer as much as it might otherwise. It is very
> difficult for a new author to judge how hard their puzzles are. The
> contest is primarily designed to draw in new authors. QED, the rules are
> geared towards new authors. Everyone else just has to suffer along for
> the cause.
If the point is to make a safety net, why not make it optional? Tell
authors, look, players won't be very impressed with your sparkling prose
if they never see the last 75% of it. Including hints or a walkthrough
will prevent this problem.
And if your walkthrough isn't clear enough for the average jerk to follow,
it'll be as if you didn't put one in at all, right?
And if there's a bug in your game which makes it unwinnable, you're going
to get *really* lousy scores.
I think most authors are capable of coming to their own conclusions,
given that sort of guideline.
Actually I think this year's contest is working well with the "you must
have some kind of hint or walkthrough thing." I've played a lot more game
than I would have if there had been no hints (or if I had any kind of
willpower. :-) But I think it would be sufficient to tell authors "A
walkthrough is a waste of time if the player can't follow it; and
unwinnable games suck."
Dan Shiovitz
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
[..]
>I think most authors are capable of coming to their own conclusions,
>given that sort of guideline.
>
>Actually I think this year's contest is working well with the "you must
>have some kind of hint or walkthrough thing." I've played a lot more game
>than I would have if there had been no hints (or if I had any kind of
>willpower. :-) But I think it would be sufficient to tell authors "A
>walkthrough is a waste of time if the player can't follow it; and
>unwinnable games suck."
Yeah. I think it's probably a good idea to make the rules only be those
things that absolutely must be rules (like the anonymity thing .. it doesn't
work too well if only some people are anonymous, like this year or last
year), and make everything else just be "strongly suggested by the
organizers, especially if you're a new game designer."
>--Z
Joe Mason
"[CONTEST] Planning for 19", declared Gerry Kevin from the Vogon ship:
GK>5. Your game must not have your name listed anywhere in it, or its
GK>accompanying package. You must contact me to get an author
GK>registration number, which you will then use in the copyright notice
GK>like "Copyright 1997 by I-F Competition Committee, Author #001-001.
GK>For identity verification, I can be reached at: blahblah."
Uh, I'm joe....@tabb.com. I doubt my identity would remain very
secret if I put a contact address on there... :-)
Joe
joe....@tabb.com
Shad Valley Carleton '96
-- The 1996 Interactive Fiction Contest is now open! --
-- From Oct. 30 to Nov. 30, vote for the best of '96 --
-- ftp://ftp.gmd.de/if-archive/games/competition96 --
ž CMPQwk 1.42 9550 žSoftware Independent: Won't work w/ any software
Jason B Dyer
Gerry Kevin Wilson (whiz...@uclink.berkeley.edu) wrote:
: Re: Win Game. You Win!
: There is one thing that will discourage this. I will eat anyone who does
: it. No really, I'm serious.
"A Change in the Weather" did this. Go west from the very
beginning.
Jason Dyer
jd...@u.arizona.edu
Walter OGrady
In article <17437...@elvw.demon.co.uk>,
That would certainly make it easier for people like me who keep
everything related to the contest in one directory and download
the whole lot in one go. I'd have to manually rename all the
WALKTHRU.TXT files as I got them to avoid writing over the existing
ones, and that would be kind of a drag. It would be so easy to forget
and lose one.
- Carrie
wog...@chass.utoronto.ca
bout...@blade.wcc.govt.nz
In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew Plotkin) writes:
>Gerry Kevin Wilson (whiz...@uclink.berkeley.edu) wrote:
>
>> their games will be posted in a winnable format, but it ensures that even
>> if their game is too hard, some folks will use portions of the walkthrough
>> in order to see the end of the game, which might be very well written, and
>> so the game will not suffer as much as it might otherwise. It is very
>> difficult for a new author to judge how hard their puzzles are. The
>> contest is primarily designed to draw in new authors. QED, the rules are
>> geared towards new authors. Everyone else just has to suffer along for
>> the cause.
>
>If the point is to make a safety net, why not make it optional?
I'm a new author - just let me say this about that...
I'm inclined to agree with this. I hate walkthrus and would never use them under
normal circumstances. Even in the competition I have tried to avoid using them.
This could be taken as sour grapes - as I stuffed up the walkthrough for Piece
(the game is still winnable - but a walkthru command got lost during a late
night edit - folks can e-mail me for it if they really want to). Yet I have my
reasons. The main one is that I don't think you get the same sense of a puzzle:
its difficulty, its relevance and its integration into the game's framework,
if it is handed to you on a plate.
IMNSHO, people should be judging as players, and basing their judgements on the
same criteria as a person who wasn't playing the competition release. If a game
turns you off from the word go - turn it off. If it makes you intrigued - play
on. If you immediately use a walkthru at the first hurdle
(onlytwohours-musthurry) you're judging the fiction - but not the
interactivity. A puzzle is more than just its solution. It's subtle clues and
responses - it's trial and (hopefully meaningful) error. You lose that with a
walkthrough. You might get the later text of the game - but you might also miss
the context of the puzzle itself - which makes it hard to judge the game on at
least some of its potential merits.
If you had no walkthrus - and people posted questions to r.g.i-f or whatever,
authors would get a much better idea of the 'difficulty' of their games.
> But I think it would be sufficient to tell authors "A
>walkthrough is a waste of time if the player can't follow it
[somewhat chastened voice] um, yeah. The best laid plans of mice and me and all
that.
; and
>unwinnable games suck."
>
>--Z
heh, heh, heh (man, I wish I could start talking about some of the contest
games in raw, unbridled detail - roll on december)
-Giles
Walter OGrady
In article <1996Nov11....@wcc.govt.nz>,
<bout...@blade.wcc.govt.nz> wrote:
>
>IMNSHO, people should be judging as players, and basing their judgements on
>the
>same criteria as a person who wasn't playing the competition release. If a
>game
>turns you off from the word go - turn it off. If it makes you intrigued - play
>on. If you immediately use a walkthru at the first hurdle
>(onlytwohours-musthurry) you're judging the fiction - but not the
>interactivity. A puzzle is more than just its solution. It's subtle clues and
>responses - it's trial and (hopefully meaningful) error. You lose that with a
>walkthrough. You might get the later text of the game - but you might also
>miss
>the context of the puzzle itself - which makes it hard to judge the game on at
>least some of its potential merits.
Speaking as a player, I'm all in favour of walkthrus, or better yet
online hint systems. Sure it would be great to muck about with trial
and error as I would in an ordinary large game, but in a small (and as
you say, rushed) game there just isn't the time. I've avoided
walkthrus as much as possible -- who wouldn't -- but sometimes I'll be
stuck on one puzzle that, when solved, will let me sail through the
rest of the game. It would be so frustrating to have to give up on a
perfectly good game because of one small oversight that messes up a
key puzzle.
>If you had no walkthrus - and people posted questions to r.g.i-f or whatever,
>authors would get a much better idea of the 'difficulty' of their games.
Hopefully this will all come out in the post-judging discussion. What
walkthrus are really useful for, IMO, is not so much solving puzzles
as getting used to the author's idea of what's "logical," which can be
pretty whacked-out. Once you've glanced at the walkthru one or 2
times and thought "That's ludicrous, but at least I see how he/she is
thinking" you're less likely to need to look at it again.
- Carrie
wog...@chass.utoronto.ca