Writing Mechanically Solid Parser Games

Introduction

I’m running a long-form text adventure game jam called ParserComp, and I’ve been writing an accompanying series of articles about how to write parser games in Inform 7.

Perhaps because I’ve been steeped in mechanics, this article is a particularly mechanical look at game design – what can be done with parser, rather than what should be done with parser. It’s a post at the ten thousand foot view, rather than getting down to the nitty-gritty of how to write an effective room description, how to build an effective puzzle, or how to guide players forward without putting the game on rails.

I’ll write those later. Promise.

Understanding the Medium

There are some things parser games do very well. There are some things parser games do very badly.

The key to writing a mechanically solid parser game is to focus on the things parser games do well, and steer away from things parser games do badly – or to find a way around what normally goes badly, and showcase whatever you did that makes it work so well.

Key Parser Constraints

For each of these examples, there are counterexamples, but they’re not common, and they require a great deal of work to implement. If you’re just starting to write text adventures, you should expect to work within these constraints.

Parser games are text-based.

Players enter typed commands. The game responds with composed prose. Sound and graphics (ASCII or otherwise) are minimal or nonexistent.

Parser games are turn-based.

Players have as long as they want to consider their next action. There is no concept of true time pressure. There is no “twitch” gaming aspect.

Parser games are single player.

Players can’t expect real-life friends to log in and join them.

Parser worlds are divided into discrete, separate rooms in space.

Each room is encapsulated. While other rooms exist, players can’t normally observe or interact with anything outside the current room.

Contrast this with a game like Minecraft, where you can stand on top of one mountain, stare over the forest valley to the far ocean, and then hike to the shore without a screen load. It’s kind of like binary versus analog.

Parser worlds are divided into discrete, separate actions in time.

In reality and static fiction, our actions blend one into another and overlap one another. People can simultaneously walk to the convenience store, chat with friends on the phone, and dodge dog poop on the sidewalk.

Parser games don’t have that luxury. While careful programming may create the illusion of simultaneous action, the reality is that parser game time passes at one speed – command-sized chunks. In real life, “WALK TO GROCERY STORE” might take 15 minutes, while “CALL FRIEND ON CELL PHONE” might take 8 minutes, and “DODGE DOG POOP” might take 1 second. In a parser game, the player’s input is discrete each time, and the game’s reaction as well.

Parser games offer a reality of finite player choice behind an illusion of infinite player choice.

At any given point, it is possible to build a list of every command available to a player in a given parser game. There may be many hundreds of choices on that list – everything from “EXAMINE ME” to “RUB LAMP” to “USE THE TROWEL TO PLANT THE POT PLANT IN THE PLANT POT” (as Magnetic Scrolls used to brag about their parser).

But the player can only make choices that have been implemented by the author and the system. The illusion of infinite choice depends upon anticipating choices the player will want to make. Providing intelligent responses to those choices is the biggest mechanical challenge faced by a parser game author.

What Parser Games Do Well

The Bartle Test of Gamer Psychology classifies players of multiplayer online games into four categories, based on whether they prefer to act on or interact with other players or the world. Bartle divided players into Killers, Achievers, Socializers, and Explorers with these axes.

These axes were designed to examine player inclinations, but they can also be used to talk about the opportunities available in a game.

Parser games are best at providing opportunities for exploration and achievement. Traditionally, parser games are full of puzzles, which fit both categories squarely – the achievement appeal of solving a puzzle, and the exploratory appeal of accessing whatever new content lies behind the puzzle.

Parser games feel spacious and versatile. No matter how many rooms a parser game actually has, it will feel vast in space, time, and opportunity to a player who hasn’t yet encountered its limits. If a parser game correctly guides the player, the player will make choices and move in directions that have been anticipated by the author, producing an ongoing pleasurable experience that reinforces that illusion of infinite choice.

In the special effects department, interactive fiction : video games :: books : movies. When your special effects are lines of prose, you can execute anything you can write about. Time travel, psychic powers, shapeshifting, casts of thousands – it’s all within the reach of prose, and therefore all within the parser’s potential reach.

What Parser Games Do Poorly

Everything that can go wrong in parser game design involves breaking one of two illusions: the illusion of infinite choice, or the illusion of a consistent world.

When those illusions break, the player experience goes downhill fast, producing problems such as guess the verb (where the action is obvious but the command is unclear), psychic author syndrome (where the solution to a puzzle cannot reasonably be derived from the environment), and crimes against mimesis (a variety of immersion-breaking problems with the surrounding universe).

In order to maintain those two illusions, a certain level of skill is required from the player – or carefully crafted handholding, hinting, and guidance from the game. It is difficult enough to maintain those illusions for an experienced player, who is cooperating with the parser. To a novice, “SEARCH THE HOUSE FROM TOP TO BOTTOM UNTIL YOU FIND THE MISSING NECKLACE” looks like a completely reasonable instruction, and it is difficult to teach new players how to operate within a parser’s moment-to-moment protocol.

Parser games are single-player, so the only other “people” in parser games are ones that have been pre-programmed. It is extraordinarily hard to write a believable, realistic NPC (non-player character), one who responds to conversation and the player’s potentially bizarre actions alike. This means that it is difficult to cultivate some emotional responses in players, since the obviously artificial nature of other NPCs acts as a turnoff.

It is also particularly difficult to simulate things that are by nature interconnected with the surrounding world. Fire, water, and rope are three classic examples, each carrying its own huge list of associated design decisions.

• What items are flammable? What are the properties of an object on fire? How does fire spread? What happens to a fully burnt object? Should fire produce ashes, soot, and smoke?
• Can objects get wet? What are the properties of a wet object? Does water drip off or evaporate? Can some water be separated from the rest of the water? Can objects be damaged or destroyed by water?
• Can the player tie objects together? Can the player drag objects at the end of the rope? Can the player tie something to the end of the rope and then throw the other object and keep the rope? Can the player cut the rope apart and make multiple ropes?

Authors can avoid messy design decisions like these by choosing discrete, solid objects to go in the game.

Recommendations for Leveraging Parser Strengths

Keep the setting small.

Parser games often feel larger than they are, but they never feel smaller, and unless you’re an experienced parser author, every room will take longer than you think it will. Each additional room requires additional writing, additional objects, additional implementation, additional testing, and (eventually) additional brainpower or mapping time for your players as they try to remember where everything is. Trust the medium, and reduce your map.

Implement objects with a light hand.

Realism isn’t everything. There are more than 40 objects on my desk right now – and that’s when some objects are grouped together, such as “a stack of index cards”, “a stack of papers”, and “a stack of business cards”. Imagine this in a game:

>look desk
On the black wooden desk, you see a copy of Creating Interactive Fiction with Inform 7, a copy of Plots Unlimited, a white Xbox controller, a black Xbox controller, a tiny black screw, a pink spiral-bound notebook, a cell phone, a pair of rhinestone-studded arm warmers, a wide-screen computer monitor, a smaller computer monitor with a prominent scratch, a purple Bic mechanical pencil, a green Bic mechanical pencil, a rubber band, a blue hair tie, an arcade token, a stack of business cards, a wireless keyboard, a pink tube of hand lotion, a green butterfly coaster, a can of Dr. Pepper, a flying squirrel puppet….

That’s only 20 things so far! It’s a world of red herrings and hurt from the player’s perspective, especially because the most prominent items are buried in the wall of text. But it’s nowhere near that confusing in life.

I will admit that I need to clean my desk. But it still demonstrates why everything present in real life shouldn’t be implemented in a game.

Build problems that can be solved by acting on objects.

A parser game can be conceived as a series of explorations that are divided by a series of blocks. The player explores, then encounters a block (a puzzle) that stops exploration in that direction. The player takes one or more actions to resolve the situation and then moves forward.

Those actions, like everything else the player does, must be conceptualized in light of the discrete nature of parser spacetime. Generally speaking, they will look something like “Take action X with object Y” – resulting in player commands like “Drop bird”, “Give food to bear”, or “Wear 3D glasses”. (Lock and key puzzles are very popular for a reason, and they can be dressed up in a remarkable variety of ways.)

By contrast, puzzle solutions that cannot be divided into discrete actions on objects are much harder to build and much harder to implement. Examples of these puzzles would be things like “Convince the guard to let you go on account of your wounded mother”, “Train the dog to pick up the soda bottle on command”, or “Use the potted plant as cover while advancing on the shooter”. All of these would work fine in static fiction, but they break down under the command-by-command, moment-by-moment nature of the parser.

Build stories that relate to people.

Okay, this recommendation isn’t mechanical. But I think it’s important, and I typically think of it back-to-back with the last one, like so:

Build problems that can be solved with objects. Build stories that relate to people.

It’s hard to write parser games that include people, because people are really hard to simulate without breaking the illusion. But if a text adventure is “a crossword at war with a narrative” (as Graham Nelson said in The Craft of Adventure) then the narrative must exist as well as the crossword. Puzzles are easier to program than people, but people are more interesting than puzzles.

If your story relates to people, and the people are interesting, then they’ll be interesting even in absentia. You can show them through flashes of memory, or voices over loudspeakers, or psychic impressions, or simply by allowing your player to wander through spaces they own. Whether you’re trying to withstand enemy interrogation (Spider and Web), work on your dissertation (Violet), save the souls of an alien race (Coloratura), or just deliver the mail (Wishbringer), having a core context related to people will help the story aspect hugely.

Play to learn

The best way to learn about the possibilities in parser games: play parser games.

Play good games and then read the reviews, so you can see what they did right. Play bad games and then read the reviews, so you can see what they did wrong. (You can find examples of games by checking the IFComp site, and lists of reviews by checking IFWiki.)

Play old classics, like Zork or Hitchhiker’s Guide to the Galaxy, and then compare them to more recent games like Andromeda Apocalypse or Rover’s Day Out.

Play games in different engines – not just Inform (Zcode or Glulx), but TADS, Hugo, Alan, and others – to see how the parser changes, and how that affects the game.

And just play because it’s fun.