The cat is asleep on the windowsill, one paw draped over the edge, tail occasionally twitching at something in a dream. I'm at the desk in the old house, surrounded by notes—frame data scrawled on index cards, screenshots with hand-drawn circles, timings recorded in a spreadsheet that's grown far too large. The afternoon light filters through the blinds, casting grid patterns across the floor.
This is how I spend most evenings: reading games backward.
Not playing them the way they're meant to be played. Not following the golden path, not chasing the story, not trying to win. Instead, I take a game apart—mechanically, systematically—and try to reconstruct the design decisions that made it feel the way it does.
This is what I call the system archaeology method. And after twenty posts, I think it's time to write down the field guide.
I. The Sensation
You've read twenty of these investigations by now. You've seen me dissect horse steering, camera distance, animation priority, loading transitions, and implicit teaching. You've watched me measure frame data, test aggro ranges, and argue with my own hypotheses. You've seen the pattern.
The sensation I'm chasing—the one that drives every investigation—is the moment when a player experience clicks into focus. When a feeling that seemed purely subjective—"this sword feels heavy," "this room feels dangerous," "this world feels alive"—reveals its mechanical underpinnings.
That click is not a reduction. It's not a destruction of mystery. It's a translation. The game is speaking in a language most reviews do not translate. I'm just trying to learn the grammar.
II. The Method
Over the past twenty articles, I've developed a repeatable method. It's not perfect. It's not scientific in the strict sense. But it's systematic—and that's what matters.
Step 1: Identify the Sensation
Every investigation starts with a feeling. Not a story beat, not a level design, not a graphical detail. A felt experience—something a player reports, something I've felt myself, something that seems too specific to be accidental.
Examples from this series:
"Horse steering in The Witcher 3 feels bad until it suddenly feels good."
"The camera in Resident Evil 4 makes rooms feel dangerous even when they're empty."
"Loading screens in Starfield make the world feel fragmented."
The sensation is the what. The method is the why.
Step 2: Suspect the Machinery
Once I've identified the sensation, I start forming hypotheses about the mechanics that could produce it. What variables are at play?
Distance: Aggro range, camera distance, travel time.
Timing: Animation frames, input buffers, loading durations.
Probability: Loot tables, enemy spawns, critical hit rates.
Priority: Animation priority, input queues, interruptibility.
Feedback: Audio, visual, haptic, and their intensity.
I'm not looking for the answer. I'm looking for a plausible mechanism—one that can be tested.
Step 3: Design the Field Test
This is the hardest part. A good field test needs to be:
Controlled: Isolate the variable you're testing.
Measurable: Capture data in a form that can be compared.
Repeatable: Someone else should be able to replicate it.
I don't always succeed. Some tests are sloppy. Some variables are impossible to isolate. But the attempt is valuable—it forces me to be explicit about what I'm measuring and why.
Examples of field tests from this series:
Measuring camera distance and tracking side attacks in Resident Evil 4.
Timing door-opening animations and loading screens across multiple games.
Observing a new player in Elden Ring to see what they learn implicitly.
Step 4: Find the Competing Explanation
This is the most important step—and the one most analysis skips.
I always ask: "What else could explain this?"
Is it emergent rather than designed?
Is it a limitation of the engine rather than a creative choice?
Is it a cultural artifact—something players have learned to expect?
Is it a byproduct of accessibility or production constraints?
If I can't find a competing explanation, I haven't looked hard enough.
Step 5: Reach a Careful Conclusion
Finally, I write down what I think the evidence supports. Not more. Not less.
I use phrases like:
"This is what I saw..."
"This is what I think it means..."
"The evidence suggests..."
"One possible interpretation is..."
I don't claim certainty. I claim inference. The numbers are evidence. The experience is the conclusion.
III. Tools of the Trade
Over the years, I've accumulated a small toolkit for reading games backward. Here's what I use:
Screen Capture and Frame Analysis
OBS Studio: For recording gameplay at 60fps or higher.
VLC Media Player: For frame-by-frame playback.
A simple stopwatch: For timing loading screens, travel times, and other durations.
Spreadsheets and Notes
Airtable or Google Sheets: For organizing data—frame counts, timings, observations.
Index cards: Old-school, but they help me see patterns across games.
Screenshots with annotations: A pen tool and a steady hand.
Controlled Testing
Mods and trainers: For adjusting variables that aren't normally accessible.
Consistent test routes: Running the same path multiple times to reduce noise.
Multiple playthroughs: Sometimes the first run is just for observation; the second is for measurement.
The Gray Cat Test
This is unofficial, but I use it often. The cat sits on my desk while I play. If she watches the screen—if her ears rotate, if her eyes track movement—I know the game has captured my attention in a way that's visible even to an observer. It's not scientific. But it's a useful barometer: Does this game hold even a cat's attention?
IV. Reading Backward
The term "reading a game backward" comes from something a designer once told me—unnamed, as always. We were discussing a game that had famously long loading screens. The conventional critique was that the loading screens were a technical failure. The designer said: "What if they're not a failure? What if they're a statement? Read it backward."
Reading backward means looking at a game's features not as accomplishments or failures, but as design decisions—even the ones that seem accidental. A loading screen isn't just a loading screen. It's a message about time. A long animation isn't just an animation. It's a message about weight. A confusing UI isn't just bad design. It's a message about what the game considers important.
Not everything is intentional. Not everything is a genius move. But reading backward forces you to treat everything as intentional—at least as a hypothesis—before dismissing it.
Examples from This Series
Horse steering: A frustrating mechanic? Or a deliberate lesson about trust and momentum?
Camera distance: A technical constraint? Or a deliberate tool for tension management?
Loading screens: A technical limitation? Or a deliberate statement about scale and space?
Implicit teaching: A design shortcut? Or a deliberate expression of respect for the player?
Reading backward doesn't mean excusing bad design. It means asking the question before answering it.
V. The Limits of the Method
I need to be honest about what this method can't do.
It can't prove intent. I can measure frame data. I can document patterns. I can make inferences about why a mechanic was designed the way it was. But I can't read the designer's mind. I can't know if they meant for the loading screen to feel like a statement, or if they just ran out of time.
It can't capture everything. Some experiences are genuinely emergent—they arise from the interaction of systems in ways that no single designer could have predicted. And some experiences are purely subjective—they depend on the player's history, culture, and mood. The method is best at capturing mechanics, not meaning.
It can't replace playing. The numbers are evidence. The experience is the conclusion. If I spend all my time measuring frame counts and never sit down to play—to feel the weight of the sword, the tension of the camera, the rhythm of the combat—I've missed the point entirely.
VI. Conclusion
This is the end of the launch roadmap. Twenty posts. Five categories. One method.
I started this site to do one thing: read games backward. To take the felt experiences that players report—the weight, the tension, the confusion, the drag—and trace them back to the hidden variables that produce them. To treat numbers as evidence, not as substitutes for experience. To show the machinery behind what players already felt.
The method isn't perfect. It's messy, iterative, and often wrong. But it's honest—it admits what it can see and what it can't, what it knows and what it only suspects.
The cat is still asleep on the windowsill. The afternoon light is fading. The notes are spread across the desk—index cards, screenshots, spreadsheets, half-finished hypotheses. Tomorrow I'll start the next phase. More investigations. More tests. More readings, backward and forward.
But for now, I'm just grateful. Grateful to have a quiet house, a patient cat, and a method that lets me keep asking the question:
Why does this feel the way it does?
This concludes the launch content roadmap. The next phase begins next week: deeper investigations, reader questions, and a few surprises. Thank you for reading.
— The Architect
No entries yet — sign the first.