If the default grammar of contemporary 2D platformers still means “tune the feel by hand, leave momentum to Rigidbody2D, hand collision to a CharacterController, then write in the post that it took forever to feel like Sonic,” then the moment Trent Brew (u/trentbrew) packaged the Sonic Retro *Sonic Physics Guide* into an offline Markdown repository and dropped it into r/gamedev on 21 September 2026 nearly flips that script in public: classic Mega Drive *Sonic* feel was never an art-direction “vibe.” It was a discrete simulation you can check frame by frame.
That sentence can sound like a nostalgia manifesto. What gives it weight is the spec table nailed into the repo—1 pixel = 256 subpixels; angles on a hex ring from 0–255; six sensor feet (A/B ground, C/D ceiling, E/F walls) that rotate through four collision modes around loops; ground speed below about 2.5 px/frame triggering a slip off steep slopes; frame order written as Player → Objects → Collision → Camera → V-INT. Once numbers pin the rhetoric, “feel” becomes, for the first time, auditable, reproducible, and deliverable to an indie team as a system.
The image that runs through this essay is those six feet on the loop. They are not ornaments of character art. They are the measuring instruments of the whole momentum world: which 16×16 solid block a foot finds, which angle byte it reads, which of Floor / Right Wall / Ceiling / Left Wall modes repositions the probes—those choices decide whether you hold the inner curve of Green Hill or fall off the wall in a way that “looks like Sonic” while the math drifts.
1. The Default Logic: Feel Equals Atmosphere, Momentum Equals Engine Interpolation
The industry default is clean—and therefore lazy.
Building a 2D platformer, teams usually open a familiar menu: give the rigid body some gravity and friction, tune jump impulse until it “feels good,” collide with capsules or boxes, and trust continuous collision detection to stop wall tunneling. Unity’s CharacterController / Rigidbody2D, Godot’s CharacterBody2D, and countless “platformer controller” assets all automate the triad of “can stand, can jump, won’t snag on seams.” Players have learned to read momentum platformers in the same vocabulary—“nice feel,” “kinda Sonic,” “missing a bit of inertia.” That mutual understanding turns “feel” into a forgivable atmosphere word: it sounds professional and almost cannot be reproduced.
Classic Genesis *Sonic* is one of the hardest titles for that grammar to absorb: 360° loops, slope acceleration, wall and ceiling adhesion, sticking to brick faces at high speed without clipping. It was aimed not at a general-purpose physics engine’s variable timestep, but at fixed-point additions once per frame at NTSC 60 Hz. Stuffing that experience into a “tweak friction for a few days and trust your gut” workflow almost automatically triggers the industry instinct for vibe-tuning.
Trent’s public repository refuses that shortcut. The README is plain: this is an unofficial derivative reformatting of the community-maintained *Sonic Physics Guide* on Sonic Retro—wiki markup converted to Markdown, diagrams and cross-links localized for offline reading and implementation. Note the wording—what is being protected is not brand nostalgia for one fangame, but whether feel can still be *accurately described*. Once description is accurate, atmosphere words lose their hiding place.
This is where default logic and production ethics diverge. Atmospheric feel asks: twist friction a little more—does it feel closer? Discrete simulation asks: how many subpixels are acceleration, deceleration, friction, top speed, jump impulse, gravity, and slope factor; do collision probes run before or after the position update; how do sensor coordinates rotate when the mode switches?
2. Smashing the Script: From “Tweaking” to a Six-Sensor State Machine
The sharpest scene in the repo and the original guide is not a nostalgia screenshot but a sensor table that reads like a labor diary: the player carries a fuller probe set than most objects—A and B for ground, C and D for ceiling, E and F for walls; white points mark relative anchors, and the first sensor in each pair inverts X by facing. On flat ground, ceiling probes sleep; once ground angle enters a loop, the whole set rewrites its offsets across four modes: Floor (about 315°–45°), Right Wall (46°–134°), Ceiling (135°–225°), Left Wall (226°–314°). Using Floor mode forever degenerates the game into an ordinary platformer—the guide nails that sentence with a comparison GIF of its own.
The scene can be reconstructed more concretely. Solid blocks carry height masks and angle bytes; both ground feet measure distance to the brick face, the nearer wins, and A wins ties; distance lifts the character out of the ground and writes the winning block’s ground angle. Wall push probes, while grounded, run *before* the position update—current X/Y speed is added to the probe coordinates; on hit, speed is pushed out of the wall and ground speed is zeroed. In air, probes no longer rotate with ground angle; instead four or five activate by air-speed quadrant. Before a jump, the ceiling is asked first: if the nearest distance is under 6 pixels, the jump is abandoned.
The key mechanism appears here: this is not the vague claim “there is collision,” but a six-probe raycast automaton, plus mode hysteresis and asymmetric execution order. The implementation guide puts three fatal traps on one page—multiplying by variable deltaTime wrecks the constant tables; wrong probes at high speed tunnel walls; concave mode switches without hysteresis twitch on curves. The industry default outsources “physics” to a general solver; Genesis *Sonic* welds physics back onto one decision chain—every per-frame addition you change must be checked against whether it still serves the same loop dash.
3. Numbers Pin the Rhetoric: Subpixels, the Constants Table, and “Slip Below 2.5”
Without a spec table, a discrete-simulation narrative slides into empty talk. The quick-reference tables in the Sonic Retro guide and Trent’s README pin the rhetoric back to verifiable ground.
Origin is top-left; collision tests discard subpixels and keep whole pixels; angle 0 faces right, 64 down, 128 left, 192 up (Genesis hex, clockwise). Common Sonic 1/2/3&K constants read like a parts list: `acc` 0x000C (12 subpixels, ~0.046875 px/frame), `dec` 0x0080 (0.5 px/frame), `frc` matching acceleration while coasting, `top` 0x0600 (6.0 px/frame on flat), `jmp` 0x0680 (6.5 px/frame; Knuckles 0x0600), `grv` 0x0038 (~0.21875 px/frame), `slp` 0x0020 (0.125 px/frame). Underwater values are halved or lower on a parallel table.
The sharper number comes from slope physics: when ground angle sits in the fall range and absolute ground speed is under 2.5 (2 pixels and 128 subpixels), the player slips—ungrounds, zeros ground speed (Sonic 3 onward uses conditional slide), and locks directional input for about 30 frames. That stops slow ceiling walking and endless gradual climbs on steep faces. Main-loop order is equally unromantic: player control interleaved with the player’s own collisions, then object routines, object–player collision, camera, then V-INT. High-speed wall clips often fail not because “the box is too small,” but because the probe was placed in the wrong half of the frame.
The narrative force of these numbers is not their retro charm but their refusal to pretend. They do not manufacture unreproducible authority with “tune until it feels right,” and they do not exempt loop scenes from the promise. Loops are exactly where mode switches, slope factor, and sensor rotation stack their cost—nailing the target there admits publicly that the experience worth protecting happens in the loudest, fastest seconds, not in a title-screen jog.
4. Feedback: Offline Docs Force Implementability Back into Indie Pipelines
The most interesting coda is not another fangame wiki, but reverse flow into today’s toolchains.
What Trent did looks clumsy: scrape, restructure, localize images and cross-links, attach an implementation chapter and an AI-agent prompt blueprint, and mark under GFDL that the text comes from Sonic Retro, that diagrams may carry their own terms, and that sprites remain Sega’s. Clumsy, because it cannot be replaced by “watching two tutorial videos”; expensive, because it consumes real reading and cross-checking, not merely engine defaults. The repository was created on 2026-09-21 (the same day as the r/gamedev post), turning pages once scattered on info.sonicretro.org into a suite you can clone, open offline, and implement file by file. The images/ directory lands a hundred-plus technical diagrams and GIFs—sensors, height masks, mode switches, slip ranges—so that “feel” stands, for the first time, where a screenshot can audit it.
This nearly rewrites where “feel references” sit in indie development. Momentum platformers were often treated as a downstream of art and tweaking—build the level, then twist friction until it is “a bit Sonic.” Trent turns the story: the boundary of classic feel becomes a stress bench that forces you to write deterministic systems before you talk presentation. Optimization stops being one-way plugin stacking and becomes shared language learning across engines—GameMaker, Godot, hand-rolled C++, all reading the same constant table.
For indie teams the feedback is especially sharp, and especially useful. You need not ship a legal Sonic clone, but you almost certainly keep your own “already good enough” list: some Rigidbody friction, some `* deltaTime`, some collision order never written down, some “feels nice” comment far past the target feel. Momentum platformers on Steam and loop stages in game jams are often where you first see how arrogant that list is. The public repo admits that “close enough” on a modern engine is often an illusion in front of fixed-point subpixels and six probes.
Closing: Independence and Craft Redefined by Auditable Feel
Put this guide back into a 2026 production floor and what it really strikes is not the empty claim “Unity cannot do Sonic,” but a quieter production laziness—assuming platform differences can be smoothed by a general rigid body, assuming feel is a two-week polish pass before ship, assuming players will forgive “kinda like it” when the momentum world is no longer the same.
The counterexample from Sonic Retro contributors and Trent’s offline restructure is clumsy and expensive: subpixels and hex angles, six sensors and four modes, a 2.5 px/frame slip threshold, an explicit frame order, GFDL attribution, and a hundred-plus original diagrams. Clumsy, because it demands you write feel as a state machine; expensive, because it spends real implementation decisions, not five-star plugin reviews.
So “indie” and “craft” can be redefined here. Indie need not mean refusing the classics; it can mean still asking, when resources are tight, what the minimal non-negotiable set of momentum rules is. Craft need not mean stacking features; it can mean rewriting collision for that minimal set—even if the rewrite looks like reconciling with 1991 assembly.
The executable notes are short and honestly harsh:
- Write your “Sonic-feel” list first: which three rules, once deformed, kill the loop (e.g. fixed 60 Hz ticks, pre/post position probe order, slope slip threshold); they hold veto power during implementation.
- Run a control experiment on your target engine—“turn off general rigid bodies; keep kinematics + hand-written probes”—not to ban physics engines forever, but to see which frames interpolation steals.
- When you change movement, regress sensor geometry, mode switching, and main-loop order together; speed tables and collision must pass in the same commit.
- Mark the cleaner patterns the guide forces (fixed-point subpixels, hex angles, explicit frame order) as candidates to flow back into your main platform controller, not as “retro-only junk code.”
The repo is there: github.com/trentbrew/sonic-physics-guide; the authoritative original remains info.sonicretro.org/Sonic_Physics_Guide. Before you twist the friction slider again, the production floor has already said the audit standard out loud: not “does it look like,” but “is it still the momentum you can reproduce frame by frame.”
Xiaoguang
Sources & Further Reading
GitHub: trentbrew/sonic-physics-guide (created 2026-09-21; README constants, full docs/, images/)
Sonic Retro original: Sonic Physics Guide (GFDL text; community-maintained)
- Key repo pages: `docs/06-slope-collision.md`, `docs/09-slope-physics.md`, `docs/12-main-game-loop.md`, `docs/23-implementation-guide.md`