This post is about 2D vs. 3D world modeling, but I’ll start with a preamble for those who arrived after the newsreel.
Preamble. I’m a writer. I do text; I don’t do graphics. If I feel like creating an interactive software something-or-other, as happens from time to time, I’ll head straight to the text adventure (also known as interactive fiction) arena. I’ve been doing exactly that, off and on, for more than 20 years.
Parser-based games were the norm in the Good Old Days of Yore. In a parser game, the reader/user/player types commands, such as “pick up the sword,” and the software responds in some manner. The user interface is based on the teletype metaphor of 1970s-era computer software. The term “parser-based” means that when the user types a command, it has to be parsed behind the scenes by a piece of software called the parser in order for the game software to make sense of it.
For today’s trendy young people (which is to say, just about all of them), the teletype metaphor is about as familiar as the Greek alphabet. You youngsters don’t want to be parsed, you just want to click or tap on links.
Parser-based games in the old style can still be written, very effectively, in several development environments, such as Inform and TADS. But if you want to write an interactive story that will attract people who were born after Zork (AZ), you’d be well advised to look into a development system that produces games that can run in a web browser. It’s true that both Inform games and TADS games can be leveraged to run in browsers, and they can be equipped with clickable links, but they’re still parser-based. They’re still BZ, not AZ.
The Point. This morning I started looking a little more seriously at Twine. It’s quite popular these days, and Twine games run natively in your web browser. To navigate through the game/story, the user clicks or taps on links. None of that messy typing.
Twine is a sophisticated system, and offers some real advantages for the would-be author of interactive stories. For one thing, you can make the “pages” of your story more attractive more easily. Also, Twine is in active development. (Inform and TADS haven’t changed significantly in the past five years.)
Now for the disadvantage. Parser-based development systems give the author a suite of tools with which to construct a three-dimensional world model. By “dimension” I don’t mean the ability to travel up and down as well as east, west, north, and south. I mean that some concrete assumptions are built in: The world of your story will have rooms, objects, and people with whom the user/player/reader can interact.
In developing a parser game using one of these systems, you don’t have to write your own code in order to create rooms or objects that can be picked up and carried. In Inform 7, for instance, writing the text “The Dining Room is a room” actually creates an object in the model world — a location that the player can visit. In TADS 3, the equivalent would be something like diningRoom: Room ‘Dining Room’.
Not only that, but the documentation for both systems assumes that you want to create rooms and perhaps new actions for the player. Maybe you want the player to be able to “flatter the prince.” There is no “flattering” action built-in, but you can easily create one. Once you’ve done it, the player can try “flatter the little girl” or “flatter the tortoise,” and the game may have an intelligible response if you’ve provided a default output in response to the “flatter” command. The docs will tell you how to construct this intuitively palpable world by writing code.
Twine has nothing like this. Twine’s model of the world of your story is nonexistent. Calling it 2D is perhaps being a little too kind. Twine is about presenting text in the browser, and that’s all it’s about. It’s very good at that, but if you happen to need, let’s say, a dagger object with which to stab the evil duke, you’ll have to write something like $dagger = “dagger”. This is not an object in the model world; it’s simply a variable ($dagger) that contains some text (“dagger”).
Twine’s documentation, from what I’ve seen so far, has absolutely nothing to say about constructing a story that embodies a model world. Your story is your affair. The Twine tutorials focus entirely on explaining how to manipulate and vary blocks of text.
Ultimately, of course, a parser-based game is only text too. But there’s a conceptual layer under the hood that makes certain useful assumptions and allows the author to leverage those assumptions to produce a satisfying story. Twine has no conceptual layer at all; it’s strictly a delivery system.
I haven’t reached any firm conclusions about the relative values of these two very different approaches, but I do sort of wish there was a single software tool that embodied both of them.
Footnote. For the player/reader/user, as opposed to the author, the difference between a Twine story and a parser-input story boils down to this: If you’re playing a parser game, you have to think. You have to visualize the scenario that’s being presented to you and imagine the possibilities. There may be things you can do in a given room that are not obvious on the surface.
Perhaps the simplest example would be, if you (the player character) are in a room with a bed, you should probably try the command “look under the bed.” That command may or may not reveal something important to the story — and there are any number of less obvious commands that the fiendishly clever author may be asking you to imagine. If you breeze through the story and take everything at face value, your experience will (if the author is any good) be badly impoverished.
In a tap-the-link “game,” that never happens. If a link isn’t presented to you, visibly, on the screen, it’s not there at all. A chimpanzee could be trained to play a Twine game without being able to read a word of English. Or a rat, I suppose, if you put the screen down on a table and gave it a suitable piece of cheese as a reward. Not only is imagination not required, neither is comprehension. The process is mechanical.
All of the choices in a tap-the-link story are yes/no. Use this link? Yes. Use that link? No. Still, you can make it look pretty, and it’s easy for people to experience your story. I guess that counts for something.
Jim Aikin's Oblong Blob 