The IFComp is over, the Rule 5 Cone of Silence is lifted, and we authors can now talk freely about our games.  Congratulations to all the authors — I thought this year was just great, with a large number of very good games.  I played them all and enjoyed almost all of them thoroughly!  It’s really gratifying to be a part of this generous-spirited community dedicated to producing high-quality interactive fiction and releasing it freely to the world.

I wrote Aotearoa, and I thought I would share some of the things I learned during development.  I’m going to write up this postmortem in several parts, to keep them focused on specific issues and to reduce the wall-of-text effect.  In this segment, I’m going to talk about the numerous convenience features included in Aotearoa, and try to decide whether or not they were worth including.

Overview and Philosophy

The main development theme I had in mind for this project was ease-of-use.  Aotearoa started out its conceptual life as a one-off game for my son, and even when I expanded the scope into something that I thought had the potential to make a good Comp-length game, I wanted to keep the focus on kids, newbies, and overall interface friendliness.

Luckily, I was able to stand on the shoulders of some giants:  Aaron Reed, of course, provided the Keyword Interface extension, but I also used his Remembering, Numbered Disambiguation Choices, and Smarter Parser extensions.  I used both Exit Lister and the Conversation Package family of extensions authored by Eric Eve, both modified somewhat.  And for the interactive tutorial I rewrote Emily Short’s Tutorial Mode extension.

As you might imagine, integrating all these extensions (and a couple other ones) into a harmonious whole was not completely straightforward.  There was substantial technical integration work required to get something usable, work that I tried to finish up front but that I ended up tweaking up until the very last release.

Once I had the initial concept and a basic design for the game, I decided on the technical features I wanted and started to build infrastructure.  I built a tech demo prototype game that consisted of the first couple of scenes (the boat and the ocean) just to assure myself that what I wanted to do could actually be done.  This prototype had all the convenience features except the final version of the tutorial mode, at least in a basic form.

There were, of course, some bugs in the prototype, but I was confident enough at that point to drive forward with development, and with that foundation having been laid, the work I had to do later was really more in the way of minor bug fixes than hardcore development.

So, down to the details:  how did these features stack up?  I’m going off of things people said in their reviews, along with my knowledge of how each feature contributed to the development hassle.  I’ll try to synthesize both and come up with a cost-benefit conclusion for each.

Keyword Interface

Ah, Keyword Interface!  Source of 1000 integration issues!  I think it’s fair to distinguish, as C. E. J. Pacian and I discussed in the authors’ forums, between games where the keyword interface is the primary mechanism used to play the game, such as in his Walker and Silhouette, and games like Blue Lacuna and Aotearoa, which use keywords to improve the accessibility and friendliness of the game but which otherwise act like standard IF.

The key component of that distinction is that full-keyword games don’t require the use of any verbs; everything is done through specification of a keyword.  Keyword-enhanced games use keywords for a subset of actions, such as examination, movement, or conversation, but rely on standard verb-noun parsing for other actions in the model world.

The reason that distinction is important is because a game that is 100% operated through keywords should be able to dispense with a large chunk of the headaches that come from trying to shoehorn a keyword system into a standard verb-noun parser.  And this is a big deal, because there are a lot of headaches.

One of the main problems I ran into is with disambiguation.  When you enter a command that is ambiguous, Inform has special code within its parser loop that prompts you to clarify your command, then continues with the augmented command.  If you’ve played with this behavior, you’ve probably noticed that you can completely ignore the disambiguation question if you type a new command.  What you probably haven’t noticed is that this only works if the command contains a recognized verb.  In normal situations this wouldn’t be a major issue.  But when you’re using keywords for several different classes of common actions, you suddenly start getting behavior that looks… odd.

And this problem only gets worse when you add more types of keywords.  Every new type brings new state information and new logic to handle the exceptional behavior.  I spent more time diagramming logic states in an attempt to reconcile the keyword system with the other extensions and my own game code than anything else in the development process, and I ended up having to accept both some poorly-phrased error messages and also a couple of rare cases where different actions didn’t behave the way I thought they should when issued after disambiguation.

Don’t get me wrong; I think keywords are a great mechanism to increase accessibility and newbie-friendliness, and they’re a convenience feature that some veterans appreciate as well.  I’m of the opinion that for keyword-enhanced games like Aotearoa, highlighted keywords should be an optional feature, but this is very easy to do.  I’m particularly intrigued to see what direction full-keyword games take — in my opinion, games like W+S end up feeling almost like a CYOA, albeit a CYOA that’s much more detailed, granular, and well-modeled than usual for the genre.  I suspect that with enough sophistication, full-keyword IF games built in TADS or Inform could provide a very interesting and rewarding type of interaction.

I, however, am not particularly interested in writing such games.  And I doubt I will use keyword-enhancement in my next game either; to me the advantages are outweighed by the difficulty of forcing a new paradigm on Inform’s parser — a new paradigm that does not suit it particularly well.

Conversation Package

There are a ton of ways to handle conversation in IF.  But out of all of them that I’ve seen, the TADS 3-inspired model used by Eric Eve’s Conversation Package is the most robust, flexible, and immersion-promoting that is available to date.

I like it for several reasons:  It supports the “ASK/TELL” model of conversation rather than intruding a full conversational menu.  Menu-driven conversation can work well, but I really wanted something that integrated into the story a bit more organically.  Conversation Package also gives a nice topic display that, while it disrupts the narrative flow a little bit, does a good job of naturally presenting possible conversational options to keep the player moving.

Like everything, it’s a tradeoff, but I really like this model for the kinds of stories I’m interested in writing.  That said, integrating it with the keyword system was a problem.  Topic keywords had to be acted upon differently than standard keywords, which meant tracking state and providing more complex rules for processing keywords.  And what if you want to examine something that’s not a viable conversational topic while you’re in a conversation?  I ended up building a large truth table of possible states and trying to identify desired behavior in all cases, and the final result was a set of behavior that I think works well but probably doesn’t cover all possible player expectations.

I got a lot of comments about the well-implemented NPCs, which I think is partially due to the conversation engine.  Only one or two people specifically called out the engine itself, but I also noticed no negative comments on it either, so I will definitely go with this conversational system again in the future.

Modified Tutorial Mode

There was a reasonable amount of work that went into rewriting this, and I’m not sure what I ended up with is the most efficient way to approach the problem, but overall I was really happy with the way this turned out.  Emily’s original extension suffered from a couple of issues that made me hesitant to use it as it was, most notably a sensitivity to the exact text used for command matching and a rigid ordering of tutorial steps.  I adjusted it by making it be satisfied by any command of the appropriate type, regardless of the wording or subject, and also by detecting correct commands even when they didn’t match the current tutorial step.

For example, if the current step was to teach taking, and the example command was “TAKE FLOWER”, Emily’s original extension would require the user to type “TAKE FLOWER” exactly.  With mine, “GET FLOWER”, “TAKE RED FLOWER”, or “GET CANARY” would all work to satisfy the tutorial that you understand the concept of taking an item.  And if you instead typed “INVENTORY” during the “TAKE FLOWER” step, it would acknowledge that you understood the concept of taking inventory and would bypass that tutorial step later.

The modified tutorial mode extension cleanly integrated into the rest of the code, with only a couple of changes required to hook into the keyword engine (due to the fact that pressing the Enter key on a blank line counts as looking).  So the development was pretty manageable, and the results seemed to get very positive reviews.  I definitely feel this was a feature that was well worth including.

Numbered Disambiguation

I really like this extension, and it was a drop-in for the most part.  Unfortunately, disambiguation caused me a lot of problems in general with the keyword extension in place, and some of those were reflected here even though they have their roots in the Inform parsing engine itself.  This extension is in some respects an insurance policy for the author — it’s not really adding a whole lot to gameplay, but can get the player around some nasty problems that the author might have overlooked.  On that basis, I think it was worth including.


Since you need Eric Eve’s Epistemology for quite a few other extensions, and it’s now part of the Inform 7 distribution, why not leverage it?  Aaron Reed’s Remembering extension uses Epistemology to keep track of the last place you saw something and lets you know if you try to use something that isn’t currently in scope.  This is a minor utility feature for players — unless there are a whole ton of takeable items, you probably aren’t going to be wondering where they were, but giving the player a quick tip isn’t harmful.

Unlike Numbered Disambiguation, however, this one can bite you if you’re not careful.  If you remove items from scope or do extensive tricks with moving items around behind the scenes, this extension can end up producing messages that are confusing and immersion-breaking, and I turned up a few of these in testing.  I’m not sure if the potential for extra bugs is worth the small amount of player functionality it delivers — only one person commented specifically on this feature, and that reviewer noted a bug with it at the same time.

Exit Lister

In my opinion, if your game has any kind of extensive geography there’s no reason not to have a good exit listing extension included.  I had been struck by the exit lister in last year’s Snowquest, and knew that I wanted it in Aotearoa.  Unfortunately, I also knew that Aotearoa was going to be a Glulx game, and Eric Eve’s Exit Lister extension doesn’t do colors in Glulx.  That wasn’t too much of a problem, though; I worked up some code to generate a second, separate status line window instead of a double-height one, and retooled the exit lister code so that it would write to that window instead.  In that window, I control the window styles and so it’s easy to mimic the Z-Code version.

This was all well and good, but I ran into a roadblock late in development.  Quixe came out, and it uses a CSS model for styles.  Originally, I’d written my code such that it destroyed and recreated the exits window with a different text color each time the user cycled through the possible color selections.  Since Quixe requires preselected statuses in CSS, I had to tweak the code so that it cycled through four internal styles, which I then coded into the CSS file.  This actually ended up working better, as it was not necessary for me to destroy and recreate that window as often, and the code actually got a bit simpler.

Not many people specifically called out the exit listing, but I think it’s widely seen as a “standard option” these days; in fact, I saw several games get called out for not having exit listing.  Also, my own experiences when playing reinforce the desirability of having the exits conveniently listed.  I definitely think this is a must-have feature.

Smarter Parser

Aaron has long been an advocate of improving the stock Inform parser.  In a game focused on kids and newcomers, his Smarter Parser extension was a natural choice.  What it does is to detect a command failure, analyze the triggering command for certain patterns using regular expressions, and then determine either a better error message or a way to attempt the command anyway.

In general this extension is nice; it seldom seems to do something you really don’t want it to do, and most of its message conditions are well-formed.  It’s also very modifiable; you can easily turn off individual checks or add your own.

There was some work required to get this working cleanly in some of the odder disambiguation cases, but in general it was easy to integrate.  I didn’t get much reviewer reaction on it either way, although I did get some negative feedback on it in the authors’ forums.  I’m not sure this is something that would be appropriate for all games, but for a newbie-focused game I felt it was definitely a good fit.  I might not use it (or might use it with significant alterations) in a game targeted at experienced players.