The Quern

It's All Grist for the Personal Mill

Conspicuous By My Absence

Feb 28

Posted by Matt Wigdahl in Computer, Games, Interactive Fiction, Writing and Philosophy | No Comments

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

Dec 29

Posted by Matt Wigdahl in Computer, Games, Interactive Fiction | 2 Comments

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

The Bronze Report — A Noob’s Starcraft 2 Education: Episode 1 — Whine and Cheese

Nov 30

Posted by Matt Wigdahl in Computer, Games, Humor | No Comments

Welcome to the start of a new feature on this blog!  I haven’t been writing much lately, partially because of burnout from writing interactive fiction, and partially because I’ve been playing a lot of Starcraft 2.  So I figured I’d try to jump-start my blogging again using my low-level Starcraft play as the subject matter.

So who am I?  I’m not an 1800-point diamond player, nor have I played Starcraft for the last 10 years.  I’m a 41-year-old guy with a day job and three kids, who enjoys gaming but has never really played an RTS title to any level of multiplayer skill in the past.  I tend to like RPGs and FPS-type games, but Starcraft 2 is different, somehow.  For the first time, due to the outstanding matchmaking system, I feel like I can learn without being repeatedly stomped into the ground by vastly more skilled players.

I’ve played the campaign, run through all the challenge scenarios, and learned to play the AI so that I can reliably beat it on Hard.  I’ve been reading TeamLiquid forums, watching Day9 and other tutorial vids, and generally trying to learn how to play correctly, but I’m coming up from zero as far as playing other players, and so I’ve spent quite a bit of time bouncing around the Bronze league.  I started off as Rank 25 Bronze, dropped down into the 45 range for a while, and slowly but surely dragged myself back up to my current level of Rank 8 Bronze.

Currently I have 83 games played, with 38 wins — I’ve been creeping closer to a 50% win rate after being at around 33% at the nadir of my play.  Oh, and I play Zerg.

So enough about my background — let’s get to the Starcraft talk!  I’m generally going to try to link a replay here with some commentary, but I don’t think it’s fruitful to look at older ones, so for today I’m just going to talk about the various pet peeves and cheese strategies I’ve encountered down with the dregs of the Bronze league:

A-Holes

I learned quickly that a quick “gl, hf” at the beginning of the game and a “gg” at the end were considered the bare minimum for courteous play, but I’m OK if the opponent just doesn’t type anything at all.  Particularly at the beginning of the game, things go quickly, and if you aren’t to the point where the opening build order is automatic for you, it can be distracting to try to type a response, and not everyone types quickly.  So I don’t let that bother me.  And if someone ragequits after a good, straight-up game that I happened to win, I almost take that as a compliment.

What does bother me is people who are deliberately rude.  So when I type “gl, hf!” and the opponent responds with “shut up” and then cannon rushes me, I do get offended.  Fortunately, these types of people are rare.  Choice responses to “gl, hf!” that I recall off the top of my head are:

  • “Shut up”
  • “NO”
  • “Zerg noob”
  • “dq plz” (I assume this is “die quick, please”)

And of course, there’s the fairly uncommon “bg” (“bad game”) comment at the end of the game, to which I would often like to respond “…4u” if the other guy had not already surrendered.

Cheese

Although I am never rude (I think I may have ragequit once to one of the guys above, who paired cheese with his rudeness), I cannot claim that I am innocent of cheesing other players.  I experimented with the 6-pool rush, the 7 roach rush, and the 3 roach rush, with limited success.  Although these rush builds can be effective, you just don’t learn much by doing them, and if you don’t manage a clean win it’s unlikely you can recover to transition into a good midgame.  I’ve actually pulled it off a couple of times, but it was a mad scramble the rest of the game, and I doubt it would have worked against a better player.

But some of the cheese I’ve been on the receiving end of is really obnoxious:

  • The Protoss cannon rush, where they plant a pylon and cannons in or near your base.  If they get a cannon up in range of your drones or buildings, it’s gg.  I’ve learned to defend against this by overlord scouting the ramp and sides of my base, and by preparing to build spine crawlers if I see a forge and/or any probe shenanigans.  This is by far the most annoying Protoss tactic.  I’d rather get void ray rushed than cannon rushed.
  • The drone/probe/SCV rush, where the other player sends all his starting workers to your base and micros them to kill all your workers.  The annoying thing about this is that they’ll show up in your base with 6 workers to your 9 or 10, but they’ve organized them into groups and have practiced fighting in the mineral line, and end up killing all your workers.  I have yet to figure out a good way to respond to this, but maybe practicing against the AI will help.  Oddly, the last person to do this to me surrendered to me after killing all my drones, which I assume means he was deliberately trying to drop his ranking quickly.
  • Bunker rush — the first marine push comes with an SCV, who plops down a bunker at the foot of your ramp.  The marines pile in, and now you have a very tough fortified position to take down to even get out of your base, which makes expanding almost impossible until you can pull the thing down.
  • Mass reaper harass — the only time someone tried this on me they were really late, and although they had a formidable force of reapers, I saw them and had speedlings, so I was able to completely destroy them.
  • Early Banshees / Early Dark Templars — not true cheese, but both of these strategies abuse lack of detection.  To defend you either have to get to Lair and morph an overseer, or build an evo chamber so you can get spore crawlers up (or both).  I’ve been abused regularly by banshees (I’ve now learned to build extra queens and ensure I have detection if I scout the early starport) but the one time I got hit with DTs he pulled them back to deal with the constant pressure I was putting on his base, and I eked out a win.

Next time I’ll post a replay or two with my own analysis of the games, and we can see where I’m weak and where I’m doing OK.

Tags:

Aotearoa Postmortem — Part 2: Development Recap

Nov 29

Posted by Matt Wigdahl in Computer, Games, Interactive Fiction, Writing and Philosophy | 3 Comments

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 Wins!

Nov 16

Posted by Matt Wigdahl in Family, Writing and Philosophy | 4 Comments

Remember those old-school Infocom text adventures like Zork, Planetfall, and The Hitchhiker’s Guide to the Galaxy?  

You might be surprised to hear that people are still making this style of computer game even today; in fact, there’s a small but thriving community making more advanced programming tools and dozens of new games every year.  Things have come a long way since the mid 80’s!

Last year around this time I started writing such a game, set in an alternate-reality (and much larger) New Zealand where dinosaurs never died out.  The game is called Aotearoa.  On October 1 of this year, I entered it into the 2010 Interactive Fiction Competition, alongside 25 other entrants.  Today, the six-week judging period is over and Aotearoa stands revealed as the top-rated game of the year, in a very strong year!

Game information:  http://ifdb.tads.org/viewgame?id=lrbpmlpsknsgvgem

You can either play it online using the link at the site above (although it will probably run pretty slowly unless you have a really fast computer) or you can download it and run it using an interpreter like Gargoyle.  I hope you enjoy it, and while you’re at it, check out the other great games available!

What are the reviewers saying about Aotearoa?

“I’ll just say it: ‘Aotearoa’ is fantastic.” — Brad Buchanan

“Man.  That was just a really good game.  No complaints.  I believe we’ve got a ten.” – Jenni Polodna

“This — THIS! — is the type of game I thought I would be playing all along.” – Flack

“Oh god… I love this game.” — Steven Odhner

“…this is a game with a lot of polish, which must have received absolutely painstaking beta.” – Jake Wildstrom

“…chock full of charm…” — Kate Sherrod (review in sonnet form)

“… it’s a wonderful adventure.” — Rhian

“Polish. Detail. The game has them, and comes alive through them.” — Peter Pears

“This feels like a gift, both to his children and the adventures he remembers.” — Sarah Morayati

“Bacon, sausages, two half-boiled eggs and a bowl of porridge. On the side, toast with marmalade, and slices of Kiwi fruit. Ovaltine to drink.” — Christopher Huang’s Breakfast Review

Aotearoa Postmortem — Part 1: Convenience Features

Nov 16

Posted by Matt Wigdahl in Computer, Games, Interactive Fiction, Writing and Philosophy | 21 Comments

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

The Evolution Chamber

Nov 11

Posted by Matt Wigdahl in Computer, Games | 1 Comment

I love Starcraft 2.  Not only is the single-player campaign fun, with a cheesy, overacted campaign and amazing flexibility and depth of gameplay, but the multiplayer is also fun, both varied and deep, and exactingly balanced.

As background, I’ve played RTS games before, but I’ve never been a huge fan of them.  I played the original Warcraft, C+C, Warcraft 2, Warcraft 3, Company of Heroes, etc., but it really wasn’t until the advent of Starcraft 2 and the new Battle.Net experience that I’ve really felt the RTS addiction like I have with other genres of games.

Of course, enjoying the multiplayer experience in Starcraft 2 doesn’t mean I’m necessarily any good at it.  I play as Zerg, the awesome bug race that owns everything.  I played my 5 placement matches, went 2-3, got placed in Bronze (the lowest league) and spent the next few days dropping down to rank 40.  I’ve learned a lot, and have been winning games recently and moving up the Bronze league ranks, but compared to the real masters of the game I’m like a child.  Or a pet.  Luckily, Battle.Net’s automatic matchmaker puts me up against other players that are about at my skill level, so I still get good games that aren’t too frustrating.

At my level, exacting optimization of the opening moves (“build order”) is not required; I and the folks like me are so deficient in basic skills that we need to be just focusing on proper production and expansion, not tweaking endlessly in order to eke 5 more minerals out of the first 30 seconds of the game.  But there is a program to do just that, at least for the Zerg race (Terrans?  Protoss?  Go recruit some more awesome programmers).

That program is called the Evolution Chamber, named after one of the Zerg upgrade structures, and it allows you to specify the target outputs of the opening you want (20 zerglings, 7 roaches, etc.) and it iterates through combinations to determine the best option.  It’s very sophisticated, using genetic algorithms to mutate the builds and squeeze the fat out, reducing the build time down to the absolute minimum possible.

Evolution Chamber is a fascinating program — almost as fascinating as Starcraft 2 itself.  It’s a lot of fun to just enter different outputs, set the constraints, and then let the optimizer whir away.  But it has practical uses also.  Particularly for “rush” strategies, where you try to accumulate powerful units very quickly to overwhelm the opponent, while sacrificing your economic development in the long term, this program shines.  It took the concept of “roach rushing” — building a number of roach units quickly — and refined it into the current “7RR” (Seven Roach Rush).  And it did so using some very odd techniques, that would not generally be found using standard the approach to building.  It uses the “extractor trick”, which is in general long-term resource suboptimal but provides a boost in this case, relies on building supply units at a point where they’re not strictly required, and at least one variant of it uses less than the full number of drones to mine gas.

If you’re a good Starcraft player, or just interested in genetic algorithms, Evolution Chamber is a fun program to play around with.

The Destructive Update

Oct 19

Posted by Matt Wigdahl in Computer | No Comments

OK, I need to get back in the habit of posting updates again.  So here’s what happened when I decided to update this blog’s theme from Arclite 1.5 to Arclite 2.x…

Under “Appearance” on the sidebar menu, there’s an item called “Arclite settings”.  In here are some options you can set to govern the general look and feel of the theme, along with a couple of boxes where you can enter footer HTML and customize the CSS to alter font choices, sizes, etc.  It’s all pretty straightforward, and when I set this blog up I made sure to make all my changes in those places rather than in the actual theme template files, since that page assured me that if I made changes to the template files they would be lost on upgrade.

I guess I assumed that if I made my changes in the appointed places, that they would not be changed when I upgraded.  Well, that wasn’t the case, apparently.  When I upgraded, the blog devolved back down to the bog-standard configuration, and I was left scratching my head, wondering how I was going to recreate my settings.

I grunged around my browser cache on a couple of machines, trying to see whether I had an old copy of the page or CSS to use, but was unable to find the correct files.  So I had to start over, going through the template CSS and pulling out the changes I wanted to make.  After about 10 minutes I had what I needed, other than a couple of widgets missing from the page footer, but it was still irritating.

Lesson:  You might be able to trust the WordPress update procedure in general, but your mileage may vary when updating themes, widgets, or other components.

Things I Learned During Beta: 2010 Edition — Part 4

Sep 26

Posted by Matt Wigdahl in Computer, Games, Interactive Fiction, Writing and Philosophy | 3 Comments

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

Sep 17

Posted by Matt Wigdahl in Computer, Games, Interactive Fiction, Writing and Philosophy | 6 Comments

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

The Quern is Stephen Fry proof thanks to caching by WP Super Cache