Guidelines for IFComp authors

This is a page of advice, not rules. (We do have rules, and you should read those too, but they’re not this.)

Following these guidelines will make it more likely that your game will earn a certain basic level of respect and interest among the IFComp’s judges and reviewers. Even if your game doesn’t take a major prize home, it will still be better positioned to receive positive attention and discussion during the comp and beyond, and in so doing will make your own participation in the comp as an author more worthwhile.

Playtest your game and credit your testers

If you apply no other guideline on this page to your IFComp entry, please consider applying this one.

Every work of interactive fiction, no matter the format, style, or experience level of the author, benefits enormously from playtesting prior to its first public release. We strongly recommend that authors always send their work through at least a round or two of testing – and subsequent improvement, based on feedback – before submitting it as entries to the IFComp.

What “testing” means varies depending upon the nature of the IF at hand. A complex, puzzle-laden work in a classic text-adventure mode might best benefit from weeks of rigorous, iterative testing, fixing, tuning and re-testing as a volunteer quality-assurance team scrambles all over the game, trying to break it as much as trying to solve it. On the other end of the spectrum, testing a story-focused work would likely focus more on the quality of the prose than on the underlying mechanics, scrutinizing the narrative branching and providing feedback about how meaningful the choices felt.

However you choose to test, the mere act of it will all but guarantee that the work you submit to the competition shall be immeasurably more polished and ready for public scrutiny than a wholly untested work.

You can recruit testers from your friends and family, or use resources like the intfiction.org forum to find helpful volunteers from the IF community. (Don’t forget to include your blurb in your call for testers, and ask testers to review your blurb, in addition to the game itself.)

Once they become active, please credit your testers within your game. Conspicuously display their names in a manner appropriate to the work, such as in a “Credits” link in a hypertext game, or via the ABOUT command in a parser IF. Not only is it the right and proper way to acknowledge all the time and attention they spent to help improve your work, but it clearly communicates to players that you cared enough about the game to have it properly playtested. Some IFComp judges will refuse to play or review games that don’t clearly identify any playtesters, dismissing them – and not without justification – as not worth their time.

And finally, please do not just post your would-be comp entry someplace public and invite the whole internet to come test it – we consider that a release, and released works are disqualified from entry in the IFComp. As long as you know exactly who played your game prior to its competition entry, then all is well.

A few additional thoughts related to testing:

In a text game, spelling and grammar mistakes are bugs. Worse, since they’re sitting right there on the surface, they can signal a level of carelessness that can make players lose faith in your game quickly. The author may have truly poured their soul into a work, but if they spell its wrong three times on the first screen, players become less likely to dig deep enough to find it.
Playing your game yourself does not count as beta testing. As the author, you willingly forego the ability to see your work with the same perspective as a reader approaching it with no foreknowledge. Of course you’ll “play” your game quite a bit while developing it, and you will find and fix plenty of flaws on your own. But you need people who are not you to play the game precisely because they lack your knowledge and expectations about it. They will uncover subtle confusions, unintentional surprises, and other problems that you would have never spotted by dint of being so close to the creation.
All this counts double for parser games. Because they accept free-form input from players, parser-based IF works should be subject to especially rigorous testing. Good testers will find suggested directions that don’t work, valid actions that produce incorrect results, and unimplemented scenery objects. Good authors will fold this feedback into a new release, which they will re-submit to further testing, and again, and again.

A thoroughly tested parser game can provide a uniquely sublime interactive fiction experience to new players. It gracefully anticipates and guides player action, and responds to most any reasonable player command, thanks to the hard work of its beta testers (and, perhaps, initial rounds of post-release players) – combined with an author diligent enough to continually improve the work based on all that feedback. Players will respond with surprise and delight.

The very same parser-game concept released without any testing at all, however, will very likely only frustrate and stymie players who will, without exception, quickly wander from the author’s expected path and encounter countless undescribed objects, broken exits, and missing synonyms. These players are unlikely to think highly of the experience.

No matter the style of your work, before submitting it to the competition, please do take the effort to have it playtested.

Include a walkthrough if your game is puzzly

If your work contains puzzles or other game-elements where a reasonable player might get stuck and not know how to keep playing, please include a walkthrough alongside your IFComp entry.

While you of course want all players of your game to work through the whole thing on their own, providing a walkthrough lets judges who do get stuck continue playing through your game, instead of helplessly giving up partway through. (Keep in mind the two-hour time limit that every judge has to form their official opinion on each game.)

You may wish to include a built-in hint system, should that suit the style and scope of your game. Thorough playtesting can reveal ways your game might subtly guide players to find puzzle solutions by themselves. But even in these cases, pairing your entry with a simple walkthrough file remains an effective way to guarantee that all judges will be able to play through your entire entry.

Write a strong blurb

Every IFComp entry has a blurb: a short paragraph or two of text displayed as part of its basic description on every comp year’s list of entries. After the game’s title and cover art, the blurb is the very first part of your game that a player will experience, prior to their actually playing it.

Like the relationship a film trailer has with its movie, a good IFComp blurb exists outside of the game’s story, but offers a taste of what players will experience through it. The best comp blurbs pique judges’ interest, putting them into a positive, receptive attitude as they begin playing.

Good blurbs can also act as epigrams that tie the whole play-experience together. Judges are likely to revisit a game’s blurb after they’re done playing it – as they return to the website to vote, say, or to choose their next entry. A good blurb can in this way function as a parting summary as well as an introductory teaser, helping judges remember and reflect upon their experience with the game right as they’re ready to submit its ranking.

Feel free to browse past years’ blurbs, noting the various approaches that high-ranking games’ authors have taken. They include pithy one-sentence teasers, evocative quotes from history or literature, and short summaries in the style of a paperback novel’s back cover, among others. Blurbs have no set format, other than brevity.

Get creative and craft a blurb appropriate to your game that will draw players in, making them hungry to see more, and suggesting its worthiness as an investment of those players’ time.

Ask your playtesters to review your blurb, including its content warning. Ask what excites them about the blurb, ask whether it accurately describes the game they tested, and ask whether there are any interesting features about the game that you have omitted.

You can also ask people who haven’t played your game to review your blurb. You can’t post your game publicly before the competition starts, but you can post your blurb publicly, allowing you to get feedback from folks who aren’t already familiar with your game. This way, you can find out whether the blurb is exciting (or whether it even makes sense) to people who haven’t played your game yet.

Use an IF authoring tool

The most well received and best remembered entries to the IFComp, almost without exception, make use of software specialized for creating IF works, such as Twine or Inform. The various tools aren’t all means to identical ends; different authoring systems are tuned for making different varieties of IF. You should choose a tool based on the kind of experience you want your game’s players to have.

If you want to make a parser-based game, look at systems like Inform or TADS.
Hypertext designs can use systems such as Twine or Undum.
For choice-based designs outside of hypertext, consider something like ChoiceScript or inklewriter.

For a more detailed summary of the relative strengths of several popular IF authoring tools, please consult this comparison by Matty Gibbons.

If you wish to submit a work that you created from scratch, please do! We only suggest you keep in mind that giving the player of an interactive story a good basic experience is hard, a software design problem at least as difficult as – and, in many circumstances, entirely separate from – the creative challenge of communicating an engaging story. Using an existing IF tool allows authors to worry less about the technology and focus more on the fiction.

Submit only finished work

It’s true that the IFComp has a deadline for entry, but do not confuse this deadline with an impassable point of make-or-break failure. If the deadline for submission approaches (this year it's August 28) and your project feels like it still has miles to go, consider aiming for a later competition instead – the Spring Thing, perhaps, or even the following year’s IFComp.

Not finishing your project when you first meant to, and watching the year’s parade of comp games march past without yours among them, can feel disappointing. However, the satisfaction of seeing that same project finally completed more than makes up for it.

Resist the temptation to either submit an entry you know is unready, or abandon it as a failure simply because the year’s deadline passed. Take the time you need to finish your work before submission, even if it means holding it for the next go-round. You’ll feel prouder for it, and the judges will appreciate the better game, too.