Tabletop Game Grammar
This was a talk given at the inaugural Tabletop Network conference, held in Snowbird, Utah, in June of 2018. This was the first time I had spoken at a boardgame design conference — and indeed, boardgame design conferences are a bit unusual, apparently.
The layout of the slides is a bit weird because the conference used a picture-in-picture video streaming setup, so the bottom right of the slides was intended to be occupied by video of the speaker.
Slides
Most of the slides have captions; hover over the slide to read them.
- I’m going to talk about game grammar, which is a thing I’ve been working on since sometime in 2003-2004, as an outgrowth of a book I wrote. What this is about, connects to James Ernest’s talk and to Mike Sellers’ talk Cognition, endorphins, etc
- It started out as a videogame centric thing, driven by the fact that on big teams we would have huge problems describing game systems to programmers, and then hoping we’d have the fun pop out the other side of implementation. Rapid iteration cycles mostly weren’t a thing, we hadn’t figured out how to do it with big teams back then.
- My own background is in the biggest of big projects, for the day. Massively multiplayer games like UO and SWG… hence the need. I used to say that making a game off the design document was like filming a movie based on the director’s commentary. If I slip and say “mechanic” instead of “mechanism” that’s why…
- So grammar started as a quest for a notation system, but to do notation we needed principles, and that turned into a decade and a half research project.
- There’s actually way too much to fit into any single talk, at this point – I have several fellow travelers who have added to the overall body of work
- And I myself have done quite a lot of talks touching on only single aspects of it
- Some of the core premises are the basic interaction loop, which is basically out of human computer interaction theory A lot of this is stuff that we do instinctively, the goal is to do it consciously
- The idea that there’s a mental model that players are updating as they acquire information… Even in perfect information games, there are dynamics that surface readings don’t provide, of course
- There’s the idea that games are not their representation – hence we can play chess in our heads and still call it chess
- That games can be defined via an understanding of their topologies
- Their internal economies
- And their decision web, which is effectively a form of machine
- Most importantly, that games are fractal; they are self-similar down to the level of trivial problems. Easy to see here. But it also keeps going, next step is the controls, the nested game of controls is at the heart of billards, marbles, Klask, lots more.
- And this carries through all forms of games, be they tabletop, digital, or physical sports. IN fact, sometimes that changes within one game – like, most games have physical mechanics on the leaves of the verb tree
- There’s a lot of nuance to some of these arguments and principles. For example, it’s illuminating of the question of game families and genres. (rose example) Consider poker, where variants have enormous rule isomorphism, but the addition or deletion of a scalar can lead to massively different dynamics. we can even look at many of these rule changes as actually being statistical variations. For example, there is a difference in perspective that comes from saying that the number of publicly shared cards in vanilla 5 card poker is a scalar variable that happens to be set to zero. To a player who only knows vanilla poker, the addition of face up cards seems like a new rule, when in fact it’s just like showing that sometimes monsters can group in an RPG, or that gravity can change, when you have thought that in practice gravity was inalterable, or grouping did not exist. That isn’t really an honest way of looking at it – when a Texas Hold ‘Em is developed, it’s likely that no one approached it as “let’s increment this zeroed out variable to a positive number.” But in analytical retrospect, the addition of a new statistical field could almost be thought of as retroactive to all earlier versions of Poker. And thus poker’s base definition grows to encompass “a game where there might be publicly shared cards.”
- Poker, for example, probably derives from primero, which we think had five possible hands to claim points (modern ones that were included, we think, are flushes and four of a kind. Then they had some inversions that we don’t use anymore, like four cards of different suits.) Rounds where you can bet and bluff were already present. Hands are size four.
- Three card brag reduces the size of a hand to three, might allow multiple hands (there’s variants with up to fifteen) and introduces more kinds of hands: straights, straight flushes, high cards, and pairs.
- Early poker was straight: no wilds, stud cards, community or flop cards, or additional draws, but most of the earlier hands, and all the betting stuff.
- Then we can add stuff like wilds.
- Stud cards
- Draws
- And community cards, and at this point we’re getting close to Texas Hold’em.
- Most of what has been added, if you abstract all this away, are resource types, and sets to match.
- This is, of course, an example of a specific kind of math problem. In fact, of several. People usually think of poker as a probability problem, and it’s true that at one level of analysis, it is.
- You could also argue that building any given hand is an example of an exact cover problem, which is a math problem that falls into the NP-Hard range of computational complexity, generically, though poker’s solution space is small enough that it isn’t up there in the specific sense.
- This means that the “find a hand that is possible given the resources I have” nests within the larger problem of “what cards remain and what are the odds of completion for any of the hands I could possibly make”. This is the fractal quality of game grammar manifesting
- Just like that old Frogger example. The “find hands that are possible” ends up being a design pattern we use. Design patterns are basically atom aggregations that we have decided to label.
- Board game designers are pretty familiar with what I might call design patterns, as evidenced by the mechanisms list at BGG, But many of the BGG mechanics are basically composites of these smaller, more atomic problems. They also aren’t all the same level of granularity. Like, grid movement versus hex… those are topology differences, not mechanisms. Press your luck is a dynamic – a possibility space for player behavior not a mechanism, but set collection is a pattern.
- Game grammar decomposes these into a few broad classifications of types of mechanisms. You might note that these map onto the various biological signals that Mike Sellers mentioned earlier. Dopamine is leveraged by the brain bug, social is rewarded via serotonin, endorphins help out on the physical reactions, and so on.
- Math problems are particularly rich, with most tabletop work fitting in here
- Most sports focus on a variety of physical challenges – most of which we can ALSO describe mathematically, interestingly, as see they share a lot with the math problems
- Social problems are a whole other kettle of fish – bluffing in poker would fall into this range, as it involves building mental models of other humans. So does playing charades or Werewolf.
- There’s a degenerate math case, which is the fact that humans are really bad at probability distributions outside of really bounded cases.
- So, this is all really theoretical, but I want to bring it back to concrete utility. I’ve found this hugely useful for a few critical tools for me: identifying bad game systems, adding fun to systems that weren’t there, and analyzing the learning loop for players.
- Diagramming games in the form of verbs and the choice trees players can engage in – which, it’s important to note, web, rather than simply unroll. This helps us spot bad spots where players engage in multiple loops without skill. Stuff like interfaces to the game that require simple combines – in tabletop this manifests as “fiddliness” a l;ot of the game, and in videogames it often manifests as “grind.” This here is a little napkin language I like to use, which uses currencies, verbs, and objects. There are a lot of choices for things you can use instead, and they’ll tilt your analysis towards game economy vs topology etc
- Use for competitive analysis, for identifying design flaws – like in Frontierville, you can see where the clean fsrming game added exploration, which was fine, then got caught up in a powerful but separate narrative system around family, and kind of lost its way over time and in fact, a few months after this graph additional features ended up spiraling the game out as it lost its center.
- Using the lens of typical problems to build mechanics out of is hugely helpful. I’ve consciously engaged in the practice now of going straight to atoms or topology to leverage them as fun core mechanics. For example, I was playing with the notion of a Hex Blokus,
- a vertex cover problem.
- I didn’t like a prior try in this design space, and I realized that the reason was that it remained a 2d Euclidean plane problem.
- So I shifted the topology to not use a strict 2d coordinate space for the vertices, which changed quite a lot about the dynamic. We play it in 2d, but it moves vertices to be a consumed resource per node; you could think of it as existing in two coordinate systems at once, if you like. The result is that the player has to think in two conflicting complex spaces at the same time. I then layered goals on top to force movement between these two differing frames of reference.
- Here’s a card game I brought with me, we can play it one of these evenings maybe. It’s a set building game that was consciously constructed out of Karp’s 21 NP hard problems, specifically a set matching satisfiability problem. But it also has interesting probability distribution characteristics when you include the game economy as a question.
- Originally, the exact same game was presented in a radically different way. This broke the player’s learning loop; the feedback system to the player wasn’t very legible. We might say that this was a UX fail, or a graphic design fail, but it’s illustrative of a more fundamental principle, that grammar is about moving players up the learning – scaffolding them, in educational theory terms.
- Shifting the game to cards made a massive difference.
- I’ve only scratched the surface of game grammar here – for example, the way in which a defining characteristic of many Euro games is their emphasis on parallel play, like players in lanes on a race track, rather than symmetrical orthogame structure where they compete over a pool of victory point resources
- Or the way in which this gives a really useful and strong lens on co-op design, via something called the trust spectrum (see Google article)
- The way in which grammar gives us a new lens of defining depth – consider these three unrollings of a hypothetical decision tree through iterated ternary indeterminacy . And indeed, the idea of “solving” games via full searches of the entire possibility tree works this way. You can “unroll” all the choices that are made, by atomizing the game, and see each decision made as a step along a branching tree. With some foreknowledge of the tree, a player (human or artificial) can make choices that are steps on the path towards a particular outcome, and can prune whole large swaths of the tree. A given binary choice has implications not just in the current choice, but in affecting the odds of a given outcome later on.
- Indeterminacy is so important that we even have names for particular flavors of it within the tree, sort of a historical record of the graph of VP movement over time.
- If you count the number of indeterminate nodes you can see that comebacks and hard fought matches, which are both more fun and better to spectate, both have more indeterminate nodes than a blowout does
- In fact we monte carlo model competitive games to look at exactly this data to tune for fun
- Or the fact that we might even be at the point where we can create a “game design processor” akin to a word processor, with grammar checking to look for issues in your game. Partial solutions to this already exist.
- But we’re just about out of time, and I am happy to talk about it more. Particularly eager to find more ways in which existing game design theory in tabletop meshes with this approach, which I believe it does.
Share this post:
- Click to share on Facebook (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on Tumblr (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to share on LinkedIn (Opens in new window)
- Click to share on WhatsApp (Opens in new window)
- Click to share on Pocket (Opens in new window)
- Click to email a link to a friend (Opens in new window)
- More