オンラインゲームの仕組みと工夫

1. オンラインゲームの仕組みと⼯工夫 @imai_̲factory

2. はじめに •  さいきんゲーム関連の仕事をすることが多くなったのでオンラインゲームについて調べてみた。 •  の、内容を社内勉強会で発表したスライド。

3. Citations •  きっかけはこのセガの節政さんのCEDEC の発表。 – http://www.4gamer.net/games/105/ G010549/20100905002/ – オンラインゲームを4つのタイプにカテゴライズしつつ、それぞれの実装コンセプトを紹介してくれている。

4. オンラインゲームの種類 •  完全同期型/キー⼊入⼒力力同期⽅方式 –  格ゲーなど •  完全同期型/コマンド⼊入⼒力力同期⽅方式 –  RTS（Age of Empiresとか） •  ⾮非同期型/サーバー集中処理理型 –  FPSなど（QuakeとかCounterStrikeとか） •  ⾮非同期型/クライアント分散処理理型 –  PSU

5. 完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1 F2 F3 F4 F5 F6 キー双方のデータが届いてからレンダーして次のフレームの処理へプレイヤーすべての処理をお互いに待ち合うので、少人数でないと成り立ちにくい ➔スケールさせづらい PlayerA PlayerB 60FPSだと1フレームは16.666..ms

6. 完全同期型/コマンド⼊入⼒力力同期⽅方式 •  RTSやターンベースのゲームさきほどと同様、お互いを待ち合う必要があるが、格ゲーなどと較べて1フレームや1ターンに掛けられる時間が長いケースが多い。特にターンベースなら数十秒や数分ということも。 PlayerA PlayerB コマンド F1/T1 F2/T2 F3/T3 F4/T4 F5/T5 F6/T6

7. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 F2 F3 F4 F5 F6 •  Client、Serverはそれぞれ独立したクロックで動作する •  ゆえにそれぞれのローカルでは軽快に動作させられる •  ダメージやアイテム取得などはサーバー側で処理 State Command State Command State Command State Command State Command State Command State Command State Command State Command State Command

8. ⾮非同期型/クライアント分散処理理型 •  PSU PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 F2 F3 F4 F5 F6 •  Client、Serverはそれぞれ独立したクロックで動作する •  Client側でダメージやアイテム取得を判断して、Server側でValida@on •  サーバー側を待つ処理がより少ないので快適度があがる State Command State Command State Command State Command State Command State Command State Command State Command State Command State Command 参考 hBp://www.mmorpg.com/gamelist.cfm/game/215/view/forums/thread/104863/PSU-‐netcode.html

9. オンラインゲームとレイテンシ •  ⾮非同期型のゲームでは、クライアントはお互いの待ち合わせを⾏行行わない •  そのためサーバーとの通信レイテンシが⼤大きいと⾃自分よりも世界のほうが速く進んでしまう •  結果として、右の絵のように、画⾯面上に過去の世界の状態が表⽰示されてしまう •  ⾒見見た⽬目上の位置に発砲しても実際の位置は違うので当たらない https://github.com/rase-‐‑‒/socket.io-‐‑‒workshop-‐‑‒full

10. レイテンシについての実際の調査 •  Unreal Tournament 2003 – 3% packet loss and 140ms latency at maximum – 75ms以上だとユーザーがラギーに感じる – 100msを超えると遊びづらくなる T. Beigbeder, R. Coughlan, C. Lusher, J. PlunkeB, E. Agu, and M. Claypool, “The eﬀects of loss and latency on user performance in unreal tournament 2003,” in Proceedings of the 3rd ACM SIGCOMM Workshop on Network and System Support for Games, ACM, Portland, Ore, USA, 2004.

11. •  FIFA soccer – 150msを超えるとゲームが成り⽴立立たない – 実際の平均レイテンシは118ms レイテンシについての実際の調査 M. Dick, O. Wellnitz, and L. Wolf, “Analysis of factors aﬀec@ng players’ performance and percep@on in mul@player games,” in Proceedings of the 4th ACM SIGCOMM Workshop on Network and System Support for Games, ACM, Hawthorne, NY, USA, 2005.

12. •  World of Warcraft 3 – 平均RTTで100ms – 500msくらいまでならゲーム可能 – 800msを超えるとゲームが成り⽴立立たないレイテンシについての実際の調査 N. Sheldon, E. Girard, S. Borg, M. Claypool, and E. Agu, “The eﬀect of latency on user performance in Warcrab III,” in Proceedings of the 2nd Workshop on Network and System Support for Games, ACM, Redwood City, Calif, USA, 2003.

13. •  A racing game –  レイテンシが50msを超えるとラップタイムが落落ち始める –  だが上級者なら150msくらいまで影響を受けない –  50ms以下のレイテンシはユーザーに気づかれない –  200msを超えると明らかにラギーに感じる –  500msになるとゲームが成り⽴立立たないレイテンシについての実際の調査 L. Pantel and L. C. Wolf, “On the impact of delay on real-‐@me mul@player games,” in Proceedings of the 12th Interna@onal Workshop on Network and Opera@ng Systems Support for Digital Audio and Video, ACM, Miami, Fla, USA, 2002.

14. •  Shen Zhou Online(MMORPG) – 150ms以下のレイテンシにおける平均プレイ時間は4時間 – 250msだと平均1時間レイテンシについての実際の調査 K.-‐T. Chen, P. Huang, and C.-‐L. Lei, “How sensi@ve are online gamers to network quality?” Communica@ons of the ACM, vol. 49, no. 11, pp. 34–38, 2006.

15. •  Half-‐‑‒Life(FPS) – 50msを超えると結構つらいレイテンシについての実際の調査 T. Henderson and S. Bhah, “Networked games—a QoS-‐ sensi@ve applica@on for QoS-‐insensi@ve users?” in Proceedings of the ACM SIGCOMM Workshop on Revisi@ng IP QoS: What Have We Learned, Why Do We Care? pp. 141–147, ACM, Karlsruhe, Germany, 2003.

16. •  Madden NFL Football – 500msくらいまでならユーザーは気づかない – 750msになるとラギーだと思われ始めるレイテンシについての実際の調査 J. Nichols and M. Claypool, “The eﬀects of latency on online Madden NFL football,” in Proceedings of the 14th Interna@onal Workshop on Network and Opera@ng System Support for Digital Audio and Video, pp. 146–151, ACM, Cork, Ireland, 2004.

17. ここで⾒見見てきたように、ゲームのジャンルや特性によって許容可能なレイテンシやラグは全く異異なる。レイテンシについての実際の調査

18. レイテンシとパケットロス •  もちろんレイテンシだけでなくパケットロス率率率も重要な要素。 •  しかし、レイテンシにシビアなゲームではTCPではなくUDP が利利⽤用されることが多い。 •  TCPによる再送されたパケットが届いても既に古くて使い物にならないため。 •  このあと解説するQUAKEでは、UDPを使いつつ、過去32フレーム分のデータを毎回送ることでパケットロスへの耐性を上げている。

19. QUAKE

20. QUAKEについて QUAKEがオープンソースになっていることを思い出したので調べてみた。コードを読む根性はなかったので、 QUAKE 3 SOURCE CODE REVIEW: ARCHITECTURE を参考に下記をまとめた。マジ感謝。 •  アーキテクチャと動作フロー •  ネットワークについての⼯工夫 •  予測

21. Architecture Overview Client A Client B Server Command Command Game status for A Game status for B

22. アーキテクチャサーバーはクライアントに毎フレーム下記の情報を送る •  他のプレイヤーの位置と加速度度 •  再⽣生すべき⾳音声やエフェクト •  これらをまとめてスナップショット（ゲーム世界のある瞬間のスナップショット）と呼ぶクライアントも毎フレーム下記の情報をサーバーに送る •  タイムスタンプ •  ⾒見見ている⽅方向（ピッチ、ヨー、ロール） •  押されているボタン •  装備している武器のコード •  加速度度

23. サーバーからクライアントに送信されるスナップショットのイメージ { time: T players: [ { player: B, position: {..}, velocity: {...}, life:...,}, { player: C, position...}, ... ], ... }

24. 動作フローサーバーサイドの動作フロー •  クライアントからコマンドを受け付けゲームエンジンに渡す •  50msごとにフレームの描画命令令をゲームエンジンに発⾏行行。 •  そのフレームの情報をクライアントに送信するクライアントサイドの動作フロー •  アクティブなフレームの描画命令令を発⾏行行 •  サーバーからあたらしいスナップショットが届いていないかを確認。届いていたらそのスナップショットを最新のものとして次に処理理するように設定。 •  クライアントは最新のスナップショット、ローカルプレイヤーのコマンド、そこから導きだされる必要な未来予測をもとに画⾯面を描画。

25. 動作フロー Server Net Channel Render Engine Controller Predic@on Net Channel Client Render! Snapshot Snapshot Predic@on from snapshot Command

26. ネットワークについての⼯工夫 [ { time: T players: [...] }, { time: ... players: [...] }, { time: T-‐‑‒31 players: [...] }, ] サーバーは最大で過去32フレーム分のスナップショットを送信するこれによりパケットロス耐性を実現している Latest Latest -‐... Latest -‐31

27. ネットワークについての⼯工夫 Server Player A Master snapshot Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=D Snapshot1 Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=D 最初のスナップショットを送信

28. ネットワークについての⼯工夫 Server Player A Master snapshot Player B: pos[0]=A, pos[1]=E, pos[2]=C, health=D Snapshot1 Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=D Ack Player AがAck Player Bが移動

29. ネットワークについての⼯工夫 Server Player A Master snapshot Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=H Snapshot1 Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=D Ack Snapshot2 Player B: pos[0]=A, pos[1]=E, pos[2]=C, health=D ? 次のフレームのスナップショットを送るが、AckされないマスターのSnapshotは常に進んで行く

30. ネットワークについての⼯工夫 Server Player A Master snapshot Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=H Snapshot1 Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=D Ack Snapshot1 Player B: pos[0]=A, pos[1]=B, pos[2]=C, health=D ? Snapshot1 Player B: pos[0]=A, pos[1]=E, pos[2]=C, health=H 次の送信時には、Ackされていないところから最新のフレームまで送信

31. Pre-‐‑‒fragmentation •  UDPは65,507バイトのペイロードを伝送可能だが、QUAKEがのNet Channelというプロトコルでは1つの意味のあるやりとりを1400バイト以内で伝えられるようにしている。 •  これは⼀一般的なMTUである1500バイト以内にパケットサイズを抑えることでフラグメンテーションを回避し、意味のあるやりとりの完遂率率率をあげるための⼯工夫。

32. Prediction •  60fpsのゲームを実現しようとした場合、すべてのフレームを実データで描画しようとした場合、サーバーからクライアントに秒間60個のスナップショットを遅滞なく届ける必要がある。 •  しかしこれは膨⼤大なネットワークリソースを必要とするうえ、パケットロスやレイテンシに⾮非常に脆弱になる。 •  これを解決するために、実際には秒間10個〜～20個のスナップショットを送るにとどめ、残りはクライアント側でスナップショットからの予測（Prediction)を使って画⾯面を描画するという⼯工夫がなされている。

33. Prediction Player B 最新のスナップショット Player B: pos[0]=A, pos[1]=B, pos[2]=C, velocity=... 次のスナップショットの予測 Player B: pos[0]=A’, pos[1]=B’, pos[2]=C’, velocity=... Player B Player B 次のスナップショットが到着するまでの間の Player Bの予測はクライアント側で予測して描画する

34. Prediction •  予測が⼤大きく外れると、次のスナップショットが到着したときにユーザーの位置が⼤大きく修正される。⾒見見た⽬目上、当該ユーザーがワープしたように⾒見見える。 •  ⾼高速度度での移動中における急激な⽅方向転換などを⾏行行うとこういうことが起きやすい。 •  ゲームによっては、急激な⽅方向転換を許容しない（たとえば物理理法則にしたがった⽅方向転換を強制する）ことによってこういった事象を防ぐ⼯工夫をしている

35. Prediction Player B 最新のスナップショット Player B: pos[0]=A, pos[1]=B, pos[2]=C, velocity=... 次のスナップショットの予測 Player B: pos[0]=A’, pos[1]=B’, pos[2]=C’, velocity=... Player B Player B 次のスナップショットが到着するまでの間の Player Bの予測はクライアント側で予測して描画する

36. さらに

37. ⼿手元でFPSを動かしてみる •  node学園2014で、socket.ioでFPS を動かすワークショップがあったので⼿手元で動かしてみた。 •  実装を⾒見見てみると、やはりQUAKE と同じようにフレームごとのスナップショットをクライアントに送信し、それをもとにフレーム描画を⾏行行うようになっていた。 •  WebGLとThree.js、すげー！ https://github.com/rase-‐‑‒/socket.io-‐‑‒workshop-‐‑‒full

38. ⼿手元でFPSを動かしてみる •  データストアとしてRedisを採⽤用しており、プレイヤーのライフなどを格納している •  データの更更新はダメージを受けた時やライフを失ったときなど、⼤大きなイベントが発⽣生したときのみ⾏行行われるようになっている。 •  FPSでのデータベースの利利⽤用の例例として⾮非常に参考になる。 https://github.com/rase-‐‑‒/socket.io-‐‑‒workshop-‐‑‒full

39. まとめ

40. まとめ •  オンラインゲームでは、ユーザー間、クライアント間でゲームのステータス（お互いの位置やライフなど）をいかに遅滞なく同期してやるのか、というのが⾮非常に重要。 •  インターネットという信頼性の低いネットワーク上でこれを実現するためにいろいろな⼯工夫がなされてきている。 •  FQUAKEがオープンソースになっているのが⾮非常にエポックメイキングなできごとだったようで、それ以降降のアクション系のゲームはみなこれを多かれ少なかれ参考にしている。

オンラインゲームの仕組みと工夫

Yuta Imai

Transcript