21 Oct

Outlining Your Game with Decision Diagrams

Feet and ArrowsI’m not much for analysis. I like to dive right in, flow with the idea and see where it takes me.

That’s usually a dead end. And another dead end. And another, and another. Ok, organic designing is fun but it’s not the most efficient way to get your game finished. Sure, you could try every combination of actions, mechanics and components you can think of but the number of combinations rapidly escalates and soon you’ll be wasting your precious playtesting time in order to see whether twelve cows or fifteen sheep are better.

That’s where a bit of analysis comes in handy. For some this comes intuitively: either they’ve designed so much that they’ll see the most common pitfalls outright or they’re used to analyzing data and can flush everything through a spreadsheet.

Me, I need help.

Tree Diagrams for Decisions

One of the ways I’ve found for finding the problems in a design and seeing what to do about them is through hierarchical decision diagrams. That’s a fancy way of saying “draw a tree diagram of everything that can happen”. Here’s how it works.

Let’s take a game of Chess. You’ve got 20 opening moves (each of the 8 pawns can move one or two steps and each of the knights can move forward and left or right). Each of these is a node in a decision tree.

Then your opponent moves, also 20 possibilities making for 400 different positions after two moves. In six moves you’re up to almost 10 million nodes, which explains why you need a Big Blue to beat a Grandmaster. There’s simply no way to map out an entire game of Chess in your head.

But wait, you can cheat. You don’t need to know all the moves, only the ones that make for different board positions. And even then, you don’t need to know all those moves, only the ones that would be somewhat logical in such a situation. And that rapidly shrinks your decision tree. But it’s not enough.

Cutting Back to Player Choices

Race for the Galaxy: All cards and componentsTake a look at Race for the Galaxy Amazon. Each turn each player choses one of 7 actions. Your decision tree for each player will consist of 7 possibilities. But some of them will be ridiculous. No sane player would chose to produce if she didn’t have a world to produce on. No sane player would chose to Settle if she didn’t have a world to Settle (sure, you could hope that someone else would choose explore and that you’d be able to draw a world then and then Settle – but that’s such a long shot that trying to analyze it is meaningless for most design situations).

What happens when you try to bone out the real possibilities is that you end up with player choices, not player actions, as nodes: attack or build? Move or trade? Diplomacy or force?

In the same way you could classify player situations in a very rough manner: rich or poor? Ahead or behind? Strong or weak? Then you’d be able to look at the possibilities through a very limited set of options and rule out those that are decidedly inferior. But these options should be relative individual mechanics or groups of mechanics, otherwise its very hard to analyze them.

Let’s say that you’ve got a race mechanic (which is the case in most VP-based games). So in that context you can be in ahead, in the middle or behind (you can also be out of the race or have a clear win but those are easy to spot without this type of formal analysis). Let’s also say that you’ve got a mechanic that lets you attack other players. Should a player then attack others, based on whether she’s ahead, in the middle or behind?

Using Categories

So you’ve got a simple tree diagram: player is ahead, middle, behind. Player is stronger, equal, weaker. And now you look at the outcomes: if the player is ahead and stronger and attacks, will she be more or less ahead afterwards? Will the attack push her to be ahead but equally strong? Will not attacking let other players catch up, so that she’ll be in the middle next turn? This opens up for a different analysis of next action and will quite quickly spiral out of control with countless possibilities. The trick here is that you don’t need that.

All you need is to see whether the actions you’ve made available to the player will change her, or the other players, categories for the next turn. Then you’re back in the decision diagram at either the same point (ops, the action is static) or a different point (hmm, is this action’s result better or worse than another action’s?).

And you don’t need to look at all the actions all the players can do at the same time. All you need is to look at what makes sense for one player positioned in one category at a time. Which is way easier than trying to keep the entire game in one’s head.

Decision diagrams are a way of breaking up the analysis into smaller chunks. Perhaps you don’t need that. Perhaps you’re so brilliant that you can keep large parts of the game in your head at once. I know that I’m not. I easily get blinded by my usually preferred strategies and miss significant options. Or I assume that this is the way to play a game and miss that it’s broken in some way.

Yes, it does get easier to see patterns as I practice designing and playtesting. But until those patterns are so complete as to make me able to design perfect games in my mind I’ll take any crutch I can.

An Example

Decision tree for DropZoneWhat I’m trying to look at is whether there’s a decent balance between fleet bid actions depending on whether you’re rich or poor. Ruleswise you can either bid (and get at least one fleet) or not bid (and get resources + a unit on any planet). If you bid you can bid low (and get the guaranteed one fleet), risk a mid level bid (and you might get more fleets) or bid high (and almost certainly get two or more fleets).

If you’re poor there’s incentives for doing anything. You could take the resources (that’s logic if there are more turns and no scoring this round). You could take one fleet and hope to get an early one. You could risk trying to get two fleets and bolster your defensive capabilities or bomb someone else. You could even go all in for fleets and hope to make it very expensive to attack you.

Same goes for an average income player, although the decisions are shifted based on whether it’s a scoring round or not (a poor player might be forced into not bidding by lack of resources even on a scoring round).

But for a rich player there’s absolutely no incentive not to bid. It’s a dead end even with the free placement of a unit as the rich player will be able to beat through any defences by buying multiple fleets and having units to spare – it is a more flexible position.

The only way to make not bidding attractive for a rich player is if there would be a way to either place the free unit last (i.e. increase flexibility) or to get more free units for not bidding (i.e. increase economic growth). But that would make it way, way, way to lucrative not to bid for poor and medium players. So I need to either come up with another mechanic for no bids or accept that a rich player will never want to do it.

Ok, this is a pretty simple diagram. It’s got 9 nodes and 10 edges (links between nodes). But that makes it workable. If I’d have wanted to analyze how being behind on points would affect those decisions I’d make another diagram using the edges from this one as nodes (so I’d have a node called “poor: get resources”, another one called “poor: get fleet”, one called “rich: bid high” and so on). Then I’d add three more nodes at the bottom called “ahead, middle, behind” and look at the edges going out from those.

Sure, I could have made a single diagram from all of the possible choices of bidding and income and VP but, for me, that would take more time and skirt the edge of what I can productively keep track of. Thus I prefer to have several small diagrams and analyze the problems one step at a time.

Free Diagraming Tools

On a final note: for the most parts it is easy to do this kind of decision diagramming using only pen and paper but sometimes you might want to take it to another level, or make very complex decision diagrams weighing lots of factors against each other, or share your diagrams with others in collaborative works. Then it might be good to look into one of these freeware tools.

Disclaimer: I’m not in any way affiliated with the makers of these tools.

yEd – My preferred diagramming software both privately and at work. It takes Excel input (and can be hacked to create Excel output as well), making it easy to go from spreadsheet to visual. It’s a bit counter intuitive sometimes, and it’s more functional than beautiful, but I like it, use it, and recommend it. yEd has the ability to re-draw your diagrams by using automatic hierarchy settings.

FreeMind – Brainstorming software. I used to use it. Once again bit of a learning curve but it lets you connect stuff in a very graphic way. It also has loads of splits and branches so you can find one that suits you.

Dia – Diagram editor like a simplified Visio. This is the one I started out with, very easy to learn but somewhat limited. Last I used it, it seemed to be heading for Internet extinction but now there’s a new version out so maybe it’s alive again.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.