Si la gramática por defecto de las plataformas 2D contemporáneas sigue siendo «afina la sensación a mano, deja el momentum al Rigidbody2D, entrega la colisión a un CharacterController y escribe en el post que tardaste una eternidad en que se sintiera como Sonic», entonces el momento en que Trent Brew (u/trentbrew) empaquetó la *Sonic Physics Guide* de Sonic Retro en un repositorio Markdown offline y la soltó en r/gamedev el 21 de septiembre de 2026 casi vuelca ese guion en público: la sensación clásica de *Sonic* en Mega Drive nunca fue un «vibe» de dirección artística. Fue una simulación discreta que se puede contrastar fotograma a fotograma.
Esa frase puede sonar a manifiesto nostálgico. Lo que le da peso es la tabla de especificaciones clavada en el repo: 1 píxel = 256 subpíxeles; ángulos en un anillo hexadecimal de 0–255; seis pies sensores (A/B suelo, C/D techo, E/F paredes) que rotan por cuatro modos de colisión en los bucles; velocidad de suelo por debajo de unos 2,5 px/frame que dispara el deslizamiento en pendientes fuertes; orden de frame escrito como Player → Objects → Collision → Camera → V-INT. Cuando los números sujetan la retórica, la «sensación» se vuelve, por primera vez, auditable, reproducible y entregable a un equipo indie como sistema.
La imagen que atraviesa este ensayo son esos seis pies en el bucle. No son adornos del arte del personaje. Son los instrumentos de medida de todo el mundo de momentum: qué bloque sólido 16×16 encuentra un pie, qué byte de ángulo lee, cuál de los modos Floor / Right Wall / Ceiling / Left Wall reposiciona las sondas—esas elecciones deciden si te pegas a la curva interior de Green Hill o te caes de la pared de un modo que «parece Sonic» mientras la matemática deriva.
1. La lógica por defecto: sensación igual a atmósfera, momentum igual a interpolación del motor
La lógica industrial por defecto es limpia—y por eso perezosa.
Al hacer una plataforma 2D, los equipos suelen abrir un menú familiar: dar al cuerpo rígido algo de gravedad y fricción, afinar el impulso de salto hasta que «se sienta bien», colisionar con cápsulas o cajas y confiar en la detección continua de colisión para frenar el atravesar paredes. CharacterController / Rigidbody2D de Unity, CharacterBody2D de Godot y un sinfín de assets de «controlador de plataformas» automatizan la tríada «puedo estar de pie, puedo saltar, no me engancho en las costuras». Los jugadores han aprendido a leer las plataformas de momentum con el mismo vocabulario—«buena sensación», «un poco Sonic», «le falta inercia». Ese entendimiento mutuo convierte «sensación» en una palabra atmosférica perdonable: suena profesional y casi no se puede reproducir.
El *Sonic* clásico de Genesis es uno de los títulos más difíciles de absorber para esa gramática: bucles de 360°, aceleración en pendiente, adhesión a muro y techo, pegarse a la cara del ladrillo a alta velocidad sin clipping. No apuntaba al paso de tiempo variable de un motor físico genérico, sino a sumas y restas de punto fijo una vez por frame a 60 Hz NTSC. Meter esa experiencia en un flujo de «toca la fricción unos días y fíate del instinto» dispara casi automáticamente el reflejo industrial de afinar por vibes.
El repositorio público de Trent rechaza ese atajo. El README es claro: es un reformateo derivado no oficial de la *Sonic Physics Guide* mantenida por la comunidad en Sonic Retro—marcado wiki convertido a Markdown, diagramas y cruces localizados para lectura e implementación offline. Nótese la redacción: lo que se protege no es la nostalgia de marca de un fangame, sino si la sensación aún puede *describirse con exactitud*. Cuando la descripción es exacta, las palabras atmosféricas pierden escondite.
Aquí divergen la lógica por defecto y la ética de producción. La sensación atmosférica pregunta: ¿si tuerzo un poco más la fricción, se acerca? La simulación discreta pregunta: ¿cuántos subpíxeles son aceleración, deceleración, fricción, velocidad tope, impulso de salto, gravedad y factor de pendiente; las sondas de colisión corren antes o después de actualizar la posición; cómo rotan las coordenadas del sensor al cambiar de modo?
2. Romper el guion: de «afinar» a una máquina de estados de seis sensores
La escena más punzante del repo y de la guía original no es una captura nostálgica, sino una tabla de sensores que lee como diario de taller: el jugador lleva un juego de sondas más completo que la mayoría de objetos—A y B para el suelo, C y D para el techo, E y F para las paredes; puntos blancos marcan anclas relativas, y el primer sensor de cada par invierte X según la orientación. En suelo plano, las sondas de techo duermen; cuando el ángulo de suelo entra en un bucle, todo el juego reescribe sus offsets en cuatro modos: Floor (unos 315°–45°), Right Wall (46°–134°), Ceiling (135°–225°), Left Wall (226°–314°). Usar solo Floor para siempre degenera el juego en una plataforma ordinaria—la propia guía clava esa frase con un GIF de contraste.
La escena se puede reconstruir con más detalle. Los bloques sólidos llevan máscaras de altura y bytes de ángulo; ambos pies de suelo miden la distancia a la cara del ladrillo, gana el más cercano y A gana los empates; la distancia saca al personaje del suelo y escribe el ángulo del bloque vencedor. Las sondas de empuje de pared, en suelo, corren *antes* de actualizar la posición—se suma la velocidad X/Y actual a las coordenadas de la sonda; al golpear, se empuja la velocidad fuera de la pared y se pone a cero la velocidad de suelo. En el aire, las sondas ya no rotan con el ángulo de suelo; se activan cuatro o cinco según el cuadrante de la velocidad aérea. Antes de saltar se pregunta primero al techo: si la distancia más cercana es menor de 6 píxeles, se abandona el salto.
Aquí aparece el mecanismo clave: no es la afirmación vaga de «hay colisión», sino un autómata de raycast de seis sondas, más histéresis de modo y orden de ejecución asimétrico. La guía de implementación pone tres trampas fatales en una página—multiplicar por deltaTime variable destroza las tablas de constantes; sondas incorrectas a alta velocidad atraviesan paredes; cambios de modo en cóncavos sin histéresis estremecen en las curvas. La industria por defecto externaliza la «física» a un solver general; el *Sonic* de Genesis suelda la física de nuevo a una sola cadena de decisión—cada suma por frame que cambias debe contrastarse con si sigue sirviendo al mismo dash de bucle.
3. Los números sujetan la retórica: subpíxeles, la tabla de constantes y «resbalar por debajo de 2,5»
Sin tabla de especificaciones, la narrativa de simulación discreta se desliza hacia el vacío. Las tablas de referencia rápida de la guía Sonic Retro y del README de Trent clavan la retórica en suelo verificable.
El origen está arriba a la izquierda; las pruebas de colisión descartan subpíxeles y conservan píxeles enteros; el ángulo 0 mira a la derecha, 64 abajo, 128 a la izquierda, 192 arriba (hex de Genesis, sentido horario). Las constantes habituales de Sonic 1/2/3&K se leen como lista de piezas: `acc` 0x000C (12 subpíxeles, ~0,046875 px/frame), `dec` 0x0080 (0,5 px/frame), `frc` igual a la aceleración al deslizar, `top` 0x0600 (6,0 px/frame en plano), `jmp` 0x0680 (6,5 px/frame; Knuckles 0x0600), `grv` 0x0038 (~0,21875 px/frame), `slp` 0x0020 (0,125 px/frame). Bajo el agua hay una tabla paralela a la mitad o menos.
El número más afilado viene de la física de pendientes: cuando el ángulo de suelo está en el rango de caída y la velocidad de suelo absoluta es menor de 2,5 (2 píxeles y 128 subpíxeles), el jugador resbala—se desengancha del suelo, pone a cero la velocidad de suelo (desde Sonic 3 hay deslizamiento condicional) y bloquea la entrada direccional unos 30 frames. Eso impide caminar despacio por el techo y trepar eternamente una pendiente empinada. El orden del bucle principal es igual de poco romántico: control del jugador entrelazado con sus propias colisiones, luego rutinas de objetos, colisión objeto–jugador, cámara y V-INT. Los clips de pared a alta velocidad suelen fallar no porque «la caja sea pequeña», sino porque la sonda se colocó en la mitad equivocada del frame.
La fuerza narrativa de estos números no está en su encanto retro, sino en su negativa a fingir. No fabrican autoridad irreproducible con «afina hasta que se sienta bien», ni excluyen las escenas de bucle de la promesa. Los bucles son exactamente donde el cambio de modo, el factor de pendiente y la rotación de sensores apilan su coste—clavar la diana ahí admite en público que la experiencia que merece protección ocurre en los segundos más ruidosos y rápidos, no en un trote de pantalla de título.
4. Retorno: la documentación offline fuerza implementabilidad de vuelta a las tuberías indie
El coda más interesante no es otra wiki de fans, sino el flujo inverso hacia las herramientas de hoy.
Lo que hizo Trent parece torpe: raspado, reestructuración, localización de imágenes y cruces, un capítulo de implementación y un blueprint de prompt para agente de IA, y marcar bajo GFDL que el texto viene de Sonic Retro, que los diagramas pueden tener términos propios y que los sprites siguen siendo de Sega. Torpe, porque no se reemplaza con «ver dos tutoriales»; caro, porque consume lectura y contraste reales, no solo componentes por defecto del motor. El repositorio se creó el 2026-09-21 (el mismo día del post en r/gamedev), convirtiendo páginas antes dispersas en info.sonicretro.org en un paquete que se puede clonar, abrir offline e implementar archivo a archivo. El directorio images/ aterriza más de cien diagramas técnicos y GIFs—sensores, máscaras de altura, cambios de modo, rangos de resbalón—para que la «sensación» se sitúe, por primera vez, donde una captura puede auditarla.
Esto casi reescribe el lugar de las «referencias de sensación» en el desarrollo indie. Las plataformas de momentum se trataban a menudo como valle abajo del arte y el afine—construye el nivel, luego tuerce la fricción hasta que sea «un poco Sonic». Trent gira la historia: el límite de la sensación clásica se vuelve banco de estrés que te obliga a escribir sistemas deterministas antes de hablar de presentación. La optimización deja de ser apilar plugins en un solo sentido y se convierte en aprendizaje de lenguaje común entre motores—GameMaker, Godot, C++ propio, todos leyendo la misma tabla de constantes.
Para equipos indie el retorno es especialmente duro, y especialmente útil. No hace falta publicar un clon legal de Sonic, pero casi seguro guardas tu lista de «ya es suficiente»: cierta fricción de Rigidbody, cierto `* deltaTime`, cierto orden de colisión nunca escrito, cierto comentario de «se siente bien» lejos de la sensación objetivo. Las plataformas de momentum en Steam y los bucles en game jams suelen ser donde ves por primera vez lo arrogante que es esa lista. El repo público admite que «bastante parecido» en un motor moderno suele ser una ilusión frente a subpíxeles de punto fijo y seis sondas.
Cierre: independencia y oficio redefinidos por una sensación auditable
Devuelve esta guía a un suelo de producción de 2026 y lo que realmente golpea no es la frase vacía «Unity no puede hacer Sonic», sino una pereza de producción más discreta—asumir que las diferencias de plataforma se alisanan con un cuerpo rígido general, que la sensación es un pase de dos semanas antes del lanzamiento, que los jugadores perdonarán «se parece un poco» cuando el mundo de momentum ya no es el mismo.
El contraejemplo de los contribuyentes de Sonic Retro y del reorden offline de Trent es torpe y caro: subpíxeles y ángulos hex, seis sensores y cuatro modos, umbral de resbalón de 2,5 px/frame, orden de frame explícito, atribución GFDL y más de cien diagramas originales. Torpe, porque exige escribir la sensación como máquina de estados; caro, porque gasta decisiones reales de implementación, no reseñas de cinco estrellas en la tienda de plugins.
Así «indie» y «oficio» pueden redefinirse aquí. Indie no tiene que significar rechazar los clásicos; puede significar seguir preguntando, con recursos escasos, cuál es el conjunto mínimo no negociable de reglas de momentum. Oficio no tiene que significar apilar funciones; puede significar reescribir la colisión por ese conjunto mínimo—aunque el reescrito parezca reconciliarse con el ensamblador de 1991.
Las notas ejecutables son cortas y honestamente severas:
- Escribe primero tu lista de «sensación Sonic»: qué tres reglas, al deformarse, matan el bucle (p. ej. ticks fijos a 60 Hz, orden de sondas antes/después de la posición, umbral de resbalón); en la implementación tienen veto.
- Haz un experimento de control en tu motor objetivo—«apaga cuerpos rígidos generales; deja cinemática + sondas escritas a mano»—no para prohibir motores físicos para siempre, sino para ver qué frames se roba la interpolación.
- Al cambiar el movimiento, regresa juntos geometría de sensores, cambio de modo y orden del bucle principal; tablas de velocidad y colisión deben pasar en el mismo commit.
- Marca los patrones más limpios que fuerza la guía (subpíxeles de punto fijo, ángulos hex, orden de frame explícito) como candidatos a devolver a tu controlador principal de plataformas, no como «código basura solo retro».
El repo está ahí: github.com/trentbrew/sonic-physics-guide; el original autoritativo sigue en info.sonicretro.org/Sonic_Physics_Guide. Antes de volver a torcer el deslizador de fricción, el suelo de producción ya ha dicho en voz alta el criterio de auditoría: no «¿se parece?», sino «¿sigue siendo el momentum que puedes reproducir fotograma a fotograma?».
Xiaoguang
Fuentes y lectura adicional
GitHub: trentbrew/sonic-physics-guide (creado 2026-09-21)
Original Sonic Retro: Sonic Physics Guide (texto GFDL)
- Páginas clave: `docs/06-slope-collision.md`, `docs/09-slope-physics.md`, `docs/12-main-game-loop.md`, `docs/23-implementation-guide.md`