オンラインゲームの仕組みと工夫
•
268 likes•874,035 views
オンラインゲームの仕組みや工夫を調べてみたのを社内勉強会で発表した。ときのスライド。の公開用。 オンラインゲームの種別とそれぞれの仕組みについての話と、オープンソースになっているQuakeの仕組みの話、という2つの話が主なトピック
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to オンラインゲームの仕組みと工夫
Similar to オンラインゲームの仕組みと工夫 (20)
More from Yuta Imai
More from Yuta Imai (20)
Recently uploaded
Recently uploaded (14)
オンラインゲームの仕組みと工夫
- 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 effects 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 affec@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 effect 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 effects 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.
- 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バイト以内にパ ケットサイズを抑えることでフラグメンテーショ ンを回避し、意味のあるやりとりの完遂率率率をあげ るための⼯工夫。
- 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の話は、それだけで多数論論⽂文が⾒見見つかる感じで、 オンラインゲームのなかでも⾮非常に重要で注⽬目度度の⾼高いト ピックらしい。 • 分散システム好きとしては、多数のクライアントから⾶飛んで きたコマンドの衝突の解決や⼀一貫性の保ち⽅方なども⾮非常に興 味深い分野だと思う。今回ちょっと⾒見見かけた感じだと、ベク タークロックみたいな⽅方式を使ってひとつを取るパターンや、 平均値をとるパターンなど、いろいろやりかたがあるっぽい。