サーバーの仕組みについて

オンラインゲームなどでプレーヤー同士の座標などの情報はサーバーに
集められ各クライアントに送信されているのですか？

もしそうならばサーバーはクライアントの数だけプロセスを持って一斉にクライアントに
情報を送っているのか？
それともクライアント毎に逐次データを送信しているのでしょうか？

No.3 ベストアンサー 回答者： Glory_777 回答日時： 2014/01/27 00:57

No.1のものです。

UDPを使っての３Dアバターチャットとなれば、相当な腕前と思います。
なので初心者向けの話よりも、実際面での話がいいですね。

その構造ですと、
MMOではなく、おそらくMOタイプを想定していると思います。

だとしたらP2Pとサーバを組み合わせたデュアル形式が良いでしょう。

TCP接続でのサーバ側との処理機構も作っておきましょう。
私は、UDPだけで充分だと思いますが。

しかし、サーバーが必要になるというのは、運用上の問題からさけられません。

何故かと言うと、マッチングを行うサーバーがどうしても必要になるためです。
未知のIPへは接続できませんから、一つのIPを公示して接続せざる終えません。

これがゲームクライアント端末であると不具合が大きいので、
マッチングサーバーがユーザ認証を行い、ゲーム中のゲームクライアントIPを
教えると言うステップが必要になります。

と言う事は、結局はサーバーを立てることを避けられないのです。
ただし、MMO型と違い、非常に簡単なデーモンプロセスになります。

こちらに簡易な重要情報（ユーザ情報、アイテムなどのゲーム情報）を保存し、
ゲームユーザの再ログインなどを保障します。

また、ゲーム中のエリアを区分けし、一度に一定数以上参加しないようにすると、
擬似的なMMOになります。

今の機種は相当ハードが強いので、工夫をすれば1エリアで50人は楽にいけるでしょう。
ところがサーバ型のMMOですと、50人でハングアップに近くなります。
とてもリアルタイム処理はできません。

旧来のMMO型は、時代の性もあって、動いているだけで受けていましたから、
本来サーバ型はライブコミュニケーションに向いていないのですが、
この方式で作りこんじゃっています。

ですので大規模MMO型と銘うって、サーバ型で運営しているゲーム会社も多いのですが、
これは古いアーキテクチャであり、設備が高い割には性能がでません。

No.1で述べましたが、ゲームエンジンを買ってしまっています。
としたら、もう捨てたほうがいいのに分からずに使っていると言うこともあるでしょう。

以上から、今の時代はUDPセッションを使ったMOタイプを、マッチングサーバーが連結し、
MMOに見せかけると言うのが適していると思います。

MOタイプでは、最大10～20の通信セッションを基本に、性能を確定しましょう。
このくらいの数で動くモジュールを作っておけば、
マッチングサーバーが連結することで100人対戦くらいにもっていけます。

では、MOタイプでの通信セッションの概要です。

初期に出たMOタイプのゲームですと、

1フレーム内での同期処理を諦め（というか無理でしょうね）、

ある程度の推測を行い、演出効果の遅延を利用したりして、同期します。

一定の期間では複数の操作をバッファリングし、このバッファ時間＋通信遅延が、

相手側への到達遅延になります。バッファリングしないと悲しいものになります。

一定期間の間に重要な判定処理が必要になる場合もあるので、

ユーザーに気づかれないように無効化し、先に結果を算出します。

この一定期間0.5秒とかのフレーム単位で各自の処理について共有し、

全クライアントで同じ情報を持つように同期をする方法が採用されています。

ゲーム中でのリアルタイムな判定処理は、参加ユーザが勝手に行うと

結果の食い違いがでてきますので、ユーザーの中の一人の判断結果を全体にコミット通知

するようにします。

ところがDirectXなどで用意されているライブラリをそのまま使いますと、

判定役の端末が落ちるとセッション自体が切れてしまいます。

なのでこういったMOタイプの半端なライブラリは捨てて、独自に作ることが基本です。

また、現実的には判定役の判断を待っていられませんから、

演出処理はさきにしてしまいます。

ここで先ほど述べた、一定期間の処理無効化を使います。

つまりは、一定のスピードで動いているものは、一定時間後はここにいる。

その間は、相手はこちらが想定しない動きをしないとし、互いにユーザ要求をブロックします。

これならば、体感で違和感無く遅延を回避できます。

操作を開始してから、反応するまでを遅らせて、相手にこちらの操作を伝えておけば、

互いにこの期間の互いの動きを予測で確定できます。

それでも齟齬がおきたとき、判定役の判断をしようして補正します。

常にじゃなくていいわけですね。

こうした情報の共有は、基本路線として、

全ユーザーが情報を同報し、いつでも判定役に成り代われるようにスタンバイします。

しかし判定役は一人とし、通常時は処理を進めます。

しかも、全てのゲーム中に発生する判定に対して同じ人が行うと、

故障のときの障害が大きいので、判定タスクを全体のふりわけておきます。

一人が落ちても、不具合が起きるタスクが一部になり、

何食わぬ顔で、別の人が引き継げるのです。

サーバー型の人はその発想が出来ず、サーバーシステム内で多重化するため、コストが高くなります。

P2Pを採用する時は、全体に同じ情報を各自が同報で配信し、

リアルタイムの補正をかけて同期し、

全ての人が判定タスクを分担し、

誰がどのタスクを受け持っているかを管理表で共有します。

この管理表の更新差分を各自が同報で配信し、同じ情報をもつようにします。

ところが管理表の競合アクセスが起きますから、管理表のレコード毎に、各担当を調停者として

配置します。これにより、通常のDBのように自分のタスクを他と共有できます。

先ずはこれを作ってから、タスクの担当を誰もが受け持てるようにし、

誰かが故障した時処理を引き継げるようにしておきます。

次は通信メッセージですが、

判定役は、自分が判断した情報のチェックサムやCRCを判定結果メッセージにつけて送ります。

判定役と同じ情報が届いていない端末ユーザーは、早急にここを判定役から補正情報として

もらい、同期を取ります。

こうした部分の処理を隠蔽し、アプリケーション側からはオブジェクトに見えるに汎用化し、

コールバック処理等でエラーに対応できるインタフェースを作ります。

こうすることで、通信エラー、サーバーダウンなどの障害だけではなく、判定役の情報と自分の

情報が違う場合も（間違って表示してしまった）、逐次対応して自然に見せかけられるわけです。

TCPセッションと、UDPセッションを行う部分は、スレッド化していると思いますが、

必ずアプリケーション側との間にFIFOキュー等をつくり、

ここでバッファリングをしてください。

通信でのロックなどは多発しますので、音声などのリアルタイム処理に影響します。

次に、先ほどのマッチングと重要情報保存用のサーバですが、

これともUDPセッションで行う方法が考えられます。

この場合は、サーバ側をPCにしてしまい、先ほど述べた通信層をそのまま使い、

サーバー側のアプリケーションとして作ってしまえば、楽に実装できます。



最後に、

MOタイプでゲームを作る場合、UDPセッションでアクション情報が送受信できるようになると、

次に何をしていいかわからなくなります。

そこで以下の二つを作り上げます

・リアルタイムな同期処理（リアルタイムに見せかける論理。FPSなどに対応できるように）
・タスクの分担を行う管理表の共有処理（NPC処理や重要情報判定処理を各端末に分担する）

まずは、同期処理。次に簡単なタスク管理表の共有などを作ることです。

参加クライアントで共有可能なタスク管理表をライブラリ化できると、

これのP2Pダウンロードなども実装できるため、途中参加も可能になります。

ダウンロード中は、更新情報をダウンロード配信者が中継してあげます。
（これは特許とっておりますが・・・）

次は、この管理表を使って、NPC処理を分担するのです。

これではじめてゲームらしくなります。

そうでないと、いつまでも３Dチャットのような雰囲気から脱せず、

モチベーションがあがらないでしょう。

管理表には、
誰かが故障しても、NPCの途中処理状態を管理表に書いておき、

処理を引き継げるようにしておきます。

リアルタイムな操作に見せかける同期処理では互いの細かい情報を配信し、

全端末でシュミレーションにより同じ結果を導けるようにします。

自分の操作以外のNPCなどの操作は、管理表を使ってクライアントで分担し、

各クライアントが自分の操作情報と同じ様に配信します。

アイテム取得等の重要情報などの判定は同じ様に管理表を使って分担できますが、

余裕がある場合はサーバを使います。

ただし、取得契機に対して、必ずサーバ側が個別のIDを発行します。

つまり、アイテム全てにIDをふり、このIDを暗号化するなどレジストレーションコード

として適当にガードをかけておきます。

良くあるID捏造と言う事故はおきません。

以上ご参考になれば。

この回答へのお礼

感謝の言葉が遅れてすいません。
どれもが刺激的な回答で実装してみようと試行錯誤していたら
遅くなってしまいました。
私にはまだまだ難しい事がたくさんありますが、一つ一つ解決していこうと
思います。

お礼日時：2014/02/01 23:55

No.4 回答者： Glory_777 回答日時： 2014/01/27 01:04

失礼しました。

No.3はNo.2のものの間違えです。

No.2 回答者： Glory_777 回答日時： 2014/01/25 13:04

そのあたり、独自に工夫をしないと、動かないのがオンラインゲームかと。

私の場合は、通信スタックの自作、同報アルゴリズムの考案（これは国際特許まで取れました）。
まで様々なことをした経験があります。

なかなかゲーム作りに進めないと言うのが、このジャンルの大変なところです。

以下は、一般的な話をします。

通信方式をTCP／IPにしたときは、コネクション毎にプロセスが起きますから、
クライアント毎にプロセスまたは、それに代替えする何かが必要かと思います。

次にUDPコネクションを使って独自に高信頼層（通信スタック）を作り、
通信部分の多重処理を可能にする方法があります。
これならばサーバ側プロセスは一つで済みます。
ただし、通信をする相手毎にパケットを履歴として残し、欠損があった場合は再送させる等、
手順を独自に作ることになります。

チャットや会議、オンラインゲーム等のライブでの双方向コミュニケーションの場合は、
一人の発信情報を全員で共有しますので、サーバ側は接続クライアント数の二乗に近い
データの送信をします。

参加者一人が発言した情報を参加者を含めて、他の人に配信すると言うことは、
参加者をNとしたときNの二乗になります。参加者の発言情報を参加者に戻さないと言う
仕組みもできますが、何らかのコミットが必要でしょう。

これはサーバの負荷が一定にならないという大変な問題が起きます。
4人で会話（サーバは16人分の情報を配信する）をしていたところ一人増えたとします。
16人分⇒25人分になります。人数が増えていくと、大変なことになります。

実際に自作し、そうなるのを何度も見ています。

MMOタイプですと、
同じ場所にいない人を分ければ、同時に情報を共有する人数を減らせます。
しかし同じ場所に人が集まると、固まって動けなくなると言う現象が起きます。

いずれにしても、サーバが情報を中継するため、大変な負荷になります。
特にチャット情報等はそのまま文字列を送信するため圧縮がし辛いです。

上記の問題を解決したあと（殆どのメーカーは解決できないでしょうけど）は、

通信内容をトランザクションとして分類し、

・データベースに記録する重要情報
・記録する必要が無い揮発情報

に分けた後、
他のクライアント要求との競合やゲーム・ルールの適用などが必要であるかに分類し、
それぞれに対して結果配信のタイミングを考慮する必要が出てきます。
サーバー内部のタスク管理が結構難しいと言うことです。
Web系の単純な構造からは想像も出来ない内容になると思います。

サーバを使わない方式ですと、
クライアントP2Pによって同報通信を使用する方法があります。
これは全順序マルチキャストの独自考案と言う難関があり、重要情報の配信ができません。

そこで日本でオンラインゲームが登場し始めた2000年頃は、
重要情報をTCPによるサーバ型、揮発情報をUDPを使ったP2Pで処理すると言うタイプが
有望とされていました。

どちらの場合も、Webなどで用意されているHttp系のミドルウェアは一切使えません。
なので、少なくともHttpdに相当するミドルウェアを自作できる自信がある人にお勧めです。

MMOタイプのオンラインゲームサーバの開発は、
こうした高度な仕組みが必要であるのと、ゲーム仕様とサーバー負荷が密接に関わって
いるため、普通のSIメーカでは開発できません。

MMOやMOタイプは、成功したゲーム会社のゲームエンジンを採用して、
カスタマイズすることで手っ取り早く運営をしているところが多いようです。
（なぜか必ず種族とスキルや転職があったりする）

ソーシャルゲーム等は、MOでもMMOでもなく、バッチ処理が型が多く、
Web系のアーキテクチャをそのまま利用することが出来るため、極端に実装が簡単です。

日本のMMO型オンラインゲームは、ある会社が頑張って独自に作った他、
まともに稼動しているのはありません。

スタンドアローンのゲームは、ユーザを思いやる心に溢れていますが、
オンラインゲームは、そうでない部分が多いと私は思います。

技術的に難しく、そんな余裕が無いというのもありますが、
実際は成功しづらく、ゲームエンジン自体が無いのだと思います。

ゲームエンジンが簡単に手に入らないとなると、
一つのゲームエンジンをどこのゲーム会社も採用することになり、
そのゲームの製作者の考え方を踏襲するため、今のクリエイターの意向が全く届かないのです。

オンラインゲームサーバーの仕組みについて、
「作った本人ですらベストであるのか自信が無い」と言うのが本当のところ。

更に作れた人が本当に少ない。
どころか作れそうな人が少ない。

TV会議システムを自作するとか、FlashやApachTomcat、Skype、
もしくはRubyやJavaのような言語を作るほうが、簡単ですよ。
もちろんAndroidOSのようなOSを自作するとかのほうが楽でしょう。

商用で動いているMMO型は、全てのミドルウェアを自作できるくらいの知識と腕前、
根性が必要というジャンルです。

以上、ご参考になれば。

この回答へのお礼

今現在UDPコネクションを使って3Dモデルが動いてチャットできるプログラムを作ったのですが、色々悩んだり妥協した部分が多々あり、実際は同様な形で動いているか気になり質問しました。
ここまで深く回答して頂いてありがとうございます。あなたのような知識を持った方の意見を伺える機会を持てたことを非常に嬉しく感じています。
文章では伝えられないですが、あなたに回答していただいたことを、とても感謝しています。また機会があればあなたの意見を伺える事を楽しみにしています。
本当にありがとうございました。

お礼日時：2014/01/26 17:11

No.1 回答者： LEVELUP100 回答日時： 2014/01/24 19:53

　興味があるならば・・・。

　以下のような技術書があります。

＞オンラインゲームを支える技術　　--壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus) [単行本（ソフトカバー）]
＞http://www.amazon.co.jp/%E3%82%AA%E3%83%B3%E3%83 …

この回答へのお礼

一度図書館で見かけたので今度借りてみようと思います。
私の質問の答えものっているでしょうか？

お礼日時：2014/01/24 23:07