[CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た，ゲームデザインの大原則

　先週行われた「CEDEC 2010」の講演から「ネットワークゲームの仕組みとゲームデザイン」と題されたセッションを紹介しよう。

「CEDEC 2010」公式サイト

　　登壇したのは，セガ第三CS研究開発部のテクニカルディレクター 節政暁生氏。節政氏は「ファンタシースター オンライン」シリーズのプログラマとして，長年ネットワークゲーム（オンラインゲーム）の開発を手がけてきてきた人物だ。この講演では，その経験からネットワークゲームのゲームデザインにおいて，気をつけるべきことについてのレクチャーが行われた。その内容には一部技術的な要素を含むものの，基本的にはプランナーに向けたものであるため，理解にそれほど専門的な知識は必要ない。いわばネットワークの基礎の基礎にあたる部分なので，そっち方面を求めている人には少々物足りないかもしれないが，普段からネットワークゲームを遊んでいる人にとっては，興味深い内容だろう。適宜解説を付け加えつつ，紹介していこう。

避けられないラグの問題

セガ 第三CS研究開発部
テクニカルディレクター 節政暁生氏

　講演は，まずネットワークゲームにおいて使用される，基本的な通信技術についての解説からスタートした。

　ネットワークゲームのゲームデザインにおいて，まず考慮しなければならないのは，いわゆる「ラグ」についての問題だ。ここでいうラグとは通信遅延のことで，ラグが頻繁に発生する環境では，ゲームでまともに遊べなくなってしまう。具体的に言えば，ゲームの進行が全体的にスローモーションになってしまったり，当たったはずの攻撃が外れてしまったりといった現象がこれにあたる^※。きっとこの記事を読んでいる人にも思い当たる経験があるだろう。

※これらの現象は，必ずしもネットワークが原因でない場合もある。

　一言でラグといっても，それを引き起こす要因には次の三つのケースがある。
　一つは「遅延」。これは文字通りの通信遅延のことで，ネットワーク的な距離があまりに遠いため，応答に時間がかかってしまうケースなどを指している。この応答速度はpingというコマンドで計測することが可能で，その値はネットワークゲームの快適さを示す，一つの指標といっていいだろう。当然応答は早いほうが良く，実際の応答速度は，LAN環境では1〜2ms，インターネット回線においては，数msから数百msといったところだ。

60fpsで動くゲームの場合場合，1F（フレーム）は約16msに相当する。もしLAN環境や携帯ゲーム機のワイヤレス通信モードが前提なら，単に入力したキーを相手に送るだけでもゲームが成立する

　次は「帯域」について。帯域は回線の“太さ”を表す指標のこと。よくインターネットのスピードを示す単位として使われているのがこの数値で，LAN環境では100M〜1Gbps，最近はインターネットでも，光回線なら50Mbpsくらいは出たりする。ただ携帯電話の3G回線なども対象にする場合には，大体200〜500kbpsくらいなので，低いほうに合せてゲームを設計する必要がある。

　最後は「パケットロス」について。パケットロスは通信の内容が，途中でどこかに行ってしまって届かない現象のことをいう。いわゆる通信の安定性というか品質とでも言うべき指標で，これが頻発する状況だとかなり厳しいことになる。主にサーバーが混雑しているときなどに起こりやすく，プレイヤー側では，あまりどうこうできるものなかったりする。

　具体的には「遅延」が発生していると，画面がカクカクした動きになって，気づいたらキャラクターが死んでいた，なんてことが多くなり，「帯域」が足りないと，例えばMMORPGで人が集まる広場などに行ったとき，重くて身動きが取れなくなる。「パケットロス」が起こると攻撃したつもりがダメージにならなかったり，頻発するようならそもそもサーバーから切断されたりといった現象が発生することになる。

ネットワークの基本，UDPとTCP，RUDPに関するお勉強

　では実際のゲームでは，これらのラグに対処し，ゲームを成立させるために，どのような工夫が行われているのだろうか。これを理解するためには，まずインターネット通信の方式について，少しばかり知っておく必要がある。現在のインターネットではTCP/IPと呼ばれる通信方式（プロトコル）が採用されており，そこでは主にUDPとTCPという通信方式が使われている。


　UDPとは，パケットを一方的に送りつけてそれで終わりという，ごく単純な仕組みのもので，パケットロスなどが発生して相手に届かなかった場合でも知らんぷりをするので，信頼性は低い。また後から送ったものが，先に送ったものより先に届くこともあって困りものだが，その分処理が速いという特徴がある。

　それに対しTCPはもう少し複雑で，パケットが届かなかった場合には，再送が行われる仕組みになっている。郵便で言うところの書留のような仕組みで受信の確認が行われるので，信頼性が高い半面，処理はどうしても遅くなる。メールやブラウザなど，ゲーム以外の通信用途では，ほぼこちらのTCPが使われていているのだが，ゲームのような処理スピードがシビアに要求されるものでは，それでは間に合わない場合があるのだ。


　とは言うものの，ちゃんと届いたかどうか分からないUDPでは，ゲームでも困ることも多い。そこで考案されたのが，RUDP（Reliable-UDP，Reliable＝信頼できる）という仕組みだ。
　RUDPでは，受信の確認はいちいち行われないものの，次に送信するパケットには「これまで相手から受け取ったパケットの番号」が記載されることになっている。相手から送られてきたパケットを見れば，相手がどこまでこちらのパケットを受け取っているか分かるので，抜けがあったら再送すればいい。プレイ中，常に相互に通信が発生するゲームならではの方式といえるだろう。
　また再送が必要な重要なデータと，再送の必要がない，あまり重要でないデータをくっつけて送るなんてことも可能で，まさにUDPとTCPのいいとこどりの通信方式だ。


　RUDPの仕様については，各プラットフォーマーから提供されることもあれば，ゲームごとに独自に実装する場合もあるそうだ。興味のある人は，技術書などをあたってみるといいだろう。

格闘ゲームの場合―― 完全同期型/キー入力同期方式

　それでは各ゲームにおける実装事例を見ていこう。まずは近年急速に快適になった，格闘ゲームでの実装事例から。氏は同社の人気格闘ゲーム「バーチャファイター5 Live Arena」（以下，VF5）を例に解説を行った。同作で採用されているのは，「完全同期型/キー入力同期方式」というものだ。「完全同期型」とは，プレイヤーが見る画面が，クライアントレベルで一致していることを前提にしたもので，またキー入力同期方式とは，入力されたキーデータをそのまま相手に送り，フレーム単位での同期を実現することを表している。


　では実際にどうやって同期を取るのか。高いアクション性をもち，1F単位での攻防が繰り返される格闘ゲーム。LAN環境のような高速かつ信頼性の高いネットワークであれば，単にキー入力を送りあうだけで実現可能だが，インターネットを介したとたん，難しくなるのは想像に難くない。

　以下の図は，VF5における「キー入力同期方式」の実装例を示したものだ。同作では1Fごとの入力キーデータをUDPによる通信で送りあうことになっている。ここで重要なのは，対戦の開始前に互いの通信遅延を測定することだ。図の場合では，相手に届くまでに2Fと少し（約40ms）の遅延が発生している。この計測値をもとに，同期のための遅延フレーム，ここでは3Fをウェイトとして設定している。この場合，自分が入力したキーは，相手の入力データが届く3Fを待ったうえで実行に移される。このような仕組みによってフレーム単位での同期を取る仕組みだ。


　しかし先にも述べたとおり，UDPは必ずしも相手に届くとは限らない通信方式である。もしパケットロスが発生してしまった場合，キーデータが相手に届かないことになる。このような場合は，届かなかったフレームでゲームの進行をストップし，次のパケットを待つことになっている。一つのパケットには，過去10F分のキーデータが入っているため，それをもって直前のフレームを処理するしくみだ。10F分のデータがあれば，1回や2回パケットロスが連続した場合でもリカバリが可能で，さらに保険として1秒（=60F）に1回，RUDPで過去60F分のデータを送ることで，10F以上のバーストエラーにも対策が行われている。

　またVF5のような1vs.1のタイトルなら問題ないが，もっと多い人数で対戦可能なタイトルの場合は，帯域が厳しくなる場合もある。ニンテンドーDSで発売された，同社の別タイトルの事例では，2vs.2での対戦を実現するために，パケット送信の頻度を落とす処理が行われているとのこと。図の例ではキーデータを2Fごとにまとめて送ることで，通信量を削減している。ただし，その分入力のウェイトは4Fに増加している。

Wi-Fiなどの無線通信の場合は，図の例よりももう少し頻度を落としたほうが良いそうだ

RTSの場合 ――完全同期型/コマンド入力同期方式

　続いてRTSの場合を見ていこう。ここでは「Age of Empires」と「スタークラフト」が例として取り上げられた。これらのRTSでは「完全同期型/コマンド入力同期方式」という方式が用いられている。格闘ゲームとは，完全同期型という点では同じだが，その実装がコマンド入力同期方式で行われているのがミソだ。


　キー入力がそのまま送られる格闘ゲームと違い，RTSの場合は，キー入力の結果として発生した“コマンド”が送受信される。RTSには数百のユニットが登場することになるが，コマンドはユニットの一つ一つに対してではなく，一まとめの集団に対しても発行される仕組みだ。このため通信量は数byteで済み，低速回線でも問題なくプレイできる。

「StarCraft」のコマンドの例。翻訳すると「Probeを選択してGatewayを建築。Gatewayを選択してZealotを生産。完成したユニットを選択して，指定した座標へ移動。移動しつつ攻撃」といった具合になる

　では実際のところ，どれくらいの頻度でコマンドが送られているのだろうか。氏は「スタークラフト」を例に挙げ，普通の人で1分あたり約50回程度の頻度とこれを説明した。ものすごいスピードで操作するプロゲーマーの場合だと，これが1分あたり200〜300回まで膨れ上がるが，それでも秒間になおせば大したことはない。通信状態が悪ければ，コマンドの送信頻度を多少減らしたところで，プレイヤーに気づかれることはないだろう。またオフラインのシングルモードでも，わざと数フレームの遅延を挟むことで，ネット対戦時に違和感を感じないような工夫が行われているそうだ。


　残念ながら日本ではあまりメジャーではないもの，氏はこのようなRTSのゲームデザインを，最初からネットワークを視野に入れた，優れたゲームデザインと指摘する。とくにプレイヤーに代わりユニットの操作を代行してくれるAIの存在は重要で，これがあるために，プレイヤーはネットワークの遅延に気づきにくい。実際，遅延が250msくらいあっても，問題なく対戦が行えてしまう。
　厳密にはRTSではないものの，より単純な例として，1999年に発売された対戦アクションパズル「チューチューロケット」を例として挙げた。同作において，画面上を走り回るネズミ達は基本的に直進し，矢印パネルの上に来ると，その通りに向きを変える。壁にぶつかった場合は，常に右に曲がるという，ごく簡単なAIになっている。このAIにはランダム性がないのがポイントで，それによってプレイヤーは，大量のネズミを混乱することなく操作できるというわけだ。ランダムに曲がるといった要素を入れ，それを同期することも不可能ではないが，それはあえて入れていないという。

ドリームキャストの初期にリリースされた名作「チューチューロケット」。未だにファンも多い同作は，氏の作品とのことだ

FPSの場合 ――非同期型/サーバー集中処理型

　お次はFPSの場合を見ていこう。ここからは非同期型の実装例となる。非同期型は，完全同期型と違い，プレイヤーによって見ている画面（世界）が違うことを許容するシステムだ。例えばあるキャラクターの位置が，プレイヤーの見ている画面によっては微妙に違った位置になることがある。ゲームデザインにあたっては，それでもゲームに問題が発生しないように配慮する必要がある。つまり同期すべき情報とそうではないものを，あらかじめ取捨選択しておく必要があるわけだ。

　このタイプの例として挙げられたのは「QuakeIII」だ。QuakeIIIは，1999年に発売されたタイトルで，以降のFPSのネットワーク対戦において，その基礎を固めた作品だという。ソースコードも公開されており，以後多くのFPSがこのタイトルを参考にしている。


　QuakeIIIでは「非同期型/サーバー集中処理型」の実装が行われており，その仕組みを図として表したのが以下のスライドだ。サーバー集中型の場合は，すべての同期はサーバーの内部で行われており，各クライアントはプレイヤーの入力をサーバーへ送る機能と，サーバーから送られてきた情報をそのまま表示する機能のみを有する。この仕組みは接続人数の規模が段違いではあるものの，基本的にはMMORPGなどでも一緒である。

右はQuakeIIIのパケットの内容を示したスライド。サーバーとクライアントをまったく別に作る必要のある非同期型は，プログラム的には若干ハードルが高い。やり取りされているパケットの内容も，これまでのものにくらべるとかなり豪華（複雑）だ。

　さて，このようなFPSにおいて，プレイヤーが一番ラグを感じるポイントはどこだろうか。それは当たり判定である。間違いなく攻撃を当てたはずなのに，通信遅延のために判定が行われなかったというのでは，ゲームの勝敗に直結する要素であるだけに，不満となりやすい。FPSのキャラクターの位置や攻撃判定などは，もちろん最優先で同期すべきデータであるものの，ネットワークを介する以上，どうしても遅延が発生する場合がある。


　そこで「カウンターストライク」といった後のタイトルでは，QuakeIIIのそれに加えて，命中の判定を「クライアントでの見た目通りに行う」処理が加えられている。具体的には，サーバー側でキャラクターの位置などのステータスを，過去数十フレーム分に渡って保存しておく。攻撃パケットが遅延して届いた場合でも，サーバーで「過去に遡って」判定を行うことで，当たり判定の違和感をなくす仕組みだ。
　ただし，これはあくまで「攻撃側からの見た目」を基準にしているので，攻撃を受ける側には不利なルールである。撃たれる前に隠れたつもりなのに，ありえないところから弾が飛んできてやられてしまう，なんて経験をした人も少なくないだろう。しかしどちらかといえば，こちらのほうが不公平感を感じにくいのは確かで，現在も多くのタイトルでこの方式が採用されている。

　なおゲームに必要な情報をすべてクライアントに送る必要があるサーバー集中タイプでは，帯域が問題になりがちだ。その解決のためには，これまでのように通信の頻度を下げる方法（MMORPGなどでは主にこちらが使われる。秒間3〜4回程度）があるが，格闘ゲームと同等か，それ以上のアクション性が求められるFPSの場合では，そうもいかない。
　そこで必要となってくるのが，データの圧縮技術だ。しかし通常の通信とは違い，ショートパケットが何度もやり取りされるネットワークゲームでは，普通の圧縮方式ではあまり効き目がない。そこで用いられるのがデルタ圧縮という圧縮方式だ。デルタ圧縮は，簡単に言えば，直前のステータス（ステータスバッファ）との差分をとって，変化したところだけを残すという圧縮方式。ちょっと難しい話になるので詳細は控えるが，要はFPSのようなゲームに向いた方式ということだ。詳しい内容については，以下のスライド，もしくは技術書を参照してほしい。

PSO/PSUの場合 ――非同期型/クライアント分散処理型

　いよいよ最後の実装例，「ファンタシースターオンライン」（以下，PSO）と「ファンタシースターユニバース」（以下，PSU）の事例に移ろう。同作のネットワーク部分は「非同期型/クライアント分散処理型」という仕組みが用いられている。


　まず同氏は，PSO制作時の前提として，全世界のプレイヤーと遊べるという目標があったことを明らかにした。これは相当なラグ（日本-ヨーロッパ間なら300msから600msの遅延）でも許容しうるシステムの構築を意味し，この時点で完全同期型はあきらめざるを得なかったという。かといって，帯域を考えればサーバー集中型も難しい。そこで採用されたのが，このクライアント分散方式だ。

クライアント分散方式の構成図。サーバーは基本的にパケットを中継するだけの役割しか持っていないのが特徴的だ

　クライアント分散方式の強みは，送受信されるデータを最小限に抑えられることだ。当たり判定やダメージ処理など，アクション性の高いほぼすべての部分を，クライアント側で処理し，そのうえでステータス情報や位置情報など，結果として起こった情報のみをサーバーに送る。サーバーはその情報をリーダー役のプレイヤーへ中継し，全体の同期はここで取られることになる。結果プレイヤーはそれぞれに違った世界を見ていることになるが，全体的な破綻がなければそれで良い，というわけだ。

　実際のところ，同作ではかなりの部分がクライアント側の処理で実装されている。例えば「歩き始める」とか「剣を振る」といったデータもタイミングを合せることなく，起こった結果がいきなり送信される仕組みだ。
　結果のみしか送信しないとすれば，では移動はどうやって処理されるのか。「歩き始め」た瞬間には，到着する場所はまだ決まっていないではないか。実は同作では，歩き始めた瞬間に，行き先はすでに決まっていたという。キーを押した瞬間には，決め打ちされた座標への移動パケットが送られており，同時にゲーム画面でも30fps動作の6F程度が一度に処理される。踏み込みが伴う攻撃などでも同様に，ボタンを押した瞬間に移動パケットが合せて送信される仕組みだ。


　しかし，これはこれで問題が発生することもある。具体的にはロビーなどでキャラクターが整列して記念写真などを撮ろうとしたとき，うまく整列するのが難しいのだ。移動が決めうちで行われるので，行き過ぎてしまって戻ったり，どうしてもジタバタすることになる。このような不満を解決するために，PSUではプランナーからの要望で，この部分に少し改良が加えられることになった。PSUの実装を示したのが以下の図だ。


　アナログキーで自由に動けるようになったPSUだが，移動開始時点に予測座標が送信されることには変わりがない。ただしクライアント上では移動先の変更が可能で，結果として予測位置と移動結果にズレが発生することになる。そのズレをどうするかというと，これはもう単純に，移動結果を見て座標を補正する＝ワープさせる処理になっている。自分の画面上ではスムーズにヘアピンカーブを描いたつもりでも，ほかのプレイヤーから見るとカクカクしているのはこのためだ。PSUでの実装に当たっても，このワープが起こらないように補正する処理を入れてみたそうだが，実際に見てみると端的に言って「気持ち悪い」動作になったそうで，それならまだワープのほうがマシと判断されたとのこと。車や飛行機といったオブジェクトなら，多少ドリフトしても違和感はないが，人間が横滑りすると，かなり気持ち悪い。それならパケットの通信頻度をあげて，ワープの発生を抑えるほうが効果的だろう，というのが氏の意見だ。

　また同作ではエネミーの座標も同期が行われていないという。これは企画の段階で同期を取らないと決めたそうで，プランナーにはそれを前提としたゲームデザインをお願いしたとのこと。敵の動きを同期させるのは技術的に困難とのことで，「モンスターハンター」といった近年のゲームでも，おそらく同期は取られていない。氏は，今考えてみても良い方法が思いつかないといい，ネットワークゲームで未だ未解決な問題の一つとして挙げていた。ただPvPなどの対戦を行わない限り，プレイヤーは敵の動きが同期していなくとも気にしない――ダメージが通って倒れてさえくれればそれで良いので，あまり気にしなくていい要素なのかもしれない。

未だにどうやってエネミーの同期を取っているのか質問されるという節政氏。「実は同期は取っていません」

　しかしボスについてだけは，ある程度同期を取る努力が払われている。その具体例を説明したのが，以下のスライドだ。ボスの行動アルゴリズムに，それぞれ十数秒のパターンを用意して，リーダーとなったクライアントが，ボスがどの行動を選択したかを決定，各クライアントに伝達する。行動パターンを受け取ったクライアントは，ボスのAIによって適宜行動を開始する仕組みだ。実際にはネットワークの遅延によってズレが生じてしまうものの，十数秒という長いスパンの行動になるので，プレイヤーはズレを実感しにくい。仮に大きなズレが生じてしまった場合でも，細かなジャンプを繰り返して位置ズレを終始したり，なんらかの理由で行動パターンが送られてこない場合でも，それを誤魔化す小さいアクション（火を吹くなど）が用意されているとのこと。AIは，ここでもラグの吸収に役立ってくれているといえるだろう。


　なおこのほかにも，PSUのMMOエリア（ロビー）では，通信量を節約する工夫が行われている。MMOで人が集まるところが重くなるのは，先にも述べたとおり。これを防ぐために，自分のキャラクターから離れたところにいるキャラクターとは通信頻度を下げ，データのやりとりを節約する工夫が行われている。

PSUのロビー風景。遠くにいるキャラクターは存在が希薄になっている

ネットワークの性質に合わせたゲームデザインを

トルネードダンス

　講演の最後に，氏はこれらの事例を参考に，プランナーにはネットワークゲームの制約を考慮したうえでのゲームデザインを考えてほしいと強調した。
　例えばPSUには“トルネードダンス”というスキルがあるが，これがどうにもエンジニア泣かせな仕様であるとして紹介が行われた。キャラクターがグルグル回転しながら突進していくこのスキルは，移動中に向きを変更可能で，確かにカッコ良くはあるものの，氏は「こんなの同期が取れるはずがない！」と言い，会場の笑いを誘っていた。

　光ファイバー接続が普及した日本のインターネット環境は，現状でほぼ理論値一杯まで速度が出ており，これ以上の通信環境の向上は，なかなか望めそうにない。むしろ今後は，Wi-Fiや3G回線といったモバイル通信に注目が集まっていくものと思われ，そうしたワイヤレス通信の環境は，ネットワークゲームにとって，ますます過酷になっていくだろう。そしてそうした環境においては，よりいっそうネットワークに気を使ったゲームデザインが求められるはずだ。


　また，講演では触れられることがなかったが，いわゆるラグの問題だけでなく，チートや回線絞り（ナローバンドのほうがゲーム上有利になる仕様）といった不正行為に近い問題であっても，ゲームデザインの段階で考慮していれば，防げるものが多いはずだ。とくに国内メーカーの場合には，このあたりに無頓着な実装が散見されるように思う。

　せっかく面白いゲームであっても，これらの問題が未解決のまま放置されるようでは，台なしといわざるを得ない。ゲームをプレイするプレイヤーの立場からも，ネットワークゲームのプランナーには，ネットワークの特性を理解したゲームデザインをお願いしたいところだ。