Hints to budding IF Comp entrants
BrettW
judges, I'd like to offer some hints that I learned from entering the
IF Comp last year. As a quick recap, I entered my first game "Mix
Tape". It got equal 18th place out of 36. This post is not about the
game itself, but what I learned from writing and entering it, so
please keep this in mind.
1. Betatest, betatest, betatest
You need to leave a lot of time to do betatesting. You need to have
several testers. You cannot test your game. Your friends who aren't
familiar with IF cannot test your game. Your mother cannot test your
game.
My mother didn't look at my game, but I failed on the other bits. In
the real world, I had one less week to work on the game because I was
going to a conference in the week before IF Comp was due. I knew this
and didn't plan accordingly. I was writing and testing until a few
hours before my flight left at 6am. While I caught a few bugs, there's
only so much you can do. You'll be too familiar with the game to bring
it close to the rough parts of the implementation. I had a few friends
giving me feedback under extreme time constraints, which was great,
but I should have allowed for more time, more testers and a few more
experienced testers. My personal feeling is that you need at the very
least a month before submission to test. This gives you and your testers
breathing space. It also allows you to implement cool additions that
make the game experience smoother.
Another way of looking at it: do not, under any circumstances, believe
that IF Comp judges are there to betatest your game or will be as
forgiving as your testers. I didn't personally feel this, but if
anyone gets the feeling that you didn't, couldn't or wouldn't betatest
your game before submitting it, you'll be torn to pieces.
2. Know your scope
IF Comp games can only be an hour's worth of play. If you leave time
for judges to look around, poke at the cool bits, and take their time
thinking about their review, then you'll do better. On the flip side,
don't try to stuff too much into your game. You have a deadline to
write to.
For those unfamiliar with Mix Tape, the basic premise was to tell a
break-up story as a mix of songs accompanying scenes. The game I
entered had (basically) 6 tracks. Throughout development the number of
planned tracks depended on the songs I wanted in, and some philosophy
regarding the best way to order a mix tape. I didn't think that adding
a single track added weeks worth of work. When the deadline quickly
approached a few tracks were ditched, and others had their
implementations cut drastically short. The original idea was to have
two sides (Side A and Side B) where one side was the break-up story
and the other was IF inspired by random songs. This was far too much
work and the game would have been too eclectic even if I did finish
that plan.
My approach was essentially the wrong way to go about it. Have a plan,
fulfil that plan and then maybe add more if you have loads of
time. This requires you to plan well ahead and know how much you want
or need to put into the game. Keep your scope tight and the game will
be more powerful as a result.
3. Know your audience
Judges come from all walks of life. Make sure your game appeals and
makes sense at a base level to everyone. Not everyone knows what you
know, and they may not get your in-jokes, jargon, references or
cultural assumptions. For example, if you write a sci-fi game, make
sure it's not only for hardcore sci-fi fans. A good way to do this is
to give the game a good story or characters. Beware that both of these
things should not rely on your genre. If you confuse or ignore your
judges, they will respond. Some will not rate your game. Some will
rate you harshly. IF Comp is for a wide audience. Respect this.
Mix Tape has a lot to do with music. More appropriately, it has a lot
to do with music I listen to. All the tracks I refer to are tracks I
own. All the bands I refer to I know. Most people wouldn't. It's fair
to say that very few people were familiar with all the songs I used as
the basis for my game. Part of the problem is that I referenced a band
called Little Birdy, which is pretty big in Australia, and maybe
Japan, but that's it. This meant that one of the foundation songs of
my game would make no sense to a lot of people, and so the whole
premise stumbled. I also had a few references to the reasonably
obscure Japanese band Cibo Matto. One reference can be ignored but I
made the frequency and prominence of the references too large. One
reviewer exclaimed in their review: "Who the hell are Cibo Matto?"
Pick your references well and make it accessible and not distracting.
Another problem Mix Tape had was that it was a break-up game. This
translates to a sad, emotional game. A lot of people got bummed out by
the theme and I didn't make it uplifting enough at the end (if the
player got that far) to redeem it. Make sure your players can take
away something from your game other than a bad mood.
4. Survive the judging period
You might feel exhausted from all that IF writing to judge any of the
games but your job isn't over. Play, rate and review the other games.
You'd want them to do the same for you. Give feedback to the other
authors. Thank anyone for feedback they give to you and take it on
board. When reviews come out, thank the authors for giving your game
a chance. This is not to suck up to anyone, but to give respect where
respect is due and to properly participate in the comp.
Luckily I did these things (for the most part). It helped me get over
the anxiety of my game being out in the wild and I didn't know if it
was worthy to be out there. I traded a few emails with Jason Devlin
who had some interesting comments and gave me some support (and I
tried to reciprocate). Comments from the other authors were
interesting and I think it's good to keep at least some
camaraderie. It's a competition, not a war. I personally tried to
thank everyone who wrote a review for Mix Tape, good or bad.
And on reviews, maybe I'm a glass-half-full kind of guy, but take
every review constructively. If they say good things, then good. If
they say bad things, then learn from it and make your game better. If
the reviews are useless rants, then leave them be. Most of the reviews
for Mix Tape were very useful to me and I've used them to plan the
rewrite.
5. Miscellany
And I'll finish on a bunch of points I don't want to elaborate on too
much. Some of these are obvious. Some of these apply to outside the
comp.
- Your game needs to satisfy two conditions: it has to be interactive
and it has to be fiction. Allow people to play around with it without
the game exploding, and provide a good story.
- Run your game through a spellchecker. A grammar checker if you
can. But most importantly, run it by several humans.
- Don't throw in puzzles for the sake of it. Keep your focus.
- Don't spend too much time implementing things that have little
impact. Focus on the story and the implementation of that story. If
you have time, then details. (See the CD collection and the old man in
Mix Tape for violations of this)
- Make your characters understandable, and likable if you can. This
especially goes for the PC.
- Catch everything you and your testers can think of.
- Implement helper verbs. Mix Tape had one good one (CHECK MAIL) and
missed an obvious one (SERVE FOOD).
- Test your game on a variety of interpreters and platforms. If you
find any problems, let everyone know via the Readme.
- Include a walk-through. Make sure it definitely works, exactly as
typed. Preferably make sure it works even if they use different
phrasings or do other things midway through the walkthrough.
- Consider a "full walkthrough" which is a transcript of the game if
you went through the walkthrough. Make sure the two are exactly the
same sets of commands.
- Add in as many hints as you possibly can. Make them adaptive if you
have time.
- Betatest, betatest, betatest!
Best of luck!
BrettW
Taz
Very good advice for all writers.
One thing I disagree with is that the characters have to be 'likeable.'
One example that springs to mind is Garf's 'Varicella.' The
characters were dynamic and interesting, but FAR from likeable. I
personally have a thing for utterly dispicable characters =D.
Chephren
BrettW wrote:
> Inspired by James Mitchelhill's recent post on bugbears for IF Comp
> judges, I'd like to offer some hints that I learned from entering the
> IF Comp last year. As a quick recap, I entered my first game "Mix
> Tape". It got equal 18th place out of 36. This post is not about the
> game itself, but what I learned from writing and entering it, so
> please keep this in mind.
>
This is all sound advice (especially the bit about beta-testing :-) ).
Some of the things you warn against shouldn't necessarily be avoided,
only marked handle with care. For instance, referring to things
unknown to the player. I think such usage can actually add to the
game, give it a more detailed and fleshed out feel. The problem is
where the game requires implicit knowledge to understand or complete.
I think this is what you were saying actually - that the game shouldn't
work solely at the level of obscure knowledge.
>
> Another problem Mix Tape had was that it was a break-up game. This
> translates to a sad, emotional game. A lot of people got bummed out by
> the theme and I didn't make it uplifting enough at the end (if the
> player got that far) to redeem it. Make sure your players can take
> away something from your game other than a bad mood.
>
I don't think a game has any requirement to be uplifting or positive.
I kinda enjoy gloomy and pessamistic stories (masochist I am). All a
game should avoid, like fiction, is being maudlin or sentimental, or
having a cheesy ending. Of course, this is a subjective judgement.
Likewise:
> - Make your characters understandable, and likable if you can. This
> especially goes for the PC.
I don't need characters to be understandable, or likeable. Maybe
understandable, in as far as believable. I only want characters to be
compelling, and interesting, to seem like they have a personality
beyond the requirements of the game.
Chephren
Eric Eve
"BrettW" <shor...@hotmail.com> wrote in message
news:op.tectsbgsy51jdq@ninja...
> Inspired by James Mitchelhill's recent post on bugbears for IF
> Comp
> judges, I'd like to offer some hints that I learned from entering
> the
> IF Comp last year. As a quick recap, I entered my first game "Mix
> Tape". It got equal 18th place out of 36. This post is not about
> the
> game itself, but what I learned from writing and entering it, so
> please keep this in mind.
>
> 1. Betatest, betatest, betatest
> You need to leave a lot of time to do betatesting. You need to
> have
> several testers. You cannot test your game.
I'm sure this is true in the sense intended, but at the risk of
stating the obvious, it may nevertheless be worth qualifying. There
is a sense in which you not only can but should test your game,
before you send it out to betatesters. It is, of course, perfectly
true that there will be any number of bugs your own testing won't
catch, so that betatesting by others is essential (and I take this
to be Brett's point here), but it is also true that there are a
large number of bugs you *can* catch with thorough alpha-testing
prior to the beta-testing stage, and this is worth doing too for a
number of reasons:
(1) The chances are that since you know your own game best, you
will catch some problems that your beta-testers may not find.
(2) It is kinder to your beta-testers not to burden them with a
game where everything seems buggy and the volume of issues that
needs reporting becomes tiresome.
(3) If you've dealt with all the issues you can find, your
beta-testers are left free to focus on the issues you couldn't find,
rather than becoming bogged down in problems you could quite easily
have identified for yourself.
(4) If your game is as bug-free as you can make it before your
beta-testers get to work, they may be in a better position to
comment on wider issues in the game (plot, characterisation,
setting, appropriateness of puzzles and the like), which they'll be
less able to do if they're faced with an annoying bug every other
turn.
I'm probably stating the obvious here, but it seems worth stating
since the need for good beta-testing is so often (rightly) stressed
round here that the need for good alpha-testing sometimes seems in
danger of being ignored. Indeed, although I don't have time to go
into right now, it might be interesting to start a discussion about
good alpha-testing techniques, since this is a topic that seems to
crop up relatively rarely.
-- Eric
Neil Cerutti
> I'm probably stating the obvious here, but it seems worth
> stating since the need for good beta-testing is so often
> (rightly) stressed round here that the need for good
> alpha-testing sometimes seems in danger of being ignored.
> Indeed, although I don't have time to go into right now, it
> might be interesting to start a discussion about good
> alpha-testing techniques, since this is a topic that seems to
> crop up relatively rarely.
I think a game author should use a transcript-from-walkthrough
test suite (a good IDE can make this easier, but command-line
tools work fine, too, with some manual configuration) to ensure
that everything he thinks he implemented works correctly.
I try to use a test-driven development scheme as far as possible.
This can become quite annoying in a game with lots of timers or
random events, though. There can sometimes not be enough time to
try out everything I implemented.
In other words, I write the string of commands I would like to
have work, and record a transcript of running those commands.
Next, I add implementation until the transcript works as it should.
After that's working, I try for "code-coverage", by adding
commands to elicit every message I've added to the game.
I7's transcript and skein is designed for this sort of
test-driven composition.
--
Neil Cerutti
The audience is asked to remain seated until the end of the
recession. --Church Bulletin Blooper
BrettW
> Some of the things you warn against shouldn't necessarily be avoided,
> only marked handle with care. For instance, referring to things
> unknown to the player. I think such usage can actually add to the
> game, give it a more detailed and fleshed out feel.
Definitely. I guess the point I was trying to make is: don't make it
seem important if it's obscure (or really not important).
> The problem is
> where the game requires implicit knowledge to understand or complete.
> I think this is what you were saying actually - that the game shouldn't
> work solely at the level of obscure knowledge.
That, and not to mislead players with it. Give players with no knowledge
of the stuff some sort of handhold, even if they don't appreciate the
reference or what-have-you.
> I don't think a game has any requirement to be uplifting or positive.
> I kinda enjoy gloomy and pessamistic stories (masochist I am). All a
> game should avoid, like fiction, is being maudlin or sentimental, or
> having a cheesy ending. Of course, this is a subjective judgement.
True. I guess: do whatever you like with your story, but make it
worthwhile. With Mix Tape some people commented that they could handle
the rough relationship stuff, but at the end, what for?
> I don't need characters to be understandable, or likeable. Maybe
> understandable, in as far as believable. I only want characters to be
> compelling, and interesting, to seem like they have a personality
> beyond the requirements of the game.
To be compelling I'd figure you'd have to understand their motivations.
They might not be particularly honorable or intelligent motivations,
but a player should know why they're investing energy in a particular
character. You don't have to agree with them, but you have to enjoy the
character in some way to make the IF experience worthwhile. Anti-heroes
can be fun, sometimes :)
BrettW
BrettW
beta-testing. Subconsciously I figure that alpha testing is part of
"writing the game properly". You should definitely check all the verbs
and all the obvious stuff. But beta-testing should cover the
nonobvious stuff so that it is presentable to a wide audience. I also
fib a little: an author can beta-test their game, if they put it away
for some time so they can play it with "fresh eyes". This is standard
practice in fiction writing. But having others look at the game is
essential - they will think of things and read passages in ways you
never would have.
I'd be interested to hear your ideas on alpha-testing. Do you think it
can largely automated?
BrettW
Erik Wennstrom
made.
BrettW wrote:
> 1. Betatest, betatest, betatest
> You need to leave a lot of time to do betatesting. You need to have
> several testers. You cannot test your game. Your friends who aren't
> familiar with IF cannot test your game. Your mother cannot test your
> game.
My mother _can_ and did test my game, and she did a damned fine job at
it. Granted, my mother has far more experience writing IF than I do
(see _Finding Martin_).
I did give my game to other people close to me who don't have any IF
experience, but that was only after I sent it two my two main testers (I
should have gotten more). More feedback is always good, even if it's
not the best feedback possible.
More seriously, I will definitely have to second the notion of leaving
yourself lots of beta-testing time. The first time I submitted my
MCDream mini-comp entry, I had left absolutely no time for betatesting.
Thankfully, due to a problem on my outgoing mail server, my game never
made it to the coordinator, and that hunk of ridiculously buggy crap
never saw the light of day. (Just thinking about it on an airplane the
next day, I found a fatal bug.) As it was, the second time around, when
the competition was extended into the next month, I wished I'd sent the
game to more testers, and earlier. I submitted the thing yesterday and
I've already found a few more bugs.
Erik
Eric Eve
> Definitely. I agree with the two distinctions of alpha-testing and
> beta-testing. Subconsciously I figure that alpha testing is part
> of
> "writing the game properly".
Yes, that seems to be fairly common, but I tend to think in terms of
a three stage model (writing, alpha-testing, beta-testing) rather
than a two-stage one (writing then beta-testing). Of course a great
deal of testing goes on in parallel with the writing stage - one
implements a new part of the game and then tests whether it works as
expected - but I find I do reach a stage where I've effectively
finished writing and move into intensive testing. For a short game
like "Dreadwine" or "Swineback Ridge" that may not take long, but
for a longer piece like "All Hope Abandon" or my current WIP, it may
be a matter of weeks rather than days, and so it definitely feels
like a stage in its own right.
> You should definitely check all the verbs and all the obvious
> stuff.
All the stuff that's obvious to the author, at any rate, or even
unobvious stuff it occurs to you. I found after having one game
beta-tested that I had a better idea of things to look for in
alpha-testing, and it becomes easier to approach your own game a bit
more like a beta-tester. You won't find everything that way, but you
probably can find more than the immediately obvious.
> But beta-testing should cover the
> nonobvious stuff so that it is presentable to a wide audience. I
> also
> fib a little: an author can beta-test their game, if they put it
> away
> for some time so they can play it with "fresh eyes". This is
> standard
> practice in fiction writing. But having others look at the game is
> essential - they will think of things and read passages in ways
> you
> never would have.
Agreed.
> I'd be interested to hear your ideas on alpha-testing. Do you
> think it
> can largely automated?
Not really, or not in general. At least, if you're thinking in terms
of running a script and checking the transcript, then you still have
to devise the script. Also, some games simply can't be thoroughly
tested with a single test-script because there are multiple
mutually-exclusive paths through the game (if only in terms of the
order in which things can be done).
When alpha-testing in TADS 3 I take advantage of the fact that a
transcript can be run through the 'terp as a script. So, once I've
got something that is basically playable, I play it through from
beginning to end, prodding and poking as much as I can along the
way, and annotating the transcript as if I were beta-testing. If I
encounter something show-stopping, I may have to fix it there and
then. Otherwise, I pay through to the end, and then have a
transcript (or series of transcripts) with a whole lot of notes
pointing out bugs, typos, inadequate room descriptions,
inappropriate responses, and anything else I didn't like along the
way. The list is usually substantial. I then work through the
transcript fixing all the issues, temporarily leaving to one side
anything that would change the flow. Once all these are fixed I can
run the old transcripts through the 'terp as a script and generate a
new transcript. This new transcript will automatically contain all
the annotations entered into the original one(s), so I can easily go
through and check that I have in fact fixed all the points I wanted
to fix (if I haven't, I then repeat the process until I have). At
that point I then fix any final points that might change the flow
(and hence render the original transcripts useless as scripts).
Having done that, I usually play through the game again, once again
recording a transcript, but taking a different route through the
game, and prodding and poking a few more things that hadn't occurred
to me first time round. This turns up a new (but hopefully shorter)
list of issues, which can be fixed and re-tested in the same way.
How many further iterations of this process I'd go through would
depend on the complexity of the game and the state of my endurance.
I generally reach a point where the law of diminishing returns
clearly feels that it's starting to bite and the piece really needs
a fresh pair of eyes. At that point I move from alpha to beta
testing.
So, an element of automation helps (if you include running
transcripts through the 'terp to generate new transcripts in that),
but the process overall requires a great deal of human input and
judgment. In particular, where there are multiple paths through a
game (if only because there's an element of freedom in the order in
which tasks can be accomplished, or even in which tasks need to be
accomplished) there can never be one single test script that
adequately tests the game.
As an aside, it's often in multiple-path issues that I find
beta-testing reveals big holes, since someone tries something in an
order I had never considered with dire results. This is one area in
particular where I find knowledge of how the game is meant to work
blinds me to some of the things other people might try, but this iis
moving back into the need for beta-testing.
But my overall point is that, at least the way I do it,
alpha-testing is not a purely mechanical process, but is often a
recognizable and often substantial stage in its own right.
-- Eric
Neil Cerutti
> True. I guess: do whatever you like with your story, but make
> it worthwhile. With Mix Tape some people commented that they
> could handle the rough relationship stuff, but at the end, what
> for?
Speaking of unrelenting dreariness, I watched "Unbreakable" for
the first time last night. Yikes! I can imagine being in the mood
to play games with that mood, but I hope it won't happen very
often.
--
Neil Cerutti
The doctors X-rayed my head and found nothing. --Dizzy Dean
Taz
> On 2006-08-16, BrettW <shor...@hotmail.com> wrote:
>
>>True. I guess: do whatever you like with your story, but make
>>it worthwhile. With Mix Tape some people commented that they
>>could handle the rough relationship stuff, but at the end, what
>>for?
>
>
> Speaking of unrelenting dreariness, I watched "Unbreakable" for
> the first time last night. Yikes! I can imagine being in the mood
> to play games with that mood, but I hope it won't happen very
> often.
>
Awesome movie - but I see what you mean. Very full on.
Emily Short
Eric Eve wrote:
> But my overall point is that, at least the way I do it,
> alpha-testing is not a purely mechanical process, but is often a
> recognizable and often substantial stage in its own right.
Yes. I also find it's useful to spend a little time playing as much as
possible like a player, *not* like a beta-tester -- that is, not really
trying to break things as such, but trying to get a sense for whether
the pacing is working, whether the tone is right, and so on. This is
hard for anyone but the author to test (because the beta-testers don't
necessarily know what feel one is looking for).
JDC
Emily Short wrote:
>
> Yes. I also find it's useful to spend a little time playing as much as
> possible like a player, *not* like a beta-tester -- that is, not really
> trying to break things as such, but trying to get a sense for whether
> the pacing is working, whether the tone is right, and so on. This is
> hard for anyone but the author to test (because the beta-testers don't
> necessarily know what feel one is looking for).
Regarding pacing: Has anyone tried to adapt the pacing of a game to
different play-styles? I'm thinking particularly of timed events, where
you want to give the player some time to explore before forcing him to
act. Some players will examine everything in sight, whereas others may
just read the room descriptions and look for the next puzzle. It would
be nice to somehow adapt timing so that the first player gets more time
to prod, and the second isn't bored.
I guess this is a similar problem to trying to figure out when the
player is stuck in order to provide an in-game hint. What techniques
have people used for this?
-JDC
Greg Boettcher
> Regarding pacing: Has anyone tried to adapt the pacing of a game to
> different play-styles? I'm thinking particularly of timed events, where
> you want to give the player some time to explore before forcing him to
> act. Some players will examine everything in sight, whereas others may
> just read the room descriptions and look for the next puzzle. It would
> be nice to somehow adapt timing so that the first player gets more time
> to prod, and the second isn't bored.
Yes, as I recall, the opening scene of The Orion Agenda did something
like this.
Greg
Jan Thorsby
Greg Boettcher
> Inspired by James Mitchelhill's recent post on bugbears for IF Comp
> judges, I'd like to offer some hints that I learned from entering the
> IF Comp last year.
My biggest advice to new authors hasn't even been mentioned yet, I
don't think. My #1 piece of advice is, play as many of the very best IF
games as you can.
For me, the worst of the IF Comp games aren't the ones that are buggy,
but the ones that wouldn't be all that interesting even if they were
bug-free. I guess such games could be due to a lack of imagination, but
I'm guessing it has more to do with not having played many good games
from the last 10 years.
The solution: play more good games. If you haven't played 5-10 of the
very best games yet, do that before playing whatever new game just
happened to come out.
What games are good? Visit these sites, read the comments, and figure
out what interests you.
http://www.mindspring.com/~emshort/literacy.htm
http://www.carouselchain.com/if/statistics.php?limit=50&type=vote
Greg
Greg Boettcher
> http://www.carouselchain.com/if/statistics.php?limit=50&type=vote
Oops, ignore that link and visit this one instead:
http://www.carouselchain.com/if/statistics.php?limit=50&type=rate
Greg
JDC
Jan Thorsby wrote:
> Have examine not take any time.
Wow. That's so much simpler than than the sort of things I had been
thinking about, and probably much more effective. Can't believe that
didn't occur to me.
-JDC
Gayla
Uh-oh, now I'm going to get blamed for the bugs I DIDN'T catch. Did
those undiscovered buglets get missed because I'm Erik's mother, or was
it just because I needed more time for beta-testing? We'll never know
the true story unless "60 Minutes" decides to do an investigation.
I can see the headlines on the Drudge Report now: "Beta-testing
Contract for Text Game Given to Mom; Halliburton Cries Foul."
Last week I heard that a plan is being discussed in the U.S. congress
to establish a family rating system for computer games. The proposal
will include a special category of games that you'd allow your mother
to play -- OFMTP will stand for "OK for Mom to Play." OFMTP games
aren't allowed to have too much violence and they aren't allowed to
have more explicit sex than the average romance novel.
There's some concern that the wording of the bill might not withstand
judicial review since some of the more recently appointed Supreme Court
justices think that Moms shouldn't be allowed to read romance novels
either.
So tell me, are there any families out there yet with THREE generations
of IFauthors? I suppose that's possible if reproduction starts at an
early enough age.
Surely there are techniques to encourage offspring to be interested in
interactive fiction.
But how early should this start? Are there audio transcripts of
classic text games whose sounds can be heard inside the womb in order
to imprint the rhythm of IF game playing as a comfort zone of the
natural environment?
> L
It's dark in here. You can't see a thing.
> OUT
You're not ready to be born yet. You probably should wait until you
have fingers.
> TALK
(to umbilical cord)
Your umbilical cord greets you with a friendly gurgle. Apparently Mom
ate Brussel sprouts for dinner again. You are reminded once again of
how much you detest Brussel sprouts and you wonder if you'll ever be
able to forgive her.
It's dark in here. You are likely to be eaten by a grue.
> ATTACK GRUE
(with placenta)
Nice try.
> STRANGLE GRUE WITH UMBILICAL CORD
Your attempt to strangle the grue with your umbilcal cord fails
miserably because:
1) I don't understand the word "strangle."
2) It's too dark in here to see anything.
3) You have no fingers.
4) All of the above.
> BURP
Under normal circumstances you wouldn't be able to burp in a prenatal
environment, but the beta-tester from Halliburton (unlike your mother)
has never experienced having his water break and therefore didn't
notice that the author left out all of the amniotic fluid that should
be surrounding you right now.
You give a loud juicy burp. Ah, that felt good.
The grue suddenly gets a whiff of Brussel sprouts. He decides that he
doesn't want to eat you any more and heads off to the east.
> N
You can't go anywhere right now. Mom is sleeping.
> KICK MOM
Mom is awake now. She goes north into the kitchen, opens the freezer,
and takes out a carton of Raspberry Cheesecake ice cream. After a
while your umbilical cord starts gurgling again and the grue comes
back.
> ASK GRUE ABOUT ICE CREAM
The grue is delighted to find someone that he can converse with on his
favorite subject, which happens to be ice cream. Apparently he used to
work for Ben and Jerry's in the flavor creation department, but on the
way home from work one night he was attacked by a gang of masked
Pillsbury doughboys. He tried poking the doughboys in the belly with
his finger in order to make them giggle, but unfortunately grues don't
have any fingers either.
After the attack the grue was so badly disfigured that he ran away into
the shadows and vowed never again to enter the light. Since then he's
been writing the score of a Broadway musical that will tell his tragic
story to the entire world and strip the masks off of the evil Pillsbury
doughboys.
The grue starts singing a song from his musical about ice cream
flavors. Even though you haven't got any ears yet, you realize that he
is badly off-key. You find yourself wishing that you could go somewhere
else. Anywhere else.
> S
Mom is sleeping again. An empty ice cream carton with a spoon has
fallen to the floor but you can't see it because:
1) You're inside Mom and the carton is outside on the floor.
2) It's too dark in here to see anything.
3) Your eyes are closed.
4) All of the above.
> KICK MOM
You miss.
However, the grue appreciates your gesture. He wanders off murmuring
about how he simply MUST write a final number for his musical involving
a kickline of masked Pillsbury doughboys.
> SLEEP
You fall asleep and dream about flamingo food.
When you wake up you discover that you now have ten tiny fingers, all
of which are so perfectly cute and adorable that when you finally get
born, a magical stupor will fall upon your parents. This will cause
your parents to feel compelled to take care of you for the next 18 to
21 years even though you will someday use those fingers to spill red
Kool-aid on the living room carpet and try to feed a hot-dog to the
cat.
> OUT
You're not ready to be born yet. You probably should wait until you
have elbows.
But since this game was written as an IntroComp entry, you don't have
to worry about elbows right now. We'll just save that for the next
trimester.
Let's just say that your dream about the flamingo food has woken your
Mom up and has given her a bad case of morning sickness. She runs
south to the bathroom.
*** YOU WIN THE GAME! CONGRATULATIONS! ***
Gayla
Happy Birthday, Erik.