Understanding the Flow of Decisions in a Game

Understanding the Flow of Decisions in a Game

October 15, 2015 2 By Ryan Sanders

Meeple Speak article by Nat Levan (designer of New Bedford) on understanding the flow of decisions in games.

Welcome to another Meeple Speak. In this edition, our guest writer is none other than Nathaniel Levan. Designer of New Bedford and author of the gaming blog Oakleaf Games.


Understanding the Flow of Decisions in a Game

By Nat Levan

When I first sat down to write this article, I had a big list of topics I wanted to cover. So I decided which ones I thought would work best, and the Inquisitive Meeple chose a subset of those. Finally, I was able to choose the one that required the least work. Sure, I could have saved some time by being lazy from the beginning, but that would have been much less interesting. And that’s what I want to talk about today.

Choices make games, and better choices make better games. But as a designer and a player, one thing I try and keep in mind is that adding choices to a game doesn’t necessarily make a game more interesting. This is something that can be hard to perceive, but taking a step back and looking at the game flow can help.

Before I jump into discussing it, I want to clarify. This isn’t about the psychological concept of Flow, which roughly translates to being in the zone, and a desire to keep playing. There are good articles out there, but that is not the topic of this article. Nor is this an article about how to make a flow charts for your game, (I recommend the tutorial on Clocksmith Games). This is instead a post about considering the flow of decisions, and how it will impact player choices. More specifically, it is about understanding the way that choices influence future choices.

I first started thinking about this after playing a game a few years ago. Based on the mechanics of the game, each decision could lead to many interesting outcomes. But when I started playing, I realized that there was really only one main path through the game, with very few decision points. It turns out that each decision step could be isolated and solved optimally, and all of the decisions were boiled down to “give up and start over” or “continue on a deterministic luck-based path.”

If you started to draw out the flow diagram for the game, it would have one main trunk, with a few tiny branches or loops, but all of the decision points simply progressed along that same trunk. This is a naive approach to strategy development, by which I mean it uses a naive algorithm, taking the most direct path from setup to the end of the game.

This can be compared to a children’s story, in which a series of loosely connected events relate to the main idea of the book. The book flows directly through each event until it reaches the end. Complex literature has multiple plots, sub-plots, and hidden plot that the reader is not explicitly informed of. Parts of the story come into and out of focus, and there are subtle interconnections between them.

Complex games do this equally as much. But in a game, the choices made by players determine which paths to follow. As different paths branch off and intersect, new choices are created for the player. In this respect, the flow of a game is all about complexity, the same complexity I wrote about on my own blog when I discussed making a game “easy.”

It is clear from this comparison  that many decisions along a simple path is not the same as many decisions along multiple intersecting paths, so understanding how a game flows, is really a tool for helping to create better decisions in a game. So to help characterize those decisions, we can put the games in terms of a flow diagram.

Start by evaluating the number of different actions players can do on their turns. This will give you the general shape of the flow diagram. Also consider how many times a player can act in each turn. this gives you an idea of the number of sub-branches. Finally, think about feedback, and how current actions affect the later game. This gives you an idea of how connected the branches are. Here are some quick examples.

Ticket to Ride has two main branches, completing tickets, and completing routes. Players can only one of three things on a turn, so there are not a lot of smaller branches. Building routes does help you with completing tickets, but completing tickets does not help you build a route, so the branches are somewhat loosely connected.

A game like Settlers of Catan gives 2 main branches: Expansion and Development. Expansion includes building roads and settlements, while development includes cities and Development cards. But these two main branches have a lot of interaction, and require a player to switch back and forth. This also allows for a third strategy of balancing both branches.

A game like Agricola has two main branches: animals and crops, with a “building” branch that includes cards and rooms, all around a main trunk of feeding and growing. Because of the way scoring is set up, a player can rarely afford to ignore a branch. Each branch also has sub-branches, for different animal types, grain versus vegetables, and the various improvements and building options. The occupation and improvement cards add even more cross links between the branches.

This can be a great way to decide how much complexity you want in the game. Designing a game for families or casual players? Reduce the number of branches and connections. If there is an obvious strategy, Put small, complexly connected sub branches into a main trunk, and players will have a hard time finding the optimum path. If you want a real brain-burner, think about ways that the chart can be connected, both horizontally and vertically. And think about how the game develops. You can have things branch in and branch out at different parts of the game.

Considering your game from the point of view of a flow diagram can be a useful way to determine where your players will be making decisions. It can also help differentiate between “interesting” decisions and evaluation. Evaluation is what players do to determine if they continue or not, while a decision is a strategic direction. In terms of a flow diagram, evaluation is vertical, while a decision is horizontal. The greater the divergence between the decision branches, the more “interesting” the decision is.

This is really only a brief foray into making interesting decisions. In fact, much of game design is simply exploring the space of what makes a decision interesting. Simply adding more decisions doesn’t change their nature, and as designers, we need ways to evaluate them. Fortunately there’s no single correct way to study the decisions in your game, and thinking about your games in terms of its flow diagram simply gives you another choice.