Category: parser

On Twitter, a teacher asked me what to tell her students about writing parser games that can be picked up and played by anyone, and therefore will make good portfolio pieces.

This is, in my view, a lot to ask, but there are two basic schools of thinking that people have pursued: the maximalist and the minimalist. (Terminology inspired by A. DeNiro talking about “new minimalism” recently.)

Maximalist: You start by asking if the player has played IF before. (Do not ask if they want a tutorial: they may say no even if they need it.) If they haven’t, give the player a tutorial. Alternatively, thread a mandatory tutorial into your first scene that at a minimum introduces examining, taking, dropping, checking inventory, movement, opening and closing things, and probably instructions on how to save and restore.

Throughout the game, you highlight keywords in output to help them find nouns that they can interact with; ideally, you provide dynamic hints and other features that will help them get un-stuck. You might even provide a suggestions mechanism to identify viable commands.

You might put in parser features that notice if players are trying to use common-but-wrong grammar, such as adverbs or attempts to include their body parts in commands (HIT DOOR WITH FIST, e.g.).

This discussion thread gets into some recent thinking about the maximalist approach.

Examples of the maximalist approach: Bronze, Blue Lacuna. Aaron Reed’s Small Kindnesses extension for Inform and his Player Experience Upgrade implement a lot of these features. These are based on Aaron’s extensive research into transcripting and first player encounters with games.

Minimalist: Instead of trying to make the player comfortable with the full expressive range and genre standards of parser IF, you’re making your game straightforward enough and well enough signaled that they don’t need to understand all that. This is solving the problem through design rather than through implementation, and it is absolutely what I would recommend to students on a short project.

Start by restricting your verb set. Pick just a handful of verbs that are going to work in this context and disable everything else.

Announce your verbs clearly at the beginning, and/or keep them on-screen the whole time. Make sure those verbs are amply implemented and always provide some result for the player: you want to make up for the limited inputs by making sure the player’s experience with those inputs is always juicy.

It may again be useful to highlight interesting nouns in the text as well.

Examples of the minimalist approach: What Fuwa Bansaku Found, Superluminal Vagrant Twin, Treasures of a Slaver’s Kingdom, You Can’t See Any Such Thing. In general, Chandler Groover and CEJ Pacian are particularly prolific in this area.

Orthogonal to the Maximalist/Minimalist choice is the question of allure — how do you make the parser game look good on screen so that people will perceive it to have value?

And there, unfortunately, Inform is lagging hard behind Twine and other options. If you have a game you can compile in a small enough space for the Z-machine, you can build a game that cooperates with Vorple, at which point you have the resources of Javascript at your disposal and can more or less do whatever you want. You Can’t See Any Such Thing is using Vorple, and so is Guilded Youth. Recent versions of Inform struggle extremely to fit anything into the Z-machine size, though — you have to disable features to get even the most default game to be small enough — so in that case it’s more a matter of using Quixe and then trying to make the stylesheet as elegant as possible. Superluminal Vagrant Twin demonstrates some effort in this direction.