JP2007229329A - ネットワークゲームシステム及びネットワークゲーム方法 - Google Patents

Abstract

【課題】ゲームサーバにかかる負荷を低減し、特定のゲームサーバがダウンしても以後の遊技を継続でき、しかも、広い選択肢の中から対戦遊技の遊技者のマッチングを行うことができるようにする。
【解決手段】複数台のゲームサーバ２は、ＤＢサーバ３に共通にアクセスできる。ロード・バランサ４は、ロールプレイングゲームの操作要求を受け付け、各ゲームサーバ２の負荷を判断して各ゲームサーバ２に分散させる。この操作要求に応じてゲームサーバ２ではロールプレイングゲームを処理する。ロールプレイングゲーム中に遊技者が対戦遊技の実行を要求したときは、当該遊技者とその対戦相手となる他の遊技者とのマッチングを行う。マッチングが成立した後、ロード・バランサ４は、マッチングがされた対戦遊技で対戦している遊技者からの操作要求については同一のゲームサーバ２に振り分ける。各ゲームサーバ２は、対戦遊技の操作要求をオン・メモリで処理する。
【選択図】図１

Description

本発明は、携帯電話などの端末装置からの操作によりネットワークを介して遊技者に遊技を行わせるネットワークゲームシステム及びネットワークゲーム方法に関する。

ＰＣ、携帯電話などから操作して、ネットワーク上のゲームサーバにより様々な遊技を楽しむことができるネットワークゲームシステムが知られている。

一般的な多人数参加型のネットワークゲームシステムは、ゲートサーバ、データベースサーバ、複数台のゲームサーバなどから構成される。

このようなシステムでは、遊技者が、ＰＣ、携帯電話などの端末装置からゲートサーバにアクセスすると、ゲートサーバは、データベースサーバを参照してＩＤ、パスワードなどにより遊技者を認証し、その後遊技が始まる。すなわち、遊技者は、複数のゲームサーバ（遊技者から見るとルーム１、ルーム２、…のように分かれている）から１つを選ぶか、あるいは、ネットワークゲームシステム側が各ゲームサーバで遊技を行っている遊技者の人数を判断し、遊技者に特定のゲームサーバで遊技するように指示することで、特定の１台のゲームサーバで遊技を行う。各ゲームサーバはオン・メモリで遊技を実行し、遊技として対戦遊技を行う場合も対戦相手のマッチングは各ゲームサーバにおいて行われる。

しかしながら、前述のネットワークゲームシステムでは、ゲームサーバが処理すべきプログラムが多様で複雑である場合には、遊技を全てオン・メモリで実行していることもあり、ゲームサーバにかかる負荷が大きくなってしまう不具合がある。

また、遊技者は特定のゲームサーバのみで遊技を行うため、そのゲームサーバがダウンしてしまうと、以後の遊技を継続できないという不具合もある。

さらに、対戦遊技を行う場合の対戦相手のマッチングも各ゲームサーバで行うため、対戦相手の候補となりうるのは遊技者が遊技を行っている特定のゲームサーバで同様に遊技を行っている他の遊技者のみとなり、他のゲームサーバで遊技を行っている遊技者は候補になりえないため、対戦相手の選択範囲が狭いという不具合もある。

そこで、本発明の目的は、ゲームサーバにかかる負荷を低減し、特定のゲームサーバがダウンしても以後の遊技を継続でき、しかも、広い選択肢の中から対戦遊技の遊技者のマッチングを行うことができるようにすることである。

（１）本発明は、各端末装置からの遊技者の操作要求を受け付け、ネットワークを介して遊技を実行するネットワークゲームシステムであって、複数台のゲームサーバと、前記各ゲームサーバが共通にアクセスするデータベースと、前記端末装置からの操作要求を受け付け、前記各ゲームサーバの負荷を判断して前記端末装置からの操作要求を当該各ゲームサーバに分散させるロード・バランサと、前記各ゲームサーバに設けられ、前記データベースにアクセスして前記端末装置からの操作要求に応じて所定遊技を実行する第１遊技実行手段と、前記所定遊技の遊技中に遊技者が前記端末装置により他の遊技者との対戦遊技の実行を要求したときは、当該遊技者とその対戦相手となる他の遊技者とのマッチングを行うマッチング手段と、前記ロード・バランサに設けられ、前記マッチングが成立した後、当該マッチングがされた前記対戦遊技で対戦している遊技者の前記各端末装置からの操作要求については同一の前記ゲームサーバに振り分ける振分手段と、前記各ゲームサーバに設けられ、前記振り分けを受けたときは当該振り分けを受けた操作要求に応じてオン・メモリで前記対戦遊技を実行する第２遊技実行手段と、を備えていることを特徴とするネットワークゲームシステムである。

この場合に、前記端末装置から前記対戦遊技の実行を要求する操作要求があったときは、当該端末装置を識別する第１識別標識と当該対戦遊技の実行を希望している旨を示す第２識別標識とを関連付けて共通のテーブルに登録する登録手段をさらに備えていて、前記マッチング手段は、前記テーブルを参照して前記第２識別標識が付されている前記第１識別標識の遊技者同士をマッチングする、ようにしてもよい。

また、前記各ゲームサーバは、前記マッチングが成立して前記対戦遊技に移行するときは、当該対戦遊技を行う各遊技者の前記端末装置に対して同一の第３識別標識を付与する識別標識付与手段をさらに備え、前記振分手段は、前記第３識別標識を伴う操作要求が前記端末装置からあったときは、同一の前記第３識別標識を伴う操作要求については同一の前記ゲームサーバに振り分ける、ようにしてもよい。

さらに、前記所定の遊技はロールプレイングゲームとしてもよい。

（２）別の面から見た本発明は、各端末装置からの遊技者の操作要求を受け付け、ネットワークを介して遊技を実行するネットワークゲーム方法であって、ロード・バランサで前記端末装置からの操作要求を受け付けて、前記各ゲームサーバの負荷を判断して前記端末装置からの操作要求を当該各ゲームサーバに分散させる第１ステップと、前記ロード・バランサから前記操作要求を受けた前記ゲームサーバにより、前記各ゲームサーバが共通にアクセスするデータベースにアクセスして、前記端末装置からの操作要求に応じて所定遊技を実行する第２ステップと、前記所定遊技の遊技中に遊技者が前記端末装置により他の遊技者との対戦遊技の実行を要求したときは、当該遊技者とその対戦相手となる他の遊技者とのマッチングを行う第３ステップと、前記ロード・バランサにより、前記マッチングが成立した後、当該マッチングがされた前記対戦遊技で対戦している遊技者の前記各端末装置からの操作要求については同一の前記ゲームサーバに振り分ける第４ステップと、前記振り分けを受けた前記ゲームサーバにより、当該振り分けを受けた操作要求に応じてオン・メモリで前記対戦遊技を実行する第５ステップと、を含んでなることを特徴とするネットワークゲーム方法である。

この場合に、前記端末装置から前記対戦遊技の実行を要求する操作要求があったときは、当該端末装置を識別する第１識別標識と当該対戦遊技の実行を希望している旨を示す第２識別標識とを関連付けて共通のテーブルに登録する第６ステップをさらに含んでいて、前記第３ステップは、前記テーブルを参照して前記第２識別標識が付されている前記第１識別標識の遊技者同士をマッチングする、ようにしてもよい。

また、前記マッチングが成立して前記対戦遊技に移行するときは、前記各ゲームサーバで、当該対戦遊技を行う各遊技者の端末装置に対して同一の第３識別標識を付与する第７ステップをさらに含んでいて、前記第４ステップは、前記第３識別標識を伴う操作要求が前記端末装置からあったときは、同一の前記第３識別標識を伴う操作要求については同一の前記ゲームサーバに振り分ける、ようにしてもよい。

さらに、前記所定の遊技はロールプレイングゲームとしてもよい。

本発明によれば、通常の所定の遊技の実行中は、ロード・バランサが各ゲームサーバの負荷を判断して各端末装置からの各操作要求を各ゲームサーバに分散させ、また、各ゲームサーバはデータベースにアクセスして、遊技に必要なデータの読み書きを行いつつ遊技を進行できるので、オン・メモリで遊技をすべて処理する場合に比較して、各ゲームサーバの負荷を低減することができる。この場合に、各ゲームサーバは共通のデータベースを使用するので、同一の遊技者の同一の遊技の中で１回、１回の各操作要求を異なるゲームサーバを介して処理するようにしても、遊技に矛盾が生じることはない。

また、所定の遊技の中で対戦遊技に移行するときは、ロード・バランサは同一の対戦遊技で対戦中の両遊技者からの操作要求は全て同一のゲームサーバに振り分けて、このゲームサーバではオン・メモリで対戦遊技を実行する。よって、複雑で処理データ量が膨大な対戦遊技については、メモリでキャッシングして処理することで、処理が緩慢にならず、遊技者側からみたレスポンスタイムも速い。

すなわち、複雑で膨大なデータ量の処理を必要とする対戦遊技については問題なく処理できるような手当てをしつつも、ロールプレイングゲームなどの所定の遊技の実行中は各ゲームサーバの負担を十分低減できるので、全体として各ゲームサーバで多様なプログラムを処理することができる。

さらに、通常の所定の遊技の実行中は、ロード・バランサが各端末装置からの各操作要求を各ゲームサーバに分散させ、対戦遊技の実行中はロード・バランサが遊技者ごとに各操作要求を特定のゲームサーバに振り分けるので、何れかのゲームサーバがダウンしても当該ゲームサーバを避けるようにすることが可能となり、ゲームサーバに不具合が生じても以後の遊技を継続することができる。

そのうえ、テーブルを用いた場合には、遊技者からの全ての対戦遊技の要求を共通のテーブルで処理すれば、ネットワークゲームシステムで現在対戦遊技の要求をしている全ての遊技者がマッチングの対象となり、広い選択肢の中から対戦遊技の遊技者のマッチングを行うことができる。

以下、本発明を実施するための最良の一形態について説明する。

［システム構成］
図１は、本実施形態のネットワークゲームシステムの全体構成を示すブロック図である。このネットワークゲームシステム１は、複数台のゲームサーバ２（第１ゲームサーバ、第２ゲームサーバ、第３ゲームサーバ、…）と、この各ゲームサーバ２が共通にアクセスできる単一のデータベース（ＤＢ）サーバ３と、ロード・バランサ（Load Balancer）４とを備えている。各ゲームサーバ２、ロード・バランサ４は、インターネット５に接続され、インターネット５、ゲートウェイ６、移動体通信網７（この例では携帯電話網）を介して端末装置８（本例では携帯電話）とパケット通信を行うことができる。なお、端末装置８としては、携帯電話以外にも、ＰＨＳ、移動体通信機能を備えたＰＣやＰＤＡ、などを用いることができる。

各ゲームサーバ２は、それぞれ端末装置８の操作に応じて所定の遊技を端末装置８の所持者である遊技者に行わせる。各ゲームサーバ２ではそれぞれ共通の遊技プログラムが動作しており、何れのゲームサーバ２でも同一の遊技を行うことができる。ロード・バランサ４は、端末装置８からの全ての操作信号を受け付け、後述のとおり、各ゲームサーバ２に分配する。

図２は、ゲームサーバ２、ロード・バランサ４、ＤＢサーバ３をそれぞれ構成している各コンピュータの電気的な接続のブロック図である。これらのコンピュータは、各種演算を行い、各部を集中的に制御するＣＰＵ１１と、各種のＲＯＭ、ＲＡＭからなるメモリ１２とがバス１３を介して接続されている。さらに、バス１３には、磁気記憶装置（ＨＤＤ）１４、インターネット５や他のコンピュータ（ゲームサーバ２、ロード・バランサ４間、ゲームサーバ２、ＤＢサーバ３間）と通信を行う通信制御装置１５，１６が接続されている。図２のコンピュータに、それぞれ専用のプログラムをセットアップすることにより、後述のとおり、それぞれゲームサーバ２、ロード・バランサ４、ＤＢサーバ３として動作する。

図３は、端末装置８の電気的な接続のブロック図である。端末装置８は本例では携帯電話であり、各部を集中的に制御するＣＰＵ２１と、各種のＲＯＭ、ＲＡＭ、あるいは磁気記憶装置（ＨＤＤ）からなる記憶装置２２とが、バス２３により接続されている。さらにバス２３には、各種キーからなる入力装置２４、液晶ディスプレイからなる表示装置２５、スピーカ２７が所定音声発生装置２６を介して接続されている。また、移動体通信網７と通信を行う送受信装置２８も接続されている。

この端末装置８には、アプリケーションプログラム３１が、ゲームサーバ２、あるいはネットワークゲームシステム１を構成する図示しないサーバ装置からダウンロードされ、記憶装置２２にセットアップされる。このアプリケーションプログラム３１は、街アプリ３２、戦闘アプリ３３の２つのプログラムから構成される。そして、移動体通信網７を介して１回にダウンロードできる容量の制限から、街アプリ３２と戦闘アプリ３３はそれぞれ別々にダウンロードされる。また、街アプリ３２がダウンロードされ、セットアップされていれば、戦闘アプリ３３がダウンロードされていなくても、とりあえずネットワークゲームシステム１と通信を行って遊技を行うことができる。戦闘アプリ３３は、遊技が進行してから必要に応じてダウンロードすればよい。

ネットワークゲームシステム１で行われる所定の遊技はロールプレイングゲームであり、このロールプレイングゲームの遊技中に、異なる遊技者同士でそれぞれキャラクタを操作してキャラクタ同士を戦わせる対戦遊技に移行することができ、この対戦遊技の終了後にまたロールプレイングゲームに復帰することができる。

街アプリ３２は、遊技の様々な操作を遊技者に可能とする。前述の遊技のうちロールプレイングゲームについては街アプリ３２で操作することができる。また、対戦遊技のリクエスト（マッチング要求）も街アプリ３２により行う。

街アプリ３２により遊技者が対戦遊技を行いたい旨の対戦要求を出すと、当該遊技者と他の対戦要求を行っている遊技者とのマッチングが行われ、このマッチングが成功すると対戦遊技に移行する。この対戦遊技の操作は戦闘アプリ３３に基づいて行われる。

［遊技処理の概要］
次に、以上のようなシステム構成で、端末装置８とネットワークゲームシステム１との間で実行される遊技の具体的な処理について、図４以下のフローチャートを参照して説明する。これらのフローチャートにおいて、ゲームサーバ２は、複数台あるゲームサーバ２のうち、ロード・バランサ４が端末装置８からの操作要求を送信したゲームサーバ２であり、常に同一のゲームサーバ２を意味するものではない。

図４は、ロールプレイングゲームを行う場合の処理のフローチャートである。遊技者は、最初は街アプリ３２が実行する処理によりロールプレイングゲームを行う。ロールプレイングゲームでは、遊技者が端末装置８を操作すると（ステップＳ１のＹ）、ロード・バランサ４にデータ操作要求が送信される（ステップＳ２）。

ロード・バランサ４がデータ操作要求を受信すると（ステップＳ３のＹ）、ロード・バランサ４では、各ゲームサーバ２のメインメモリとなるＲＡＭの使用率や、ＣＰＵ１１の負荷を判断し、各ゲームサーバ２の負荷を分散できるように、使用するゲームサーバ２を１台選択し（ステップＳ４）、このゲームサーバ２に対してデータ操作要求を送信する（ステップＳ５）。

このデータ操作要求を受信したゲームサーバ２は（ステップＳ６のＹ）、ＤＢサーバ３に当該遊技者のデータ要求を行う（ステップＳ７）。すなわち、ロールプレイングゲームを実行するために必要なデータは遊技者ごとＤＢサーバ３に登録される。このデータは遊技者ごとに遊技者を識別する識別標識、本例でユーザＩＤ（ＵＩＤ）が付されて登録されている。データ操作要求（ステップＳ２）にも同様のＵＩＤが付されているので、データ操作要求（ステップＳ２）があった遊技者のＤＢサーバ３中のデータを識別することができる。なお、このＤＢサーバ３へのデータ要求（ステップＳ７）は、データ操作要求を受信する（ステップＳ６のＹ）度に必ず行われるとは限らず、必要な場合に適宜行われる。

このデータ要求を受け付けたときは（ステップＳ８のＹ）、ＤＢサーバ３は、データ要求（ステップＳ７）を行ったゲームサーバ２に対して対応するデータを送信して応答を行う（ステップＳ９）。

この応答を受けたゲームサーバ２は（ステップＳ１０のＹ）、ＤＢサーバ３から受信した当該遊技者の遊技に関するデータに基づいてデータ操作要求を処理する（ステップＳ１１）。これにより遊技者の操作に応じた遊技の進行が１つ図られる。そして、このデータ操作要求の処理に応じた新たなデータを当該遊技者のデータに付け加えるように、新たなデータの登録をＤＢサーバ３に要求し（ステップＳ１２）、応答を、該当する遊技者の端末装置８に返す（ステップＳ１３）。この応答を受けた端末装置８では（ステップＳ１４のＹ）、この応答の内容を反映させた画像表示を表示装置２５に行い、音声出力をスピーカ２７から行うので（ステップＳ１５）、遊技者は自らの操作（ステップＳ１のＹ）に応じた遊技の進行を画像表示と音声出力により確認することができる。

このような処理を繰り返すことにより、遊技者はロールプレイングゲームの遊技を進行させ、仮想世界の中で各キャラクタが繰り広げる物語を進めていくことができる。そして、遊技者がこのロールプレイングゲームの遊技の進行の中で対戦遊技を要求すると、対戦相手となる他の遊技者とのマッチングが行われ、異なる遊技者同士でネットワークを介して対戦遊技を行うことができる。

図５は、この対戦遊技を要求する場合の処理のフローチャートである。まず、遊技者が端末装置８を操作して街アプリ３２に基づいて対戦遊技の実行を要求する操作要求であるマッチング要求を行うと（ステップＳ２１のＹ）、ロード・バランサ４にマッチング要求が送信される（ステップＳ２２）。このマッチング要求には、対戦遊技のためのマッチングを要求する情報のほか、遊技者のＵＩＤ、遊技者が入力したマッチング相手の条件（対戦相手に要求する対戦遊技の実力レベルなど）などが含まれる。

ロード・バランサ４がデータ操作要求を受信すると（ステップＳ２３のＹ）、ロード・バランサ４は、各ゲームサーバ２のメインメモリとなるＲＡＭの使用率や、ＣＰＵ１１の負荷を判断し、各ゲームサーバ２の負荷を分散できるように使用するゲームサーバ２を１台選択し（ステップＳ２４）、このゲームサーバ２に対してマッチング要求を送信する（ステップＳ２５）。

このマッチング要求を受信したゲームサーバ２は（ステップＳ２６のＹ）、ＤＢサーバ３に当該マッチング要求を送信する（ステップＳ２７）。ＤＢサーバ３では、マッチング要求を受信すると（ステップＳ２８のＹ）、当該マッチング要求を行った遊技者のデータを図６に示す対戦テーブル４１に登録する（ステップＳ２９）。

図６に示すように、この対戦テーブル４１には、マッチング要求を行った各遊技者のデータが登録される。符号４２は、それぞれ個々の遊技者の個人データを示す。この個人データ４２中には、当該遊技者を識別する所定の識別標識（ＵＩＤなど）、遊技者が指定したマッチング相手の条件など、対戦相手のマッチングに必要な情報が関連付けられて登録される。また、現在マッチングを待っている状態にあるのか、あるいは対戦が成立しているのかを示す識別標識として、「マッチング状態」というステート情報も登録される。「マッチング状態」が「０」のときは現在マッチングを待っている状態にあることを示し、「１」のときは対戦が成立していることを示す。よって、ステップＳ２９では、「マッチング状態」として現在マッチングを待っている状態にあることを示す「０」が付されて、個人データ４２が登録される。

そして、ＤＢサーバ３は、「マッチング状態」として「０」が登録されている各個人データ４２の中から、所定のアルゴリズムにしたがって互いに対戦遊技を行う２名の遊技者の個人データ４２を特定することでマッチングを行い（ステップＳ３０）、マッチングに成功したときは（ステップＳ３１のＹ）、この両名の個人データ４２をまとめて単一の対戦データ４３とし、この単一の対戦データ４３の「マッチング状態」を「１」とし、さらに、この対戦データ４３に例えば３２桁のランダム文字列からなる識別標識であるバトルＩＤ（ＢＩＤ）を登録する（ステップＳ３２）。

なお、図５の例は、マッチングに成功するまでマッチング処理を継続する例を示しているが（ステップＳ３０，Ｓ３１）、一定時間経過してもマッチングに成功しないときは、その結果を、ゲームサーバ２を介して端末装置８に送信して、対戦遊技の実行を拒否するようにしてもよいし、あるいは、後述のようにゲームサーバ２が対戦相手となって対戦遊技を行なってもよい。

このようにＢＩＤを登録すると（ステップＳ３２）、ＤＢサーバ３は、マッチング要求を行ったゲームサーバ２に対してデータ応答を行う（ステップＳ３３）。この応答にはステップＳ３２で登録したＢＩＤも含む。

なお、マッチング要求は対戦することになった２名の遊技者からそれぞれ行われるため、マッチング要求を行ったゲームサーバ２が遊技者により異なる場合がある。その場合には、例えば、マッチングが成立した際において、各ゲームサーバ２の中で処理の負荷が軽いものを選択してデータ応答を行なえばよい。また、この場合には、データ応答を受けたゲームサーバ２は、ロード・バランサ４に対して自己（ゲームサーバ２）の識別情報とＢＩＤとを関連付けて送信すれば、図７を参照して後述するとおり、ロード・バランサ４は対戦遊技を行う際に使用するゲームサーバ２を特定することができる。

この応答を受けたゲームサーバ２は（ステップＳ３４のＹ）、マッチング要求を行なってマッチングが成立した２名の遊技者の各端末装置８に対して、戦闘アプリ３３の起動要求をそれぞれ送信する（図５の例では端末装置８が１台のみ図示されているが、この処理の戦闘アプリ３３の起動要求の送信先は２台の端末装置８となる）（ステップＳ３５）。ステップＳ３５で、マッチングが成立した２名の遊技者の各端末装置８の特定は、ステップＳ３３でゲームサーバ２に送信される応答の中に含まれる両遊技者のＵＩＤなどに基づいて行えばよい。この各起動要求にもステップＳ３２で登録したＢＩＤが含まれる。

このようにして戦闘アプリ３３の起動要求を受けた遊技者は、戦闘アプリ３３が端末装置８にすでにセットアップ済みであるときは当該戦闘アプリ３３を起動し、いまだ戦闘アプリ３３がダウンロードされていないときは、戦闘アプリ３３をダウンロードした上で端末装置８にセットアップして、当該戦闘アプリ３３を起動する。この戦闘アプリ３３では、前述の戦闘アプリ３３の起動要求に含まれるＢＩＤを保持する。これにより、戦闘アプリ３３に基づく処理が開始される。以下、かかる戦闘アプリ３３に基づく処理について説明する。

図７は、戦闘アプリ３３に基づく処理を説明するフローチャートである。まず、遊技者が戦闘遊技の操作を端末装置８で行うと（ステップＳ４１のＹ）、端末装置８は操作要求である戦闘要求データをロード・バランサ４に送信する（ステップＳ４２）。この戦闘要求データには、ステップＳ３５で送信された起動要求に含まれていたＢＩＤを含む。

この戦闘要求データをロード・バランサ４が受信すると（ステップＳ４３のＹ）、ロード・バランサ４は戦闘要求データに含まれているＢＩＤに応じて当該戦闘要求データを何れかのゲームサーバ２に振り分ける（ステップＳ４４，Ｓ４５）。すなわち、ゲームサーバ２を選択して（ステップＳ４４）戦闘要求データを送信する（ステップＳ４５）この振り分けは、同一のＢＩＤを含む戦闘要求データについては常に同じゲームサーバ２に送信されるように行う。具体的には、前述のとおり、ロード・バランサ４はゲームサーバ２から送信された当該ゲームサーバ２の識別情報とＢＩＤとにより、データを送信すべきゲームサーバ２を決定することができる。

このようにして同一のＢＩＤについては常に同一のゲームサーバ２が選択され、その戦闘要求データを受けたゲームサーバ２では（ステップＳ４６のＹ）、戦闘要求データが示す遊技者の操作に応じて、戦闘要求データの処理を、ＤＢサーバ３を参照することなくオン・メモリで行い（ステップＳ４７）、その処理結果を同一のＢＩＤの付与を受けている２名の遊技者の携帯端末８に送信する（ステップＳ４８）。この２名の遊技者の携帯端末８の特定は、例えば、ステップＳ３５の戦闘アプリ３３の起動要求中に、マッチングされた２名の遊技者のＵＩＤを含め、これにより、ステップＳ４２の戦闘要求データには、マッチングされた２名の遊技者のＵＩＤが含まれるようにすればよい。あるいは、ステップＳ３５の戦闘アプリ３３の起動要求中に、マッチングされた２名の遊技者のＵＩＤを含め、このＵＩＤとＢＩＤとを関連付けてゲームサーバ２に保持するようにすれば、ステップＳ４２の戦闘要求データにはＢＩＤのみが含まれていればよい。

以上のように、戦闘遊技の操作（ステップＳ４１のＹ）を対戦している２名の遊技者で交互に行い、一操作ごとにステップＳ４１以下の処理を行うことで、対戦遊技は進行する。そして、戦闘の勝負がつくことにより対戦遊技は終了する。対戦遊技が終了すると、ゲームサーバ２の指示でＤＢサーバ３が当該終了した対戦遊技に関する対戦データ４３を対戦テーブル４１から消去する。そして、対戦遊技の終了の宣言が、対戦していた両遊技者の端末装置８に送信され、これらの遊技者の端末装置８では戦闘アプリ３３による処理を終了し、街アプリ３２によるロールプレイングゲームに戻る。また、必要に応じて、対戦遊技の戦闘結果のデータをＤＢサーバ３に保存し、あるいは、街アプリ３２に引き渡す。

以上の処理を行うことにより、ロールプレイングゲームの実行中は、ロード・バランサ４が各ゲームサーバ２の負荷を判断して各端末装置８からの各操作要求を各ゲームサーバ２に分散させ、また、各ゲームサーバ２はＤＢサーバ３にアクセスして、遊技に必要なデータの読み書きを行いつつ遊技を進行できるので、オン・メモリで遊技をすべて処理する場合に比較して、各ゲームサーバ２の負荷を低減することができる。この場合に、同一の遊技者の同一の遊技の中で１回、１回の各操作要求を異なるゲームサーバ２を介して処理する場合が生じうるが、各ゲームサーバ２は共通のＤＢサーバ３により遊技に必要なデータの読み書きを行なって遊技を進行させるので、遊技に矛盾が生じることはない。

また、ロールプレイングゲームの中で対戦遊技に移行するときは、ロード・バランサ４は同一の対戦遊技で対戦中の両遊技者からの操作要求は全て同一のゲームサーバ２に振り分けて、このゲームサーバ２ではオン・メモリで対戦遊技を実行する。よって、複雑で処理データ量が膨大な対戦遊技については、メモリでキャッシングして処理することで、処理が緩慢にならず、遊技者側からみたレスポンスタイムも速い。

すなわち、複雑で膨大なデータ量の処理を必要とする対戦遊技については問題なく処理できるような手当てをしつつも、ロールプレイングゲームの実行中は各ゲームサーバ２の負担を十分低減できるので、全体として各ゲームサーバ２により多様で複雑なプログラムを処理することができる。

特に、本システムでは対戦遊技の実行中に対戦している両遊技者の一方の端末装置８との通信が何らかのトラブルにより途絶しても、その遊技者の以後の遊技を各ゲームサーバ２の人工知能により通信が復旧するまで肩代わりする機能を備えている。これにより、他方の遊技者から見たときは対戦遊技を何の問題もなく継続することができる。

このような機能は複雑なプログラムの処理が必要となるが、本システムでは上記のとおり各ゲームサーバ２の負担を十分低減できるようにしているので、このようなプログラムの処理も問題なく行なうことができる。

さらに、通常のロールプレイングゲームの実行中は、ロード・バランサ４が各端末装置８からの各操作要求を各ゲームサーバ２に分散させ、対戦遊技の実行中はロード・バランサ４が遊技者ごとに各操作要求を特定のゲームサーバ２に振り分けるので、何れかのゲームサーバ２がダウンしても当該ゲームサーバ２を避けることが可能となり、ゲームサーバ２に不具合が生じても以後の遊技を継続することができる。

そのうえ、遊技者からの全ての対戦遊技の要求を単一の対戦テーブル４１で処理することにより、現在対戦遊技の要求をしている全ての遊技者がマッチングの対照となるので、広い選択肢の中から対戦遊技の遊技者のマッチングを行うことができる。例えば、知り合い同士の２名の遊技者が、示し合わせてネットワークゲームシステム１にそれぞれアクセスして遊技を行う場合でも、従来のように各遊技者が別々のゲームサーバ２に振り分けられてしまって、この両名による対戦遊技を行なうことができないという事態を防止することができる。

［対戦遊技の画面表示］
次に、前述の対戦遊技において、遊技者の端末装置８の表示装置２５に表示される画面について説明する。この例では、遊技者ＡとＢが対戦遊技を行っていて、遊技者Ａは遊技中のキャラクタａを操作し、遊技者Ｂは遊技中のキャラクタｂを操作して、キャラクタａとキャラクタｂとを対戦させる例で説明する。

図８は、一般的な対戦遊技の場合の画面表示の例を説明する説明図である。図８（ａ）は１プレーヤ（１Ｐ）となる遊技者Ａの端末装置８の表示装置２５に表示される画面を示し、図８（ｂ）は２プレーヤ（２Ｐ）となる遊技者Ｂの端末装置８の表示装置２５に表示される画面を示している。図８（ａ）の遊技者Ａの画面では、１Ｐとなる遊技者Ａの操作するキャラクタａが画面左側に表示され、２Ｐとなる遊技者Ｂの操作するキャラクタｂが画面右側に表示されている。このようなキャラクタａ，ｂの左右配置は図８（ｂ）の遊技者Ｂの画面でも同様であり、遊技者Ｂの画面でも、１Ｐとなる遊技者Ａの操作するキャラクタａが画面左側に表示され、２Ｐとなる遊技者Ｂの操作するキャラクタｂが画面右側に表示される。

しかしながら、端末装置８が本例のように携帯電話である場合、右利きの人は右手で携帯電話を支え、右手親指で操作しており、例えばキャラクタａ，ｂを移動させるための左ボタン（左に移動させる）は操作しやすいが右ボタン（右に移動させる）は操作しにくいなど、操作しやすいキー操作、操作しにくいキー操作が生じうる。それにもかかわらず、図８の例では遊技者が１Ｐとなるか２Ｐとなるかにより、キャラクタの操作をするキーが異なってしまい、１Ｐとなるか２Ｐという偶然的な条件により操作条件が異なってしまうことになる。前述の例で、左ボタン（キャラクタを左に移動させる）は操作しやすいが右ボタン（キャラクタを右に移動させる）は操作しにくい遊技者は、１Ｐになると、遊技者を前進させるのはスムースだが、交代させるのはスムースにいかないことになる。これが２Ｐになると、遊技者を前進させるのはスムースにいかないが、交代させるのはスムースにいくことになる。このような１Ｐとなるか２Ｐとなるかにより操作性が異なるのは、遊技者にとっては大変遊技しにくいといえる。また、この場合は遊技者ＡとＢとで画像表示が異なるので、対戦アプリ３３も遊技者ＡとＢとで異なるものを用意する必要がある。あるいは、遊技者ＡとＢとで同一内容の対戦アプリ３３が使用できるようにすると、処理量が倍になってしまう。

そこで、本実施形態では、図９に示すような画面表示を行っている。すなわち、図９（ａ）の遊技者Ａの画面では、１Ｐとなる遊技者Ａの操作するキャラクタａが画面左側に表示され、２Ｐとなる遊技者Ｂの操作するキャラクタｂが画面右側に表示されている。この点は図８（ａ）の例と同様である。これに対して、図９（ｂ）遊技者Ｂの画面では、２Ｐとなる遊技者Ｂの操作するキャラクタｂが画面左側に表示され、１Ｐとなる遊技者Ａの操作するキャラクタａが画面右側に表示されている。すなわち、本実施形態では、遊技者が１Ｐか２Ｐかに関わらず、常に自分が操作するキャラクタが画面の左側に表示され、対戦相手の操作するキャラクタが右側に表示される（もちろん、この逆にしてもよい）。

このように、遊技者が１Ｐか２Ｐかに関わらず、常に自分が操作するキャラクタが画面の同じ側に表示されるので、操作性が常に同一となり、遊技者にとっては大変遊技しやすくなる。また、対戦するどちらの遊技者も自らの端末装置８に表示される自己のキャラクタ、対戦相手のキャラクタが同じになるようにしているので、このような画像表示を行っている対戦アプリ３３は、全ての遊技者にとって同一の処理内容のソフトウェアを用いることができ、それにもかかわらず処理量が多大なものとなることがない。

なお、前述の例では遊技者が１Ｐか２Ｐかに関わらず、常に自分が操作するキャラクタが画面の同じ側に表示されるようにしたが、遊技者によりキャラクタが左側か右側かにより操作のしやすさが異なる場合もあり、また、右利き左利きという違いもあるため、遊技者が端末装置８を操作して、自分のキャラクタが右側か左側か（相手のキャラクタが左側か右側か）所望により選択できるようにしてもよい。

［対戦相手の情報取得機能］
本実施形態では、対戦アプリ３３の機能により、当該対戦アプリ３３がセットアップされている端末装置８の所定の情報を自動的に取得し、所定のタイミングでゲームサーバ２などのサーバに送信し、サーバから当該対戦相手の端末装置８に送信して、その表示装置２５に表示させることができる（この表示も対戦アプリ３３の機能による）。

このようにして、対戦アプリ３３が端末装置８から取得しうる情報の例としては、携帯電話である端末装置８の、バッテリー残量、サウンドのボリューム量、表示装置２５のバックライトのＯＮ，ＯＦＦ、バイブレーションのＯＮ，ＯＦＦ、音声発着信時設定、携帯電話ＩＤなどのＩＤ情報、端末装置８の折りたたみ状態、メールの有無や未読メールの有無などのメール状態、メールの内容、アンテナが圏外か圏内かのアンテナ状態、マナーモード設定の有無のマナーモード状態、指定電話番号へ音声通話、電話帳グループの新規登録、電話帳エントリの新規登録、ｗｅｂブラウザのブックマークの登録、（スケジュール登録機能がある場合の）スケジュールの登録、（カメラを備えている場合の）カメラ画像サイズ設定や撮影属性設定、ｗｅｂブラウザや別アプリケーションの起動の有無、カメラ撮影画像、着信音の内容、など様々である。

これらの機能を用い、例えば、端末装置８のバッテリー残量が残り少ないという情報を取得して対戦相手の画面に表示して報知すれば、一方の遊技者が対戦遊技を途中でやめるのは負けそうになって逃げるためではなく、端末装置８のバッテリー残量が残り少なくなっているためであると対戦相手に悟らせることができる。

また、端末装置８を現在折りたたみ中であることを対戦相手の画面に表示して報知すれば、遊技が中断されているのは相手に何らかの事情が生じて端末装置８を使用していないからであると知らせることもできる。

このように、本実施形態では、対戦アプリ３３の機能により、端末装置８の所定の情報を自動的に取得し、対戦相手の端末装置８に表示させることができるので、遊技者が対戦相手の状況を知ることができる。

［アプリケーションのダウンロード］
本実施形態のアプリケーション３１は、遊技者が所定の方法で決済することで当該アプリケーション３１を購入し、このアプリケーション３１をゲームサーバ２、あるいは図示しない他のサーバからダウンロードし、端末装置８にセットアップすることで使用する。

アプリケーション３１のダウンロードを行うサーバでは、その日、その日のアプリケーション３１の販売本数が決められていて、また、このアプリケーション３１の販売後の残量を示すカウンタ機能を備えており、アプリケーション３１を１本販売するたびに、このカウンタの数値を「１」だけデクリメントする。そして、このカウンタの数値が「０」になったときは、その後のアプリケーション３１の販売、ダウンロードを拒否する。

図１０（ａ）は、このダウンロードの際にアプリケーション３１を購入した遊技者の端末装置８に表示されるダウンロード画面である。ボタン５１を操作することにより、アプリケーション３１のダウンロードが開始し、また、符号５２の領域には現在残っているアプリケーション３１の在庫数が表示される。在庫数５２は１本のアプリケーション３１が販売されるたびに、「１」だけデクリメントされて表示され、この数値が「０」になると、図１０（ｂ）のような画面が表示され、以後のアプリケーション３１の販売、ダウンロードの要求は拒否される。

このように、本実施形態では１日に販売するアプリケーション３１の本数を制限しているので、過剰な本数のアプリケーション３１を販売し、遊技者のアクセスがネットワークゲームシステム１に過度に集中し、過大な負荷によりシステムがダウンしてしまう事態を防止している。

本発明の一実施形態であるネットワークゲームシステムのシステム構成を示すブロック図である。 ネットワークゲームシステムを構成する各コンピュータの電気的な接続のブロック図である。 端末装置の電気的な接続のブロック図である。 ロールプレイングゲームを行う場合の処理のフローチャートである。 対戦遊技を要求する場合の処理のフローチャートである。 対戦テーブルの説明図である。 対戦遊技の処理のフローチャートである。 従来の対戦遊技における画面表示における各キャラクタの配置を示す説明図である。 本実施形態の対戦遊技における画面表示における各キャラクタの配置を示す説明図である。 アプリケーションのダウンロードの際に遊技者の端末装置に表示されるダウンロード画面（ａ）と、アプリケーションの在庫がなくなった場合に遊技者の端末装置に表示されるダウンロード画面（ｂ）の説明図である。

符号の説明

１ ネットワークゲームシステム
２ ゲームサーバ
３ データベースサーバ
４ ロード・バランサ
８ 端末装置
３１ アプリケーション
３２ 街アプリ
３３ 戦闘アプリ
４１ 対戦テーブル

Claims (8)

1. 各端末装置からの遊技者の操作要求を受け付け、ネットワークを介して遊技を実行するネットワークゲームシステムであって、
   複数台のゲームサーバと、
   前記各ゲームサーバが共通にアクセスするデータベースと、
   前記端末装置からの操作要求を受け付け、前記各ゲームサーバの負荷を判断して前記端末装置からの操作要求を当該各ゲームサーバに分散させるロード・バランサと、
   前記各ゲームサーバに設けられ、前記データベースにアクセスして前記端末装置からの操作要求に応じて所定遊技を実行する第１遊技実行手段と、
   前記所定遊技の遊技中に遊技者が前記端末装置により他の遊技者との対戦遊技の実行を要求したときは、当該遊技者とその対戦相手となる他の遊技者とのマッチングを行うマッチング手段と、
   前記ロード・バランサに設けられ、前記マッチングが成立した後、当該マッチングがされた前記対戦遊技で対戦している遊技者の前記各端末装置からの操作要求については同一の前記ゲームサーバに振り分ける振分手段と、
   前記各ゲームサーバに設けられ、前記振り分けを受けたときは当該振り分けを受けた操作要求に応じてオン・メモリで前記対戦遊技を実行する第２遊技実行手段と、
   を備えていることを特徴とするネットワークゲームシステム。
2. 前記端末装置から前記対戦遊技の実行を要求する操作要求があったときは、当該端末装置を識別する第１識別標識と当該対戦遊技の実行を希望している旨を示す第２識別標識とを関連付けて共通のテーブルに登録する登録手段をさらに備えていて、
   前記マッチング手段は、前記テーブルを参照して前記第２識別標識が付されている前記第１識別標識の遊技者同士をマッチングする、
   ことを特徴とする請求項１に記載のネットワークゲームシステム。
3. 前記各ゲームサーバは、前記マッチングが成立して前記対戦遊技に移行するときは、当該対戦遊技を行う各遊技者の前記端末装置に対して同一の第３識別標識を付与する識別標識付与手段をさらに備え、
   前記振分手段は、前記第３識別標識を伴う操作要求が前記端末装置からあったときは、同一の前記第３識別標識を伴う操作要求については同一の前記ゲームサーバに振り分ける、
   ことを特徴とする請求項１又は２に記載のネットワークゲームシステム。
4. 前記所定の遊技はロールプレイングゲームである、ことを特徴とする請求項１〜３の何れかの一項に記載のネットワークゲームシステム。
5. 各端末装置からの遊技者の操作要求を受け付け、ネットワークを介して遊技を実行するネットワークゲーム方法であって、
   ロード・バランサで前記端末装置からの操作要求を受け付けて、前記各ゲームサーバの負荷を判断して前記端末装置からの操作要求を当該各ゲームサーバに分散させる第１ステップと、
   前記ロード・バランサから前記操作要求を受けた前記ゲームサーバにより、前記各ゲームサーバが共通にアクセスするデータベースにアクセスして、前記端末装置からの操作要求に応じて所定遊技を実行する第２ステップと、
   前記所定遊技の遊技中に遊技者が前記端末装置により他の遊技者との対戦遊技の実行を要求したときは、当該遊技者とその対戦相手となる他の遊技者とのマッチングを行う第３ステップと、
   前記ロード・バランサにより、前記マッチングが成立した後、当該マッチングがされた前記対戦遊技で対戦している遊技者の前記各端末装置からの操作要求については同一の前記ゲームサーバに振り分ける第４ステップと、
   前記振り分けを受けた前記ゲームサーバにより、当該振り分けを受けた操作要求に応じてオン・メモリで前記対戦遊技を実行する第５ステップと、
   を含んでなることを特徴とするネットワークゲーム方法。
6. 前記端末装置から前記対戦遊技の実行を要求する操作要求があったときは、当該端末装置を識別する第１識別標識と当該対戦遊技の実行を希望している旨を示す第２識別標識とを関連付けて共通のテーブルに登録する第６ステップをさらに含んでいて、
   前記第３ステップは、前記テーブルを参照して前記第２識別標識が付されている前記第１識別標識の遊技者同士をマッチングする、
   ことを特徴とする請求項５に記載のネットワークゲーム方法。
7. 前記マッチングが成立して前記対戦遊技に移行するときは、前記各ゲームサーバで、当該対戦遊技を行う各遊技者の端末装置に対して同一の第３識別標識を付与する第７ステップをさらに含んでいて、
   前記第４ステップは、前記第３識別標識を伴う操作要求が前記端末装置からあったときは、同一の前記第３識別標識を伴う操作要求については同一の前記ゲームサーバに振り分ける、
   ことを特徴とする請求項５又は６に記載のネットワークゲーム方法。
8. 前記所定の遊技はロールプレイングゲームである、ことを特徴とする請求項５〜７の何れかの一項に記載のネットワークゲーム方法。

Images