Flags and states in open-world gamebooks

I think it was Mark Smith and Jamie Thomson who first started using keywords in gamebooks. Prior to that, a gamebook might say something like, "If you met the old man in the almshouse and he gave you a piece of stained glass, turn to X." 

You can see the problem. What if I don't remember if I met the old man or not? That's especially likely if I've played through the adventure several times and can't remember whether I met him on this run-through or a previous one.

The other advantage of keywords is that they don't give the game away. The keyword for getting the stained glass fragment wouldn't be GLASS, for example, or even VITREOUS but something unrelated to the story event -- OBLIQUITY, for example. That way, if you come across the keyword without having triggered the event that would give it to you, you have no idea what effect it would have. That's particularly important in open world gamebooks like Vulcanverse and Fabled Lands, though there are cases where it's fine to know why an event is triggered -- getting arrested if you're a wanted fugitive, for example, or being granted an audience with the king because you're the court champion -- and in those cases we typically use a title like Godslayer or Saviour of Iskandria.

Keywords can serve one of two functions. The first is to record if an event has happened. For example, has the player ever met Baroness Ravayne? Once they have, that can't be undone. So in design terms that's a flag. The other use of keywords is to track a state that can change. An example of that would be whether they are an ally or enemy of Baroness Ravayne. Prior to meeting her, neither can apply. But once they are able to enter those states, there could be ways to flip them; you might become the Baroness's enemy, then redeem yourself and become her ally, then do something to make yourself an enemy again.

How many keywords do we need for this kind of set-up? I'll give you an example from The Pillars of the Sky, the fourth book in the Vulcanverse series. We've actually discussed this before. If you want to familiarize yourself with the scenario, here's a short demo version. The gist of it is that the player comes across a valley in perpetual darkness and finds a switch that lets them turn the sun on and off. (Here in London in icy January I could do with something like that.)

I used two keywords. Quell identifies whether the player has found the switch. So that's the first kind of keyword mentioned above, a logic flag. Once you've found the switch, you can't unfind it. The other keyword, Quire, records if the sun is currently on. If you go back to the switch and flip it to the off position, you lose the keyword Quire. Anytime you're in the valley, if you have Quire then the sun is shining, and if you don't it's pitch dark. So Quire records a state.

Typically you want to limit the number of keywords used in a book, as the reader is going to have to check through a list every time a keyword is called. In a multi-book series it helps a bit if the designer uses different letters of the alphabet for each book, as we did in Fabled Lands and Vulcanverse, but it's still preferable not to have too many. Initially I tried to economize in The Pillars of the Sky by only using Quire for the valley with the artificial sun. That meant there was no difference between the sun being off because the player hadn't found the switch and the sun being off because they had found the switch and left it in its original position. Later on I discovered that there were circumstances where it mattered whether the player had found the switch, so I had to bring in Quell too.

A slightly more streamlined (if less aesthetic) solution would have been to have Quire-ON and Quire-OFF as keywords, using ON and OFF to designate substates. Then I wouldn't have needed Quell as I'd be able to infer the state by asking, "Do you have a Quire-* keyword?" -- or maybe, more elegantly, "Do you have any form of Quire keyword?" I wouldn't do that in code as it's cleaner to differentiate the flag (has the switch been found?) from the state (is the switch up or down)? In fact, if the code isn't visible to the player, in an app version for example, I'd have both Quell and Quire-ON/OFF. As you will appreciate, technically I don't need the ON/OFF substates in that case because all conditions can be derived from simple combinations of Quell and Quire:

• Quell && Quire = The player has switched the sun on
• Quell && !Quire = The player has switched the sun off
• !Quell = The player hasn't found the switch

So the only reason for having the Quire substates is the belt-and-braces principle that when debugging it helps to have everything spelled out. Trust me on this -- currently I'm coding all the Vulcanverse books as a web app and O! the bugs!

If you try playing the demo, here's a moment from Workshop of the Gods that gives a hint of how that sunless valley came about:

Actions and consequences in an open world

When I mentioned on social media that Vulcanverse would be the first open-world gamebook series to be finished, somebody rightly pointed out that "finished" is a moot term when we're talking about open-world adventures. Fabled Lands, for example, is famously incomplete -- but all that actually means is that you can only explore about two-thirds of the areas shown on the map. If and when we ever type "The End" on Fabled Lands book 12, that wouldn't constitute an ending in the way a linear story ends. You can go round and round forever. That's what open worlds are all about.

Vulcanverse is different. Superficially it is like Fabled Lands, a sandbox for adventuring in, but that's deceptive. It's actually more like an open-world CRPG where you can take up quests in any order, but they feed into a central story thread that will lead you to a grand finale. Minor quests allow you to qualify for major quests, and some of those have payoffs that change the landscape of the game (literally) or win you allies who may rally to your side at the showdown with the Big Bad.

The last half of Workshop of the Gods (around 880 sections out of 1667 in total) is devoted to that endgame track, and once you complete it the game is over. You can bide your time entering the endgame, gathering everything and everyone you think you'll need, but once you're on it the structure is pretty linear. It's like a traditional gamebook from that point, sacrificing complete freedom of choice in favour of a dramatic conclusion.

I got to wondering how many quests are up for grabs in the whole five books. One clue might be in the codewords that we use to keep track of earlier decisions. For instance, if you begin your adventures in Book Five you start with the codeword Reverie. That remembers that you have a home and family in the city, and that you are familiar with the main landmarks. Titles such as Amazonian Queen or Tricked by a Water Nymph serve a similar function, the main difference being that you can see what the title records whereas the function of a codeword is usually not obvious immediately.

There are about two hundred codewords and seventy-odd titles across the five Vulcanverse books. As a quick yardstick, that might suggest around 250 quests (given that you might pick up more than one codeword on the bigger quests) but actually it's the tip of the iceberg. We only use codewords and titles when a player choice can have consequences anywhere in the Vulcanverse. All sorts of people you meet will react differently if you're the Amazonian Queen, for example.

But there are plenty of quests that don't have global repercussions, so to avoid having to check codeword lists too often we use a non-global logic filter: the tickbox. A tickbox is located "in the code". At the point that you arrive at a location, say, a tickbox could record whether this is your first visit (in which case you get the longer description) or a follow-up. Multiple codewords can be used to trigger different events each time you visit the location, as in the case of the tengu king's court in FL Book Six:

With a little extra tweaking, a tickbox can serve to filter a quest that is not yet complete, or that has just been completed, or that you completed a while ago. Here's an instance of that from Vulcanverse Book Four:

In this case, section 912 gives you the set-up conditions before the quest is dealt with and asks if you have what's needed to fulfil it. Usually you'll go away and come back later with what you need, though you might be lucky enough to have it already -- an item, a codeword, a companion, etc. If and when you do, 912 steers you to a section (or a whole subquest loop consisting of many sections) that if successful routes you back to 408 with the instruction to tick the box. At that point, you'll then go to section 1043 and be told the outcome and what reward you get. If you return to the Atlas tree later on, you'll see that the box is already ticked and so you'll go to section 1007, which tells you the new status quo that applies since you resolved the quest.

There are a lot more localized quests than globally significant ones, just like in a CRPG, so at a rough guess that means the whole Vulcanverse series comprises about six or seven hundred distinct quests. Some just earn you an item or a stat boost. Others unlock bigger quests. Each of the first four books features three major quests called labours, and when you've completed all twelve of those it unlocks the possibility to jump into the endgame in Book Five whenever you're ready.

I haven't seen a breakdown of the quest structure for something like The Witcher or Baldur's Gate, but I'm curious to know how the scope of those games measures up beside Vulcanverse. If you know the numbers, share them in the comments. And if you have a loved or loathed gamebook design feature -- maybe you can't stand writing in books, or you don't like logic gates -- let us know about that too.

Online Adventure Sheets

Tickbox and codeword spreadsheet for all 5 Vulcanverse books

Buy the Vulcanverse series on Amazon