Posts Tagged Programming

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 rec.arts.int-fiction!  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: , ,

Duplo LEGO Star Wars — A Modest Proposal for the Wii

This is a guest post from my son, Thomas, who has a game proposal he’d like to submit to any interested developers.  So if there are any LucasArts folks trolling the blogosphere who are looking for a creative idea for a new game by a very enthusiastic Lego Star Wars fan, read on:

Dear LucasArts,

My name is Thomas Wigdahl and I want to work with you to publish a Wii game called Duplo LEGO Star Wars.  Can you help me create it?

The reason this game uses Duplos is that it’s a new idea that no one has used before.

The best part of my idea is that it has adventure in it and cool bosses that have a variety of vehicles, ships and droids.

My game would be fun to play because you can build your own vehicles and weapons.

Something new in this game is it only has five levels that are longer than Lego Star Wars levels.

Thanks!

Sincerely,

Thomas

Concept art is below:

Tags: , , ,

“Good Eats”

alton_brown_geek_motivator[1]OK, this will be a special early post so I can get the link out there.  This month we’re hosting Dinner Club, and rather than our usual Iron Chef-style theme ingredient, we decided to go with an Alton Brown theme.

Part of the reason is that we’ve been watching a lot of Good Eats lately in the evenings after the two older kids are in bed but while Jonathan is still active.  Usually the choice is between Star Trek TNG and Good Eats as to decent shows to watch, and Alton has more… general appeal, shall we say.

So we came up with a comfort-food menu based on Alton Brown’s recipes, but I had a brainstorm after finishing the menu:  I’ve been working on interactive fiction lately — why not make an interactive menu?

I didn’t have enough time for that, but I did put together a short, themed interactive fiction work, loaded with Alton Brown quotes and quote-look-alikes, to serve as a companion piece — an appetizer if you will — to this month’s dinner club.

I used a couple of 3rd-party extensions and the core of one of my own proto-extensions to speed development, and after about 3-4 hours of work I ended up with “Good Eats”, an interactive menu.  Click on the link to run it directly in your web browser through Parchment, a Javascript interpreter.  The reason you can do this with this game and not with my competition game is because this one is small enough to fit in the old Infocom Z-machine format, which is the only one currently supported by Parchment.  You can, of course, also download the file directly and play it on your favorite standalone interpreter.

I hope you enjoy “Good Eats” as much as I enjoyed making it!  It was a nice break from longer, more involved projects; I now see the appeal Speed-IF has for participants where I didn’t before.

Tags: , , ,

IFComp 2009 Overview — Grounded in Space Postmortem

pcm_trophy_lrg[1]The Rule 5-induced cone of silence has lifted, and the results are in!  Grounded in Space did reasonably well, placing 10th out of the 24 entries, very close to where I expected it would be (I had mentally blocked out 8th to 14th as the range I was expecting, based on reviews and my own experience playing the competition games).  I learned a lot and met a lot of cool people participating in this year’s competition.  Here are some of the major lessons I took away:

1.  I probably wasn’t ready to release Grounded in Space.  I vastly underestimated the amount of work required to make the game release-quality, especially post-beta work.  And I definitely did not know Inform 7 well enough to accomplish everything I wanted to; the triage required on the design to get the game playable was pretty severe.  Many of the cool parts of the original design ended up on the cutting-room floor, due to either lack of facility with the language or a self-inflicted lack of time.  I slacked a bit in the middle where if I’d put in more effort I might have accomplished quite a bit more.

2.  I’m glad I did release.  The experience of competing in IFComp ’09 was invaluable; there are things I learned from the process, from the other games in the Comp, and from the discussions on the authors’ forums, that I probably couldn’t have learned in any other way.  In particular, I believe that I could not have learned the final process of making a game releasable — the testing and tradeoffs required in the end stages of development — had I not forced myself through it, even with a game that ended up deficient in some ways.

3.  Reviewers are all over the map in terms of what they like or don’t like.  I was pretty unlucky in that the first few reviews all either said or implied “I don’t like Heinlein.”  Well, that pretty much meant those reviews were going to be bad, since Grounded in Space is directly patterned on Heinlein juveniles to the best of my ability.  Later reviewers were more kind in that respect; there are some Heinlein fans out there after all!  Similarly, some folks liked complicated puzzles and some probably would have punched me if I’d been to hand when they got to the engine console.

4.  Notwithstanding #3, there were a number of valid criticisms of my game that were widely given:

  • The premise was really off the wall, and a lot of reviewers bounced off of it.  Sam Kabo Ashwell was very insightful here — it really was the result of me taking the shortest distance between two plot points.  Even a little more thought and effort here would have lowered the suspension of disbelief bar substantially, I think.
  • The introduction lacked interactivity — some objected to this and some didn’t, but there were certainly ways I could have improved interactivity in this section, and I simply didn’t have time to do so.  That was the first section I coded, so it was the one with the least language facility backing it.  I wanted to rewrite it, but bugs with the engine puzzle kept me busy right down to the wire, and I didn’t get the chance.
  • I got criticism that the engine puzzle was not suitable for the text format.  I disagree with this somewhat; I think that with a better text interface I could have made this more palatable for a lot of people.  But a subset of players was never going to be happy with a puzzle that required you to SET THETA DIAL TO -1575, and I didn’t realize quite how large that subset was.

5.  The game is likely unsalvageable.  At this point there are enough flaws baked into the design that trying to improve the game experience would require gutting and rewriting large sections of it, and I’m not going to do that.  I started on another work the day I submitted this one, and I’m planning to move forward with that instead.  There will, however, be a sequel to Grounded in Space at some point in the future.

6.  Inform 7 is awesome.  The learning curve is… interesting — you can get off the ground quickly, but getting really good with it requires you to cross the natural-language equivalent of the “uncanny valley”.  But the expressive power of the language is amazing, and I’m sure the pleasure (and it is, truly, a pleasure) of developing in Inform 7 is one of the main reasons — along with the great people in the community — that I’m so excited about continuing to write IF.

7.  Develop like you were developing any other kind of software.  I didn’t do this at first, treating it as if I were typing up an email.  Oh, I designed up front, of course, and had plenty of design documentation.  But I didn’t have source code control, nor any kind of issue tracking/prioritization system, and so I found myself wasting time on trivial issues or, worse, fearing to make changes in complex code (the reflectors, anyone?) for fear of breaking more things than I was trying to fix.  For my next project, I’ve addressed this; I’m now using Perforce for source code control and I already feel more fearless, comfortable, and productive as a result.

8.  Some of your beta testers should be from the IF community.  I used exclusively non-IF friends for testers, and although they found staggering amounts of bugs, helped me with aspects of the story, gave me a great insight into how newbies might interact with the game, and really got me to widen my net of synonyms, a few IF vets in the mix would probably have latched on to the more structural shortcomings of my work and made suggestions early on that might have helped me avoid some of the big design/architecture pitfalls I stumbled into.

9.  The whole experience was great, and an encouragement to proceed.  Even the negative reviews usually had something nice for me to take away.  The good ones (and there were more of these towards the end of the Comp, for some reason) were extremely encouraging.  Knowing my work clicked in a good way for some people, no matter how few, is a very powerful motivator to continue, and I will certainly be writing more IF and entering the Comp again.

So thanks to everyone who played the games this year, particularly to those who took the time to write reviews and let us know what you thought of our works.  I enjoyed writing for you and hearing both what you considered good about Grounded in Space and what you considered bad.  Next year I hope to improve quality on all fronts and produce something that will knock your socks off!

Tags: , ,

IF Development Tools

Christopher2[1]

Chris Doesn't Use Source Code Control...

Although Rule 5 is still in effect, so I can’t discuss my IFComp-submitted work, I’m still working on IF.  I’ve started two new projects which will share a bit of infrastructural code.

This time around, I’m improving my processes.  As a professional software developer, I wouldn’t dream of doing a project at work that didn’t use a source code control system.  In my previous IF work at home, however, I didn’t bother to set one up in the beginning.  While I was just dinking around, it wasn’t a problem.  However, once I got serious about a project, the closer I got to completion the more nerve-wracking it was making changes, for fear I’d blast something and have to laboriously reconstruct it.

Source code control protects you from this single-point-of-failure problem.  With an SCC tool, you check out and check in versions of the source code, so losing your current copy only loses you the changes since your last checkin.  In addition, a centralized SCC gives you a repository, so there are multiple copies of your file in the event of a catastrophic disk failure (of course, you should have a backup strategy as well; that’s orthogonal to the SCC issue).

I resolved that I wasn’t going to walk the tightrope without a net again.  The question then became which SCC system to get.  There are several good choices:  Subversion; Mercurial; Git; and Perforce, to name the top contenders.

I didn’t want to spend any money, but I’m not particularly ideologically wedded to an open source project.  I also use Windows, which affects the types of UIs available for OSS systems like Git, where the primary focus is on Unix-based systems.  What cinched it for me in the end was that Perforce, the system we use at work, apparently offers a free, non-expiring download of a 2-person maximum server, which is full-featured and supports all of their client apps.

I downloaded it and fired it up, and it was perhaps the easiest setup and configuration of a software package I’ve had to date.  No more than 5 minutes and the server was up and running, configured as a service.  3 more minutes and I had P4V running on my development machine and was importing my files.

Everyone has their own taste in SCC, but if you haven’t tried one yet, and if you’re working in a Windows environment, you could do far worse than to use Perforce.

Tags: , , ,

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