When Dave Morris and Jamie Thomson invented the Fabled Lands codeword system, they created something that massively increased the interactivity of gamebook adventures. Until then, gamebooks tracked a player’s activity through a combination of several techniques: simple branching, unique possessions and player memory. Simple branching is straightforward: if the player was reading a passage that was only reachable after a choice, then the text could ‘know’ that this choice had been taken and could describe what had happened as a result. However, this is a one-time and one-directional choice: no reader can go back and ‘undo’ their choice in the same read-through, and other branches of the narrative are closed to them until they die and restart.
Unique possessions, usually noted in an adventure sheet, can also identify whether a player has made certain previous choices. If a particular horned helmet is only available within the loot of a dragon, then by asking the reader whether they possess it, the book is also practically tracking whether the reader defeated or avoided the dragon earlier in the story. However, this can be complicated if a reader has to manage a limited inventory and decides to jettison an item that seems, at the time, unimportant.
Player memory was the least sophisticated and least reliable of these methods. It was used when a passage simply asked the reader something like ‘Have you visited this place before?’ Problems here are the ease of cheating and the need to ask this question quite soon after the original event, meaning a short consequence delay, because readers can genuinely be quite forgetful.
Whereas codewords are something else. An alphabetical list of neutral, arbitrary(ish) words that can be ticked – and unticked – are unlose-able, repeatable and undoable trackers that can be used by the writer of a gamebook to note any variable they choose. Your reader defeats the dragon? Get them to tick the codeword Basket. Your reader returns to the dragon’s cave. If they possess Basket, all they will find is an empty cave and a faint smell of sulphur… but if they don’t possess it, turn to passage 701 where the dragon is alive and well. Until the reader visits these passages, the appearance of the word Basket in a list in the back of the book doesn’t even hint at the mortality of a dragon. What do these all do, we wonder. If Basket tags a dead dragon, could Burnish imply that the protagonist is pursued by a vengeful ghost? (That one is very Dave Morris).
In short, codewords allowed Morris and Thomson to invent the open-world, responsive gamebook. It’s an elegant and a powerful system, and one which Fabled Lands doesn’t abuse by leaning on too heavily. Unlike what I think I’ve done in Steam Highwayman III: The Reeking Metropolis.
In the current draft, SH3 has 98 codewords… Some of those track choices in other books and offer you the consequences of actions you took in other books – or that you will only be able to take when I write future books. Some track non-player-character’s attitudes or destinies, locations, others track quest solutions, faction loyalties, the profitability of certain businesses and a whole lot of other stuff. In fact, one of the powerful results of this system is the ability to cause side-effects: the reader kills a soldier and gains a certain codeword, meaning that when they return to that location, the soldier will be dead. But what about when the player visits a nearby terrace and, possessing the same codeword, is directed to a cottage where a wife weeps over her lost husband and cries, knowing that she and her hungry children will soon be evicted for unpaid rent? Now that’s interactivity.
But 98 is a few too many, so I’ll be trimming the fat in the next few weeks. But until then, peer at a blurry section of the entire list and enjoy your own puzzle: what do these arbitrary words actually track? What is possible in The Reeking Metropolis?
I made a deliberate decision to not include codewords in my gamebook – I then decided that doing so was a mistake when writing the 2nd book, as I really would’ve benefitted from using such a simple mechanic to remember past events. My original thinking was that I didn’t want the ‘game’ aspect to overwhelm the adventure, but I now wish it was much easier for me to track a player’s earlier decisions. Live and learn!
Special items and checkboxes and codewords are Boolean variables: only tracking a yes/nor or true/false state. The next level of complexity (which would also add much more functionality) would be variables that track an integer value, with all codewords starting play with a value of zero. Note that any arithmetic that has to be performed by the player must be simple (basic addition and subtraction only) so as not to break the flow of play.
Example 1 (one codeword replaces multiple checkboxes): “When you reach this section, if the codeword Battlement has a value of 5 then turn immediately to 378. Otherwise add 1 to codeword Battlement and read on.” A simple timer mechanism that removes the need for multiple checkboxes.
Example 2 (one codeword replaces multiple codewords): In a multi-state quest, you can use a single keyword for the entire quest, using its value to track the status. 0 = quest not started. 1 = quest just started. 2 = section 1 failed. 3 = section 1 successful. Add 2 if section 2 is failed; add 4 if section 2 is successful. You’ve then got one value encapsulating four possible end states (4,5,6,7) which you can condition on easily. If you don’t need to track individual success and failure, you can use the keyword value as a counter to track the progress through each stage of the quest.
Example 3 (codeword tracks an amount of money): While acting as a waiter in a restaurant… “The man wears a black yak-hide jerkin and has coloured beads in his braided hair. He says, ‘I’ll take your recommendation for food and drink, but no dairy please: it gives me a dodgy tummy.'” If the player has visited the right places, they will recognise the clothing as being Pebustani, a culture that highly values meat. The hairstyle marks this man as a priest of Jochim, and will therefore shun “grape and grain”. The player then must choose what to serve him for each course, and the codeword value represents the tip they get at the end. So negative modifiers for wine or beer, but positive for mead. Negative for anything containing dairy (requires some culinary knowledge), positive for a meat-based course, and so on. If the final keyword value is negative, he raises a complaint and you get fired. If the value is under 50, you get that amount as a tip. If it is 50+ you get 50 plus some extra information that may prove useful later on.
Example 4 (codeword holds a section number): On path A, add 100 to codeword Juniper; on path B, add 200 to codeword Juniper; on path C, add 300 to codeword Juniper. After any further adjustments to the codeword, you are instructed to turn to the section with the same number as the value of codeword Juniper. This is similar to example 2, but with direct equating of codeword value to section number without translation. This would work best with up to three stages (units, tens, hundreds) to avoid any arithmetic mistakes. 0 + 8 + 20 + 300 is an easy sum. Sections then need to exist for each possible combination.
Thanks Stelio – some great contributions to the discussion.