Parser as Prototype: why choice-based games are more interesting

December 5, 2013 by joningold 32 Comments

Gosh, but it’s been a long time since I wrote anything here. The reason for that is I’ve been tied up with inkle: the last post was September ’12, which was about when we started on our Sorcery! series, and that hasn’t really let up. Sorcery!, if you don’t know, is a series of choice-based text-games for touch screens, that’s done pretty well so far. I’ve been working on the design, and also done the adaptation from the original gamebooks to our inklewriter-based format.

But that’s not really what I wanted to write about. What I wanted to write about the type of games we’re now making. They’re not parser games – they use choices – but in terms of design, they’ve ended up being closer to parser games than anything else. In fact, I’ve got a provocative statement to make, which is this.

“Parser games are prototypes of choice-based games.”

This is not quite true, but it’s quite close to something true. I’m now going to try and argue it.

A Matter of Structure

First up, I don’t want to start inventing terms, but I want to talk about the underlying models behind the game, and not just the interface into that model. Our games have explicit choices – but so does everything from Versu to Choice of Games to a traditional book CYOA. But in terms of how these stories are created, these examples form a spectrum from simulation through to state-machine. We’re on that spectrum ourselves, somewhere left of centre.

We don’t use a simulation-ready engine. By which I mean, none of our games have an update loop. There isn’t a single code-path that gets called on every “turn” of the game, so there’s nowhere sensible to update timers or process background events (note: I mean, nowhere in the script. The apps themselves have update loops, obviously).

Instead, we our scripting language is built around a state-machine: a tree of text, with options that branch to other bits of text, and joins that link the story-flow back up again. It’s got a memory: as the player works through, the engine remembers what you chose and alters counters and flags appropriately, and this information is used to alter the text and choices that appear later.

Modelling the World

But the devil is in the data. We use it to model explicit things, that’s straightforward enough – how much health or money do you have, have you learnt a fact about the backstory yet. But we also do a lot more implicit modelling, say friend/foe counters for what characters think of you, and what the game thinks of you, that alter the game appropriately. These are interesting because they are altered not by one decision but by many. Use enough of these hidden switches, and the outcome of any given play-through might become difficult to predict even for its author, though of course, all the outcomes themselves are pre-scripted.

But it doesn’t end there: we also have support for named constants and routines, and those can either be calculations or  – with a bit more infrastructure in the script – sub-sections of story, that are dropped into, played through, and then returned from. That means with a little more work we can start to model the game world. For instance, we can keep track of the time of day, and create a day/night cycle when the hour shifts past dawn or dusk. Characters can move around the map, based on rules and goals which shift, using variables to track where they were last, and what they think they want.

We can then insert new text, options and even little chunks of interactivity into the flow depending on variable-state: adding in options to talk to characters if they happen to be where you are; or different options for manipulating items if they’re in the required state. We can insert the same interactive chunk into multiple places on multiple occasions (using cycles and sequences in the text to prevent the repetition from becoming obvious). At this point, what we’re doing is more like adding responses to standard commands in Inform than anything you could do in a gamebook.

The Design Process

During the construction of Sorcery! 2, and as we move into Sorcery! 3, which is going to be even more open-world-ish – these possibility are starting to mess with my head. The more I write like this, the more I’m turning off the multiple-choice part of my brain, and turning back on the parser-IF design side. The design process of locations, puzzles and interactions is starting to feel more the process behind The Mulldoon Legacy or Make It Good than the process behind games like The Intercept.

Instead of simply writing, laying down choices that endlessly move the story forward, we’re now constructing locations, adding details, altering the description of those details based on state, providing options to manipulate those states, and providing outcomes based on reaching certain states. That is to say: create rooms, with objects, and puzzles.

So that’s to say, our choice-based games are reaching up out of the gutter to approach the fidelity of a parser game. But parser games are still richer, right? They have hidden affordances, moments of inspiration, that sense of infinite freedom…

The Myth of Freedom

Well, don’t they? I started to think that, no, maybe they don’t. I mean, it’s obvious a parser game doesn’t allow you to type anything. But more importantly, the player at the keyboard of a parser game doesn’t act like the game can understand anything either.

A player – at least, one who is capable of playing – approaches the game with a list of relevant verbs, with an eye for useable nouns, and with an ear for the normal interactions of movement, stacking objects, and pushing, pulling and touching things. They learn new verbs if new verbs are introduced, and mostly complain if new verbs are expected but are not introduced. When we play a parser game in that fluid way we enjoy, we are not playing a game of infinite scope or freedom. We’re playing a game of finite choices, we’re just assembling and filtering that list in our heads, instead of the computer doing it for us.

I’ve argued in the past that for parser games to be penetrable to newcomers, we need to improve the input loop and ensure, at the very least that (a) the player cannot type anything the game simply won’t understand, due to incorrect verbs, or typos, or whatever; and (b) any error, clarification or other null-content messages the player invokes should not hang around a moment longer than they are useful. The player’s scroll-back should be a stream of content, positively-reinforcing perfect playthrough.

But while these two things are now both possible – Interactive Parsing does one, Vorple the other – I no longer think they’re enough. Having the game not let me type a command that it won’t understand is a good way to teach me to interact with parsers, but it’s still the game saying “no” to wrong input. Instead, why shouldn’t the game do that filtering of the context for me?

If it did – if it filtered all the possible input down to what’s sensible and interesting, and then presented them as a choice – surely then the game is reinforcing my presence and position in that world, and not detracting from it. In this new game, every action I take is interacting directly with something which has been determined to be interesting, rewarding and worth my attention. I am in a loop of meaningful activity.

Building A Choice-Based Parallel

The choice-based games we’re now making at inkle are stabs in this direction: they have simple world-models, but clever contextual recognition: we’ll turn options on when they’re relevant and hide them when they’re not.

If you want the joy of the puzzle where you think to do X with the Y, you can still have it, but as an author you simply need to put X and Y in different places and have your player think of bringing them together: that act is, in itself, enough. You want more detail? Make Y a subelement that the player needs to choose to act on, before being given options of how to act — that’s exactly what your text game player is doing in his head as he constructs his X with Y plan, after all.

You want to replicate that moment in Spider And Web? You can; although, the solution will most likely be brute-forceable now. But how many players brute-forced that moment anyway…?

You want to replicate that moment in Photopia? Harder, perhaps, but you can still have a long choice of verbs… and if the solution isn’t the first the player tries, they’ll still have a moment of  delight when it works…

A Shift Of Default

So, at the very least, a choice-game can start to approximate a parser game, to a less or greater extent. We can maybe agree that.

But what about all the things a choice-game does better? Like forward-momentum, story, and dialogue? Simple cause-and-effect? A variation of scale – interacting over moments one minute, years the next? Make It Good contains 5 characters and took 10 years to write; Sorcery! 2 has about forty and took 6 months. None are quite as complex as the ones in Make It Good, true, but several are really quite complex, and can be goaded, fooled, tricked, bribed, discouraged, and misled, over the course of short-to-medium length interactions.

In a choice-based framework, it is easy to make time pass; it is the natural state of play. And this is where I get my “prototype” statement from. There are things I can do in a parser game which I can basically do in a choice-based game, but there are things I can do in a choice-based game which are virtually impossible in a parser game. So, bar a few edge cases, and specific, unusual effects, the choice-based game with a strong underlying world-model provides for a wider super-class of experiences and narratives.

In general: if we’re comparing a system which has an update loop (parser IF) and a system with a spine (standard choice-based authoring), I think what I’m finding is that it’s far easier to call out to an update loop from the story spine than it is to create a story spine from inside an update loop where the passing of time can only ever be inferred.

Context-Free Actions

In fact, I’d argue there’s only one area that parser games hold high over choice-based structures, and that’s “context-free actions”: actions which are always available, but have little impact on the game-state; such as examining, checking your inventory, or moving around the map. They’re not totally context-free, of course, but in a choice-based game, it’s hard to insert them into the right point in the flow because they can be executed at more or less any moment, and indeed, might need to be.

These verbs open the scope of parser games a little – they let the player break out of the forward flow of the game to gather information from around the world, and across their possessions and what they can see. I think it’s here that the “freedom” of the parser game really lies – not in the commands at all, but in the breadth of objects that can be passively examined at any time.

Still, though; having the main game feed fill up with examinations of items – and often repeated examinations – does seem a little less than perfect. Solutions to that have been tried with multiple windows, showing maps and inventory screens – but these somehow never quite gel, and I suspect it’s because suddenly listing out these options in parallel with the main game starts to make the experience  feel overwhelming. (Something the parser does well is to provide a large possibility space that looks like a small one. In fact, I’d argue the parser does a better job of seeming constrained than it does of feeling open..!)

Leaning on the Interface

So for our games, we’ve cheated. We’ve created an interface layer on top of the game. We have a visual map, because having something to look at helps, and so the player can understand they are moving around. We’ve created inventory screens, and placed Examine buttons on those screens, as well as adding Examine choices into the normal flow at places where it made sense. It’s the multiple window solution – but we’ve made them stack in a rather attractive way, and I think we got away with it.

The resulting balance is, I think, quite effective: and as we set about constructing Sorcery! 3, we’re finding that starting to play out. The new game is being built with a framework of locations, objects and map connections; these fire off calls to update-loop-style routines which do turn-by-turn work, before calling set-piece-like sequences of choice-based flow that carry the meat of each scene. At the end of the scene, we pass flow back to the map layer. The result is a choice-based game which allows free exploration of an environment, object-based puzzles, but which on meeting a character can drop instantly into dialogue-based conversation without a change in interface or tone.

Testing will, no doubt, be a nightmare, just as for a parser game.

And a voice in the back of my head is nagging me to try porting Make It Good. I think it could be done. I fear it would be better.

Categories: Uncategorized | Permalink.