Hidden Assumptions

Last month I decided it’s time to finish an interactive story (a text adventure game) that I started more than ten years ago. I’ve stopped working on it several times, the main reason being that it’s just too darn large. I’m not sure I’m going to be able to get it thoroughly beta-tested, unless I pay the testers. And when it’s released, will anybody ever play it? People have told me they like large games, but it remains to be seen how sincere they are.

This is a parser game, a structure that harks back to the early days of computing. The player types commands, such as perhaps GET LAMP, and the game responds in some way: “You pick up the lamp.” And then you have a lamp that you can light and carry into a dark room. This is how the world model works.

Typing a few words at the command prompt was normal in home computers in 1978, which was about when this sort of game first hit the runway. Computers didn’t even have graphics in those days, just text.

There’s still a small but active community of people who write and/or play text games, but the world of computing has moved on. Spiffy graphics and clicking or tapping links are the norm today. So I had pretty much concluded that this game will be my last venture into the genre. It’s called The Only Possible Prom Dress, and I’m hoping to have it finished in time to enter it in the annual IFComp. You’ll love it, trust me!

And then last night I had an idea for a new game. I think it’s a pretty darn good idea. But I’m not sure it wants to be a parser game.

I use a development system called TADS 3. (That’s an acronym for The Adventure Development System.) While I like TADS and grudgingly respect the more popular system called Inform, I may be ready to try something different.

I’ve written before in this space about the difference between parser-based text games and games written in Twine. Twine stories run in your web browser. They can have graphics and music. Okay, technically you can embed graphics and music in a TADS or Inform game, but it’s kind of a square-peg-in-a-round-hole situation. Those authoring systems were not built from the ground up with the idea that they would present interactive stories in a modern way. Quite the contrary.

Twine builds your story as an html file. It can use css and javascript. It rocks. The Twine stories I’ve looked at tend not to rock, because the writing is usually very bad, but the presentation — ah, that’s the lovely part.

The reason I’ve resisted Twine up to now is that it has no world model. Everything in your story is just flat text. Yes, you can use variables, and that’s vital if you want to do anything serious in the way of a branching story, but if you want to set your story in a world that’s built out of “rooms,” so that your reader/player can travel from room to room, pick up and drop objects, open locked containers using keys, and stuff like that, in Twine you have to build the world model yourself. Systems like TADS and Inform (there are several others) give you a built-in structure with which to deploy your world.

This is a tremendous advantage, if your story is of that hallowed and perhaps too familiar type. But it immediately struck me that my new story idea (which I’m not going to talk about yet) would be constrained, perhaps badly constrained, by the stock world model. I don’t think I want the reader/player to type commands like N, S, E, and W to move from “room” to “room.” In a parser game, every object that’s in the room with the player is “in scope,” which means the player can interact with it using commands, but anything that is not in the room is not in scope, so generally speaking the parser won’t let the player refer to it at all. If the player tries to give a command about some object that’s not in scope, the parser responds with an error message along the lines of, “You see no bathtub here.”

Rooms, scope, and travel by compass direction are a fabulous foundation on which to build a traditional text game. But that foundation will steer the author, unavoidably, in a certain direction. If you happen to want to do something as simple as varying the description of a castle based on how far away it is, you’ll have to fight with the TADS or Inform system, which assumes every object is either present (in scope) or absent.

So yeah, maybe it’s time to learn Twine. I’m still not a graphic artist; I don’t plan to embed illustrations, much less link to videos on my YouTube channel. But there are still things that Twine does easily, things as simple as using a different background color on different pages. And for a certain type of story, clicking or tapping links may be more natural as well as more modern.

Plus, learning a new programming language is my idea of fun. Well, except for the tearing-your-hair-out part, but I do that right now with TADS programming, so I’m used to it.