特開2018-195322(P2018-195322A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社コナミデジタルエンタテインメントの特許一覧
特開2018-195322ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置
<>
  • 特開2018195322-ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置 図000003
  • 特開2018195322-ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置 図000004
  • 特開2018195322-ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置 図000005
  • 特開2018195322-ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置 図000006
  • 特開2018195322-ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置 図000007
  • 特開2018195322-ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置 図000008
  • 特開2018195322-ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置 図000009
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2018-195322(P2018-195322A)
(43)【公開日】2018年12月6日
(54)【発明の名称】ゲームシステム、それに用いられるコンピュータプログラム、及びサーバ装置
(51)【国際特許分類】
   G06Q 30/04 20120101AFI20181109BHJP
   A63F 13/792 20140101ALI20181109BHJP
【FI】
   G06Q30/04
   A63F13/792
【審査請求】未請求
【請求項の数】1
【出願形態】OL
【全頁数】17
(21)【出願番号】特願2018-127324(P2018-127324)
(22)【出願日】2018年7月4日
(62)【分割の表示】特願2016-38013(P2016-38013)の分割
【原出願日】2016年2月29日
(71)【出願人】
【識別番号】506113602
【氏名又は名称】株式会社コナミデジタルエンタテインメント
(72)【発明者】
【氏名】岡 隆史
(72)【発明者】
【氏名】成田 順彦
(72)【発明者】
【氏名】小林 祐介
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049BB11
(57)【要約】
【課題】複数のユーザが共通のゲームをプレイする場合に各ユーザによって支払われる所定の対価の合計額を、ユーザの数に応じて各ユーザに割り当てられるべき均等額が変化するように変化させることができるゲームシステムを提供する。
【解決手段】ゲームシステム1は、所定の対価の徴収と引き換えに複数のユーザUを含むグループUGに共通の音楽ゲームをプレイさせるゲームシステムである。また、ゲームシステム1は、音楽ゲームをプレイするグループUGのユーザUの人数を判別し、その判別結果に基づいて、音楽ゲームのプレイに伴う所定の対価としてグループUGの全体から徴収されるべきグループ料金の額を、グループUGの各ユーザUに均等に割り当てた場合の均等額がユーザUの人数に応じて変化するように設定する。
【選択図】図3
【特許請求の範囲】
【請求項1】
所定の対価の徴収と引き換えに複数のユーザに共通のゲームをプレイさせるゲームシステムであって、
前記ゲームをプレイする前記複数のユーザの人数を判別する人数判別手段と、
前記人数判別手段の判別結果に基づいて、前記ゲームのプレイに伴い前記所定の対価として前記複数のユーザの全体から徴収されるべき全体の対価の額を前記複数のユーザの各ユーザに均等に割り当てた場合の均等額が前記複数のユーザの人数に応じて変化するように、各ユーザから個別に徴収されるべき個別の対価及び前記全体の対価の少なくともいずれか一方の額を設定する対価設定手段と、
を備える、ゲームシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、所定の対価の徴収と引き換えに複数のユーザに共通のゲームをプレイさせるゲームシステム等に関する。
【背景技術】
【0002】
所定の対価の徴収と引き換えに複数のユーザに共通のゲームをプレイさせるゲームシステムが存在する。例えば、このようなゲームシステムとして、所定の対価としての2枚のコインの徴収と引き換えに、一台のゲーム機を共用する二人のユーザに共通のゲーム(いわゆる二人プレイ)をプレイさせるゲームシステムが知られている(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特許第5318508号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1のゲームシステムでは、各ユーザに要求される対価は、二人プレイの場合でも一人プレイの場合と同様である。つまり、ゲームを共通にプレイするユーザの数が増えても、各ユーザが負担すべき額は変化しない。このため、対価の面ではユーザの数の増加に対する動機付けがあるとは言えない。
【0005】
そこで、本発明は、複数のユーザが共通のゲームをプレイする場合に各ユーザによって支払われる所定の対価の合計額を、ユーザの数に応じて各ユーザに割り当てられるべき均等額が変化するように変化させることができるゲームシステム等を提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明のゲームシステムは、所定の対価の徴収と引き換えに複数のユーザに共通のゲームをプレイさせるゲームシステムであって、前記ゲームをプレイする前記複数のユーザの人数を判別する人数判別手段と、前記人数判別手段の判別結果に基づいて、前記ゲームのプレイに伴い前記所定の対価として前記複数のユーザの全体から徴収されるべき全体の対価の額を前記複数のユーザの各ユーザに均等に割り当てた場合の均等額が前記複数のユーザの人数に応じて変化するように、各ユーザから個別に徴収されるべき個別の対価及び前記全体の対価の少なくともいずれか一方の額を設定する対価設定手段と、を備えている。
【0007】
一方、本発明のコンピュータプログラムは、前記ゲームの提供に使用される出力装置に接続されるコンピュータを、上述のゲームシステムの各手段として機能させるように構成されたものである。
【0008】
また、本発明のサーバ装置は、前記ゲームの提供に使用される出力装置にネットワークを介して接続され、上述のゲームシステムの各手段として機能するものである。
【図面の簡単な説明】
【0009】
図1】本発明の一形態に係るゲームシステムの全体構成の概要を示す図。
図2】ゲームシステムの制御系の要部の構成を示す図。
図3】音楽ゲームのプレイ料金(所定の対価)の一例を説明するための説明図。
図4】人数に応じた均等額の変化の一例を説明するための説明図。
図5】グループ料金の支払い方法の一例を説明するための説明図。
図6】集団料金データの内容の一例を説明するための説明図。
図7】料金通知処理ルーチンのフローチャートの一例を示す図。
【発明を実施するための形態】
【0010】
以下、本発明の一形態に係るゲームシステムについて説明する。図1は、本発明の一形態に係るゲームシステムの全体構成の概要を示す図である。図1に示すように、ゲームシステム1は、サーバ装置としてのセンターサーバ2及びゲーム機GMを含んでいる。ゲーム機GMは、ネットワーク3を介してセンターサーバ2に接続される。一例として、ゲーム機GMは、業務用(商業用)のゲーム機として構成されている。業務用のゲーム機は、有料或いは無料で所定範囲のゲームをプレイさせるゲーム機である。一例として、ゲーム機GMは、有料で音楽ゲームを提供する。具体的には、ゲーム機GMは、例えば、所定の対価の消費と引き換えに、その対価に応じた範囲で音楽ゲームを提供する。ゲーム機GMは、店舗4等の商業施設に適当な台数ずつ設置される。
【0011】
センターサーバ2は、一台の物理的装置によって構成される例に限らない。例えば、複数の物理的装置としてのサーバ群によって一台の論理的なセンターサーバ2が構成されてもよい。また、クラウドコンピューティングを利用して論理的にセンターサーバ2が構成されてもよい。さらに、ゲーム機GMがセンターサーバ2として機能してもよい。
【0012】
また、センターサーバ2には、ネットワーク3を介して、ユーザ端末5が接続される。ユーザ端末5は、センターサーバ2から配信されるソフトウェアを実行することにより、各種の機能を発揮するネットワーク端末装置の一種である。図1の例では、ユーザ端末5の一例として、携帯電話(スマートフォンを含む)が利用されている。また、ユーザ端末5として、例えば、その他にもパーソナルコンピュータ、携帯型ゲーム機、携帯型タブレット端末装置といった、ネットワーク接続が可能でかつユーザの個人用途に供される各種のネットワーク端末装置が利用されてよい。
【0013】
ネットワーク3は、一例として、TCP/IPプロトコルを利用してネットワーク通信を実現するように構成されてよい。典型的には、WANとしてのインターネットと、LANとしてのイントラネットと、を組み合わせてネットワーク3が構成されてよい。図1の例では、センターサーバ2及びゲーム機GMはルータ3aを介して、ユーザ端末5はアクセスポイント3bを介して、それぞれネットワーク3に接続されている。
【0014】
なお、ネットワーク3は、TCP/IPプロトコルを利用する形態に限定されない。ネットワーク3として、通信用の有線回線、或いは無線回線(赤外線通信、近距離無線通信等を含む)等を利用する各種の形態が利用されてよい。或いは、ユーザ端末5とゲーム機GM等との通信は、例えば、通信用の回線(有線及び無線を含む)を利用せずに、二次元コード等、各種情報を含むように所定の規格に準拠して生成されるコード(例えば、二次元コード)を利用して実現されてよい。したがって、ネットワーク(或いは通信回線)の用語は、このようなコードを利用する通信方法等、回線を利用せずに情報の送受信をする形態を含んでよい。
【0015】
センターサーバ2は、ゲーム機GM又はそのユーザに対して各種のゲーム機用サービスを提供する。ゲーム機用サービスとして、例えば、ゲーム機GMからユーザの識別情報を受け取って、そのユーザを認証するサービスが提供されてよい。また、認証したユーザのプレイデータをゲーム機GMから受け取って保存し、或いは保存するプレイデータをゲーム機GMに提供するサービスが提供されてもよい。さらに、ゲーム機用サービスには、ネットワーク3を介してゲーム機GMのプログラム或いはデータを配信し、更新するサービス、ネットワーク3を介して複数のユーザが共通のゲームをプレイする際にユーザ同士をマッチングするマッチングサービス等が含まれていてもよい。
【0016】
また、センターサーバ2は、ネットワーク3を介してユーザ端末5のユーザに各種のWebサービスを提供する。Webサービスには、例えば、ゲーム機GMが提供するゲームに関する各種の情報を提供するゲーム用情報サービスが含まれてよい。また、例えば、Webサービスには、各ユーザ端末5に各種データ或いはソフトウェアを配信(データ等のアップデートを含む)する配信サービスが含まれてもよい。さらに、Webサービスには、その他にもユーザによる情報発信、交換、共有といった交流の場を提供するコミュニティサービス、各ユーザを識別するためのユーザIDを付与するサービス等のサービスが含まれてよい。
【0017】
次に、音楽ゲームを提供するためのゲームシステム1の制御系の要部について説明する。図2は、ゲームシステム1の制御系の要部の構成を示す図である。図2に示すように、センターサーバ2は、制御ユニット10と、記憶ユニット11と、を備えている。制御ユニット10は、マイクロプロセッサと、そのマイクロプロセッサの動作に必要な内部記憶装置(一例としてROM及びRAM)等の各種周辺装置とを組み合わせたコンピュータユニットとして構成されている。なお、制御ユニット10には、キーボード等の入力装置、モニタ等の出力装置等が接続され得る。しかし、それらの図示は省略した。
【0018】
記憶ユニット11は、コンピュータとしての制御ユニット10に接続されている。記憶ユニット11は、電源の供給がなくても記憶を保持可能なように、例えば、磁気テープ等の大容量記憶媒体により構成されていてよい。記憶ユニット11には、サーバ用データ14及びサーバ用プログラム15が記憶されている。サーバ用プログラム15は、センターサーバ2がゲーム機GM等に各種のサービスを提供するために必要なコンピュータプログラムである。制御ユニット10がサーバ用プログラム15を読み取って実行することにより、制御ユニット10の内部には、例えば、ゲーム機サービス管理部16及びWebサービス管理部17が設けられてよい。
【0019】
ゲーム機サービス管理部16は、上述のゲーム機用サービスを提供するための処理を実行する。一方、Webサービス管理部17は、上述のWebサービスを提供するために必要な処理を実行する。ゲーム機サービス管理部16及びWebサービス管理部17は、コンピュータハードウェアとコンピュータプログラムとの組み合わせにより実現される論理的装置である。なお、制御ユニット10の内部には、その他にも各種の論理的装置が設けられ得る。しかし、それらの図示は省略した。
【0020】
サーバ用データ14は、サーバ用プログラム15の実行に伴って参照されるデータである。例えば、サーバ用データ14は、集団料金データ14aを含んでいてよい。集団料金データ14aの詳細は、後述する。
【0021】
また、サーバ用データ14は、その他にもゲームを実現するための各種のデータを含み得る。例えば、そのようなデータにはプレイデータやID管理データが含まれていてもよい。プレイデータは、各ユーザの過去のプレイ実績に関する情報が記述されたデータである。プレイデータは、例えば、前回までのプレイ結果(過去の実績)を次回以降に引き継ぐため、或いは各ユーザに固有の設定内容を引き継ぐために使用されてよい。また、ID管理データは、ユーザID等の各種IDを管理するためのデータである。しかし、それらの図示は省略した。
【0022】
一方、ゲーム機GMには、コンピュータとしての制御ユニット30と、記憶ユニット31と、出力装置としてのモニタMOと、入力装置7と、スピーカ8と、リーダ9と、が設けられている。記憶ユニット31、モニタMO、入力装置7、スピーカ8及びリーダ9は、いずれも制御ユニット30に接続されている。制御ユニット30は、マイクロプロセッサと、そのマイクロプロセッサの動作に必要な内部記憶装置(一例としてROM及びRAM)等の各種周辺装置とを組み合わせたコンピュータユニットとして構成されている。なお、制御ユニット30には、例えば、その他にもゲームを提供するための各種の装置が接続され得る。例えば、そのような装置には、コイン認証装置等の所定の対価を徴収するための周知の装置が含まれてもよい。そして、例えば、そのようなコイン認証装置等を通じて、所定の対価としてのコイン等が徴収されてよい。しかし、それらの図示は省略した。
【0023】
モニタMOは、制御ユニット30からの出力信号に基づいて各種の画像等を表示するための周知の表示装置である。一例として、モニタMOは、制御ユニット30からの出力信号に応じて、音楽ゲームをプレイするためのゲーム画面を表示する。入力装置7は、ユーザのプレイ行為を入力するための周知の装置である。入力装置7は、ユーザが実行したプレイ行為に対応する信号を制御ユニット30に出力する。例えば、入力装置7として、ユーザが指等で触れると、その接触位置に応じた信号を出力するタッチパネルが使用されてよい。そして、タッチパネルは、ユーザのタッチ操作に基づいてそのタッチ位置に対応する信号を制御ユニット30に出力してよい。同様に、スピーカ8は、制御ユニット30からの出力信号に基づいて各種の音声を再生するための周知の出力装置(音声再生装置)である。スピーカ8は、例えば、制御ユニット30からの出力信号に応じて、BGM等のゲームで使用される各種の音声を再生する。
【0024】
リーダ9は、例えば、近距離無線通信を利用し、記憶媒体に記録された各種の情報を非接触状態で読み取る周知の装置である。リーダ9は、記憶媒体の一例としてカードCDの情報の読み取りに使用されてよい。具体的には、リーダ9は、一例として、各ユーザが所持するカードCDの情報を読み取ってその情報に対応した信号を制御ユニット30に出力してよい。
【0025】
また、カードCDには、例えば、ICチップ、磁気ストライプといった不揮発性記憶媒体(不図示)が設けられていてよい。そして、カードCDには、このような不揮発性記憶媒体等を介して、各種の情報が記録されてよい。また、例えば、各種の情報には、ユーザIDの情報(ユーザIDを特定可能な情報を含む)が含まれてよい。つまり、カードCDは、例えば、IDカードとして、IDカードに対応する各ユーザの特定に使用されてよい。さらに、各種の情報には、例えば、その他にも所定の対価として使用される価値の量の情報(価値の量を特定するための情報を含む)が含まれてもよい。そして、その価値の量を消費することにより所定の対価が徴収されてもよい。つまり、カードCDは、一例として、所定の対価の支払いに使用されてもよい。
【0026】
なお、カードCDは、各種の情報を電子的に記録する形態に限定されない。例えば、カードCDは、二次元コード等の各種のコードを介して各種の情報を記録してもよい。この場合、リーダ9は、そのようなコードを読み取り可能なコードリーダを含む等によりそのようなコードを読み取り可能に構成されていてよい。つまり、リーダ9は、そのようなコードの読み取りに使用されてもよい。
【0027】
一方、記憶ユニット31は、電源の供給がなくても記憶を保持可能なように、例えば、磁気記録媒体や光記録媒体、フラッシュSSD(Solid State Drive)などにより構成されてよい。記憶ユニット31には、ゲームプログラム34及びゲームデータ35が記憶されている。ゲームプログラム34は、ゲーム機GMがゲームを提供するために必要なコンピュータプログラムである。ゲームプログラム34の実行に伴って、制御ユニット30の内部には、例えば、ゲーム提供部37が設けられてよい。ゲーム提供部37は、ゲームを提供するために必要な各種処理を実行する。ゲーム提供部37は、コンピュータハードウェアとコンピュータプログラムとの組み合わせにより実現される論理的装置である。なお、制御ユニット30の内部には、その他にも各種の論理的装置が設けられ得る。しかし、それらの図示は省略した。
【0028】
ゲームデータ35は、ゲームプログラム34の実行に伴って参照されるデータである。ゲームデータ35は、例えば、楽曲データ36及びシーケンスデータ38を含んでいる。楽曲データ36は、音楽ゲームで使用される楽曲等の各種の音声をスピーカ8に再生させるために必要なデータである。シーケンスデータ38は、音楽ゲームにおいて適切なプレイ行為を実行すべき時期をユーザに案内するために必要なデータである。例えば、シーケンスデータ38には、適切な位置をタッチ操作すべき操作時期が予め記述されていてよい。そして、例えば、音楽ゲームでは、シーケンスデータ38に記述された各操作時期に基づいて適切なタッチ操作をすべき位置及び時期が案内されてよい。楽曲データ36及びシーケンスデータ38は周知の音楽ゲームと同様に構成されてよいため、詳細の説明は省略する。
【0029】
また、ゲームデータ35は、その他にもゲームを実行するための各種のデータを含んでいてよい。例えば、そのようなデータには、上述の集団料金データ14aが含まれていてよい。例えば、集団料金データ14aは、必要な部分が含まれるように、少なくとも一部がセンターサーバ2から提供されてよい。同様に、そのような各種のデータには、例えば、その他にも画像データ及び効果音データが含まれてよい。画像データは、ゲームに必要な各種画像を表示するためのデータである。効果音データは、BGM等、ゲームに必要な各種の音声を再生するためのデータである。しかし、それらの図示は省略した。
【0030】
次に、ゲーム機GMが提供する音楽ゲームについて説明する。音楽ゲームは、タイミングゲームの一種である。タイミングゲームは、適切なプレイ行為の実行時期を評価するタイプのゲームである。音楽ゲームの場合、その適切なプレイ行為を実行すべき実行時期が楽曲とともに提供される。また、音楽ゲームでは、楽曲のリズムと一致する時期が実行時期として利用される。つまり、音楽ゲームは、適切なプレイ行為を実行すべき時期を楽曲のリズムに合わせてユーザに案内し、実際にプレイ行為が実行された時期を評価するタイプのゲームである。また、例えば、音楽ゲームにはプレイ用に複数の楽曲が用意され、そこから選択された楽曲が実際のプレイに使用されてよい。
【0031】
例えば、そのような音楽ゲームは、モニタMOに表示されるゲーム画面を通じて提供されてよい。具体的には、例えば、ゲーム画面は、各実行時期に対応する指示標識及び現在時刻の基準として機能する基準標識を含んでいてよい。そして、例えば、各実行時期において基準標識の位置と一致するように移動する指示標識の移動により各実行時期が案内されてもよい。また、適切なプレイ行為として、指示標識と基準標識との一致に合わせてその一致位置をタッチするタッチ操作が採用されてよい。ゲーム機GMは、例えば、このようなゲーム画面を通じて音楽ゲームを提供してよい。
【0032】
また、音楽ゲームは、ユーザ単位(一人のユーザ毎)だけでなくグループ単位(複数のユーザ毎)で提供されてよい。グループ単位で音楽ゲームが提供される場合、音楽ゲームはそのグループを形成する複数のユーザに共通にプレイされてよい。つまり、ゲーム機GMは、一度のプレイ機会に複数のユーザが参加するように共通の音楽ゲームを提供してよい。そして、ゲーム機GMは、例えば、単数若しくは複数のグループに含まれるユーザが協力して共通の音楽ゲームをプレイする形態、及び同じグループ内のユーザ間或いは複数のグループ間で対戦が実現されるように共通の音楽ゲームをプレイする形態等、各種の形態でグループ単位の音楽ゲームを提供してよい。
【0033】
図3図5を参照して、音楽ゲームがグループ単位でプレイされる場合の所定の対価について説明する。図3は、音楽ゲームのプレイ料金(所定の対価)の一例を説明するための説明図である。図3に示すように、音楽ゲームのゲーム範囲は、個別プレイ(ユーザ単位のプレイ)及びグループプレイ(グループ単位のプレイ)を含んでいてよい。そして、これらのプレイ料金として、個別プレイには個別料金が、グループプレイにはグループ料金が、それぞれ設定されてよい。
【0034】
具体的には、個別料金は、各ユーザUが個別に音楽ゲームをプレイするために必要な所定の対価である。つまり、個別料金の支払いに伴い、音楽ゲームの個別プレイがユーザUに提供される。また、グループ料金は、グループUGが音楽ゲームをプレイするために必要な所定の対価である。つまり、グループ料金は、グループUGの全ユーザUが音楽ゲームをプレイするための対価としてグループUGの各ユーザUに共通に設定される料金である。例えば、グループ料金は、グループUGを形成するユーザUの人数に応じて決定されてよい。つまり、グループ料金は、グループプレイを共通にプレイするユーザUの人数に応じて変化してよい。そして、グループ料金の支払いに伴い(グループ料金の徴収と引き換えに)、音楽ゲームのグループプレイがグループUGの各ユーザUに提供される。
【0035】
図3の例では、第1ユーザU1によって個別プレイが選択され、個別料金が支払われている。そして、個別料金の徴収に伴い、この個別料金を支払った第1ユーザU1に個別プレイが提供される。一方、グループUGは、例えば、第2ユーザU2及び第3ユーザU3を含んでいる。また、グループUGによってグループプレイが選択され、グループ料金が支払われている。そして、グループ料金の徴収に伴い、第2ユーザU2及び第3ユーザU3といった、このグループUGを形成する各ユーザUにグループプレイが提供される。
【0036】
また、図3の例では、グループ料金は、グループUGのユーザUの人数に応じた第1グループ料金及び第2グループ料金を含んでいる。また、一例として、第1グループ料金及び第2グループ料金には、グループUGのユーザUの人数で割った場合の均等額、つまりこれらのグループ料金を各ユーザUに均等に割り当てた場合のそれぞれの均等額が相違するように互いに異なる額が設定される。具体的には、第1グループ料金は第1均等額が、第2グループ料金は第2均等額が、それぞれ均等額となるように設定されてよい。そして、第1均等額と第2均等額とは互いに相違している。つまり、グループ料金は、人数に応じて単に均等額分が増加するのではなく、この均等額自体が変化するように設定される。一例として、このようにグループUGのユーザUの人数に応じて均等額が変化するようにグループ料金は設定される。この場合、グループUGを形成する複数のユーザUが本発明の複数のユーザとして、グループ料金が本発明の全体の対価として、それぞれ機能する。
【0037】
なお、グループUGは、適宜の形態で形成されてよい。例えば、グループUGは、ユーザUの指定等、その他の各種の条件に基づいて形成されてもよい。具体的には、例えば、グループUGは、上述のマッチングサービスを通じてマッチング(ゲームの途中でマッチングされる場合を含む)によって形成されてよい。つまり、グループUGは、マッチングされた各ゲーム機GMのユーザUによって形成されてよい。また、このようなマッチングは、例えば、各ゲーム機GMの要求(募集)に基づいて要求したゲーム機GMを含むように実行されてもよいし、特定のゲーム機GMの要求に基づいてその特定のゲーム機GMを含むように実行されてもよい。或いは、特定のゲーム機GM及びその特定のゲーム機GMを使用する特定のユーザUが指定する指定のゲーム機GMを含むようにマッチングが実行されてもよい。そして、その特定のユーザU及び指定のゲーム機GMを使用するユーザUによってグループUGが形成されてもよい。これらの場合、マッチングされた複数のゲーム機GM及びそれらを使用するユーザが本発明の複数のゲーム機及び複数のユーザとしてそれぞれ機能する。或いは、グループUGは、一台のゲーム機GMを共通に使用する各ユーザUによって形成されてもよい。同様に、グループUGを形成するユーザUの数も適宜でよい。
【0038】
図4は、人数に応じた均等額の変化の一例を説明するための説明図である。図4に示すように、例えば、グループ料金は、グループUGを形成するユーザUの人数が増えるに従って均等額が小さくなるように設定されてよい。つまり、グループ料金は、ユーザUの人数が多くなるほど、均等額が小さくなるように設定されてよい。
【0039】
具体的には、例えば、二人のユーザUによって形成される第1グループUG1に第1グループ料金が、三人のユーザUによって形成される第2グループUG2に第2グループ料金が、それぞれグループ料金として設定されてよい。つまり、第1グループ料金はユーザUの数が二人の場合のグループ料金に、第2グループ料金はユーザUの数が三人の場合のグループ料金に、それぞれ対応してよい。そして、例えば、人数の増加に従って均等額が減少するように、第1グループ料金及び第2グループ料金は設定されてよい。つまり、第2均等額の方が第1均等額よりも小額になるように第1グループ料金及び第2グループ料金が設定されてよい。換言すれば、プレイ人数に応じた特典(一人当たりの負担額の減少)がプレイ料金に付与されるようにグループ料金は設定されてよい。したがって、第2グループ料金(三人分のグループプレイのプレイ料金)の額は、第1均等額を三人分積算した額よりも小さくなってよい。
【0040】
図4の例では、第1均等額(“200円”)として、個別料金が利用されている。結果として、個別料金(“200円”)を二人分積算した積算額(“400円”)が第1グループ料金として設定されている。また、この設定に伴い、第1グループUG1を形成する第2ユーザU2及び第3ユーザU3の二人のユーザUに第1グループ料金及び第1均等額の少なくともいずれか一方が通知される。そして、この第1グループ料金の支払いに伴い、第2ユーザU2及び第3ユーザU3に共通のグループプレイが提供される。
【0041】
なお、グループ料金が均等に分担される場合の各ユーザUの負担額は、個別料金に限定されない。このような負担額として、ユーザUの人数に応じて設定されるグループ料金の各種の均等額が採用されてよい。例えば、このような均等額は、徴収可能な対価の単位に応じて適宜に設定されてよい。例えば、グループ料金がコインによって徴収される場合には、10円、或いは100円等の単位で適宜に設定されてよい。同様に、グループ料金が電子通貨によって徴収される場合には、1円単位等の適宜の単位で設定されてよい。また、端数(徴収可能な対価の単位より小さい数)は、切り捨て或いは切り上げ等により適宜に処理されてよい。或いは、端数は、特定のユーザU等にまとめて加算されてもよい。例えば、コイン及び電子通貨等の複数の支払い方法が存在する場合には、そのような端数は電子通貨によって支払うユーザU等、端数の支払いが可能なユーザUに加算されてもよい。
【0042】
或いは、グループ料金(人数に応じて変化する料金)の適用は、特定の支払い方法のユーザUに限定されてもよい。この場合、グループ料金の算出は、その特定の支払い方法のユーザUの人数を対象に実行されてもよいし、他の支払い方法のユーザUを含むグループ全体の人数を対象に実行されてもよい。これにより、特定の支払い方法の選択を促進することができる。具体的には、特定の支払い方法として、例えば、電子通貨による支払いが採用されてもよい。この場合、例えば、コイン支払い及び電子通貨支払いのユーザUが混在するときには、コイン支払いのユーザUの負担額として個別料金が適用される一方で、その支払い後に残るグループ料金の残額を按分した額が電子通貨支払いのユーザUの負担額として適用されてもよい。また、この場合のグループ料金は、コイン支払いのユーザUの人数を含めて算出されてもよいし、電子通貨支払いのユーザUの人数だけを対象に算出されてもよい。
【0043】
同様に、支払い方法は、例えば、実際の支払いによって特定されてもよいし、各ユーザUの選択(自己申請)によって特定されてもよい。このような選択は、例えば、人数の確定のために人数確定前(例えば、マッチング前)に行われてもよいし、人数確定後(例えば、マッチング後)に行われてもよい。支払い方法に応じて負担額が変化する場合等、通知後の負担額の変化に伴い、負担額と実際の支払額と間に差額が生じる(実際の支払い額の方が多い)場合、差額分が次回の支払い用に保留されもよいし、払い戻されてもよい。この払い戻しは、別の支払い方法に対応する対価を通じて実行されもよい。例えば、コインで支払われた場合の差額が電子通貨として払い戻されてもよい。また、支払い方法は、例えば、選択可能か否かによって自動で特定されてもよい。具体的には、例えば、カードCDが所定の価値として電子通貨の支払いに使用される場合に、カードCDが電子通貨の支払いに使用可能であるか否か、或いはその支払い可能な残高が支払いに十分か否かによって特定されてよい。つまり、一例として、電子通貨の支払いが可能であり、残高も十分なカードCDが使用された場合に支払い方法が自動的に電子通貨支払いと特定されてもよい。
【0044】
一方、図4の例では、第1均等額を三人分積算した場合の積算額に該当する600円よりも小さい料金が第2グループ料金として設定されている。具体的には、第2グループ料金はとして“500円”が設定されている。これを第2グループUG2のユーザUの人数(三人)で割った場合、“167円”が均等額(第2均等額)として算出される。つまり、第1均等額よりも第2均等額(“167円”)が33円安くなるように第2グループ料金は設定されている。そして、このような第2グループ料金及び第2均等額の少なくともいずれか一方が第2グループUG2を形成する第2ユーザU2〜第4ユーザU4に通知され、この第2グループ料金の支払いに伴い、第2ユーザU2〜第4ユーザU4の三人のユーザUに共通のグループプレイが提供される。一例として、グループUGの人数に応じて、このような特典(割引)が付与されるようにグループ料金は設定されてよい。
【0045】
グループ料金は、グループUGの各ユーザUが適宜の負担額を分担するように各種の支払方法で支払われてよい。図5は、グループ料金の支払い方法の一例を説明するための説明図である。また、図5の例は、図4の例の第1グループUG1が第1グループ料金を支払う場合の支払い方法の一例を示している。図5に示すように、第1グループ料金は、例えば、第1グループUG1を形成する第2ユーザU2及び第3ユーザU3の負担額がそれぞれ相違する第1支払い方法〜第3支払い方法によって支払われてよい。
【0046】
具体的には、例えば、第1支払い方法として、第1グループ料金(“400円”)の第1均等額(“200円”)を第2ユーザU2及び第3ユーザU3が均等に負担する支払い方法が採用されてよい。つまり、第1グループ料金は、第2ユーザU2及び第3ユーザU3によって平等に負担されてよい。この場合、第2ユーザU2及び第3ユーザU3の負担額は等しく第1均等額となる。
【0047】
一方、例えば、第2支払い方法及び第3支払い方法として、第2ユーザU2及び第3ユーザU3の負担額が相違する(負担額が等しくない)方法が採用されてもよい。例えば、第2支払い方法及び第3支払い方法として、本来各ユーザUが負担すべき第1均等額の一部を他のユーザUが負担する支払い方法、及び全部を負担する支払い方法が採用されてよい。つまり、第1グループ料金は、グループUGの二人のユーザU間における負担額の相違を許容するように設定されてよい。
【0048】
図5の例では、第2支払い方法として、第1グループUG1の第2ユーザU2及び第3ユーザU3のうち、第2ユーザU2の方が第3ユーザU3よりも100円多く負担する支払い方法が採用されている。つまり、第1均等額(“200円”)のうち、本来第3ユーザU3が負担すべき一部(100円)を第2ユーザU2が負担している。結果として、第2ユーザU2の負担額(“300円”)と第3ユーザU3の負担額(“100円”)との間には、200円の差が生じている。
【0049】
一方、図5の例では、第3支払い方法として、第2ユーザU2が第1グループ料金の全部を負担する支払い方法が採用されている。つまり、第1均等額のうち、本来第3ユーザU3が負担すべき全部(“200円”)を第2ユーザU2が負担している。結果として、第3ユーザU3は第1グループ料金を全く負担しておらず、第2ユーザU2の負担額(“300円”)と第3ユーザU3の負担額(“0円”)との間には、400円の差が生じている。一例として、グループ料金がグループUGの各ユーザUに均等(同額)に負担される場合だけでなく、このようにグループUGの一部のユーザUによってグループ料金の全額が負担される場合も含め、異なる負担額が生じることも許容するように各種の支払い方法でグループ料金は支払われてよい。
【0050】
なお、例えば、各ユーザUの負担割合(グループ料金を負担する割合)は、予め決められていてもよい。同様に、負担割合が他のユーザUよりも大きいユーザUも予め決められていてもよい。例えば、このような負担割合(負担額)の大きいユーザUは、特定のユーザUが他のユーザUよりも多く料金を負担する等、各ユーザUによる指定、或いは自己申請(自己による指定)等によって決定されてもよい。或いは、グループUGがマッチングによって決定される場合には、マッチングを要求したゲーム機GMのユーザUがこのようなユーザUとして機能してもよい。同様に、マッチングがユーザUの指定した各ゲーム機GMをマッチングするように実行される場合には、その各ゲーム機GMを指定する特定のユーザUがこのようなユーザUとして機能してもよい。或いは、マッチングサービスに最初にエントリしたユーザUや特定の支払い方法(例えば、電子通貨による支払い等)によって対価を支払った(或いは支払い可能な)ユーザUが、このようなユーザUとして機能してもよい。さらには、負担割合の大きいユーザUは、抽選等によりランダムに決定されてもよい。
【0051】
同様に、負担割合の大きいユーザUの負担額は、複数人分等、予め決められていてもよい。また、このような負担額は、例えば、負担条件に基づいて決定されてもよい。例えば、負担条件は、自己が負担すべき負担額の指定を要件に含んでいてもよい。つまり、各ユーザUの負担額は、各ユーザUの選択によって決定されてもよい。具体的には、例えば、グループプレイは、通常モード及び通常モードに比べて各種の有利な展開やゲーム要素を有する特別モードを含み、これらのモードには特別モードの方がプレイに必要な対価の額が高くなるように異なる対価の額が設定されていてよい。そして、通常モードを選択したユーザUには通常モードに対応する対価の額が、特別モードを選択したユーザUには特別モードに対応する対価の額が、負担すべき負担額として設定されてよい。つまり、対価の額の相違するモードの選択を通じて各ユーザUの負担額が決定されてもよい。この場合、特定モードに対応する対価の額及び特定モードの指定が本発明の特定負担額及び特定負担額の指定としてそれぞれ機能する。
【0052】
また、例えば、グループUG内の少なくとも一部のユーザUが特別モードを選択し、それに対応する対価を支払った場合、グループUG内の全員に特別モードが提供されてもよい。つまり、特別モードの有利な展開等が負担額の異なるユーザU(特別モードを選択したユーザU)の存在に伴う特典として利用されてもよい。この場合、この特典の対象は、グループUGの全員と捉えられてもよいし、特別モードを選択したユーザU以外と捉えられてもよい。つまり、負担額の異なるユーザUの存在に伴い、グループUGの全員或いは一部のユーザUに特典が付与されてもよい。これにより、負担額の相違を促進することができる。また、このような特典として、例えば、その他にも、特別の背景等の装飾要素、或いはアイテムやプレイ時間の追加等のゲームの進行に有利な要素等、各種のゲーム要素が利用されてもよい。
【0053】
負担条件は、例えば、その他にも抽選結果を要件に含んでいてよい。つまり、各ユーザUの負担額は、抽選結果によりランダムに決定されてもよい。また、各ユーザUの選択や抽選等により負担額の大きいユーザUが決められる場合、換言すれば、各ユーザUの支払うべき負担額がセンターサーバ2等により事前に決められる場合、各ユーザUが支払うべき負担額(個別の負担額)は、各ゲーム機GM等を通じて各ユーザUに通知されてもよい。そして、各ユーザUには、その通知された負担額の支払が要求されてよい。
【0054】
次に、集団料金データ14aの詳細について説明する。集団料金データ14aは、グループ料金を管理するためのデータである。図5は、集団料金データ14aの内容の一例を説明するための説明図である。図5に示すように、例えば、集団料金データ14aは、“集団ID”、“ユーザID”、“集団料金”、及び“徴収結果”の情報を含んでいてよい。
【0055】
“集団ID”は、グループUG毎にユニークな集団IDを示す情報である。集団IDは、例えば、各グループUGの識別(特定)に使用される。また、“ユーザID”は、上述のユーザIDを示す情報である。“ユーザID”の情報は、例えば、各グループUGに属するユーザUの数の取得に使用されてもよい。つまり、“ユーザID”の情報は、各グループUGのユーザUの数の情報として機能してよい。
【0056】
一方、“集団料金”は、グループプレイに設定されるグループ料金を示す情報である。グループ料金は、上述の通り、例えば、ユーザUの人数に応じて均等額が変化するように設定されてよい。具体的には、グループ料金は、例えば、ユーザUの数に応じた第1グループ料金等を含んでよい。このような場合、“集団料金”には、ユーザUの数に応じて設定されるべき第1グループ料金等のグループ料金の情報が記述されてよい。また、第1グループ料金等、ユーザUの人数に応じたグループ料金の候補が予め用意されている場合には、“集団料金”の情報として、例えば、これらの候補を特定(識別)するための情報が利用されてもよい。
【0057】
“徴収結果”は、グループ料金の徴収結果を示す情報である。具体的には、“徴収結果”は、例えば、グループ料金が徴収されたことを示す徴収済みの情報或いは徴収されていないことを示す未徴収の情報を含んでいてよい。一例として、集団料金データ14aは、これらの情報が互いに関連付けられるように記述されたレコードの集合として構成されてよい。
【0058】
なお、集団料金データ14aは、例えば、その他にも“個別負担額”或いは“均等額”の情報を含んでいてもよい。“個別負担額”は、各ユーザUが個別に負担すべき負担額を示す情報である。“個別負担額”には、例えば、負担割合の大きいユーザUの負担額等、各ユーザUの負担額が事前に特定される場合に、そのような各ユーザUの負担額を示す情報が記述されてよい。そして、“個別負担額”は各ユーザUの負担額の特定や通知等に使用されてよい。同様に、“均等額”は、グループ料金をユーザUの数で割った場合の均等額を示す情報である。例えば、“均等額”の情報は、第1均等額等、各グループ料金の均等額が各ユーザUに通知される場合に、この通知のために使用されてよい。
【0059】
次に、料金通知処理について説明する。料金通知処理は、グループ単位で音楽ゲームがプレイされる場合のグループ料金を通知するための処理である。具体的には、グループUGのユーザUの人数に応じて変化するグループ料金の額を通知するための処理である。料金通知処理は、例えば、図7のルーチンを通じてセンターサーバ2の制御ユニット10によって実現されてよい。より具体的には、図7のルーチンは、制御ユニット10のWebサービス管理部17を通じて実行されてよい。なお、ゲーム機GMの制御ユニット30及びセンターサーバ2の制御ユニット10は、この処理の他にも各種の周知な処理等を、それぞれ単独で或いは互いに協働して実行する。しかし、それらの詳細な説明は省略する。
【0060】
図7は、料金通知処理を実現するための料金通知処理ルーチンのフローチャートの一例を示す図である。より具体的には、図7の例は、マッチングによってグループUGが形成される場合の料金通知処理ルーチンのフローチャートの一例を示している。図7のルーチンは、例えば、各ゲーム機GMからグループ料金の設定が要求された場合に実行されてよい。また、例えば、各ゲーム機GMは、例えば、音楽ゲームのプレイのうち、グループプレイが選択された場合にグループ料金の設定をセンターサーバ2に要求してよい。なお、例えば、グループUGが一台のゲーム機GMを共通に使用する各ユーザUによって形成される場合等、一台のゲーム機GMでグループUGの形成が可能な場合には、図7のルーチンは、ゲーム機GMの制御ユニット30によって実行されてもよい。
【0061】
図7のルーチンが開始されると、Webサービス管理部17は、まずステップS11においてグループプレイをプレイするユーザUの数、換言すれば、グループUGを形成するユーザUの数を特定する。この特定は、例えば、マッチング結果に基づいて実現されてよい。或いは、この特定は集団料金データ14aの“ユーザID”の情報に基づいて実現されてもよい。なお、グループUGがユーザUの設定等、マッチングサービス以外によって形成される場合、例えば、ユーザUの入力結果に基づいてユーザUの数が特定されてもよい。
【0062】
続くステップS12において、Webサービス管理部17は、グループプレイに必要なグループUG全体のプレイ料金として、ユーザUの数に応じて均等額が変化するようにグループUGに共通のグループ料金を設定する。具体的には、例えば、第1グループ料金等の候補が予め用意されている場合には、Webサービス管理部17は、グループUGのユーザUの数に応じて設定されるべきグループ料金をそれらの候補から選択することによりユーザUの数に応じて均等額が変化するグループ料金を設定してよい。さらに、各ユーザUの負担額が事前に決められている場合には、Webサービス管理部17は、ステップS12においてユーザU毎の負担額を設定してもよい。具体的には、例えば、各ユーザUから個別料金(均等額)が徴収されるべき場合には、Webサービス管理部17は各ユーザUが個別料金を負担するように各ユーザUの負担額として個別料金を設定してよい。或いは、各ユーザUの負担額がモードの指定によって決定される場合には、特定モードを指定したユーザUが特定モードに対応する料金を、通常モードを指定したユーザUが通常モードに対応する料金を、それぞれ負担するように、Webサービス管理部17は各ユーザUに指定結果に対応するモードの料金を負担額として設定してよい。
【0063】
次のステップS13において、Webサービス管理部17は、ステップS12で設定したグループ料金が各ユーザUに通知されるように、そのグループ料金をグループUGに属する各ゲーム機に通知する。また、ステップS12においてユーザU毎の負担額が設定されている場合には、この通知にはユーザU毎の負担額が含まれていてもよい。そして、Webサービス管理部17は、ステップS13の処理を終えると、今回のルーチンを終了する。これにより、グループプレイが選択される場合に、ユーザUの数に応じて均等額が変化するグループ料金が設定され、各ユーザUに通知される。また、ユーザU毎の負担額が事前に決められる場合には、ユーザU毎の負担額も設定され、通知される。
【0064】
以上に説明したように、この形態によれば、グループプレイを選択するグループUGのユーザUの数に応じて均等額が変化するように、グループプレイをプレイするためのグループ料金が設定される。つまり、グループプレイをするために支払われる料金のグループUG単位の合計額(総額)を、ユーザUの数に応じて均等額が変化するように変化させることができる。結果として、その合計額の変化を通じてグループUGを形成するユーザUの数に動機付けを行うことができる。
【0065】
より具体的には、例えば、グループUGを形成するユーザUの数の増加に伴い均等額が小さくなるようにグループ料金が設定される場合には、ユーザUの数に応じた割引(ボリュームディスカウント)を実現することができる。この場合、ユーザUの数が増えるに従って各ユーザUが負担すべき負担額を減少させることができるので、料金面でユーザUの数の増加に対する動機付けを行うことができる。これにより、グループUGのユーザUの数の増加を促進することができる。つまり、ボリュームディスカウントを通じて、グループプレイをプレイするユーザUの数の増加に対する動機付け及びその増加の促進を実現することができる。ボリュームディスカウントにより均等額は減少するものの、グループUGのユーザUの数が増加すれば、グループ料金の総額は増加する。したがって、これらによりグループプレイに伴い徴収される料金の額を増加させることができる。
【0066】
以上の形態において、センターサーバ2の制御ユニット10が、図7のルーチンを実行することにより本発明の人数判別手段及び対価設定手段として機能する。
【0067】
本発明は上述の形態に限定されず、適宜の形態にて実施することができる。例えば、上述の形態では、グループプレイの場合、グループUGの全体の料金としてグループ料金が設定されている。しかし、本発明は、このような形態に限定されない。例えば、グループ料金の設定は、省略されてもよい。具体的には、例えば、グループUGの各ユーザUが均等額を負担する場合やモードの指定に応じて各ユーザUの負担額が決められる場合等、負担条件等に基づいて各ユーザUが個別に負担すべき個別の負担額が事前に決められる場合には、グループ料金の設定は省略されてもよい。この場合、負担条件等に基づいて決められる各ユーザUの個別の負担額が本発明の個別の対価として機能する。
【0068】
上述の形態では、グループ料金は、グループUGのユーザUの数が増加するほど、均等額が小さくなるように変化している。しかし、本発明は、このような形態に限定さない。例えば、グループ料金は、上述の形態とは反対に、グループUGのユーザUの数が増えるに従って均等額が増加するように変化してもよい。このような場合でも、例えば、ユーザの数が所定数以上のときに限定される展開(プレイ範囲)や有利な要素等の特典の付与を利用して、やはりユーザの数の増加に対する動機付けを行うことができる。また、このような場合も、ユーザUの数の増加に伴い、各ユーザUの単価を増加させることができるので、やはりグループプレイによって徴収される料金の額を増加させることができる。
【0069】
上述の形態では、ゲーム機GMは音楽ゲームを提供している。しかし、ゲーム機GMが提供するゲームは、このような形態に限定されない。例えば、その他にも、アクションゲーム、ロールプレイングゲーム、アドベンチャーゲーム、シミュレーションゲーム、パズルゲーム、カードゲーム、シューティングゲーム、スポーツゲーム、複合ゲーム等の各種のゲームがゲーム機GMによって提供されてよい。
【0070】
同様に、上述の形態では、制御ユニット30及び記憶ユニット31がゲーム機GMに設けられている。しかし、本発明のゲーム機GMは、このような形態に限定されない。例えば、クラウドコンピューティングを利用してネットワーク上に論理的に制御ユニット30及び記憶ユニット31が設けられてもよい。つまり、ゲーム機GMは、ネットワーク3を通じて制御ユニット30の処理結果を提供する端末として構成されていてもよい。さらに、本発明のゲームシステムは、一台のゲーム機GMを使用する複数のユーザUによってグループUGが形成される場合等において、センターサーバ2が省略され、一台のゲーム機GMによって実現されてもよい。
【0071】
以下に、上述の内容から得られる本発明の一例を記載する。なお、以下の説明では本発明の理解を容易にするために添付図面の参照符号を括弧書きにて付記したが、それにより本発明が図示の形態に限定されるものではない。
【0072】
本発明のゲームシステムは、所定の対価の徴収と引き換えに複数のユーザ(UG)に共通のゲームをプレイさせるゲームシステム(1)であって、前記ゲームをプレイする前記複数のユーザの人数を判別する人数判別手段(10)と、前記人数判別手段の判別結果に基づいて、前記ゲームのプレイに伴い前記所定の対価として前記複数のユーザの全体から徴収されるべき全体の対価の額(例えば、グループ料金)を前記複数のユーザの各ユーザに均等に割り当てた場合の均等額が前記複数のユーザの人数に応じて変化するように、各ユーザから個別に徴収されるべき個別の対価(例えば、個別の負担額)及び前記全体の対価の少なくともいずれか一方の額を設定する対価設定手段(10)と、を備えている。
【0073】
本発明のゲームシステムによれば、共通のゲームをプレイする複数のユーザの数に応じて均等額が変化するように、このゲームのプレイに伴う対価として複数のユーザの全体から徴収されるべき全体の対価の額及び各ユーザから個別に徴収されるべき個別の額の少なくともいずれか一方の額が設定される。これにより、複数のユーザが共通のゲームをプレイする場合に各ユーザによって支払われる所定の対価の合計額を、ユーザの数に応じて各ユーザに割り当てられるべき均等額が変化するように変化させることができる。結果として、対価の合計額を通じて共通のゲームをプレイする複数のユーザの数に動機付けを行うことができる。具体的には、例えば、ユーザの数の増加に伴い均等額が減少するように変化する場合には、共通のゲームをプレイするユーザの数に応じた割引(ボリュームディスカウント)を実現することができる。この場合、ユーザの数が増えるに従って各ユーザが負担すべき負担額を減少させることができるので、対価の面でユーザの数の増加に対する動機付けを行うことができる。これにより、共通のゲームをプレイするユーザの数の増加を促進することができる。一方、例えば、ユーザの数の増加に伴い均等額が増加するように変化する場合でも、例えば、ユーザの数が所定数以上のときに限定される展開(プレイ範囲)や有利な要素等の特典の付与を利用して、やはりユーザの数の増加に対する動機付けを行うことができる。結果として、これらにより徴収される対価の額を増加させることもできる。
【0074】
個別の対価及び全体の対価は、各種の態様で設定されてよい。例えば、本発明のゲームシステムの一態様において、前記対価設定手段は、前記複数のユーザ間における負担額の相違を許容するようにユーザ毎の前記個別の対価及び前記全体の対価の少なくともいずれか一方の額を設定してもよい。また、この態様において、前記対価設定手段は、前記複数のユーザに含まれる特定のユーザ(例えば、特別モードを選択したユーザU)が負担すべき特定負担額(例えば、特別モードに対応する対価の額)が負担条件に基づいて決定される場合に、当該特定負担額を前記特定のユーザが負担するように、前記ユーザ毎の前記個別の対価を設定してもよい。さらに、この態様において、前記負担条件は、前記特定のユーザによる前記特定負担額の指定(例えば、特別モードの指定)を要件に含み、前記対価設定手段は、前記特定のユーザによって前記特定負担額が指定された場合に、当該特定負担額を前記特定のユーザが負担するように、前記ユーザ毎の前記個別の対価を設定してもよい。
【0075】
また、本発明のゲームシステムの一態様において、前記対価設定手段は、前記複数のユーザの人数が多くなるほど、前記均等額が小さくなるように、前記個別の対価及び前記全体の対価の少なくともいずれか一方の額を設定してもよい。この場合、ボリュームディスカウントを通じて、ユーザの数の増加に対する動機付け及びゲームをプレイするユーザの数の増加の促進を実現することができる。
【0076】
複数のユーザは、各種の態様で決定されてよい。例えば、本発明のゲームシステムの一態様として、各ユーザに前記ゲームを提供する各ゲーム機(GM)と、各ゲーム機とネットワーク(3)を介して接続されるサーバ装置(2)と、を備え、前記複数のユーザは、前記サーバ装置が実行するマッチングによって決定され、前記複数のユーザとして、前記サーバ装置を介してマッチングされた複数のゲーム機をそれぞれ使用する複数のユーザが機能する態様が採用されてもよい。
【0077】
一方、本発明のコンピュータプログラムは、前記ゲームの提供に使用される出力装置(MO)に接続されるコンピュータ(10、30)を、上述のゲームシステムの各手段として機能させるように構成されたものである。
【0078】
また、本発明のサーバ装置(2)は、前記ゲームの提供に使用される出力装置(MO)にネットワーク(3)を介して接続され、上述のゲームシステムの各手段として機能するものである。本発明のコンピュータプログラム或いはサーバ装置が実行されることにより、本発明のゲームシステムを実現することができる。
【符号の説明】
【0079】
1 ゲームシステム
2 センターサーバ(サーバ装置)
3 ネットワーク
10 制御ユニット(コンピュータ、人数判別手段、対価設定手段)
U ユーザ
UG グループ(複数のユーザ)
MO モニタ(出力装置)
GM ゲーム機
図1
図2
図3
図4
図5
図6
図7