Do Not Crush List

Why Most Game Designers Get This Wrong

I spent about three years working on a tabletop RPG system before I ever heard the term Do Not Crush List. Someone on a Discord server mentioned it casually, and it instantly explained why two previous projects had quietly died on my hard drive. The core idea is simple but easy to overlook: every game has certain elements that seem expendable when you are drafting rules, but they actually hold the whole thing together. Crush those elements, and the game stops functioning. The problem is that most designers do not realize they are crushing things until after the project is already broken. You strip out a mechanic because it looks complicated. You remove a narrative constraint because it feels restrictive. You optimize a system until the thing that made it interesting is gone. The Do Not Crush List exists to stop that from happening.

What the List Actually Is

A Do Not Crush List is a documented inventory of game components, rules, constraints, and design decisions that the designer has identified as non-negotiable. These are elements that contribute to the core experience in ways that are hard to quantify during normal development. They are easy to mistake for bloat or optional complexity because they do not always produce immediate, measurable value. That does not mean they are useless. It means their value shows up in playtesting, not on paper. I have seen teams treat this list as a sacred document. I have also seen teams make one and then ignore it the moment a playtest revealed a problem. Both approaches have consequences. The list is not meant to prevent all changes. It is meant to make every change intentional. When you remove something from a game, you should be able to articulate exactly what breaks if you remove it. If you cannot articulate that, the thing is probably on the list.

How to Build a Real Do Not Crush List

Start with a complete draft of your game. I do not mean a sketch. I mean something close to finishable, even if the mechanics are ugly. Then run through the following process. Step one: isolate every mechanical subsystem. This means dice rolls, resource tracks, condition markers, turn sequences, card draws, movement rules, and any other system that requires a player to make a decision. Write down each one on its own line. Do not group them. Grouping hides the fragile stuff. Step two: record what each subsystem produces at the table. Not what it is supposed to do. What it actually does. Time spent. Player engagement level. Arguments that come up. Pauses in play. Laughter. Frustration. I keep a spreadsheet with columns for mechanic name, observed behavior, frequency of use, and friction rating. The friction rating is subjective, but being forced to assign a number makes you confront your assumptions.

Step three: identify which subsystems exist purely for structural support. This is the step most people skip. A rule that seems decorative often holds a whole section together. In one project I worked on, there was a seemingly pointless rule about shuffling discard piles at the end of each round. It added about twelve seconds to gameplay. We almost removed it. During a live session, a player forgot to reshuffle, and the entire resource economy collapsed because the deck became predictable. The rule was invisible until it was gone. That rule went on the Do Not Crush List. Step four: document the constraint version of each element. For every item on the list, write a sentence that starts with the word without. Without the reshuffle rule, the game breaks at turn four. Without the condition tracker, skill checks become meaningless. Without the card limit, players hold too many options and analysis paralysis sets in. These sentences force you to state the cost of removal in plain language. Step five: revisit the list after every major playtest. The list changes. Sometimes an element earns its keep and stays. Sometimes an element is proven unnecessary and can be removed with confidence. The value is in the conversation you have when deciding whether to keep something. That conversation prevents accidental deletion.

Common Pitfalls That Break the Process

I see the same mistakes repeatedly. The first is treating the list as permanent. It is not permanent. It is a living document. You will learn things about your own game through testing. When you learn that an element you feared to remove is actually safe to cut, remove it. But remove it deliberately, not accidentally. The second mistake is building the list before the game is complete. I made this error early on. I created a Do Not Crush List from a prototype that was missing half the content. Everything looked fragile because the game was incomplete. I protected rules that did not matter and deleted rules that did. The list reflected my ignorance, not the game's needs. Wait until you have a playable version. Then build the list. The third mistake is using the list as a weapon against feedback. A playtester says something is confusing. You point to the Do Not Crush List and say we cannot change it. That is not how the tool works. The list documents your current understanding of what matters. It does not override actual problems. If the playtester is right, the rule is wrong, even if it is on the list. Update the list instead of arguing with your audience.

Edge Cases and What Happens When You Ignore the List

Here is a specific problem I ran into during the development of a card-driven combat system. The Do Not Crush List included a rule that forced players to reveal their hand at the start of each round. The rule felt invasive and slow. It added about twenty seconds per round. Every optimization pass wanted to remove it. I kept it on the list because removing it changed the risk assessment players made before committing cards. That was my reasoning on paper. The problem came during a session with experienced players who were also fast readers. They found a workaround. They memorized their hand composition and started making decisions based on remembered states rather than revealed states. The rule had no effect on their actual play, but it still took twenty seconds. The Do Not Crush List said keep it. My instincts said it was dead weight. I kept it anyway for two more sessions. Then I removed it and rebuilt the system around hidden information. The new version was faster and actually more strategic. The lesson was not that the list was wrong. The lesson was that the list captured the symptom, not the underlying design goal. The goal was information asymmetry. The method was hand revelation. When the method stopped serving the goal, I replaced the method instead of clinging to it. This is the nuance that beginners miss. The Do Not Crush List protects design intent, not implementation details. If an element is listed, protect what it achieves, not the element itself.

Why This Matters More for Solo Designers

Teams have built-in protection against accidental destruction. One person suggests cutting a rule. Another person remembers why it exists. Solo designers do not have that safety net. You are your own worst enemy when you are tired, because tired you sees complexity as a problem instead of as a feature. The Do Not Crush List is the external memory you do not have when you are running on three hours of sleep and a cold cup of coffee. It is also useful for collaboration. When you hand a rulebook to someone and they ask why a section exists, you should be able to point to a documented reason. Without that, you are just defending preferences. With it, you are defending decisions.

Where to Download a Do Not Crush List Template

I host a plain text template that matches the process described here. It includes the fields for mechanic name, observed behavior, friction rating, constraint sentence, and status. You can download it from the project repository linked below. The file is formatted for plain editors, git compatibility, and easy import into spreadsheets if you prefer that workflow. There is also a companion Markdown file for teams who want to embed the list directly in documentation tools. The template does not replace the process. It just removes the friction of setting up the structure. You still have to do the work of testing and observing. No file will do that for you.

When the Method Fails Completely

The Do Not Crush List is not a universal solution. It fails when the game is fundamentally broken. A broken game will not be saved by protecting its parts. You need to rebuild, not preserve. It also fails when the list becomes so long that it paralyzes revision. I have seen teams accumulate fifty items on a list and then refuse to touch anything for six months. That is not careful design. That is fear dressed as rigor. Another scenario where this approach breaks down is hybrid projects. If you are building a game that intentionally blends incompatible systems, the list may flag elements that should be crushed precisely because they create productive tension. The tool assumes coherence. When your goal is controlled chaos, the tool gives noisy results. If those conditions apply to your project, consider an alternative. Use a crash log instead of a preservation list. Document what breaks when you remove each element, then review the crashes after every test session. The crash log is blunt. It does not protect anything. It only tells you what has weight. Sometimes that is exactly what you need.

Final Practical Notes

Build the list after your first complete playtest cycle. Do not build it before. Revisit it after every session. Write constraint sentences in plain language. Protect design intent, not implementation. Accept that some items will leave the list over time. Keep the template small and usable. Large spreadsheets get abandoned. A single page with honest entries gets maintained. The Do Not Crush List is not a magic shield. It is a record of what you learned about your own game while you were still learning it. The value is in the documentation, not in the decoration. Treat it like notes, not like scripture.