Meta Note: Early drafts were too complex. Complexity is Bad. I simplified.
Mark Rosewater, head of design at Magic: The Gathering who I recently praised for writing down his process, has a podcast called Drive to Work. Commuting is really bad (citation not needed), so recording a podcast is a great idea. Usually it is a great geek out, but incomprehensible to non-players.
The recent episode on complexity is an exception. No game knowledge is needed and the insights transfer to life in general. He is explaining how to think about complexity. The central point is: Complexity is Bad.
It is known that Complexity is Bad, but it is important that your model of this is made of gears. To help with this, I will summarize his most important points, and add some more of my own.
People can only have so much attention.
People can only store so much information at once, typically seven things.
People can only think about so many things at once, typically three things.
If people have too many things to remember, do or think about, bad things happen.
Often they will have to prioritize, and will often prioritize wrong. They will distill the situation, or your argument, to make it simpler, whether you like it or not, in ways you can’t predict or control.
Often they will throw up their hands and give up, doing nothing or doing something at random.
Other times complexity is a barrier to entry and people won’t understand or engage with you at all.
Complexity often papers over mistakes, preventing you from finding better, more elegant solutions. You are patching bad outputs rather than fixing your underlying process.
More complex systems are harder to analyze and understand. They are more fragile and have more points of failure. They are harder to usefully change, especially without adding more complexity.
Even in the best case, complex things take longer and more concentration to engage with.
In exchange, complexity lets you do more complex things, have whatever you are building or rules you are making achieve more complex outcomes, and to better understand and explain things that are complex, which is most things. Complexity is highly useful.
Albert Einstein summarized this as “everything should be made as simple as possible, but no simpler.” Mark Rosewater summarizes this as “complexity is a cost.”
Mark’s system gives you complexity points to spend. When you increase complexity, you are spending complexity points. Spending too many has a large cost. This works similarly to weirdness points. These may be the same points.
Getting the most out of your points is valuable. Mark shares techniques for this when designing a system; there are also lots of ways for the player/user to help with this, but I will consider that beyond scope.
Resonance is where your complexity maps onto concepts that are already familiar. Flying creatures cannot be blocked by non-flying creatures. Because, you know, flying.
Chunking is where you make it easy to combine things into conceptually simple bigger things, so the new thing only counts as one thing to remember and think about. This lets people handle more complexity, so make it easy to do.
Ramping up complexity slowly is a classic. You start new players/users off slowly, as many games do, with something simple, then introduce your complexity a little bit at a time.
Hiding your complexity often works well. You put your complexity where new users/players will not think to look, or care about. When they are ready for it, they will notice. Even better, you hide it where they cannot even see it until they go looking for it. Hidden features are great for this.
Emergent complexity is great. The complexity comes not from lots of explicit pieces or rules, but from how the simpler rules of the system interact.
Complexity Is Bad
Previously: Choices are Bad, Change Is Bad
Meta Note: Early drafts were too complex. Complexity is Bad. I simplified.
Mark Rosewater, head of design at Magic: The Gathering who I recently praised for writing down his process, has a podcast called Drive to Work. Commuting is really bad (citation not needed), so recording a podcast is a great idea. Usually it is a great geek out, but incomprehensible to non-players.
The recent episode on complexity is an exception. No game knowledge is needed and the insights transfer to life in general. He is explaining how to think about complexity. The central point is: Complexity is Bad.
It is known that Complexity is Bad, but it is important that your model of this is made of gears. To help with this, I will summarize his most important points, and add some more of my own.
People can only have so much attention.
People can only store so much information at once, typically seven things.
People can only think about so many things at once, typically three things.
If people have too many things to remember, do or think about, bad things happen.
Often they will have to prioritize, and will often prioritize wrong. They will distill the situation, or your argument, to make it simpler, whether you like it or not, in ways you can’t predict or control.
Often they will throw up their hands and give up, doing nothing or doing something at random.
Other times complexity is a barrier to entry and people won’t understand or engage with you at all.
Complexity often papers over mistakes, preventing you from finding better, more elegant solutions. You are patching bad outputs rather than fixing your underlying process.
More complex systems are harder to analyze and understand. They are more fragile and have more points of failure. They are harder to usefully change, especially without adding more complexity.
Even in the best case, complex things take longer and more concentration to engage with.
The more complex something is, the higher the standards it is judged by, since you had more choices and anyone interacting with it likely has more choices.
In exchange, complexity lets you do more complex things, have whatever you are building or rules you are making achieve more complex outcomes, and to better understand and explain things that are complex, which is most things. Complexity is highly useful.
Albert Einstein summarized this as “everything should be made as simple as possible, but no simpler.” Mark Rosewater summarizes this as “complexity is a cost.”
Mark’s system gives you complexity points to spend. When you increase complexity, you are spending complexity points. Spending too many has a large cost. This works similarly to weirdness points. These may be the same points.
Getting the most out of your points is valuable. Mark shares techniques for this when designing a system; there are also lots of ways for the player/user to help with this, but I will consider that beyond scope.
Resonance is where your complexity maps onto concepts that are already familiar. Flying creatures cannot be blocked by non-flying creatures. Because, you know, flying.
Chunking is where you make it easy to combine things into conceptually simple bigger things, so the new thing only counts as one thing to remember and think about. This lets people handle more complexity, so make it easy to do.
Ramping up complexity slowly is a classic. You start new players/users off slowly, as many games do, with something simple, then introduce your complexity a little bit at a time.
Hiding your complexity often works well. You put your complexity where new users/players will not think to look, or care about. When they are ready for it, they will notice. Even better, you hide it where they cannot even see it until they go looking for it. Hidden features are great for this.
Emergent complexity is great. The complexity comes not from lots of explicit pieces or rules, but from how the simpler rules of the system interact.