Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•
•
Yuta Imai
Yuta Imai

オンラインゲームの仕組みや工夫を調べてみたのを社内勉強会で発表した。ときのスライド。の公開用。 オンラインゲームの種別とそれぞれの仕組みについての話と、オープンソースになっているQuakeの仕組みの話、という2つの話が主なトピック

1 of 56
Downloaded 310 times
オンラインゲームの仕組みと⼯工夫 @imai_̲factory
はじめに •  さいきんゲーム関連の仕事をすることが 多くなったのでオンラインゲームについ て調べてみた。 •  の、内容を社内勉強会で発表したスライ ド。
Citations •  きっかけはこのセガの節政さんのCEDEC の発表。 – http://www.4gamer.net/games/105/ G010549/20100905002/ – オンラインゲームを4つのタイプにカテゴラ イズしつつ、それぞれの実装コンセプトを紹 介してくれている。
オンラインゲームの種類 •  完全同期型/キー⼊入⼒力力同期⽅方式 –  格ゲーなど •  完全同期型/コマンド⼊入⼒力力同期⽅方式 –  RTS（Age  of  Empiresとか） •  ⾮非同期型/サーバー集中処理理型 –  FPSなど（QuakeとかCounterStrikeとか） •  ⾮非同期型/クライアント分散処理理型 –  PSU
完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1   F2   F3   F4   F5   F6   PlayerA   PlayerB  
完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1   F2   F3   F4   F5   F6   キー   PlayerA   PlayerB  
完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1   F2   F3   F4   F5   F6   キー   PlayerA   PlayerB   キー  
完全同期型/キー⼊入⼒力力同期⽅方式 •  格ゲーなど F1   F2   F3   F4   F5   F6   キー   PlayerA   PlayerB   キー   双方のデータが届いてからレンダーして次のフレームの処理へ   レンダー  
完全同期型/キー⼊入⼒力力同期⽅方式 PlayerA   PlayerB   キー   F1/T1   F2/T2   F3/T3   F4/T4   F5/T5   F6/T6   •  格ゲーなど ユーザーがお互いを待ち合わせする必要があるので、レイテンシの⾼高い ユーザーに⾜足を引っ張られる。なので⼤大きくスケールさせるのは難しい キー   レンダー   •  あとはこの繰り返し。 •  60fpsの場合、1フレームは16.6666...ms
完全同期型/コマンド⼊入⼒力力同期⽅方式 •  RTSやターンベースのゲーム さきほどと同様、お互いを待ち合う必要があるが、格ゲーなどと較べて1フレー ムや1ターンに掛けられる時間が長いケースが多い。特にターンベースなら数 十秒や数分ということも。   PlayerA   PlayerB   コマンド   F1/T1   F2/T2   F3/T3   F4/T4   F5/T5   F6/T6  
⾮非同期型/サーバー集中処理理型 •  FPSなど PlayerA   PlayerB   F1   F2   F3   F4   F5   F6   Server   F1   F2   F3   F4   F5   F6   F1   F2   F3   F4   F5   F6  
⾮非同期型/サーバー集中処理理型 •  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が配布 されて、それをもとにそれぞれのプレイヤーマシンで画⾯面レンダリング
⾮非同期型/サーバー集中処理理型 •  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   サーバーは⾃自分のペースで次のフレームの世界のスナップショットを作り、 同じように配る
⾮非同期型/サーバー集中処理理型 •  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   同時にプレイヤーも活動を始める。プレイヤーからはコマンドがサーバーに 送られてくる。
⾮非同期型/サーバー集中処理理型 •  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のフレームで 処理理（当たり判定やアイテム取得判定）され、世界のスナップショットに反映され ふたたびプレイヤーに配られる
⾮非同期型/サーバー集中処理理型 •  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   あとはその繰り返し
⾮非同期型/サーバー集中処理理型 •  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はコマンド送信と画面描画のみを管理し、当たり判定などはサーバー側で行う。   •  なので自分の発行したコマンドの結果はサーバーからの返事をまって見た目上の世界に適用 される。
⾮非同期型/サーバー集中処理理型 •  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  
•  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  
オンラインゲームとネットワーク •  基本的にオンラインゲームではフレームやターンなど、そのゲーム の単位時間ごとに各ユーザーの情報をスナップショットとして同期 している。 •  理理論論上、60fpsのゲームなら秒間60回の情報同期をすることに！ （実際にはこれを減らす様々な⼯工夫があることもわかった） •  考えてみれば確かに当然なのだが、Web屋の⾃自分にとっては結構衝 撃的。 •  ということで、オンラインゲームはネットワークの品質や性能に⼤大 きく依存している。
オンラインゲームとレイテンシ •  ⾮非同期型のゲームでは、クライアントは お互いの待ち合わせを⾏行行わない •  そのためサーバーとの通信レイテンシが ⼤大きいと⾃自分よりも世界のほうが速く進 んでしまう •  結果として、右の絵のように、画⾯面上に 過去の世界の状態が表⽰示されてしまう •  ⾒見見た⽬目上の位置に発砲しても実際の位置 は違うので当たらない https://github.com/rase-‐‑‒/socket.io-‐‑‒workshop-‐‑‒full
レイテンシについての実際の調査 •  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.  
•  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.      
•  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.  
•  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.  
•  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.  
•  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.  
•  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.  
ここで⾒見見てきたように、ゲームのジャンル や特性によって許容可能なレイテンシやラ グは全く異異なる。 レイテンシについての実際の調査
レイテンシとパケットロス •  もちろんレイテンシだけでなくパケットロス率率率も重要な要素。 •  しかし、レイテンシにシビアなゲームではTCPではなくUDP が利利⽤用されることが多い。 •  TCPによる再送されたパケットが届いても既に古くて使い物 にならないため。 •  このあと解説するQUAKEでは、UDPを使いつつ、過去32フ レーム分のデータを毎回送ることでパケットロスへの耐性を 上げている。
QUAKE
QUAKEについて QUAKEがオープンソースになっていることを思い出し たので調べてみた。コードを読む根性はなかったので、 QUAKE  3  SOURCE  CODE  REVIEW:  ARCHITECTURE を参考に下記をまとめた。マジ感謝。 •  アーキテクチャと動作フロー •  ネットワークについての⼯工夫 •  予測
Architecture  Overview Client  A   Client  B   Server   Command   Command   Game  status  for  A   Game  status  for  B  
アーキテクチャ サーバーはクライアントに毎フレーム下記の情報を送る •  他のプレイヤーの位置と加速度度 •  再⽣生すべき⾳音声やエフェクト •  これらをまとめてスナップショット（ゲーム世界のある瞬間 のスナップショット）と呼ぶ クライアントも毎フレーム下記の情報をサーバーに送る •  タイムスタンプ •  ⾒見見ている⽅方向（ピッチ、ヨー、ロール） •  押されているボタン •  装備している武器のコード •  加速度度
サーバーからクライアントに送信されるス ナップショットのイメージ { time:  T players:  [ {  player:  B,  position:  {..},  velocity:  {...},      life:...,}, {  player:  C,  position...}, ...   ], ... }
動作フロー サーバーサイドの動作フロー •  クライアントからコマンドを受け付けゲームエンジンに渡す •  50msごとにフレームの描画命令令をゲームエンジンに発⾏行行。 •  そのフレームの情報をクライアントに送信する クライアントサイドの動作フロー •  アクティブなフレームの描画命令令を発⾏行行 •  サーバーからあたらしいスナップショットが届いていないかを確 認。届いていたらそのスナップショットを最新のものとして次に 処理理するように設定。 •  クライアントは最新のスナップショット、ローカルプレイヤーの コマンド、そこから導きだされる必要な未来予測をもとに画⾯面を 描画。
動作フロー Server   Net   Channel   Render   Engine   Controller   Predic@on   Net   Channel   Client   Render!   Snapshot   Snapshot   Predic@on  from   snapshot   Command  
動作フロー •  サーバーのスナップショット送信は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   この間はクライアント側で予測補完  
ネットワークについての⼯工夫 [ { time:  T players:  [...] }, { time:  ... players:  [...] }, { time:  T-‐‑‒31 players:  [...] }, ] サーバーは最大で過去32フ レーム分のスナップショットを 送信する これによりパケットロス耐性を 実現している Latest   Latest  -­‐...   Latest  -­‐31  
ネットワークについての⼯工夫 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   最初のスナップショットを送信  
ネットワークについての⼯工夫 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が移動  
ネットワークについての⼯工夫 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は   常に進んで行く  
ネットワークについての⼯工夫 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されていないところから   最新のフレームまで送信  
ネットワークについての⼯工夫 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   更にデータサイズを小さくするため、前のフレームから の差分を取るデルタ圧縮方式を利用している  
Pre-‐‑‒fragmentation •  UDPは65,507バイトのペイロードを伝送可能だ が、QUAKEがのNet  Channelというプロトコルで は1つの意味のあるやりとりを1400バイト以内で 伝えられるようにしている。 •  これは⼀一般的なMTUである1500バイト以内にパ ケットサイズを抑えることでフラグメンテーショ ンを回避し、意味のあるやりとりの完遂率率率をあげ るための⼯工夫。
ネットワークへのゲーム仕様の依存？ •  ここまでのネットワーク周りの⼯工夫を⾒見見 る限り下記のことが⾔言える気がする。 •  「1パケットにどれだけのユーザーの情報 を詰め込めるのか？」というところに、 そのゲームのフレームレートや同時プレ イ可能⼈人数が依存している・・！
さらにネットワーク依存を軽減する:   Prediction •  60fpsのゲームを実現しようとした場合、すべてのフレーム を実データで描画しようとした場合、サーバーからクライア ントに秒間60個のスナップショットを遅滞なく届ける必要が ある。 •  しかしこれは膨⼤大なネットワークリソースを必要とするうえ、 パケットロスやレイテンシに⾮非常に脆弱になる。 •  これを解決するために、実際には秒間10個〜～20個のスナップ ショットを送るにとどめ、残りはクライアント側でスナップ ショットからの予測（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の予測はクライ アント側で予測して描画 する さらにネットワーク依存を軽減する:   Prediction
•  予測が⼤大きく外れると、次のスナップショットが到着 したときにユーザーの位置が⼤大きく修正される。⾒見見た ⽬目上、当該ユーザーがワープしたように⾒見見える。 •  ⾼高速度度での移動中における急激な⽅方向転換などを⾏行行う とこういうことが起きやすい。 •  ゲームによっては、急激な⽅方向転換を許容しない（た とえば物理理法則にしたがった⽅方向転換を強制する）こ とによってこういった事象を防ぐ⼯工夫をしている さらにネットワーク依存を軽減する:   Prediction
さらに
⼿手元でFPSを動かしてみる •  node学園2014で、socket.ioでFPS を動かすワークショップがあったの で⼿手元で動かしてみた。 •  実装を⾒見見てみると、やはりQUAKE と同じようにフレームごとのスナッ プショットをクライアントに送信し、 それをもとにフレーム描画を⾏行行うよ うになっていた。 •  WebGLとThree.js、すげー！ https://github.com/rase-‐‑‒/socket.io-‐‑‒workshop-‐‑‒full
⼿手元でFPSを動かしてみる •  データストアとしてRedisを採⽤用し ており、プレイヤーのライフなどを 格納している •  データの更更新はダメージを受けた時 やライフを失ったときなど、⼤大きな イベントが発⽣生したときのみ⾏行行われ るようになっている。 •  FPSでのデータベースの利利⽤用の例例と して⾮非常に参考になる。 https://github.com/rase-‐‑‒/socket.io-‐‑‒workshop-‐‑‒full
まとめ
まとめ •  オンラインゲームでは、ユーザー間、クライアント間でゲー ムのステータス（お互いの位置やライフなど）をいかに遅滞 なく同期してやるのか、というのが⾮非常に重要。 •  インターネットという信頼性の低いネットワーク上でこれを 実現するためにいろいろな⼯工夫がなされてきている。 •  FQUAKEがオープンソースになっているのが⾮非常にエポック メイキングなできごとだったようで、それ以降降のアクション 系のゲームはみなこれを多かれ少なかれ参考にしている。
ここからさきは？
他にも •  今回はおもにネットワークとレイテンシの話にフォーカスを 絞ったが・・・ •  Predictionの話は、それだけで多数論論⽂文が⾒見見つかる感じで、 オンラインゲームのなかでも⾮非常に重要で注⽬目度度の⾼高いト ピックらしい。 •  分散システム好きとしては、多数のクライアントから⾶飛んで きたコマンドの衝突の解決や⼀一貫性の保ち⽅方なども⾮非常に興 味深い分野だと思う。今回ちょっと⾒見見かけた感じだと、ベク タークロックみたいな⽅方式を使ってひとつを取るパターンや、 平均値をとるパターンなど、いろいろやりかたがあるっぽい。

More Related Content

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