Posts Tagged Inform 7

Conspicuous By My Absence

Curse you, time zones.  I’d meant to attend — planned to attend — the XYZZY awards for months.  As the date approached, we planned a trip out of town for the weekend of the ceremony, but that was OK because my oldest son had his last basketball game of the season on Saturday afternoon, and we were going to leave afterwards.  We were going to leave town at two, the ceremony started at noon — it was all good, right?

Wrong.  We needed to leave no later than two Central, and the ceremony started at noon Pacific.  Which is two Central.  So I’m very sorry I missed it, although it probably spared you having to read what would have been halting, unprepared acceptance speeches.

I’m both gratified and more than a little overwhelmed by the reception and support Aotearoa has received this year.  One of the most insightful descriptions I read in the many reviews this year was by Sarah Morayati, who said, in part: “This feels like a gift, both to his children and the adventures he remembers.”  It is.  That’s exactly what it is.

Like a lot of people in the community, especially those of us who won’t see 40 again, I have a long history with Infocom games, and many fond memories of hours spent playing those old titles.  Masterful, powerful games like Planetfall, A Mind Forever Voyaging, and Trinity taught me that computer games could be about far more than just joysticks and puzzles — that interactive fiction could tell a real, affecting story in a way that was, and still is, unique.  Infocom died right about the time that I went to college.  I thought the IF era was over.  It took me decades to rediscover the IF community and the new tools, but once I did, the old joy came back undimmed.

With Aotearoa, I started off wanting to write an adventure story for (and about) my oldest son — something simple and quick with lots of interesting, wacky animals and a plucky boy protagonist.  As I did research and planned the story, it changed and grew, became far more substantial, and took on a life of its own.  It’s the first time a story has just jerked itself out of my hands and started off in its own direction, and I’m so glad I decided to let go of the leash and just follow the story where it led.

One of the places it led me was to the Māori.  Once I had decided on “New Zealand with dinosaurs” as the setting of the story, I spent a lot of time researching the Māori language and culture.  I worked hard trying to do a good job of representing the Māori people in this story, and I think I did as well as I could.  But I’m not even a New Zealander, let alone a Māori, so there was no way I could actually get across a true Māori perspective.  After the game was released, I had a great email conversation with a New Zealand native who was kind enough to point me to some very good Māori-written fiction.  One in particular stands out as a phenomenal work of art.  If you, like me, have become fascinated with the history and culture of the Māori, I cannot recommend the book Potiki, by Patricia Grace, highly enough.  Written in a powerful, mythic, rhythmic style, Potiki follows an extended Māori family as they attempt to reclaim and hold onto their ancestral land, culture, and way of life.  It was a humbling experience to read this book and realize the gulf of culture, experience, and even perception between the West and the Māori, and then further to realize how deftly Patricia Grace bridges that gulf.

So what’s next?  For the past few months I’ve been taking a bit of a hiatus from development, playing Mass Effect 2 and Starcraft 2 (both excellent in their own ways, not to mention ridiculously addicting) and reading, but I’ve gotten back into the saddle and am starting IF development again.  I’ve recently released version 2 of Keywords for Conversation, the extension I wrote that ties together Aaron Reed’s Keyword Interface and Eric Eve’s Conversation Package.  I’ve converted Aotearoa to build 6G60 of Inform 7, and am working on the bug fixes and revisions for version 2 of it.  I’m also pulling out the tutorial mode code from Aotearoa and generalizing it into a separate extension, which will be released fairly shortly.

And of course, I’ve got games in the works.  I have too many ideas for the time I have available, but I’m hoping to release another shorter game this year, and I have a couple of long-form ideas in the planning stages.

I definitely want to thank everyone who participated in the IFComp this year.  I played every game (a first for me) and was really impressed with the high quality of this year’s games.  I was especially happy to be part of the fun and camaraderie on the authors’ forum.  Finally, huge thanks to everyone who beta tested, played, rated, reviewed, and voted for Aotearoa this year.  I’m happy I’ve been able to contribute this to the community, and thrilled to be an ongoing part of it!

Tags: ,

Review: Treasures of a Slaver’s Kingdom

Treasures of a Slaver’s Kingdom

Author:  S. John Ross

Rating:  5/5

Warning:  Mild spoilers.

I can see why this game is polarizing.  It’s got loads of randomized combat, which is a turn-off for some players.  It’s a pastiche of old-old-school imbalanced pen-and-paper RPGs, which may be confusing if you’ve never been a role-player.  It restricts available verbs to about a half-dozen, and the plot starts off as barely remixed Conan the Barbarian.

But under the covers, this is a fantastic game.  It’s tightly-implemented, bug-free as far as I could see, and takes full advantage of Inform technology to make the playing experience smooth and clean.  The writing, although it apes the breathless earnestness of early RPG modules, is chock full of hilarious descriptions.  Clever responses to unusual commands are liberally sprinkled throughout (try to PARLEY with your DUFFEL BAG, for instance).

This is definitely a game that benefits from sitting down and reading the documentation first.  And there’s plenty of it.  The distribution comes with a manual that details the alternate history the game ostensibly comes from, followed by the entire sourcebook for the fictitious Encounter Critical RPG that ToaSK is based upon, followed by encrypted clues.  Although you don’t have to read the documentation, the Encounter Critical RPG setting is the central structure for everything in the game, and understanding it will make some puzzles far more clear.  Also, for me, reading the documentation made the game far funnier as I was able to quickly pick out the references.

From a design perspective ToaSK is very interesting.  The decision to greatly limit the verbs obviously limits the potential actions the player can take, but doing that also helps the player get interesting responses more easily.  If there are only a few things you can do to a given object, it’s far easier to code meaningful text for all of them.  The result is a game that feels more fully implemented, even though it doesn’t have full physical modeling.  But who needs Inform’s physical modeling when you have “scientific realism”?

The other consequence of the restricted verb set is that it makes the player seem smarter.  It’s easier to figure out what items do when there are fewer interactions, and even brute-force repetition can work to reveal hidden puzzle solutions.  This type of design approach wouldn’t work for every game, but it certainly works here, and works well.

To counteract this, the parser breaks the fourth wall constantly and deliberately, and slings gratuitious insults for the slightest deviation in command input.  Fauxld English is used throughout (methinks this be, mayhaps, where Tiberius Thingamus got his inspiration).

There is, of course, no detailed conversation model.  And anyway, you’re a barbarian — sophisticated conversation would be wasted on you.  Your interactions with characters are limited to the same verb set as inanimate objects, but this still allows a surprising number of things you can do (try ENTERing characters, for example…).  And the choice to limit character interaction allows ToaSK to include many different interesting characters, from Gina the willing virgin sacrifice to the Viraxian Dark Gods, to the runecarved, peg-legged dwarf Gunwar.  And, of course, there’s Vessa, the Delicate Doxy, to whom you will be returning many times.

The game is fairly well paced via its combat leveling mechanic.  You’ll need to explore and solve puzzles to gain health points.  Gaining health points will enable you to fight more powerful enemies, which will get you more gear and items with which to solve more puzzles.  Most combats are potentially fatal, but multi-level UNDO works wonders to get you out of fights where you’re in over your head.

Overall impressions?  The world of Encounter Critical feels like a tall, cold Kitchen Sink made with bathtub gin.  Think of a handwritten mixture of Gamma World (the original edition, of course), Eldritch Wizardry, and Traveller, with some Star Trek, The Lord of the Rings, Star Wars, Dune, Sinbad the Sailor, Conan the Barbarian, and a Godzilla movie or two thrown in for flavor.  Add snark and sex, then overheat the writing to taste.

Until Christmas Eve, the full version of this game cost $6.95.  It’s well worth it at that price (and I paid it on December 23 after discovering it that day), but it’s since been released for free.  If you’ve only played the intro version, you haven’t seen anything.  Don’t miss the opportunity to play the full game, and experience one of the unsung masterpieces of modern retro IF.  Or is that retro modern?  Anyway, you should definitely, definitely play it.

Tags: , ,

Aotearoa Postmortem — Part 2: Development Recap

In the last installment I talked about the overall goal I had in mind for Aotearoa, and the pros and cons of the various convenience features I included.  This time I want to talk about some of the other technologies I included and cover some of the issues and lessons learned based on my development schedule and design choices.  There will be some spoilers below, so consider this fair warning if you haven’t played yet!

Additional Game Features

Naming

Aside from the convenience features I talked about earlier, there were a few other things I included in Aotearoa.  The first, and most obvious, was the animal naming feature.  I’m embarrassed to say that despite many long hours playing Beyond Zork with my friends back in high school and college, I had completely forgotten that you were able to nickname items in that game.  Now that I think back, of course I remember doing so (for some reason that is now [probably fortunately] lost, we named the sword ‘Bbob’), but at the time I couldn’t think of another game that had done it.

The basic technique is not particularly difficult — you attach a nickname to a thing (or in this case, an animal) and make the nickname property describe the thing.  In fact, I think Emily has an example of doing this in the Inform documentation that I used as a starting point.  There was a bit of tap-dancing required to get this to work cleanly — for example, when naming or unnaming, when do you refer to the actual name and when do you refer to the nickname?  How do you avoid infinite loops when printing the name of something that is nicknamed?  And of course, how does it interact with the keyword system?  But it’s not really very difficult, and it seemed to get the most consistently positive reactions of any feature I included in the game.

Foley

I also worked up a foley system that didn’t really perform the way I thought it would.  If you’re not familiar with the word, ‘foley’ is a filmmaking term that refers to sound effects that are recorded offstage and added into the film in post-production to enhance the quality of sound and enhance viewer immersion.  My foley system was supposed to provide a framework for adding in short flavor-text messages that described what was happening in a particular scene or area.

The system was implemented as a table-driven mechanism that could key off of several different conditions, and iterated through a prioritized list of possible messages that were assigned different appearance probability levels.  If that sounds complicated, it was!  It ended up being quite a bit of effort to set up, for results that weren’t really measurably different than just picking randomly from a list.  I used this mechanism for the boat and ocean scenes, and then abandoned it starting from the mainland.

I think that it worked fairly well in the scenes where I used it, but in a lot of cases, the last thing I needed was more text spewed out onto the screen, particularly where there were a lot of other actions going on.  Too many one-sentence action blurbs and the text really starts to feel disjointed.  Once the animals came into play, the extra foley was just too much.

I still think that atmospheric foley text is a good idea, but I would not go to such lengths to try to systematize it in the future.  I think a dozen or so possibilities, tailored to the specific game state that exists at the time, would do the job just as well with much less work.

Radio

The radio was a late addition to the game.  Up until very late beta, you had to return to Eruera every time you wanted to ask him about something.  Since I wanted to emphasize the interactions with him, this caused some serious issues with either pacing (if they chose to return) or delivery of plot information (if they chose to go it alone).  Also, once I decided to add the fear mechanic, Tim had to speak to Eruera, and there was a very real chance that folks would become stuck if they didn’t realize that.

Enter the radio mechanism.  By doing a bit of manipulation with scope, I was able to allow communication via the survival radios.  This allowed Tim to call back to Eruera at any point, and more importantly, allowed Eruera to call Tim at certain points of the story.  This allowed me to hint more organically and push plot information without worrying about too much backtracking.  Of course, the player could still drop the radio, but it would be clear what they were doing, so I wasn’t too worried about that.

There were some fairly significant technical issues to deal with (some of which weren’t dealt with and need to be fixed in the post-Comp release), including removing visual cues from the conversational sequences when communicating by radio, ensuring proper termination of conversations when moving with and without the radio, and handling conversational state when transitioning between scenes.

Riding

Finally, there was the mechanism used to ride the notoceratops.  Originally I’d just plugged in Graham Nelson’s Rideable Animals extension.  This worked — it was possible to hop on the dino and ride away, but as there was really only one way to go, the quasi-freedom actually served to interrupt the action, and frustrate the player.

I then tried to put the riding sequence on rails, and just carry the player through to the camp, but there ended up being no sense of agency, and the player just had to hit ‘z’ over and over again, which was unsatisfying.  Sam Kabo Ashwell pointed out in late beta that a riding system where you had limited control over the beast, such as in The Edifice, might be a good compromise.  I had never played The Edifice, but the idea was clear, and I implemented the mechanics that made it into the final release:  you can turn the dino and spur it faster or slower, but you don’t have full movement abilities.

I really like the way this turned out — there’s a gentle challenge in figuring out the movement commands, and you have to use them appropriately to get to your destination, so a sequence that could be either “you can’t go that way” frustrating or “z.z.z.z” boring ends up building some involvement and excitement up to the climax of ramming your way into camp.

Design and Timeline

I have three young kids ranging in age from one up to nine, one of whom has autism, which means I don’t have vast stretches of excess time to put into hobbies.  I plowed most of the free time I did have last year into working on Aotearoa, which pushed all my other activities into the shadows for the most part.  This added up to hundreds of hours — my best guess is around 400, probably half of which came in the final month — writing and debugging Aotearoa, spread out over almost a full calendar year.  This worked well in some respects and caused some serious problems in others.

One of the most obvious issues was sustaining interest in the project given the slow pace of development.  I was highly motivated to pursue the project, but even so it was disheartening to look back over a week’s work and see very little progress.  When I encountered infrastructure issues that required rewriting, it was intensely frustrating to see several weeks of work slide down the drain.

I tried to get around this by ensuring that I spent at least 4 hours a week working on the project, and by breaking down development tasks into very small, discrete milestones.  This breakdown helped in two ways.  First, it helped me to better analyze the requirements of individual tasks, which helped to reduce the number of times I got blindsided by something after getting halfway done.  Second, it gave me a feeling of progress and accomplishment when I could get through a couple hours of coding and be able to check four bullet points off my list.

Another major issue was keeping a distinctive style throughout the game.  Since Aotearoa was written in bite-sized chunks over the course of a year, it was very erratic in style.  Early drafts were really rough, and it wasn’t until I got some really good writing advice from Sam Kabo Ashwell and Aaron Reed that I took the time to go over everything, tighten it up, and make sure it flowed well and had a consistent voice and vocabulary.  Yes, I said “tighten it up”.  I’m aware that it’s still pretty verbose — you should have seen it before!

Even if I hadn’t had a spread-out creative cycle, I’d still advocate a thorough rewrite.  Just like static fiction, your first draft is rarely publication-worthy.  I was much, much happier with the prose after cleaning it up.

Another major issue, which the extended development cycle just made worse, was the second-system syndrome in the game.  In software development, there’s a well-known tendency to try to address every weakness in your first product when you design your second one.  You’ve learned all the lessons and you’re ready to make something vastly better!  In reality, that overdesigned second system often collapses under the weight of extra features packed into it.

I got lucky in that although I had tons of extra features in the game, most of them were derived from quality extensions and didn’t cause the system to collapse.  Even so, the end of development and the beta period were full of frantic scrambling to address strange bugs and unintentional interactions that were the result of feature bloat.  I got away with it this time, but my third game will pull back from the full cornucopia of features I stuffed into Aotearoa.

Finally, there’s one last consequence of the longer development cycle:  looser, cruder code.  This was intentional, and I feel it was a key to the success of the project.  If you’ve programmed much, you likely know the phenomenon programmers call “flow”.  You get into the zone, the world recedes, and the mental model of the software you’re trying to write becomes clear.  You can accomplish amazing things when flowing, but often these things are not as easy to understand when you’re picking them up hours or days later, when you’re out of the flow state.

And getting into flow takes time.  When you’re coding for an hour here or an hour there, it’s not easy to achieve and sustain flow, and you risk spending a lot of time staring at complicated code structures that made sense when you wrote them but seem incomprehensible now.  The engine puzzle in 2009′s Grounded in Space was like this — so complex that I could only understand it after an involved process of coming back up to speed on it.

In writing Aotearoa, I knew it was going to be a long project and that I was going to be working on it piecemeal over a long stretch of calendar time.  So I deliberately tried to avoid clever, complex coding tricks wherever possible.  By keeping organized, sticking to straightforward, well-named rule-based code and resisting the temptation to write big blocks of complex logic, I helped to ensure that I could always pick the code back up, get to where I left off, and make progress right from the start.  The resulting code isn’t always as cool or elegant, but it’s understandable and functional, and helped me make efficient use of my time.  In the end, the important product is the game, not the source code for the game.

Conclusion

Writing Aotearoa was much more work than I thought it was going to be, even though I knew I was biting off a pretty large project.  From designing puzzles while waiting in a Federal jury room to researching New Zealand plant and animal life, it’s been both fun and educational, and I’m very happy that most players have found that old-fashioned excitement and sense of wonder that I was hoping to convey.  I hope these postmortem reports have been useful to other authors who are considering similar technologies or who are working under similar time constraints.

Tags: , ,

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.

Remembering

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.

Tags: , ,

Things I Learned During Beta: 2010 Edition — Part 4

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: , ,

Things I Learned During Beta: 2010 Edition — Part 3

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: , ,

Things I Learned During Beta: 2010 Edition — Part 2

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: , ,

Things I Learned During Beta: 2010 Edition

I’m in the process of tightening up my upcoming game for IFComp, and that means beta testing!  I’ve had several transcripts come back so far, and among the game-breaking bugs and writing issues it’s uncovering, I found one issue that is tripping up so many people that I feel confident I can state it as a universal rule:

If you output text before the room description block, no one will read it.

It doesn’t matter if the person is an absolute IF newbie, or a seasoned veteran; there’s something about that boldface room name line that draws the eye and says “start reading here”.  I had several places in the game where I was outputting text using a “before going” rule, and in the transcripts you can always see the players flailing around for turns afterward without realizing what happened.

I’m guessing this is a side effect of the move to keeping verbose room descriptions on all the time.  Personally, I always did this anyway; from what others have said I think the preference for verbose mode is probably up over 80%.  But what it means is that you often reread (or quickly scan-and-bypass) the same room description multiple times as you move around the map, which could easily lead to the tendency to just skip over the real differences.

Most of the time, it’s easy to fix this type of problem.  Either shift to using a later point to generate the output (I use a custom specific action-processing rulebook called “post-report” for this type of thing, due to the nature of how the going action leads into the looking action), or do the text output but block the movement.  I’ve used both methods and it really seems to help with drawing attention to the text.

Tags: ,

Interactive Fiction WIP Progress Report

I’m working on a project for this year’s Interactive Fiction Competition (IFComp 2010).  It’s one that I started as kind of a small palate-cleanser after last year’s Comp, intended to be a quickie adventure for my son.  As I worked through the idea and setting, however, I realized that there was more there than I was planning on implementing, and I reevaluated the scale of the project.

The result is my current work in progress (still nameless for now).  I’ve been working on it almost since I submitted last year’s entry, aside from a couple of breaks, and I’m happy to report that I’ve completed implementation of the last puzzles and the ending sequence, at least in skeletal form.  Much of the early game is more completely implemented, but getting the “bones” of the rest of the game laid down means that I don’t have to worry too much about infrastructural issues any more, and can concentrate on finishing the writing and improving the polish.

I’m very relieved to be at this stage; I pushed hard to get here over the past month and am happy that I achieved this.  I can hear you saying “But Matt, it’s the middle of July!  Why are you worked up about completing your game when you have two and a half months left until the Comp submission deadline?!?”

Well, there are several reasons.  First, with a baby in the house that’s almost exactly as old as my WIP, plus two other young kids and a wife I enjoy spending time with, getting time to work on the project is not easy.  I’ve used almost the entire amount of my free time since the last Comp (except for a Dragon Age break) to get here, and I’ve needed it.  I know that finishing the rest of the game in time is still going to require focused effort, especially when school starts back up in the fall.

Second, I have a much better idea of what goes into creating a finished, polished game than I did last year.  For Grounded in Space, I didn’t give myself enough time for development, for learning the tools, or (most importantly) for testing.  This year, even with the game scaffolding implemented end-to-end, I still have the following left to do (in roughly the order they need to be accomplished):

  • Enhancing the in-game tutorial
  • Fixing some known game-derailing bugs
  • Write out the ending sequences in full
  • Test and enhance the default message modifications
  • Implement some additional short scenes and interactive dialogue
  • Review my keyword implementation to ensure it’s consistent and useful
  • Perform object testing a la Juhana’s Object Response Tests
  • Alpha testing
  • Revise my writing
  • Test compatibility on various interpreters and platforms
  • Set up Quixe-specific modifications required for proper keywording and exit-lister display
  • Do cover art and a blurb
  • Beta testing and bug fixing

So no, I’m not resting on my laurels having gotten to this point.  If anything, getting this far has only permitted me to lift my head up and see how far away the finish line still is.

Wish me luck — I’m going to need it!  And for all the other authors this year – both returnees and first-timers — I wish you the best of success with your stories!

Tags: , , ,

Upgrading to Inform 7 6E72

With the recent releases of both the in-browser Glulx interpreter Quixe, and the newest Inform 7 Build 6E72, it was pretty obvious that I’d have to upgrade.  Sure, theoretically it would be possible to stick with the last version of Inform and manually roll out a playable website for my WIP.  But why turn down all the labor-saving power of the new “release along with an interpreter” option?  It automatically builds you a nice website, converts the Glulx file to Javascript for you, and packages it neatly up for release.  I’d also modified my source to remove the very few procedural rules I’d previously used, since I’d heard I7 is deprecating them, so I figured getting my WIP up and running wouldn’t be too arduous.

Happily, I was right!  I did run into about a dozen errors, which fell into two broad categories:

  1. Errors due to more strict syntax checking in the new build.  These were easy to find and fix — I spent maybe 5 minutes on these.
  2. Errors due to changes in the extensions I use.  My WIP uses a lot of extensions, and I hack some of them up a bit as well with overrides.  So pulling down the newest versions of all these extensions caused me a bit of worry.  Of them all, however, the only one that gave me any more than the most ephemeral trouble was the new version of Jon Ingold’s Flexible Windows.  Instead of a single drawing rule, it now uses an object-based rulebook, which required a couple of minor changes (as he points out in the changelog, I should note).  Actually making the code changes was easy; finding out exactly what needed to change was the trick.  Even this, though, didn’t take me more than about 15 minutes.

So the first thing I did now that I could get up and running in the new I7 was to set up Quixe and try a test release using it.  I was pleasantly surprised by the nice CSS defaults for the web pages.  The result isn’t quite up to the level of typography you can get with Gargoyle, of course, but for a literally no-effort setup it’s more than serviceable.  The only thing I ended up doing to the generated pages was to modify the User1 and User2 styles so that they reflected the colored text defaults that I start with, and I was off and running.

I have noticed that I7 is a touch slower to compile now than it was before, and generates a larger story file as well.  Before the upgrade I was running at just over 800 KB, and after the upgrade I’m up over 1 MB.  All the changes and improvements in the I7 release probably contribute to this, but I was pretty surprised to see the size of the generated file increase by 20%.  What this really means, I guess, is that it’s a good thing Quixe came out when it did, since the new I7 has pretty well priced itself out of the Z-machine’s range for all but the most trivial stories.

One thing I hope people continue to look at is the performance of Quixe.  The speed difference when running under Gargoyle vs. when running under Quixe is shocking — Quixe is at least an order of magnitude slower than standalone compiled interpreters, and I suspect more can be done to optimize Quixe given how brand-new the implementation is.  My fairly large WIP is certainly playable, but the slow response time is jarring.  Until speed improves I’ll still be playing most games through a standalone interpreter.

Now the only trick remaining is for me to work out how to support the dynamic color shifting for user styles that the standalone interpreters can use.  I have an extra window created below the status line that should be able to display one of four choices of colored text depending on what the user wants.  I’m thinking that with some judicious changes to the standard styles for that window, along with some minor changes to the code that displays the text, that I can support the appropriate choices in Quixe with a single set of CSS.  If I can’t, I guess I can create alternate windows with different color settings in their specific CSS sections and swap them in appropriately.  I’ll just have to ensure that whatever I end up doing for Quixe doesn’t break the solution I’m using for other interpreters.

Tags: , , ,

The Quern is Digg proof thanks to caching by WP Super Cache