Claude Fable 5にスマホゲームのオンライン対戦を実装させた

Claude Fable 5 が再公開されたので、また何か作らせてみることにしました。前回は回路図エディタでしたが、今回はこのサイトに置いてある3Dドライブゲーム（/drive3d_mobile）にオンライン対戦を足してもらいました。スマホ2台で、4桁のルームコードを伝え合うだけで対戦できます。

問題：サーバがRaspberry Pi

このサイトは自宅のRaspberry Piで動いています。ゲームサーバとして毎秒何十回も位置情報を中継するような仕事をさせたら、他のページごと死にます。

そこでClaudeに出した条件は「できればスマホ端末同士で直接通信してほしい」。返ってきた設計はこうでした。

• ゲーム中の通信は WebRTC DataChannel によるスマホ同士のP2P直結。サーバは一切経由しない
• サーバ（Flask）の仕事は接続確立時のシグナリングだけ。ホストとゲストのSDP（接続情報）を4桁コードに紐付けて受け渡す、数回のHTTPリクエストで終わる仕事
• ICE候補の逐次交換（Trickle ICE）はやらず、候補収集が終わった完全なSDPを一度だけ交換する Vanilla ICE 方式。おかげでシグナリングAPIは create / join / answer の3本だけ

ルーム情報はFlaskプロセスのメモリ上のdictに置くだけ（10分で自動破棄）。SDP交換が済んだら即削除されるので、サーバに残るものは何もありません。Piの負荷は実測でほぼゼロです。

同期の設計：「自機のことは自分の端末が決める」

P2P対戦で面倒なのは、遅延がある中で「どっちの画面を信じるか」です。Claudeの採った方針はシンプルでした。

• 自分の車の位置・被弾・落下は常に自分の端末が権威。相手の画面上の自分は、20Hzで送られてくる状態を補間表示した「分身」
• 弾は毎フレームの位置を送るのではなく、発射イベント（位置・方向・初速）だけ送って相手側でも同じ物理で飛ばす
• 爆発も同様にイベントで送り、吹き飛ばされるかどうかは受けた側が自分で判定する

これなら遅延があっても「自分は避けたのに死んだ」という理不尽が起きにくい。判定が両端末で完全一致はしませんが、落ちたら負けというルール上、勝敗判定（自分の落下）は各自が自分の分だけ宣言するので矛盾しません。

その後の改善で、DataChannelは2本に分けました。位置更新は順序なし・再送なしのチャンネル（古いパケットはシーケンス番号で捨てる）、弾・爆発・勝敗などのイベントは信頼性ありのチャンネル。1本の信頼性チャンネルに全部載せると、パケットロス時に位置更新まで巻き添えで遅延する（head-of-line blocking）ためです。

会話しながら育てた機能

最初のP2P対戦が動いたあとは、思いつくまま注文を投げて育てていきました。

• カメラ設定モード：距離・高さ・注視点・FOVをゲーム中にスライダーで調整、localStorageに保存
• ステージ選択：部屋を立てるときに広さ（小/中/大）と種類を選べる。ノーマル・穴あき・十字・4つの島・縮む足場
• ルール設定：爆発の強さ、連射の強さ（連射は速度とMP燃費が両方変わる）
• 開始カウントダウンと連戦スコア：接続確立と同時に始まると先に画面を見ていた側が有利なので、ホストの合図で「3・2・1・GO!」を同期。リマッチをまたいで勝敗数も表示

気に入っているのは縮む足場の実装です。足場の縮小は「ラウンド開始からの経過時間」だけから決定的に計算されるので、縮小のための同期通信が1バイトも要らない。P2Pゲームのギミックはこういう作り方をするのかと感心しました。

ハマったところ

Jinjaテンプレートと ES6 テンプレートリテラルの衝突。 ゲームのHTMLはFlask（Jinja）経由で配信されているので、JavaScriptに ${{...}} のようなコードを書くと、Jinjaが {{ }} を自分の構文として解釈してサイトごと500エラーになります。一度これでゲームページが丸ごと落ちました。しかもClaude自身が「JinjaだからJSに {{ は書けない」という注意コメントをコードに残そうとして、そのコメント内の {{ でまた500を出すというオチ付き。

見えないCPU車が弾を食っていた。 対戦モードではソロ用のCPU車を非表示にしていたのですが、当たり判定は生きたままでした。ローカルの画面分割対戦では「たまに弾が消える」程度で誰も気づかなかったのが、オンライン化でCPU車の配置乱数が端末ごとに違うため「自分の画面では当たったのに相手の画面では外れている」という形で顕在化。オンライン化は隠れバグの検出器にもなります。

STUNだけではつながらない相手がいる。 TURN中継サーバを立てればほぼ確実につながりますが、中継トラフィックがPiを通るなら本末転倒なのでSTUNのみにしました。キャリア回線同士（対称NAT）だと稀に接続に失敗します。同じWi-Fiなら確実につながるので、個人サイトのゲームとしてはこれで十分と判断。

iPhoneのSafariは全画面にできない。 実機で遊ぶと、Safariの下のツールバーが消えずゲームが全画面になりません。調べてもらったところ、これは実装の問題ではなくiPhoneのSafariがページからのFullscreen APIを提供していないという仕様でした（動画だけは全画面にできる。iPadやAndroidのChromeでは使える）。つまりSafariのタブ内で完全全画面は、どんなサイトでも原理的に不可能。

対策は3段構えになりました。

• iPhone：PWA用のメタタグ（apple-mobile-web-app-capable など）を足し、Safariの共有メニューから「ホーム画面に追加」→そのアイコンから起動すると、Safariの表示が一切ない完全全画面（standalone）で立ち上がる。実機で確認済みで、ちゃんと全画面になりました。オンライン対戦もそのまま動きます
• Androidなど：Fullscreen API対応ブラウザでは、モード選択ボタンを押した瞬間に自動で全画面化
• ブラウザ内で遊ぶ場合：100dvh でツールバーを除いた実表示域に高さを合わせ、viewport-fit=cover + env(safe-area-inset-*) でスティックやボタンがノッチ・ホームバーに被らないよう調整

「全画面にして」という雑な注文に対して、「iPhoneではAPIが存在しないので、ホーム画面追加へ誘導する案内をiPhoneのSafariで開いたときだけ表示する」という落とし所まで含めて返ってくるのは、制約の説明込みで任せられて楽でした。

まとめ

• 貧弱なサーバでも、WebRTCなら「マッチングだけサーバ、対戦はP2P」でオンラインゲームが成立する
• シグナリングはVanilla ICEにすればFlaskのルート3本で書ける
• 「自機の判定は自分の端末」方式は、カジュアルゲームの遅延対策として実装が軽くて効果的
• Fable 5との開発は、設計方針の相談から実装・デプロイ・curlでの動作確認までが会話で完結して快適でした。特に「サーバが貧弱」という制約を伝えただけでP2P前提の構成を選んでくるあたり、任せ方がだいぶ雑でよくなった

対戦相手がいる方はぜひ /drive3d_mobile からどうぞ。