(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0026】
[1.ゲームシステムのハードウェア構成]
以下、本発明の一実施形態(実施形態)について、図面に基づき詳細に説明する。
図1は、本発明の実施形態に係るゲームシステムSの全体構成を示す図である。
図1に示すように、ゲームシステムSは、例えば、ゲームサーバ1と、複数のユーザ装置2と、を含む。ゲームシステムSに含まれる各装置は、ネットワークを介してデータ通信可能に接続される。
【0027】
ゲームサーバ1は、例えば、公知のサーバコンピュータである。
図1に示すように、ゲームサーバ1は、制御部10と、記憶部12と、通信部14とを含む。なお、ゲームサーバ1は、他にも図示しないキーボード、モニタ、情報記憶媒体の読取装置等を含んでいてもよい。
【0028】
制御部10は、例えば、CPU等を含んで構成される。制御部10は、記憶部12に記憶されたプログラムを実行して各種処理を行ったり、通信部14を介してユーザ装置2と各種データの送受信を行ったりする。記憶部12は、例えば、ハードディスクやRAM等のメモリを含んで構成される。記憶部12は、ゲームプログラム等の各種プログラムや各種データ等を記憶する。通信部14は、例えば、ネットワークカード等の通信装置である。
【0029】
ユーザ装置2は、公知のコンピュータによって実現される。例えば、ユーザ装置2は、家庭用ゲーム機、業務用ゲーム機、携帯電話機(スマートフォン)、パーソナルコンピュータ等である。
図1に示すようにユーザ装置2は、制御部20と、記憶部22と、操作部24と、表示部26と、入力部28と、通信部30と、から構成される。なお、ユーザ装置2は、図示しない他の構成を含んでいてもよい。
【0030】
制御部20と記憶部22と通信部30とは、それぞれ制御部10と記憶部12と通信部14と同様のハードウェア構成であるので、説明を省略する。本実施形態では、制御部20は、記憶部22に記憶されたプログラムを実行することによって、ゲームを実行する。操作部24は、コントローラ及びキーボード等を含み、ユーザの操作内容を制御部10に伝達する。表示部26は、液晶表示パネル等を含み、制御部10の指示により各種画面を表示する。入力部28は、DVD再生装置等を含み、外部記憶装置から各種データを入力する。
【0031】
なお、本実施形態において記憶部22に記憶されているものとして説明するプログラムやデータは、入力部28を介して情報記憶媒体から取得されるようにしてもよいし、ネットワークを介して外部のコンピュータから取得されるようにしてもよい。
【0032】
[2.ゲームシステムにおいて実行されるゲーム]
ゲームシステムSにおいては、ユーザが使用対象を用いてプレイするゲームが実行される。ここでは、ユーザがキャラクタを用いてプレイするサッカーゲームが実行される場合を説明する。サッカーゲームは、一のユーザが他のユーザと対戦する形式であってもよいし、一のユーザがコンピュータと対戦する形式であってもよい。サッカーゲームが開始されると、ユーザは、複数のキャラクタのうちから試合で使用するキャラクタ(例えば、スターティングメンバー及び控えメンバー)を選択する。
【0033】
図2は、ユーザがゲームで使用するキャラクタを選択するためのキャラクタ選択画面の一例を示す図である。
図2に示すように、キャラクタ選択画面40は、ユーザが操作するチームに所属する複数のキャラクタを示す所属キャラクタ一覧42と、ユーザが選択したキャラクタを示す使用キャラクタ一覧44を含む。
【0034】
ユーザは、所与の操作を行い、チームに所属するキャラクタのうちからゲームで使用するキャラクタを選択する。例えば、使用キャラクタ一覧44には、ユーザが操作対象としたチームに所属する複数のキャラクタのうち、ユーザが選択操作を行った複数のキャラクタ(例えば、チームに所属する30人のキャラクタのうちの23人のキャラクタ)が表示されることになる。
【0035】
なお、本実施例では、ユーザが操作対象とするチームに所属する複数のキャラクタから、使用キャラクタを選択するとしたが、ユーザが使用するキャラクタの選択方法は、これに限られない。予め用意されたキャラクタのうちからユーザが選択するようにすればよく、他にも例えば、全てのキャラクタのうちからユーザが使用するキャラクタを選択するようにしてもよいし、ユーザがゲームの進行を通じて保持したキャラクタ(例えば、ユーザがゲームプレイ中に獲得したキャラクタ)のうちからユーザが使用するキャラクタを選択するようにしてもよい。
【0036】
また、所属キャラクタ一覧42及び使用キャラクタ一覧44には、各キャラクタに関する情報が表示される。ここでは、
図2に示すように、キャラクタの名前とポジションとコストと、が所属キャラクタ一覧42及び使用キャラクタ一覧44に表示される。
【0037】
コストとは、ゲームにおいてキャラクタを使用するために必要な数値を示すパラメータである。本実施形態では、ユーザは、試合に出場するキャラクタの総コストが基準値以下となるように、キャラクタを選択する必要がある。ユーザが所属キャラクタ一覧42からキャラクタを選択して使用キャラクタ一覧44に追加すると、ユーザが選択したキャラクタの総コスト46が更新される。
図2の画面例では、ユーザは、総コスト46に示される数値が、基準値48に示される数値以下となるように、キャラクタを選択することになる。即ち、総コスト46が基準値48よりも大きくなるようなキャラクタの組み合わせでは、ユーザは試合を開始することができない。
【0038】
本実施形態のゲームシステムSは、ゲームにおけるキャラクタの使用状況に応じて、各キャラクタのコストを変化させる構成になっている。例えば、ユーザによるキャラクタの使用頻度が高くなるほどコストが高くなり、使用頻度が低くなるほどコストが低くなる。その結果、使用頻度の低いキャラクタがゲームで使用しやすくなり、使用頻度の高いキャラクタがゲームで使用しにくくなるため、各キャラクタを満遍なく使用させることができる構成になっている。以降、当該構成について詳細に説明する。
【0039】
[3.ゲームシステムによって実現される機能]
図3は、ゲームシステムSの機能ブロック図である。
図3に示すように、ゲームシステムSは、ゲームデータ記憶部60と、ゲーム実行部62と、パラメータ取得部64と、パラメータ判定部66と、決定部68と、パラメータ変更部70と、を含む。
【0040】
本実施形態においては、これら各機能がユーザ装置2により実現される場合を説明する。例えば、制御部20が、記憶部22から読み出されたプログラムに従って動作することによって、これら各機能が実現される。また、上記各機能のうち、ゲームデータ記憶部60は、記憶部22を主として実現され、他の各機能は、制御部20を主として実現される。
【0041】
[3−1.ゲームデータ記憶部]
ゲームデータ記憶部60は、ユーザが使用対象(例えば、キャラクタ)を用いてプレイするゲームに関する各種データを記憶する。本実施形態における使用対象とは、ユーザがゲームで使用するオブジェクトであり、例えば、キャラクタ、カード、又はアイテム等である。ここでは、キャラクタが使用対象に相当する。ゲームデータ記憶部60は、チームに所属するキャラクタに関するキャラクタデータを記憶する。
【0042】
図4は、キャラクタデータの一例を示す図である。
図4に示すように、キャラクタデータは、キャラクタを一意に識別するためのキャラクタIDと、キャラクタ名と、キャラクタをゲームで使用するために必要なコストを示すコストパラメータと、ゲームにおけるキャラクタの使用状況と、キャラクタに関する各種パラメータ(能力パラメータやポジション等)と、を含む。
【0043】
キャラクタの使用状況とは、現在又は過去におけるキャラクタの使用の程度であり、例えば、キャラクタの使用頻度、使用回数、使用期間等である。ここでは、所定期間におけるキャラクタの使用状況が、キャラクタデータに格納される。所定期間とは、予め定められた期間であればよく、例えば、現時点に基づいて定まる期間、又は、所定時間毎に区切られた各期間のことである。
【0044】
現時点に基づいて定まる期間とは、現時点の所定時間前から現時点までの期間であり、例えば、過去1カ月におけるキャラクタの使用回数が、キャラクタデータに格納される。また、所定時間毎に区切られた各期間とは、例えば、月単位(月の初めから終わりまでの期間)や週単位(ある曜日から次の当該曜日の前日までの期間。例えば、週の初めから終わりまでの期間)であり、例えば、所定の月におけるキャラクタの使用回数や所定の週におけるキャラクタの使用回数が、キャラクタデータに格納される。
【0045】
なお、ゲームデータ記憶部60に記憶される内容は、上記の例に限られない。他にも例えば、基準値48の値を示すデータ、実行中のゲームの状況を示すゲーム状況データ(例えば、ゲーム空間の現在の状態(例えば、キャラクタの位置等)や現在の試合の戦況、試合の経過時間等)、ユーザによる過去のゲームプレイに関するデータ(例えば、ユーザのレベルや戦績等)、又は過去に実行されたゲームの実行結果に関するデータ等が、ゲームデータ記憶部60に記憶されているようにしてもよい。また、ゲーム実行部62は、これら各種データを取得する手段及び更新する手段として機能する。
【0046】
[3−2.ゲーム実行部]
ゲーム実行部62は、ユーザが使用対象(例えば、キャラクタ)を用いてプレイするゲームを実行する。ゲーム実行部62は、ユーザが選択したキャラクタに基づいて、ゲームを実行することになる。例えば、ゲーム実行部62は、ユーザの操作に基づいてキャラクタを動作させ、ゲームデータ記憶部60に記憶されたゲーム状況データを更新する。
【0047】
また例えば、ゲーム実行部62は、ユーザがゲームをプレイした場合、当該ゲームにおいて用いられたキャラクタの使用状況を更新する。ここでは、ゲーム実行部62は、過去のゲームの実行結果から、所定期間におけるキャラクタの使用状況(例えば、使用回数)を取得して、キャラクタデータに格納された各キャラクタの使用状況を更新する。
【0048】
[3−3.パラメータ取得部]
パラメータ取得部64は、複数の使用対象候補(例えば、チームに所属するキャラクタ)の各々のコストに係るパラメータを記憶する手段(例えば、ゲームデータ記憶部60)に記憶される当該パラメータを取得する。パラメータ取得部64は、ゲームデータ記憶部60に記憶されたキャラクタデータを参照し、各キャラクタのコストパラメータを取得する。
【0049】
[3−4.パラメータ判定部]
パラメータ判定部66は、複数の使用対象候補(例えば、チームに所属するキャラクタ)のうちユーザにより選択された使用対象候補のパラメータ(例えば、コストパラメータ)の組み合わせが所与の組み合わせであるか否かを判定する。コストパラメータの組み合わせとは、ユーザが選択した各キャラクタのコストパラメータに基づいて算出される数値(コストパラメータを所与の数式に代入して得られる数値)であり、例えば、各キャラクタのコストパラメータの総和(総コスト46が示す数値)である。
【0050】
例えば、パラメータ判定部66は、組み合わせに関する条件が満たされるか否かを判定する組み合わせに関する条件とは、コストパラメータに基づいて算出される数値が所定範囲(例えば、基準値よりも大きい)であるか否かを示す条件であり、例えば、各キャラクタのコストパラメータの総和が所定範囲であるか否かを示す条件である。
【0051】
[3−5.決定部]
決定部68は、パラメータ判定部66の判定結果に基づいて、ゲームにおける使用対象候補(例えば、キャラクタ)の使用制限をするか否かを決定する。キャラクタの使用制限とは、ゲームにおいてキャラクタが用いられないように抑止すること、キャラクタに関するパラメータが変化すること(例えば、キャラクタの能力が低下すること)、キャラクタがユーザの操作に基づいて動作しなくなること(例えば、ユーザの操作対象として設定されなくなること)、キャラクタ固有の処理(例えば、特定のキャラクタのみが行うことのできる技)を実行しないこと等である。ここでは、ユーザが選択したキャラクタを使用キャラクタ一覧44にキャラクタを追加させず、ゲームで使用させないようにすることが、キャラクタの使用制限をすることに相当する。
【0052】
本実施形態では、パラメータ判定部66により組み合わせに関する条件が満たされると判定された場合、決定部68は、キャラクタの使用制限をしないと決定し、パラメータ判定部66により組み合わせに関する条件が満たされないと判定された場合、決定部68は、キャラクタの使用制限をすると決定する。
【0053】
[3−6.パラメータ変更部]
パラメータ変更部70は、複数の使用対象候補(例えば、キャラクタ)の各々のパラメータ(例えば、コストパラメータ)を、ゲームにおける当該使用対象候補の使用状況に基づいて変更する。「コストパラメータを変更する」とは、コストパラメータが示す値を変化(増減)させることである。パラメータ変更部70は、キャラクタの使用状況が所与の条件を満たす場合に、コストパラメータを変更する。
【0054】
図5は、キャラクタの使用状況とコストパラメータの変更方法との関連付けを示す図である。
図5に示す関連付けは、ゲームデータ記憶部60に記憶されており、数式形式であってもよいしテーブル形式であってもよい。コストパラメータの変更方法としては、コストパラメータを変更するか否かを示す情報、変更後のコストパラメータの数値を示す情報、又は、コストパラメータを変更する場合の変化量を示す情報が格納される。
【0055】
ここでは、キャラクタの使用状況として、所定期間における使用状況が用いられるので、パラメータ変更部70は、複数の使用対象候補(例えば、キャラクタ)の各々のパラメータ(例えば、コストパラメータ)を、当該使用対象候補の所定期間における使用状況に基づいて変更することになる。パラメータ変更部70は、キャラクタの使用状況に関連付けられた変更方法に基づいて、当該キャラクタのコストパラメータを変更する。
【0056】
例えば、
図5に示すように、使用状況に関する条件が定められており、パラメータ変更部70は、各キャラクタの使用状況が当該条件を満たすか否かを判定する。使用状況に関する条件は、キャラクタが使用されたか否か、キャラクタの使用回数若しくは使用頻度が所定範囲であるか否か、又はキャラクタが使用された期間が所定期間であるか否か等を示す条件である。パラメータ変更部70は、キャラクタの使用状況が満たすと判定された条件に関連付けられた変更方法に基づいて、当該キャラクタのコストパラメータの数値を決定することになる。
【0057】
ここでは、パラメータ変更部70は、所定期間におけるキャラクタの使用回数が多い(使用頻度が高い)ほど、コストパラメータが大きくなるように(コストパラメータが基準値に近付くように)、当該キャラクタのコストパラメータを変更する。即ち、パラメータ変更部70は、所定期間におけるキャラクタの使用回数が少ない(使用頻度が低い)ほど、コストパラメータが小さくなるように(コストパラメータが基準値から遠ざかるように)、当該キャラクタのコストパラメータを変更する。
【0058】
[4.ゲームシステムにおいて実行される処理]
図6及び
図7は、ゲームシステムSにおいて実行される処理の一例を示すフロー図である。
図6及び
図7の処理は、制御部20が、記憶部22から読み出されたプログラムに従って動作することにより実行される。また、
図6及び
図7に示す処理は、キャラクタ選択画面40が表示される際に実行される。
【0059】
図6に示すように、まず、制御部20は、表示部26にキャラクタ選択画面40を表示させる(S1)。S1においては、制御部20は、キャラクタデータを参照し、チームに所属するキャラクタを特定する。制御部20は、当該特定したキャラクタに基づいて所属キャラクタ一覧42を含むキャラクタ選択画面40を表示させる。
【0060】
制御部20は、操作部24からの操作信号に基づいて、所属キャラクタ一覧42に表示されたキャラクタがユーザにより選択されたか否かを判定する(S2)。S2においては、制御部20は、チームに所属するキャラクタのうちからユーザによる選択を受け付けることになる。
【0061】
キャラクタがユーザにより選択されたと判定されない場合(S2;N)、処理は、S8に移行する。
【0062】
一方、キャラクタがユーザにより選択されたと判定された場合(S2;Y)、制御部20は、当該選択されたキャラクタのコストパラメータを取得する(S3)。S3においては、制御部20は、キャラクタデータを参照し、ユーザに選択されたキャラクタに関連付けられたコストパラメータを取得することになる。
【0063】
制御部20は、S3において取得されたコストパラメータと、既に選択されたキャラクタ(即ち、使用キャラクタ一覧44に表示されたキャラクタ)のコストパラメータと、に基づいて総コスト46を算出する(S4)。ユーザが既に選択したキャラクタを示す情報と、これら選択されたキャラクタのコストパラメータの総和を示す情報とは、記憶部22に記憶されるものとする。S4においては、制御部20は、記憶部22に記憶された総和に、S3において取得されたコストパラメータが示す数値を加算させることになる。
【0064】
制御部20は、S4において算出された総コスト46が基準値よりも大きいか否かを判定する(S5)。S4において算出された総コスト46が基準値以下であると判定された場合(S5;N)、制御部20は、ユーザが選択したキャラクタを使用キャラクタ一覧44に追加する(S6)。S6においては、ユーザが既に選択したキャラクタを示す情報に、S2において選択されたと判定されたキャラクタが追加され、所属キャラクタ一覧42、使用キャラクタ一覧44、及び総コスト46の表示が更新されることになる。
【0065】
一方、S4において算出された数値が基準値よりも大きいと判定された場合(S5;Y)、制御部20は、ユーザが選択したキャラクタを使用キャラクタ一覧44に追加させず、エラーメッセージをキャラクタ選択画面40に表示させる(S7)。S7においては、S2において選択されたと判定されたキャラクタが、使用キャラクタ一覧44に追加されず、総コスト46の表示も更新されない。即ち、この場合、当該キャラクタの使用が制限されることになる。
【0066】
制御部20は、ユーザが既に選択したキャラクタの除外操作が行われたか否かを判定する(S8)。除外操作は、ユーザが選択したキャラクタをゲームで使用するキャラクタから除外するための操作であり、例えば、使用キャラクタ一覧44に表示されたキャラクタの何れかを選択するための操作である。
【0067】
除外操作が行われたと判定されない場合(S8;N)、処理はS12に移行する。
【0068】
一方、除外操作が行われたと判定された場合(S8;Y)、制御部20は、ユーザが選択したキャラクタを、使用キャラクタ一覧44から消去する(S9)。S9においては、制御部20は、使用キャラクタ一覧44から消去させたキャラクタを、所属キャラクタ一覧42に追加する。
【0069】
制御部20は、S9において除外されたキャラクタのコストパラメータを取得する(S10)。制御部20は、S10において取得されたコストパラメータを、総コスト46から減算する(S11)。S11においては、制御部20は、記憶部22に記憶された総コスト46の数値から、S9において取得されたコストを減算し、総コスト46の表示を更新する。
【0070】
制御部20は、開始ボタン50が選択されたか否かを判定する(S12)。開始ボタン50が選択されたと判定されない場合(S12;N)、処理はS2に戻り、ユーザがゲームで使用するキャラクタについての選択が受け付けられることになる。
【0071】
一方、開始ボタン50が選択されたと判定された場合(S12;Y)、
図7に移り、制御部20は、使用キャラクタ一覧44に表示されているキャラクタに基づいて、サッカーゲームを開始する(S13)。なお、ゲームを開始するために要する数以上のキャラクタをユーザが選択していない場合には、開始ボタン50を選択することができないようにしてもよい。
【0072】
S13においてサッカーゲームが開始されると、制御部20は、ユーザの操作に応じて、サッカーゲームを進行させる(S14)。ゲームの進行自体は、公知の種々の処理が適用可能であるので、ここでは説明を省略する。なお、ゲームの実行中に、ユーザが使用するキャラクタが変更可能であってもよい。
【0073】
制御部20は、ゲームが終了したか否かを判定する(S15)。ゲームが終了したと判定されない場合(S15;N)、処理はS14に戻り、ゲームが進行される。
【0074】
一方、ゲームが終了したと判定された場合(S15;Y)、制御部20は、ゲームにおいて使用されたキャラクタのコストパラメータを増加させ(S16)、本処理は終了する。S16においては、使用キャラクタ一覧44に表示させた全キャラクタのコストパラメータが増加するようにしてもよいし、実際に試合に出場したキャラクタのコストパラメータのみが増加するようにしてもよい。例えば、S16においては、制御部20は、S14におけるゲームの実行結果に基づいてキャラクタの使用状況を特定し、当該使用状況に関連付けられた変更方法でコストパラメータを変更することになる。
【0075】
以上説明したゲームシステムSでは、キャラクタの使用状況に応じてコストパラメータが変動し、例えば、使用頻度の低いキャラクタほどゲームで使用しやすくなり、使用頻度の高いキャラクタほどゲームで使用しにくくなるので、各キャラクタを満遍なくユーザに使用させることができる。
【0076】
また、コストパラメータの組み合わせに関する条件を定めておき、当該条件が満たされるか否かに応じて、キャラクタの使用制限をすることができる。また、所定期間における使用状況を考慮してコストパラメータを変動させるので、例えば、最近のキャラクタの使用状況に応じて当該キャラクタの使用制限をすることができる。
【0077】
[5.変形例]
なお、本発明は、以上説明した実施の形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更可能である。
【0078】
図8は、変形例の機能ブロック図である。
図8に示すように、変形例のゲームシステムSは、実施形態の機能に加えて、関連付け取得部72と、役割指定受付部74と、役割比較部76と、組み合わせ変更部78と、評価部80と、キャラクタ判定部82と、を含む。
【0079】
(1)例えば、実施形態においては、ある一人のユーザによるキャラクタの使用状況に応じてコストパラメータが変更される場合を説明したが、複数のユーザの各々がプレイするゲームが実行される場合には、各ユーザの使用状況に応じて一のキャラクタのコストパラメータが変更されるようにしてもよい。即ち、あるユーザがキャラクタを使用していなくても、他のユーザが当該キャラクタを使用した場合に、当該キャラクタのコストパラメータの数値が増加するようにしてもよい。
【0080】
変形例(1)においては、
図7に示す各機能がゲームサーバ1において実現されるものとする。例えば、ゲームデータ記憶部60は、記憶部12を主として実現され、他の各機能は、制御部10を主として実現される。変形例(1)のゲームデータ記憶部60は、複数のユーザに共通する一のキャラクタデータを記憶する。各ユーザがゲームをプレイする場合には、当該一のキャラクタデータが参照されることになる。キャラクタデータのデータ格納例は、実施形態と同様である。
【0081】
本変形例では、ゲーム実行部62は、キャラクタデータに格納された各キャラクタについて、複数のユーザの何れかが当該キャラクタを使用した場合に、キャラクタデータに格納された使用状況を更新することになる。
【0082】
パラメータ変更部70は、複数の使用対象候補(例えば、キャラクタ)の各々のパラメータを、複数のユーザによる、当該使用対象候補の使用状況に基づいて変更する。この場合、
図5に示す使用状況は、複数のユーザの何れかがキャラクタを使用した場合の使用条件に関する条件となる。即ち、パラメータ変更部70は、複数のユーザの何れかがキャラクタを使用した場合に、当該キャラクタのコストパラメータを変更する。別の言い方をすれば、パラメータ変更部70は、一のユーザが使用するキャラクタのコストパラメータを、当該一のユーザ及び他のユーザによる当該キャラクタの使用状況に基づいて変更するともいえる。
【0083】
変形例(1)によれば、複数のユーザの使用状況に応じてコストパラメータを変更することができる。なお、上記説明したパラメータ変更部70の機能は必須ではなく、省略するようにしてもよい。
【0084】
(2)また例えば、ゲームシステムSを利用するユーザ同士が関連付けられている場合には、一のユーザに関連付けられている他のユーザがキャラクタを使用した場合に、コストパラメータが変化するようにしてもよい。例えば、あるユーザと友人関係の他のユーザがキャラクタを使用した場合に、当該キャラクタのコストパラメータを変更するようにしてもよい。なお、この場合、友人関係にない他のユーザがキャラクタを使用した場合には、当該キャラクタのコストパラメータは変更されない。
【0085】
図9は、ユーザ同士の関連付けを示す図である。
図9に示す関連付けは、ゲームデータ記憶部60に記憶され、各ユーザの操作により更新される。例えば、ユーザが所定の操作をすると、当該ユーザと他のユーザとが関連付けられる。より具体的には、他のユーザが行った友人申請に対し、ユーザが承認操作を行うと、これらのユーザ同士が関連付けられることになる。
【0086】
変形例(2)においては、
図8に示す各機能がゲームサーバ1により実現される。また、変形例(2)のゲームシステムSは、関連付け取得部72を含む。関連付け取得部72は、例えば、制御部10を主として実現される。関連付け取得部72は、一のユーザと他のユーザとの関連付けを記憶する手段(例えば、ゲームデータ記憶部60)に記憶される当該関連付けを取得する。即ち、関連付け取得部72は、一のユーザに関連付けられた他のユーザを特定するための情報を取得することになる。
【0087】
また、パラメータ取得部64は、複数のユーザの各々と、複数の使用対象候補(例えば、キャラクタ)の各々のパラメータ(例えば、コストパラメータ)と、を関連付けて記憶する手段(例えば、ゲームデータ記憶部60)に記憶される当該パラメータを取得する。例えば、変形例(2)では、ユーザ毎にキャラクタデータが用意されているものとする。パラメータ取得部64は、ユーザ毎に用意されたキャラクタデータを取得することになる。
【0088】
パラメータ変更部70は、複数のユーザの各々に関連付けられた複数の使用対象候補の各々のパラメータを、当該ユーザに関連付けられた他のユーザによる、当該使用対象候補の使用状況に基づいて変更する。パラメータ変更部70は、一のユーザに関連付けられた他のユーザがゲームにおいてキャラクタを使用した場合に、当該一のユーザに関連付けられた当該キャラクタのコストパラメータを増加させる。
【0089】
変形例(2)によれば、あるユーザに関連付けられたユーザによるキャラクタの使用状況に応じてコストパラメータを変更するので、例えば、仲間関係にあるユーザと使用するキャラクタが重複することを防止することができる。なお、上記説明したパラメータ取得部64、パラメータ変更部70、及び関連付け取得部72の機能は必須ではなく、省略するようにしてもよい。
【0090】
また、変形例(2)において、一のユーザと仲間関係にある他のユーザの使用状況だけでなく、当該一のユーザ及び当該他のユーザの両者の使用状況に応じて、キャラクタのコストパラメータが変更するようにしてもよい。
【0091】
また、上記においては、あるユーザが行った友人申請を他のユーザが承認した場合に、これらユーザ同士が関連付けられる場合を説明したが、ユーザ同士が関連付けられるための承認操作は必ずしも必要ではない。他にも例えば、一のゲームに一緒に参加したユーザ同士が関連付けられるようにしてもよい。この場合、あるユーザと対戦又は協力した他のユーザとを関連付けるようにしてもよいし、対戦回数又は協力プレイ回数が基準回数以上のユーザ同士を関連付けるようにしてもよい。対戦又は協力する相手によるキャラクタの使用状況を考慮してコストパラメータを変更するので、例えば、これから対戦又は協力する相手と、ゲームで使用するキャラクタが重複することを防止することができる。
【0092】
(3)例えば、実施形態のように、ユーザが複数のゲームパートの各々をプレイするゲームが実行される場合、各パートにおけるキャラクタの使用状況に応じて、コストパラメータを変化させるようにしてもよい。なお、ここでのゲームパートとは、ゲームに含まれる複数の場面の各々のことであり、サッカーゲームは、試合の前半のゲームパートと、試合の後半のゲームパートと、で構成される。即ち、ユーザがキャラクタを一試合通じて使用した場合と、前半又は後半のみ使用した場合と、でコストパラメータの変化量を異ならせるようにしてもよい。
【0093】
変形例(3)のパラメータ変更部70は、複数の使用対象候補(例えば、キャラクタ)の各々のパラメータを、複数のゲームパートの各々における当該使用対象候補の使用状況に基づいて変更する。例えば、パラメータ変更部70は、ゲーム実行部62によるゲーム実行結果に基づいて、各キャラクタが使用されたゲームパートを特定する。そしてパラメータ変更部70は、当該特定されたゲームパートに基づいて、当該キャラクタのコストパラメータを変更する。
【0094】
この場合、パラメータ変更部70は、キャラクタが使用されたゲームパートの数が多いほど、コストパラメータの変化量が大きくなるように、コストパラメータを変更する。即ち、パラメータ変更部70は、キャラクタが使用されたゲームパートの数が少ないほど、コストパラメータの変化量が小さくなるように、コストパラメータを変更する。
【0095】
変形例(3)によれば、ユーザがキャラクタを使用したゲームパートに応じてコストパラメータを変更することができる。なお、上記説明したパラメータ変更部70の機能は必須ではなく、省略するようにしてもよい。
【0096】
(4)また例えば、実施形態のように、複数の使用対象候補(例えば、キャラクタ)の各々に、複数種類の役割(例えば、ポジション)の少なくとも一つが関連付けられている場合には、当該役割に応じてコストパラメータを変更するようにしてもよい。例えば、キャラクタがゲームで使用された場合であっても、当該キャラクタが得意とするポジションで使用された場合と、当該キャラクタが不得意とするポジションで使用された場合と、でコストパラメータの変化量を異ならせるようにしてもよい。
【0097】
変形例(4)のキャラクタデータには、各キャラクタと一又は複数のポジションとが関連付けられている。当該ポジションは、キャラクタに設定されたポジションであり、例えば、キャラクタが得意とするポジションである。例えば、ゲームにおいて複数種類の役割(例えば、フォワード、ミッドフィールダー、ディフェンダー、ゴールキーパーの4種類)が用意されており、各キャラクタには、予めこれら複数種類の役割の少なくとも一つが関連付けられている。
【0098】
変形例(4)のゲームシステムSは、役割指定受付部74と、役割比較部76と、を含む。これらは、例えば、制御部20を主として実現される。役割指定受付部74は、複数の使用対象候補(例えば、キャラクタ)の各々の役割(例えば、ポジション)について、ユーザによる指定を受け付ける。例えば、ゲームで使用されるキャラクタをユーザが選択する場合に、複数種類のポジションがユーザに提示される。役割指定受付部74は、当該提示された複数種類のポジションのうちからユーザによる指定を受け付ける。
【0099】
役割比較部76は、複数の使用対象候補(例えば、キャラクタ)の各々に関連付けられた役割(例えば、ポジション)と、当該使用対象候補についてユーザにより指定された役割と、を比較する。役割比較部76は、キャラクタデータに格納されたキャラクタのポジションと、ユーザが指定したポジションと、を比較して、両者が一致するか否かを判定する。
【0100】
変形例(4)のパラメータ変更部70は、複数の使用対象候補の各々のパラメータを、当該使用対象候補の使用状況と、役割比較部76の比較結果と、に基づいて変更する。パラメータ変更部70は、キャラクタデータに格納されたキャラクタのポジションとユーザが指定したポジションとが一致しない場合と、一致する場合と、でコストパラメータの変化量を異ならせる。
【0101】
例えば、パラメータ変更部70は、キャラクタデータに格納されたキャラクタのポジションとユーザが指定したポジションとが一致しない場合、一致する場合よりも、コストパラメータの変化量を大きくする。即ち、パラメータ変更部70は、キャラクタデータに格納されたキャラクタのポジションとユーザが指定したポジションとが一致する場合、一致しない場合よりも、コストパラメータの変化量を小さくする。
【0102】
変形例(4)によれば、ゲームにおけるキャラクタの役割に応じてコストパラメータの変化量を異ならせることができる。例えば、キャラクタが得意とするポジションで試合に出場した場合には、キャラクタが不得意とするポジションで試合に出場した場合よりも、コストパラメータの増加量を少なくすることができる。なお、上記説明したパラメータ変更部70、役割指定受付部74、及び役割比較部76の機能は必須ではなく、省略するようにしてもよい。
【0103】
(5)また例えば、使用対象のゲームにおける使用を制限されないためにコストパラメータの組み合わせが満たすべき所与の組み合わせを示す基準値48の数値を、所与の条件のもとで変更するようにしてもよい。例えば、トーナメント形式でサッカーの試合が実行される場合、ユーザがこれからプレイする試合の種別(即ち、第何回戦であるか)に応じて基準値が変更されるようにしてもよい。
【0104】
変形例(5)のゲームシステムSは、組み合わせ変更部78を含む。組み合わせ変更部78は、制御部20を主として実現される。組み合わせ変更部78は、所与の組み合わせを変更する。ここでは、組み合わせ変更部78は、組み合わせに関する条件、例えば、総コスト46の基準値48を変更する。パラメータ判定部66は、上記変更された組み合わせに基づいて判定処理を行うことになる。
【0105】
例えば、組み合わせ変更部78は、試合が開始される際にランダムで基準値48を変更したり、ユーザ又は対戦相手の操作に応じて基準値48を変更したり、ユーザ又は対戦相手の過去のゲームプレイ(例えば、ユーザの強さや戦績)に応じて基準値48を変更したり、ユーザがプレイするゲームの種別(例えば、試合内容)に応じて基準値48を変更したりするようにしてもよい。
【0106】
図10は、変更条件と総コストの基準値の変更方法との関連付けを示す図である。
図10に示す関連付けは、ゲームデータ記憶部60に記憶されており、数式形式であってもよいし、テーブル形式であってもよい。変更条件は、総コスト46の基準値48を変更するための条件であり、これからユーザがプレイするゲームに係る各種条件が設定される。例えば、ユーザ又は対戦相手により所与の操作が行われたか否かを示す条件、ユーザ又は対戦相手の過去のゲームプレイに関する条件、ユーザがプレイするゲームの種別に関する条件等が、変更条件に相当する。
【0107】
組み合わせ変更部78は、ユーザがプレイするゲームに基づいて、
図10に示す変更条件が満たされるか否かを判定する。組み合わせ変更部78は、変更条件が満たされると判定された場合、当該変更条件に関連付けられた変更方法で、総コスト46の基準値48を変更する。例えば、組み合わせ変更部78は、変更条件に関連付けられた基準値48を新たな総コスト46の基準値48としたり、変更条件に関連付けられた変化量に基づいて基準値48を変更したりする。
【0108】
変形例(5)によれば、総コスト46の基準値48を変更することができる。なお、上記説明した組み合わせ変更部78の機能は必須ではなく、省略するようにしてもよい。
【0109】
(6)また例えば、実施形態においては、ユーザがこれからプレイする1試合に使用するキャラクタの総コスト46の基準値48が設定されている場合を説明したが、ユーザが複数試合をプレイする場合に、これら複数試合のトータルでのコストの上限値が定められているようにしてもよい。例えば、10試合のコストパラメータの総和が5000以下となるように、ユーザがキャラクタを使用するようなサッカーゲームが実行されるようにしてもよい。
【0110】
変形例(6)のパラメータ判定部66は、過去に実行されたゲームにおいて用いられた使用対象候補(例えば、キャラクタ)のパラメータの組み合わせと、ユーザにより選択された使用対象候補のパラメータの組み合わせと、が所与の組み合わせであるか否かを判定する。例えば、パラメータ判定部66は、過去のゲームにおけるキャラクタの総コスト46と、直近のゲームにおけるキャラクタの総コスト46と、を所与の数式に代入して得られる数値が所定範囲であるか否かを判定する。
【0111】
ここでは、パラメータ判定部66は、最近のN(Nは2以上の整数)試合における総コスト46の総和を算出して基準値以下であるか否かを判定する。決定部68は、最近のN試合における総コスト46の総和が基準値以下であると判定された場合、ユーザが選択したキャラクタの使用制限をしないと決定し、最近のN試合における総コスト46の総和が基準値よりも大きいと判定された場合、ユーザが選択したキャラクタの使用制限をすると決定する。
【0112】
変形例(6)によれば、複数試合を決められたコストで戦い抜くゲームをユーザに提供することができる。なお、上記説明したパラメータ判定部66の機能は必須ではなく、省略するようにしてもよい。
【0113】
(7)また例えば、ユーザがプレイした試合における総コスト46に基づいて、当該ユーザのゲームプレイが評価されるようにしてもよい。例えば、ユーザが使用した総コスト46が低いほど、当該ユーザに高い評価が付与されるようにしてもよい。
【0114】
変形例(7)のゲームシステムSは、評価部80を含む。評価部80は、制御部20を主として実現される。評価部80は、ゲームが終了した場合、当該ゲームにおいて用いられた使用対象候補(例えば、キャラクタ)のパラメータ(例えば、コストパラメータ)の組み合わせに基づいて、ユーザのゲームプレイを評価する。
【0115】
評価部80は、終了したゲームにおける総コスト46に基づいて、ユーザのゲームプレイを評価する。評価部80は、総コスト46が小さいほど、ユーザに高い評価を付与する。即ち、評価部80は、総コスト46が大きいほど、ユーザに低い評価を付与する。なお、「評価を付与する」とは、ユーザに所与の称号を付与すること、ゲームにおけるパラメータ(例えば、ユーザのスコアやユーザが保有するポイント又はゲーム内通貨等)を変化させること、ゲームアイテムを付与すること等である。
【0116】
変形例(7)によれば、ユーザがプレイした試合の総コストに基づいて、当該ユーザのゲームプレイを評価することができる。なお、上記説明した評価部80の機能は必須ではなく、省略するようにしてもよい。
【0117】
また、上記では、ユーザがプレイした試合での総コスト46で評価が行われる場合を説明したが、ユーザがプレイした複数試合での総コスト46で評価が行われるようにしてもよい。この場合、評価部80は、終了したゲームにおいて用いられたキャラクタの総コスト46と、過去に実行されたゲームにおいて用いられたキャラクタの総コスト46と、に基づいてユーザのゲームプレイを評価する。例えば、評価部80は、過去のゲームにおけるキャラクタの総コスト46と、直近のゲームにおけるキャラクタの総コスト46と、を所与の数式に代入して得られる数値に基づいてユーザのゲームプレイを評価することになる。
【0118】
(8)また例えば、ユーザが選択したキャラクタの組み合わせに応じて、ゲームにおいて特別な効果が発生するようにしてもよい。ここでは、所定のゲームイベントにおいてユーザに付与されるゲームカードに、サッカーのフォーメーション(ポジションの組み合わせ)が記載されており、ユーザがこのフォーメーションに合うようにキャラクタを選択すると、当該ゲームカードに関連付けられた効果が試合で発動する場合を説明する。
【0119】
図11は、キャラクタの組み合わせと効果との関連付けを示す図である。
図11に示す関連付けは、ゲームデータ記憶部60に記憶されている。キャラクタの組み合わせとは、ユーザが選択したキャラクタが所与の組み合わせであるか否かを示す条件であり、例えば、キャラクタの役割(ポジション)の組み合わせが所与の組み合わせ(フォーメーション)であるか否か、キャラクタに係るパラメータ(例えば、コストパラメータや能力パラメータ等)の組み合わせが所与の組み合わせであるか否かを示す条件である。
【0120】
また、ここでの効果とは、ゲームにおいてパラメータを変化させること(例えば、能力パラメータを変化させること)、所与のゲームイベントを発生させること、所与のゲームアイテムをユーザに付与すること等である。
【0121】
変形例(8)のゲームシステムSは、キャラクタ判定部82を含む。キャラクタ判定部82は、ユーザにより選択された使用対象候補(例えば、キャラクタ)の組み合わせが、所与の組み合わせであるか否かを判定する。キャラクタ判定部82は、ユーザにより選択されたキャラクタと、ゲームカードに記載された組み合わせと、を比較し、両者が一致するか否かを判定する。
【0122】
変形例(8)のゲーム実行部62は、キャラクタ判定部82の判定結果に基づいて、ゲームを実行する。ここでは、ゲーム実行部62は、使用対象候補(例えば、キャラクタ)の組み合わせとゲームにおいて発生する効果との関連付けと、キャラクタ判定部82の判定結果と、に基づいてゲームを実行する。ゲーム実行部62は、ゲームカードに記載された組み合わせが満たされる場合、当該組み合わせに関連付けられた効果を、ゲームにおいて発動させる。
【0123】
変形例(8)によれば、ユーザが選択したキャラクタの組み合わせに応じて特有の効果を発動させることができる。なお、上記説明したゲーム実行部62及びキャラクタ判定部82の機能は必須ではなく、省略するようにしてもよい。また、ゲームカードに記載されたフォーメーションは、所与の条件のもとで変更されるようにしてもよい。例えば、ユーザ若しくは対戦相手の操作、ユーザ若しくは対戦相手の過去のゲームプレイ、又はユーザがプレイするゲームの種別に応じて、ゲームカードに記載されたフォーメーションを変更したりしてもよい。
【0124】
(9)また例えば、上記においては、ユーザが選択したキャラクタの総コスト46が基準値48を超えるような組み合わせでは、ユーザは試合を開始することができない場合を説明したが、キャラクタの制限方法は、これに限られない。他にも例えば、ユーザが選択したキャラクタの総コスト46が基準値48を超えた場合には、キャラクタの能力が低下したり、ユーザの操作に応じて動作しなくなったりしてもよい。
【0125】
決定部68は、パラメータ判定部66の判定結果に基づいて、ユーザにより選択された使用対象候補(例えば、キャラクタ)に係るゲーム処理の実行を制限するか否かを決定する。ゲーム処理の実行を制限するとは、キャラクタの能力又は動作を制限することであり、例えば、キャラクタの能力を低下させること、キャラクタが行うことができる動作の種類が減少すること、又は、キャラクタがユーザの操作に応じて動作しなくなることである。
【0126】
変形例(9)によれば、ユーザが選択したキャラクタの総コストが基準値を超えた場合に、キャラクタの能力を低下させたり動作を制限したりすることができる。なお、上記説明した決定部68の機能は必須ではなく、省略するようにしてもよい。
【0127】
(10)また例えば、上記説明した実施形態及び変形例のうち、2つ以上を組み合わせてもよい。
【0128】
また例えば、実施形態においては、コストパラメータの組み合わせに関する条件の一例として、ユーザが選択したキャラクタの総コスト46が基準値48よりも大きいか否かを示す条件を挙げて説明したが、他の条件が用いられるようにしてもよい。例えば、コストパラメータが示す値と、当該値のコストパラメータのキャラクタを選択すべき数と、の関連付けが条件として用いられるようにしてもよい。例えば、コストパラメータが1〜5のキャラクタを3人、コストパラメータが6〜10のキャラクタを5人、コストパラメータが11以上のキャラクタを3人、となるような組み合わせでキャラクタを選択させるようにしてもよい。
【0129】
また、所属キャラクタ一覧42に表示されたキャラクタのうち、コストパラメータと総コスト46とを加算した値が基準値48を超えるキャラクタについては、ユーザによる選択を受け付けないようにしてもよい。更に、実施形態のS1では、チームに所属するキャラクタのうちから、ゲームで使用するキャラクタをユーザが選択する場合を説明したが、必ずしもチームに所属するキャラクタから選択する必要はなく、所与のキャラクタのうちからゲームで使用するキャラクタをユーザが選択するようにすればよい。
【0130】
また、コストに係るパラメータは数値でなくてもよく記号であってもよい。また、各キャラクタがランク付け(分類分け)されている場合、各キャラクタのランクを示すパラメータがコストに係るパラメータに相当するようにしてもよい。更に、実施形態においては、ゲームが終了した後のS16においてコストパラメータが変更される場合を説明したが、コストパラメータの変更タイミングは、これに限られない。ユーザがゲームでキャラクタを使用した場合に、任意のタイミングでコストパラメータが変更されるようにすればよい。他にも例えば、キャラクタ選択画面40が表示される際にキャラクタデータが参照されてコストパラメータが変更されるようにしてもよいし、所定タイミングが到来する場合(例えば、所定曜日が到来する場合、又は、指定された日数(例えば、14日)が経過する場合)に、コストパラメータが変更されるようにしてもよい。
【0131】
また、上記実施形態においては、ユーザ装置2により、機能ブロック図に示す各機能が実現される例を挙げて説明した。ゲームシステムSに含まれる上記の各機能は、ゲームサーバ1又はユーザ装置2の何れかに含まれるようにすればよい。
【0132】
例えば、ゲームサーバ1において、各機能ブロックが実現されるようにしてもよい。この場合、ゲームデータ記憶部60は、記憶部12を主として実現され、他の各機能は、制御部10を主として実現されることになる。ゲームサーバ1は、各ユーザ装置2からユーザの操作内容を取得してゲームを実行することになる。
【0133】
また、ゲームサーバ1又はユーザ装置2とで機能ブロック図に示す各機能が分担されるようにしてもよい。この場合、ゲームシステムSを構成する各装置は、適宜、ネットワーク等を介してデータを送受信することにより、上記の各機能を実現することになる。
【0134】
また、上記実施形態では、ゲームシステムSに、ゲームサーバ1と、複数のユーザ装置2と、が含まれる例を挙げて説明したが、ゲームシステムSにはゲームサーバ1が含まれていなくてもよい。この場合、複数のユーザ装置2のうちの何れかがゲームサーバ1としての役割を果たす。他にも例えば、ゲームシステムSには、複数のゲームサーバ1が含まれていてもよい。この場合、複数のゲームサーバ1は、互いにデータの整合性を取り、本発明に係る処理を実行する。
【0135】
また例えば、上記では、ゲームサーバ1とユーザ装置2とが接続されたゲームシステムSについて説明したが、機能ブロック図で説明した各機能が一つのゲーム装置によって実現されるようにしてもよい。即ち、他のコンピュータとデータ送受信可能に接続されていない状態(即ち、オフラインの状態)でのゲーム装置に、本発明を適用するようにしてもよい。
【0136】
また、ゲームシステムSで実行されるゲームをサッカーゲームとして説明したが、ゲームシステムSで実行されるゲームは、ユーザが使用対象を使用してプレイするゲームであればよい。例えば、アメリカンフットボールゲーム、バスケットボールゲーム、ホッケーゲーム等であってもよい。また、スポーツゲーム以外のゲームであってもよく、例えば、ユーザが保有するカードを用いて対戦するカードゲームであってもよい。この場合には、各カードにコストパラメータが関連付けられており、ユーザは、自分が保有するカードのうちからゲームで使用するカードを選択することになる。