Mudlab sticks around, like a quietly humming tape drive, full of mud dev ideas; and of course hundreds of muds are out there, some as empty as unmanned lighthouses, but their light still flashing if you care to look for it. Rom, Merc, Mush, Cold, LP…decades of ideas expressed in code and (perhaps) source documentation, waiting to be found again.

It rather reminds me of the endless questions you see on stackoverflow and Hacker News on how to learn programming. Usually the answers revolve around which languages to learn and what books to read. But very, very rarely will anyone suggest what programs to read or what software to use (beyond learning version control or one of the canonical text editors). Would anyone tell an aspiring author they just should read Stephen King’s book on storytelling and a manual on Microsoft Word and get cracking?

In mud forums developers will discredit anything with a DIKU stamp as hopelessly antiquated — yes, old code rusts, but then again, all that glitters isn’t gold.

If you continue the analogy with the writing world you see part of the problem with reading code rather than just writing it; most writing isn’t that good, and a lot of it is terrible. But it seems like it’s a lot more work to find the good code compared to finding the good writing.

Maybe that’s because code is not just meant to be read, but to do useful work — and while it may be less elegant to hammer a trim nail with a framing hammer than a finish hammer, you still get the job done (as I can well attest).

What’s more, the better you are at hammering, the less it matters what kind of hammer you have. Indeed, there’s a bit of pride involved in making rough, crude tools do fine work, and I’d guess it’s even more fun to do it yourself, rather than throwing some expensive (in terms of effort to learn or obtain) tools at the job.

I don’t deny it’s necessary for people to reinvent old ideas, but my opinion is that the successful developers will have an acute awareness of what’s come before them. At a certain point, if you’re serious about what you’re doing, you need to dive down deep.

Have you seen a hundred people gathered in one spot? A hundred people
is a lot of people! If you, as one person, can make something a
hundred people enjoy, is that not an amazing achievement in itself?
Especially, as often in roguelikes, that the hundred people aren’t
just friends and relations pressured into “enjoying it”, but instead
random individuals with theoretically better things to do.

and

I would never advocate intentionally limiting your audience. You had
expressed dismay that a game had only reached 10,000 people, however.
While we can all likely agree it would be better to reach 100,000, it
isn’t necessary. And one shouldn’t feel dismay.

Turn it around – there are only so many games *you* can play in your
life. So how many people can expect to have you be a player of their
game? In some ways it would be tragic if all games hit 1 million
players, for that would mean there would only be a few thousand
games! Us humans are way too diverse to limit ourselves that way.

While there’s a vast amount of mud information out there, it’s widely scattered, buried in archives, or surfaces once every umpteen years like that Scottish castle I can’t remember the name of when someone asks a relevant question on a forum somewhere.

None of this is particularly bad or even unusual. Information has a habit of filtering down like groundwater into the substrate of a community. But to beat a bad analogy a bit more, I feel like the wells are starting to run a bit dry.

Between the whole fiasco with ‘mudstandards.org‘ and the general sorry state of protocols with respect to server and client development, if a young coder decides to make a mud or a mud client — a worthy, attractive project, and based on the number of repos on Github I’m not the only one with that opinion — they are going to have a frustrating experience and are not going to get much support from the state of the existing resources.

The mud community doesn’t gain then the resources or energy of those developers in return, and this reinforces a negative feedback loop: projects that could be promising don’t overcome the friction of their early development, and the mud community rolls on without as much progress or evolution as it could have.

Not to say some people aren’t making an effort. Mudpedia is promising (see its comparison of clients) and individual developers seem to soldier on, despite sentiments such as these:

And this is just my personal feeling now, but I’m a little unsure there’s that much value in having shared standards in this field in the first place. In the end of the day this is about making games, and if you can provide a good client that people use to play your (good?) game, that’s all you need. Past are the days of only using telnet from a relatively dumb terminal to connect and therefore there being value in standardized connection. How many of the successful games (not just MUDs) out there support more than one client?

While there’s an important truth here (don’t lose sight that we’re making games) I think it misses an important point. Muds came of age within a strong tradition of free games and shared resources. To now lump muds in with the general field of games essentially ignores that history. While commercial text muds are extremely important in my opinion to the health of the mud community, and not just commercial muds but ambitious games with custom clients, the history of free games and shared resources shouldn’t be consigned to the past or simply salvaged and scavenged like you would a shipwreck.

But back to the point and the title of this post. At the moment there exists no comprehensive, current reference for the aspiring mud developer, but this information does exist and I think could be assembled with some work. With promotion I think new mud devs could find this reference fairly easily, and within a short amount of time (on the mud time scale anyway) we would have a document that, simply because nothing else like it exists, would be the ‘go-to’ reference for new mud developers and a touchstone for the rest of the mud community.

My plan now is to contact a few people and start to pull together resources to see how this takes shape.

For a while I’ve been kicking around a 3D mud idea, but certain problems seemed intractable. Sure, I could write graphical building tools and incorporate maps into the client, but the more I explored that the more I felt a deep disconnect between that and the experience I wanted in the text game itself. I had to ask myself if I wanted Godwars 2 with a z layer, and somewhat to my own surprise, the answer was…not really. What I did want was a more dynamic space than what you’d get with a classic room-based mud.

Some muds base their room layouts on coordinates (Dead Souls I think does this as well as the in-development Lithmeria), other muds such as Maiden Desmodus use pathfinding algorithms and landmarks to make navigation easier. The old Legends of Karinth, as well as many other muds, had a dynamic wilderness system in addition to a room-based layout.

What do I mean by dynamic space exactly? I’m talking about characters scaling buildings and cliffs, racing across rooftops, running rapids in a river, jumping off a waterfall…you could certainly simulate this with a 3D coordinate space, or you could write specific systems for what you wanted — rooftops code, or river-running code — or you could even create all of these spaces with a room-based layout.

But to step back even further for a moment — what is the text experience I want to create? My ideal is something between an open world game, and a path-driven game (think of a gamebook or a classic cRPG). In an open world game there’s always something else to explore, new territory to cross. In a path-driven game — let’s call it a directed game — the choices are constrained but each choice gets more weight and narrative and interactive impact.

At first glance this looks like a dynamic wilderness system plus a room-based layout. But when you’re in the room-based world you don’t really gain the advantages of the wilderness space, and vice-versa.

Not to say it wasn’t fun in Karinth, it was. But my thesis here will be that wilderness plus rooms doesn’t offer as many dynamic possibilities as a more integrated approach, and that a full 3D coordinate system the player interacts with directly provides a text experience different from what I’m aiming for.

First a little summary of how most muds handle it. The space of room-based muds is defined by rooms/nodes and exits. Rooms commonly have a sector/terrain type and an indoor/outdoor flag. Some systems use internal room coordinates, dynamic furniture, portals within the room (somewhat distinct from exits), allow missile combat between rooms, define an air/sky space above rooms, and so on.

As you move through the world, you get a room description (or not if you’ve turned room descriptions off in your configuration) and (sometimes) a list of exits, you choose an exit, get the next room description, and so on.

Karinth’s dynamic wilderness used an ASCII map that basically substituted for the room description, only it was a much lower scale view. The game generated the wilderness map from a large graphic map (reading the pixels); traditional room-based zones were placed on the map (much like Godwars 2 places dungeons on its world map, though those dungeons aren’t really room-based).

Two things stand out from this summary for me. First, that once a player has read a room description a couple of time, they’re unlikely to read it again. At that point rooms are purely containers to define the space (with a caveat for dynamic descriptions, which I’ll address in a moment). Second, once this happens, the player’s main interaction with the room is to use it to know where they are.

Of course this is blindingly obvious. But allow me to talk like an idiot for a while (if I haven’t been already). Disregarding coordinate-based muds for a moment, are rooms the only way to know where they are?

What is ‘where’ in a mud anyway? Where can mean a lot of things. It can be where you are in relation to something you’re hunting, or something hunting you. It can be on the way to a destination, or it can be a somewhere you run to or through while trying to escape. It can be a location in a quest or a safe haven where you can rest without fear of attack, a place of quiet work or a gathering spot.

It so happens that rooms are a simple and flexible way to make this work. Coordinate systems extend this concept and add a lot of functionality, at the price of some interface hurdles and other technical challenges. Rooms on a coordinate grid is a third possibility. But is there another way to do it?

Going back to an open world + a directed world. How could you abstract the space in a mud in such a way to create the environment where that experience would develop? I think you could use four elements.

• spaces
• surfaces
• paths
• features

Spaces are containers of any size, arranged in a tree. These aren’t rooms as we know them in muds — I don’t know of any room systems where you can examine the outside of a room, for example. They’re more like a basic thing in a mush; the base thing in Godwars 2 also works similarly I believe, as a container you can put things into (and examine from the outside). I’m not calling them things or containers because I don’t want to pin them down in such a way; a space could be a treasure chest, a house, an ocean, or an atmosphere just as easily.

Surfaces are 2D surfaces (in the mathematical sense) related to spaces, such that they don’t exist on their own. A surface always is in or on a space, in other words. A surface would be a ground or wall plane, for example.

Paths connect spaces, and usually lie on a surface.

Finally, features are interactive or dynamic elements that are not necessarily spaces, though they may be spaces themselves, and relate to paths, surfaces, and spaces. For example, a path might cross a chasm. The chasm could be modeled as a space itself, but often it would be more convenient to make it a feature of the path.

So, why bother? What can you do with this model that is harder to do with rooms or coordinates?

Consider the ideal again — open world plus directed paths — in light of this example: A group of players want to go explore a ruined castle they’ve heard of up in the mountains. They find a path to the mountains and set out.

Now, if they’re not moving through rooms, or coordinates, what are they seeing? Back to dynamic descriptions. The game, using the properties of the path, the characters, the space and the surface the path relates to, its features, etcetera, describes the experience of travel. The path has a distance which determines the amount of RL time this process takes. It’s like a pen and paper game where the DM leads a party through encounters and choices.

In other words, there are no room descriptions, but periodic messages that describe the experience. However, this seems to create a problem related to the discussion above — how do the players know where they are? Fortunately the answer is quite simple. Based on how far along the path they’ve traveled, where they are is a slice of the path at that moment, much like the description you see in Godwars 2 at any one moment as your character is traveling.

If that’s the case, though, isn’t this just a very circumscribed coordinate system? What makes a path better for this experience?

I think the advantage is that the path is especially created as a directed experience for the players. The encounters, the messages, can all be tailored for this experience as well. Of course, you could accomplish much the same thing in a coordinate system by adding paths to it — but what is the interesting part here? The path or the rest of the coordinates? I would argue the path.

But, that ignores the open world I was talking about. Indeed, straying off the path often is just as interesting! Laying out many, many paths from the ‘current path’ at every point of that path doesn’t seem ideal.

This is where spaces take over. In our example, the players are on the path, now in a forest (a space). A couple of characters have the idea of exploring…what happens?

The forest space now takes on some of the functionality of a path. It provides encounters, messages, and choices as the players explore. Whereas on a path the player doesn’t have to worry about direction (always either going forward or back), in the open space the players do need to make navigational choices presented by the space. However there are naturally other paths in the game world, and what happens is the other paths ‘pull’ the players towards them. So, the forest is a possibility space; once you stray from the current path, the forest presents multiple choices that lead you in the direction of other paths.

So our characters wandering in the forest come to a steep cliff wall. Here is a surface. The cliff could be a space of its own, but in this example it’s more likely that it’s a surface within the space of the forest. This surface has properties of its own — the difficulty of climbing it, what players may find on it, and so forth.

The cliff also brings up the question — once the players climb it, where are they? How far are they from the original path? How much time would it take to return? Could they return by some other way, not climbing down the cliff if it’s too dangerous?

Ultimately this question is asking, are spaces, surfaces, and paths actually related in space in a logical way? How would players map this ‘experience’ so it wouldn’t be blind wandering every time they wanted to enter the forest? Certainly it would be a frustrating experience if space wasn’t somewhat predictable.

The answer is that the elements are related in 3D space, but the player doesn’t interact with the coordinates at all. Their framework is basically time and spatial relations (how long does it take to go from this to that and in what direction, that is, a vector) and choice (what do I go to, and how). So in the case of descending the cliff, the players really are wanting to go back to the path from which they came, and so the game would offer them the option of finding another way around the surface, taking time and spatial relations into account.

By completely abstracting the 3D world, yet maintaining it in the underlying simulation, the player gets the dynamic movement of an open world and the directed experience more similar to a classic room-based layout. The game stresses what’s important — time, spatial relation, and choice — while not bothering the player with micromanaging coordinates.

It should be clear that the text experience you get here probably won’t be appealing to many players used to room-based layouts, but I feel that it could attract a different group of players with its ‘directed freedom’.

So, where to go from here? With any luck, a prototype, using Pants for networking.

The thing keeping me up last night was compiling Steel Bank Common Lisp for Windows. Mostly a straightforward job thanks to the fine folks working on sbcl and the msys/MinGW build environment, but if you ever need to do the same thing, just put the sbcl source directory in a path without spaces before you compile — trust me on this one.

The other wrinkle not really mentioned in the sbcl install docs is you’ll probably have to explicitly set the sbcl home variable if you don’t usually work as the Windows admin user, and then reboot your system for the path changes to take full effect.

What led me to compiling sbcl rather than using the slightly older Windows binary was a problem loading cl-tcod from within Emacs+SLIME using Quicklisp (a nicer alternative to the older asdf-install package loading library for the language Common Lisp).

If you’ve read stuff here before you may recognize the tcod initials — cl-tcod is a binding for the great roguelike library libtcod. Not only is libtcod a great roguelike library, but the community has grown so much that it now has bindings for many different languages. For a language aficionado like myself, that makes it a great handle to learn new languages that I’m interested in — which brings me full circle back to the title of this post, game development, and Lisp.

It may sound weird, but I feel like going to the land of Lisp is an inevitable part of my programming bildungsroman. It started back in May with some prompt or another, I don’t remember exactly what, which led to trying out Racket, a dialect of Scheme. Racket is quite nice, and I found Michele Simionato’s The Adventures of a Pythonista in Schemeland an excellent guide along the way.

But in the end, even though there is of course a Racket binding to libtcod, I felt there wasn’t enough support in terms of a game development environment with Racket. However it did look like there was a lot of activity on the other side of the fence so to speak, with Common Lisp, once I discovered the Lisp Games Wiki — and so I was lured over.

It seems like Lisp is a whirlpool — once I went for Common Lisp, diving into Emacs and SLIME followed soon after. The problem with something like this is the complexity just exploded. It’s nothing like first working with Python, where getting a development environment set up fast is relatively trivial. With the Lisp bindings to libtcod, I found myself really using msys for the first time, compiling the latest libtcod in svn, then compiling sbcl, working my way through the right choice of a package installer for Common Lisp, setting up SLIME, getting the package installer configured correctly, and on and on. Much of this friction comes from working in Windows, and I suppose I accept that willingly given the trade offs.

Then you have Lisp itself, and especially Common Lisp — a 40 something year old legacy and all the cruft that entails. Seriously, some of this stuff almost makes me cry working through it — the influence of Lisp on Python is obvious, and it’s a bloody trail hacked out of the Forest of Lisp! Good guides here have been Practical Common Lisp and Successful Lisp. The Common Lisp Cookbook is a good companion too.

Despite the complexities and the cruft, there’s something about Lisp that’s positively endearing — I can’t put my finger on it yet. It just feels worth it.

Of course I have a roguelike game idea I’m working on in Common Lisp, and I’ll record the progress of that here for anyone else who might learn from it.

So this is (again) the first step. To put all the links in one place, if you want to follow along:

Getting started with game development and Common Lisp

* msys/MinGW
* SBCL
* Emacs
* SLIME
* Quicklisp
* Lisp Games Wiki
* Practical Common Lisp
* Successful Lisp
* cl-tcod
* libtcod
* Common Lisp Cookbook

Mushclient + plugin:

Here’s the update thread on the GW2 forums. Remember to create an /images folder in the Mushclient directory, and use the latest Mushclient (not the stable download) — get that Mushclient here
. And of course, if you don’t know already, information on connecting to GW2 is over here.

I think it’s refreshing that GW2 is moving in this direction. GW2 is kind of like Dwarf Fortress in that it’s an amazing game somewhat burdened by its interface, but it doesn’t even have the retro ASCII niche appeal going for it. I like how the plugins can enhance the experience while still allowing things to work gracefully for those who don’t want or need them, especially those with screen readers.

Once (if?) GW2 gets a one-stop bundled mushclient + plugin download going it’d be great to write a TIGSource post on it.

It’s an early Spring here. You’d think that would get the creative urge going; however it seems to be doing the opposite. On the other hand, I tend to do things backwards at first. Maybe then this is the natural state of affairs. It’s sort of making room for doing a lot of little things in a leisurely and lazy way.

Transplanted the tomatoes to four inch pots:

Found a cool Python editor — basically a livecoding editor — called Reinteract. Haven’t got it to work with pyglet yet, probably because pyglet’s event loop and the Reinteract GTK loop won’t play together nicely without some hacking. Someone on the Leo list clued me to Reinteract, so maybe someone on the list will run with a Leo to Reinteract bridge. It’s a pretty cool IDE, I recommend checking it out.

Starting to play around with an idea for an IF news service. I think as more and more people are blogging on IF, combined with the various forums and newsgroups, some way of feeding (and possibly filtering based on the recipient?) the flow of community information will become more valuable. I like Planet IF but it’s not really serving this purpose at the moment, and I’m not sure that it could; what I’d like is something that gathers all the disparate sources. And well, since I obsessively read everything anyway, why not put that to some good use. The first iteration was just me collecting links. I have some ideas on where to take that but nothing solid yet. I also have wanted to get more into web stuff so this would be a nice project for that.

Worked some more on mockups for a Python IF IDE in GIMP and Inkscape, and realized that’s harder than I thought it would be! I’d really like to work more on drawing to make this easier. As a result I’ve started to learn the Qt framework for GUIs, which is easier than I thought it would be. So there you have that.

While in the library today to pick up a book (and pay my overdue fines, again; I think I must support several librarian’s wages really) a book on display caught my eye, The Assault by Harry Mulisch. In the first part of the book a 13 year old boy witnesses a German collaborator gunned down by the resistance in front of his house, his brother disappears into the night with the collaborator’s gun, and the Germans arrest his family and destroy his house with grenades and flamethrowers. Then he spends the night in a jail cell with a beautiful wounded Communist terrorist, narrowly escapes death the next morning when an Allied fighter strafes his convoy en route to Amsterdam, and finally reaches safety in the arms of his uncle. Mulisch is a prominent Dutch author (who I had never heard of) and it shows, the writing is masterful even in translation, and shares a lot with two of my favorite writers, Saramago and Murakami, in the way their narrative voice exists on top, through, and under the work itself.

As usual I have a list of ideas a mile long. Something is brewing, I just don’t know what.

In my opinion there currently are three viable options for creating IF with Python: PAWS, PyF, or a custom system. An alternative form of IF can be made with Ren’Py, a visual novel system. Finally, there are two possibilities in the future: Curveship, and another I learned of recently, Prosemonger.

Two other ‘less possible’ possibilities are PUB, and any one of a number of Python mud engines (particularly those with Twisted, a lib originally built for mud IF).

But let’s talk about making a game, using Python, in prose-based, command-line IF (you know, what most people call, ‘IF”). That rules out Ren’Py, PUB (too old), and Python mud engines (too incomplete, or conversely, too complicated I think).

Curveship and Prosemonger are out too of course, as they’re not yet released. As an aside, while I’m eager to write with Curveship, from what I know I don’t think it will be much like IF as it’s played and written today. I think it will be more akin to an academic, generative narrative system, but only time will tell.

At this point a digression is in order (well, with me digressions always are in order, but I…OK, I won’t go there). When I say ‘towards popular Python IF’, what does that mean anyway? And why would you want to write IF with Python in the first place when there are at least five major IF systems that would fit the task very nicely — TADS 3, Inform 7, Inform 6, Hugo, and Adrift?

I’ll take the second question first. How does Python compare to these other systems?

First, let’s dispense with the VM argument — i.e., the relative portability of the Python VM versus the z-machine or anything else. In my opinion this won’t really matter in the future. Why? Because most mobiles, tablets, and so on will have capable web browsers. Therefore the portability of a VM won’t matter, so much as its ability to compile a game to something like a JavaScript source (here we may ask why someone is not writing a full-fledged JavaScript IF development system…and that would be a very good question!).

In this respect Python is in a good position. There are many parallel efforts right now to bring Python, or a Python to JavaScript bridge, to the browser.

These efforts attest to one big advantage of Python — its user base. There are many libraries that cover topics relevant to IF — language parsing, intelligent agents, knowledge models, and so on. Above and beyond that, there are numerous game and multimedia libraries available as well. All in all it’s a huge resource for an IF author.

At the same time, if you wanted to write IF using these libs, it’s a bit like making snowballs in an avalanche. What the IF systems do is make a domain-specific language available that puts you miles ahead of anyone trying to write their own parser and world model, or assemble one from third party libraries.

Python also has a couple of disadvantages in my opinion with respect to IF:

1. because Python isn’t an ‘IF language’, it doesn’t respect one important IF convention — the ability to make source code assignments and definitions without regard for their order in the source code file.

2. Python source code isn’t interested in the marriage of prose and code — I think this is a critical consideration when designing a structure in which to write IF.

Prosemonger and PyF, I think the two most viable ‘contemporary’ Python IF options (though Prosemonger isn’t yet released), both take a similar approach to the ‘IF writing structure’ — the world is declared in a structured markup, XML. This somewhat gets around the two disadvantages noted above, by setting up a universal structure — XML, and scripting — for the source code.

It’s a sensible approach, but as you may have guessed by now, I’m not sure it’s a good one. First of all, writing and editing XML creates a lot of friction.

A solution to that, of course, is a good XML editor, especially with a WYSIWYG authoring environment (I’m not sure anyone really advocates for hand-editing XML in the first place), but I wonder whether that really solves the problem? Regardless, in my own experience, I’ve always dispensed with visual editors and gone to the source code to get stuff done, and as a hobbyist it’s not like I’m really hardcore or anything.

Still, just from using Leo, I think structured source code is a good idea and I think as one ‘view’ of such a structure, a good visual editor could work. My take on this has changed from my original pawsy experiments — an attempt to write ‘prosey’ IF while including Python scripting. Such source code may not be necessary with the right editor.

The question is whether this editor is something that could be bolted on to an existing system (it doesn’t seem like such a tool is in the plans for PyF or Prosemonger). Furthermore this doesn’t really solve the first disadvantage above, that of source code assignment order. That’s really a problem that is asking for a compiler pre-parser (what most IF languages use I think), so now two tools are asked for, an editor and a pre-parser. It’s not like people haven’t made third-party tools like this for IF before (there’s at least one IF-specific code editor out there), but are the best tools made hand-in-hand with the system they’re used for?

I’ll punt on that question for a moment, because I don’t want to say that writing in XML is such a big downer that it obviates the advantage of the ‘Python universe’ of code. Writing an example game with PyF and incorporating Twython, for example, was really fun, and Python syntax itself is quite nice (opinions on this, of course, vary!).

Another major point in Python’s favor is it’s not weighed down by the multimedia or typographical constraints of the IF systems, all of which tend to roll their own solutions, rather than using common standards — for good reasons respective to each system, for sure, but it’s still something of a burden.

To go back to the first question, what does ‘towards popular Python IF’ mean? I didn’t say ‘making Python IF popular’, as I’m not really sure you could do that if you tried, but by popular I mean:

Easy to communicate for authors and players: Browser interpreters, sharing libs (i.e., extensions in IF parlance), sharing transcripts — on open, democratic platforms.

Easy to write: not in the sense of a visual editor, or filling out checkboxes instead of writing source code (which I emphatically don’t mean), but writing IF in a humane way, a people-centered way, without ignoring the essence of the work as a program.

So by popular, I mean, ‘for and of people’. Well, it’s a little ambiguous I admit, but suitable as a design goal nevertheless.

Where do I leave this, practically speaking? Taking PyF as a base is one starting point, and waiting to see what Prosemonger (and perhaps Curveship) is made of is another. I’ll try to get to some details of a structured source code IF editor in a future post.

It comes up a couple of times that Earl Grey was criticized in IFComp reviews for not conforming to the IF community’s expectations — that it had ‘too much interactivity’ (not a quote of Parrish, but the interviewer) — but from what I remember of the reviews this wasn’t the main criticism at all, rather reviewers wanted more interactivity. They felt that the Earl Grey puzzles were unfairly arbitrary and obtuse, and didn’t explore the mechanics nearly enough. I’ll quote Victor Gijsbers at length (to make sure I include the good things he says, because I should add I did like Earl Grey a lot too):

This is a delightful idea, but its execution leaves a lot to be desired. There are simply too many words in the game that ought to be knockable, but aren’t, or that ought to be castable, but aren’t.

[....]

I can see how this would have been a pain to implement, but really, this game needs to be more open. We have in this magic system the perfect opportunity to reward player creativity and have multiple solutions to all puzzles, but instead, the authors have chosen to make the game very linear indeed. Only the things you must knock or cast or steep can be knocked, casted or steeped. Nothing else works.

[....]

The game, then, is not open enough, and is too difficult. Nevertheless, I enjoyed myself hugely, more so than with any other game in this competition so far. (Okay, I loved solving the card puzzle in The Grand Quest, but that was less because it was a brilliant puzzle than because my linear algebra skills were itching.) The writing was mostly very good. The scenes were evocative, if perhaps a tad too surreal. The implementation was very good as well. The side comments of the main character were a brilliant idea–the piece was much funnier for them, and also made more sense. In fact, most of the jokes actually worked.

But, most importantly, as far as the puzzles were solvable, they were great fun. This is interactive fiction doing one of the things that interactive fiction does best: using language in interesting new ways, doing things with it that could not be done in any other medium.

Of the eight competition games I have played so far, this is the first that might make it onto my list of “must play” games published in 2009. Not because it is perfect; it is not. But because it explores a very interesting puzzle concept in a highly competent and often enjoyable way.

Oh, and Rob and Adam? If you make a post-competition release which responds to more input and allows more solutions of the puzzles, this game might actually rise to the level of “great puzzle game”.

- [IF Competition] Earl Grey

In any case, I definitely recommend it. A lot of other good interviews at Another Castle too.