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

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

6. 完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1 F2 F3 F4 F5 F6 キー PlayerA PlayerB

7. 完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1 F2 F3 F4 F5 F6 キー PlayerA PlayerB キー

8. 完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1 F2 F3 F4 F5 F6 キー PlayerA PlayerB キー双方のデータが届いてからレンダーして次のフレームの処理へレンダー

9. 完全同期型/キー⼊入⼒力力同期⽅方式 PlayerA PlayerB キー F1/T1 F2/T2 F3/T3 F4/T4 F5/T5 F6/T6 •  格ゲーなどユーザーがお互いを待ち合わせする必要があるので、レイテンシの⾼高いユーザーに⾜足を引っ張られる。なので⼤大きくスケールさせるのは難しいキーレンダー •  あとはこの繰り返し。 •  60fpsの場合、1フレームは16.6666...ms

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

11. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 F2 F3 F4 F5 F6

12. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot まずはサーバーからPlayerに世界の状態のSnapshotが配布されて、それをもとにそれぞれのプレイヤーマシンで画⾯面レンダリング

13. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot State State render render Snapshot サーバーは⾃自分のペースで次のフレームの世界のスナップショットを作り、同じように配る

14. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot State State render render Snapshot Command Command 同時にプレイヤーも活動を始める。プレイヤーからはコマンドがサーバーに送られてくる。

15. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot State State render render Snapshot Command Command State render render Snapshot 各プレイヤーのF2で送信されたコマンドは、サーバー上のF3のフレームで処理理（当たり判定やアイテム取得判定）され、世界のスナップショットに反映されふたたびプレイヤーに配られる

16. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot State State render render Snapshot Command Command State render render Snapshot State render render Snapshot State render render Snapshot Command Command Command Command Command Command あとはその繰り返し

17. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot State State render render Snapshot Command Command State render render Snapshot State render render Snapshot State render render Snapshot Command Command Command Command Command Command •  Client、Serverはそれぞれ独立したクロックで動作する •  Clientはコマンド送信と画面描画のみを管理し、当たり判定などはサーバー側で行う。 •  なので自分の発行したコマンドの結果はサーバーからの返事をまって見た目上の世界に適用される。

18. ⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot State render Snapshot Command render Snapshot render Snapshot render Snapshot Command Command Command •  実際には下記のようにレイテンシの高いユーザーがいることが多い。 •  そういったユーザーのから見た世界は、サーバーよりも遅れている。（ラグ） State render State render State render State render Command Command Command Command

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

20. オンラインゲームとネットワーク •  基本的にオンラインゲームではフレームやターンなど、そのゲームの単位時間ごとに各ユーザーの情報をスナップショットとして同期している。 •  理理論論上、60fpsのゲームなら秒間60回の情報同期をすることに！（実際にはこれを減らす様々な⼯工夫があることもわかった） •  考えてみれば確かに当然なのだが、Web屋の⾃自分にとっては結構衝撃的。 •  ということで、オンラインゲームはネットワークの品質や性能に⼤大きく依存している。

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

22. レイテンシについての実際の調査 •  Unreal Tournament 2003 – 3% packet loss and 140ms latency at maximum – 75ms以上だとユーザーがラギーに感じる – 100msを超えると遊びづらくなる T. Beigbeder, R. Coughlan, C. Lusher, J. PlunkeA, 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.

23. •  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.

24. •  Warcraft III – 平均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.

25. •  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.

26. •  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.

27. •  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.

28. •  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.

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

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

31. QUAKE

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

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

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

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

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

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

38. 動作フロー •  サーバーのスナップショット送信は50msごと •  そのあいだの動きはクライアント側で予測（Prediction）して補完 PlayerA PlayerB F1 F2 F3 F4 F5 F6 Server F1 F2 F3 F4 F5 F6 F1 State F2 F3 F4 F5 F6 State render render Snapshot State render render Command Command render render State render render Snapshot render render Command Command Command Command Command Command この間はクライアント側で予測補完

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

40. ネットワークについての⼯工夫 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 最初のスナップショットを送信

41. ネットワークについての⼯工夫 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が移動

42. ネットワークについての⼯工夫 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は常に進んで行く

43. ネットワークについての⼯工夫 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されていないところから最新のフレームまで送信

44. ネットワークについての⼯工夫 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]=0, pos[1]=+2, pos[2]=0, health=-‐2 更にデータサイズを小さくするため、前のフレームからの差分を取るデルタ圧縮方式を利用している

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

46. ネットワークへのゲーム仕様の依存？ •  ここまでのネットワーク周りの⼯工夫を⾒見見る限り下記のことが⾔言える気がする。 •  「1パケットにどれだけのユーザーの情報を詰め込めるのか？」というところに、そのゲームのフレームレートや同時プレイ可能⼈人数が依存している・・！

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

48. 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の予測はクライアント側で予測して描画するさらにネットワーク依存を軽減する: Prediction

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

50. さらに

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

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

53. まとめ

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

55. ここからさきは？

56. 他にも •  今回はおもにネットワークとレイテンシの話にフォーカスを絞ったが・・・ •  Predictionの話は、それだけで多数論論⽂文が⾒見見つかる感じで、オンラインゲームのなかでも⾮非常に重要で注⽬目度度の⾼高いトピックらしい。 •  分散システム好きとしては、多数のクライアントから⾶飛んできたコマンドの衝突の解決や⼀一貫性の保ち⽅方なども⾮非常に興味深い分野だと思う。今回ちょっと⾒見見かけた感じだと、ベクタークロックみたいな⽅方式を使ってひとつを取るパターンや、平均値をとるパターンなど、いろいろやりかたがあるっぽい。

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to オンラインゲームの仕組みと工夫 (20)

More from Yuta Imai (20)

Recently uploaded (20)