The Stack

Spoilers follow the break

And once again we have a demo of a homebrew system, but this time it has some puzzle content, an escape-from-work scenario. It’s “snack-sized” (as the author describes it) and very old-school in both its content and its presentation, all minimalist and solitary.

The system behind the game is Java-based. I myself once tried creating a Java-based adventure system, long ago, when Java was new and exciting. I was convinced, at the time, that Java’s Exception model would simplify command processing in all sorts of ways, but ultimately gave it up when I decided that a system where you needed a separate source file for every class wasn’t ideally suited to a genre where most objects are singletons. This was before there were Inner Classes; modern Java is a lot more sophisticated than what I was dealing with back then, and may be better-suited to what I had in mind. On the other hand, every time I look at Java source code these days, it always seems to be a mess of Factories and Managers and other constructs with no obvious connection to either the problem domain or the underlying technology, and I think I want to keep away from whatever it is that’s distorting people’s sensibilities so much that this looks like good code to them.

At any rate, the system used here, called MechaniQue, isn’t much like my abandoned one: where I was trying to make a system for making adventure games in Java, this is adventure game system that merely happens to be written in Java. In fact, the author’s web page brags that the system is easier to use than other systems because it has “no objects, functions and variables”. What? Looking at the documentation, and the Nerd Quest data file (which is just rot13-encoded MechaniQue source code), it seems that the entire state of the game is stored as a single undifferentiated bag of strings that it calls “keys”. Even the locations of objects are stored as a key formed by concatenating the room name and the object name; even the command line is processed by turning it into keys. This is certainly simpler than using objects, functions and variables, at least in the sense that contains fewer concepts. But easier? Writing an adventure game in this strikes me as having a likely difficulty somewhere between writing one in BASIC and writing one in INTERCAL.

And while I can appreciate how much fun it must have been to put this system together, it is, predictably, nowhere near as robust, flexible, or sophisticated as the established ones. It has no “save game” feature, and at one point it crashed (that is, threw a NullPointerException and exited) as a result of simply examining an object. That was near the beginning of the game, and the game is small enough that it wouldn’t take long to replay even if it happened near the end, but still, that’s a bad combination.

Rating: 2