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

オンラインゲームの仕組みと⼯工夫
@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
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.

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

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

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

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

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

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、すげー！

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

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

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

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

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

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

More from Yuta Imai (20)

Recently uploaded (9)

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

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.