ゲームのリアルタイム通信から見た QUIC と MoQ

MoQ Meetup Japan (https://moqmeetup.connpass.com/event/406585/) にて講演した
『ゲームのリアルタイム通信から見た QUIC と MoQ』の資料です

※講演の動画を閲覧したい場合は https://www.youtube.com/watch?v=yUneU7UzI8Y をご参照ください

Transcript

1. ゲームのリアルタイム通信から見た QUIC と MoQ 株式会社セガ 竹原涼
2. 自己紹介 (お仕事) 株式会社セガ 開発技術部 テクニカルリサーチセクション シニアエンジニア/サブマネージャ 竹原 涼 登壇歴  CEDEC 2025 ゲームにおけるリアルタイム通信へのQUIC導入事例の紹介  CEDEC 2023 「CRI ADXプロファイラー活用によるサウンドQAの自動化・可視化に関する取り組みの紹介」  CEDEC 2021 「ダウンロード時間を大幅減！～大量のアセットをさばく高速な実装と運用事例の共有～」  CEDEC 2021 「Android iOS 実機上での自動テストをより楽に有意義にする為に ～端末管理・イメージ転送・動画 記録等の周辺情報のノウハウ共有～」  Unite Tokyo 2019 「大量のアセットも怖くない！～HTTP/2による高速な通信の実装例～」  CEDEC 2018、CEDEC 2016、CEDEC 2015 プロダクション関連のラウンドテーブル  GDC2016 報告会 「GDC16にみる自動化技術とテストのトレンド」
3. 自己紹介 (プライベート) 【登壇歴】  CEDEC 2025 「ゲーム業界におけるリアルタイム通信プロトコルの最適な選択肢を探るラウンドテーブル 2025」  CEDEC 2023 「ゲーム業界におけるリアルタイム通信プロトコルの最適な選択肢を探るラウンドテーブル」  CEDEC 2020 技術同人作家になろう ～働き方改革時代におけるエンジニアのレベルアップの一例～ 【著書（技術同人誌）】  ゲームリアルタイム通信プロトコル コミュニティ 会合誌 Vol.1 (2026)  『くいっく』 DATAGRAM 編 RFC対応版 (2024)  『くいっく』 HTTP/3 編 RFC対応版 (2022) 【運営】  「ゲームリアルタイム通信プロトコル」コミュニティ
4. おしながき 1. ゲーム特有の多様な通信要求 2. ゲームにおけるリアルタイム通信に関する工夫 3. ゲームでの QUIC 活用事例 4. ゲームとリアルタイム通信のプロトコルの今後
5. ゲーム特有の多様な通信要求
6. ゲーム特有の多様な通信要求 1. 一つのゲームの中に性質の違う通信が共存している 2. ジャンルによって要求スペックが全く異なる 3. 世界中の実環境でなるべく平等に動かなければならない 4. 対応しなければならないクライアントプラットフォームが多種多様
7. 一つのゲームの中に性質の違う通信が共存 している ゲームプレイの同期・チャット・観戦・配信等が一つのゲームの中に共存している 同じゲームの中でも「何を、いつまでに、どう届けるか」が異なる
8. データの扱いに求めること ※あくまでざっくりとした例であって、ゲームの内容によって実際の扱いは異なる ※有効期限 → それを過ぎると本来のタイミングでは利用できなくなる期限
9. ゲームの遊び方・設計によって通信要求が 異なる ※あくまでざっくりとした例であって、ゲームの内容によって実際の扱いは異なる
10. 世界中の実環境でなるべく平等に動かなけ ればならない 遅延や通信の揺らぎでの対戦結果や体験の優劣を出さない  プレイヤーは世界各地の家庭回線や無線環境から参加する  予測・補正で遅延の影響を抑える際も、他のプレイヤーへの影響を考える必要がある
11. 対応しなければならないプラットフォームが 多種多様 同じゲームをPC・スマートフォン・家庭用ゲーム機で機種をまたいでプレイさせたい  プラットフォームごとに開発環境や利用できるライブラリの条件が異なる  適合する OSS のライブラリがあっても移植・ゲームエンジンとの連携・実機検証・継続 的な保守が必要になる  クローズドなプラットフォームでは採用可否を判断しにくい 機能だけでなく、すべての対応機種で実装・検証・保守できるかが採用の条件
12. ゲームにおけるリアルタイム通信に関す る工夫
13. 工夫① 自分の操作を先行して反映する 1. ボタンを押下後、ローカルではすぐにキャラクターへ反映 2. 同時に操作をサーバへ送り、サーバ側でも移動を反映 3. 結果が食い違った場合は、サーバの結果に合わせて補正
14. 工夫② 相手の操作の反映を少し待って補 正を掛ける 1. 少し過去の位置情報をバッファ 2. 最新の相手の位置情報を受信 3. 位置情報を補間して滑らかに表示 ※待ち時間を増やすと揺らぎは吸収しやすいが、相手の動きが遅れて見える
15. 工夫③ 未来予測を行い、間違っていたら ロールバックする 1. まだ届いていない相手の入力を予測する 2. 予測した入力でゲームを先に進める 3. 届いた入力が予測の値と異なる場合、過去の状態へロールバックして再計算を行う 予測 相手は立ち 攻撃がヒット 現在 実際の入力が到着し予測とはずれた為に過去に処理を戻す 現実 相手はしゃがみ 攻撃が外れる 現在
16. 工夫④ 入力が失われても回収できるよう、 次の送信にも含める 最新入力に直近の過去入力も含め、パケットロス時に欠落した入力を補間する 前々回のデータ 120,50,10 110,50,10 100,50,10 前回のデータ (パケットロス) 130,50,10 120,50,10 110,50,10 今回のデータ 140,50,10 130,50,10 120,50,10 ロスしたデータを補間できる
17. 工夫⑤ 必要な情報を選別して送る 1. ゲームプレイへの影響が小さいプレイヤーは更新頻度や情報量を下げる  2. 距離が遠かったり、画面に見えていない等 距離が近づいてくる等で影響の度合いが高まったらそれに合わせて通信頻度を高め ていく 他プレイヤー① 自分 近いので 0.1 秒間隔でデータ送信！ 遠い(影響が小さいので)ので 1 秒間隔で十分 他プレイヤー②
18. ゲームでの QUIC 活用事例
19. ゲームでの QUIC 活用事例 今回紹介する二例は、 CEDEC 2025 『ゲームにおけるリアルタイム通信への QUIC導 入事例の紹介』 にて発表された内容より抜粋してお伝えしております より詳細な情報が知りたい場合は https://speakerdeck.com/segadevtech/cedec-2025gemuniokeruriarutaimutong-xin-heno-quicdao-ru-shi-li-noshao-jie を参照ください
20. SONIC RUMBLE QUIC 導入概要    新規の内製リアルタイムネットワークライブラリ Nemofiller に QUIC を採用  自前で RUDP の実装をしたくなかった  C# での QUIC 実装がなく、結局各プラットフォーム対応はそれなりにコストが掛かった QUIC 使い分け  QUIC-STREAM : 到達保証と順序保証が必要な RELIABLE なデータに利用  QUIC-DATAGRAM ： 再送を行わない UNRELIABLE なデータに利用 QUIC で接続できない場合は TCP へフォールバック  TCP へのフォールバック発生率は平均 0.014% だった
21. SONIC RUMBLE QUIC はリアルタイム通信ゲームのプロトコルになり得た？ 多人数接続・高頻度通信下において以下を確認  揺らぎはあるものの、比較的安定した RTT 値  理論値と乖離の少ない RTT 値  通信相手との距離に応じた RTT 値 QUIC はリアルタイム通信のプロトコルになり得た
22. SONIC RUMBLE QUIC-DATAGRAM の運用上の課題 切断判定に至るケースが一定割合で発生     原因推測  非効率なメッセージ送信を数多く送る実装になっていた  通信量の割にパケット数が多く、通信経路上の機器でパケットドロップが起きたと推測 対策  送信データをなるべくまとめた  QUIC-DATAGRAM の ACK の影響も懸念された為に UDP へ暫定変更した 結果  切断判定の件数が減少  その後、ゲームの体感を変えない範囲で更に送信データをまとめ、切断判定の件数はさらに減少 課題  QUIC-DATAGRAM の ACK の有無や頻度を制御できる機能への要求が残った  https://datatracker.ietf.org/doc/draft-ietf-quic-ack-frequency/ に期待(竹原感想)
23. Sphingo Connection Migration 導入の背景  内製リアルタイムネットワークライブラリ Sphingo   TCP・UDP 上に SCTP ベースの独自プロトコルを実装 この Sphingo の対応プロトコルに QUIC を追加した事例  既存タイトルでクライアントの接続回線が切り替わった際の自動復旧が必要になった  独自プロトコルの維持管理コストを抑え、標準プロトコルを選択肢に加える為 QUIC を選択
24. Sphingo Connection-Migration 導入における課題  QUIC は通信経路の切り替えに配慮のあるプロトコル     (裏を返すと)実際には具体的な実装は各々で行う必要がある 実装のポイント  Winsock/NDIS など OS のネットワークスタックが変化を吸収し、アプリケーションから IP 変更を検出しにくい場合がある  IP やポートが変わっても接続が維持され、明確なコールバックがないケースがある 動作確認のポイント  NAT や切り替えタイミングの影響があり、仮想環境だけでは完全な確認にならない  クライアント環境によって実装対応が異なり、テスト環境の組み合わせが大きくなる 結論  標準仕様を使っても、プラットフォーム対応・サーバ対応・実環境テストは各自で必要  Connection-Migration は、仕様があること自体に価値がある
25. MoQ とゲームの接点、コミュニティの 取り組み
26. MoQ とゲームの適合 ※ゲームのリアルタイム通信に MoQ を採用した具体的な事例ではなく、 MoQ のモデル とゲーム側の要求を対応付けのアイデア
27. 「ゲームリアルタイム通信プロトコル」コミュニティ  活動目的   ゲーム業界においてリアルタイム通信で使用されるプロトコルについて情報交換を行い、業 界全体でリアルタイム通信の品質向上を目指す 活動の流れ 1. ゲームのリアルタイム通信における QUIC の採用事例を集める 2. 並行でゲームのリアルタイム通信に必要な要素を整理 3. 必要な要素ベースで QUIC の採用事例を評価 4. QUUIC に不足があればゲーム向けプロトコルを検討する 議事録等 → TakeharaR/game-realtime-protocol
28. 「ゲームリアルタイム通信プロトコル」コミュニティ 現在の議論   活動を進める中で見えてきたこと  公開されている QUIC の公開採用事例が少なく、比較材料の収集が十分に進んでいない  ゲームのリアルタイム通信に必要な要素を仕様・実装・環境ベースで整理したものの、網羅 的に並べると大きくなり、個別のゲームの要求に適合し辛い 現在の方向  単一のゲーム用のリアルタイム通信プロトコルを求めるのではなく、ユースケースから要求・ト レードオフ・評価指標・試験条件を整理する  必要に応じて、標準プロトコルの拡張やゲーム向けプロトコルを検討する
29. まとめ  リアルタイム通信には様々な要求があるが、ゲームではその振れ幅が特に大きい  同じゲームの中でも、入力・状態同期・イベント・観戦など性質の異なる通信が共存する  ゲームの設計によっても要求が大きく変わる  ゲームのリアルタイム通信で用いるプロトコルを評価する際は、性能面だけでなくゲー ム体験への影響や実装、保守コストまで含めて考える必要がある  QUIC / MoQ についてもゲーム内のどの通信に適合するかという観点が重要