Aotearoa Postmortem — Part 1: Convenience Features

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.

21 thoughts on “Aotearoa Postmortem — Part 1: Convenience Features”

  1. Thanks for posting the link from the intfiction forum to here. Based on this I’d be interested in your game reviews, too.

    It’s neat to see in depth what you did, what sort of extensions you used, etc. I was curious how the game went about doing the tutorial stuff, and despite the in depth stuff it used, it never really felt abstruse.

    Being new to IF, I often got great mileage from the “About” sections that told which extensions the authors used. Lots of “Oh, that’s how they did it without coding til 2 AM” moments. It’s even neater to see a why-they-did-it and even what can be improved, because a lot of times I can still hit the ceiling immediately and figure I better be happy with what’s there, so I like to see this sort of thinking.

    The big one here is the conversation package. I seriously had no clue. But now that you mentioned it, of course someone refined things. I’d been having trouble with making NPCs talk from scratch & that’s hindered some things I was trying to do.

    I’m still not at the stage where I can comment critically on this sort of thing, but on the other hand I’m still picking stuff up at a good rate from this sort of discussion. It’s greatly appreciated.

  2. Yeah, Eric Eve’s Conversation Package is a great family of extensions. I’ve posted several other articles on the site that detail some of what I’ve done with it and how it works. By all means if you have any questions, post them as a comment and I’ll try to address them in one of the upcoming installments.

  3. It’s always good to hear what extensions people use. I collect extensions at a terrific rate, and have to literally remind myself that it’s not “cheating” to not code something from scratch.

    I tend to collect extensions at an embarrassing rate. I definitely notice when there’s no exit lister. It’s forgivable in very very small spaces, but otherwise, it’s a pretty unobtrusive add-on that really packs a lot of usefulness – at least for those of us with poor mental mapping skills.

    Would you consider sharing your modified tutorial extension? Those sound like good changes to be making.

  4. Thanks for sharing — I’d also be interested to hear what the authors’ forum had to say against Smarter Parser, because I’m currently working it into a WIP. I think experienced players are often unlikely to run into its behavior because they know not to put extraneous bits into their commands to start with. Where I find it most often is when it’s correcting for a command like HIT DOOR WITH STICK and only HIT DOOR is required. Then its input is very welcome.

    Re. Tutorial Mode — I was intentionally emulating the style of casual game tutorials, which are very, VERY restrictive at the outset. (“Click on the blinking thing now! Do nothing else! If you do anything else, I will ignore you!”) This is definitely not suitable in all cases. (It may not be suitable in *any* cases, for that matter, but I thought it would be interesting to experiment with.)

    If your version is encapsulated as an extension, might you be willing to release it? I think the more of these things, the better.

    1. Emily, I will ask the author who commented about Smarter Parser if he minds if I repost his opinion here, or if he might wish to post it himself in an intfiction thread.

      I will be happy to package up my modifications to Tutorial Mode as a separate extension. The only reason I hadn’t done it before was that I wasn’t sure what the protocol was when releasing extensions that are modifications of another’s work. If it’s acceptable to make a “Modified Tutorial Mode” or “Alt Tutorial Mode” extension based on my changes, including your original code wholesale (and crediting you, of course), I’ll just do that.

      By the way, thanks again for all your great work on Inform, including Tutorial Mode! The language and tools are a joy to use!

  5. Statistical trivia — Aotearoa’s scores have the lowest standard deviation of any game in the top 10 of the comp since std. dev. started being published in Comp ’01. (Only counting top-ten games, because very low-scoring games usually have very high deviation.) The only game that comes close is Floatpoint.

  6. If it’s acceptable to make a “Modified Tutorial Mode” or “Alt Tutorial Mode” extension based on my changes, including your original code wholesale (and crediting you, of course), I’ll just do that.

    That’s totally within bounds, esp. given the CC-BY license.

  7. The Smarter Parser comments were part of a larger comment/rant I made about all this game behaviour which Matt explained to thoroughly here in this post.

    There were two main points concerning this sub-topic. The first one is the parser reply “That noun did not make sense in this context.” Unfortunately, I hit this all the time. Even for extremely basic commands like EXAMINE WATER. That parser reply is not only extremely unhelpful, because it gives not even a bit of an indication what might have been wrong with the command, but it’s also complete nonsense. How exactly doesn’t the noun WATER make sense in the context EXAMINE? I believe it makes perfect sense. Having played many games, I realised the game was basically just trying to tell me there was no WATER object visible in the current scope, but expecting such knowledge defeats the purpose of a supposedly newbie-friendly extension. This parser response annoyed me to no end, to be honest.

    “Where I find it most often is when it’s correcting for a command like HIT DOOR WITH STICK and only HIT DOOR is required. Then its input is very welcome.”

    This is exactly my other complaint. It can easily lead to the player suddenly being confronted with having triggered completely unintended actions. A simple example (intentionally using another game than Aotearoa here): In Snowquest (original version), final scene, I tried throwing the package as far away as possible for the bad guy to launch after it so that I could take advantage of his distraction and overpower him (or possibly just get away at least). So I tried things like:
    And so on. The Smarter Parser would have shortened this to the understood THROW PACKAGE – which would have resulted in losing the game in death! Such situations could probably be avoided with very careful programming, but just to show you that such automatic attempts of the game to try something “similar” might not always be welcome.

  8. There were two main points concerning this sub-topic. The first one is the parser reply “That noun did not make sense in this context.”

    I’d have to experiment to be sure that this was Smarter Parser’s fault, exactly. At a guess, it’s more likely to be the fault of Remembering: it’s the parser reply that appears when Inform thinks you’re trying to use an action that is allowed to apply to out of scope items. So for instance, if I allowed THINK ABOUT [any thing] in my game, and the player tried THINK ABOUT FREESIAS, I don’t want “You can’t see any such thing”, because the player doesn’t have to be able to see them in order to think about them. “That noun doesn’t make sense…” goes there instead. So, pending experiment, I’d guess that it was appearing here because Remembering was trying to check for out-of-scope items as a next step after in-scope items were exhausted. I could be wrong, but I agree that this error message is frequently annoying. I’d like Inform to be a little cleverer about when it generates that message, actually, but I’m not totally decided what I think the ideal behavior is, which is why I haven’t submitted a suggestion yet.

    As to the second point… hm.

    One alternative here is to insert a check with the player at that phase. “The only part of that that made sense was THROW PACKAGE. Is that what you wanted to do? >” — and then reparse the command if permitted to do so.

    I still think it’s a useful thing to help guide the player towards the syntax that works.

  9. Gee, editing fail on my first comment. Sorry.

    The “That noun doesn’t make any sense” is indeed something you run into with scope issues, although I suppose it might be part of Smarter Parser, too. It’s something I’ve been wrestling with – I keep thinking I’ve got it whipped, and then there it is again.

    Part of the irritation might be solved by custom parser messages; like “That dangerous act . . .” I think the giving the player credit is worth while. They probably didn’t type something that didn’t make sense; it’s almost certainly a grammar understanding issue. It *could* be a typo, of course, but there’s almost certainly a more helpful message to give.

    Like Hannes, I’m not a huge fan of the auto-replace command in general. I would prefer a gentle correction (“You’ve never had a good aim; the best you can do is THROW something and hope for the best.”). That sets the bar really high, though. A slightly easier error message to write would give you the correct syntax. (“I only understood you as far as wanting to THROW something; if you were trying to THROW DOWN something, try DROP instead. THROW requires no modifiers – you can THROW BALL but not THROW BALL THROUGH WINDOW.”) This is aggressive and intrusive, but still six times better than “I only understood you as far as wanting to throw the ball.”

    The exception is something like Tourist Trap, where I tried to ask someone about something. The game gently told me all I needed to do was talk, and then proceeded to act as though I’d done exactly that. I think that’s a perfect handling when intent is clear.

  10. I agree that “you don’t see…” isn’t a very helpful (or even appropriate) message, either, in many situations. Gravel is correct about it not being a good idea to put the blame on the player, though. “*I* could not make sense of this noun in this context” (the parser speaking), for example, would be a much better reply than “That noun *did not* make sense in this context”. At least for me, since I wouldn’t expect a parser to understand “everything” anyway and admitting this would seem reasonable. In the context of thinking about something, a much better message would probably be something like “You don’t know anything about this subject.” or “You currently can’t remember anything about this.”

    Re. which extension this message comes from, I honestly can’t say. I simply assumed. My thoughts are more about the general issue of parser responses rather than a specific extension.

  11. Hi, Matt. Congrats on the win. Fantastic game — I was dying for more. It felt like the first episode in a series to me.

    *** SPOILERS ***
    I think Numbered Disambiguation broke mimesis for me a couple of times. The first time (for which I didn’t save a transcript) was in the captain’s room on the cutter: I was a bit unsure about what to do next, noticed the captain tapping his foot, and randomly decided to EXAMINE FOOT, whereupon the parser asked if I meant (1) Eruera’s broken foot or (2) my lucky rabbit’s foot — neither of which I’d discovered at that point!

    The second time was when I said PUSH BUTTON to call Eruera on the radio. I was asked “Which do you mean, the 1) GPS or the 2) call button?” At that point, I hadn’t yet acquired the GPS!

    Minor points, of course, but I thought you might like to know.

  12. As a first-time IF author, I find this sort of posting very helpful. Not sure I want to wade into all of these extensions, but it’s helpful to see how others do it.

  13. Hi Matt — tried looking for an email but can’t find one. Had a questino about the game: At the top of the title page, it says “Difficulty Level: Introductory Cruelty Level:Polite.” Are those settings that can change or informational? I’m guessing informational, but why are they colored blue like keywords? Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *