Here are some tips for competition participants on how to make the best of their entry.

Plan further than the intro

This is perhaps the most common sin of IntroComp entries: the author has not designed the game beyond the entry itself, which makes it hard to continue building the full version.

It would be wise to have the story and gameplay thought out at least twice as far as the actual intro, preferably all the way to the end, at least conceptually. This includes visioning what happens immediately after the intro ends and what is the overall story structure: the intro is the beginning but what happens in the middle and how the full story is resolved in the end. Otherwise there's a good change that the intro ends in a creative dead end with no easy way forward.

It's not hard to tell if an author has planned the story beyond the intro. Intros with short term design are often tightly self-contained and convey no feeling of there being something else beyond what you see. When the world and the general plot is well thought out, it's almost automatically visible in the resulting work. (See also a previous article discussing the subject.)

Start with the relevant story

Sometimes the word "intro" is taken too literally and the entry ends before the actual story even gets to start.

A fictitious example: Your story is a retelling of the 12 labors of Hercules. A good intro would contain the first labor to its completion; it would give a good indication of how the gameplay works and judges could easily imagine what the rest of the story would look like in its full version.

A bad intro would be about Hercules packing his backpack and a puzzle about finding a map for the location of the Nemean lion, and it would end just after reaching the entrance to the lion's cave. It would tell very little about what the game is actually like.

So cut off everything that's inconsequential to the big picture and start right from the action.

Make a proper ending...

Even though we're talking about introductions, it's still important that the entry reaches some kind of conclusion of its own. Sometimes that's easy to do when the story can be neatly divided into independent scenes (like in the 12 labors of Hercules example), but sometimes you'll have to work harder to find a good place to end the intro.

As a rough generalization you'd have one or two short term goals that are resolved during the intro while the overall goal is both left unresolved and made clear to the player.

...but leave some loose ends untied

This comes back to the "plan ahead" advice. Even though it's good to resolve a short term goal or two, there should be some kind of hook that makes the player want to continue playing the finished work.

A cliffhanger is a traditional way to end the intro, but it shouldn't be the only hook. As said before, the intro's purpose is to build expectations for the full version. It shouldn't be self-contained: leave room for future expansion. A couple of locked doors, interesting inventory items with reuse potential, references to NPCs not yet encountered. Anything that makes the player's imagination run wild.

Remember though that it's important that you as the author know where the loose ends are going – you can't just drop a locked door somewhere without knowing where it leads. Anything that serves a purpose usually comes across as such in the writing, whereas pointless scenery is often easy to spot.

Have the entry betatested

While technical issues are not explicitly in the judging criteria, bugs and spelling mistakes will reflect poorly on the entry. After all nobody wants to play a buggy game and the intro is taken as an indication of the finished entry's quality.

You don't need a whole army of testers, one or two should be sufficient for a short intro (although more is always better.) It's easier to find testers for IntroComp entries than for many other games because potential testers know that the game should be short and therefore doesn't require a huge time commitment. Testers can be recruited from the beta testing site or from the intfiction.org forum, among other places.

Remember that choice-based entries need testing too for things such as spelling, tone, and pacing.

So, how did the number of testers affect the final rating? Here's a handy scatter plot chart.

The correlation looks quite clear, doesn't it? One game had 15 testers, three games had 16. Those all ranked from 2 to 5. Only the winner had a little bit less -- 9 (but it did have two authors, when the design and testing process might arguably be a bit different).

Conversely, the bottom three had no testers at all. The other two games that had no testers ranked 18th and 19th, only two games separating them from the other untested works.

Here's the same with bars:

The correlation becomes even more clear when we compare the number of testers to the average score of each game:

I don't think I have to spell out what the lesson is to be learned from this data.

* Note that it wasn't easy to get an absolute number of testers for some games. Yon Astounding Castle named one tester and mentioned "anonymous testers", but not their amount. Condemned and Beta Tester did not credit any testers in-game (boo) but evidence elsewhere on the Internet reveals that they had testers. Both have been marked down as having one tester, but in truth they could have had much more. Many other games credited people for tools they had made, inspiration, technical support or other help. These are not counted in the numbers. If you have more accurate information, please let me know so I can update the charts.

Update: The author of Yon Astounding Castle confirms that there were 4 testers total.