もし現代の2Dプラットフォーマーの既定文法が、いまなお「手触りはパラメーター調整、運動量は Rigidbody2D、衝突は CharacterController に任せ、投稿には『ソニックっぽくなるまで長く調律した』と書く」ことだとすれば、Trent Brew（u/trentbrew）が 2026年9月21日に Sonic Retro の『Sonic Physics Guide』をオフライン用 Markdown リポジトリへ編成し、r/gamedev へ投げ込んだ瞬間は、その台本を公衆の面前で裏返す行為に近い。クラシック Mega Drive『ソニック』の手触りは、アートディレクション上の「感覚」ではなかった。フレームごとに突合できる離散シミュレーションだった。
その一文は懐古の宣言にも聞こえる。重みを与えるのは、リポジトリに釘付けされた仕様表だ——1ピクセル＝256サブピクセル、角度は 0–255 の十六進リング、六本のセンサー足（A/B 地面、C/D 天井、E/F 壁）が四つの衝突モードでループに合わせて回転すること、地面速度が約 2.5 ピクセル/フレームを下回ると急斜面から滑落すること、フレーム順序が Player → Objects → Collision → Camera → V-INT と書かれていること。数字が修辞を押し留めたとき、「手触り」は初めて監査可能で、再現可能で、インディーチームへシステムとして引き渡せるものになる。
本稿を貫くイメージは、ループ上のその六本の足だ。それらはキャラクター絵の飾りではない。運動量世界全体の計測器である。どの 16×16 固体ブロックを足が踏むか、どの角度バイトを読むか、Floor / Right Wall / Ceiling / Left Wall のどのモードでプローブが再配置されるか——それが、グリーンヒルの内周に貼り付いて駆け抜けるのか、「見た目は近いが計算は漂う」落ち方をするのかを決める。
一、既定論理：手触りは雰囲気、運動量はエンジン補間
業界の既定論理はきれいだ。だから怠惰でもある。
2D プラットフォーマーを作るとき、チームは見慣れたメニューを開く。剛体に重力と摩擦を与え、ジャンプ衝動を「気持ちいい」まで調え、カプセルや箱で地面に当て、連続衝突検出で壁抜けを防ぐ。Unity の CharacterController / Rigidbody2D、Godot の CharacterBody2D、無数の「プラットフォーマー・コントローラー」資産は、「立てる・跳べる・隙間に噛まない」の三点を自動化してくれる。プレイヤーも同じ語彙で運動量プラットフォーマーを読むようになった——「手触りが良い」「ソニックっぽい」「慣性がもう少し」。この暗黙の合意が、「手触り」を赦されうる雰囲気語にする。専門的に聞こえ、ほとんど再現できない。
クラシック Genesis『ソニック』は、その文法が最も吞み込みにくい作品の一つだ。360° ループ、斜面加速、壁と天井への貼り付き、高速でもレンガ面に沿いながら貫通しないこと。それは汎用物理エンジンの可変タイムステップではなく、NTSC 60 Hz でフレームごとに一度行う固定小数点の加減算を狙っていた。その体験を「摩擦を数日弄って勘を信じる」作業へ押し込むと、業界の直感はほぼ自動的に「雰囲気調律」へ向かう。
Trent の公開リポジトリはその近道を拒む。README は率直だ。これは Sonic Retro コミュニティが維持する『Sonic Physics Guide』の非公式な派生再編——wiki マークアップを Markdown へ変換し、図と相互リンクをローカライズし、オフラインでの閲覧と実装を可能にするものだ。言い回しに注意してほしい。守られているのは特定ファンゲームのブランド連想ではなく、「手触りがなお正確に記述できるか否か」である。記述が正確になれば、雰囲気語は逃げ場を失う。
ここで既定論理と制作倫理が分岐する。雰囲気としての手触りは問う——摩擦をもう少し捻れば近づくか。離散シミュレーションは問う——加速度・減速度・摩擦・最高速・ジャンプ初速・重力・斜面係数はそれぞれ何サブピクセルか、衝突プローブは位置更新の前か後か、モード切替時にセンサー座標はどう回転するか。
二、台本を砕く：「調律」から六センサー状態機械へ
リポジトリと原ガイドで最も刺さる場面は、懐古スクリーンショットではなく、労働日誌のようなセンサー表だ。プレイヤーは通常オブジェクトより多いプローブ一式を持つ——A・B が地面、C・D が天井、E・F が壁押し。白い点が相対アンカーを示し、各組��第一センサーは向きに応じて X を反転する。平坦な地面では天井プローブは休眠し、地面角がループに入ると、四モードでオフセット全体が書き換わる。Floor（約 315°–45°）、Right Wall（46°–134°）、Ceiling（135°–225°）、Left Wall（226°–314°）。Floor モードだけを永遠に使えば、ゲームは普通のプラットフォーマーへ退化すると、ガイド自身が対照 GIF で釘を刺している。
場面はさらに具体的に復元できる。固体ブロックは高さマスクと角度バイトを持ち、両地面足がレンガ面までの距離を測り、近い方が勝ち、同距離なら A 優先。距離はキャラクターを地面から押し出し、勝ったブロックの地面角を書き込む。着地中の壁プッシュは位置更新の*前*に起きる——現在の X/Y 速度がプローブ座標に加算され、当たれば速度を壁から押し出し、地面速度をゼロにする。空中ではプローブは地面角に合わせて回転せず、空中速度の象限で四〜五本が有効になる。ジャンプ前には天井を先に問う。最近距離が 6 ピクセル未満なら、起跳そのものを諦める。
ここで核心機構が姿を現す。これは「衝突がある」という曖昧さではなく、六プローブのレイキャスト・オートマトンであり、モードのヒステリシスと実行順序の非対称を伴う。実装ガイドは致命的な罠を一頁に並べる——可変 deltaTime による速度乗算は定数表を壊し、高速時の誤ったプローブは壁抜けを許し、凹面でのモード切替に遅滞がなければカーブで痙攣する。業界既定は「物理」を汎用ソルバへ外注する。Genesis『ソニック』は物理を一本の意思決定鎖へ溶接し直す——あなたが変える毎フレームの加算は、同じループ疾走になお奉仕しているかを振り返って照合されねばならない。
三、数字が修辞を押さえる：サブピクセル、定数表、そして「2.5 未満で滑る」
仕様表がなければ、離散シミュレーションの物語は空論へ滑る。Sonic Retro ガイドと Trent の README にあるクイック参照表は、修辞を検証可能な地面へ釘付けする。
原点は左上。衝突テストはサブピクセルを捨て、整数ピクセルだけを認める。角度 0 は右、64 は下、128 は左、192 は上（Genesis 十六進、時計回り）。Sonic 1/2/3&K の常用定数は部品表のように書かれる。`acc` 0x000C（12 サブピクセル、約 0.046875 px/frame）、`dec` 0x0080（0.5 px/frame）、`frc` は惰性時に加速度と同値、`top` 0x0600（平坦で 6.0 px/frame）、`jmp` 0x0680（6.5 px/frame；Knuckles は 0x0600）、`grv` 0x0038（約 0.21875 px/frame）、`slp` 0x0020（0.125 px/frame）。水中は別表で半減またはさらに低い。
より尖った数字は斜面物理から来る。地面角が滑落区間にあり、地面速度の絶対値が 2.5（2 ピクセルと 128 サブピクセル）未満なら、プレイヤーは滑る——着地解除、地面速度ゼロ（Sonic 3 以降は条件付き滑走）、方向入力を約 30 フレームロック。これにより天井をゆっくり歩けず、急斜面を永遠に這い上がることもできない。メインループの順序も同様にロマンチックではない。プレイヤー制御と自身の衝突が交錯し、物体ルーチン、物体とプレイヤーの衝突、カメラ、そして V-INT。高速の壁抜けが防ぎにくいのは、しばしば「箱が小さいから」ではなく、プローブがフレームの誤った半側に置かれたからだ。
この数字群の物語力は、そのレトロ趣味ではなく、偽ることを拒む点にある。「手触りが合うまで調えればよい」という再検証不能な権威を捏造せず、ループ場面を約束の外にも置かない。ループこそ、モード切替・斜面係数・センサー回転のコストが重なる場面だ。そこに的を釘付けすることは、守るべき体験が最も騒がしく最も速い数秒に起きると公に認めることに等しい。
四、還流：オフライン文書が強いる実装可能性が、インディーの管線へ戻る
物語で最も興味深い終幕は、別のファン wiki ではなく、現代ツールチェーンへの逆流だ。
Trent の仕事は愚直に見える。スクレイプ、再編、画像と相互リンクのローカライズ、実装章と AI エージェント用プロンプトの添付、そしてテキストが Sonic Retro 由来であること、図には独自の条項がありうること、スプライト著作権はなお Sega にあることを GFDL に沿って明示すること。愚直なのは、「チュートリアル動画を二本見る」では代替できないからだ。高価なのは、エンジン既定部品ではなく、本当の読解と突合を消費するからだ。リポジトリは 2026-09-21 に作成され（r/gamedev 投稿と同日）、かつて info.sonicretro.org に散らばっていた権威ページを、clone でき、オフラインで開け、ファイル順に実装できる文書一式へ変えた。images/ には百枚超の技術図と GIF——センサー、高さマスク、モード切替、滑落区間——が丸ごと着地し、「感覚」が初めてスクリーンショットで監査できる位置に立つ。
これはインディー開発における「手触り参考」の位置をほぼ書き換える。運動量プラットフォーマーはしばしば美術と調律の下流だった——まずステージを作り、摩擦を「少しソニック」まで捻る。Trent は物語をねじる。クラシック手触りの境界がストレステスト台になり、表現層の前に決定論的システムを書かせる。最適化は一方向のプラグイン追加ではなく、エンジン横断の共通言語学習になる——GameMaker も Godot も自前 C++ も、同じ定数表を読む。
インディーと小チームにとって、この還流は特に耳が痛い。同時に特に有用だ。合法なソニック複製を出す必要はない。だが誰もが「もう十分」リストを持っている——ある Rigidbody 摩擦、ある `* deltaTime`、一度も書かれなかった衝突順序、「手触りが良い」という目標から遠いコメント。Steam の運動量作品やゲームジャムのループ面は、そのリストの傲慢さを初めて見せる場所になりがちだ。公開リポジトリは認める。現代エンジン上の「だいたい似ている」は、固定小数点サブピクセルと六本のプローブの前では、しばしば幻覚にすぎない。
結び：独立と制作は、「監査可能な手触り」のなかで再定義される
このガイドを 2026 年の制作現場へ戻すとき、それが本当に打つのは「Unity ではソニックができない」という空言ではなく、より隠微な制作の怠惰だ——プラットフォーム差は汎用剛体で均せると信じ、手触りは発売二週間前の調律だと信じ、プレイヤーが「ちょっと似てる」で「もはや同じ運動量世界ではない」ことを許すと信じること。
Sonic Retro 貢献者と Trent のオフライン再編が示す反例は、愚直で高価だ。サブピクセルと十六進角、六センサーと四モード、2.5 px/frame の滑落閾値、明示されたフレーム順序、GFDL 帰属、百枚超の原図。愚直なのは、感覚を状態機械として書くことを要求するから。高価なのは、プラグイン店の五星ではなく、本当の実装決定を消費するから。
こうして「独立」と「制作」はここで再定義できる。独立はクラシック拒否とイコールである必要はなく、資源が逼迫しても「運動量の最小不可破壊集合は何か」と問い続けることでありうる。制作は機能の積み上げとイコールである必要はなく、その最小集合のために衝突を書き直す意思——たとえ 1991 年のアセンブリと突合しているように見えても——でありうる。
実行可能な指針は短いが、十分に辛辣で正直だ。
- まず「Sonic 感」リストを書く。どの三規則が変形したらループが死ぬか（例：固定 60 Hz ステップ、着地前後のプローブ順序、斜面滑落閾値）。実装時、それらに拒否権を与える。
- 対象エンジンで対照実験をする——「汎用剛体を切り、運動学ボディ＋自前プローブだけ残す」。永久に物理エンジンを捨てるためではなく、補間がどのフレームを盗むかを見るためだ。
- 移動実装を変えるとき、センサー幾何・モード切替・メインループ順序を同時に回帰する。速度定数表と衝突は同一コミットで合否を出す。
- ガイドが強いるよりきれいな書き方（固定小数点サブピクセル、hex 角、明示フレーム順序）を候補にし、主力プラットフォーマー・コントローラーへ還流できるか評価する。「レトロ専用のゴミコード」にしない。
リポジトリはそこにある。github.com/trentbrew/sonic-physics-guide。権威ある原文はなお info.sonicretro.org/Sonic_Physics_Guide。次に摩擦スライダーを捻る前に、制作現場は監査基準を言い切っている。問いは「似ているか」ではない。「フレームごとに再現できる、あの運動量のままか」だ。
出典と参考
GitHub：trentbrew/sonic-physics-guide（2026-09-21 作成）
Sonic Retro 原ガイド：Sonic Physics Guide（GFDL）
- リポジトリ内：`docs/06-slope-collision.md`、`docs/09-slope-physics.md`、`docs/12-main-game-loop.md`、`docs/23-implementation-guide.md`