Posts Tagged Programming

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


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.


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.


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.


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.


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

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

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

Andrew Plotkin’s Quixe Beta: Glulx Games Directly In-Browser!

In a surge of holiday-weekend coding, Andrew Plotkin (Zarf) has progressed his Quixe project to the beta stage and released it for evaluation.  If you’re very familiar with the excellent Parchment project, you’ll know that Parchment provides a Javascript implementation of the Z-machine, which is one of the major virtual machines used in the interactive fiction community.  When you play a game via Parchment, you don’t need plugins or standalone interpreter software at all — you play directly and natively in the browser.  This has obvious advantages for outreach — many people are leery of downloading unknown executable files at all.  And unless your game runs in Flash, convincing someone to install a browser plugin can be almost as hard a sell.  So Parchment has been a great mechanism to make Z-machine games available to not just a wider audience, but to a wide variety of devices as well.  Almost any device that supports a Javascript-enabled web browser can access interactive fiction through Parchment.

But until now, Glulx games were left in the cold.  Glulx is an alternate virtual machine developed by Andrew Plotkin to address some of the limitations of the Z-machine.  There’s more addressable memory as well as support for multiple windows, graphics, and sound, among other improvements.  Inform 7 gives you a choice of using Glulx or one of the Z-machine formats when you compile a game.

Unfortunately, using Inform 7 for a game of any complexity almost forces you into using Glulx, whether you are making use of its enhanced capabilities or not.  Inform 7 generates large game files that easily push past the Z-machine limits.  Particularly if you make use of the growing extension libraries you are likely to inflate yourself right past even the Z8 format’s cap on size.

So Inform 7 developers have (for the most part) found themselves unable to enjoy the same advantages of accessibility and ubiquity that Parchment gives Z-machine authors.

Enter Quixe.  Quixe provides a native Javascript implementation of the Glulx VM.  When combined with a suitable output layer (in this case I believe Zarf is using his own GlkOte implementation) it enables the same type of direct-in-browser play for Glulx-based games that Parchment enables for the Z-machine.

He’s currently got five games up on his page, but authors are able to convert any existing Glulx games using the zcode2js tool, and run them via his engine.  If you do this, you’ll notice that not everything is functional yet.  In particular, if you play the conversion of Rover’s Day Out you’ll miss much of the text formatting and screen effects that are visible in the game when played via a standalone interpreter.  Also, Internet Explorer does not currently work (!) Presumably these problems will be fixed and capabilities will be added in as development proceeds.  I expect we’ll also see the new style model that Zarf has been discussing over the past few months.

And of course, I had to run a conversion of my own Glulx game, Grounded in Space!  Despite not being very long or complex, I had to use Glulx for this game due the need for fairly high-precision floating-point math for one of the puzzles.  I haven’t gone through it in detail yet, but it seems to have converted correctly.  It doesn’t use any odd tricks that should prevent it from being playable, although the geometry puzzle might be even less comprehensible due to style and font issues.  At any rate, it’s very cool to have this capability, and I hope by the time this year’s Comp rolls around we’ll have a much larger number of games able to be played online due to Quixe!

Tags: , , ,

New Inform 7 Release Imminent

Great news from vaporware’s post on!  Inform 7 will have a new release on or shortly after April 28th!

Items slated for the new build will include:

  • Tidier user interface
  • Easily publish Inform works to the web, including a release mode
    that creates a playable web site using Parchment
  • Many language restrictions removed, and more expressiveness in
    talking about kinds, phrases, relations, etc.
  • Many Standard Rules actions changed to provide default behavior
    closer to what modern authors tend to want (automatically opening
    doors, handling TAKE ALL more naturally, and so on)
  • More than 250 bug reports resolved

Can’t wait!

Tags: , , ,

More Service Broker

After a two-day period of intense hacking, I’ve got the basic architecture of a replacement for our messaging engine working in Service Broker.  It’s fast, lock contention isn’t an issue, and I’m very hopeful that we can not only use Service Broker to replace our messaging engine, but also to reduce our dependence on external apps that poll the database for changes.

Service Broker is not particularly difficult to understand, but getting the syntax right can be tricky.  I ran into several minor stumbling blocks, which I was luckily able to get over quickly:

  1. I did not specify the “no encryption” option on the conversations I opened, so initially messages weren’t being sent due to the fact that I didn’t have a master key set up for the database in question.
  2. My first cut at implementation used the “fire and forget” pattern, where the initiator terminates the conversation immediately after sending.  This is a problem because if the far side needs to return error information to the initiator, it can’t, since the initiator has already jumped ship.  The fix for this is to let the target terminate the conversation and to put a little activated stored procedure on the initiator side to handle any error responses.

After getting past these issues, it was smooth sailing.  I expect to be able to implement the routing logic today, after which it will just be a matter of cleaning it up for inclusion in our software.  We could potentially be running with it in about a week, at least in its 1.0 version, particularly if I go with straight text for the RPC messages rather than have to mess around with XML serialization.  If I were using C# it would be a no-brainer to use XML, but the options available under C++/MFC are less than stellar.

Tags: ,

SQL Server Service Broker

Sorry for the late update; I’ve been feverishly working on a new project at work, using SQL Server Service Broker to replace our older interprocess messaging and database notification system.

Service Broker is a very cool piece of technology, and since it leverages the ubiquity of the database (everyone that needs notifications has connections to our server) we can end up eliminating a huge amount of code by implementing it.  We’re also likely to gain speed, as it will eliminate the single-point-of-contention queue table and the manual polling logic that we were using before.

I’m almost ready to roll with my second proof-of-concept exercise — this one demonstrating a stripped down version of my proposed architecture.  If I can get it to work the way I suspect I can, we’ll be ready to forge full speed ahead to implementation, and eliminate a code structure that ‘s been a thorn in my side for almost 10 years!

Tags: , ,

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