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:
