Make Your Own

After learning a bit about IF and playing a few games, you might think to yourself: hey, I could do this! And the best part is: you're right. The modern IF scene is so vibrant largely because it's quite possible for a single author to build a game from start to finish. It's easy for new authors to get discouraged, however, so here's some advice to make sure your creation makes it to the finish line.

1. Choose a programming language
Your brain may be bursting with creative ideas, but a little groundwork at the beginning will prevent big problems later. The good news is, you won't have to reinvent the wheel in Java or Visual Basic; IF is blessed with a number of programming languages designed specifically for the job. These languages automatically handle tasks such as room creation, NPCs, inventory management, and the all-powerful parser – the code which turns English commands like "give brie to Emily" into useful in-game results.

The two most popular and supported languages are Inform and TADS. It's probably best to choose a language that was used to create games you enjoyed. Regardless of what language you select, Graham Nelson's Designer Manual, fourth edition, is full of advice and design tips for the budding IF author. Other helpful information can be found at IF link resource PARSIFAL.

Read about your chosen language. Study some example code. Look at the source code for some games. Experiment with the language by coding a small example game with a few objects and NPCs, perhaps set in your apartment or place of work. Please don't release your virtual apartment as your first game! Instead, take what you've learned and start in earnest on your main project.

2. Plan your game
There's no "right" way to plan a piece of IF. Some people start with a single room, expanding the game world with each new location, item, and character. Others begin by writing an "ideal" transcript for the entire game; a list of descriptions, commands, and responses a player might read as she plays from start to finish. Still others start with single puzzle or set piece vividly in mind, then reverse engineer the rest of the game from that initial idea.

No matter how you start, you might want to keep these design tips in mind as you continue. It's a good idea to draw a map as you add rooms to your game; in IF, what goes up won't come down unless you code it that way. Generally, your text should be brief and to the point; this isn't a Tad Williams novel, and long pages of non-interactive text bore most players. Remember that this is interactive fiction; though you may have a story your want to tell, the player should at least feel like she's in control. And please spellcheck your game! Playing a poorly edited game is like visiting a shoddily constructed house - you feel as if the ground could give way at any moment.

3. Code your game
Once you're comfortable with your game's general design, start coding! It's best for new authors to test each new room or object as it's added, instead of waiting to the end and discovering that flipping the lightswitch turns off your cell phone. As you add each piece, think about how it fits into the overall whole of the game world. You know what the player should do, but the player doesn't. The player will spend most of her time exploring and trying things that don't work, so after you've implemented the skeleton of the gameplay, fill the edges in with interesting responses to "non-critical" player actions.

You're certain to run into a few snags as you piece your game together. If the coding manuals aren't any help, you can look for the answer in rec.arts.int-fiction. The online IF community predates the web, and this Usenet group, along with rec.games.int-fiction, is still the primary way for people to stay in touch. The easiest way to access these communities nowadays is via Google Groups. Be sure to search the archives before you ask your question; a lot of the same problems have come up time and time again over the past ten years.

4. Test your game
Of course, you should be testing your game yourself as you write it. But once it's "finished," once you've tested it extensively and stamped out every bug you can find, you should always let your game be tested by others. You may think your game is bug-free, but other players will find problems you never imagined: doors that can be picked up and walked away with, boxes that can be placed inside themselves, and NPCs that can walk through walls. You can't untangle these last few kinks on your own, so ask your friends, family, and roommates for help. Once they turn you down, ask again in rec.arts.int-fiction. Some kindhearted souls there will likely give you a hand.

It's a good idea to ask beta testers to record transcripts of their playthroughs. Seeing what they tried and how your game responded (or failed to respond) can be a great help when tweaking puzzle difficulty and improving the clarity of your descriptions.

5. Release your game
You've learned the programming language, planned your game, coded it, and tested it extensively. What's the best way to tell people about your project? Nowadays, most new games are submitted into the yearly IF Competition. But if the competition is months away and you just can't wait, you can submit your game to the IF Archive and post an announcement on rec.arts.int-fiction.

Congratulations! No matter what the critical response may be, if you've made it this far, you deserve a pat on the back.