新着情報

2011.09.02 Multi Action Game In the Coffee ~多人数ネットワーク対戦アクションのゲームデザイン~

CEDECのウェブサイトはこちら。

■Today's Contents

1.通信方式に関する基礎情報
2.通信ゲームデザインの基礎
3.TCP/UDPそれぞれの欠点と、その解決法
4.処理負荷との戦い
5.バグチェックについて、少しだけ...
6.結局、どちらの方式を選べばいいの?
7.美味しい珈琲の入れ方♪




1.通信方式に関する基礎情報

TCP/UDPについて

まず、マルチアクションゲームの話をするまえに
そもそも通信について、理解しておくべき基礎が1つあります。

それが・・・・通信方式です
ほんとの基礎の基礎なので、最初にそこだけ話させてください。

一般的な通信には2つの方式があります。
それがTCPとUDPです。

で、まずはTCPの特徴ですが

良い点としては...
エラー検出などがきっちりと行われることで、信頼性の高い通信を行う事が可能なところ。

逆に悪い点として...
信頼性が上がる代償に処理負荷が大きい...非常に大きいのです。

ちなみに、PSPではこれをPTPと呼びます。

次に、UDPの特徴ですが

良い点としては...
「ブロードキャスト送信」という、データを一斉にばらまくような送信方法が利用可能で、 通信処理が非常に高速です!

逆に悪い点として...
ばらまくだけで、送信結果を確認しないので「信頼性」が確保できない。
という状態にあります。

ちなみに、PSPではこれをPDPと呼びます。

マルチアクションゲーム開発の経験者であったり、興味を持たれている方は 何を今更・・・と言う感じかと思いますが、はい。基礎と言うことでお許しください。

では、2つある通信方式をどのように選べばいいのか?
どっちでもいいのか? そんなことは無くて、判断基準があります。

プロジェクトの通信仕様を決定する上で重要なのは...

ズバリ通信量です。

1対1とか少人数で処理に余裕があるなら信頼性のPTPを。
逆に最初から多人数、通信量も多くなるとわかっているなら 通信が高速なUDPを選択するのがいいかと思います。

弊社開発実績では、UDP方式採用が比較的多いのですが それでもUDPが必ずしも正解ではないので タイトルごとの特徴によって、常に選択を行っている状態です。



2.通信ゲームデザインの基礎

・マッチングについて
・ゲームの進行管理について
・通信切断について

では、ここからゲームデザイン論の始まりですが まず最初に、全てのマルチアクションゲームに必要であろう処理から、 重要な3つを抜き出して簡単な説明と、デザインの指針を話します。

本当はもっと沢山の話をしたいのですが50分という時間の中で、話せる物を 重要な順で選びました。

各端末同士の通信の結びつきを決定する処理。
協力相手、対戦相手を決定するためのもの。

マルチアクションというか、通信ゲーム全ての入り口と言えます。
端末同士を結びつけることから、まず始めないとそもそも繋がりませんからね。。。

で、マッチングにもタイプがいくつかあるので、それを見てみましょう。

方法1 ルーム作成タイプ
ユーザーが任意で作ったルームをリスト上から選んでジョインするタイプ

方法2 ルーム選択タイプ
タイトルが予め用意したルームを適宜選択してジョインするタイプ

方法3 ロビータイプ
ロビー上でゲストがジョインした後にルームが作られるタイプ

方法4 オートマチックタイプ
リスト化されたルームの中からタイトルが決められた条件に従って、 自動的にジョインさせるタイプ

などなど...他にもあるけど、ここはこの程度で割愛します。

で、どんな風にプレイヤー同士を出会わせるのか?というのはプロジェクトのポリシーによって、タイミングや方法論が異なるため、我々ゲームデザイナーには、企画的なこだわりと、システムの理解の両方が求められると言えます。

ちなみに弊社タイトルは今のところ、全て1か2で作成しています。
4人対4人の対戦アクションゲームを作った際に方法4も検討したのですが、そもそもアドホック通信では、目の前のプレイヤーと共に遊ぶことがメインでタイトル側が作為的にマッチングさせる意味がないことから、別案が採用されました。

さて、これでマッチングのタイプを決定したとします。
次にマッチング時に表示させる情報の取捨選択が必要となります。

表示させる情報とは通信を行うユーザー同士が何を求めているか?
何を元に通信プレイを決定するのか?ということでもありますが、これはアドホック通信と、インフラストラクチャ通信で内容が全く違ってきます。
例えば、必ずユーザー同士が目の前でコミュニケーションを取って遊ぶことが前提のゲームでは参加プレイヤーの名前がわかればマッチングには十分と言えます。
それ以上のものはコミュニケーションの、一環としてゲームデザインの見地から見せる見せないを検討すれば良いのです。

しかしインフラストラクチャ対応があり、ユーザー同士がコミニュケーションを行えない 状況を考慮する必要があるとすれば...表示情報の吟味にはとても神経を使います。

ユーザー名だけでなく、参加人数や、プレイするミッション内容、ルール、難易度、ホストの熟練度などまであらゆる情報をユーザーに告知する必要があります。

マルチアクションゲームでは、このようにマッチングひとつとってもゲームデザインに関わる重要な要素になってくるわけです。

マッチングの次に、重要な要素が「進行管理」です。
複数のプレイヤーが同時にひとつのゲームで遊ぶわけなのでこの進行管理がうまくいかないと、ゲーム自体に破綻をきたすことになりかねません。

そこで、色々な方法論を考えるわけですが...
最も単純なのは『ホスト』に全てを合わせる方法と言えます。

例えば、『参加出来るマップがまだ開示されてない。』『キャラクターが使えない。』『レベルが達していない』など。マッチング時に判定をして、ホストの進行管理条件に満たないプレイヤーを弾く訳です。

そうすれば全てを『ホスト』で一元管理できるので、不整合を避けることができる。
これが一番簡単で安全な方法なのは、間違いない。

しかし、言い換えると、『条件に合わないプレイヤーは、遊ぶな!』と言っているわけですからゲームデザイナーとして、本当にそれでいいのか??と。

そこで、ホストに合わせない形で進行管理する方法を模索することになるわけです。

例えば、ホストが絶対に正解!という方法だけじゃ物語(時系列)のあるゲームでは単純にいかない...
 ※「一緒に進められない」というのはユーザー不満の上位ある。

結局のところ参加出来るプレイヤーの条件を如何に増やすか?(ゆるくできるか?)がマルチプレイのゲームを自由に楽しませる最大のポイントなので、こちらの都合で一緒に遊ぶことのできるプレイヤーを縛ってはいけない。と。

つまり、ゲームデザイナーとして求められているのは『進行管理がちゃんと出来る仕様』ではなく、『進行管理への影響が単純で、なおかつ遊びたいときに、すぐに参加出来る仕様』 と言えるわけです。

「現段階では、」という付帯条件付きですが、弊社の開発実績で色々と試した結果、『進行を最も遅いプレイヤーに合わせることがベターである。』という結論に至っています。

進んでいるプレイヤーは同じシークェンスを再度プレイすることになりますが、大凡の場合において許容されます。
なぜなら一緒に遊ぶのはほとんどの場合が友達同士だからです。


シーン別のプレイヤーを相互に関連させる方法

ちなみに弊社開発のとあるタイトルでは、別マップでの攻略が、もう一方の戦況に影響する要素が存在します。

この進行管理をどうやって行っているか?
フラグでしょ?と言う感じですが、通信ではそうも簡単ではなくてちょっとだけコツがあります。

 ・そのコツは共通するフラグ表を参照し、なおかつ一度立ったフラグは下せない
  というルールを設けること

つまり、イベントを制御する1つのフラグのON/OFFで進行を判定するのではなくイベント制御用のいくつものフラグを順番にONにしていくことで、進行がどこまで進んでいるか?を判定していく訳です。

そうすることで、端末間の不整合が発生した場合でも、どの端末の情報が正しく、どの端末の情報が更新漏れであるのか?が一目瞭然となります。

要は立てた『フラグは戻せない』ということなので、1台でもフラグの立っている端末が あれば、その端末が即ち正解ということです。

端末間の齟齬については、この後話すUDP方式の欠点の項でも出てくると思いますのでまあ、ここでは流しましょう。

次に通信ゲーム全てが抱える問題、通信の切断について説明します。
通信切断はアドホック通信、インフラストラクチャ通信、有線問わず必ず存在します。

なので、ゲームデザイナーとしては、①通信が切断されたのかどうかを判断することと、②切断された後、ゲームをどうやって成り立たせるのか?をデザインする必要があります。

で、まずは①の切断の判断ですが・・・
どうやって、通信待機中なのか、切断してしまったのかを判断するのか?
答えは「時間」です。
どれくらい返答がないか?を切断の判断材料とするしかありません。

ただし、あまりに長い時間を設定してしまうと、ハードメーカーのガイドライン(TRC/TCRなど)に抵触するため、抵触しない範囲で少し長めの時間を模索。
結果はアドホック通信で10秒~15秒。インフラストラクチャ通信では30~60秒。 と言う形で落ち着きました。

インフラストラクチャ通信で判断時間が長いのは、通信インフラによる遅延を考慮してのものです。

次に、通信切断が発生してしまった場合の、具体的な対策です。

この場合も通信切断によって、落ちたのがホストか、ゲストかで処理が異なります。
最も一般的な手段は、ここに書かれているように、

「ホストが落ちたら、ゲーム終了。」
「ゲストが落ちたら、そのゲストがゲームから消える。」というもの。

ルールも明確でバグも少ないので、マルチアクションゲームを作り始めた当初はコレがベストだと考えていました。
当時は、通信切断=仕様と割り切ってゲームプレイを損なう形でも、商品化させていたわけです。

しかし、この状態では、本来求めるゲームプレイとは言えない。と経験を重ねるごとに気づき、近年では次のようなことを行っています。

「ホストが落ちた場合でも...ゲームが終了するのではなく、ホストが別に端末に引き継がれる。」
これで、急にゲームが終了することは、ほぼ 回避されました。

「ゲストが落ちた場合には...ゲストのキャラクターを該当するAIが引き継いで、続きをプレイする。」

こうすることで、完璧ではないが通信切断の影響を少しでもゲームプレイから排除できるわけで、そういった努力を行うのが良いゲームデザインといえます。

現状は、この形である程度満足をしていますが、おそらく将来的には落ちたホストの再参加や、代行AIの挙動強化など、まだ課題はあると思いますね。

単に「通信」といってもユーザーにとっては、商品の一部ですから、これからも「仕様」と割り切らないゲームデザインを心がけていきたい。
そのためには、プランナーといえどもハード仕様やシステム、技術を基礎くらいは理解しておくのが良いかと思います。



3.TCP/UDPそれぞれの欠点と解決法

TCPの欠点と解決法
UDPの欠点と解決法

では、話を通信方式に戻します。
TCP/ UDPのそれぞれの欠点と解決法を、弊社実績の具体例を交えて話します。

TCPは最初の項で話したように、信頼性が高く、データが確実に届く通信方式です。
こう聞くと、欠点が無いように思えますが...そんなことはありません。
TCPの欠点は...「通信ラグ」です。

信頼性が高いのは、やりとりをしっかりしているからで、やりとりをしっかりしているということは、処理がかかるってことなんです。

で、処理がかかると通信のやりとりに時間がかかって通信ラグが発生する。
通信ラグが発生すると、同期処理の待機が発生し、結果、ゲームプレイがガクつくのです。

では、弊社ではその通信ラグをどのように解消したのか?について話しますと該当タイトルでは『キー入力データ』のみを送受信したんです。

送信元の端末でキーの動きをトレースし、それを送信。
受け手の端末で送られてきた動きをシミュレートするわけです。

ゲームのヒット判定や、座標計算などはお互いの端末で別々に行います。
ただ、同じプログラム、同じ計算方法で動いているハズなので結果が同じになる!という仕組みです。

ちょっと違うけど、離れた2つのコントローラーで同じゲームを遊んでいる感じかなと。

注意点として、二つの端末での結果が全く同じになる必要があるわけなので、"ランダム要素"の結果も、同じになるようにプログラムしておく必要があります。

ランダムのスリップダメージが、A端末では「5」だけれども、B端末では「7」など、ずれが発生すると目も当てられない結果になりますので。

これでも満足のいく通信速度が得られないときは、データを送信する端末を1フレームに1台のみとして、4フレームかけて全端末の情報を送信する形で実装しました。

なので実際にはキー入力から4フレーム遅れてゲームが動いていることになりますが実際に遊んでみて、体感的にセーフという判断を行い決定しました。
机上の空論では、議論が前に進まないことも多いため、弊社では「実際に作って試す」ということを重視して仕様決定をしています。

次に、高速で大量のデータを送信することのできるUDPですが、こちらにも欠点があります。 その欠点は...「パケットロス」です。

パケットロスとは、送信したデータが途中で欠落するなど、上手く届かないこと。
通信がされていることが前提の通信ゲームにおいて、データが届かないという致命的な状況なわけです。

一般的なのが座標飛び。ヒット/死亡判定の齟齬。など。
マルチアクションRPGではエンカウント判定/クエストクリア判定など、別シーンにいるプレイヤー同士の不整合も発生します。

これらの解消には毎回非常に労力を取られます。

さて、これでマッチングのタイプを決定したとします。
次にマッチング時に表示させる情報の取捨選択が必要となります。

表示させる情報とは通信を行うユーザー同士が何を求めているか?
何を元に通信プレイを決定するのか?ということでもありますが、これはアドホック通信と、インフラストラクチャ通信で内容が全く違ってきます。
例えば、必ずユーザー同士が目の前でコミュニケーションを取って遊ぶことが前提のゲームでは参加プレイヤーの名前がわかればマッチングには十分と言えます。
それ以上のものはコミュニケーションの、一環としてゲームデザインの見地から見せる見せないを検討すれば良いのです。

しかしインフラストラクチャ対応があり、ユーザー同士がコミニュケーションを行えない 状況を考慮する必要があるとすれば...表示情報の吟味にはとても神経を使います。

ユーザー名だけでなく、参加人数や、プレイするミッション内容、ルール、難易度、ホストの熟練度などまであらゆる情報をユーザーに告知する必要があります。

マルチアクションゲームでは、このようにマッチングひとつとってもゲームデザインに関わる重要な要素になってくるわけです。

で、これを解消するための一般的な方法ですが、「データの再パケット化」と「ステートやフラグの不可逆化」となります。

データの再パケット化は再度データを送ること、この後詳しく話します。

不可逆なステートとは、一度増加した値は、減ることはない、というものです。
先ほど「進行管理」の項で出てきた話ですね。

例えば、現在地上で活動している地上オブジェクトというステートは、 (撃滅することで数が減るので)不可逆化できません。

こういうステートは通信でのやりとりには向かないため、「ミッション開始からの撃滅された地上オブジェクトの数の累積」というふうにステートを読み変えます。
このようにすることで、ミッションの状態は増加方向にしか更新されませんので、データが送受信された時点での増加したステートの値でのみ辻褄を合わせることが出来ます。

結果、端末間でのズレをプレイ中に何度も補正しながら、ミッションの同期が取れているように見せることができます。

前項で話したように、どの端末が正解なのか?が明確だからです。

次に再パケット化についてですが...
要は「下手な鉄砲も数撃ちゃ当たる!」ってlことです。
これが以外に有効で、バカに出来ない訳です。

弊社の開発実績では1回の送信で18%のパケットロスが発生しました。

そこで、これを元に

 2回目の送信で18 % ×18%=3.2%...
 3回目の送信で18%×18%×18%=0.6%
 4回目の送信で18%×18%×18%×18%=0.1%

と確率計算を行い、4回送信すればほぼ100%(99.9%)になるだろうと仮定して実装を試しました。

で、で、で、結果「4回送れば、まあ大丈夫。」という想定通りの結論に達したわけです。

弊社のほぼ全てのタイトルはこの4回ベースで作成されていますが、某タイトルでは、どうしても同期を取らなければならない処理に限り、回数制限を設けず、応答があるまで送り続けるという実装を行っています。
 ※UDPにもかかわらず、いわゆる同期を取っている処理になります。
 ※この場合、応答が来るまで延々待ち続けるという危険もあります。

それでもデータが届かない時はどうしたらいい?

答えは簡単で「データが届かない前提でゲームデザインを行う」のです。

つまりは、複数の端末間で、もしもデータの不整合が発生しても、それが=重大な問題と発展しないように...「美しくごまかす」のです。はい。

では、そのごまかし方の例を見てみましょうか・・・

美しくごまかすには、ユーザーの気にする部分と気にしない部分を理解する必要があります。
そこでユーザーの行動や視線、思考に注意を払ってみると操作に集中しているプレイヤーは「見ているようで見てない」のです。はい。

「ロックオンした敵に集中していると、周囲の敵やNPCの行動は見えない」
「飛んでいくミサイルに注目していると、自分に飛んでくるミサイルは見えない」
「マップを見て位置関係を把握していると、位置がずれていたり、こっそりNPCが移動しても気づかない」などなど...

そういう所を探して、許容していったり、計算結果をホスト優先にしてしまったり、こっそりNPCを復活させたりと、上手に端折ります。

真面目に理詰めで考えれば考えるほどハマリます。なので、もし、可能なら試すのが一番早いでしょう。そうすれば大丈夫なことが何かわかってくると思います。

その判断基準があれば、たとえQAテスト中に「本来気にしなくても良い不整合」が報告されても、明確に「仕様」なのかどうかを判定できるようになります。


4.処理負荷との戦い

ここまでで、「通信方式の基礎」、「マルチアクションゲームにつきものの3つの処理について」、「TCP/UDPの問題点と解決策」を話しました。
これらを念頭にゲームデザインを検討してみてください。

では次に、どちらの方式を採択しても必要なもの。
処理軽減について、実例を交えて説明します。

処理負荷軽減の工夫について その1
まず最初にやることは...「通信データサイズの軽減」です。

最初はそもそも、送る物自体を小さくして、データ量を減らすわけです。
詳しくは↓の図を確認してください。

こういった工夫は後に大きな違いとなりますので、重要ですよ!

処理負荷軽減の工夫について その2
次にやるのは...「送信頻度(回数)を検討」です。

サイズの次は回数です。サイズと回数で総合的にデータ量を減らすわけです。

ただし、全体的に送信回数を減らすと先ほどのラグや、パケットロスなどの問題に回帰してしまいますので、ゲーム進行に影響する重要度の高いデータとそうでないデータで送信回数を使い分ける必要があります。

例を挙げると...

・送信回数多い
→自キャラの座標や、弾の発射情報、ダメージ、死亡情報等
 進行に大きく影響を与えるもの。
 また、ゲーム開始や終了等の確実な同期が必要なものも回数を多くしておく。

・送信回数少ない
→主に演出系となるが、エフェクトの挙動やUIのアニメーション等。
 これらは通信2回で1回しか送らない形でもゲームプレイへの影響は軽微といえる。

データ量を減らし、送信回数を見直したあと、次にやるのは...
「ホストの一括管理を分散させる」こと。これは超有効です。はい。

CPUがマルチスレッドならホスト端末内での処理分散を検討しても良いですが、マルチスレッドはゲーム自体の処理分散に残しておきたいので通信の為の分散は、参加している端末で行うのがベター。

最初から参加端末で処理を分散させることを念頭に設計すれば、端末が増えるごとにホストの負担だけが増えていくというようなことを回避できるわけです。

特にAIの処理等は処理負荷が高くなりがちなので、この方法で分散するのは有効といえます。
もちろん万能ではないが、重要なテクニックだと言えるでしょう。

これで、プログラム的にやれることは大まかに終わりなんですが、まだ処理が足りない時があります...そんなときは次のページです。

そんな時は・・・
「通信以外の処理でやるしかない」

...で処理負荷の代表はなにか?と調べたら当然「描画関連!」となります。

もうデザイナーの登場ですね。はい。

弊社実績でいうと、リソースのリダクションによってラグが減り、結果パケットロスも減少しました。
この場合も、4項で話したように「美しくごまかす」ことは忘れず、気にならない所から手をつけます。

もし、描画関連に手を出してもまだ十分な処理が得られない場合は、ゲームデザイン自体を見直しましょう。

無駄に敵が出ていないか?
無理な描画を強いていないか? そもそものデザインや設計にミスがあるかもしれません。



5.バグチェックについて、少しだけ...

ここまでで、主なトピックは終了です。
お疲れ様でした。

次はちょっと蛇足になりますが、バグチェックについても少しだけ話しますね。

通信ゲームのバグチェックについて...

想定外のことが必ず起こるのが通信ゲームのバグチェックです。
なので、イレギュラープレイを入念に行うわけですが、あくまでも商品作りのバグチェックなので、神経質になりすぎるのも良くありません。

イレギュラーの中のイレギュラーというか、超人イレギュラープレイに関しては、仕様としていく判断も必要とされるわけです。

つまり「妥協点を知ること。」これ、結構重要です。はい。

このさじ加減がすごく難しくて、そのコツをお教えしたいのですが、残念ながら簡単に言葉にできるほど、単純ではありません。
この点は、通信ゲームを何本か作って実績から判断するしかないと思います。

もしかすると、ある意味それがマルチアクションゲーム制作のノウハウなのかもしれません。

次にマルチアクションゲームのバグチェックで重要なのが、全ての組み合わせを試すということ。
シングルプレイでは起こりえない膨大な組み合わせが、マルチプレイには存在ます。

それらを全てチェックせず商品化すると、必ずあり得ないミスが残ってしまいます。必ずです。なので、絶対に全ての組み合わせを試す必要がある。

ただ、それを一つ一つ手作業でやっていては、到底スケジュールに間に合わないので、自動化バッチの登場となります。

弊社ではバグチェックが始まると毎夜30台以上の開発機がガリガリと自動化チェックを進めています。
朝来て、止まっていたり、問題があったらログをたどって原因究明する。

組み合わせが膨大だから、時間的問題を解決できないから、「マルチゲーム開発を諦める」のではなく、自動化という形でそのリスクを軽減する。
そういうバックアップに支えられて、ゲームデザインという見地からマルチアクションゲームの企画を進めることが出来る。

そういうチーム作りも、重要な要素であると付け加えさせていただきます。



6.結局、どちらの方式を選べばいいの?

ここまで色々と話をしてきましたが、結局のところTCP/ UDPのどちらが作りやすいんだろうか?
どちらが優れているんだろうか?と言うお話です。

せっかくお越し頂いたので結論を持って帰っていただきたいのですが......

結局は【ゲームデザインによって、採用される通信方式は変わる!】
これが結論です。すいません。

ですので、まずはご自身のプロジェクトがどんな物なのか?をしっかりと把握してみてください。

ここまで通信技術の基礎と、ゲームデザインについて話してきましたが...
最も重要なのは「何を作りたいか?」が明確であること。

これは通信だけでなく、描画や、UI、コントロールなどにも言えることで、それは即ちゲームデザインそのものについて話をさせていただいたつもりです。

自分のプロジェクトを知り、それに最も適した技術を選ぶ。
その選ぶための指標として、基礎知識くらいは身につけたほうが得ですね。多少の誤解があってもいいです。そこはご自身のチームのプログラマーがわかりやすく教えてくれると思うので。

今日は通信に偏った内容でしたが、ここで話したお話は現行機だけではなく、今後の開発にも使える内容だと思っています。VITAや3DS、スマートフォンやコンソールにも転用できると思います。

弊社の開発実績や、経験がすこしでも皆さんのお役に立てたら幸いです。
ながながとお付き合いいただきありがとうございました。

以上、みんな愛してる!