【第7回】Cloudflare Workersで創るP2Pゲーム記：WebRTC開発ロードマップと伝言板シグナリング構想

前回（第6回）は、サーバーサイドで厳密にEloレーティングを計算し、D1のトランザクションを使って自分と相手の戦績を同時に更新する、鉄壁のチート対策ロジックを実装しました。
前回：Cloudflare Workersで創るP2Pゲーム記：チートを断つEloレーティング実装とアトミック検証【CFW P2P心理戦ゲーム開発記】 #6

バックエンドとデータベースの強力な土台（フェーズ1）がカンペキに仕上がったので、今回からはいよいよ本ゲームの最重要システムである「WebRTCを用いたP2Pリアルタイム通信」の実装フェーズへと駒を進めていきます！

ただ、WebRTCは非常にエキサイティングな技術である反面、一筋縄ではいかないモンスター技術でもあります。そこで今回は、本格的なコードを書く前に、「これからどうやってWebRTCを攻略していくか」のロードマップとシグナリングの構想を整理・共有したいと思います。

1. WebRTCの壁と「急がば回れ」の3ステップ開発

webRTCには、一度に登場する概念（SDP、ICE Candidate、シグナリング、DataChannelなど）が非常に多く、最初からゲームの画面やロジックと混ぜて作ってしまうとデバッグが大変になってしまいます。
そこで、いきなり最終実装をするのではなく、簡単なものから順に以下のようなフェーズ分けして、実装して試していこうと思います。

WebRTC編のステップ・ロードマップ

【フェーズ1】超ミニマムなP2P疎通サンプル（次回はここ！）

ゴール： ブラウザでタブを2つ開き、Workersを仲介（シグナリング）にしてP2Pの「データチャネル（DataChannel）」を確立。「Hello P2P」という文字がサーバーを介さずに直接行き来することを確認する。
Workersの役割：お互いの接続情報（アドレスの紙切れのようなもの＝SDPやICE）を相手にリレーするだけの「シグナリングサーバー」として最小限のコードを実装。
フロント： HTML1枚、JS1枚のプレーンな構成。

【フェーズ2】ゲーム画面（UI）のモックと状態の設計

ゴール： P2P通信はいったん脇に置いておき、バックショット・ルーレットのゲーム画面（自分のライフ、相手のライフ、銃の絵、アイテム欄など）をHTML/CSS（または好みのフレームワーク）で組み立てる。
ポイント： 「今、どちらのターンか」「銃の中に弾は何発残っているか」というゲームの状態（ステート）をコード上でどう管理するか設計します。

【フェーズ3】通信とゲームの融合（合体！）

ゴール： フェーズ1で完成した「P2P通信のパイプ」に、フェーズ2の「ゲームの行動（引き金を引いた、アイテムを使った）」をデータとして流し、2つの画面が完全にリアルタイム同期して遊べる状態にする。

予定なので、実際にやってみたら変わるかもしれませんがおおむねこんな予定で作っていく予定です。

2. 最初の難所「シグナリング」はどうやる？

WebRTCはプレイヤー同士がサーバーを介さずに直接通信（P2P）する技術ですが、「お互いのIPアドレスも知らない状態の2人が、どうやって最初に出会うか？」 という問題が必ず発生します。

この、最初の「出会いの仲介」を行うプロセスのことをシグナリング（Signaling）と呼び、その仲介サーバーをシグナリングサーバーと呼びます。

接続方法についてさくらインターネットのWebRTCはプレイヤー同士がサーバーを介さずに直接通信（P2P）する技術ですが、「お互いのIPアドレスも知らない状態の2人が、どうやって最初に出会うか？」という問題が必ず発生します。この、最初の「出会いの仲介」を行うプロセスのことをシグナリング（Signaling）と呼び、その仲介サーバーをシグナリングサーバーと呼びます。

接続方法についてさくらインターネットのWebRTCとは？仕組みやサーバー構成を解説というページがきれいにまとめてくれていたので画像を引用しますが、大まかな概要としては以下のような複数の要素で構成されています。

さくらインターネットブログより引用

最終的には、Cloudflare Workersの強力な機能（Durable Objectsなど）を使って本格的な双方向シグナリングを実装する予定ですが、フェーズ1の段階ではもっとシンプルに行きます。

D1データベース、あるいはWorkers KVを一時的な「デジタル伝言板」として使い、
1. プレイヤーAが「俺の接続情報（SDP）」を伝言板にPOSTで書き込む
2. プレイヤーBが伝言板をGETで覗き見して（ポーリング）、Aの情報を取得する

という、普通のHTTPリクエストで行う「超シンプルな伝言板方式」のリレーから始めてみます。これなら、現在のシンプルなWorkersの環境のまま、最小のコード量でWebRTCの通信テストが行えます。

3. まとめ

今回は、いよいよ始まるWebRTC編の全体像と、開発を破綻させないためのロードマップを整理しました。

一見、遠回りに見える「テキストが行き来するだけのサンプル作り」ですが、今後の実装の足掛けとしてはちょうどいい経験になったかなと思います。

次回予告

次回（第8回）は、さっそくこのロードマップの「【フェーズ1】超ミニマムなP2P疎通サンプル」の実装に挑みます！

HTML1枚とWorkersの伝言板だけで、ブラウザのタブ同士が直接繋がり、サーバーを通さない光速のデータ通信が走る感動の瞬間をお届けします。

次回、初めてのWebRTC接続編
(記事は現在利用できません: ID 8020)

ここまで読んでいただきありがとうございます。では、次の記事で。　lumenHero

Post Views: 0