JP3998466B2 - ネットワークゲームシステムおよびネットワークゲーム処理方法 - Google Patents
ネットワークゲームシステムおよびネットワークゲーム処理方法 Download PDFInfo
- Publication number
- JP3998466B2 JP3998466B2 JP2001379493A JP2001379493A JP3998466B2 JP 3998466 B2 JP3998466 B2 JP 3998466B2 JP 2001379493 A JP2001379493 A JP 2001379493A JP 2001379493 A JP2001379493 A JP 2001379493A JP 3998466 B2 JP3998466 B2 JP 3998466B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- client
- game
- storage means
- transmission number
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
- A63F13/35—Details of game servers
- A63F13/358—Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
- A63F13/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
- A63F13/335—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using Internet
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＵＤＰ／ＩＰの通信プロトコルを用いたネットワークゲームシステムおよびネットワークゲーム処理方法に関する。
【０００２】
【従来の技術】
ネットワークゲームにおいてはゲームの興趣性を高めるには、素早いレスポンスが要求される。この場合、クライアントシステムとなるゲーム端末装置においは、プレイヤの操作に応じてのリクエストが発生した時点でパケットを発行し、発行されたそれぞれのパケットに対し圧縮を加えてゲームサーバへ送信するようにすることで、ネットワークに対する負荷が軽減されることから、素早いレスポンスが得られるものと考えられる。
【０００３】
ところが、ネットワークゲームでは、１サーバ当りの最大接続可能な人数（クライアントシステム）は設定されているものの、いつもほぼ同じ人数のプレイヤが参加しているのではなく、時間によるバラツキが大きいため、瞬間的なネットワーク負荷を予測することは極めて困難である。そのため、用意されているバックボーン以上の通信量が発生した場合には、トラヒックの増加により、ゲームサーバからの応答にタイムラグが発生してしまう。このため、レスポンスの維持が困難となる。それを回避するためには、ネットワークゲームに参加するプレイヤが多くなるに伴い、パケット量を必要以上には、抑制する必要が生じるものと予測される。
【０００４】
また、一般にネットワークゲームのプレイ中においては、パケットが常時頻繁に流れており、途切れることが無い。この場合、プレイを一時中断したり、途中でプレイを放棄するクライアント（プレイヤ）も出てくるが、ゲームが進行中であるとき、ゲームサーバ側ではその分の通信リソースを他のクライアントに振分けるということは技術的に困難である。
【０００５】
【発明が解決しようとする課題】
このように、ネットワークゲームにおけるゲームの興趣性を高めるには、素早いレスポンスが要求されるため、ネットワークゲームにおけるレスポンスの向上を図ることができるシステムの開発が望まれていた。
【０００６】
本発明は、上述のような状況に鑑みてなされたものであり、ゲームサーバのサーバシステムとゲーム端末装置のクライアントシステムがネットワーク接続されるネットワークゲームシステムにおいて、ゲームサーバの負荷の最大値を決めておくことができるように、すなわち、サーバシステムとクライアントシステムとの間のパケット通信における最大通信量を、所定の値に定めるように、送信パケットは所定量とすることで、ネットワークに対する負荷を軽減し、ネットワークゲームにおけるレスポンスの向上を図ることを目的とするものである。
【０００７】
【課題を解決するための手段】
上記の目的を達成するため、本発明は第１の態様として、本発明によるネットワークゲームシステムは、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間でゲーム進行に応じてキャラクタの情報のやり取りが行われるネットワークゲームシステムであって、前記クライアントシステムに設けられて、ネットワークゲームの進行に応じた利用者の操作入力による生成されたリクエストを順に格納する第１の格納手段と、前記クライアントシステムに設けられて、前記第１の格納手段に格納された未送信リクエストがある場合に当該未送信リクエストを所定量に到達するまで格納する第２の格納手段と、前記クライアントシステムに設けられて、第２の格納手段に格納された所定量のリクエストに送信番号を付与してゲームサーバシステムに送信する処理を所定時間ごとに行うとともに前記送信番号を前記第１の格納手段に格納されている対応のリクエストに付与して管理するクライアント側リクエスト管理手段と、前記ゲームサーバシステムに設けられて、クライアントシステムから送信されたリクエストの処理が終了した前記送信番号を格納する記憶手段と、前記ゲームサーバシステムに設けられて、クライアントシステムから送信されたリクエストに付与された前記送信番号が前記記憶手段に格納されていない場合にリクエストの処理を行い、処理が終了した前記送信番号をクライアントシステムに返送するとともに前記送信番号を前記記憶手段に格納して管理するサーバ側リクエスト管理手段と、を備え、クライアント側リクエスト管理手段は、ゲームサーバシステムから返送された前記送信番号に基づいて当該送信番号に対応するリクエストを廃棄することを特徴とするものである。
【０００８】
第1の態様のネットワークゲームシステムにおいて、前記サーバ側リクエスト管理手段は前記記憶手段に前記送信番号が格納されている場合には、リクエストの処理を行うことなく、クライアントシステムから送信されたリクエストを破棄するようにしてもよい。
【０００９】
また、第１の態様のネットワークゲームシステムにおいて、前記クライアント側リクエスト管理手段は、所定の時間内に前記ゲームサーバシステムから前記送信番号の返送がない場合、当該送信番号に対応するリクエストを再送するようにしてもよい。
【００１０】
また、この場合に、ネットワークゲームシステムにおいては、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間の通信には、通信プロトコルとしてＵＤＰ／ＩＰプロトコルにより通信を行う。
【００１１】
本発明は第２の態様として、本発明によるネットワークゲーム処理方法は、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間でゲーム進行に応じてキャラクタの情報のやり取りを行いネットワークゲームの処理を行うネットワークゲーム処理方法であって、前記クライアントシステムにおいて処理される、前記クライアントシステムの第１の格納手段に、ネットワークゲームの進行に応じた利用者の操作入力による生成されたリクエストを順に格納する工程と、前記クライアントシステムの第２の格納手段に、前記第１の格納手段に格納された未送信リクエストがある場合に当該未送信リクエストを所定量に到達するまで格納する工程と、第２の格納手段に格納された所定量のリクエストに送信番号を付与してゲームサーバシステムに送信する処理を所定時間ごとに行うとともに前記送信番号を前記第１の格納手段に格納されている対応のリクエストに付与して管理するクライアント側リクエスト管理工程と、前記ゲームサーバシステムにおいて処理される、前記ゲームサーバシステムの記憶手段に、クライアントシステムから送信されたリクエストの処理が終了した前記送信番号を格納する工程と、クライアントシステムから送信されたリクエストに付与された前記送信番号が前記記憶手段に格納されていない場合にリクエストの処理を行い、処理が終了した前記送信番号をクライアントシステムに返送するとともに前記送信番号を前記記憶手段に格納して管理するサーバ側リクエスト管理工程と、前記クライアントシステムにおいて処理される、ゲームサーバシステムから返送された前記送信番号に基づいて当該送信番号に対応するリクエストを廃棄する工程とを行うことを特徴とするものである。
【００１２】
第２の態様のネットワークゲーム処理方法において、前記サーバ側リクエスト管理工程は、前記記憶手段に前記送信番号が格納されている場合には、リクエストの処理を行うことなく、クライアントシステムから送信されたリクエストを破棄するようにしてもよい。
【００１３】
また、第２の態様のネットワークゲーム処理方法において、前記クライアント側リクエスト管理工程は、所定の時間内に前記ゲームサーバシステムから前記送信番号の返送がない場合、当該送信番号に対応するリクエストを再送するようにしてもよい。
【００１４】
この場合に、ネットワークゲーム処理方法においては、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間の通信には、通信プロトコルとしてＵＤＰ／ＩＰプロトコルにより通信を行う。
【００１５】
【発明の実施の形態】
以下、添付図面を参照して本発明の実施の形態について説明する。
【００１６】
図１は、本発明のネットワークゲームシステムの一実施の形態を示す図である。図１に示すネットワークゲームシステムは、ネットワークゲームを実行するための環境を提供するサーバシステムであるエコーサーバ１００とゲームに参加する際に使用される複数のクライアントシステムであるゲーム端末装置のクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとがネットワーク３００を介して相互に通信できる構成とされている。
【００１７】
エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間は、パケット通信が行われて、ゲームを進行させる。パケット通信を行う際の通信プロトコルは、ＴＣＰ／ＩＰに比べて煩雑な手順を必要としないためにデータ転送が高速となるＵＤＰ／ＩＰが用いられる。
【００１８】
また、エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のパケット通信における単位時間内における最大通信量は、予め所定の値（設定値）に定められている。これは、瞬間的なネットワーク負荷を予測することが極めて困難であることに対しての対処であり、すなわち、この場合に、ネットワーク負荷が予め定められている所定の値（設定値）を越えなくするような構成とすることで、エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のレスポンスが良好に維持される。また、パケット通信における最大通信量が所定の値（設定値）を越えないようにするために、エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間の送信パケットのサイズも予め定められているが、その詳細は後述する。
【００１９】
エコーサーバ１００は、図２に示すように、クライアント管理部１０１、サーバ側リクエスト管理部１０２、記憶装置１０３、通信インターフェイス１０４を備えている。
【００２０】
クライアント管理部１０１は、ネットワーク３００を介してアクセスのある各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃを管理するものである。管理の際には、たとえば、各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからのパケット内の発信者を示すデータによってそれぞれのクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃを識別することができる。
【００２１】
サーバ側リクエスト管理部１０２は、ゲーム進行中に発生する各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからのリクエストを管理するものであるが、その詳細は後述する。記憶装置１０３には、各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからのリクエストを処理した情報やその情報の履歴等が記憶される。リクエストの詳細については、後述する。通信インターフェイス１０４は、ネットワーク３００を介し各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間でのパケット通信を行うものである。
【００２２】
各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃは、図３に示すように、制御部２０１、ＲＡＭ２０２、クライアント側リクエスト管理部２０３、ＱＵＥバッファ２０４、パケットバッファ２０５、サウンド処理部２０６、入力部２０７、インターフェイス部２０８、グラフィック処理部２０９、ＣＤ−ＲＯＭドライブ２１０、通信インターフェイス２１１を備えている。また、各部のデータのやり取りは、データバス２１３を介して行われる。
【００２３】
制御部２０１は、図示しないＲＯＭに格納されている所定の制御プログラムに従い各部の動作を制御するものである。ＲＡＭ２０２には、たとえばＣＤ−ＲＯＭドライブ２１０によって再生されるＣＤ−ＲＯＭ２２１のゲームプログラムやオーディオ／ビデオデータ等が記憶される。
【００２４】
クライアント側リクエスト管理部２０３は、リクエストの管理を行うものである。リクエストの管理を行うに際しては、各種リクエストをネットワークゲームの進行に伴いプレイヤの操作入力に応じて生成するとともに、その生成した各種リクエストをＱＵＥバッファ２０４に一旦格納し、所定のタイミングでその格納したリクエストを所定の数だけパケットバッファ２０５に格納した後、パケットバッファ２０５に格納したリクエストの送信パケットを、所定の間隔で発行するようになっている。
【００２５】
ここで、リクエストは、後述するように、ゲーム進行におけるプレイヤの判断の結果であるプレイヤの操作入力に応じて、プレイヤ・キャラクタが何らかの行動を行い生成されるものである。たとえば、位置の移動、コマンド（戦う、魔法等）の実行、装備の変更等を指示する操作入力により生成される。また、夫々の操作入力に応じて生成される各種リクエストの大きさは、その種類によって異なるが、数十バイトの大きさであり、それらのリクエストが、後述する所定の大きさ（たとえば１５００バイト程度）を持ったパケットバッファ２０５に搭載（スタック）可能な範囲で積み込まれる。そのため、搭載（スタック）されるリクエスト（群）の総量が、パケットバッファ２０５の所定量を越えることはなく、このため、スタックされるリクエストの数が制御されるようになっている。
【００２６】
第１の格納手段であるＱＵＥバッファ２０４には、ゲーム進行中に生成される各種リクエストが一旦格納される。第２の格納手段であるパケットバッファ２０５には、エコーサーバ１００にリクエストを送信するため、ＱＵＥバッファ２０４内のリクエストが順に格納される。ここで、パケットバッファ２０５は、その格納領域が所定のサイズ（たとえば１５００バイト程度）とされている。そのため、パケットバッファ２０５には、所定のサイズ分（所定量）のリクエストのみが格納されるようになっている。
【００２７】
サウンド処理部２０６は、ＲＡＭ２０２に記憶されているオーディオデータをゲームの進行に合わせてアナログ信号に変換し出力するものである。入力部２０７は、コントローラ、キーボード、リモコン等からの操作指示内容を示すデータを入力するものである。
【００２８】
インターフェイス部２０８は、メモリカード２１２との間でのゲーム情報のやり取りを行うものである。グラフィック処理部２０９は、ＲＡＭ２０２に記憶されているビデオデータをゲームの進行に合わせてアナログ信号に変換し、表示装置２２０に出力するものである。
【００２９】
ＣＤ−ＲＯＭドライブ２１０は、ＣＤ−ＲＯＭ２２１のデータを再生するものである。通信インターフェイス２１１は、ネットワーク３００との通信を受持つものである。
【００３０】
ここで、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとしては、パーソナルコンピュータ、ノートパソコン、ＰＤＡ（個人情報端末）、携帯電話、ＷｅｂＴＶ、通信機能を有したゲーム機器の何れかを用いることができる。
【００３１】
次に、図１のネットワークゲームシステムにおけるネットワークゲーム処理方法について説明する。
【００３２】
まず、通常のパケット送信について説明すると、ネットワークゲームを行うに際しては、ＣＤ−ＲＯＭ２２１をＣＤ−ＲＯＭドライブ２１０によって再生する。ＣＤ−ＲＯＭドライブ２１０によって再生されたゲームプログラムやオーディオ／ビデオデータは、ＲＡＭ２０２に記憶される。ここで、ゲームプログラムは、たとえばロールプレイングゲームとする。
【００３３】
ちなみに、ロールプレイングゲームとは、何らかの目標に向ってゲームが進行していくものや、特に最終的な目標を持たずにゲームが進行していくもの等をいう。何らかの目標に向ってゲームが進行していくものでは、プレイヤがゲーム内に存在するキャラクタ（プレイやキャラクタ）を操作することにより、そのキャラクタとして行動し、数々のイベントをクリアしていく内容となっている。キャラクタの行動（アクション）は、プレイヤの操作入力により決定されるが、このキャラクタの行動の結果がイベントのクリア条件を満たせば、そのイベントがクリアとなる。このようにして一つのイベントをクリアする毎に、最終目標（イベント）に近づいていくことになる。
【００３４】
また、ロールプレイングゲームの舞台には、現実世界の他、英雄が活躍するようなファンタジーの世界、ＳＦで登場するような宇宙、現実世界に非常に似ているが背筋も凍るような怪物の登場するホラーの世界、その他フィクションで出てくるようなありとあらゆる世界を再現しているものがある。
【００３５】
ロールプレイングゲームを行う各プレイヤは、そうした世界の住人であるキャラクタのたとえば何れか一人を操作することにより、そのキャラクタとしてゲームを進めていくことになる。この場合、各プレイヤは、何れかのキャラクタ等を選択することになる。
【００３６】
ゲームを進めていくためには、予め用意されたイベントをクリアすることが要求される。そのため、キャラクタに希望する行動を行わせるように、プレイヤは操作入力する必要がある。キャラクタの行動としては、歩く・走るといった移動行動、剣を振る、魔法を使うというようなモーション行動、装備変更行動等がある。そして、これらの行動を行わせる操作入力を行う度に、その行動に応じたリクエストが生成されることになる。
【００３７】
そこで、まず図４に示すように、プレイヤの操作入力により生成されたリクエストを（Ｒ１〜Ｒ５）とすると、これらのリクエスト（Ｒ１〜Ｒ５）がＱＵＥバッファ２０４に格納される（ステップ４０１）。すなわち、この処理は、図５に示すリクエストの格納動作の処理により行われる。プレイヤの入力操作を受け付け（ステップ５０１）、ある場面にて、自分が選択したキャラクタ（プレイヤ・キャラクタ）に所定の行動を行わせるための何れかの判断を下す処理が行われる（ステップ５０２）。例えば、この場合、コントローラ、キーボード、リモコン等を操作してプレイヤ・キャラクタをその場から移動させたとすると、クライアント側リクエスト管理部２０３の処理により、その行動に応じたリクエストが生成され（ステップ５０３）、この生成されたリクエストが、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４に格納される（ステップ５０４）。
【００３８】
以降、プレイヤが操作入力により、ある場面にてプレイヤ・キャラクタに次の行動をさせる度に、リクエスト管理部２０３の処理により、その行動に応じたリクエストが生成されてＱＵＥバッファ２０４に順次格納されていく。
【００３９】
また、上述したリクエストの生成が行われ、生成されたリクエストがＱＵＥバッファ２０４に格納されると、図４の（ステップ４０２）に示すように、ＱＵＥバッファ２０４内のリクエストがパケットバッファ２０５に格納される。すなわち、この処理は、図６に示すパケットの発行動作の処理により行われる。説明を続けると、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４にリクエストが格納された後、リクエスト管理部２０３の処理により、所定時間が経過したか否かが判断される（ステップ６０１）。所定時間が経過したと判断されると、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４に未送信のリクエストがあるか否かが判断される（ステップ６０２）。なお、未送信のリクエストについては後述する。
【００４０】
未送信のリクエストがあると判断されると、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４内に既に格納されている最先のリクエストがパケットバッファ２０５に格納される（ステップ６０３）。このとき、リクエスト管理部２０３の処理により、パケットバッファ２０５に格納されたリクエストの総量＋最先のリクエストが所定量に到達したか否かが判断される（ステップ６０４）。所定量に到達していない場合は、最先のリクエストの次のリクエストがパケットバッファ２０５に格納される（ステップ６０５）。次に、（ステップ６０６）において、ＱＵＥバッファ２０４に未送信のリクエストがあるか否かが判断され、さらに（ステップ６０４）にて所定量に到達したか否かが判断されて、所定量に到達すると、リクエスト管理部２０３の処理により、パケットバッファ２０５へのリクエストの格納が終了となる（ステップ６０７）。また、（ステップ６０６）において、未送信のリクエストが無い場合もパケットバッファ２０５へのリクエストの格納が終了となる。
【００４１】
パケットバッファ２０５へのリクエストの格納が終了となると、パケットバッファ２０５内のリクエストに送信Ｎｏ（送信番号）が付与される（ステップ６０８）。送信Ｎｏが付与されると、このとき、パケットバッファ２０５内のリクエストに対応するＱＵＥバッファ２０４内のリクエストにも、同一の送信Ｎｏが付与される（ステップ６０９）。これら送信Ｎｏの付与の処理は、リクエスト管理部２０３の処理によって行われる。
【００４２】
送信Ｎｏの付与が終了すると、リクエスト管理部２０３の処理により、パケットバッファ２０５内のリクエストが圧縮されてパケットが発行される（ステップ６１０，６１１）。
【００４３】
そして、図４に示すように、パケットを送信するタイミングである時間ｔ１となると、リクエスト管理部２０３の処理により、発行されたパケットが送信パケットとして、ネットワーク３００を介しエコーサーバ１００に送信される（ステップ４０３）。
【００４４】
エコーサーバ１００側では、クライアント（通信端末）２００からの送信パケットを受取ると（ステップ４０４）、送信パケット内の送信Ｎｏ（Ｓ１）を記憶装置１０３に記憶されている履歴でチェックし（ステップ４０５）、その履歴に送信Ｎｏ（Ｓ１）に該当するものがあれば、既に処理済みであるので、その送信パケットを破棄する。これに対し、その履歴に送信Ｎｏ（Ｓ１）に該当するものが無ければ、送信パケット内のリクエスト（Ｒ１，Ｒ２）の処理を行う（ステップ４０６）。このとき、処理されたリクエスト（Ｒ１，Ｒ２）は、処理済リクエスト（ＲＲ１，ＲＲ２）として記憶装置１０３に記憶される（ステップ４０７）。そして、処理済リクエスト（ＲＲ１，ＲＲ２）が記憶装置１０３に記憶されると、エコーサーバ１００側からは、受取った送信Ｎｏ（Ｓ１）を含めた返信パケットがクライアント（通信端末）２００側に対して返される（ステップ４０８，４０９）。
【００４５】
このとき、クライアント（通信端末）２００側では、リクエスト管理部２０３の処理により、エコーサーバ１００側からの返信パケット内の送信Ｎｏ（Ｓ１）に基づき、その送信Ｎｏ（Ｓ１）に対応するリクエスト（Ｒ１，Ｒ２）がＱＵＥバッファ２０４内にあるか否かが判断され、あると判断された場合には該当するリクエスト（Ｒ１，Ｒ２）が破棄される（ステップ４１０）。
【００４６】
すなわち、この処理は、図７に示す返信パケットの処理動作の処理により行われる。続いて説明すると、クライアント（通信端末）２００側では、エコーサーバ１００側からの返信パケットを受取ると（ステップ７０１）、リクエスト管理部２０３の処理により、その返信パケット内の送信Ｎｏに基づき、その送信Ｎｏに対応するリクエストがＱＵＥバッファ２０４内にあるか否かが判断され（ステップ７０２）、あると判断された場合には該当するリクエストが破棄される（ステップ７０３）。
【００４７】
続いて、図４の（ステップ４１１）から、前述した図６により説明したパケットの発行動作と同様の処理が実行される。すなわち、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４内に格納されている次のリクエスト、すなわち、最先のリクエスト（Ｒ３）、リクエスト（Ｒ４）が順にパケットバッファ２０５に格納され、格納されたリクエスト（Ｒ３，Ｒ４）が所定量に到達したと判断されると、パケットバッファ２０５へのリクエストの格納が終了された後、パケットバッファ２０５内のリクエスト（Ｒ３，Ｒ４）に送信Ｎｏ（Ｓ２）が付与されて書込まれる（ステップ４１１）。このとき、前述の場合と同様に、パケットバッファ２０５内のリクエストに対応するＱＵＥバッファ２０４内のリクエスト（Ｒ３，Ｒ４）にも、同一の送信Ｎｏ（Ｓ２）が付与されて書込まれる（ステップ４１２）。
【００４８】
送信Ｎｏ（Ｓ２）の書込みが終了すると、リクエスト管理部２０３の処理により、パケットバッファ２０５内のリクエスト（Ｒ３，Ｒ４）が圧縮されてパケットが発行される。その後、パケットを送信するタイミングである時間ｔ２となると、上記同様に、発行されたパケットが、送信パケットとしてネットワーク３００を介しエコーサーバ１００に送信される（ステップ４１３）。
【００４９】
エコーサーバ１００側では、上記同様に、クライアント（通信端末）２００からの送信パケットを受取ると（ステップ４１４）、送信パケット内の送信Ｎｏ（Ｓ２）を記憶装置１０３に記憶されている履歴でチェックして（ステップ４１５）、その履歴に送信Ｎｏ（Ｓ２）に該当するものがあれば、その送信パケットを破棄する。これに対し、その履歴に送信Ｎｏ（Ｓ２）に該当するものが無ければ、送信パケット内のリクエスト（Ｒ３，Ｒ４）の処理を行う（ステップ４１６）。このとき、処理されたリクエスト（Ｒ３，Ｒ４）は、処理済リクエスト（ＲＲ３，ＲＲ４）として記憶装置１０３に記憶される（ステップ４１７）。そして、処理済リクエスト（ＲＲ３，ＲＲ４）が記憶装置１０３に記憶されると、エコーサーバ１００側から受取った送信Ｎｏ（Ｓ２）を含めた返信パケットがクライアント（通信端末）２００側に返される（ステップ４１８，４１９）。
【００５０】
クライアント（通信端末）２００側では、上記同様に、リクエスト管理部２０３の処理により、エコーサーバ１００側からの返信パケット内の送信Ｎｏ（Ｓ２）に基づき、その送信Ｎｏ（Ｓ２）に対応するリクエスト（Ｒ３，Ｒ４）がＱＵＥバッファ２０４内にあるか否かが判断され、あると判断した場合には該当するリクエスト（Ｒ３，Ｒ４）が破棄される（ステップ４２０）。
【００５１】
以降、同様にして、図６により説明したように、ＱＵＥバッファに未送信のリクエストがある場合にパケットバッファに所定量のリクエストが格納されるたびに送信パケットを発行して、クライアント（通信端末）２００側から所定量の送信パケットをエコーサーバ１００側に順に送信し、これに対して、エコーサーバから返信パケットを受け取ると、クライアント（通信端末）２００側では返信パケット内の送信Ｎｏに基づき、その送信Ｎｏに対応するリクエストがＱＵＥバッファ２０４内にあるか否かが判断され、あると判断した場合には該当するリクエストが破棄される。このような処理が、ネットワークゲームが終了となるまで繰返される。
【００５２】
次に、次の送信パケットを送信するタイミングの時間になっても先に送信した送信パケットに対する返信パケットが返されていないとき、先に送信した送信パケットが再度送信される場合について、図８により説明する。
【００５３】
図８においては、（ステップ８０１）〜（ステップ８１８）までが図４の（ステップ４０１）〜（ステップ４１８）と同じ手順であるため、ここではその説明を省略する。
【００５４】
すなわち、クライアント（通信端末）２００側では、たとえば、パケットバッファ２０５内のリクエスト（Ｒ３，Ｒ４）に対する送信パケットの送信後、次のリクエスト（Ｒ５以降）に対するパケットの発行処理が進められることになる。そして、リクエスト（Ｒ５以降）に対するパケットの送信タイミングである時間ｔ３となると、上記同様にして、送信パケットがネットワーク３００を介してエコーサーバ１００に送信されることになるが、その場合に、リクエスト（Ｒ３，Ｒ４）に対する返信パケットを受信（ステップ８１９）していない場合には、つまり、時間ｔ３においても返信パケットが返されていないと判断されると、先のリクエスト（Ｒ３，Ｒ４）に対する送信パケットが、時間ｔ３にてエコーサーバ１００に再送される（ステップ８２０，８２１）。
【００５５】
これにより、先に送信された、または、再送されたリクエスト（Ｒ３，Ｒ４）の送信パケットに対する返信パケットが返されることで、次のリクエスト（Ｒ５以降）に対するパケットの送信処理が確実に行われることになる。
【００５６】
このように、本実施の形態では、サーバシステムとしてのエコーサーバ１００とクライアントシステムとしてのクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のパケット通信における最大通信量が、予め所定の値に定めるようにするため、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃから送信する送信パケットを所定のサイズ（所定量）のものとするようにしたので、ネットワーク３００に対する負荷を軽減することができ、素早いレスポンスを得ることができる。
【００５７】
これにより、サーバシステムとしてのエコーサーバ１００とクライアントシステムとしてのクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のパケット通信における最大通信量が、予め所定の値に定められるので、不特定多数のプレイヤの参加により、瞬間的にネットワーク負荷が多くなった場合であっても、用意されているバックボーン以上の通信量が発生しないことから、トラフィックの増加に伴うエコーサーバ１００からの応答のタイムラグも抑制することができる。
【００５８】
また、サーバシステムをエコーサーバ１００とし、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからの送信パケット内の送信Ｎｏが記憶手段としての記憶装置１０３に記憶されている履歴に該当しない場合に限り、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃに送信Ｎｏを含めた返信パケットを返すようにしていることでも、ネットワーク負荷の軽減が図れる。
【００５９】
また、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃにおいては、送受信手段である通信インターフェイス２１１により、エコーサーバ１００へ送信パケットを送信するとともに、エコーサーバ１００からの返信パケットの受信を行うようにし、クライアント側リクエスト管理手段であるクライアント側リクエスト管理部２０３の処理により、ネットワークゲームの進行に伴う各種リクエストを生成して第１の格納手段であるＱＵＥバッファ２０４に格納し、所定時間が経過したとき、ＱＵＥバッファ２０４内のリクエストを所定のサイズ分だけ第２の格納手段であるパケットバッファ２０５に格納し、送信Ｎｏを書込んで圧縮したパケットを発行するようにしたので、ネットワーク負荷が予め定められた最大通信量を越えることが無く、バックボーン以上の通信量の発生を抑制することができる。
【００６０】
しかも、エコーサーバ１００とクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間の送信パケットおよび返信パケットの通信プロトコルは、ＴＣＰ／ＩＰに比べて煩雑な手順を必要としないＵＤＰ／ＩＰとしているため、パケット通信を高速で行うことができる。
【００６１】
この場合、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃにおいては、所定の時間内にエコーサーバ１００からの返信パケットの受け取りが無い場合に、前回送信した送信パケットの再送を行うようにしているので、ＴＣＰ／ＩＰに採用されている手順でなくても、すなわち、パケット送信の度に受信確認の通信を行わなくても、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとエコーサーバ１００との間では、リクエストの送信およびその処理を確実に行うことができる。
【００６２】
【発明の効果】
以上説明したように、本発明によれば、ゲームサーバの負荷の最大値を決めておくことができるので、ネットワークゲームにおけるレスポンスの向上を図ることができる。
【図面の簡単な説明】
【図１】 本発明のネットワークゲームシステムの一実施の形態を示す図である。
【図２】 図１のネットワークゲームシステムのエコーサーバの詳細を示す図である。
【図３】 図１のネットワークゲームシステムのクライアント（通信端末）の詳細を示す図である。
【図４】 図１のネットワークゲームシステムにおける通常動作を説明するためのタイムチャートである。
【図５】 図３のクライアント（通信端末）におけるリクエストの格納動作を説明するためのフローチャートである。
【図６】 図３のクライアント（通信端末）におけるパケットの発行動作を説明するためのフローチャートである。
【図７】 図３のクライアント（通信端末）における返信パケットの処理動作を説明するためのフローチャートである。
【図８】 図１のネットワークゲームシステムにおける再送動作を説明するためのタイムチャートである。
【符号の説明】
１００ エコーサーバ
２００Ａ，２００Ｂ，２００Ｃ，２００ クライアント（通信端末）
３００ ネットワーク
１０１ クライアント管理部
１０２ サーバ側リクエスト管理部
１０３ 記憶装置
２０３ クライアント側リクエスト管理部
２０４ ＱＵＥバッファ
２０５ パケットバッファ
２１１ 通信インターフェイス
【発明の属する技術分野】
本発明は、ＵＤＰ／ＩＰの通信プロトコルを用いたネットワークゲームシステムおよびネットワークゲーム処理方法に関する。
【０００２】
【従来の技術】
ネットワークゲームにおいてはゲームの興趣性を高めるには、素早いレスポンスが要求される。この場合、クライアントシステムとなるゲーム端末装置においは、プレイヤの操作に応じてのリクエストが発生した時点でパケットを発行し、発行されたそれぞれのパケットに対し圧縮を加えてゲームサーバへ送信するようにすることで、ネットワークに対する負荷が軽減されることから、素早いレスポンスが得られるものと考えられる。
【０００３】
ところが、ネットワークゲームでは、１サーバ当りの最大接続可能な人数（クライアントシステム）は設定されているものの、いつもほぼ同じ人数のプレイヤが参加しているのではなく、時間によるバラツキが大きいため、瞬間的なネットワーク負荷を予測することは極めて困難である。そのため、用意されているバックボーン以上の通信量が発生した場合には、トラヒックの増加により、ゲームサーバからの応答にタイムラグが発生してしまう。このため、レスポンスの維持が困難となる。それを回避するためには、ネットワークゲームに参加するプレイヤが多くなるに伴い、パケット量を必要以上には、抑制する必要が生じるものと予測される。
【０００４】
また、一般にネットワークゲームのプレイ中においては、パケットが常時頻繁に流れており、途切れることが無い。この場合、プレイを一時中断したり、途中でプレイを放棄するクライアント（プレイヤ）も出てくるが、ゲームが進行中であるとき、ゲームサーバ側ではその分の通信リソースを他のクライアントに振分けるということは技術的に困難である。
【０００５】
【発明が解決しようとする課題】
このように、ネットワークゲームにおけるゲームの興趣性を高めるには、素早いレスポンスが要求されるため、ネットワークゲームにおけるレスポンスの向上を図ることができるシステムの開発が望まれていた。
【０００６】
本発明は、上述のような状況に鑑みてなされたものであり、ゲームサーバのサーバシステムとゲーム端末装置のクライアントシステムがネットワーク接続されるネットワークゲームシステムにおいて、ゲームサーバの負荷の最大値を決めておくことができるように、すなわち、サーバシステムとクライアントシステムとの間のパケット通信における最大通信量を、所定の値に定めるように、送信パケットは所定量とすることで、ネットワークに対する負荷を軽減し、ネットワークゲームにおけるレスポンスの向上を図ることを目的とするものである。
【０００７】
【課題を解決するための手段】
上記の目的を達成するため、本発明は第１の態様として、本発明によるネットワークゲームシステムは、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間でゲーム進行に応じてキャラクタの情報のやり取りが行われるネットワークゲームシステムであって、前記クライアントシステムに設けられて、ネットワークゲームの進行に応じた利用者の操作入力による生成されたリクエストを順に格納する第１の格納手段と、前記クライアントシステムに設けられて、前記第１の格納手段に格納された未送信リクエストがある場合に当該未送信リクエストを所定量に到達するまで格納する第２の格納手段と、前記クライアントシステムに設けられて、第２の格納手段に格納された所定量のリクエストに送信番号を付与してゲームサーバシステムに送信する処理を所定時間ごとに行うとともに前記送信番号を前記第１の格納手段に格納されている対応のリクエストに付与して管理するクライアント側リクエスト管理手段と、前記ゲームサーバシステムに設けられて、クライアントシステムから送信されたリクエストの処理が終了した前記送信番号を格納する記憶手段と、前記ゲームサーバシステムに設けられて、クライアントシステムから送信されたリクエストに付与された前記送信番号が前記記憶手段に格納されていない場合にリクエストの処理を行い、処理が終了した前記送信番号をクライアントシステムに返送するとともに前記送信番号を前記記憶手段に格納して管理するサーバ側リクエスト管理手段と、を備え、クライアント側リクエスト管理手段は、ゲームサーバシステムから返送された前記送信番号に基づいて当該送信番号に対応するリクエストを廃棄することを特徴とするものである。
【０００８】
第1の態様のネットワークゲームシステムにおいて、前記サーバ側リクエスト管理手段は前記記憶手段に前記送信番号が格納されている場合には、リクエストの処理を行うことなく、クライアントシステムから送信されたリクエストを破棄するようにしてもよい。
【０００９】
また、第１の態様のネットワークゲームシステムにおいて、前記クライアント側リクエスト管理手段は、所定の時間内に前記ゲームサーバシステムから前記送信番号の返送がない場合、当該送信番号に対応するリクエストを再送するようにしてもよい。
【００１０】
また、この場合に、ネットワークゲームシステムにおいては、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間の通信には、通信プロトコルとしてＵＤＰ／ＩＰプロトコルにより通信を行う。
【００１１】
本発明は第２の態様として、本発明によるネットワークゲーム処理方法は、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間でゲーム進行に応じてキャラクタの情報のやり取りを行いネットワークゲームの処理を行うネットワークゲーム処理方法であって、前記クライアントシステムにおいて処理される、前記クライアントシステムの第１の格納手段に、ネットワークゲームの進行に応じた利用者の操作入力による生成されたリクエストを順に格納する工程と、前記クライアントシステムの第２の格納手段に、前記第１の格納手段に格納された未送信リクエストがある場合に当該未送信リクエストを所定量に到達するまで格納する工程と、第２の格納手段に格納された所定量のリクエストに送信番号を付与してゲームサーバシステムに送信する処理を所定時間ごとに行うとともに前記送信番号を前記第１の格納手段に格納されている対応のリクエストに付与して管理するクライアント側リクエスト管理工程と、前記ゲームサーバシステムにおいて処理される、前記ゲームサーバシステムの記憶手段に、クライアントシステムから送信されたリクエストの処理が終了した前記送信番号を格納する工程と、クライアントシステムから送信されたリクエストに付与された前記送信番号が前記記憶手段に格納されていない場合にリクエストの処理を行い、処理が終了した前記送信番号をクライアントシステムに返送するとともに前記送信番号を前記記憶手段に格納して管理するサーバ側リクエスト管理工程と、前記クライアントシステムにおいて処理される、ゲームサーバシステムから返送された前記送信番号に基づいて当該送信番号に対応するリクエストを廃棄する工程とを行うことを特徴とするものである。
【００１２】
第２の態様のネットワークゲーム処理方法において、前記サーバ側リクエスト管理工程は、前記記憶手段に前記送信番号が格納されている場合には、リクエストの処理を行うことなく、クライアントシステムから送信されたリクエストを破棄するようにしてもよい。
【００１３】
また、第２の態様のネットワークゲーム処理方法において、前記クライアント側リクエスト管理工程は、所定の時間内に前記ゲームサーバシステムから前記送信番号の返送がない場合、当該送信番号に対応するリクエストを再送するようにしてもよい。
【００１４】
この場合に、ネットワークゲーム処理方法においては、ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間の通信には、通信プロトコルとしてＵＤＰ／ＩＰプロトコルにより通信を行う。
【００１５】
【発明の実施の形態】
以下、添付図面を参照して本発明の実施の形態について説明する。
【００１６】
図１は、本発明のネットワークゲームシステムの一実施の形態を示す図である。図１に示すネットワークゲームシステムは、ネットワークゲームを実行するための環境を提供するサーバシステムであるエコーサーバ１００とゲームに参加する際に使用される複数のクライアントシステムであるゲーム端末装置のクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとがネットワーク３００を介して相互に通信できる構成とされている。
【００１７】
エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間は、パケット通信が行われて、ゲームを進行させる。パケット通信を行う際の通信プロトコルは、ＴＣＰ／ＩＰに比べて煩雑な手順を必要としないためにデータ転送が高速となるＵＤＰ／ＩＰが用いられる。
【００１８】
また、エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のパケット通信における単位時間内における最大通信量は、予め所定の値（設定値）に定められている。これは、瞬間的なネットワーク負荷を予測することが極めて困難であることに対しての対処であり、すなわち、この場合に、ネットワーク負荷が予め定められている所定の値（設定値）を越えなくするような構成とすることで、エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のレスポンスが良好に維持される。また、パケット通信における最大通信量が所定の値（設定値）を越えないようにするために、エコーサーバ１００と各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間の送信パケットのサイズも予め定められているが、その詳細は後述する。
【００１９】
エコーサーバ１００は、図２に示すように、クライアント管理部１０１、サーバ側リクエスト管理部１０２、記憶装置１０３、通信インターフェイス１０４を備えている。
【００２０】
クライアント管理部１０１は、ネットワーク３００を介してアクセスのある各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃを管理するものである。管理の際には、たとえば、各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからのパケット内の発信者を示すデータによってそれぞれのクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃを識別することができる。
【００２１】
サーバ側リクエスト管理部１０２は、ゲーム進行中に発生する各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからのリクエストを管理するものであるが、その詳細は後述する。記憶装置１０３には、各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからのリクエストを処理した情報やその情報の履歴等が記憶される。リクエストの詳細については、後述する。通信インターフェイス１０４は、ネットワーク３００を介し各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間でのパケット通信を行うものである。
【００２２】
各クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃは、図３に示すように、制御部２０１、ＲＡＭ２０２、クライアント側リクエスト管理部２０３、ＱＵＥバッファ２０４、パケットバッファ２０５、サウンド処理部２０６、入力部２０７、インターフェイス部２０８、グラフィック処理部２０９、ＣＤ−ＲＯＭドライブ２１０、通信インターフェイス２１１を備えている。また、各部のデータのやり取りは、データバス２１３を介して行われる。
【００２３】
制御部２０１は、図示しないＲＯＭに格納されている所定の制御プログラムに従い各部の動作を制御するものである。ＲＡＭ２０２には、たとえばＣＤ−ＲＯＭドライブ２１０によって再生されるＣＤ−ＲＯＭ２２１のゲームプログラムやオーディオ／ビデオデータ等が記憶される。
【００２４】
クライアント側リクエスト管理部２０３は、リクエストの管理を行うものである。リクエストの管理を行うに際しては、各種リクエストをネットワークゲームの進行に伴いプレイヤの操作入力に応じて生成するとともに、その生成した各種リクエストをＱＵＥバッファ２０４に一旦格納し、所定のタイミングでその格納したリクエストを所定の数だけパケットバッファ２０５に格納した後、パケットバッファ２０５に格納したリクエストの送信パケットを、所定の間隔で発行するようになっている。
【００２５】
ここで、リクエストは、後述するように、ゲーム進行におけるプレイヤの判断の結果であるプレイヤの操作入力に応じて、プレイヤ・キャラクタが何らかの行動を行い生成されるものである。たとえば、位置の移動、コマンド（戦う、魔法等）の実行、装備の変更等を指示する操作入力により生成される。また、夫々の操作入力に応じて生成される各種リクエストの大きさは、その種類によって異なるが、数十バイトの大きさであり、それらのリクエストが、後述する所定の大きさ（たとえば１５００バイト程度）を持ったパケットバッファ２０５に搭載（スタック）可能な範囲で積み込まれる。そのため、搭載（スタック）されるリクエスト（群）の総量が、パケットバッファ２０５の所定量を越えることはなく、このため、スタックされるリクエストの数が制御されるようになっている。
【００２６】
第１の格納手段であるＱＵＥバッファ２０４には、ゲーム進行中に生成される各種リクエストが一旦格納される。第２の格納手段であるパケットバッファ２０５には、エコーサーバ１００にリクエストを送信するため、ＱＵＥバッファ２０４内のリクエストが順に格納される。ここで、パケットバッファ２０５は、その格納領域が所定のサイズ（たとえば１５００バイト程度）とされている。そのため、パケットバッファ２０５には、所定のサイズ分（所定量）のリクエストのみが格納されるようになっている。
【００２７】
サウンド処理部２０６は、ＲＡＭ２０２に記憶されているオーディオデータをゲームの進行に合わせてアナログ信号に変換し出力するものである。入力部２０７は、コントローラ、キーボード、リモコン等からの操作指示内容を示すデータを入力するものである。
【００２８】
インターフェイス部２０８は、メモリカード２１２との間でのゲーム情報のやり取りを行うものである。グラフィック処理部２０９は、ＲＡＭ２０２に記憶されているビデオデータをゲームの進行に合わせてアナログ信号に変換し、表示装置２２０に出力するものである。
【００２９】
ＣＤ−ＲＯＭドライブ２１０は、ＣＤ−ＲＯＭ２２１のデータを再生するものである。通信インターフェイス２１１は、ネットワーク３００との通信を受持つものである。
【００３０】
ここで、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとしては、パーソナルコンピュータ、ノートパソコン、ＰＤＡ（個人情報端末）、携帯電話、ＷｅｂＴＶ、通信機能を有したゲーム機器の何れかを用いることができる。
【００３１】
次に、図１のネットワークゲームシステムにおけるネットワークゲーム処理方法について説明する。
【００３２】
まず、通常のパケット送信について説明すると、ネットワークゲームを行うに際しては、ＣＤ−ＲＯＭ２２１をＣＤ−ＲＯＭドライブ２１０によって再生する。ＣＤ−ＲＯＭドライブ２１０によって再生されたゲームプログラムやオーディオ／ビデオデータは、ＲＡＭ２０２に記憶される。ここで、ゲームプログラムは、たとえばロールプレイングゲームとする。
【００３３】
ちなみに、ロールプレイングゲームとは、何らかの目標に向ってゲームが進行していくものや、特に最終的な目標を持たずにゲームが進行していくもの等をいう。何らかの目標に向ってゲームが進行していくものでは、プレイヤがゲーム内に存在するキャラクタ（プレイやキャラクタ）を操作することにより、そのキャラクタとして行動し、数々のイベントをクリアしていく内容となっている。キャラクタの行動（アクション）は、プレイヤの操作入力により決定されるが、このキャラクタの行動の結果がイベントのクリア条件を満たせば、そのイベントがクリアとなる。このようにして一つのイベントをクリアする毎に、最終目標（イベント）に近づいていくことになる。
【００３４】
また、ロールプレイングゲームの舞台には、現実世界の他、英雄が活躍するようなファンタジーの世界、ＳＦで登場するような宇宙、現実世界に非常に似ているが背筋も凍るような怪物の登場するホラーの世界、その他フィクションで出てくるようなありとあらゆる世界を再現しているものがある。
【００３５】
ロールプレイングゲームを行う各プレイヤは、そうした世界の住人であるキャラクタのたとえば何れか一人を操作することにより、そのキャラクタとしてゲームを進めていくことになる。この場合、各プレイヤは、何れかのキャラクタ等を選択することになる。
【００３６】
ゲームを進めていくためには、予め用意されたイベントをクリアすることが要求される。そのため、キャラクタに希望する行動を行わせるように、プレイヤは操作入力する必要がある。キャラクタの行動としては、歩く・走るといった移動行動、剣を振る、魔法を使うというようなモーション行動、装備変更行動等がある。そして、これらの行動を行わせる操作入力を行う度に、その行動に応じたリクエストが生成されることになる。
【００３７】
そこで、まず図４に示すように、プレイヤの操作入力により生成されたリクエストを（Ｒ１〜Ｒ５）とすると、これらのリクエスト（Ｒ１〜Ｒ５）がＱＵＥバッファ２０４に格納される（ステップ４０１）。すなわち、この処理は、図５に示すリクエストの格納動作の処理により行われる。プレイヤの入力操作を受け付け（ステップ５０１）、ある場面にて、自分が選択したキャラクタ（プレイヤ・キャラクタ）に所定の行動を行わせるための何れかの判断を下す処理が行われる（ステップ５０２）。例えば、この場合、コントローラ、キーボード、リモコン等を操作してプレイヤ・キャラクタをその場から移動させたとすると、クライアント側リクエスト管理部２０３の処理により、その行動に応じたリクエストが生成され（ステップ５０３）、この生成されたリクエストが、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４に格納される（ステップ５０４）。
【００３８】
以降、プレイヤが操作入力により、ある場面にてプレイヤ・キャラクタに次の行動をさせる度に、リクエスト管理部２０３の処理により、その行動に応じたリクエストが生成されてＱＵＥバッファ２０４に順次格納されていく。
【００３９】
また、上述したリクエストの生成が行われ、生成されたリクエストがＱＵＥバッファ２０４に格納されると、図４の（ステップ４０２）に示すように、ＱＵＥバッファ２０４内のリクエストがパケットバッファ２０５に格納される。すなわち、この処理は、図６に示すパケットの発行動作の処理により行われる。説明を続けると、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４にリクエストが格納された後、リクエスト管理部２０３の処理により、所定時間が経過したか否かが判断される（ステップ６０１）。所定時間が経過したと判断されると、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４に未送信のリクエストがあるか否かが判断される（ステップ６０２）。なお、未送信のリクエストについては後述する。
【００４０】
未送信のリクエストがあると判断されると、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４内に既に格納されている最先のリクエストがパケットバッファ２０５に格納される（ステップ６０３）。このとき、リクエスト管理部２０３の処理により、パケットバッファ２０５に格納されたリクエストの総量＋最先のリクエストが所定量に到達したか否かが判断される（ステップ６０４）。所定量に到達していない場合は、最先のリクエストの次のリクエストがパケットバッファ２０５に格納される（ステップ６０５）。次に、（ステップ６０６）において、ＱＵＥバッファ２０４に未送信のリクエストがあるか否かが判断され、さらに（ステップ６０４）にて所定量に到達したか否かが判断されて、所定量に到達すると、リクエスト管理部２０３の処理により、パケットバッファ２０５へのリクエストの格納が終了となる（ステップ６０７）。また、（ステップ６０６）において、未送信のリクエストが無い場合もパケットバッファ２０５へのリクエストの格納が終了となる。
【００４１】
パケットバッファ２０５へのリクエストの格納が終了となると、パケットバッファ２０５内のリクエストに送信Ｎｏ（送信番号）が付与される（ステップ６０８）。送信Ｎｏが付与されると、このとき、パケットバッファ２０５内のリクエストに対応するＱＵＥバッファ２０４内のリクエストにも、同一の送信Ｎｏが付与される（ステップ６０９）。これら送信Ｎｏの付与の処理は、リクエスト管理部２０３の処理によって行われる。
【００４２】
送信Ｎｏの付与が終了すると、リクエスト管理部２０３の処理により、パケットバッファ２０５内のリクエストが圧縮されてパケットが発行される（ステップ６１０，６１１）。
【００４３】
そして、図４に示すように、パケットを送信するタイミングである時間ｔ１となると、リクエスト管理部２０３の処理により、発行されたパケットが送信パケットとして、ネットワーク３００を介しエコーサーバ１００に送信される（ステップ４０３）。
【００４４】
エコーサーバ１００側では、クライアント（通信端末）２００からの送信パケットを受取ると（ステップ４０４）、送信パケット内の送信Ｎｏ（Ｓ１）を記憶装置１０３に記憶されている履歴でチェックし（ステップ４０５）、その履歴に送信Ｎｏ（Ｓ１）に該当するものがあれば、既に処理済みであるので、その送信パケットを破棄する。これに対し、その履歴に送信Ｎｏ（Ｓ１）に該当するものが無ければ、送信パケット内のリクエスト（Ｒ１，Ｒ２）の処理を行う（ステップ４０６）。このとき、処理されたリクエスト（Ｒ１，Ｒ２）は、処理済リクエスト（ＲＲ１，ＲＲ２）として記憶装置１０３に記憶される（ステップ４０７）。そして、処理済リクエスト（ＲＲ１，ＲＲ２）が記憶装置１０３に記憶されると、エコーサーバ１００側からは、受取った送信Ｎｏ（Ｓ１）を含めた返信パケットがクライアント（通信端末）２００側に対して返される（ステップ４０８，４０９）。
【００４５】
このとき、クライアント（通信端末）２００側では、リクエスト管理部２０３の処理により、エコーサーバ１００側からの返信パケット内の送信Ｎｏ（Ｓ１）に基づき、その送信Ｎｏ（Ｓ１）に対応するリクエスト（Ｒ１，Ｒ２）がＱＵＥバッファ２０４内にあるか否かが判断され、あると判断された場合には該当するリクエスト（Ｒ１，Ｒ２）が破棄される（ステップ４１０）。
【００４６】
すなわち、この処理は、図７に示す返信パケットの処理動作の処理により行われる。続いて説明すると、クライアント（通信端末）２００側では、エコーサーバ１００側からの返信パケットを受取ると（ステップ７０１）、リクエスト管理部２０３の処理により、その返信パケット内の送信Ｎｏに基づき、その送信Ｎｏに対応するリクエストがＱＵＥバッファ２０４内にあるか否かが判断され（ステップ７０２）、あると判断された場合には該当するリクエストが破棄される（ステップ７０３）。
【００４７】
続いて、図４の（ステップ４１１）から、前述した図６により説明したパケットの発行動作と同様の処理が実行される。すなわち、リクエスト管理部２０３の処理により、ＱＵＥバッファ２０４内に格納されている次のリクエスト、すなわち、最先のリクエスト（Ｒ３）、リクエスト（Ｒ４）が順にパケットバッファ２０５に格納され、格納されたリクエスト（Ｒ３，Ｒ４）が所定量に到達したと判断されると、パケットバッファ２０５へのリクエストの格納が終了された後、パケットバッファ２０５内のリクエスト（Ｒ３，Ｒ４）に送信Ｎｏ（Ｓ２）が付与されて書込まれる（ステップ４１１）。このとき、前述の場合と同様に、パケットバッファ２０５内のリクエストに対応するＱＵＥバッファ２０４内のリクエスト（Ｒ３，Ｒ４）にも、同一の送信Ｎｏ（Ｓ２）が付与されて書込まれる（ステップ４１２）。
【００４８】
送信Ｎｏ（Ｓ２）の書込みが終了すると、リクエスト管理部２０３の処理により、パケットバッファ２０５内のリクエスト（Ｒ３，Ｒ４）が圧縮されてパケットが発行される。その後、パケットを送信するタイミングである時間ｔ２となると、上記同様に、発行されたパケットが、送信パケットとしてネットワーク３００を介しエコーサーバ１００に送信される（ステップ４１３）。
【００４９】
エコーサーバ１００側では、上記同様に、クライアント（通信端末）２００からの送信パケットを受取ると（ステップ４１４）、送信パケット内の送信Ｎｏ（Ｓ２）を記憶装置１０３に記憶されている履歴でチェックして（ステップ４１５）、その履歴に送信Ｎｏ（Ｓ２）に該当するものがあれば、その送信パケットを破棄する。これに対し、その履歴に送信Ｎｏ（Ｓ２）に該当するものが無ければ、送信パケット内のリクエスト（Ｒ３，Ｒ４）の処理を行う（ステップ４１６）。このとき、処理されたリクエスト（Ｒ３，Ｒ４）は、処理済リクエスト（ＲＲ３，ＲＲ４）として記憶装置１０３に記憶される（ステップ４１７）。そして、処理済リクエスト（ＲＲ３，ＲＲ４）が記憶装置１０３に記憶されると、エコーサーバ１００側から受取った送信Ｎｏ（Ｓ２）を含めた返信パケットがクライアント（通信端末）２００側に返される（ステップ４１８，４１９）。
【００５０】
クライアント（通信端末）２００側では、上記同様に、リクエスト管理部２０３の処理により、エコーサーバ１００側からの返信パケット内の送信Ｎｏ（Ｓ２）に基づき、その送信Ｎｏ（Ｓ２）に対応するリクエスト（Ｒ３，Ｒ４）がＱＵＥバッファ２０４内にあるか否かが判断され、あると判断した場合には該当するリクエスト（Ｒ３，Ｒ４）が破棄される（ステップ４２０）。
【００５１】
以降、同様にして、図６により説明したように、ＱＵＥバッファに未送信のリクエストがある場合にパケットバッファに所定量のリクエストが格納されるたびに送信パケットを発行して、クライアント（通信端末）２００側から所定量の送信パケットをエコーサーバ１００側に順に送信し、これに対して、エコーサーバから返信パケットを受け取ると、クライアント（通信端末）２００側では返信パケット内の送信Ｎｏに基づき、その送信Ｎｏに対応するリクエストがＱＵＥバッファ２０４内にあるか否かが判断され、あると判断した場合には該当するリクエストが破棄される。このような処理が、ネットワークゲームが終了となるまで繰返される。
【００５２】
次に、次の送信パケットを送信するタイミングの時間になっても先に送信した送信パケットに対する返信パケットが返されていないとき、先に送信した送信パケットが再度送信される場合について、図８により説明する。
【００５３】
図８においては、（ステップ８０１）〜（ステップ８１８）までが図４の（ステップ４０１）〜（ステップ４１８）と同じ手順であるため、ここではその説明を省略する。
【００５４】
すなわち、クライアント（通信端末）２００側では、たとえば、パケットバッファ２０５内のリクエスト（Ｒ３，Ｒ４）に対する送信パケットの送信後、次のリクエスト（Ｒ５以降）に対するパケットの発行処理が進められることになる。そして、リクエスト（Ｒ５以降）に対するパケットの送信タイミングである時間ｔ３となると、上記同様にして、送信パケットがネットワーク３００を介してエコーサーバ１００に送信されることになるが、その場合に、リクエスト（Ｒ３，Ｒ４）に対する返信パケットを受信（ステップ８１９）していない場合には、つまり、時間ｔ３においても返信パケットが返されていないと判断されると、先のリクエスト（Ｒ３，Ｒ４）に対する送信パケットが、時間ｔ３にてエコーサーバ１００に再送される（ステップ８２０，８２１）。
【００５５】
これにより、先に送信された、または、再送されたリクエスト（Ｒ３，Ｒ４）の送信パケットに対する返信パケットが返されることで、次のリクエスト（Ｒ５以降）に対するパケットの送信処理が確実に行われることになる。
【００５６】
このように、本実施の形態では、サーバシステムとしてのエコーサーバ１００とクライアントシステムとしてのクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のパケット通信における最大通信量が、予め所定の値に定めるようにするため、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃから送信する送信パケットを所定のサイズ（所定量）のものとするようにしたので、ネットワーク３００に対する負荷を軽減することができ、素早いレスポンスを得ることができる。
【００５７】
これにより、サーバシステムとしてのエコーサーバ１００とクライアントシステムとしてのクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間のパケット通信における最大通信量が、予め所定の値に定められるので、不特定多数のプレイヤの参加により、瞬間的にネットワーク負荷が多くなった場合であっても、用意されているバックボーン以上の通信量が発生しないことから、トラフィックの増加に伴うエコーサーバ１００からの応答のタイムラグも抑制することができる。
【００５８】
また、サーバシステムをエコーサーバ１００とし、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃからの送信パケット内の送信Ｎｏが記憶手段としての記憶装置１０３に記憶されている履歴に該当しない場合に限り、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃに送信Ｎｏを含めた返信パケットを返すようにしていることでも、ネットワーク負荷の軽減が図れる。
【００５９】
また、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃにおいては、送受信手段である通信インターフェイス２１１により、エコーサーバ１００へ送信パケットを送信するとともに、エコーサーバ１００からの返信パケットの受信を行うようにし、クライアント側リクエスト管理手段であるクライアント側リクエスト管理部２０３の処理により、ネットワークゲームの進行に伴う各種リクエストを生成して第１の格納手段であるＱＵＥバッファ２０４に格納し、所定時間が経過したとき、ＱＵＥバッファ２０４内のリクエストを所定のサイズ分だけ第２の格納手段であるパケットバッファ２０５に格納し、送信Ｎｏを書込んで圧縮したパケットを発行するようにしたので、ネットワーク負荷が予め定められた最大通信量を越えることが無く、バックボーン以上の通信量の発生を抑制することができる。
【００６０】
しかも、エコーサーバ１００とクライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとの間の送信パケットおよび返信パケットの通信プロトコルは、ＴＣＰ／ＩＰに比べて煩雑な手順を必要としないＵＤＰ／ＩＰとしているため、パケット通信を高速で行うことができる。
【００６１】
この場合、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃにおいては、所定の時間内にエコーサーバ１００からの返信パケットの受け取りが無い場合に、前回送信した送信パケットの再送を行うようにしているので、ＴＣＰ／ＩＰに採用されている手順でなくても、すなわち、パケット送信の度に受信確認の通信を行わなくても、クライアント（通信端末）２００Ａ，２００Ｂ，２００Ｃとエコーサーバ１００との間では、リクエストの送信およびその処理を確実に行うことができる。
【００６２】
【発明の効果】
以上説明したように、本発明によれば、ゲームサーバの負荷の最大値を決めておくことができるので、ネットワークゲームにおけるレスポンスの向上を図ることができる。
【図面の簡単な説明】
【図１】 本発明のネットワークゲームシステムの一実施の形態を示す図である。
【図２】 図１のネットワークゲームシステムのエコーサーバの詳細を示す図である。
【図３】 図１のネットワークゲームシステムのクライアント（通信端末）の詳細を示す図である。
【図４】 図１のネットワークゲームシステムにおける通常動作を説明するためのタイムチャートである。
【図５】 図３のクライアント（通信端末）におけるリクエストの格納動作を説明するためのフローチャートである。
【図６】 図３のクライアント（通信端末）におけるパケットの発行動作を説明するためのフローチャートである。
【図７】 図３のクライアント（通信端末）における返信パケットの処理動作を説明するためのフローチャートである。
【図８】 図１のネットワークゲームシステムにおける再送動作を説明するためのタイムチャートである。
【符号の説明】
１００ エコーサーバ
２００Ａ，２００Ｂ，２００Ｃ，２００ クライアント（通信端末）
３００ ネットワーク
１０１ クライアント管理部
１０２ サーバ側リクエスト管理部
１０３ 記憶装置
２０３ クライアント側リクエスト管理部
２０４ ＱＵＥバッファ
２０５ パケットバッファ
２１１ 通信インターフェイス
Claims (6)
- ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間で通信プロトコルとしてＵＤＰ／ＩＰプロトコルにより通信を行い、ゲームサーバシステムと複数のクライアントシステムとの間でゲーム進行に応じてキャラクタの情報のやり取りが行われるネットワークゲームシステムであって、
前記クライアントシステムに設けられて、
ネットワークゲームの進行に応じた利用者の操作入力による生成されたリクエストを順に格納する第１の格納手段と、
前記クライアントシステムに設けられて、
前記第１の格納手段に格納された未送信リクエストがある場合に当該未送信リクエストを所定量に到達するまで格納する第２の格納手段と、
前記クライアントシステムに設けられて、
第２の格納手段に格納された所定量のリクエストに送信番号を付与してゲームサーバシステムに送信する処理を所定時間ごとに行うとともに前記送信番号を前記第１の格納手段に格納されている対応のリクエストに付与して管理するクライアント側リクエスト管理手段と、
前記ゲームサーバシステムに設けられて、
クライアントシステムから送信されたリクエストの処理が終了した前記送信番号を格納する記憶手段と、
前記ゲームサーバシステムに設けられて、
クライアントシステムから送信されたリクエストに付与された前記送信番号が前記記憶手段に格納されていない場合にリクエストの処理を行い、処理が終了した前記送信番号をクライアントシステムに返送するとともに前記送信番号を前記記憶手段に格納して管理するサーバ側リクエスト管理手段と、
を備え、
クライアント側リクエスト管理手段は、ゲームサーバシステムから返送された前記送信番号に基づいて当該送信番号に対応するリクエストを廃棄する
ことを特徴とするネットワークゲームシステム。 - 請求項１に記載のネットワークゲームシステムにおいて、
前記サーバ側リクエスト管理手段は、前記記憶手段に前記送信番号が格納されている場合には、リクエストの処理を行うことなく、クライアントシステムから送信されたリクエストを破棄する
ことを特徴とするネットワークゲームシステム。 - 請求項１に記載のネットワークゲームシステムにおいて、
前記クライアント側リクエスト管理手段は、所定の時間内に前記ゲームサーバシステムから前記送信番号の返送がない場合、当該送信番号に対応するリクエストを再送する
ことを特徴とするネットワークゲームシステム。 - ネットワークを介して接続されたゲームサーバシステムと複数のクライアントシステムとの間で通信プロトコルとしてＵＤＰ／ＩＰプロトコルにより通信を行い、ゲームサーバシステムと複数のクライアントシステムとの間でゲーム進行に応じてキャラクタの情報のやり取りが行われるネットワークゲームの処理を行うネットワークゲーム処理方法であって、
前記クライアントシステムにおいて処理される、
前記クライアントシステムの第１の格納手段に、
ネットワークゲームの進行に応じた利用者の操作入力による生成されたリクエストを順に格納する工程と、
前記クライアントシステムの第２の格納手段に、
前記第１の格納手段に格納された未送信リクエストがある場合に当該未送信リクエストを所定量に到達するまで格納する工程と、
第２の格納手段に格納された所定量のリクエストに送信番号を付与してゲームサーバシステムに送信する処理を所定時間ごとに行うとともに前記送信番号を前記第１の格納手段に格納されている対応のリクエストに付与して管理するクライアント側リクエスト管理工程と、
前記ゲームサーバシステムにおいて処理される、
前記ゲームサーバシステムの記憶手段に、
クライアントシステムから送信されたリクエストの処理が終了した前記送信番号を格納する工程と、
クライアントシステムから送信されたリクエストに付与された前記送信番号が前記記憶手段に格納されていない場合にリクエストの処理を行い、処理が終了した前記送信番号をクライアントシステムに返送するとともに前記送信番号を前記記憶手段に格納して管理するサーバ側リクエスト管理工程と、
前記クライアントシステムにおいて処理される、
ゲームサーバシステムから返送された前記送信番号に基づいて当該送信番号に対応するリクエストを廃棄する工程と
を行うことを特徴とするネットワークゲーム処理方法。 - 請求項４に記載のネットワークゲーム処理方法において、
前記サーバ側リクエスト管理工程は、前記記憶手段に前記送信番号が格納されている場合には、リクエストの処理を行うことなく、クライアントシステムから送信されたリクエストを破棄する
ことを特徴とするネットワークゲーム処理方法。 - 請求項４に記載のネットワークゲーム処理方法において、
前記クライアント側リクエスト管理工程は、所定の時間内に前記ゲームサーバシステムから前記送信番号の返送がない場合、当該送信番号に対応するリクエストを再送する
ことを特徴とするネットワークゲーム処理方法。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001379493A JP3998466B2 (ja) | 2001-12-13 | 2001-12-13 | ネットワークゲームシステムおよびネットワークゲーム処理方法 |
| EP02027588A EP1319431A3 (en) | 2001-12-13 | 2002-12-10 | Network game system, client system, network game processing method and recording medium |
| US10/315,998 US20030114225A1 (en) | 2001-12-13 | 2002-12-11 | Network game system, server system, client system, network game processing method and recording medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001379493A JP3998466B2 (ja) | 2001-12-13 | 2001-12-13 | ネットワークゲームシステムおよびネットワークゲーム処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003181145A JP2003181145A (ja) | 2003-07-02 |
| JP3998466B2 true JP3998466B2 (ja) | 2007-10-24 |
Family
ID=19186841
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001379493A Expired - Lifetime JP3998466B2 (ja) | 2001-12-13 | 2001-12-13 | ネットワークゲームシステムおよびネットワークゲーム処理方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20030114225A1 (ja) |
| EP (1) | EP1319431A3 (ja) |
| JP (1) | JP3998466B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4086862B2 (ja) * | 2005-06-28 | 2008-05-14 | 株式会社コナミデジタルエンタテインメント | ゲームシステム及びその制御方法、ゲーム装置、並びにプログラム |
| JP4047874B2 (ja) * | 2005-06-28 | 2008-02-13 | 株式会社コナミデジタルエンタテインメント | ゲームシステム及びその制御方法、ゲーム装置、並びにプログラム |
| JP4308283B2 (ja) * | 2007-06-29 | 2009-08-05 | 株式会社スクウェア・エニックス | サーバ装置、携帯電話機、対戦者選定システム及び方法、プログラム及び記録媒体 |
| JP4240509B2 (ja) * | 2007-08-02 | 2009-03-18 | 株式会社コナミデジタルエンタテインメント | ゲームシステム、端末機及びコンピュータプログラム |
| JP2009119150A (ja) * | 2007-11-16 | 2009-06-04 | Square Enix Co Ltd | ネットワークゲームシステム、及びプログラム |
| CN106973074B (zh) * | 2016-01-13 | 2019-11-19 | 腾讯科技（深圳）有限公司 | 一种数据处理方法、装置及*** |
| CN106375314B (zh) * | 2016-08-31 | 2018-10-02 | 腾讯科技（深圳）有限公司 | 一种游戏同步方法、游戏客户端及游戏服务器 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4908828A (en) * | 1987-12-29 | 1990-03-13 | Indesys, Inc. | Method for error free message reception |
| US5598535A (en) * | 1994-08-01 | 1997-01-28 | International Business Machines Corporation | System for selectively and cumulatively grouping packets from different sessions upon the absence of exception condition and sending the packets after preselected time conditions |
| US5751951A (en) * | 1995-10-30 | 1998-05-12 | Mitsubishi Electric Information Technology Center America, Inc. | Network interface |
| US6050898A (en) * | 1996-05-15 | 2000-04-18 | Vr-1, Inc. | Initiating and scaling massive concurrent data transaction |
| US5930252A (en) * | 1996-12-11 | 1999-07-27 | International Business Machines Corporation | Method and apparatus for queuing and triggering data flow streams for ATM networks |
| US5903735A (en) * | 1996-12-24 | 1999-05-11 | Intel Corporation | Method and apparatus for transmitting data having minimal bandwidth requirements |
| US6161123A (en) * | 1997-05-06 | 2000-12-12 | Intermec Ip Corporation | Providing reliable communication over an unreliable transport layer in a hand-held device using a persistent session |
| JPH1157215A (ja) * | 1997-08-20 | 1999-03-02 | Fuji Xerox Co Ltd | ネットワークゲームシステム、ネットワークゲームサーバ装置、ネットワークゲームクライアント装置、対局者選定プログラムを記録した媒体及び対局者情報取得プログラムを記録した媒体 |
| JP3990051B2 (ja) * | 1998-10-02 | 2007-10-10 | 株式会社バンダイナムコゲームス | ゲーム装置及び情報記憶媒体 |
| US6621799B1 (en) * | 1998-10-05 | 2003-09-16 | Enterasys Networks, Inc. | Semi-reliable data transport |
| JP2004514189A (ja) * | 2000-02-17 | 2004-05-13 | アクレイム エンターテインメント インコーポレイテッド | マルチプレーヤーのコンピュータゲーム、システム及び方法 |
| JP2001237882A (ja) * | 2000-02-23 | 2001-08-31 | Nec Corp | パケットデータ転送におけるパケットサイズ制御装置及びその制御方法 |
| US6767287B1 (en) * | 2000-03-16 | 2004-07-27 | Sony Computer Entertainment America Inc. | Computer system and method for implementing a virtual reality environment for a multi-player game |
| JP4168582B2 (ja) * | 2000-08-31 | 2008-10-22 | 沖電気工業株式会社 | 通信接続装置およびデータ出力制御方法 |
| US7013346B1 (en) * | 2000-10-06 | 2006-03-14 | Apple Computer, Inc. | Connectionless protocol |
| US6963921B1 (en) * | 2001-02-16 | 2005-11-08 | 3Com Corporation | Method and apparatus for hardware assisted TCP packet re-assembly |
-
2001
- 2001-12-13 JP JP2001379493A patent/JP3998466B2/ja not_active Expired - Lifetime
-
2002
- 2002-12-10 EP EP02027588A patent/EP1319431A3/en not_active Withdrawn
- 2002-12-11 US US10/315,998 patent/US20030114225A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20030114225A1 (en) | 2003-06-19 |
| EP1319431A3 (en) | 2004-06-30 |
| EP1319431A2 (en) | 2003-06-18 |
| JP2003181145A (ja) | 2003-07-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6050898A (en) | Initiating and scaling massive concurrent data transaction | |
| CN107404514A (zh) | 数据处理方法和装置 | |
| US7527558B2 (en) | Coherent data sharing | |
| US20150367238A1 (en) | Game system, game apparatus, a method of controlling the same, a program, and a storage medium | |
| JP6047670B2 (ja) | ネットワークマルチプレイヤーゲームにおける待ち時間を隠蔽するための方法及び装置 | |
| KR100883907B1 (ko) | 다중 접속 온라인 게임에서의 분산 서버를 통한 게임 제어방법 및 시스템 | |
| US7927217B2 (en) | Network game system, game server system, client system, network game processing method, and recording medium | |
| IL146348A (en) | Server unit, client unit and communication network for multiplier applications | |
| JP3998466B2 (ja) | ネットワークゲームシステムおよびネットワークゲーム処理方法 | |
| CN113993600A (zh) | 延迟消除 | |
| JP2001170360A (ja) | 対戦ゲーム観戦システム | |
| US8651955B2 (en) | Game device, control method, and computer program product | |
| EP1206955A2 (en) | Information terminal, information providing server, online game method and recording medium | |
| JP2018051339A (ja) | ゲームサーバ及びプログラム | |
| CN115943619B (zh) | 信息处理装置、记录介质、数据同步方法、数据同步***以及终端装置 | |
| JP3916601B2 (ja) | 通信システム、サーバ装置、端末、サービス方法、端末方法、および、プログラム | |
| JP5067993B2 (ja) | サーバ、プログラム及び情報記憶媒体 | |
| Wang et al. | Experiences from implementing a mobile multiplayer real-time game for wireless networks with high latency | |
| JP3424821B2 (ja) | ネットワークゲームシステム、ゲームサーバ、ゲーム端末、それらの制御方法及びプログラム | |
| JP6913809B1 (ja) | ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法 | |
| JP2002224438A (ja) | ビデオゲームのアルバム作成プログラム、アルバム作成プログラムを記録した記録媒体及びアルバム作成方法、ゲーム装置並びにビデオゲームキャラクタ画像のトレーディングシステム | |
| CN117046103B (zh) | 游戏战斗处理方法、装置、设备及存储介质 | |
| KR20050068360A (ko) | 네트워크 게임에서의 동기화 방법 및 그 방법이 구현된게임 프로그램을 기록한 컴퓨터가 읽을 수 있는 기록매체 | |
| Bai et al. | Offloading AI for peer-to-peer games with dead reckoning. | |
| Chan et al. | Strifeshadow Fantasy: a massive multi-player online game |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040921 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041119 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20041125 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20050922 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070713 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070807 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3998466 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100817 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110817 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110817 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120817 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120817 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130817 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130817 Year of fee payment: 6 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130817 Year of fee payment: 6 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |