Aotearoa, my entry in this year’s IFComp, is almost done.  Hope you like dinosaurs!

This will probably be the last I’ll talk about IFComp until after the judging period is over.  Rule 5 will be in effect, and although I’ll be writing up a more detailed postmortem of my development experiences, I won’t publish until after the cone of silence is lifted on November 15.  Thank goodness there will be an authors’ area set up at the intfiction forums.  I’m really looking forward to playing a bunch of fresh new games this year and seeing what everyone came up with.  It will be nice to see whether any of the folks I met last year in the forums will be returning with new games, and it will be fun to talk with the new authors and get their impressions of writing their first games.

In previous posts, I’ve tried to distill down to a single aphorism, but I don’t think I can sum up the rest of what I’ve learned with just one statement in this last post.  Here is a list of the major things I learned:

1. Quantity leads to quality.  No, I’m not talking about lines of code.  Or am I?  Granted, we should strive for efficiency in coding, and you can’t just shovel out a huge mass of boilerplate IF and expect to have created a masterpiece.  But there’s simply no substitute for sweating the details and writing the myriads of special-case rules required to make objects distinctive under the world model, and that does mean lines of code.  As another facet of this, there’s also no substitute for poring over as many transcripts as you can get from beta testers.  Every new tester has a new approach and will shake out new bugs and weaknesses.  It’s a very parallelizable process, too.  More beta testers means more bugs found faster, and that’s a winning formula.
2. Organization is very important.  It’s not really important which methodology you use, but you should have a plan for organizing your source code and stick to it.  Having a good organizational structure means you can navigate easily with the Index, of course, but most of the time you won’t need to use it, because the structure itself will prompt you to the correct location in the code.  There may come a time near the end of the project when you’re under the gun, when you might have to hack in some quick fixes or make some changes to mechanics with a short turnaround time, and the structure may degrade (it certainly did for me in places).  But at least if you have it in the first place you’ll be able to make those hacks faster and more accurately and you’ll put things in approximately the right place.
3. Programming maxims apply to Interactive Fiction.  In particular, the major ones that affected me on this go-around were:
   • Second System Syndrome:  I wanted to fix absolutely everything that was deficient in my earlier title, plus add everything that was cool in the best current games — keyword support a la Blue Lacuna, a conversation engine (integrated with the keyword engine, naturally), integrated tutorial, nameable animals, a status line exit lister like Eric Eve had for Snowquest (but improved for Glulx, of course!), etc.  I seriously thought about adding an achievement feature at one point, but luckily came to my senses.
   • The Ninety-Ninety Rule:  In particular, the variant that states, “The first 90% of the code takes 90% of development time. The other 90% of code takes the other 90% of time.”  The project took much longer than I expected, and when I thought I was done, I was really only half done.  Seriously.  In June I thought my project would top out at 60,000 lines.  At this point it’s at over 100,000 lines.  Finishing and polishing takes much more time and effort than you might think, particularly if your project is larger or you’ve gone crazy with features.  Budget for it.
4. Stay flexible.  Unless you have been doing design review and testing from the early stages (and you should), you will probably find that a paraphrase of Helmuth von Moltke‘s famous statement applies to your IF title:  “No game survives contact with the testers.”  Give yourself time and allow yourself to admit that you have made some suboptimal decisions.  If you’ve built your code solidly and got feedback early enough, you’ll have time to adapt.  I ended up adding two new systems to my game with two weeks left before the Comp deadline.  Neither were huge, and I think both came off without serious problems, but I still would have liked more time to integrate them, just to lower the stress level.
5. It’s never over ’til it’s over.  After a year of working on this game, it would be very easy to not look at the source code any more — to just put it aside, say “good enough”, and drive on.  But a hard deadline can be very focusing, and I still have a few days left.  I’m [well] past the point where I’m making major changes in structure, but I can still get things done.  I’ve done a couple of the following already, and may not get to them all, but they’re all on the table:
   • Fix remaining minor bugs
   • Add sensory descriptions
   • Double-check for unimplemented nouns and needed synonyms
   • Spellcheck
   • Go over the writing again for weak phrasings
   • Make feelies
   • Look at optimizing performance for Quixe
6. Remember why you did this.  You wanted to make a cool game or a moving story or a challenging brainteaser.  Sure, you spent more time than you thought you’d have to spend, and coding that one puzzle gave you fits.  But did you succeed?  Did you have fun doing it?  Interactive Fiction is one of the very few areas of computer gaming where the one-person project is still the norm.  You’ve taken a game from concept through design and implementation to polish and release, handling the writing, coding, documentation and packaging yourself.  Do you feel satisfied and proud now that you’re about to release your game to the wide world?  You should!

So there’s the last of the notes from my personal journey.  I’ll wrap up with a visual thank-you to my beta testers.  So I could easily highlight problems for collation, I printed off the transcripts I got back from people in 7-point type with no margins.  Some transcripts were double-sided, others not, and I didn’t print them all.  Stacked up, they’re a pile about 2 1/2 inches tall.  Beta testers, I can’t thank you guys enough for the priceless help you gave in this project.  Your testing, feedback, and suggestions have fueled a huge improvement in the quality of Aotearoa.

Enjoy the Comp, everyone!

Tags: Inform 7, Interactive Fiction, Programming

Here’s the nugget of wisdom for today:

Possession relations can be confusing.  Reread Chapter 13 until you finally get it.

Even after a year and a half of Inform 7 programming, and coming up on 130,000 lines of released (or shortly-to-be-released) Inform 7 total, I still found yesterday that I was off in the weeds about the precise definitions of the possession relations in Inform 7.

You really should read Chapter 13 in full, but I’ll try to sum up what was confusing me just to lock it down in my own head:

People carry items, but this applies only to things the player directly holds in their hot little hands.

People can also wear items, which is distinct from carrying.  So far, so good.

To indicate something that is either carried or worn, there is the generalized possession relation, or having.

None of the above apply to things that are in containers which are themselves carried by the player.  For that, we need the concept of enclosure.

The player can enclose items, but he/she never contains them (unless you’re a sentient cupholder in a Rybread Celsius homage, but you’re not).  Enclosure should, according to the documentation, handle multiple nesting levels of containment as well (I have not tested this).

The “to hold” verb appears to amalgamate direct containment, supporting, and subobject composition, which would lead you to believe that the player does not “hold” items.  But in fact, at least in the 5Z71 version of Inform, the player does hold an item that he or she carries, while not containing it, so I’m likely missing something here.

At any rate, it’s probably better not to write something like “If the player holds the parasol”, which may not express quite what you think you want.  Most of the time you want “If the player carries the parasol” or “If the player has the parasol”.  If you want the test to succeed even if the parasol is stuck in your suitcase, the only correct choice is “If the player encloses the parasol”.

Tags: Inform 7, Interactive Fiction, Programming

Here is the revelation I’m sharing today:

You didn’t start testing early enough.  If you think you did, you’re not testing the right things.

I don’t mean just implementation and technical issues, although the statement is true enough for that as well.  You really can never have enough time to root out obscure bugs and corner-case responses, un- or poorly-implemented items, and so forth.  But even if you managed do do a perfect job at that, there’s a whole other component to your interactive fiction work.  Are you testing that other component?

Your interactive fiction game is, as the quote from Graham Nelson goes, a crossword at war with a narrative.  Discussions of testing usually center on fixing programming bugs, which all fall on the crossword side.  Sometimes there’s discussion of “polish”, which is generally understood to mean cleaning up grammatical errors, misspelled words, and awkward phrasing.  That’s more on the narrative side, granted, but it’s not heavy lifting by any means.  If your underlying story has flaws, that kind of “polish” is on the order of rearranging the deck chairs on the Titanic.

So let’s say you’ve been writing a game for the past six months to a year.  You’ve built some cool technical features, crafted some intricately-coded puzzles, and written a lot of room descriptions, response messages, and NPC actions and dialogue.  The Comp is coming up, and you have a month left to go.  You’re close to feature-complete and the game is winnable, so you package up a beta version and send it out to some willing or coercible testers.

The transcripts start coming back, and the game has quite a few bugs.  More than you expected, really, but although some of them look pretty bad and have significant in-game effects, when you drill into them you find they’re not that hard to fix.  Your construction is basically sound, and it looks as if you have plenty of time to root out the remaining problems and lacunae in implementation.

And then a transcript comes back from someone who knows how to write and how to critique writing.  She isn’t concerned with the bugs she’s running into, but she thinks your scenes are unfocused, your main character’s personality is unclear, his backstory is ambiguous if not self-contradictory, and that the pacing of the action is too slow.

Wait a second, is that legitimate for a beta tester to report?  Aren’t they supposed to just find bugs?

Actually, she’s worth her weight in computronium.  She is finding bugs.  The problem is that they’re bugs in your writing, and by the time you’ve written months worth of text in your story, it can be daunting to go back and make the kind of fundamental changes that a poorly-chosen authorial voice might require.  Even correcting pacing and plot issues can be major undertakings, as they might require structural changes to your story that have serious technical repercussions.

Others have addressed this, most recently Aaron Reed in his new book Creating Interactive Fiction with Inform 7.  What he advocates there, and what the methodology Emily Short calls the “transcript fully, then implement” approach facilitates, is to get feedback on your story and writing early on, almost from the beginning of your project.  By doing this, you can get a better feel for how your story is going to come together without having to start major textual surgery one month out from your release date.

It’s not rocket science — this is something that print authors have known about forever — but it may not come naturally to authors arriving at interactive fiction from the programming side.  Even though code review and beta testing are fundamentals of software development, programmers don’t always think of collaboration in the context of writing.  In the non-interactive sphere, writing critique groups and authors’ circles are very common, both in the real world and online.

My testing experiences this year have certainly woken me up to the value of early feedback on story issues and writing quality — you can’t make a truly great interactive fiction without competent execution on both sides of the Fundamental Divide.  I think all IF authors, but particularly new ones with a great idea and lots of enthusiasm who want to enter their first Comp, should keep this in mind and take both time and pride in polishing their narratives as much as they do in burnishing their crosswords.

Tags: Inform 7, Interactive Fiction, Programming