12 Tenets of Board Game Design

As many aspiring game designers likely do I have been trolling numerous game companies online. With so many possible directions to go in game design it is really easy to design a bad game. When I stumbled upon Stonemaier Games list of design tenets I was really challenged in my thinking. I am sure other companies have similar principles, even if they aren’t in writing. But to so visibly see the exact guidelines they use to assess games and select them for production was insightful. And although these might not be exactly the rules I want to live by, they are really great list for consideration. In fact they are so solid in my opinion that at this moment I don’t see anything I would change. For now, this will be my go-to checklist.

And here they are, 12 tenets of board game design at Stonemaier Games (source link):

  1. Quick beginning and organic end: Streamlined setup with (at most) minimal pre-game choices, and an organic end-game trigger (we’re generally not drawn to games with a set number of rounds).
  2. Ability to plan ahead before taking your turn (you shouldn’t have to wait for the previous player to complete their turn to be able to decide what you’re doing on your turn).
  3. Limited analysis paralysis with choices displayed on player mats, game board, etc. This also manifests in a reasonable amount of information on display, not dozens of cards and tiles with detailed text that players need to read from across the table.
  4. Tension, not hostility. We like to limit the potential for spite while still encouraging various forms of interaction.
  5. Interesting choices are better than luck. If there are elements of randomness, players should be able to make decisions based on random input (instead of, say, rolling dice to determine the outcome). Agency is very important; it means that players have control over their fate.
  6. Rewards and forward momentum, not punishment and backwards movement. Players should feel like they’ve progressed during the game to a superior position than at the beginning, and the mechanisms should support this (i.e., engine building).
  7. Very, very few rules exceptions.
  8. Strong connection between theme and mechanisms. Mechanisms should be designed to keep players immersed in the game instead of reminding them they’re playing a game. Two key examples of mechanisms that don’t do this are phases and action checklists. There are much better, thematic ways of showing players what they can do on their turn.
  9. The potential for dramatic, memorable moments in a game is difficult to achieve, but it’s a huge plus when the game allows and encourages them to happen.
  10. Board games are tactile experiences. We love games with some type of appealing, exciting component. It can be as simply as the cardboard Tetris-style pieces in Patchwork or as complex (yet important) wheels in Tzolk’in.
  11. Variable factors to create replayability–you can’t play the same exact game twice, even if you try.
  12. Multiple paths to victory. Various game subsystems should be equal in their ability to reach the winning criteria.

 

Concept Models and Game Design

Concept models are a tool used to understand how the elements within a topic relate to each other. They are often used by designers to understand how the many parts of a system relate to each other.

The creator places all of the nouns in circles. The nouns are all the “things” related to the topic. Then connect the nouns with arrows pointing in one direction. Put a verb (or a few words) on the arrow such that when you read aloud the noun + verb + noun you get a sentence that makes sense. Not only does it make sense, but it explains some relationship between elements. Repeat this until you have exhausted the topic. Finally, make an attempt to organize the circles and arrows so that the chart is easier to read.

Imagine a diagram intended to break down the components in a deck of cards. It could start like this:

deck-1.jpg

Read this as “Deck contains cards”. It is this type of relationship we seek to chart out. And the more elements a game or topic contains the more relationships there are to explore and consider.

Then, we can expand on this and add more elements, building out the chart. Here is a chart with a few more nouns:

deck-2.jpg

Note that I have intentionally connected elements in different ways to show how you can read things in many ways.

Additional layers can be added if it is useful. For example you could add color to the circles in order to show how similar elements relate to each other and form groupings. You can also put containers around related elements. This isn’t a rigid method, add whatever helps you make sense of the topic.

This works perfectly for mapping out the elements of a board game and visually seeing how all the parts interrelate to each other. This can help the game designer in many ways:

  • Discovering connections you hadn’t anticipated
  • Identify little used parts that can be eliminated
  • Assess the overall complexity of the game (more parts = more complex)
  • Visualize the openness of the game – or the amount of flexibility players will have with the parts
  • Discover new ways to integrate parts and create multiple paths through the game

Here is an example of concept model I created to understand the parts of Settlers of Catan.

Settlers of Catan - Diagram.jpg

It is worth noteing that this diagram does not contain every single possible relationship. There are times where you leave some out because it just clutters things up. This is risky though. For example, in this chart I have failed to detail all of the possible relationships that development cards might have. They can also allow you to do things like collect resources, build roads or move the robber. To flush these types of details out it might make sense to create noun objects for each type of card. Then these could be connected to all the elements they relate to. In this case it might make sense to make a separate chart just showing what the deck of development cards can do.

The reason I started using this method was to better understand the parts of games and how they relate to each other. As it turns out, doing this really really helps you see how game parts are used. Having done many of these I will be posting and sharing those here on this site. In fact, my vision is to essentially use this method on any game I play, design or generally need to assess. I highly recommend you not only look through the ones I have made but to make your own. Though others might learn from these diagrams, it is the creator that learns the most. As such I challenge you to take up this challenge and begin by charting the games you love most; it is easiest to model games we know well.

Simplified Concept Model

The next step I put these concept models through is not something I do in the UX world, but for games I have found it to be a very useful approach. With a complete chart that plots out every element of the game I work to make a second version. In this second version I simplify and condense elements. I also remove extraneous elements that are less important. The goal here is to make a more simplified chart that portrays the general flow of the game.

Here is the simplified version of the Settlers of Catan chart shown above.

Settlers of Catan - Diagram 2.jpg

The purpose of this is to seek to understand the core flows of the game. Some parts of the game (like a pawn or dice) aren’t really key to understanding how the game flows. Both layers of detail are helpful depending on what you goal is.

Decision Tree

Building a concept model leads to another interesting artifact. Once you see all the parts of the system and consider how they relate to each other you can easily assess and plot out all the decisions the player is able to make. Making a decision tree is fairly easy and really depends on the specifics of the game. In general it plots out all the choices a player is able to make. The quantity of decisions directly relates to the amount of control the player can inject into the game. If the players have too few choices the game can become predictable or perhaps just boring. In small, faster games, a limited decision tree is ok. But in larger and longer games one expects to be able to make more choices and through them have a greater influence on the game. The whole world of decisions is a topic I would like to explore in much greater detail. This interesting article on Objective Driven Gameplay shows how much thought and insight can be gained from this line of thinking.

Settlers of Catan - Diagram 3.jpg

Just to clarify, these are not long term choices the player gets to make (such as an overall strategy). Rather these are just the immediate choices a player gets to make on their turn.

While not directly related to the topics presented here, this article on the Anatomy of Carcassonne shows how the parts of a game can be modeled in yet another way. There is no “right” way to do this, so use which ever method or methods work best for you.

Game Design vs UX Design

I am keenly interested in migrating my skills in the world of UX Design to that of game design (physical board game design in particular). I recently discovered Raph Koster’s article titled Game Design vs UX Design and it obviously rung a bell for me.

As a UX Designer it is indeed my goal and job to remove obstacles from users path to success with software. Raph hits the nail on the head in his description of what a UX Designer does. I know he is specifically talking about video game design in this article, but I suspect much of this translates over to the world of board game design.

His list of goals as a game designer struck me as very helpful as I consider my role as a game designer:

  • challenging. Often, we want the game to make the user think a lot.
  • explorable. We usually want the user to think there are always more possibilities in there.
  • scalable, so that players learn better play as they play.
  • crazy juicy, so that players are captivated by spectacle, well beyond the needs of feedback from a UX perspective
  • inviting of error. We want players to learn through mistakes.

From: http://www.raphkoster.com/2015/06/29/game-design-ux-design/

As I attempt to adapt my skills it seems imperative that I consider, understand and embrace how goals are different and how my skills as a UX Designer can be leveraged to achieve these goals.

Timmy, Johnny and Spike and the usage of personas in game design

mtgcom_daily_mr11b_pic1_enAn important tool in the world of UX design is the persona. It is used to describe your user base by breaking them into groups and giving them key traits and names. The idea is to remind the designer or developer that they are building a product for someone other then themselves. It doesn’t matter if you the designer understand the product – of course you do, you designed it – but rather, does the user?

Game design is the exact same way. As a game designer we are making games to be played by people. Most likely we are designing games to be played by non game designers. This great article by Mark Rosewater of MtG fame shows how they user personas to keep their target audience in mind as they create cards for their game.

Although I think of them as personas, Mark refers to them as Psychographic Profiles. This lead me to discovering something I hadn’t considered before in game design, aesthetic profiles. The notion of segmenting the audience based on their aesthetic expectations. In interface design it is well established the aesthetics play a key role in the usability of an application. And of course I translated this to game design. Even in the prototyping stage I believe that aesthetics play a big role in determining if we like a game or not. But what I had not considered is the importance of creating a persona of the types of aesthetics your audience is looking for.

 

Twenty Years, Twenty Lessons

This presentation from the lead designer on Magic the Gathering is fantastic. He shares highlights from 20 years of experience working on MtG. I personally love how so much of what he shares relates to the world of UX Design. He has a strong focus on how the users (players) will think of things and how they will expect things to work. It strongly parallels the way I think of using UX techniques in game design.

http://magic.wizards.com/en/articles/archive/making-magic/twenty-years-twenty-lessons-part-1-2016-05-30

10-12-2016-9-51-05-am