Category: Design

Hello all! Many of you have likely seen me mention the methodology behind my design, destructive design, and I thought it was due time I broke the idea down a little bit. I thought approachable theory might be the best place to do it, because simple is good. I’ll talk about the origin of the methodology, how it’s applied, and what’s the difference between destructive design and hacking. I hope you enjoy the article!

Origins

Destructive design has existed informally, for sure, for a long time. From the first time someone took the time to examine a game’s design and use it to construct something new, the roots have been there. For me, personally, they’re rooted in the approach my dad taught me for repairing engines and similar things – I talked about this a little on [insert quest here].

My dad can take anything apart, put it back together, and fix the problems it had – his repair skills are legendary. He taught himself a lot of the skills necessary for it using the root of the mentality for destructive design. He would take things apart entirely – whole engines, down to the nuts and bolts – and put them back together. In the process, he could find the root of what wasn’t working just right, learn how the machine worked, and find opportunities to improve things. He taught me this when I was a young kid, and it stuck with me.

When I started in games, I kept finding games that were almost there, nearly right, but not quite what I needed. I wanted to fix it, and the only way I knew how to do that was to take it apart and put it back together. A common misconception is that my games and things I create with this method could be that they’re the put back together part – but that’s not how it works. I build something new – maybe making molds of ideas or pieces, but never copying right over – and try to make what I want to see, whether it’s like that other thing at all or not.

After all, my dad – an engineer – did that, too. He could take what he learned from those engines and build new designs for machines and tools. And it was pretty cool.

My dad also likes to fish. Photo by Bonnie Cousins.

Application

It maybe isn’t easy to do destructive design, depending on your approach, but the core ideas are simple:

1. Have a concept or mechanic
2. Break it down into its basest parts
3. Examine it in detail
4. Build it back up again and look for cracks and loose bolts in the process
5. Build something new from what you’ve learned

For an example, we’ll look at Struggles in Turn. Turn is a game about shapeshifters in small towns who must find balance between their human and beast identities. Struggles are what might otherwise be moves in a Powered by the Apocalypse game. There are just some slight changes, but they matter. Moves in Monsterhearts are one of the first parts that I broke down.

The “turn someone on” move from Monsterhearts.

Here are some of the base parts of moves*:

– Descriptive prompt (when you ____, roll with _____).
– Requires die roll
– Stats can be penalty or bonus
– Success ladder (10+ succeed, 7-9 succeed at cost, 6- fail)
– Narrative options
– Mechanical options
– Risk of failure

When I designed struggles, I started with a different set of assumptions based on what I learned here. First, I built the pieces back together and realized that one of the key elements of these moves was what I wanted to avoid: failure. In Turn, while it might take time and will have consequences, you always succeed at what you do. So I struck out “risk of failure.” Next, I wanted struggles to exclusively be something that happened when you were doing something that your opposed form didn’t want to do, or that it might resist, or in situations where you were trying to hold your opposed form back from doing something. When you look at Monsterhearts moves, they’re only when you’re actively doing something, and you’re assumed to want to do it. I decided to make you always rolling a penalty to these rolls, so I took out “stats can be penalty or bonus.”

The success ladder is just handy, and I did want to require a die roll. I also wanted to include mechanical and narrative options for any pick lists. But with the ladder now, the 6- wasn’t a failure – it was just a giant pile of consequences. You do want you want, but the ladder represented the severity of consequences for succeeding. The base parts of struggles are now like this*:

– Descriptive prompt (when you ____, roll with _____).
– Requires die roll
– Stats are penalty
– Success ladder (10+ no or few consequences, 7-9 more consequences, 6- all consequences)
– Narrative options
– Mechanical options
– Guaranteed success

The “mind your manners” struggle in Turn.

If you swapped these two mechanics – put struggles in Monsterhearts and moves in Turn – the games would be radically different. Giving characters in Monsterhearts guaranteed success could end up with towns overrun with monstrous teens, meanwhile making it so the stats could be bonuses could make shifters in Turn even more dangerous. It would change tone, and alter how people play.

The process of breaking these things down is really exciting sometimes! It is good to see what’s lying beneath the surface, what’s grinding the gears – and when put into application, destructive design can be revealing and instructive.

*Not necessarily an exhaustive list.

Destructive Design versus Hacking

What’s the difference between destructive design and hacking? Well, they’re not mutually exclusive. In fact, plenty of people who hack games use destructive design. The real core differences are that with destructive design your goal is to create something notably different on a structural or conceptual level, while some hacks intend to be similar, matching structure and concepts but with different dressing – and destructive design is an active and purposeful process.

Destructive design can happen even on the smallest mechanical or narrative design level. Some people do it, but wouldn’t call it that, because we don’t always label how we do something. Meanwhile, I use the term because it helps me align my methods and do things with intent. A person could consider Turn to be a hack – and some people do – but I don’t, because I think that I used destructive design to change fundamental concepts and structure. Like all parts of game theory, though, people’s perspectives differ.

I love these animals from ravensribbon.tumblr.com.

Examples

One of the most significant examples of destructive design is Turn, which is currently in production. Turn was born of playing Monsterhearts and finding it wasn’t quite hitting the nerve I wanted, and then sitting there with my ideas piled up for like four years before I finally wrote anything down. There’s definitely evidence of Monsterhearts in Turn, but it is a completely different beast.

Another example of destructive design by me is Script Change. It doesn’t seem like it would be one! It’s just a content and safety toolbox, right? Well, some could say Script Change was inspired by the X-card… except the inspiration was to break it down into concepts and try to make it what I wanted. After using the X-card for a while and talking to John Stavropolous and so on, I realized it was a great tool, but not the right one for me. I examined it, watched it in play, and then figured out what worked best for me.

Many of my works are destructive design – including Let Me Take a Selfie! All of the games inside come from the root of seeing other selfie games and wanting to see how I could use a mechanic I cared about to tell the stories I wanted to, but not by using the same methods as the other games. None of them are directly inspired, none of them are intended to be similar at all to other games – they just come from the root of “break down this idea and build it back up so I can build something new.”

Conclusion

This post was supported by the community on patreon.com/briecs. Tell your friends!

To leave some cash in the tip jar, go to http://paypal.me/thoughty.

If you’d like to be interviewed for Thoughty, or have a project featured, email contactbriecs@gmail.com.