Cutting Up Games

Actually Taking Games Apart

Most people who try to analyze games do it wrong. They write essays about what they felt playing Dark Souls or they list every mechanic in a spreadsheet without connecting anything to anything else. Cutting Up Games is different because it forces you to look at the actual architecture of what you're playing instead of your emotional response to it. I learned this through painful experience after burning three weeks on a broken analysis framework that didn't lead anywhere useful. Here's what it actually is. You pick a game, any game, and you systematically break it down into its component systems. Not the narrative. Not the art style. The mechanics. The rules. The feedback loops. The input-output relationships. You treat it like an engineer would treat a broken carburetor on a 1998 Civic — you don't care about the paint job, you care about how the parts interact under load. I start by identifying the core loop first. What is the player doing repeatedly? What happens each time they complete that loop? Then I map the secondary systems that feed into it or get fed by it. Combat feeds resource acquisition which feeds progression which changes combat parameters. That kind of thing. I write it all out on paper with arrows between boxes. Digital tools make this worse because they encourage you to polish the diagram instead of actually thinking through the connections.

The third step is the part nobody does correctly. You identify the tension points. Where does the system create friction? Where does it reward the player for pushing against the intended path? This is where the analysis actually becomes useful for design work. Without tension points identified, you've just made a flowchart. A flowchart doesn't teach you anything about why a game works or doesn't work.

Why This Matters For Anyone Working With Games

I've seen game design students produce competent but hollow analyses because they skipped the cutting up portion and jumped straight to critique. You can't effectively critique what you haven't dissected. The order matters. Cut first, then decide if the organs are healthy or diseased. Here's a specific problem I ran into that most people don't anticipate. When cutting up a game like Celeste or Hollow Knight, the tension between the core loop and the metroidvania progression system creates a feedback loop that's nearly impossible to map linearly. The upgrade system changes the core loop mid-playthrough in ways that aren't documented anywhere. My workaround was to treat each major ability unlock as a separate version of the game and cut each one independently, then overlay the differences. That gave me a version-aware analysis instead of a flattened one that missed the structural evolution. Another thing beginners consistently get wrong is confusing description with analysis. Writing "the jump mechanic feels snappy" is a description. Identifying that the jump has a 6-frame input buffer, variable height based on hold duration, and a coyote time window of 8 frames is analysis. The description tells you nothing actionable. The analysis lets you recreate the feel or intentionally deviate from it.

Practical Tips For Cutting Up Games

Use a consistent template. Don't invent a new structure for each game you analyze. I use a six-part breakdown: core loop, control scheme, progression system, fail state handling, pacing markers, and systemic interactions. Six parts. Every game gets the same six. This forces you to find content for each section even when it feels like a stretch, and that's where the interesting discoveries happen. The pacing markers section is almost always the most revealing because most games don't document their pacing intentionally. Record yourself playing while you analyze. I don't mean speedrun recording. I mean play through normally but take notes on every decision point where you had a meaningful choice. Those choice points are where the design intent becomes visible. A game's philosophy shows up in what it lets you do, not what it tells you to do. This method has real limitations. It doesn't work well for games where the experience is primarily emergent rather than systemic. Games like Dwarf Fortress or RimWorld generate interesting design patterns through player-driven storytelling, and the cutting up approach tends to flatten those into sterile system descriptions. For those games, a different analytical framework is better suited. You can still use cutting up on the subsystems within those games, but treating the whole thing as a machine to be taken apart misses what makes it worth playing in the first place.

Also, this takes time. A thorough cut-up of a medium-complexity game runs about 4 to 6 hours. A complex one can take 10 or more. If you're working against a deadline and need quick insights, you'll want to focus on just the core loop and tension points rather than doing the full six-part breakdown. The full treatment is for when you have the bandwidth to go deep. The payoff comes when you start applying what you've learned to your own design work. After cutting up about a dozen games using this method, I noticed patterns repeating across genres. The tension point identification in particular became second nature. I could look at a prototype and immediately see where the system was either too loose or too tight without needing to play it for hours. That's the actual utility here. It's not an academic exercise. It's a skill that compounds over time.