WebSocketでオンライン対戦を作るには？ルームとサーバー判定の設計

1. 勝敗の確定は、サーバー側に一つの窓口を置く

ColyseusのState Synchronization資料は、サーバーが状態を変更し、クライアントがその変化を受け取る構成を説明しています。クライアントは状態の変更を依頼するメッセージを送ります。この方針は、入力と確定した結果を分けて考えるための具体例になります。

この記事の設計案では、ブラウザから「自分が勝った」ではなく「この手を選んだ」という操作を送ります。サーバー側は参加者、手番、盤面、制限時間などを確認し、採用する操作だけで状態を更新します。受信したデータをそのまま信用せず、ルールが成立するかを一箇所で調べると、両方の画面へ同じ結果を伝えやすくなります。

自分の移動をすぐ画面に出す予測表示を使う場合も、確定状態とは区別します。後から修正が入る可能性を持つ見た目を、得点や勝利の確定表示と混ぜないようにします。初めての実装では、まず手番制の小さな対戦など、操作の順序を追いやすいルールで経路を確認する方法もあります。

2. ルームに、開始前と試合中と終了後の状態を持たせる

対戦ルームには、人数がそろう前、準備確認、試合中、終了という状態を用意します。新しい参加者をいつまで受け入れるか、観戦を許可するか、終了した部屋をいつ片付けるかも決めます。二人を同じ場所につなぐだけでは、片方だけが再挑戦を押した場合などの挙動を説明できません。

ルーム番号は参加先を指定する情報とし、参加者本人の確認とは分けます。ブラウザから届いたIDだけで、他人の操作を許可しない構成にします。この記事の状態例は作品に合わせて変えられますが、状態ごとに受け付けるメッセージを一覧にする作業は、誤って試合開始前の攻撃を採用する問題などを見つける手掛かりになります。

ルーム状態の設計例
waiting：参加・退出を受け付ける
ready：参加者の準備を確認する
playing：有効な操作だけ採用する
finished：結果を表示し再試合の合意を待つ
操作には種類・連番・必要な値を持たせる。

3. 通信が詰まったとき、送る量を減らす

MDNのWebSocket資料は、通常のWebSocket APIが自動的なバックプレッシャーを提供しない点を説明しています。bufferedAmountは送信待ちのバイト数を確認する値です。送受信の量と処理の速度を、アプリ側で考える必要があります。

連続する位置情報は最新のものにまとめられる場合がありますが、購入、攻撃の決定、手番の操作などは単純に消してはいけません。メッセージの種類を分け、更新間隔と上限を決めます。小さな対戦であっても、毎回すべての盤面を送る構成と、変化だけを送る構成のどちらが必要かを、まず読みやすさと実測から考えましょう。

送信待ちが増えたときは、上限まで何でも送り続けるのではなく、通信状態を表示して入力の扱いを調整します。古い位置情報を送り終えることが目的になると、現在の操作の反応が遅れます。採用した上限値は作品のデータ量と確認条件を根拠にし、普遍的な対戦ゲームの正解として説明しないようにします。

4. 再接続後は状態を取り直し、古い操作を見直す

接続が戻ったら、現在の試合番号、状態の版、参加者としての権限を確認します。切断中に押した操作をすべて再送すると、終了済みの試合へ操作を追加してしまうかもしれません。サーバーが採用済みの連番を把握できる構成なら、同じ操作の重複も扱いやすくなります。具体的な再送規則はゲームの性質に合わせて決めます。

確認では、準備中の切断、操作直後の切断、終了後の再接続を分けます。一方の端末だけを非表示にした場合も、サーバーの時間が進むなら画面へ説明が必要です。この記事のチェック項目は設計用の案です。二人が別の回線を使う条件や遅い通信も含め、同じ結果が表示されることを確認した後に、参加人数やルーム機能を増やしましょう。

手番制なら、切断中に相手の手が確定した後の復帰を最初の確認例にできます。復帰した画面では盤面と現在の手番を取り直し、切断前に選んだ場所がまだ有効かを調べます。選択表示を残す場合も、確定した手としては扱わないようにします。ルールの分かりやすい小さな対戦でこの経路を通してから、連続する移動や攻撃のあるゲームへ広げると、必要な同期を一つずつ追加できます。

• 同じ操作を重複して送る
• 手番でない操作を送る
• 準備中と試合中に切断する
• 終了済みの試合へ古い操作を送る
• 再接続した画面で現在の状態を取り直す