Born of technical limitations, parser-based interactive fiction has proven to have enduring qualities. Fans of the medium invoke the natural feeling that you're simply having a conversation with the computer, as well as the impression of freedom — that for a while you can suspend your disbelief and pretend you can type anything at all at the prompt. Myself, I like how you can easily see what you did a moment ago, so there's less to remember, and just as easily repeat a recent command, with or without changes, no matter how complex it is.
The downside to that, of course, is that the illusion of complete freedom shatters all too easily, and that presumes you were able to enter "the zone" in the first place. Which just isn't for everyone. Commands have to be learned, you can't just stumble upon them like in a graphical game, and despite many attempts at tutorials, both interactive and less so, beginners still struggle. Perhaps because tutorials can teach you the form, but not so much the mindset — the method behind the madness, that you need in order to intuit new commands by yourself. The latter is something you must figure out alone. And sooner or later, you will have to.
Because, you see, not only does interactive fiction partly rely on discovery — on making some possible actions non-obvious — but there are way too many commands to teach them all outright. If I'm not mistaken, top-tier authoring systems each provide about one hundred default verbs, of which three quarters will be completely irrelevant to any particular story. But you still have them at your fingertips, and unless the author takes great pains to steer you away from all that fluff (an undue burden, considering how many other details they need to take care of), you'll be left to navigate a maze of fake options in search of whatever nuggets of meaningful interaction are sprinkled throughout.
It's one thing to gently weave a consensual illusion, and another to actively mislead the player, then shrug and smile when they call out your lie.
In my recent work with Alan 3, I took advantage of the platform's nature to only include those verbs that are likely to be widely used in the vast majority of games. That way, if the game does understand a verb at all, there's a good chance it has an actual use at some point. But that doesn't solve the discovery problem. I could include a tutorial... which is likely to have as much text as the rest of the game together, and still leave things unclear. You see, in a MU* you have real people there with you in the virtual world, who can hold your hand while you learn the most important commands — mostly just how to move around, and "say"/"pose". While in a single player game, if you just aren't on the author's wavelength, you're out of luck...
There has to be a better way. And I thought of one.
Imagine, if you will, a game development system where you start by declaring the verbs that will be available to the player. There is only one by default, namely "help", which lists all other verbs automatically, and can show you the syntax for each one. Exactly what they'll do and how will differ from game to game; naturally, the system should offer some basic building blocks, but if we are to recognize parser-based games as a distinct medium with intrinsic appeal, then using it only for text adventures strikes me as limiting. Ever felt that interactive fiction, no matter how high-brow, can get a little repetitive? How many kinds of games never get made because our excellent authoring tools want to be used in a very specific way, and you have to fight them tooth and nail to do anything even a little different?
Programmers reading this must be already thinking of similar solutions used in their own tools:
git help will list all subcommands, and git help <command> will tell you how to use each one;- the
getopt library, too, automatically builds a help screen from the program options you register with it;
- web frameworks such as Bottle work by letting you register handlers for so-called routes — essentially, entry points to your application.
Interestingly, interactive fiction authoring tools can already do this, as you have to declare the syntax of each verb anyway. But I don't think any of them provides a VERBS command except for debugging purposes. This idea that players appreciate the illusion of freedom more than knowing what they can actually do in the game has deep roots.
But wandering off the beaten path is fun. Getting lost, not so much.
(Incidentally, some adventure games provide lists of verbs and nouns to click on, but that's basically giving up and deciding the parser is unsalvageable. And touchscreen devices are begging for different kinds of interfaces altogether.)
Of course, parser-based games that aren't IF have been around for decades. Linux users can install the bsd-games package for a nice collection. More recently, my friend Mark wrote a few of his own, that you can find at zesago.net. And the kind of strategy game I described in my previous article can work just fine with a command-line interface, too. As for other possibilities, sometimes you don't know what you can express until you have the vocabulary to express it.
As for the fact that command lines scare away most people nowadays, I see exceptions all the time, new players discovering MU*s and parser-based interactive fiction and loving it. Maybe it's a niche, but the game industry has already tried catering to the lowest-common denominator, and we all know where that led us. And the approach I'm proposing can lead to games that embrace the idea of carrying a dialogue with the player and behave accordingly for a change.
(For further reading, Emily Short's old article So, do we need that parser thing, anyway? is still highly relevant. And Evennia is kinda-sorta trying to provide the kind of framework I'm describing, except for multiplayer games.)