For the sake of demonstration, let us construct a hypothetical game.
(Don’t worry, in this case, “hypothetical” means it won’t be a whole thing, and by “us” I mean me. You don’t have to lift a finger.)
This game contains, among many other components, the following snippet of rulestext:
“When you activate an Action, suffer its Consequences.”
This tells us a few things about the game right from the get-go. We know at least two defined components of the game: Actions and Consequences. We also know that each Action has Consequences specific to it, that Actions are activated on some occasion of the play, that Actions are enacted by individual players and their corresponding Consequences applied to them, etcetera. The game has denoted two important concepts to us, and in so doing also given us more insight into their interconnection, and existence within the broader context of the game. (Which we still know nothing about beyond this one line.)
Now consider a second game – similar in structure and goal, sharing much of the same DNA as the first, but still distinct in its specifics. This second game contains, instead, this snippet:
“When you Activate an Action, Suffer its Consequences.”
This tells us more than the prior one did, alongside everything it did. We have two new keywords, words designated as Important, to work with – Activate and Suffer. And precisely because they’re designated as such, we can’t just fold them into the presumed operations of the previous keywords. They mean something now. Can you Suffer other things, in other contexts? Can you Activate things that are not Actions? Or, perhaps, is Activating an Action a more specific thing than we might consider as “using” it – perhaps a given Action will Activate itself three times over the course of its resolution, prompting three instances of Suffering said Consequences. Or perhaps there are multiple ways to “use” an Action, of which Activating is only one – you could Gamble it, or Belay it, or Activate it, and only the last prompts you to Suffer the Consequences – ooh, but maybe Gambling it prompts you to Inflict its Consequences, a wholly different operation using that same Consequence field, and-!
Well, that’s enough of that for the moment. The point isn’t to actually build these out into games, as potentially compelling as some of those thoughts may be. Instead, it’s the simple note that, marking out words as keywords gives people insight on how the game works when they read it. Whenever you designate a given word as Important, in whatever format you use – it doesn’t even have to be capitalization, it could be italics, bold, or however else you want to make the word pop out – that tells the reader that it means something, and as they navigate the rest of the game they should keep an eye out for what it does mean, and what it can tell them about the rest of the game. And then, when they get to the point of sitting down and playing, they’re all primed and ready for exactly what Activating an Action means, and what they should worry about when they do it!
Of course, the fact of the matter is this is a question of presentation. “When you activate an action, suffer its consequences” is just as feasible a line for either game, and could mean everything the given lines meant, and it could also just as easily read “When you apply Operation X to Type A, apply Operation Y to Type B” and, on a mechanical level, mean the same thing. But I think you can already see the problem in both approaches. The former is, while fine, less indicative at a glance. Is suffer an important keyword, like it was before? Is action, even? We can guess, and are more likely to get it right the more we know about the game, but think about how much we got, both of explicit knowledge and of potential implications, from out prior examples. As first impressions go, it’s much easier if you get told which words are directly meaningful and which ones aren’t. And as for the Operation X approach, well, that’s all well and good if you’re plugging it into a computer, but the players will have to read that, sigh, flip to the glossary to figure out what Operation X does, flip back, then do the same three more times to identify the types of items you’re calling for and what you’re doing with them. A player can read “Suffer” and get the gist of what is supposed to happen even if they don’t know what it means in mechanical terms – and that’s going to help things run much smoother even once they reach the point where they do know that much.
That’s not to knock the Operation X approach entirely, of course. It’s certainly not presentable, and a headache to navigate, but as a design step, it’s honestly quite useful to sit down and write out all the processes you have for the game, and what, in mechanical terms, they do. That way you can see what components have the most hooks into them, which are relatively extraneous and could be integrated further (or removed altogether!), and the general flow of operations as you go through the game. Initiate Fight to Activate Action to Suffer Consequences.
That model of operation-flow, and what parts of the game are called upon by each step, is gonna end up looking like a weird engine diagram, and that’s precisely what it is. A game is an “engine of meaning” – a device that flows between concepts by using operations that are themselves also concepts, with tokens and progress marks and dice rolls and hit points exchanged to determine specifics of how it flows when. What you’re staring at, that diagram you’ve made, is a map of the engine you’re building, and what parts you gave for it. And you can see better that way if a certain part is top-heavy, or overstressed due to high traffic, or what have you.
The discussion of keywords is a question of how you translate that to language.
Most players, if you give them a flowchart of processes, are gonna find it rather obtuse. The more complex it is, the more useful it might be to see it presented in that way, but, readers like words. They want to be able to flip through the book and see, written out, what you should do when. And that’s why you get lines like “When you Activate an Action, Suffer the Consequences.” The flowchart is for your benefit first and foremost – it’s important for players to understand the shape of the game they’re playing and how it flows together, of course, but ideally in broad strokes. You can tell them that sometimes the game transitions to combat, and combat is a sequence of Actions and the effects of them, ramping up to a big Finale that ends the fight, and then it swaps over to the politics in the commentator’s booth mode of play, and really, that’s enough. The specific, moment-to-moment operations get to go in their own section of how you resolve Activating an Action, how you resolve Suffering, etcetera. By breaking down the concepts into small chunks that the players can get used to on an instinctual level, they can read a sequence of words that’s actually describing a whole chunk of the flowchart, and still get it.
There is, in some game design spaces, a sentiment I often encounter that this kind of thing is to be avoided at all costs. That it takes the reader out of the experience to read a suddenly capitalized word, to be told by the game that it is Important, that when it says “make an Attack” that means something mechanically specific. I understand this impulse! For people far less used to building mechanical things as their primary perspective on creation, it is jarring to see that. And writing things out in natural language that makes for easier-seeming prose can feel like the sensible course of action. But, the flowchart of play is going to be a truth either way, and writing it in unclear terms will make that harder for the readers to understand. If some uses of the word “attack” are not an Attack, and some Attacks never use the word attack, the player will struggle to have a concrete “here is the process of Attacking and I know when I should do that” in their head. And even when they do get that, the edge cases will make the worst effects of that fraying shine, and you do not want that.
The fact of the matter is, on an initial readthrough, a player will encounter “make an Attack” and will, inwardly, think “oh right, this is a game”. But the second time they read that, they won’t think that, they’ll think “oh, I know what to do when I Attack”, because of the clarity that a keyword brings. They can construct, in their own head, using their own mental infrastructure, their own flowchart, their own sense of the shape of the game and what each cog and bellow does when they call upon it. And once they’re clued into that, you can write things like “Resolve: Activate, Attack, Activate; Consequences: 1 Harm”! Seems like a string of gobbledygook, but to the player who’s already read that far, they can easily parse that that’s an action that makes an Attack and causes them to Suffer 2 Harm – 1 before the Attack, and 1 after. And then, when they’re down to 2 Harm left to take, and there’s an enemy that will go down to one Attack, they know they can use that power to win, and their thoughts are flowing precisely through how that flowchart wants them to.
It’s a handy feature of games that the substance that composes them, meaning, is so easily communicable. Each player can have their own copy of the device they’re toying with inside their head, and unlike with examining blueprints of a car or the code of a program that insists on crashing on launch, the engine can literally be inside of their head. For most players, showing the blueprint of the game and the flowchart of play won’t do that, but being clear about the components, the processes, and how things are expected to run, that can translate it much more effectively than it might seem.
That’s the power of keywords.
Ru's Roleplay Rants 