Hi there! This week I’m returning to game design principles I picked up over the course of my career. The topic of the day is complexity budget. I first heard this principle clearly stated by Wizards of the Coast veteran Skaff Elias. He was part of a gang of Magic designers who played the heck out of everything Skip, Monte, Jonathan, and I were putting together for 3^rd Edition Dungeons & Dragons. He offered tons of great feedback and suggestions, helping us to make 3^rd Edition better. We were down in the weeds of the skill system when Skaff expressed the “complexity budget” idea:

Every system in a game has a “cost” in complexity. Choosing where to spend your design’s complexity budget is an important decision.

In other words, a system that’s highly complex but not very important is a misuse of resources. And it’s easy to create something like that by accident, rather than by making a conscious decision that this particular part of a game needs to be complex.

What Is Complexity?

I’m sure there are plenty of academic definitions for game complexity, but as a working game designer I default to a rather binary understanding of complexity: Is this system easy to learn, or hard to learn?

There are many ways things can be easy or hard. For example, if you provide a system that works like something else players already know how to do, it’s easy. If you load up a system with lots of technical jargon, it might be harder than it needs to be. Systems that deliver counterintuitive results are more complex than systems that produced expected results. And so on.

Ultimately, you want players to be able to quickly “internalize” most game play, so they can concentrate on what they’re trying to do in the game, not how.

Complexity isn’t necessarily bad if it supports important game play and fulfills player expectations. A rule that says a master swordsman kills any human they attack would be simple. But most players expect the complexity of different outcomes based on different targets, or some randomness like a d20 roll. The temptation to try to make your game an accurate simulation of “what would really happen” is pretty strong. Choose the actions you want high simulation value for carefully, and avoid complexity elsewhere.

Example: Axis & Allies Naval Miniatures

When I drew the assignment of designing the War at Sea game, I faced a pretty common challenge for a game designer: I knew a lot about the topic because I was passionate about it, and I wanted to make sure the game I created was a pretty good simulation of the subject.

There were many things I could have spent complexity on: armor penetration, tactical maneuvers, detection, you name it. But after a week or so of noodling around with design drafts, I realized that the real complexity of the game was hiding in the fact that we needed a game that brought together all domains of naval warfare—air, surface, and subsurface. We wanted Axis & Allies Naval Miniatures to cover U-boat wolfpacks attacking convoys, furious surface battles in Ironbottom Sound, and Midway-like carrier strikes.

So, I made the conscious decision to devote complexity to the sequence of play and the way units of different types could attack each other. Look at an AANM unit stat card, and the thing that jumps out at you is the matrix of attacks in the middle of the card. Units have values for Gunnery, Antiair, ASW, and Torpedo attacks. The sequence of play tells you when each type of attack takes place. Your fighter squadrons can destroy or drive off enemy dive bombers before they knock out your carrier, and your destroyers can protect your battleships by depth-charging enemy subs before they make their torpedo attacks. It winds up feeling like a pretty good approximation of WW2 air-sea battles.

By comparison, everything else in the game is pretty simple. We don’t worry about which way ships are pointing or which firing arcs their guns face. Attacks are buckets of dice that loosely measure firepower, not accuracy or armor penetration. Strange as it is to say, AANM players generally don’t miss those things. The game succeeds and is fun to play because it spends its complexity budget appropriately.

(I should note there is another source of high complexity in Axis & Allies Naval Miniatures: the Special Abilities of the various units. For Luca Tarigo, those are Sub Hunter and Lay Smoke Screen. This is an example of something known as “exceptions-based rules design.” Every special ability is a way the unit can break the rules of the game or do something other units can’t. Any game that accumulates lots of unique special abilities will be pretty complex because potential interactions multiply, and players need to figure out which abilities are important. But that’s pretty common for collectible miniatures games.)

Winding Up

I could dive in on more examples of good or bad complexity budgets, but this post is getting long and I’m sure you can identify some examples of your own. Next time you’re working on a system for a game and it’s getting complex, take a step back and ask yourself if it’s a good use of your complexity budget. You’d be surprised how often the answer is no.