Announcing Adventure Prompt

2016-11-17

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:

advprompt screen

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:

advprompt cloak

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.