This was originally posted to rec.games.int-fiction.
These are some tips for entering the competition in general. I have plenty
more I could say about actually writing the game, but I’m even less an
When you get your game beta tested (and it’s a given that you intend to),
have them run transcripts. Not everything that can go wrong in your game is
going to look wrong to players. Or they’ll forgot to mention it.
When you get yoru game beta tested, try to pick up a couple testers that
are familiar with Interactive Fiction. In the past, I’ve recruited testers
who like text adventures, but aren’t really familiar with what most players
are going to expect. Newbie testers will let a lot of things slide that comp
judges won’t, and having experienced people help you is a great asset.
Remember that people are judging your game. The seven hundred hours you
spent writing it will only count for something to a very small number of
them. Even the winners get criticized by some. Brace yourself for the worst.
If you’re in a crunch, aim smaller. What I’ve found is that judges tend
to like games that push or exceed the two-hour rule, but they look more
favorably on a well-written short game than on a sparse one that’s longer.
Writing a well-implemented longer game is by no means trivial. If you intend
to do so, and you haven’t already started, then either (a) it’s already too
late, or (b) you better be working on it twelve hours a day until the end of
Entering your game into the IFComp can be the greatest way for a new
author (perhaps even an established one) to get exposure. What I’ve seen is
that your game is likely to get far more play in six weeks than it would
otherwise get it six years. But, see tip #3.
Some people win or rank really highly (and I mean, like top 5) in their
first time out. Most don’t. Many are probably discouraged from ever writing
IF again, because the feedback you get can be brutal. Consider any ranking
in the top half great, and in the top 10 amazing.
Play games from prior competitions. I’d suggest playing the winner,
another game or two from the top ten, and a couple from the bottom half,
just to see what works and what doesn’t. You might consider playing the
competition version of games that have been updated, if you really want to
see that product that people were judging.
Don’t write your game in a programming language that isn’t specificially
structured for Interactive Fiction. Judges – especially those already
familiar with IF – will be biased against them before they even start. I’ve
done it both ways now. It’s worth planning ahead and learning an IF
language, than to spend that much effort trying to home-brew an engine that
will probably only serve to cripple your game anyway.
Play the other entries, when voting begins. You can’t vote, but you can
review and share the experience with your peers. Plus, it might take your
mind off the dreadful 6-week wait, where nothing is being said publicly
about your own game.
Calculate your risks. Judges – especially the ones trying to beat the
deadline and play all entries – are likely to get cranky and burnt out
toward the end. Your game may be played toward the end. If you don’t have to
make things difficult for players, then don’t. Two hours isn’t much time to
solve a difficult game. Experimental games can work in the IFComp, but
they can just as easily fall flat.
In addition to playing prior games, read the reviews from prior years. A
large number of last year’s reviews have been collected at the IF Wiki here:
ifwiki.org/index.php/11th_An … n#Reviews.
Often, what advice the reviewers give can help you spot pitfalls in your own
WIP, especially if you see a recurring complaint about a particular game.
Be original. A generic setting can work if it has a point, and if the
story is interesting and well-told. A familiar theme can work if it’s
unexpected or uncommon to interactive fiction. If your setting seems
generic, isn’t told in an entertaining way, and is of a theme that’s
overused already, consider it three strikes against you.
Have a story, not just a collection of arbitrary puzzles. In keeping
with that, try to make the puzzles as non-arbitrary as you can (assuming
your “game” will even have puzzles, which isn’t absolutely necessary).
Avoid long text dumps. And if your cutscenes can be interactive, they
might be better off to be. You can’t make everything interactive, but believe
me, judges tend to frown on a “text dump” that is more than a couple long
Jason Devlin, last year’s winner, also added:
- When you get your game beta tested (and it’s a given that you intend
to), have them run transcripts. Not everything that can go wrong in your
game is going to look wrong to players. Or they’ll forgot to mention it.
Transcripts are great, but annotated transcripts are even better. If your
betatesters don’t mind, ask them to put specific points in as they play the
game. Usually it works to just type the comments as a command prefaced by
“@@” (or some other suitably rare combination) for easy searching. This
let’s them make simple notes as they’re going and also let’s you see exactly
what the problem is.
Have a clear focus throughout your game. You don’t have to set up the
complete plot in the introduction, but you should give the player a clear
idea of what they should be doing. Set an immediate goal, and when that’s
done, set another. They don’t have to be major, just clear. It’s one thing
as a player to know what you want to do, but be unable to do it. It’s
another thing entirely to have no idea.