Full details here: http://rockethands.com/ruby-ogmo

A classic text adventure. Image by Peter Scheyen.

These days there are great tools for writing text adventure games. The best would have to be Inform 7, which lets you write text adventures that are compatible with the Infocom Z-Machine (and thereby playable on a whole bunch of platforms, including the iPhone). Code written in Inform looks like this:

The wood-slatted crate is in the Gazebo. The crate is a container 

Insane, right? You should try it out. It’s pretty amazingly great.

If you’re not interested in writing your own text adventures, but you do enjoy playing them, then you’ll be pleased to know that there’s a vibrant community that continues to produce wonderful games (and who would prefer it if they were referred to as “interactive fiction”, thank-you very much). If you want to play the very best of these modern text adventures (sorry), then you could do worse than check out the winning entries of the Interactive Fiction Competition, which has been running for the past fifteen years. Heck, you can even play them in your browser, with Parchment (a z-machine interpreter written in JavaScript).

Speaking of text adventures, I’ve recently received my copy of Get Lamp, the text adventure documentary. Perhaps a screening is in order?

Stack Overflow. Image by Jeff Atwood.

Joel and Jeff reused the Q&A Engine they developed for StackOverflow to power a couple of related websites, ServerFault and SuperUser, and then attempted to monetise the whole shebang by offering StackExchange, providing hosted Q&A websites on any topic to whomever was prepared to pay a steep monthly hosting fee. That didn’t work out so well.

Not ones to give up, Joel and Jeff tried Plan B, visiting a whole bunch of VCs in a whirlwind tour, raising US$6m in two weeks. They then returned to the drawing-board, coming up with StackExchance2.0, which is totally free, and whereby new Q&A sites are born via a community proposal process, which is how the USENET newsgroups of yore were created. It seems to be going swimmingly, and there are now about a dozen new Q&A websites in open beta on topics that include Cooking, Bicycles, Home Improvement and Personal Finance.

Many of the questions and answers across all of the websites in the StackExchange family are interesting to browse. As a StackOverflow user, I’ve been creating accounts on all of the new sites as they go into open beta, but, unless you’re really motivated to ask questions or write answers (and they do their darndest to motivate you, with XBLA-style achievements, points and leaderboards), you’ll find it difficult just to browse the sites for enjoyment.

Late last week I discovered two things that I hope will change that.

1. They’ve released a public API that’s super clean and powerful. It’s easy to browse if you have the JSONview Firefox extension, and really easy to access from script.
2. Amazon have, finally, implemented default root object capability for CloudFront, making it possible to serve a static website entirely from S3.

I’m currently writing a Ruby script that will spider all of the StackExchange Q&A websites, with the intention of finding the 100 best question-answer pairs for each site (as determined by a metric that takes into account many things, such as the brevity of the question and answer, the number of upvotes the question received, and the difference between the upvotes received by the first and second answers). These question-answer pairs will be grouped into ten buckets, based on the tags associated with the questions. All of this will then drive a new website, FAQoverflow, which purports to contain “great answers to questions about everything”. The site will be easy to browse (even on your iPhone), using styling inspired by Readability. And there’ll be PDF and eBook editions of the FAQ available for download. It’ll all be built automagically via a script that publishes a new edition every week or so, and will be user-supported (I’ll ask for donations from the community to pay the minimal hosting bill).

Game Face. Photo By: Phillip Toledano

A branch of the AI research crowd are interested in games both as a testbed for theoretical work and as a market for applied AI. Unfortunately, these are conflicting goals.

People play games to be entertained, and any AI present in the game must contribute to this. I personally think that AI enhances player enjoyment when it is both surprising and relevant. That is, it should result in an experience which feels new, yet which is consistent in the current context.

This regrettably suggests that AI is synonymous with NPCs, which is a mistake that both game players and researchers make. There are plenty of opportunities for non-NPC AI in games, and yet there is scant research being done in these areas. I’m referring to things such as

• a cinematic camera that responds realistically to game world events and player movement;
• dynamic set pieces, including chase sequences and fights;
• story events that fit the overarching narrative but which adapt to a sandbox environment;
• an audio score that foreshadows unscripted events and announces the presence of hero characters;
• large-scale crowd and vehicle simulation;
• adaptive character animation and movement;
• accurate matchmaking algorithms for multiplayer online games;
• elegantly handling dropouts with automatic AI takeover;
• automatic navmesh generation from a polygon soup;
• predicting player behaviour to counteract controller and network lag; and
• automatic exploit detection and prevention.

The problem is that the role of the (usually lone) AI programmer on a game development team often involves many tasks that get in the way of performing research, including asset acquisition, audio and animation integration, data production, tool implementation and support, multithreading support, optimisation, debugging and so on, leaving a perfect opportunity for academia to supply the research chops. What’s needed are robust, efficient, designer-tweakable techniques that are easy to debug, and which scale with available CPU and memory. Sadly these requirements are not a priority for researchers, and yet researchers remain perplexed that game developers don’t use some of the inefficient, unpredictable techniques that they develop.

You see, the problem is that your neat little algorithm might perform well 95% of the time, which may be a great improvement over the state-of-the-art, and which may justify publication, but 95% is not good enough when you have an audience of 5 million game players (as hundreds of thousands of them will see broken behaviour).

But the biggest point of contention between game developers and researchers is that we gamedevs think that cheating is acceptable. After all, a game is just a Turing Test, with the player deciding whether intelligence exists based on the behaviour they perceive, so why not use all available information to deliver on that promise, instead of placing artificial restrictions on what data can be used based on whether or not it would be available to a human player? It just doesn’t matter how the behaviour is achieved – we’re not looking for insights into how the human brain works – it’s all down to player experience. This behavioural approach is out of favour with researchers (and has been ever since Chomsky defeated Skinner), but is the core of pragmatic game design. Perhaps never the twain shall meet.

For me, this event was totally different to the Global Game Jam held earlier in the year. Due to the lack of other sites around the globe, I wasn’t spurred on by a sense of competition. It was more a case of manufacturing inspiration and enthusiasm by surrounding yourself with like-minded people and imposing constraints in the form of a deadline, a theme, and a “significant asset”. Also, the non-presence of that Louis Castle douchbag removed hate as a motivating factor, so I wasn’t keen to develop an evil game with Louis as the antagonist, as I did for GGJ.

Mr. Wittber chose to announce the theme and significant asset well in advance of the jam, giving everyone ample time to think about what they wanted to do. This was a great decision, as the amount of dithering about was reduced almost to zero, replaced with interesting discussions about several really promising game concepts. I went into January’s Global Game Jam wanting to make a flash-based game, which I’d never attempted before, and I used the time to learn how to write a game in ActionScript, using the FlashPunk framework, from scratch. This time, I knew I wanted to create a fluid simulation, similar to this one. I was pretty happy when I found out that the significant asset was a bubble, because that fitted what I wanted to achieve. As for the theme of “choose two at the expense of the other”, my first thought was the old project management adage “cost, quality, time: choose any two”. Kudos to Simon for choosing a much, much better theme than GGJ2010.

During the pre-Jam BBQ (during which Simon proudly revealed his massive cheese kransky, which both honoured and humbled me), I discussed two concepts with Jack, Nick et al.:

1. A resource management game called Gusher, whereby you send out geologists to explore land and sea, them choose a suitable spot to drill an exploratory hole, then build an oil rig to extract the crude, then refine it, store it to manipulate the market, then pipe or ship it to sell. You’d need to manipulate the media and the authorities, and there’d always be the chance of an incident (either deliberate or accidental). Each choice would allow you to fix two of the three cost, time and quality constraints, so, for instance, you would get an inaccurate report of where to drill if you sent your geologists out on a tight deadline and didn’t pay them very much.
2. A fishing game called Floater where you paddle your wooden boat across a turbulent ocean, choosing to stop and fish, bail out your vessel or move it left and right (only being able to do two of these things at a time).

After I began coding, I quickly realised that the fluid simulation would take a long time to code, and wouldn’t run at a decent framerate in Flash (I coded up a quick demo in C++ and in Flash, both using Box2D, to find big performance hits with more than 100 physics objects at once in Flash). So I started doing a little bubble simulation instead, using Box2D’s built-in support for buoyancy. This quickly led to an idea of a chef cooking a pot of soup on the stove, with ingredients being thrown in to raise the water level, and a game mechanic of merging like-coloured bubbles both to increase score (the deliciousness of the stock) and decrease heat (hence reducing the likelihood of losing an ingredient due to the intensity of bubbling, which would be the lose condition).

This worked out pretty well. Jack helped out with the graphics and playtesting, and the game mechanic came together nicely. You can have a go yerself on the RocketHands web site. Comments and feedback welcomed!

So what now? As I mentioned to Jack, Simon, Anthony and others at the end of the Jam, I treated things this time around as a great way of getting started on a project, rather than as a great way of finishing something off. So I plan to keep working on the soup-making game, which I’ve called Gusher2, until it’s at a point where I’m happy with it. With that in mind, here’s my to-do list:

• Ask Simon Boxer to draw some lewd cartoonish graphics, inspired by Muscle March. We need an attract screen, the main game screen in the same style, a win screen, a lose screen, and five distinct ingredients (celery, tomato, carrot, onion and kransky sausage).
• Add an egg-timer, and constrain playtime to 3 minutes, with a new ingredient going in every 30 seconds.
• Make the ingredients change the water level when they go in, and change the tint and alpha of the stock, to ramp up the level of difficulty as the game progresses.
• Display the current score somewhere on screen, and tweak the scoring mechanism to favour multi-merges.
• Continue to improve the game mechanic. Some playtesters have said they’d prefer to click on bubbles, rather than click-and-drag. So I’ll try that out.
• Animate some fire under the pot, some particles in the stock, some steam on top of it and so on.
• Add suitable sound effects, musical stings and… voice acting. Oh yeah: “My soup… she’s a-ready!”

After all that, I’m going to perform an experiment with online flash games:

1. Integrate with mochimedia. to experiment with in-game advertising as a revenue stream, to get analytics information, to keep online high scores, and so forth. Did I mention I want 5 different win screens, depending on whether you’re the top scorer, in the top 10%, and so on?
2. Integrate with Kongregate, to do much the same thing with a different API (mochimedia and Kongregate have an agreement to stay off each other’s turf, so to properly experiment you need to do both).

I’m hoping that integration with these services will increase re-playability. After all, competing with members of your social network for high scores seems to work. I’d like to give it a shot.

I want to get all of this done in the next four weeks. I’m working on three other projects. I have two small children. I’m building a house. We’ll see how it goes!

The other goal of the InputManager is to give game contexts and game systems controlled access to input controllers. For example, when a particular game context is active, it may require exclusive access to touch. In other circumstances, several game systems and contexts may use touch simultaneously (as would be the case when implementing game entity control with touch and overlaying a HUD that contains buttons that may be pressed). I want to avoid the usual technique of having entities, contexts and systems query the input devices directly, so that’s taking a bit of thought and hacking to figure out.

I expect I’ll be a day or two on this, and then will move onto entities.

It can be a struggle getting back to an old project when the code has been left dormant for so long (well, it’s been weeks and weeks and weeks, you know). Code rot is real, you know. But I am keen as anything to get back into making a componentised entity system, so we’ll see how things go. Tonight it’s just preparatory work – I’ve been upgrading to the latest release of Airplay SDK (which now supports iPhone app signing on the PC without having to run a klunky signing server on a Mac), actually getting the PC app signing working, fixing a few memory bugs and basically making sure I actually know what I’ll be doing tomorrow night when I dive back into things.

It’s good to be back :)

Then Global Game Jam suddenly loomed, and I decided to put the Postal Worker project in pause mode so I could hack out a game in 48 hours. I took the opportunity to learn ActionScript, and made a dinky little flip-screen arcade adventure called Bogus Quest. I spent the week following GGJ adding new features to the game and fixing some bugs. I still have a list of things that I want to do, including adding a proper loading screen and adding sound effects.

Then Mike Turner came and raided the Interzone offices, and I became involved with spreading the word about what happened in an attempt to get the Australian government to actually do something about it.  A lot of people have been seriously disadvantaged by all of this, but, at the same time, there was a great sense of camaraderie, and it was quite a lot of fun analysing documents, editing video and basically getting the word out to journalists.

Tonight I realised that I’ve got three hobby projects on the go. I’m a self-proclaimed procrastinating perfectionist, by which I mean that I have a bunch of crazy ideas but never actually get around to completing any of them, out of fear of failure. Ask me about Magnate, my web scraper cum news aggregator, or my procedurally generated text adventure, or MegaHAL10 (the next version of the chatterbot I wrote 15 years ago), or Thrust Harder, or dBoard, or SpeedReader, or Fanglr. All projects that I’ve been incredibly excited about, and all terribly incomplete.

Well, no more. I’m going to manage my push-down stack, and make sure that I always go back to and complete projects that were interrupted. I won’t stop the interruptions. They’re fun. But I will make my default activity finishing the current project, whatever that might be.

So look out for a blog post about Bogus Quest soon. And, after that, keep your eyes peeled for Postal Worker 13. I promise!