Competition Entry - ThePix/QuestJS GitHub Wiki

Competitions can be a good way to reach a wider audience for your Quest adventure, but you better be prepared to be judged harshly...

Probably the most significant Interactive Fiction competition is IfComp, run during October each year, and this page is mostly geared towards that. It will not guarantee your game is a winner, but hopefully will improve its ranking to some degree. IFComp gives cash prizes to anyone in the top two thirds, though decreasing amounts!

I originally wrote this in 2013 for Quest 5, and have updated it slightly, and now moved it to the Quest 6 documentation. My game The Myothian Falcon was placed 24th out of 38 entries in IFComp 2011 (hey, it was high enough to get offered a prize), while The House on Highfield Lane, written in QuestJS, came 17th out of 71 in IFComp 2021. I have beta-tested a few entries two, including a few got placed in the top ten.

That said, obviously, this is just my opinion.

Note: Most competitions are only open to games that have not previously been released. This means you can only enter your game in one competition (though IntroComp muddies the waters...). It also means you have to ensure you do not make it publicly available before hand.

Starting Out

Before you start creating, think about your game:

Time

IFComp requires that games can be played in two hours. This is a practical necessity with dozens of games submitted each year. There were 81 in 2019 - that adds up to nearly of week of solid playing time! They do not have time for longer games. Aim for a 1.5 to 2 hour play time.

If you do exceed that, however, I would not worry about it too much. Better a longer game if that is going to work better. The form for IFComp will ask how long the game is - be realistic so players know what to expect. If you tell them it will take four hours, you will tend to get players who want to play longer games, and will judge your game better..

Originality

Try to create a game that stands out from the crowd, something with a novel hook to it. Perhaps easier said than done, but take a look at previous winners to see what I mean. Talking of which…

Easy Puzzles

Do not make the puzzles too tricky. With only two hours playing time, if a user gets stuck on one puzzle, she might not find half your game. Of course, you need some challenges, the trick is to get the balance right (and to honest, I probably failed to do that in my entries).

Adding hints may be a solution.

Compare to Other Entries

Take a look at some other entries from previous years, and see what works and what does not. See what the standard is. Just as important, read the reviews and see what the judges think worked and what did not. Think if common criticisms might also apply to your own work, and modify it accordingly.

Keep it simple

A complex game takes more effort to create, longer to play and - most importantly - far more effort to properly test. If there is a single route through your game, all your testers see everything. If there are numerous branches, lots of items to manipulate, alternative approaches to puzzles, there will be gaps in your testing, and players will find them.

In IFComp you are up against CYOA games that might only have three branching points. These things can be knocked out in three days, and thoroughly tested by just a couple of people, and judges will still see a polished, well-written game, and - unlike your - it has no bugs.

Implementation

Help, Hints and Walk-through

Include some in-game system to help users get to the end. They only have two hours and if they are stuck on a puzzle with no way to cheat, they just will not see the end of your game. Make sure the clues are both good (easy to follow) and comprehensive (cover all possible problems).

IFComp recommends a walk-through to prove the game is winnable, but a long list of commands is actually pretty useless to the user. Providing a walk-through that tells the user what to do, rather than what to type, will ensure they can get to the end and hopefully still enjoy the trip.

See here for some ways to do hints.

About

Include an “about” command, so you can tell people who wrote the game, and give thanks to anyone who helped you. It should include a version number - and that should be modified when new versions are released, once you get to beta-testing.

Credit beta-testers here; you may be marked down otherwise. Seriously!

Implement Everything

Every object mentioned in the text should be implemented as an object that can be looked at in the game. if that description mentions something, implement that too. Seriously. I had someone - a player, not a beta-tester - complain I had not implemented "nose" and "hair" because the player-character's description mentioned them.

If you use ASK/ABOUT with NPCs, think about all the topics they could be asked about. Any puzzle for one thing - if the user cannot work out how to pass the troll, she is likely to ask everyone about the troll.

Also aim to implement all the common commands such as “jump”, “xyzzy”, etc., even if they are not relevant. Default and error responses are bad.

Think about what else players might want to do - if there is a beach, they might want to build a sandcastle, if there is a stage, they might want to act or dance. These are real examples beta-testers wanted to do in my game!

Or submit a game without a command line...

Feelies

Some games include feelies. Back in the day, commercial adventure games included posters, comic books, scratch-and-sniff cards, etc. to limit piracy as much as anything. Nowadays, these feelies are virtual… so you cannot actually feel them. Nevertheless, they seem to be popular, and can help to give a game a profession touch.

Unfortunately, it is easy for users to miss feelies; if they play on-line, they just will not know they exist, so make it obvious. One way is to put a link in the text to another file (use a relative address, and put the file in the "game" folder; see here for an example).

The Text Adventures website has support for cover art built-in; IFComp does similar.

The User Interface

Think carefully what elements of the user interface (UI) you want to include. By default, Quest includes a command line and the panes on the side, and you can also add hyperlinks too. Are they all appropriate to your game?

Turning off the command bar will make it much easier to build your game, as you very much limit what the player can do, but at the cost of destroying the illusion of freedom for the user. On the other hand, for a traditional game, you might prefer to have only the command line.

Also think about the colours and the font. Be sure to pick a font that reflects the style of your game, and is easy to read. Some users prefer white on black; check how your game looks in DARK mode.

The important message here is to think about the UI, and make a choice for what is right for your game, and not just use the Quest defaults.

Testing

Beta-testing is getting other people to play your game before you release it. It is absolutely vital; they are sure to find spelling mistakes, objects you have not implemented, verbs you have not thought of, routes through the game you have not considered. Better these things are found during beta-testing than after a release, and especially during a competition.

Before Beta-Testing

It is tempting to get the game to beta-testers fast, but you are really just wasting their time and yours if you know there are problems before sending it. So play the game through and correct any mistakes you can find.

There is a list of things to check for here.

All that said, if the competition deadline is approaching, you might want to start beta-testing earlier, whilst still working on certain sections of the game. Let the testers know what is a work-in-progress (you can flag a room by settings its "todo" attribute).

Beta-Testing

When you are ready for beta-testing, set settings.playMode to "beta", and then publish your game as normal, but ensure it is "Unlisted" if using textadventures.co.uk; itch.io has a similar option. This is important as the rules of IfComp mean your game will be disqualified if it is released openly before the competition. An unlisted game will not appear on the Text Adventurers web site, but you will be able to give your testers a link to the game.

I allowed three months for beta-testing for my 2021 IFComp entry, and had fifteen testers. There were well over twenty versions released for testing! For a 2 hour parser game, this worked well - I would not advise trying to do it in less than two months. For a non-parser game (i.e., no text input), you may find it can be done faster.

Be aware that as the deadline for IFComp approaches, testers can be hard to find. Also be aware that they vary in quality. You may get some who offer help but never send you anything, while others will be happy to test various versions and offer plenty of advice.

Credit Your Testers

Remember to credit your testers; they worked hard too. If this is for a competition, you may get a lower score if you do not, as people will assume the game is untested.

Blurb and cover

IFComp had over 100 entries in 2020, and just getting people to play your game may be an issue. Therefore you need to craft your blurb and cover too. Note that it is important to accurately reflect your game; you want to attract users who enjoy this type of game. A more in-depth discussion here.