セミナー

【セミナー】将来的にゲームデータの同期は必要なくなるのか？…モノビット中嶋氏が”通信”環境の現状から未来の展望を語る

2019.12.02 09:48

サムザップは、スマートフォンゲームエンジニアを対象とした勉強会「サムザップテックナイトvol.7　ゲーム業界の通信の未来を語る　～次世代のゲーム体験はどう変わるのか～」を、10月10日に開催した。本稿では、当日の講演の模様をお届けしていく。

本イベントは、スマートフォンゲーム業界を盛り上げていくことを目的に、サムザップが定期的に開催している勉強会だ。第７回となる今回は、「オンラインゲームを支える技術－壮大なプレイ空間の舞台裏」の著者である、モノビット取締役CTOの中嶋謙互氏をゲストに迎え、ゲーム業界の通信について講演を行った。また、サムザップで『リンクスリングス』のリードエンジニアを務める二宮章太氏と、エンジニアを務める石井岳氏は同作の運用で学んだネットワーク遅延対策について語ってくれた。

■4つの視点から”通信”の現状を確認し未来を予測

会が始まると、まずはモノビット取締役CTOの中嶋謙互氏が登壇。「ゲームの通信をつくる仕事はどうなるのだろう？」をテーマに講演を行った。

▲これまで25年ほどオンラインゲームを作り続けてきたという中嶋氏は、この仕事を選んだ理由として「一人でオンラインゲームを好きなように作って世界中の人と遊びたい」という理由を挙げた。これを可能にする方法の模索や、手法を共有したいといった想いから今回の講演を行っている。

本講演は、低いレイヤーから上に登っていく形で4つの階層ごとに説明が行われた。最初は物理的にインターネットを支えている「ハードウェア」について。次にパケットをマシンまで届ける「インターネット」、マシンの中のプロセスやソケットにデータを届ける「トランスポート」、最後が「アプリケーション」となる。

では、ゲームに関わるマシン（サーバー、クライアント）はどう変わってきたのか、またどう変わっていくのか。中嶋氏によると、プロセッサ性能はトランジスタの数が増えており、この点に関しては今後も増えていくという。対して、シングスレッドの性能は頭打ちになりつつあり、周波数や消費電力は2005年ごろからほぼ変わっていない。さらに、コアの数は増えている。つまり、シングルスレッド性能が頭打ちになったことでコアやトランジスタが増えているというのが、プロセッサの今の姿であると説明した。

次に、メモリの帯域幅は着実に速くなっているという。特に、CPUはチップセットの改善もあり2008年から見ても2倍以上速くなっている。

ただし、メモリのコストに関しては2010年頃から劇的に下がることはなく、量あたりのコストは以前とそれほど変わらないことが以下のグラフから分かる。

さらに、消費電力あたりの性能に関してはCPUもGPUも着実に上がっていると説明した。これは、専用の命令が増えていることも関係しているという。

ここまでがプロセッサとメモリについての話。続いて中嶋氏は、ネットワークについて言及した。Ethernetのロードマップを紹介すると共に、現在AWSなどのクラウドで使用できるネットワークはおよそ10GBになるということを紹介した。5年ほど前は2GB～4GBだったため、ここ数年で数倍伸びており、サーバ間のデータコピーもより速くできるようになっている。

一方、無線LANに関するユーザー側のネットワーク環境は、下記の写真でいう「WiFi6」が一部のスマホに実装されている。また、10Gbps以上出ると言われている「WiFi7」が4～5年後には導入されるだろうと予測した。

データ通信がまともに使用できるようになったのは1991年頃で、当時40Kbpsだったのが現在は1Gbpsに。パケット数は何十万と膨らんできたため、定額を導入するところが増えてきている。今、世間でも騒がれている5Gに関しては、遅延が1msまで縮んでいるほか、パケットに関してはアメリカでは既に追加費用を払えば使用できることが明言されている。ただ、これについて日本がどうなるかはまだ公表されていないとのこと。

続いて、クラウドマシンのCPUコスト、送信コスト、クラウドストレージのコストに関しては、いずれも値段が下がっていると述べた。特に、LinodeやDigitalOceanなどのシンプル系データセンターに関してはさらに下落し続けており、用途によって使い分けるようになっていると説明した。

ハードウェアの現状が確認できたところで、続いてはインターネット環境の現状を見ていく。これは、ひとつのパケットをマシンに届けるまでの工程となる。ここに使用されているのは「IPv4」と「IPv6」。遅延の大きさやクラウドがどこにあるのかということを紹介した。

IPv4とIPv6では、送信元や宛先のアドレスが異なると違いが説明された。現在は、インターネットの3割ほどでIPv6が使用されているという。また、今後はインターネットに繋がっているマシンが42億では足りなくなるのでどんどん伸びていくのではないかとの見解を示した。

距離による転送時間の比較については以下の通り。長距離転送に関しては、現状で既に改善が難しいレベルまで洗練されているが、中距離については改善の余地が残されている可能性があるという。さらに都市内転送に関しては、物理的な問題があるものの、速くなる可能性が高いとのことだ。そのほか、同一AZ内転送は速くなっているがインスタンスタイプによってさまざまな制限がかかってしまうと現状を説明した。

また、以下は大手企業のDCの位置を示した地図である。インターネットを使用している国を全てカバーできる位置に配置されていることが分かる。なお、中国・ロシア・アフリカに関しては情報が公開されていないとのことだ。

次に、マシンの中のプロセスやソケットにデータを届ける「トランスポート」レイヤーについて。インターネットはパケットがすぐ消えてしまうため信頼できないと中嶋氏は話す。そこで特定のプロセスに対してデータを届けるのがトランスポートの仕事となる。

インターネットというものは、送ったデータの順番が入れ替わったり、途中で消えたりするのだという。これは、例え有線LANを繋いでいたとしても受信側のマシンのメモリやCPUが足りなくなった際にも発生するほか、無線LANでは負荷がないときでも1万個に1つは消えてしまう。

アプリを作成する際には、このように不安定なインターネットをほぼそのまま使用する「UDP」というプロトコルと、パケットが消失したことを検出して再送したり、データの順序をメモリに保存してバッファリングで保証したりする「TCP」というプロトコルの2つが主要であると紹介した。

続いて、1981年に発明されたTCPの歴史についても紹介している。

しかし、そんなTPCでも未だに解決できない問題が2つあるという。それは「head-of-line blocking」と「IPアドレスの変化に対応できない」という点だ。なお、head-of-line blockingがどういったものかについては、下記のスライドで説明されている。これは、TCPが順番通りにしかデータを送信できないために発生している課題だと述べた。

また、モバイルネットワークから無線LANに切り替わる際にはIPアドレスが変化する。そうするとTPCは接続をし直す処理が必要になり、ロードバランスがサーバにあると異なるサーバに入ってしまい接続性の問題が生じる。

モバイルゲームアプリ市場の現状としては、移動しながらゲームをすることやロード時間が長いことが嫌われることから、これらの問題が今の時代に合わなくなってきているという。そこで、UDPやTPCに代わる第3のプロトコルが必要となり、2012年ごろからGoogleが「QUIC」の研究を始め、現在はバージョン23まで進んでおり、まだまだ改良を続けている段階であることを紹介した。ちなみに、このプロトコルでは上記2つの問題を解決するほか、ブラウザでドキュメントを同時に取得したり新規接続が速くなるなど、多くの要求を満たす巨大な仕様になっているとの話だった。

しかし、これはゲームに適用するには大きすぎることや、MMOサーバで使用するのは複雑すぎることから、モノビットではUDPやTPCに代わるプロトコルを自社エンジンに搭載していることを紹介した。

▲中嶋氏が自らプログラムを書いているというプロトコルの概要。早めの再送を行うことで、仮にパケットが消えていた場合にもデータ送信時間のロスが少なくなる。あえて無駄な送信を入れることで再送を減らすという強引な手法を取り入れていると説明した。

こうした状況から、HTTPの次のバージョンではQUICがベースになるのではないかと述べて話をまとめた。

最後に「どうやってゲームを作るか」というアプリケーション層について。中嶋氏が最も影響が多いであろうとう予測しているのは、クラウドゲーミングに関する技術であるという。クラウドゲーミングの概要は以下の通り。

また、クラウドゲーミングは3つのモデルに分けることができるという。

・1:1／1ユーザーに1サーバ

▲ユーザーからの操作をインターネット経由でゲームサーバに伝え、レンダリング・描画を行い映像や音を提供する。

・N:N／1:1ゲームをNユーザーでマルチプレイ

▲マルチプレイの場合はサーバが2つ立てられ、ゲームサーバ同士が通信を行う。ほとんどの場合は同じデータセンターにある。

・1:N／Nユーザーに1サーバ

▲3つ目は、複数人が同じサーバにアクセスして複数人分のレンダリングを行うパターン。

さらに、1:Nの映像を提供する際のフローについてはより具体的に説明。複数人分の操作を1つのサーバで受け取り、映像を4回レンダリング・エンコードしてそれぞれの端末に送っている。特徴として、GPUの中に入っているものは4人とも同じであるため、GPUの中のリソースは共有した状態となる。そのため、1:NではサーバのGPUやCPUを節約できるとのこと。

また、GPUなしのサーバで映像を送らない場合についても言及。2Dのゲームなどでは、操作を受け付けた後にジオメトリのデータを毎フレーム追って描画を行う。この場合は、GPUを使用したレンダリングやラスタライズが必要なくなり、ジオメトリの処理までで済むため消費帯域が少なくなる。

その後、スタンドアローンのゲーム（タッチ対応・非対応）とクラウドゲーム（タッチ対応・非対応）の4種で遅延にどれほどの違いが出るかについても解説した。VRだとレスポンスが厳しく難しいが、スマートフォンのゲームであれば大丈夫ではないかとの見解を示した。

以下はクラウドゲームで必要な帯域について。

そのほか、クラウドゲームでサーバを作成する際には映像で送信するデータを少なくするためにさまざまな手法が使われている。これは、映像をエンコードするときにゲームのロジックが同じプログラムで動いているのでエンコーダに指示できるためだという。例えば「右にスクロールする」ということをエンコーダに教えるだけで圧縮率が上がるとの話だった。

『リンクスリングス』の場合は、地形・キャラ・モブ・エフェクトはインゲーム映像としてサーバでレンダリングし、ボタンやマップなどHUDに関してはブラウザ側でレンダリングを行っている。こういった工夫を取り入れることで、クライアントの処理が軽くなる。また、鍵となる環境の変化について費用の面からも言及した。

では、環境が変化すれば将来的にはゲームデータの同期は必要なくなるのか。この点に関しては、クラウドゲーミングでもN:Nの場合は必要と中嶋氏は述べる。また、MMOのサーバ間通信や、スタンドアローンのゲームもクラウドのみにするというのは時期尚早であると結論を述べた。ただし、プロトタイプの段階では不要になるかもしれないとの展望も示した。

講演の最後には、ありえそうな今後の展開として、Unityなどのエンジンやミドルウェア、またプラットフォームが1:Nをサポートすることや、ゲームに特化したWebブラウザの普及が進むのではないかと展望を語る。

ゲーマーとしては、実況などの動画からすぐにゲームをプレイできる機能や、アプリストアからのダウンロードやアップデートが不要となる未来を望む一方、エンジニアとしてはマルチプレイゲームに関するネットコードを書くのが手間になっているためテスト公開できる環境があると良いと述べて講演の締めとした。

■『リンクスリングス』の運用から学ぶ”ネットワーク遅延”との付き合い方とは

後半は、サムザップの二宮章太氏と石井岳氏が『リンクスリングス』の運用から学んだネットワーク遅延への対策についての講演レポートをお届けしていく。

▲サムザップで『リンクスリングス』のリードエンジニアを務める二宮章太氏。2015年に同社へと入社して『リンクスリングス』のバトル部分を担当している。

『リンクスリングス』は、ざっくり説明すると「陣取りゲーム」であるため、高頻度に通信のやり取りが必要となるゲームである。その中で、プレイヤーの思い通りの操作を実現するためにも同社では入力に対する”反応速度を重視”していると紹介した。

そのため、移動やスキルの発動などは入力を受けたらサーバを経由せずローカルですぐに実行しているという。そのままでは端末間の遅延によってズレが生じてしまうが、『リンクスリングス』ではそれが致命傷にならない工夫が各所に取り入れられている。

続いてはどのように工夫しているかをより具体的に紹介。まずは、「遅延によるマイナスを減らす」という点について。例えば、「避けたはずなのにダメージを受けた」ということをなくすためにダメージを受ける側で当たり判定を行っているという。

しかし、そうした場合、攻撃側は当てたつもりなのに外れているという印象は受けないのか。これについて二宮氏は、コリジョンを工夫して「実際の攻撃エフェクトの見た目より当たり判定を広く取る」ことで違和感が生まれないようにしていると説明した。例えば、敵に向かって突進するような攻撃や剣を振る角度からそれを計算することで、攻撃を受ける側としても理不尽に当たっているという印象は減るようだ。

また、ダメージテキストのヒット演出に関してはユーザーが「当たった」と感じてから表示されるようにしている。これは反応速度より「判定の正しさ」を重視したもので、人間の反応速度を計算したうえで多少の時間差があっても問題ないと判断して実装されている。

同じくヒット演出から、ローカルで処理しているものも紹介。「ヒットしたら爆発する球」に関しては、ローカルで当たり判定を取らなければ通過してから爆発する形になってしまうと二宮氏は説明した。しかし、これにより稀に発生する副作用もあり、当たり判定を受けた人の画面では正常に表示されているが、周囲は球の爆発が見えないため何にやられているかが分からないというデメリットもあるようだ。また、その逆で自分の画面では爆発が当たったように見えるが、判定はダメージを受ける側で行われているため相手の画面では避けられているという事象が稀に起きることを挙げた。

ヒット演出について最後は、スキル使用後に敵に向かって突撃し、接敵したらストップするスキルについて。これは、ローカルで処理してしまうとラグで当たらない可能性があるため、ダメージテキストの事例と同様にヒット判定があってから処理するようにしている。また、敵が通過してしまうという事態を防ぐためにキャラの周囲にもコリジョンを設置することで対策しているという。

さらに、ラグに関しては上限を設定していることも明かされた。そのため、『リンクスリングス』ではRTTに閾値を設け、この値を超えた場合は通信環境が回復するまで動けないという処置を施している。当初は250程度で設定していたが、電車内などで快適にプレイできなくなってしまったため現在は350程度まで許容されているとのこと。これにより、相手が瞬間移動したというような報告も稀に発生するようになってしまったが、全体比としてより多くのユーザーがストレスなくプレイできているのではないかと二宮氏は述べた。

続いては切断対策について。ネットワークが同じでも、アプリによって切断しやすいものと切断しにくいものが存在するという。この理由を探るため、RUDPの仕組みに着目したところ、到達保障と順序保障というものに行き着く。

先ほどの中嶋氏の講演にもあった通り、UDPは通信がロストしてしまうことがある。Photonでは、Actで到着確認をしつつ、ロストしてしまった場合には再送を行っている。それでもダメな場合は切断扱いにしているため、到達保障を多用しすぎてしまうと通信の瞬断に対してシビアになるのだと説明した。

そこで、『リンクスリングス』では到達保障に関する通信を減らすように努力している。そのため、移動にかんしては最新が合えばOKという形で途中が抜けることを許容している。また、陣取りに関してはサーバからクライアントへ送るものに関してはズレがないよう保証しているが、クライアントからサーバに送信する分にはロストしても構わないと判断している。

これで山手線に乗車してプレイしたところ問題がなかったので大丈夫かと思いきや、いざリリースしてみると甘かったことが判明する。まず、山手線の回線が実は良かったということや、陣取りは数フレームおきに発生していることから絶えず到達保障の通信が必要だということから、リコネクト機能の実装が決定する。リコネクト機能の詳細は以下の通り。

最後に二宮氏は、おまけとしてリコネクト機能をリリース後に作るのは大変だったという苦労話も語ってくれた。そもそも、『リンクスリングス』はPhoton Cloudで制作していたが途中からPhoton Serverに移行したため、サーバにデータが揃っていないところからのスタートに。状態の補完機能もなく、リコネクトをしなければ機能を試せないため、まずはデバッグツールを作成して補完処理を実装するところから進めていったのだという。こうした苦労があるため、リコネクトは最初から考慮してほしいと述べて講演の締めとした。

次にサムザップのエンジニアである石井岳氏が登壇。サーバサイドUnityの可能性についての講演を行った。

▲石井氏は2016年にサイバーエージェントに入社。その後、サムザップに出向して新規タイトルの開発に関わる。『リンクスリングス』では、クライアントエンジニアとしてバトル部分を担当している。

ここでは、Unityがマルチプレイ用ゲームサーバのフレームワークとして活用できるかどうかについて言及を行っていく。そもそも、Unityは物理シミュレーションやレンダリングなどオールインワンのゲームエンジンとして有名だが、果たしてUnityがサーバアプリケーションとして活用できるのだろうか。そこで石井氏は、Unityが備えているゲームサーバとして活用できる機能を紹介した。

・HeadlessMode
レンダリングをOFFにした実行モード。レンダリングなどに使用していたCPUをゲームのロジックに集中させることができる。

・PlayerLoop
Unityが備えている各種機能を開発者の好きなように組み替えることができる機能。物理シミュレーションのみを抜いてサーバとしての処理のみに集中させることも可能となっている。

・Unity Transport Package
Unity向けのネットワークライブラリ。

・DOTS-Netcode
今秋プレビュー版が公開。最近Unityが力を入れているゲームアプリを効率的に動作させるDOTSという仕組みに則ってより効率的にコードを記述することができる。

上記から、ゲームサーバに必要な機能に絞ったり、効率的なネットワークライブラリが充実してきていると石井氏は述べる。

しかし、C#で書けるということに関しても既にモノビットやPhotonなど、洗練されたフレームワークは存在する。その中で何故Unityを採用するのか。それは、クライアントと同じコード、同じアセットで動作させることができるためだと石井氏は説明する。例えば、エンジンが同じということを活かしてマップデータを共通化することで開発効率を向上させるというメリットがあると説明した。また、デバック用のクライアントを実装することなくサーバ上のゲームを簡単に視覚化できることも大きな特徴であるという。

さらに、Unityをゲームサーバ用のアプリケーションとして運用するための選択肢も広がってきていると紹介する。ホスティングサービスでは「Amazon GameLift」「Multiplay」「Google Cloud Game Servers」、オープンソースソフトウェアのホスティングツールである「Agones」がこれに該当する。これらはUnity向けのSDKが用意されているなど親和性が高いものとなっていると述べた。こういった多様な選択肢からニーズに合ったホスティングを選択できる状態であるとの話だ。

これまでの理由から、Unityはゲームサーバフレームワークとしてのポテンシャルを備えていると言っても良いのではないかと石井氏は結論付けて講演の締めとした。