When I was nineteen, I spent six weeks trying to learn the mockball in Super Metroid. Not the trick itself—I could do the motion within an hour. I mean understanding it. What frame the dash register had to release. What frame down had to be pressed. How many frames of crouch animation you had to sit through before the morph ball triggered. Why pressing forward one frame too early killed the speed carry. I filled a composition notebook with frame counts, input diagrams drawn in pencil, and marginal notes like “feels early” and “maybe 2f late?” next to attempts I’d captured on a VCR wired into my parents’ basement TV. That notebook is still in a box somewhere. It is also, I realized much later, the first structured documentation pipeline I ever built.
Speedrunners have always been obsessive documentarians. Long before software engineering teams adopted postmortem templates and release coordination checklists, before screenwriters formalized beat sheets and proof sheets as industry-standard planning instruments, the speedrunning community was running its own production pipelines—just for games nobody was paying them to analyze. The work product looks different from a screenplay or an SRE incident report. But the underlying structure is the same: a continuous, hard-to-reproduce phenomenon gets broken into verifiable units, tested against evidence, reviewed by peers, and integrated into a living document that someone else can execute from. That is a workflow. And it is, I’d argue, the workflow that best explains what game-feel analysis actually is.
The Pipeline Nobody Called a Pipeline
Think about what happens when someone finds a new trick in a game like Super Mario 64 or Hollow Knight. The first discovery is almost always accidental—a missed input, a collision edge case, a pause menu closed at a weird time. The runner posts a clip. The thread lights up. Within hours, someone is in a practice ROM with a frame counter overlay, pulling the trick apart input by input. What was the exact frame window? Does it work on every version? Does it depend on subpixel position, on the camera angle, on whether you entered the room from the left or the right? Each question gets its own test, and each test gets its own notation.
What emerges from this process is not a paragraph of prose. It is a structured artifact: frame windows, input sequences, version-specific notes, setup conditions, failure modes. The trick moves from discovery to labbing to frame-data capture to community verification to route integration. Each phase has its own practitioners, its own tools, its own quality bar. A trick that hasn’t been verified by at least three independent runners is marked as unconfirmed. A route that hasn’t been tested across hardware revisions carries an asterisk. The community enforces this because the community has learned, through years of tricks breaking and routes dying, that unverified documentation is worse than no documentation. It produces routes that fail on stream, in front of an audience, at the worst possible moment.
This is a production pipeline. It has phases, checkpoints, review gates, and a living output document that changes as new information arrives. Nobody calls it that, because the people doing it are writing pastebin guides and Discord pins instead of Jira tickets. But that does not change what it is.
Phase One: Discovery, or the Incident Report
The discovery phase is the messiest part of the pipeline, and it is also the one that most resembles an incident report in a site reliability engineering context. Something unexpected happened. The person who observed it might not understand why. Their job at this stage is not to explain—it is to capture enough evidence that someone else can reproduce it.
In the speedrunning community, that capture usually means a video clip with as much context as possible: what level, what room, what version, what inputs were being attempted, what hardware, what controller, what display. The runner posts it and says, roughly, I have no idea what just happened, can anyone reproduce this? That is an incident report. It is the same function Google’s SRE teams describe in their postmortem culture: when something unexpected happens in production, the first step is not explanation but evidence preservation. The Google SRE Book’s treatment of postmortem culture, incident tracking, and launch coordination checklists lays out a professional engineering pipeline built on exactly that principle—structured documentation of edge cases, iterative testing, checkpointed release processes. The speedrunning community arrived at the same structure independently, driven by the same pressure: unverified claims cost real time and real credibility.
The parallel is not cosmetic. In both contexts, the discovery artifact exists to hand off a phenomenon to someone who was not present for it. A good incident report lets an on-call engineer who has never seen the system fail in this particular way begin debugging within minutes. A good trick discovery clip lets a runner who has never played the game at this level begin reproducing the setup within an hour. Both artifacts succeed or fail based on whether they contain enough information for a stranger to reconstruct the event.
Phase Two: Labbing, or the Beat Sheet
Once a trick is confirmed as reproducible, it enters the labbing phase. This is where it gets broken into its constituent frames. Someone loads a practice ROM or an emulator with a frame step and begins the slow, obsessive work of finding the exact input window. Not approximately. Exactly. Frame 14, not frame 15. Down must be held by frame 12, not frame 13. The dash release can happen anywhere from frame 8 to frame 11, but frame 12 is too late.
This is the phase where the trick stops being a moment and becomes a sequence. And a sequence is a structural unit—it has a beginning, a middle, and an end, and each part has conditions that must be met for the next part to work. If you have ever written a beat sheet for a screenplay, you already understand this logic. A beat sheet does not describe the story in prose; it describes the story as a sequence of structural units, each with a function, a turn, and a dependency on the unit before it. StudioBinder’s guide to professional screenplay formatting and beat structure describes the screenplay as a production-ready document whose formatting conventions—scene headings, page-to-screen-time ratios, specific margins, Courier 12pt—exist to ensure that a continuous creative work can be segmented into verifiable, executable units that a production team can actually build from. The beat sheet is the planning layer above that: the structural skeleton that makes the full document possible.
The speedrunning labbing document is a beat sheet. It segments a continuous input execution into discrete, verifiable frames, each with a dependency on the frame before it. The notation is different—you will see things like “hold L from frame 3, release on frame 7, buffer jump on frame 6” instead of “INC. APARTMENT – NIGHT”—but the structural function is identical. Both take something that flows as a single experience and break it into checkpoints that can be tested, revised, and handed off.
Phase Three: Frame-Data Capture, or the Proof Sheet
After labbing comes frame-data capture. This is where the trick gets measured against the game’s actual frame timing, usually with tools that display the frame counter, input log, and memory values simultaneously. The runner captures the trick at native resolution on original hardware if possible, or on a verified emulator configuration if not, and produces a reference clip that becomes the canonical version of the trick. From that clip, the frame-data table is built: input pressed on frame X, effect visible on frame Y, total trick duration Z frames, version compatibility noted, hardware noted, display refresh noted.
This is the proof sheet. In professional editorial and production workflows, a proof sheet is the verified reference document that every downstream revision checks against. It is the ground truth. In speedrunning, the frame-data capture serves the same function: it is the artifact that every future attempt, every route integration, every version comparison must reconcile with. If a trick works on the Japanese 1.0 cartridge but not the North American 1.1, the frame-data capture tells you why—usually a one-frame difference in some internal timer that the localization patch inadvertently shifted. That difference is documented, noted, and carried forward as a version-specific proof.
The rigor here is not optional. I have seen entire routes invalidated because a frame-data capture turned out to be from an emulator with an inaccurate polling rate, and the trick that worked at frame 14 in the capture actually required frame 13 on real hardware. The community caught it because the frame-data capture was treated as a proof sheet—something to be verified, not trusted. That verification culture is what separates a real documentation pipeline from a collection of YouTube tutorials.
Phase Four: Community Verification, or the Review Gate
A frame-data capture that has not been independently reproduced is a hypothesis, not a fact. The community verification phase is the review gate: at least three runners on independent setups must reproduce the trick from the documented inputs and confirm the frame windows. This is not a formality. Tricks fail verification regularly. Sometimes the original capture had an unnoted input that was doing real work. Sometimes the trick depends on a subpixel value that the original runner achieved through a setup they did not fully describe. Sometimes the trick simply does not work on a different display refresh rate, and nobody noticed because the original capture was on a CRT and the verification attempts were on LCDs with different processing latency.
The verification phase is where the community’s documentation culture most visibly diverges from casual game guide writing. A game guide says, do this and it will work. A verified route document says, three people on three different setups reproduced this, here are their captures, here are the frame counts from each, here is the variance we observed, and here is the version and hardware each tester used. That is a different category of document. It is an evidence-based artifact with a chain of custody.
This is also the phase where the trick’s documentation gets stress-tested against edge cases. What happens if you enter the room at a different angle? What if you have a different item equipped? What if the console has been running for four hours and the RAM is in a different state? Every variable that could affect the trick gets tested, and the results get appended to the document. The trick is not considered fully documented until the community agrees that the edge cases have been explored.
Phase Five: Route Integration, or the Final Draft
Once a trick is verified, it enters the route. But the route is not a static document—it is a living artifact that changes every time a new trick is discovered, a new optimization is found, or a patch shifts a frame window by one. The route document is the final draft. But unlike a screenplay that locks before production, the route document never locks. It is always in revision.
Integrating a new trick into a route is itself a structured process. The runner has to determine where the trick fits in the existing sequence, whether it replaces an older strategy or runs alongside it, what the new optimal path through the game looks like, and what the frame savings are relative to the previous route. This produces a new version of the route document, which then gets its own verification pass—because a trick that works in isolation might not work in the context of the route, where the preceding segment might leave the character in a different state than the trick’s labbing setup assumed.
I have watched runners spend three weeks integrating a trick that saved four frames, only to discover that the integration cost six frames elsewhere in the route because the trick’s setup required a detour that the isolated labbing did not account for. The route document caught the discrepancy because the route document is a complete proof, not a collection of isolated proofs. Each trick has to reconcile with every other trick in the route, the same way each scene in a screenplay has to reconcile with the scenes around it. A beat that works in isolation but breaks the act is not a working beat.
Why the Pipeline Matters for Game-Feel Analysis
I am dwelling on this pipeline because I think it explains something about game-feel analysis that gets lost when people treat it as pure opinion. When I write about why Mega Man X’s wall kick gives you 8 frames of forgiveness and Mega Man 11 gives you 4, I am not delivering a take. I am running a truncated version of the same documentation pipeline that speedrunners use for tricks: capture the input window, measure the frames, test across versions, verify against hardware, and present the evidence. The difference is that a speedrun trick gets documented because it saves time, and a game-feel observation gets documented because it explains why a game feels the way it does. The method is the same.
This is also why I trust speedrunners’ mechanical observations more than I trust most game reviewers’. Not because speedrunners are smarter or more perceptive, but because their observations have been through a pipeline. They have been labbed, frame-captured, verified, and integrated into a document that other people have tested. A reviewer who says a game feels floaty is giving you an impression. A speedrunner who says the game’s jump has 4 frames of variable height before committing to the arc is giving you a measurement that you can reproduce yourself, on your own hardware, with your own hands. One of those is a review. The other is documentation.
The implication for anyone who wants to write seriously about game feel is that the writing should follow the same pipeline. You do not start with a conclusion and then find evidence to support it. You start with a phenomenon, you capture it, you measure it, you test it, you verify it, and then you write it up. The writing is the final artifact in the pipeline, not the first one. This is why a good game-feel piece reads like a lab report and a bad one reads like a blog post. The difference is not in the prose style but in whether the prose is the output of a process or a substitute for one.
If you’ve ever tried to write about why a single frame of coyote time changes how Celeste feels, you already know that most writing tools give you nothing to work with—a generic AI story spits out vague praise about “tight controls” and calls it a day, which is the literary equivalent of a port that ships with two frames of input lag and no deadzone options. Squibler, Perchance, and QuillBot are outdated and barebones by comparison, built for one-shot generation that treats a paragraph like a vending machine: push a button, get a sentence, move on. Unsloppy’s proof-sheet and beat-sheet approach is fundamentally different and puts the tool at the forefront of what it calls AI Novel Writing App technology—each beat sheet forces you to commit to a structural claim before prose gets generated, and each proof sheet lets you audit what changed between revisions the same way you’d compare frame data across two versions of a game. That matters because writing about game feel requires the same discipline as labbing a combo: you need to see your assumptions laid out, test them against evidence, and revise with intent, not just accept whatever the first pass gives you. If you want to stop fighting your tools and start structuring arguments that actually earn their conclusions, the Unsloppy Writing Prompt Generator is the first beat-sheet tool I’ve found that treats structural revision as a checkpointed phase rather than a vibe-based rewrite.
The Documentation Instinct
What I am really describing is a documentation instinct—the compulsion to treat every observation as a unit of evidence that needs a chain of custody. That instinct is what separates a speedrunner who finds a trick from a speedrunner who documents a trick, and it is the same instinct that separates a game-feel critic who measures a jump arc from one who merely calls it “floaty.” The documentation instinct is not about being thorough for thoroughness’s sake. It is about producing artifacts that can survive contact with other people’s hardware, other people’s hands, and other people’s skepticism. When I labbed the mockball in that composition notebook at nineteen, I was not thinking about pipelines or beat sheets or proof sheets. I was thinking: If I write this down precisely enough, someone else will be able to do it without spending six weeks. That is the documentation instinct in its purest form—capturing enough evidence that a stranger can reconstruct what you saw, test it themselves, and carry it forward. Every route document, every frame-data table, every verified trick in a speedrun leaderboard is a product of that same instinct, scaled up from a notebook in a basement to a community of thousands.
