Most competitor research dies in a slide. Someone on the team spends a weekend collecting store pages, pastes six logos onto a grid labelled "the landscape," writes "our game is more accessible than X and deeper than Y," and the file is never opened again. The pitch deck gets a page. The design doesn't change by a single line.
A teardown is the opposite of that. It is a structured play session where you take a competitor apart to steal its answers to problems you have not solved yet — and, more importantly, to find the problem it solves badly that you can solve well. Done properly, it produces design constraints, not marketing adjectives. Here is a method that takes about two days.
Pick five games, not fifty
The instinct is to be comprehensive. Resist it. A teardown you finish on five games beats a spreadsheet of forty you skimmed on YouTube. Choose across three bands:
| Band | How many | What it tells you |
|---|---|---|
| Direct | 2 | What your player already owns. These set expectations you will be judged against. |
| Adjacent | 2 | Games from a nearby genre that share one core verb or loop with you. These are where you steal mechanics. |
| Aspirational | 1 | The best-executed game in your shape, regardless of budget. This sets your quality bar, not your scope. |
If you are making a co-op deckbuilder, your adjacent band might be a solo roguelite deckbuilder and a co-op action game with no cards at all; your aspirational pick might be Slay the Spire, whose content volume you will never match but whose structure you can learn from.
Write down why each game is on the list before you play it. If you cannot finish the sentence "this game is here because it solves ___," it does not belong on the list.
Play with a stopwatch, not a review score
Buy the game. Play it yourself. Watching a streamer tells you how it looks; it does not tell you how it feels in the hand, and feel is most of what you are competing on.
Set a fixed budget — 90 minutes per game is enough for a first pass — and log against the clock. What you are capturing:
- Time to first meaningful choice. Not the first button press. The first decision where the player could plausibly have chosen otherwise. In Slay the Spire this arrives inside a minute: the first card reward after the first fight.
- The loop length. How long from "start of a unit of play" to "meaningfully changed state"? Vampire Survivors caps a run at 30 minutes and hands you a weapon choice at every level-up, nesting a very short loop inside a long one. Stardew Valley's unit is a single in-game day inside a 28-day season.
- What the tutorial refuses to explain. The things a game trusts you to work out are what its designers considered legible without help — a direct read on their assumptions about their audience.
- The moment you got bored, and what you were doing. Write the timestamp. This is the single most valuable line in the whole exercise.
Keep the notes ugly and specific. "Menu felt clunky" is worthless. "Four button presses and two loading screens between the end of a run and the start of the next one" is a design constraint you can hold yourself to.
Score on the axes you actually compete on
Now convert notes into something comparable. Pick five to seven axes that matter for your game — not generic ones. A survival crafting game might score on base-building depth, threat pressure, inventory friction, co-op drop-in and session length flexibility. Score each game 1–5, and score your own current design honestly on the same axes. An example from a teardown of an imagined tactics game:
| Axis | Competitor A | Competitor B | Aspirational pick | Us (current) |
|---|---|---|---|---|
| Readability of a turn | 3 | 2 | 5 | 3 |
| Meaningful build variety | 4 | 5 | 3 | 2 |
| Session length flexibility | 2 | 2 | 5 | 4 |
| Recovery from a bad turn | 4 | 3 | 2 | 4 |
| Onboarding without text | 2 | 3 | 5 | 2 |
The table is not a scoreboard. It is a shape-finder. Read the columns and you learn who is good at what; read the rows and you learn which axes are already crowded at 4–5 and which are stuck at 2–3 across the board.
Into the Breach shows what a deliberate high score on one axis buys you: by telegraphing every enemy's next attack exactly, it pushes readability to the ceiling and accepts a smaller possibility space as the price. That is a trade, chosen on purpose.
Find the gap you can defend
A gap is only useful if three things are true:
- It is real. Two or more competitors score 2 or below on the axis, and players complain about it — competitor forums and negative reviews state recurring complaints in plain language.
- You can be a 5 there. Not a 4. If the gap needs a feature you cannot build with your team on your schedule, it is someone else's gap.
- It is legible from outside the game. A player must grasp your advantage from a store page or 30 seconds of footage. "Deeper systems" is not legible. "Pause a co-op run and hand the save to your friend to finish solo" is.
If a candidate fails any of the three, discard it and look again. Most teardowns produce one defensible gap. That is a success, not a disappointment.
Turn findings into constraints
This is the step everyone skips, and it is the only one that changes the game. Each finding becomes a line that a future designer on your team can check work against. Write them as testable statements:
- "A player can start a new run within 8 seconds of the previous one ending, including all menus."
- "Every enemy telegraph must be readable from a static screenshot with no UI."
- "No build requires reading a stat number to evaluate; icons and colour must carry it."
Constraints like these belong in the design documentation where they will be consulted, not in a research folder. In GameDesignerX, the Market Analysis module is the natural home for the comparison table and the per-game notes, with each resulting constraint promoted into the relevant mechanics or level entry so it surfaces while someone is actually designing. Log the calls you decided not to act on in the decision log too — "we chose not to compete on content volume" is exactly what a team re-argues in month nine.
Two-day checklist
- Five games chosen, each with a one-line reason
- 90 minutes played per game, notes timestamped
- Boredom moment recorded for every game, including your own prototype
- Five to seven axes defined before scoring begins
- Scoring table filled in, your own game included and scored honestly
- Competitor negative reviews skimmed for recurring plain-language complaints
- One defensible gap identified and tested against the three criteria
- Three to six findings rewritten as testable design constraints
- Constraints filed where designers will hit them, not in a research folder
- Calendar reminder to repeat the pass in six months
Failure modes worth naming
Scoring your own game generously. If your prototype scores 4s across the board, you have written fiction. Have someone who has not touched the project in a month score it instead.
Confusing a gap with an omission. Sometimes every competitor scores 2 on an axis because players do not want a 5 there. Before you commit, find evidence that anyone is asking for it.
Teardowns as procrastination. Two days, five games, then back to the build. If you are on week two of "research," you are hiding.
Doing it once. The landscape you tore down at the start of a three-year project is not the landscape you ship into. Re-run the pass at each major milestone; two days is the cheapest course correction you will ever make.
The point of all this is not to know your market. It is to come back to your own design document with a shorter list of things you are allowed to be mediocre at, and one thing you have decided to be the best at.