Seven years ago, I discovered MUSHes and MUCKs, also known as text-based virtual worlds. I stayed for the community, but what drew me to them in the first place was online building: the ability to build text adventure settings interactively, in the same environment and in the same way one navigates the same settings: by typing commands at a prompt.
Since then, I dreamed of bringing that unique quality to interactive fiction somehow, but could never think of a way to make the concept compelling enough, especially compared to the sophistication of modern authoring systems. So the idea stayed in a corner of my mind.
Fast forward to this spring, when I had an idea for a kind of text-based RPG with interactive fiction elements. As explained nearly a month ago, part of that failed concept found new life in a Twine game prototype. But then I got around to playing Robin Johnson's Detectiveland, and something clicked. This! This is what I was looking for: interactive fiction with a proper world model, except with a button-based interface instead of a parser (which just isn't friendly to touchscreens... or attention spans). And because this UI is equivalent to a two-word parser, the simplified world model of MU*s would be a good match instead of a letdown. Moreover, Detectiveland has been incredibly popular, revealing a demand for retro, stylized text adventures closer to classic Scott Adams titles than baroque Inform 7 epics.
Now, I could have went with a Javascript API, like I did for Jaiffa. But that would have tied the new authoring system to a single platform again — the web browser — and made it inaccessible to anyone who lacks the time or inclination to learn programming. Besides, the point was to make something different. Which reminded me of that old idea. But command line apps aren't as easy to make as they seem, and ever harder to make friendly.
Enter Python's standard cmd module. Having eyed it ever since that article about verb-oriented game design, I finally got around to experimenting with it in September. And it turns out to be an amazing piece of software. Not only cmd makes creating command line interfaces easy, it also encourages you to write documentation upfront. I found myself writing the design document of a game right within the source code, in the form of help text for the player. Little wonder that this Python module has been widely emulated in other languages.
Of course, the command set of TinyMUD descendants has been pretty much the same for some decades, so it was a matter of days to end up with this:
I went with a very early screenshot here, because recent ones are rather overwhelming: there are thirty commands and fourteen other help topics right now, and there's not even any kind of scripting support yet — every behavior is implicit in the data model. Which of course means the interpreter has to shoulder the burden:
Even so, it's still smaller than the editor. Only because it's very incomplete, of course — it can barely run an imperfect Cloak of Darkness. But it's also very simple: shouldn't be very hard to reimplement in, say, Python and Tkinter. For that matter, it wouldn't be very hard to replace it with something quite different, for example a command line front-end sporting a two-word parser. And the story files are JSON-based, making them easy to embed in either Javascript or Python to form a stand-alone game.
Which begs the question, why bother with the MUSH-like interactive editor in the first place? After all, the format is uniform enough to edit with a spreadsheet — no, really! Or you could make it easy to manipulate with an ordinary text editor:
[META]
title = Untitled
author = Anonymous
[limbo]
type = room
name = Limbo
description = You are in Limbo.
[hero]
type = actor
name = me
description = As good-looking as ever.
location = limbo
Well, you know what? That would be great. In fact, if my little toy catches on, I'd love to see all these approaches being tried, and others besides. That's the forgotten strength of data-driven authoring systems. Even better, none of this precludes adding a scripting layer on top later, without disturbing already present functionality.
But first, to go as far as possible with just data. I'm willing to bet that's quite a lot.
P.S. You can grab an alpha version of the system, and keep up with developments, over on GitHub. Feedback is welcome. Enjoy.
Comments
I like this effort and the different approaches being explored – kudos! I’ve also been working on a custom mixed simulation-and-choice-game system(commercial project so nothing much to share now) and went for a high-powered “edit one giant XML file” scheme, but have recently been thinking about things like chatbots and how a one-topic-at-a-time interactive dialogue approach can really help with creative blocks sometimes. That’s something I want to explore more at some point.
On scripting, I came to the conclusion some time ago – through many other “game making tool” projects – that a good end-user UX eschews general-purpose power, as it makes the workflow a lot more dirty and undirected; and having the power without also having good tooling and debugging backing it up makes for an awful development experience, while bootstrapping heavily off the outer environment(e.g. how Twine employs JS) is an ugly hack that hurts portability to new runtimes. The “form-driven” experience, in contrast, is straightforward enough that young kids can usually pick it up, if it’s presented with some polish.
But I still want to have the possibility of power at a lower layer, even if it isn’t exposed in the source data syntax, which led me to iterate into a tiny VM model that focuses almost entirely on concurrent flow control, black-box API calls, and resource addressing(e.g. pulling in data like body text, images, etc. with a unix-like path system). The VM can own its own variables, but it doesn’t have a built in notion of computation beyond passing or returning values – that’s something the APIs do.
Addressing turns out to be a huge concern as you go farther down the VM+API path: how to compile the resources from source, relate them to each other, mix dynamic and static resources, serialize, typecheck categories of resources(including ones derived at runtime), swap elements at runtime for fast iterative development, etc. Building up this knowledge is getting me towards a stronger model for game engines of many kinds, IF or otherwise – something I can’t quite realize as a full-fledged system until this project is out the door, but can at least toy with and set down a few experimental roots.
— James Hofmann
Well, power and generality versus ease of use is a delicate balancing act. It should also be a deliberate one. I want a full-featured scripting system in Adventure Prompt, too, but if it becomes as cryptic as MUSHcode or MUF then I will have failed as a designer. Putting together a simple interpreter is easy, and that’s exactly where the trap lies. Luckily, I came up with a plan.
Thank you for the nice words, and good luck with your own project. Stay tuned.
— Felix