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.

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 game-testing.org or the intfiction.org forum to find helpful volunteers from the IF community.

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:

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

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.

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.

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.

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.

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 October approaches 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.