23
19

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

AltPlusAdvent Calendar 2016

Day 12

通信ラグとの上手な付き合い方

Posted at

※この記事は「AltPlus Advent Calendar 2016」の12日目の記事です。

2016年10月にオルトプラスに入社しましたtoshihiko-honmaです。
エンジニア出身で現在はマネージャーやってます。

ここ数年、スマホゲームでも複数人で同時に遊ぶ「マルチバトル」が増えてきていますよね。

そこで必要になるのがマルチ通信エンジンなのですが、巷にはクラウドサービスで利用できる非常に優れたエンジンがいくつか存在していて、今時フルスクラッチでゲームサーバーを開発する機会は殆どなくなったように思います。便利な世の中になりました。

とはいえ、マルチバトルを同期させるためのリアルタイム通信には落とし穴も多く、エンジンを利用してもハマってしまうポイントがいくつかあります。

ここでは、落とし穴の一つであるインターネット上の「通信ラグ」について書いてみようかと思います。

#代表的なプロトコル
リアルタイム同期式のゲームで使用される通信プロトコルとして代表的なものはTCP、UDP、RUDPの3種類ですが、それぞれに利点・欠点があります。

TCP UDP RUDP
再送制御 ×
順序制御 ×
フロー制御 ×
オーバーヘッド ×
NAT超え × ×

TCPは相手に確実にパケットが届くけれどもオーバーヘッドが大きく処理が重くなります。
UDPは処理は軽いものの信頼性が低いため、再送処理が必要な場合は自前で実装する必要があります。
RUDPはTCPとUDPの良いとこ取りですが、正式規格になっていないため現状ではベンダーマターの実装が多いようです。

どのプロトコルを採用するかは、ゲームの特性によって変わってきます。

ターン制バトルで確実に全情報を同期する必要があればTCPを利用する、レースゲームのようにリアルタイム同期することが重視されるゲームであれば、移動情報が多少欠落してでも速度を重視してUDPを利用する、という具合です。

#通信の理想形
4人対戦のマルチバトルゲームを例にすると「Aさんが攻撃を行った瞬間にB~Dさんに行動が通知されて、全員同時に同じ画面が表示されること」が理想です。

理想を実現するためには、通信遅延やパケットロスが一切発生しない通信環境が必要ですが、インターネットでは現実的ではありません。

image

#実際のところ
光の速さで通信したとしても秒速30万キロメートルでしか情報は進みません。そのため、通信経路の物理的距離が長くなれば、それだけで遅延は増大します。

経路上で経由するルーターが増えれば処理遅延も加算されますし、途中の通信帯域が細ければ通信速度が制限されます。LTEなどの移動体通信であれば、ハンドオーバー(基地局の切り替え)による遅延やバーストも無視できません。

加えて、機器やケーブルの物理的な障害やソフトウェアの不具合などで、パケットがロストすることもありえます。

image

#どうすればよいのか?
乱暴に言ってしまうと、インターネットの通信ラグを完全に防ぐことは不可能です。通信経路上の出来事は制御できませんので、あきらめるしかありません。

かといって、何も気にしないわけにもいかないので、できる限りの対処療法を仕込むことになります。いくつかポイントを列挙してみます。

  • 目的に合わせた適切なプロトコルを選択する
  • パケットサイズや通信回数を効率化して回線負荷を下げる
  • ラグやパケットロスが発生した場合であっても安全サイドに倒れこむ実装にする
  • アプリケーション遅延を最小化できるよう、効率の良いコードを書く

当たり前のことばかりですが、「ラグが必ず発生すること」を意識しておかないと意外とハマってしまいます。

#ゲームデザインへのフィードバック
エンジニアとしてできることがもう一つあります。

「リアルタイムバトルなんて企画するの初めてです~」なんてプランナーを見かけたら、「ラグってのはゼロになんねぇんだよ!!」 と言い続けましょう。これが超大事だったりします。

ラグを考慮せずにゲームデザインを決めてしまうと、社内テスト時は(LAN環境だったから)動いていたのに、運用環境に持っていったらラグってゲームにならなかった、なんてことになりがちです。

ゲームデザインレベルでラグを考慮することで、通信開始時にエフェクトを入れて時間猶予を設けたり、移動仕様を単純化して数フレーム先の位置情報補完を実現しやすくしたり、結果としてユーザーに**「ラグを感じさせない見せ方」**を提供することができるかもしれません。

よりよいゲームを開発するためにも、企画と技術の協力関係は重要です。

#最後に
私は前職もゲーム開発会社でして、7年間、時代の変遷とともに「ガラケーの通信対戦アプリ」「Webソシャゲ」「スマホのマルチ対戦アプリ」など色々なタイトル開発に関わる機会がありました。その前の12年間はSI企業に勤めていて、社会インフラの通信制御システム開発でバイナリの通信ログを眺めて暮らす日々を送っていました。

そう考えると「なんかしら通信するもの」を作り続けてもう20年くらいになります。自他ともに認めるおっさんです。最近では自分で実装する機会はすっかり減ってしまいましたが、おっさんなりの過去のノウハウが誰かの何かに役立てば嬉しいな、と思っています。

ここまで読んでいただき、ありがとうございます。

#参考URL
ネットワークゲームについて非常にわかりやすく解説されています。おすすめ。
[CEDEC 2010]ネットゲームの裏で何が起こっているのか。ネットワークエンジニアから見た,ゲームデザインの大原則

23
19
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
23
19

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?