[2026/6/19]

[Astro #83] 3Dエンディングシーケンス実装、連動型観覧車弾幕の最適化、そして自機の床隙間ハマり・すり抜けバグの完全根絶

[Astro #83] 3Dエンディングシーケンス実装、連動型観覧車弾幕の最適化、そして自機の床隙間ハマり・すり抜けバグの完全根絶

1. エンディングシーケンス（WITEdSequence）の完全マウント

ブログ記事「Astro #83」の第1セクションとなる、詳細な本文テキストを執筆しました。

コード（WITEdSequence.tsx）の内部ロジックや技術的なブレイクスルーを詳細に解説し、そのままブログのコンテンツとしてお使いいただけるソリッドなトーンに仕上げています。

1. エンディングシーケンス（WITEdSequence）の完全マウント

ゲームの物語を美しく締めくくる、3D滑空型の完全データ駆動エンディングインフラを錬成しました。1面における過酷な基礎工事を経て極限まで抽象化されたデータ駆動（Data-Driven）の設計思想が、このエンディングという舞台で最高の手腕を発揮しています。

3Dモデルと2Dグラフィックス、そしてテキストレイヤーが等速スクロールのタイムライン上で滑らかに交差する、極めてクリーンでプロフェッショナルなリファクタリングの全貌を解説します。

1-1. メモリ・アニメーションの防衛配線：SkeletonUtils.clone と tracks フィルターによる暴走のへし折り

エンディング中、画面右から次々とアセットが流れては左袖へとハケていくシーケンスにおいて、最大の懸念となるのが「VRAMのリーク」と「Blender側で仕込まれた予期せぬアニメーションの暴走」でした。

非VRMモデル（ステージオブジェクトやエネミーなど）のGLTFデータをそのままシーンに使い回すと、メモリ参照の競合やリークを引き起こすリスクがあります。これを防ぐため、以下のクローン生成パイプラインを構築しました。

const scene = isVrm ? gltf.scene : SkeletonUtils.clone(gltf.scene);

SkeletonUtils.clone を用いて、GPUに負荷をかけず安全に独立したインスタンスを生成します。さらに、アンマウント（アセットの切り替え）が発生した瞬間、裏で居残ろうとするゾンビモデルを useGLTF.clear(targetUrl) によって100msの時間差で確実に完全パージ（お掃除）する防衛機構も配備しています。

また、Blender側でモデル自体に「移動データ（ルートモーション）」や「予期せぬ軸回転」のキーフレームが埋め込まれている場合、中央で綺麗にモデルを自転させたいエンディングのカメラワークが完全に崩壊してしまいます。そこで、レンダラーに描画を渡す直前でキーフレームを検閲・強制切除する tracks フィルターハックを実装しました。

if (gltf.animations && gltf.animations.length > 0 && data.animationIndex !== undefined) {
  const originalClip = gltf.animations[data.animationIndex];
  const clip = originalClip.clone();

  if (data.id === "WIT_TERRAIN_TOMOKO") {
    // 🐈 おでかけコンパス（ともこ）の移動と回転キーフレームを完全パージ
    clip.tracks = clip.tracks.filter(track =>
      !track.name.endsWith('.position') && !track.name.endsWith('.rotation')
    );
    console.log(`🧼 [WIT ED LOCK] ${data.id} のアニメーション回転・移動を完全にロックしました。`);
  } else {
    // その他のモデルも一律で位置移動データをへし折る
    clip.tracks = clip.tracks.filter(track => !track.name.endsWith('.position'));
  }

  const mixer = new THREE.AnimationMixer(scene);
  mixer.clipAction(clip).play();
  mixerRef.current = mixer;
}

特に縦横無尽に飛び回るアニメーションデータのあった WIT_TERRAIN_TOMOKO（おでかけコンパス）に対しては、.position だけでなく .rotation のトラックまで根こそぎ間引くことで、地軸の暴走をへし折り、本来の美しいマスコットとしての佇まいを中央に完全固定（ホールド）させることに成功しています。

1-2. インターロックガード：連打によるブラウザ即死（Render process gone）を阻む e.repeat 防壁

ユーザーの手動送り（Enterキー押下）によってスライダーが次のフェーズへと遷移するシステムにおいて、キーの「長押し」や「過度な連打」はフロントエンドにおける致命的なボトルネックになります。

Reactのステート更新（setMotionState）がフレームレートを出し抜いてミリ秒間に何十回も多重トリガーされると、非同期のアセットロードとアンマウントがクラッシュし、最悪の場合はブラウザの描画プロセス自体が悲鳴を上げて死に至ります（Render process gone）。

これをワンラインで完璧にインターロック（過負荷遮断）したのが、この e.repeat ガードです。

useEffect(() => {
  const handleNextItemDebug = (e: KeyboardEvent) => {
    if (e.key === 'Enter') {
      if (e.repeat) return; // 🛡️ OS側からの高速キーリピート連打を完全に黙殺！
      if (motionState === 'STAY') {
        console.log(`⏭️ [WIT ED DEBUG] Enter検知：次へ送ります [ID: ${data.id}]`);
        setMotionState('OUTGOING');
      }
    }
  };
  window.addEventListener('keydown', handleNextItemDebug);
  return () => window.removeEventListener('keydown', handleNextItemDebug);
}, [motionState, data.id]);

OS側から供給される「押しっぱなしによる連続キーイベント」を完全に無視し、1回の完全な打鍵（スタンドアロンな初回押下）のみを抽出してフェーズを OUTGOING にスイッチします。

これにより、どれだけ熱狂的にEnterキーを叩き込もうが、システムは驚くほど平然と、絹のように滑らかなハケのスクロールアニメーションを維持し続けます。

1-3. 真のデータ駆動化：クレジット情報の動的一本化とバナー表示比率の自動最適化（WITEdImageBillboard）

本実装の最も美しいリファクタリングは、コード側を1文字も汚すことなく、プロジェクト内の全アセットのJSONデータからクレジット情報を一撃で自動回収してくる「統合アセットパイプライン」の構築です。

WIT_AVATARS、ACCESSORIES.STAGE_OBJ、WIT_ENEMIES、ACCESSORIES.items の各JSONを走査し、creator の記述があるデータを useMemo 内で重複なく自動回収（スカウト）します。

// 各アセットの個別スケール・位置をJSON側からダイレクトにルックアップ
if (data.edScale || data.edPosition) {
  return {
    scale: data.edScale || (data.baseScale || [1, 1, 1]),
    position: data.edPosition || [0, 0.15, 0.05],
    rotation: data.edRotation || [0, Math.PI, 0]
  };
}

これにより、開発者はJSON側に "edScale" や "edPosition"、"edRotation" をパチパチと書き込むだけで、エンディング内での見栄えをミリ単位でホットリロード（HMR）確認しながら、完全にコントロールできるようになりました。

さらに、3Dモデルを持たない「効果音ラボ」や「BGMコンポーザー」の2Dロゴ・グラフィック（imageUrl）を投影するサブスレッド WITEdImageBillboard にも、インテリジェンスな自動最適化ロジックを配線しています。

const WITEdImageBillboard: React.FC<{ url: string }> = ({ url }) => {
  const tex = useTexture(url);
  if (!tex) return null;

  // イラストアセットと横長バナーロゴの比率をパス名から自動判別・最適化！
  const isCompassIllustration = url.includes("odekake");
  const args: [number, number] = isCompassIllustration ? [1.1, 0.62] : [1.4, 0.45];

  return (
    <mesh position={[0, 0.22, 0.05]}>
      <planeGeometry args={args} />
      <meshBasicMaterial map={tex} transparent={true} toneMapped={false} depthTest={true} />
    </mesh>
  );
};

テクスチャのURL文字列を検出し、おでかけコンパスのスクエアなイラスト（odekake）なのか、あるいは企業の横長バナーロゴなのかをシステムが自動で嗅ぎ分け、メッシュのジオメトリ args（planeGeometry）の縦横アスペクト比を一撃でジャストフィットさせます。

エントリーとエグジットの座標制限も従来の広すぎる設定から 2.5 / -2.5 へと絶妙に引き締められたことで、赤い緞帳（カーテン）の裏からアセットがポップするまでの不自然な「ラグ（待ち時間）」が完全に消滅し、無駄のない極上の演出テンポが完成しました。

2. 新中ボスエネミー『イースター・エッグAI』の追加と最適化

Blenderで綺麗に直立加工していただいた最新の縦型10連卵リングモデル（WIT_ENEMY_EASTER_EGGS_BLUE_COLLECTION）をインゲームへ完全配線しました。

前作から引き継いだ混沌とした3D空間の座標系をデータ駆動によって統御し、ゲームデザインとして極めて外連味（けれんみ）のある強力な中ボスAIへと昇華させたハックのディテールを解説します。

2-1. 副作用ゼロの3D傾転ハック：キャッシュ汚染を防ぐシーングラフ「親子ノードカプセル化」

Blenderからエクスポートされた3DモデルをThree.js（React Three Fiber）上で回転・並進させる際、最もやってはならない禁忌が「グローバルなロードキャッシュ（元のシーンオブジェクト）に対する直接のミューテーション（破壊的変更）」です。これをやってしまうと、同じアセットを量産した際にすべての敵が同じ回転運動に強制同期されたり、画面がリロードされた際に地軸が歪むバグの原因になります。

今回はモデルのインポート状態を1ミリも汚さず、R3Fの持つシーングラフ（親子ノードの地軸階層）の特性をフルに活用し、外側のラッパーだけで完全にグラフィックを制御する鉄壁の配線を施しました。

// 📄 src/components/PROJECT_LAIN/WIT/WITManager.tsx より抜粋

// 🥚 【判定フラグ】：現在処理しているのがイースターエッグ（卵リング）かどうか
const isEasterEgg = resolvedId === 'WIT_ENEMY_EASTER_EGGS_BLUE_COLLECTION';

return (
  <group
    key={enemy.id}
    // 🛠️ ハックA：移動制御（x, y）をこの一番外側の親グループが100%統治する
    position={isEasterEgg ? [enemy.x, enemy.y + hitOffset, 0.04] : [0, heightOffset, 0]}
  >
    {/* 🛠️ ハックB：移動軸を完全に保護したまま、中身のグラフィックだけを垂直（大観覧車）に90度強制傾転！ */}
    <group rotation={[isEasterEgg ? Math.PI / 2 : 0, 0, 0]}>
      <EnemyInstance
        // 🛠️ ハックC：親グループがすでに移動を肩代わりしているので、内部座標は「0」に偽装
        enemy={isEasterEgg ? { ...enemy, x: 0, y: -hitOffset } : enemy}
        baseScene={baseScene}
        enemyScale={enemyScale}
        spin={spin}
        rotationOffset={rotationOffset}
      />
    </group>

    {/* 物理衝突判定の可視化赤リング */}
    {showHitbox && (
      <mesh position={isEasterEgg ? [0, 0, 0] : [enemy.x, enemy.y - heightOffset + hitOffset, 0.04]}>
        <torusGeometry args={[enemyRadius, 0.0025, 4, 32]} />
        <meshBasicMaterial color="#ff0000" depthTest={false} transparent opacity={0.85} toneMapped={false} />
      </mesh>
    )}
  </group>
);

最外殻の <group> が物理エンジン側の移動軸（enemy.x, enemy.y）を正確にドライブし、その直下の中間ラッパー層がグラフィックだけを Math.PI / 2（90度）垂直にへし折ることで、大観覧車のような美しい「Z軸等速スピンロール」を副作用ゼロで実現しています。

これにより、インゲームの物理空間上のXY平面と、3Dモデル側のローカル軸が美しくアイソレートされ、デバッグ用の衝突赤リング（torusGeometry）もブレることなくジャストの物理中心点へ固定投影されるようになります。

2-2. 時間軸・発射回数の完全同期：1ミリのデッドタイムも許さない「定周期インターロックAI」

中ボスのタイムライン設計において、「指定回数弾を撃ち終えたら、即座に次のフォーメーションへ移行する」という挙動をハードコード（秒数管理）で記述すると、フレームレートの変動や攻撃パターンの変更時に必ず時間軸のズレ（無駄な静止時間や攻撃の誤爆）が生じます。

この問題を解決するため、enemyPatterns.ts 側に発射定数（SHOT_COUNT）と移動サイクルが完全に数学的連動する「定周期バインドAI」を構築しました。

// 📄 src/components/PROJECT_LAIN/WIT/utils/enemyPatterns.ts より抜粋

const T_BURST = 1.0;    // 💥 弾と弾のあいだの発射間隔（秒）
const SHOT_COUNT = 3;   // 🎯 【指定発射回数】（ここを変えるだけで移動タイミングも自動追従！）

// 📐 攻撃フェーズの長さを「間隔×回数」にジャストフィットさせる！（1.0s × 3回 = 3.0秒）
const PHASE_ATTACK = T_BURST * SHOT_COUNT;
const PHASE_SWAP = 1.6;  // 🚀 入れ替え移動にかける秒数
const CYCLE = PHASE_ATTACK + PHASE_SWAP;

// ② 攻撃フェーズ（指定回数をジャストで撃ちきるまでの時間軸）
if (cycleTime < PHASE_ATTACK) {
  shootPhase = 'FIRING';
  const subBurstIndex = Math.floor(cycleTime / T_BURST);
  // 全サイクルを通した一意の通し番号に変換して、WITManager側のトリガーを叩く燃料にする
  burstIndex = cycleCount * SHOT_COUNT + Math.min(subBurstIndex, SHOT_COUNT - 1);

  const isSwapped = cycleCount % 2 !== 0;
  if (index === 0) y = isSwapped ? bottomY : topY;
  else y = isSwapped ? topY : bottomY;
}
// ③ スワップ移動フェーズ（指定回数を撃ち終えた瞬間に、1フレームの遅延もなく即座に突入！）
else {
  shootPhase = 'SWAP';
  burstIndex = cycleCount * SHOT_COUNT + (SHOT_COUNT - 1); // 射撃バースト値をロック

  const swapProgress = (cycleTime - PHASE_ATTACK) / PHASE_SWAP;
  const eased = (1 - Math.cos(swapProgress * Math.PI)) / 2; // スムーズなサイン補間

  const startIsSwapped = cycleCount % 2 !== 0;
  if (index === 0) {
    const startLocalY = startIsSwapped ? bottomY : topY;
    const endLocalY = startIsSwapped ? topY : bottomY;
    y = startLocalY + (endLocalY - startLocalY) * eased;
  } else {
    // index === 1 側の反転移動処理
    ...
  }
}

この数理モデルにより、cycleTime が PHASE_ATTACK（3.0秒）を超えた瞬間に、システムは1ミリ秒のデッドタイムも挟むことなく、流れるように上下の高度入れ替え（SWAP）フェーズへと突入します。

移動中は burstIndex が前回の最終値で完全にホールドされるため、スワップ運動中の弾の暴発が物理的に発生し得ない、極めて堅牢なステートマシンが完成しました。

2-3. 並進壁弾幕ハック：大観覧車の回転座標から「真左直進ベクトル」への完全ロック

イースター・エッグAIが放つ弾幕は、回転する10個の卵それぞれの先端（サークル座標）から発生します。通常、このようなサークル型の配置から弾を放つと、放射状（全方位）に弾が拡散していくのがSTGの定番ですが、今回はあえて「発生源は回転追従、進行方向は真左に完全固定」という特殊な空間ベクトルの変調ハックを仕込みました。

// 📄 src/components/PROJECT_LAIN/WIT/WITManager.tsx より抜粋

if (config.shootPhase === 'FIRING' && config.burstIndex !== enemy.lastBurstIndex) {
  enemy.lastBurstIndex = config.burstIndex;
  const eggCount = 10;
  const radius = 0.26;

  for (let i = 0; i < eggCount; i++) {
    // 🛠️ 発生源の計算：卵それぞれの位置（angle）は回転に同期させてキープ！
    const angle = ((i * Math.PI * 2) / eggCount) + enemy.rotationY;
    const bx = enemy.x + Math.cos(angle) * radius;
    const by = enemy.y + Math.sin(angle) * radius;

    enemyBulletsRef.current.push({
      id: `eb_egg_${enemy.id}_${i}_c${config.burstIndex}`,
      x: bx,
      y: by,

      // 🎯 👑 【方向転換ハック】：拡散させるのをやめ、真左（前）へ固定直進！
      vx: -(GLOBAL_ENEMY_BULLET_SPEED * 0.7),
      vy: 0,

      scale: 0.52,
    });
  }
  audioController.playSe("SE_RIPPLE_SHOT", getSeVolume("SE_RIPPLE_SHOT", 0.4) * 0.5);
}

発生座標の初期値（bx, by）には Math.cos(angle) / Math.sin(angle) による美しい円運動同期を噛ませつつ、初速度ベクトルを vx: -SPEED, vy: 0 へと強制ロック（射影）しています。

これにより、画面に展開される弾幕は、回る大観覧車から縦一列に整列したピンクの光の針が、スクリーンの上下を完全に覆い尽くしながら「並進する壁」として等速で迫り来るという、プレイヤーに緻密な位置取りを要求する最高に緊迫感のある火線グラフィックを形成することになりました。

2-4. JSONパラメータの全面委任：コアロジックを汚さない「データ駆動型HP・半径回収インフラ」

中ボスアセットの耐久値（hp）や当たり判定のサイズ（hitRadius）を調整するたびに、巨大な WITManager.tsx の内部コードを検索してif文を書き換えるハードコードスタイルは、保守性を極限まで低下させます。

そこで、新中ボス配線と同時に、出現した敵のIDをキーに Enemies.json の設定レイヤーからすべての物理定数を動的にスカウトしてバインドする、完全なデータ駆動パイプラインへと一本化しました。

// 📄 src/components/PROJECT_LAIN/WIT/WITManager.tsx より抜粋

// タイムラインから出現した敵IDをルックアップし、JSON側の hp を動的に回収！
const spawnEnemyId = (nextEvent as any).enemyId || WIT_ENEMIES.enemies[0].id;
const matchedEnemyConfig = WIT_ENEMIES.enemies.find(e => e.id === spawnEnemyId);
const finalHp = matchedEnemyConfig?.hp ?? 1; // JSONに記述がなければ安全弁として1を配給

// 衝突判定スレッド側でも、JSONに記述された固有の hitRadius と高さ補正（hitOffset）を動的回収
const resolvedId = (enemy as any).enemyId;
const enemyConfig = WIT_ENEMIES.enemies.find(e => e.id === resolvedId);
const enemyRadius = enemyConfig?.hitRadius || 0.07;
const hitOffset = (enemyConfig as any).hitOffset || 0;

const dx = bullet.x - enemy.x;
const dy = bullet.y - (enemy.y + hitOffset); // 弾の交差位置を赤リングの中心へ正確に持ち上げる

これにより、プログラム側のコアロジックは完全にカプセル化され、ユーザーは Enemies.json の数値を書き換えるだけで、中ボスのHPのタフさや、グラフィックに対する当たり判定の赤リングの大きさ、位置ズレ（hitOffset）の調整までを一瞬でリアルタイム同期させることが可能になりました。開発の機動性が一変する、非常に美しい抽象化インフラです。

3. 2面（ステージ2）開発サンドボックス環境の構築

ステージ1という巨大なマイルストーンを越え、次なる舞台「ステージ2」のタイムライン構築およびアセット配置へと開発の舵を切るにあたり、最優先すべきは「1ストロークあたりのデバッグ効率を極限まで高めること」でした。

手作業による泥臭い座標調整や、トライ＆エラーのサイクルを秒単位まで短縮するために構築した、2面開発専用サンドボックス環境のインフラ構造について詳解します。

3-1. リスタート防衛定数：デバッグループを爆速化する DEVELOPMENT_STAGE 配線

3Dシューティング（STG）の開発において、2面の道中ギミックやスクロールの検証を行う際、被弾してゲームオーバーになるたびにタイトル画面を経由してステージ1の最初から通しプレイを強制される仕様は、開発者の集中力とエネルギーを著しく削ぎ落とします。

この開発上の最大のボトルネックを破壊するため、システム最上部にリリースフラグとしても機能するグローバル定数 DEVELOPMENT_STAGE を配線しました。

// 📄 src/components/PROJECT_LAIN/WIT/WITManager.tsx より抜粋

// デバッグ用ステージ選択
const DEVELOPMENT_STAGE = 2; // 💡 開発中はここを 2 に固定ホールド！

export const WITManager = () => {
  const { camera, size , clock, scene } = useThree();

  // 初期ステートに開発対象ステージをダイレクトにインジェクション
  const [stageNum, setStageNum] = useState(DEVELOPMENT_STAGE);

この定数は初期起動時のステージセレクト（useState）を書き換えるだけでなく、ファイルの最下部に位置する GameOverInputHandler にまで一気通貫でルーティングされています。

// 📄 ファイル最下部：GameOverInputHandler 内の初期化スレッド
const handleReset = () => {
  if (isGameOver && showHitAnyKey) {
    setIsGameOver(false);
    if (isGameOverRef) isGameOverRef.current = false;
    setShowHitAnyKey(false);

    // 🎯 👑 【リスタート防衛】：ゲームオーバー復帰時も1面に戻さず開発指定ステージで完全固定ホールド！
    setStageNum(DEVELOPMENT_STAGE);

    setLives(3);
    setScore(0);
    // ── 装備全リセット処理 ──
    ...

これにより、2面のテストプレイ中にどれだけ激しい弾幕に被弾してゲームオーバー画面に叩き落とされようとも、Rキーの連打や画面クリックによる復帰の瞬間に、1ミリの遅延もなく即座にステージ2のスタートラインへと爆速でループ復帰する「聖域（サンドボックス）」が確立されました。

製品版として通しプレイ仕様で書き出す（ビルドする）直前に、この定数を 1 にカチッと巻き戻すだけで、すべての初期化処理・リスタートインフラが一括追従してアーケード本来の挙動に戻るという、極めてクリーンなリリースワークフローが完成しています。

3-2. 地形ヒットボックスの動的自動ルックアップ：コライダーと描画高数の完全同期インフラ

2面で新しく導入した背景アセットであるバーガーショップ（WIT_BURGER_RESTAURANT）などをタイムラインへ配置していくマップデザインの工程は、ゲーム開発の中で最も孤独で根気のいる職人仕事です。3Dモデルのスケール・見た目の接地位置・そして内部の衝突判定（物理コライダーの青枠）の3つの辻褄を、手作業で1マスずつコードにハードコードしていくのは現実的ではありません。

この摩擦をゼロにするため、地形オブジェクト（STAGE_OBJ）が描画される瞬間に、JSONに定義された "hitbox" サイズおよび足元のめり込みオフセット高度（hitOffset）をリアルタイムに吸い上げる「動的衝突同期レイヤー」へとリファクタリングを敢行しました。

// 📄 src/components/PROJECT_LAIN/WIT/WITManager.tsx（地上物描画ループ）より抜粋

{visualTerrain.map((obj) => {
  const screenEdge = MONITOR_WIDTH / 2;
  if (obj.x > screenEdge + WING_WIDTH || obj.x < -(screenEdge + WING_WIDTH)) return null;
  const scene = terrainScenes.get(obj.modelId);
  const stageObjConfig = (ACCESSORIES as any).STAGE_OBJ?.find((o: any) => o.id === obj.modelId);
  const objScale = (stageObjConfig?.scale || [0.05, 0.05, 0.05]) as [number, number, number];

  // 定数からこの地上物固有のヒットボックスサイズ（width, height）を取得
  const box = getTerrainHitBox(obj.modelId);

  // 👑 🎯 オブジェクトが持っている固有のズレ幅（未定義ならconfigから）を抽出
  const hitOffset = obj.hitOffset ?? (stageObjConfig?.hitOffset || 0);

  return (
    <group key={obj.id}>
      {/* ① 地形オブジェクト本体の描画：グラフィックの配置位置だけを足元へキュッと引き下げるハック！ */}
      <TerrainInstance
        obj={{ ...obj, y: obj.y - hitOffset }} // 🎯 物理中心から見た目のズレ幅分だけグラフィックを沈める
        baseScene={scene}
        objScale={objScale}
        objRotation={obj.rotation}
      />

      {/* 👑 🎯 ② 【地形ヒットボックスの可視化インフラ】 */}
      {/* obj.y はすでに100%完璧な物理中心を指しているので、そのままの座標で青枠がジャストフィットします！ */}
      {showHitbox && box.width > 0 && box.height > 0 && (
        <mesh position={[obj.x, obj.y, 0.04]}>
          <planeGeometry args={[box.width, box.height]} />
          <meshBasicMaterial color="#000dff" wireframe={true} depthTest={false} transparent opacity={0.6} toneMapped={false} />
        </mesh>
      )}
    </group>
  );
})}

グラフィック側の描画関数（<TerrainInstance>）にデータを渡す直前で、本来の同期的物理中心（obj.y）から JSON 側の指定値である hitOffset を差し引いた座標（obj.y - hitOffset）へとインラインでスライド変調（変位）させています。

このデータ駆動化の恩恵は絶大です。「H」キーを押して当たり判定のレントゲン青枠を表示させたまま、ブラウザの横で Enemies.json や Accessories.json の "hitbox" や "hitOffset" の数値をパチパチと叩くだけで、「グラフィックの見た目の接地」「物理的な壁の青枠」「ミサイルの床滑走判定」「自機の侵入制限判定」がすべて一撃で、リアルタイムに完全同期するようになりました。

一度この高精度なインフラがマウントされてしまえば、あとはタイムライン配列へ地形アセットを無限にコピペして並べていくだけの「コピペ天国」へと突入します。1面の過酷な開発でシステムを徹底的に抽象化しきったからこそ辿り着けた、開発機動性を爆発的に引き上げる最強のデバッグ環境です。

4. 歴史的物理バグの完全討伐（プレイヤー隙間ハマり・すり抜けの根絶）

1面時代からひっそりと潜み、タイルの境目でイレイナがガタついたり、床下にすり抜けてウッドデッキまで落ちてスタックしてしまっていた、このエンジン最大の謎だった怪奇現象を完全解決しました。

JSON側でどれだけコライダーの数値を盛っても自機が床をすり抜けていた理由と、それをコンポーネントの外部から一撃で無力化した「ゴーストコライダー・インターセプター」の全貌を明かします。

4-1. 検閲ロックの看破：WITController に潜む1面時代の遺産と「床の虚空化」

放置してじっくりとゲーム画面を観察する（プロファイリング）なかで浮上したのが、「実は1面の頃からタイルの継ぎ目で自機が一瞬ガタついていた」という不穏な予兆でした。

この原因を突き止めるべく、自機の移動制限および地形とのめり込み防止を司る外部コンポーネント WITController.tsx の衝突判定スレッドを精査したところ、以下の致命的な名前検閲ハードコードが息を潜めていることが判明しました。

// 📄 src/components/PROJECT_LAIN/WIT/WITController.tsx 内部の侵入不可クランプ処理より
if (terrainObjs.length > 0) {
  ...
  terrainObjs.forEach(obj => {
    // 🚨 1面時代に埋め込まれた、特定キーワード以外の「床オブジェクト無視」の壁
    if (obj.modelId === "WIT_TERRAIN_GRASS" || obj.modelId === "WIT_TERRAIN_MUSHROOM") return;

    // ※内部の modelId 文字列に "BLOCK" や "FLOOR" が含まれている前提で物理演算を走らせていた
    const dx = playerPosRef.current.x - obj.x;
    const dy = playerPosRef.current.y - obj.y;
    ...

1面で敷き詰めていた床アセットは WIT_TERRAIN_BLOCK などのIDだったため、この移動エンジンのめり込みクランプが正常に機能していました。しかし、2面で新しく Blender からインポートしたアセットのIDは "WIT_TERRAIN_TILE" や "WIT_BURGER_RESTAURANT" です。

大文字に変換しても BLOCK や FLOOR といった1面の床公認キーワードを1ミリも含まないため、WITController 側からは「こいつらは固い床ではない。ただの背景の飾り（装飾品）だ」と判定され、すべてのめり込み防止スレッドから門前払い（スルー）を食らっていました。

物理コライダーの存在そのものを黙殺されているため、JSON側で hitbox の横幅をどれだけ広げようがイレイナは物理法則を無視して床をすり抜け、システムの最下端移動限界（ウッドデッキの高さ）まで落ちてスタックして動けなくなっていた、というのがこの怪奇現象の真のメカニズムです。

4-2. 1面床ID偽装 ＆ 5重ゴースト糊付けシステム：外部レイヤーからの物理空間埋め立てハック

原因さえ特定できれば、解決のためにわざわざ基幹コンポーネントである WITController.tsx の内部ロジックを書き換えて、1面と2面の分岐条件でコードを汚す必要はありません。

今回は、WITManager.tsx から WITController へProps経由で地形データを引き渡す一瞬の隙を狙い、データを完全に書き換えて流し込む「ゴースト・コライダー・インターセプター」を useMemo レイヤーにマウントしました。

// 📄 src/components/PROJECT_LAIN/WIT/WITManager.tsx より

// ── 🎯 👑 【プレイヤー隙間ハマり完全封鎖：1面床ID偽装 ＆ 糊付け極限強化システム】 ──
// WITController 内部の「文字列検閲」を完全バイパスするため、
// 2面の新アセットの ID を、1面の実績ある床ID "WIT_TERRAIN_BLOCK" へ瞬時に偽装！
// さらに、隣同士の1フレーム未満の計算隙間を完全に埋め立てるため、左右の糊付けマージを「0.06」へ極限拡張します。
const paddedTerrainForPlayer = useMemo(() => {
  const arr: any[] = [];
  visualTerrain.forEach(obj => {
    // 🧱 👑 全オブジェクトのIDを、WITControllerが100%床として公認する名前にすり替える（グラフィックの見た目はそのまま）
    const fakeObj = { ...obj, modelId: "WIT_TERRAIN_BLOCK" };

    arr.push({ ...fakeObj, x: obj.x - 0.06, id: `${obj.id}_GL2` }); // 👻 左の外側分身
    arr.push({ ...fakeObj, x: obj.x - 0.03, id: `${obj.id}_GL1` }); // 👻 左の内側分身
    arr.push(fakeObj);                                             // 🧱 本尊
    arr.push({ ...fakeObj, x: obj.x + 0.03, id: `${obj.id}_GR1` }); // 👻 右の内側分身
    arr.push({ ...fakeObj, x: obj.x + 0.06, id: `${obj.id}_GR2` }); // 👻 右の外側分身
  });
  return arr;
}, [visualTerrain]);

このインターセプターの仕組みは以下の2つのアプローチでバグの侵入経路を完全に封鎖（ハック）しています。

  1. IDの同期的すり替え（2面対応）： WITController に配列が手渡される瞬間に、2面のすべてのタイルの ID が "WIT_TERRAIN_BLOCK" という「1面の絶対に安全な床ID」へとディープに偽装されます。これにより、自機の移動制限エンジンが「1面の安全なコンクリート床が敷き詰められている」と完璧に錯覚し、めり込み防止のクランプをフルパワーで稼働させ始めます。
  2. 5重連動ゴーストによる超高密度糊付け（隙間スタック対策）： 1面タイルのジャスト 0.3 の繋ぎ目で発生していた「浮動小数点数の計算誤差による1フレーム未満の虚無のスリット」を完全に埋め立てるため、1つのタイルに対して左右へ 0.03 / 0.06 刻みではみ出させた計4体の「不可視の分身（ゴーストコライダー）」を動的に生成・密結合させました。
<WITController
  ...
  // 🎯 従来の visualTerrain から、隙間を完全封鎖した偽装配列へスイッチ！
  terrainObjs={paddedTerrainForPlayer}
  onUpdate={(pos, pitch) => { ... }}
/>

画面に映るグラフィック（見た目）は、Blenderからエクスポートした美しい2面の芝生や木のタイルのまま、内部の物理足場だけが、左右の判定をガッチリと重ね合わせて糊付けした「1ミリの計算隙間も存在しない完全な一枚岩」へと変貌を遂げました。

このバスターハックをデプロイした結果、1面から続いていた自機のガタツキおよび2面でのスタックバグが完全に、200%根絶されたことを確認しました。スピードをMAXまで上げて地形の上を超高速で滑空しても、驚くほど吸い付くような、極上のシルクの上をフライトしているかのような快適な操作フィールを維持し続けています。