以下、本発明の実施形態の例を図面に基づいて説明する。
[1.ゲームシステムの構成]図1は、本発明の実施形態に係るゲームシステムの構成を示す。図1に示すように、本実施形態に係るゲームシステム1はサーバ10と複数のゲーム端末30−1,30−2,30−3とを含む。ゲーム端末30−1〜30−3は異なるユーザによって使用される。以下では、ゲーム端末30−1がユーザU1によって使用され、ゲーム端末30−2がユーザU2によって使用され、ゲーム端末30−3がユーザU3によって使用される場合を想定する。なお、図1では3台のゲーム端末30−1〜30−3が示されているが、ゲームシステム1は4台以上のゲーム端末を含むようにしてもよいし、2台のゲーム端末を含むようにしてもよい。
ゲーム端末30−1〜30−3はサーバ10とネットワークNを介して相互にデータ通信を行うことが可能である。また、ゲーム端末30−1〜30−3の間でもネットワークNを介して相互にデータ通信を行うことが可能である。
サーバ10は例えばサーバコンピュータである。図1に示すように、サーバ10は制御部11、記憶部12、及び通信部13を含む。制御部11は少なくとも一つのマイクロプロセッサ(CPU)を含み、記憶部12に記憶されたオペレーティングシステムやその他のプログラムに従って情報処理を実行する。記憶部12は、主記憶部(例えばRAM)及び補助記憶部(例えば、不揮発性の半導体メモリ、ハードディスクドライブ、又はソリッドステートドライブ)を含む。記憶部12はプログラムやデータを記憶するためのものである。通信部13は、ネットワークNを介して他の装置と通信するためのものである。
サーバ10はデータベース14にアクセス可能である。データベース14はサーバ10内に構築されてもよいし、他のサーバコンピュータ内に構築されてもよい。
ゲーム端末30−1〜30−3は、それぞれ、ゲームをプレイするために使用されるコンピュータである。例えば、ゲーム端末30−1〜30−3は、携帯電話機(スマートフォンを含む)、携帯情報端末(タブレット型コンピュータを含む)、携帯用ゲーム機、家庭用ゲーム機(据置型ゲーム機)、遊戯施設等に設置される業務用ゲーム機、ラップトップ型コンピュータ、又はデスクトップ型コンピュータである。ゲーム端末30−1〜30−3は同種のコンピュータでなくてもよい。
図1に示すように、ゲーム端末30−1は制御部31、記憶部32、通信部33、操作部34、表示部35、及び音声出力部36を含む。制御部31、記憶部32、及び通信部33はサーバ10の制御部11、記憶部12、及び通信部13と同様である。
操作部34は、ユーザが各種操作を行うためのものである。操作部34は、例えばボタン(キー)、レバー(スティック)、タッチパネル、又はマウス等を含む。操作部34は、ユーザが音声又はジェスチャによって操作を行うためのものであってもよい。表示部35は各種画面画像を表示するためのものであり、例えば液晶ディスプレイ又は有機ELディスプレイ等である。音声出力部36は音声データを出力するためのものであり、例えばスピーカ又はヘッドホン等である。操作部34、表示部35、及び音声出力部36は第1ゲーム端末30−1自体に設けられていてもよいし、ゲーム端末30−1に接続された外部装置として設けられてもよい。
図1では省略されているが、ゲーム端末30−1と同様に、ゲーム端末30−2,30−3も、それぞれ、制御部31、記憶部32、通信部33、操作部34、表示部35、及び音声出力部36を含む。
プログラムやデータはネットワークNを介して遠隔地からサーバ10又はゲーム端末30−1〜30−3に供給されて、記憶部12又は記憶部32に記憶される。なお、情報記憶媒体(例えば光ディスク又はメモリカード等)に記憶されたプログラムやデータを読み取るための構成要素(例えば光ディスクドライブ又はメモリーカードスロット等)がサーバ10又はゲーム端末30−1〜30−3に備えられていてもよい。そして、プログラムやデータが情報記憶媒体を介してサーバ10又はゲーム端末30−1〜30−3に供給されるようにしてもよい。
なお以下では、ゲーム端末30−1〜30−3がスマートフォンである場合を想定する。また以下では、ゲーム端末30−1〜30−3を総称して「ゲーム端末30」と記載する場合がある。
[2.ゲームの概要]ゲームシステム1では、ゲーム端末30でプログラムが実行されることによってゲームが実行される。ゲームシステム1では各種ゲームを実行することが可能である。例えば、スポーツゲーム(野球、サッカー、テニス、アメリカンフットボール、バスケットボール、バレーボール等を題材としたゲーム)、アドベンチャーゲーム、シミュレーションゲーム、ロールプレイングゲーム、又は育成ゲームのように、ゲーム形式・ジャンルを問わず様々なゲームを実行することが可能である。
またゲームシステム1では、複数のユーザが参加するゲームを実行することが可能である。例えば、複数のユーザが協力して所定の目的を達成することを目指すゲームを実行することが可能である。
ここで、「複数のユーザが協力して所定の目的を達成することを目指すゲーム」とは、例えば、複数のユーザが協力して対戦相手と対戦する対戦ゲームである。この場合、対戦で所定の結果(例えば勝利)を収めることが「目的」に相当する。なお、「対戦相手」とは、コンピュータ(CPU)であってもよいし、他のユーザであってもよい。対戦相手の数は1であってもよいし、複数であってもよい。また、「対戦」とは、複数のユーザと1又は複数の対戦相手とで行われ、勝敗等の結果を決することである。必ずしも勝ち/負けが決まらなくてもよく、引き分けになる場合があってもよい。「対戦」は、複数のユーザと1又は複数の対戦相手とが順位を競う競争(例えばレース等)も含む。「対戦」はスポーツの試合やレースに限られず、戦闘等も含む。
また、「複数のユーザが協力して所定の目的を達成することを目指すゲーム」とは、例えば、複数のユーザが協力して敵を退治するゲーム、複数のユーザが協力して特定のゲームアイテムを入手することを目指すゲーム、又は、複数のユーザが協力してゲームイベントをクリアするゲーム等であってもよい。この場合、敵を退治すること、特定のゲームアイテムを入手すること、又は、ゲームイベントをクリアすることが「目的」に相当する。
以下、ゲームシステム1で実行されるゲームの一例として野球ゲームについて説明する。以下では、便宜上、この野球ゲームのことを「野球ゲームX」と記載する。
野球ゲームXは、ユーザが一人でプレイする一人プレイパート(第1ゲームパートの一例)と、複数のユーザが協力して目的を達成することを目指してプレイする協力プレイパート(第2ゲームパートの一例)とを備える。
[2−1]まず、一人プレイパートについて説明する。例えば、一人プレイパートでは、ユーザはシナリオ(ゲームストーリー)を進めながら主人公キャラクタ(主人公たるゲームキャラクタ)に練習等を行わせることによって主人公キャラクタを育成して、自分だけのオリジナルのゲームキャラクタを作成する。
図2は一人プレイパートのフローの一例を示す。図2に示すように、一人プレイパートでは、プレフェーズPH10が実行された後、育成フェーズPH11が実行される。プレフェーズPH10では育成フェーズPH11のために必要な情報が登録・設定される。
図2に示すように、プレフェーズPH10では、まず、主人公キャラクタの基本情報の登録が行われる(PH100)。この場合、主人公キャラクタの基本情報の登録を行うための画面画像である基本情報登録画像が表示部35に表示される。
図3は基本情報登録画像の一例を示す。図3に示すように、基本情報登録画像G100の領域A101は、主人公キャラクタの基本情報を登録するための領域である。例えば、名前、音声、ポジション、利き腕、打撃フォーム(又は投球フォーム)が基本情報として登録される。「音声」は、主人公キャラクタの名前を音声出力する際の名前の読み方(よみがな・ふりがな)である。ポジションが投手以外である場合には「打撃フォーム」が登録され、ポジションが投手である場合には「投球フォーム」が登録される。
主人公キャラクタの基本情報は自動的に初期設定され、領域A101に表示される。領域A101では、各項目にそれぞれ関連付けて要素P102−1,P102−2,P102−3,P102−4,P102−5が表示される。なお、「要素」とは、例えば、画像に含まれる要素(画像、記号、又はテキスト等)であり、例えば、ボタン、アイコン、又はリンク等が「要素」の一例に相当する。「要素」には処理が関連付けられている場合があり、当該要素が選択された場合には、当該要素に関連付けられた処理が実行される。
ユーザは要素P102−1〜P102−5を選択することによって、当該要素に関連付けられた項目の内容を変更できる。例えば、「名前」には要素P102−1が関連付けられているため、ユーザは要素P102−1を選択することによって、主人公キャラクタの名前を任意の名前に変更できる。
また、基本情報登録画像G100は要素P103を含む。要素P103には、主人公キャラクタの基本情報の登録を完了するための処理が関連付けられている。ユーザが要素P103を選択すると、主人公キャラクタの基本情報の登録が完了する。
図2に示すように、主人公キャラクタの基本情報の登録が完了した場合、イベントデッキの設定が行われる(PH101)。図4は、イベントデッキの設定を行うために表示部35に表示される画面画像であるイベントデッキ設定画像の一例を示す。
ここで、「イベントデッキ」について説明しておく。イベントデッキは1又は複数のゲームキャラクタを用いて構築される。後述するように、育成フェーズPH11では、主人公キャラクタの能力の向上に有利なイベント等の各種イベントが発生する。この点、育成フェーズPH11では、発生するイベントが固定的ではなく、イベントデッキに組み込まれた1又は複数のゲームキャラクタに応じて、発生するイベントが変化する。このため、ユーザはイベントデッキに組み込むゲームキャラクタを選択することによって、育成フェーズPH11で発生し得るイベントを選択できる。なお以下では、イベントデッキに組み込むことが可能なゲームキャラクタのことを「イベントキャラクタ」と記載する。
図4に示すように、イベントデッキ設定画像G110には、イベントデッキのメンバとなるイベントキャラクタを設定するための6つの設定枠A111−1,A111−2,A111−3,A111−4,A111−5,A112が設けられている。
野球ゲームXでは、野球ゲームXを初めてプレイする際に所定数のイベントキャラクタがユーザに付与される。また、ユーザは抽選によってイベントキャラクタを入手したり、ゲームにおける報酬としてイベントキャラクタを入手したり、他のユーザからイベントキャラクタを入手したりすることができる。イベントキャラクタはゲームカードの形式でユーザに付与され、ユーザはイベントキャラクタをゲームカードの形式で所有できる。野球ゲームXでは、ユーザ自身の所有しているイベントキャラクタや、他のユーザの所有しているイベントキャラクタをイベントデッキに組み込むことができる。
設定枠A111−1〜A111−5は、ユーザ自身の所有しているイベントキャラクタをイベントデッキのメンバとして任意に設定するための枠である。また、設定枠A112は、他のユーザの所有しているイベントキャラクタをイベントデッキのメンバとして任意に設定するための枠である。設定枠A111−1〜A111−5,A112には、ユーザによってイベントデッキに組み込まれたイベントキャラクタを示す画像が当該イベントキャラクタのレアリティやレベルとともに表示される。
ここで、「レアリティ」及び「レベル」について説明しておく。「レアリティ」は、例えばイベントキャラクタの入手し難さを示す。イベントキャラクタのレアリティが高いほど、そのイベントキャラクタを入手し難いことを示す。一般的に、イベントキャラクタのレアリティが高いほど、そのイベントキャラクタの有用性(能力や効果等)は高くなるため、「レアリティ」はイベントキャラクタの有用性も示している。
図4に示す例では、イベントキャラクタの画像の上側に表示された「R」,「SR」,「N」,「PSR」がイベントキャラクタのレアリティを示す。野球ゲームXでは、PSR(パワフルスーパーレア),SR(スーパーレア),PR(パワフルレア),R(レア),PN(パワフルノーマル),N(ノーマル)の複数段階のレアリティのいずれかが各イベントキャラクタに関連付けられる。なお、これらを高いものから順に並べると、PSR,SR,PR,R,PN,Nとなる。同じイベントキャラクタ(同じ名前のイベントキャラクタであり、同じ見た目(画像)のイベントキャラクタ)でもレアリティの異なるものが存在し得る。
「レベル」はイベントキャラクタのレベルを示す。図4に示す例では、イベントキャラクタの画像の下側に表示された「Lv.8」,「Lv.5」,「Lv.10」,「Iv.3」がイベントキャラクタのレベルを示す。例えば、イベントキャラクタに他のイベントキャラクタを合成することによって、イベントキャラクタに経験値が付与される。そして、イベントキャラクタの経験値が所定値に達すると、イベントキャラクタのレベルが1つ上昇する。
ユーザが設定枠A111−1〜A111−5のいずれかを選択すると(例えば、設定枠A111−1〜A111−5のいずれかに対してタップ操作(短い時間だけタッチする操作)を行うと)、当該設定枠に設定するイベントキャラクタを選択するための画面画像であるイベントキャラクタ選択画像が表示部35に表示される。
図5はイベントキャラクタ選択画像の一例を示す。イベントキャラクタ選択画像G120は、ユーザの所有しているイベントキャラクタのリストを示す。なお、イベントキャラクタ選択画像G120は要素P121を含む。要素P121には、イベントデッキ設定画像G110に戻るための処理が関連付けられている。このため、ユーザが要素P121を選択すると、イベントデッキ設定画像G110が表示部35に表示される。
イベントキャラクタ選択画像G120は、設定枠を空き状態(いずれのイベントキャラクタも設定されていない状態)にするための要素P122と、ユーザの所有しているイベントキャラクタにそれぞれ対応する要素P123−1〜P123−9とを含む。要素P123−1〜P123−9の各々は、イベントキャラクタの画像、レアリティ、及びレベルを示す。なお、すでにイベントデッキに組み込まれているイベントキャラクタに関しては、「使用中」とのテキスト(又は画像)が表示され、同じイベントキャラクタを重複してイベントデッキに組み込むことはできないようになっている。
ユーザが要素P123−1〜P123−9のいずれかに対して長押し操作(所定時間以上にわたってタッチし続ける操作)を行うと、当該要素に対応するイベントキャラクタの情報を示す画面画像であるイベントキャラクタ情報画像が表示部35に表示される。
図6は、イベントキャラクタ情報画像の一例を示す。図6に示すように、イベントキャラクタ情報画像G130の領域A131には、イベントキャラクタの名前、画像、レアリティ、レベル、選手能力、得意練習が表示される。
「選手能力」はイベントキャラクタの選手としての能力を示す。育成フェーズPH11(シナリオ)では試合イベントが発生し、主人公キャラクタの属する高校と他の高校との試合が行われる。この試合には、イベントデッキに組み込まれたイベントキャラクタが主人公キャラクタのチームメイトとして試合に参加する。「選手能力」は、このような試合でイベントキャラクタが発揮し得る能力の高さを示す。「選手能力」は数値及びアルファベットによって示される。数値が高いほど、選手能力が高いことを示す。アルファベット(例えばS,A,B,C,D,E,F,G)は選手能力の高さのレベルを示す。「S」は選手能力が非常に高いことを示し、「F」は選手能力が非常に低いことを示す。なお、ユーザがイベントキャラクタ情報画像G130の要素P133を選択すると、イベントキャラクタの選手能力の詳細を示す画面画像が表示部35に表示される。
「得意練習」はイベントキャラクタの得意な練習を示す。野球ゲームXでは、「打撃」、「筋力」、「走塁」、「肩力」、「守備」、「メンタル」、「球速」、「コントロール」、「スタミナ」、「変化球」の10種類の練習のうちのいずれかがイベントキャラクタの得意練習として設定される。育成フェーズPH11(シナリオ)では、主人公キャラクタに練習を行わせることによって、主人公キャラクタの能力を上昇させることができる。特に、イベントデッキに組み込まれたイベントキャラクタの得意練習を主人公キャラクタに行わせることによって、通常の場合よりも主人公キャラクタの能力を大きく上昇させることができる場合がある。
図6に示すように、イベントキャラクタ情報画像G130の領域A132は、イベントキャラクタのイベントリスト、イベント効果、プロフィールを示す。領域A132はタブT134−1,T134−2,タブT134−3を含む。
タブT134−1はイベントキャラクタのイベントリストを示す。すなわち、イベントキャラクタがイベントデッキに組み込まれている場合に育成フェーズPH11で発生し得るイベントのリストを示す。また、タブT134−3はイベントキャラクタのプロフィールを示す。図6ではタブT143−2が主に表示されているが、ユーザはタブT134−1,T134−3を選択することによって、タブT134−2に替えて、タブT134−1,T134−3を表示させることができる。
タブT134−2はイベントキャラクタのイベント効果を示す。育成フェーズPH11では、イベントデッキに組み込まれているイベントキャラクタによって、主人公キャラクタの能力を上昇させるのに有利な効果が発生する。「イベント効果」は、イベントキャラクタがイベントデッキに組み込まれている場合に育成フェーズPH11で発生し得る効果である。タブT134−2は要素P135を含む。要素P135には、イベントキャラクタのイベント効果の詳細を示す画面画像を表示するための処理が関連付けられている。ユーザは要素P135を選択することによって、イベントキャラクタのイベント効果の内容を把握できる。
イベントキャラクタはイベント効果とともに応援効果も有する。詳細については後述するが、イベントキャラクタは協力プレイパートでも使用される。協力プレイパートでは、イベントキャラクタを、ユーザと協力して対戦相手と対戦する他のユーザを応援するための応援キャラクタとして使用でき、応援キャラクタとして使用されたイベントキャラクタによって、他のユーザにとって有利な効果が発生する。このため、「応援効果」は、協力プレイパートでイベントキャラクタが応援キャラクタとして使用された場合に発生し得る効果である。タブT134−2は要素P136も含む。要素P136には、イベントキャラクタの応援効果の詳細を示す画面画像を表示するための処理が関連付けられている。ユーザは要素P136を選択することによって、イベントキャラクタの応援効果の内容を把握できる(後述の図11参照)。
図5に示したイベントキャラクタ選択画像G120において、ユーザが要素P123−1〜P123−9のいずれかに対してタップ操作を行うと、当該要素に対応するイベントキャラクタが設定枠に割り当てられる。なお、ユーザが要素P121を選択すると、設定枠が空き状態に設定される。
以上のようにして、ユーザはイベントデッキ設定画像G110の設定枠A111−1〜A111−5にイベントキャラクタを設定する。また、ユーザがイベントデッキ設定画像G110の設定枠A112を選択すると、他のユーザの所有しているイベントキャラクタのうちから助っ人を選択するための画像(画面画像)が表示部35に表示される。そして、ユーザが他のユーザの所有しているイベントキャラクタのうちのいずれかを選択すると、当該イベントキャラクタが設定枠A112に設定される。
なお、イベントデッキ設定画像G110の領域A113は、イベントデッキに組み込まれたイベントキャラクタの得意練習を示す。また、要素P114は、設定枠A111−1〜A111−5,A112に対してイベントキャラクタを自動的に設定するためのものであり、要素P115は、イベントデッキの設定を完了するためのものである。ユーザが要素P115を選択すると、イベントデッキの設定が完了する。
図2に示すように、イベントデッキの設定が完了した場合、ゲームアイテムの選択が行われる(PH102)。野球ゲームXでは、ユーザは主人公キャラクタの能力を上昇するのに有利となるゲームアイテムを報酬として入手したり、他のユーザから入手したりすることができる。このフェーズでは、ユーザは自らの所有しているゲームアイテムのうちから、育成フェーズPH11で使用するゲームアイテムを選択する。
ゲームアイテムの選択が完了すると、育成フェーズが開始される(PH11)。図2に示すように、育成フェーズPH11ではシナリオが開始される。育成フェーズPH11では、ユーザが主人公キャラクタに行わせる行動(練習、休養、又は遊び等)を繰り返し選択することによってシナリオが進行していく。このシナリオでは、主人公キャラクタは高校の野球部に所属して、チームメイトと練習を積みながら、野球の大会に出場し、高校3年生の秋にプロ野球選手としてスカウトされることを目指す。なお、先述したように、シナリオには、イベントデッキに組み込まれたイベントキャラクタが登場し、当該イベントキャラクタに応じてイベントが発生する。
育成フェーズPH11では、ユーザの選択した行動に基づいて経験ポイントが主人公キャラクタに付与される。ユーザは経験ポイントを使用して主人公キャラクタの能力を向上させることができる。例えば、主人公キャラクタの基本能力を上昇させたり、主人公キャラクタに特殊能力を修得させたりすることができる。育成フェーズPH11では投手又は野手の選手キャラクタを作成できる。
シナリオが最後まで進行すると、主人公キャラクタの育成が完了する。育成が完了した主人公キャラクタはオリジナルキャラクタとして登録される(PH12)。この場合、育成が完了した主人公キャラクタをオリジナルキャラクタとして登録するための画面画像であるオリジナルキャラクタ登録画像が表示部35に表示される。
図7はオリジナルキャラクタ登録画像の一例を示す。オリジナルキャラクタ登録画像G140には、育成が完了した主人公キャラクタの情報が表示される。例えば、オリジナルキャラクタ登録画像G140の要素P141,P142は、育成が完了した主人公キャラクタの画像、名前、ポジション、打撃フォーム、及び利き腕を示す。
要素P143は、育成が完了した主人公キャラクタの基本能力パラメータを示す。図7に示す例では、弾道、ミート、パワー、走力、肩力、守備力、捕球パラメータが示されており、各基本能力パラメータごとに数値及びアルファベットが示されている。数値は基本能力パラメータの値を示し、アルファベット(例えば、S,A,B,C,D,E,F,G)は基本能力の高さのレベル(段階)を示す。「S」は基本能力が非常に高いことを示し、「G」は基本能力が非常に低いことを示す。
なお、弾道パラメータは打球がどの程度高く上がるのかを示す。ミートパラメータはミート力(投手が投げたボールにバットを当てる能力)を示す。パワーパラメータはパワー(投手が投げたボールをバットで打つことによって遠くに飛ばす能力)を示す。走力パラメータは足の速さを示す。肩力パラメータは送球の速さを示す。守備力パラメータは守備の巧さを示す。
要素P144は、育成が完了した主人公キャラクタが修得した特殊能力を示す。図7に示す例では、特殊能力として、「チャンス◎」、「対左投手○」、「盗塁○」が示されており。「◎」及び「○」は特殊能力の高さの程度を示しており、「◎」は「○」よりも特殊能力の高さの程度が高いことを示している。
なお、「チャンス◎」は、チャンスに非常に強いという特殊能力である。オリジナルキャラクタが「チャンス◎」を修得していると、チャンスの際にオリジナルキャラクタの基本能力が大きく上昇する。「対左投手○」は、左投手に強いという特殊能力である。オリジナルキャラクタが「対左投手○」を修得していると、対戦相手の投手が左投手である際にオリジナルキャラクタの基本能力が高くなる。「盗塁○」は、盗塁に成功し易くなるという特殊能力である。オリジナルキャラクタが「盗塁○」を修得していると、オリジナルキャラクタが盗塁に成功し易くなる。
また、オリジナルキャラクタ登録画像G140は要素P145を含む。要素P145には、育成が完了した主人公キャラクタをオリジナルキャラクタとして登録するための処理が関連付けられている。このため、ユーザが要素P145を選択すると、育成が完了した主人公キャラクタがオリジナルキャラクタとして登録される。後述するように、登録されたオリジナルキャラクタは協力プレイパートで使用することが可能になる。なお、一人プレイパートの終了後、再度、最初から一人プレイパートを開始することによって、別の主人公キャラクタを育成する(すなわち、別のオリジナルキャラクタを生成する)ことができる。
[2−2]次に、協力プレイパートについて説明する。協力プレイパートでは、ユーザは他のユーザと協力して対戦相手と対戦して勝利することを目指す。
図8は、協力プレイパートのフローの一例を示す。図8に示すように、協力プレイパートでは、プレフェーズPH20が実行された後、試合フェーズPH21が実行される。プレフェーズPH20では試合フェーズPH21のために必要な処理が実行される。
図8に示すように、プレフェーズPH20では、まず、選手キャラクタの設定が行われる(PH200)。この場合、選手キャラクタの設定を行うための画面画像である選手キャラクタ設定画像が表示部35に表示される。
図9は選手キャラクタ設定画像の一例を示す。図9に示すように、選手キャラクタ設定画像G150は、野球の各ポジションにそれぞれ対応する設定枠A151−1〜A151−12を含む。ユーザは設定枠A151−1〜A151−12の各々に対してユーザ自身の所有しているオリジナルキャラクタを設定することによって、野球の各ポジションの選手キャラクタをユーザ自身の所有しているオリジナルキャラクタのうちから選択する。後述するように、ユーザが他のユーザと協力して対戦相手と対戦する際には、選手キャラクタ設定画像G150で設定された選手キャラクタを用いてオーダーが設定される。このため、選手キャラクタ設定画像G150で設定される選手キャラクタは、対戦相手との試合に出場する候補の選手キャラクタということができる。
選手キャラクタ設定画像G150は要素P152,P153を含む。要素P152には、設定枠A151−1〜A151−12の各々に対してオリジナルキャラクタを自動的に設定するための処理が関連付けられている。このため、ユーザが要素P152を選択すると、ユーザ自身の所有しているオリジナルキャラクタのポジションや能力パラメータ等に基づいて、設定枠A151−1〜A151−12の各々に対してオリジナルキャラクタが自動的に設定される。要素P153には、選手キャラクタの設定を完了するための処理が関連付けられている。このため、ユーザが要素P153を選択すると、選手キャラクタの設定が完了する。
図8に示すように、選手キャラクタの設定の完了後、応援キャラクタの設定が行われる(PH201)。
ここで、「応援キャラクタ」について説明しておく。後述するように、試合フェーズPH21では、基本的に、ユーザが操作(攻撃時の打撃操作・走塁操作又は守備時の投球操作・守備操作)を行うことなく試合が自動的に進行する(自動進行パート)。そして、試合状況が所定状況になった場合に限って、選手キャラクタを操作することが可能な機会がユーザに提供される(アクションパート)。野球ゲームXではイベントキャラクタに応援効果も設定されており、イベントキャラクタを応援キャラクタとして使用することも可能である。応援キャラクタはアクションパートで使用され、アクションパートでは、使用された応援キャラクタによって応援効果が発生する。「応援効果」は、アクションパートで良好な結果を出すのに有利な効果(言い換えれば、対戦相手に勝利するのに有利な効果)である。詳細については後述する(後述の図11参照)。
応援キャラクタの設定を行う際には、ユーザ自身の所有しているイベントキャラクタを応援キャラクタとして設定するための画面画像である応援キャラクタ設定画像が表示部35に表示される。図10は応援キャラクタ設定画像の一例を示す。図10に示すように、応援キャラクタ設定画像G160は、イベントキャラクタを応援キャラクタとして設定するための3つの設定枠A161−1〜A161−3を含む。
設定枠A161−1〜A161−3の各々には、レアリティに関する制限条件が関連付けられている。図10に示す例では、設定枠A161−1〜A161−3には、それぞれ、「PSR以下」、「SR以下」、「R以下」が制限条件として設定されている。このため、ユーザは、レアリティが「PSR」以下であるイベントキャラクタを設定枠A161−1に設定できるが、設定枠A161−2には、レアリティが「SR」以下であるイベントキャラクタしか設定できず、設定枠A161−3には、レアリティが「R」以下であるイベントキャラクタしか設定できない。
ユーザが設定枠A161−1〜A161−3のいずれかを選択すると(例えば、ユーザが設定枠A161−1〜A161−3のいずれかに対してタップ操作を行うと)、当該設定枠に設定する応援キャラクタをユーザ自身の所有しているイベントキャラクタのうちから選択するための画面画像であるイベントキャラクタ選択画像が表示部35に表示される。
このイベントキャラクタ選択画像は図5に示したイベントキャラクタ選択画像G120と同様である。ただし、この場合のイベントキャラクタ選択画像G120では、設定枠の制限条件を満足しないイベントキャラクタを選択できないようになる。例えば、設定枠A161−2がユーザによって選択された場合には、レアリティが「SR」よりも高いイベントキャラクタが選択不可の状態(例えばグレーアウトの状態又は非アクティブの状態等)で表示される。または、レアリティが「SR」よりも高いイベントキャラクタが表示されない。あるいは、レアリティが「SR」よりも高いイベントキャラクタが選択された場合にはエラーメッセージが表示される。
例えば、ユーザは設定枠A161−2を選択し、かつ、イベントキャラクタ選択画像G120の要素P123−1〜P123−9のうちの、レアリティが「SR」以下のイベントキャラクタのうちのいずれかに対応する要素に対してタップ操作を行うことによって、イベントキャラクタを応援キャラクタとして設定枠A161−2に設定できる。
先述したように、イベントキャラクタ選択画像G120の要素P123−1〜P123−9のうちのいずれかに対して長押し操作を行うと、イベントキャラクタ情報画像G130が表示される。この場合、ユーザはイベントキャラクタ情報画像G130の要素P136を選択することによって、イベントキャラクタの応援効果を把握できる。
図11は、要素P136が選択された場合に表示部35に表示される画面画像である応援効果情報画像の一例を示す。図11に示す応援効果情報画像G170は、イベントキャラクタが応援効果として「ミート+1」、「パワー+2」、「ピンチ○無効」、及び「ピストル打線」を有している場合を示している。これらの応援効果の詳細については後述する。なお、ユーザが応援効果情報画像G170の要素P171を選択すると、イベントキャラクタ情報画像G130に戻る。
なお、イベントデッキ設定画像G110の要素P114と同様に、応援キャラクタ設定画像G160も、設定枠A161−1〜A161−3の各々に応援キャラクタを自動的に設定するための要素を含むようにしてもよい。この要素が選択された場合には、設定枠A161−1〜A161−3の各々に設定する応援キャラクタとして、制限条件(レアリティ条件)を満足するイベントキャラクタのうちから、応援効果が最も高いイベントキャラクタ(又はレアリティ・レベルが最も高いイベントキャラクタ)が自動的に設定されるようにしてもよい。
図10に示すように、応援キャラクタ設定画像G160は要素P162を含む。要素P162には、応援キャラクタの設定を完了するための処理が関連付けられている。このため、ユーザが要素P162を選択すると、応援キャラクタの設定が完了する。
図8に示すように、応援キャラクタの設定の完了後、ユーザは他のユーザと協力して対戦相手と対戦するために、チームを作成するか、他のユーザによって作成されたチームに参加する必要がある(PH202,PH204)。
まず、チームを作成する場合について説明する。ここでは、ユーザU1が他のユーザと協力して対戦相手と対戦すべく、チームを作成する場合を想定する。
この場合、ユーザU1がホストとなってチームが作成され(PH202)、当該チームへの参加を他のユーザから受け付ける(PH203)。この場合、チームへの参加を希望する他のユーザが現れるのを待つための画面画像である待受画像がユーザU1のゲーム端末30−1の表示部35に表示される。なお、「ホスト」とは、チームを作成したユーザのことを示している。
図12はこの場合の待受画像G180の一例を示す。待受画像G180の要素P181はチームの対戦レベルを示す。図12に示す例では、チームの対戦レベルが「0」に設定されている。試合フェーズPH21では、対戦レベルが高いほど、対戦相手が強くなる。野球ゲームXでは対戦相手に勝利することによってユーザの対戦レベルが上がる。チームの対戦レベルは、ホストであるユーザU1の対戦レベルに合わせて設定され、他のユーザは自らの対戦レベル以下のチームに参加できる。
例えば、ユーザU1の対戦レベルは「0」に初期設定される。この状態でユーザU1がチームを作成すると、図12に示す例のように、チームの対戦レベルが「0」に設定される。ユーザU1が他のユーザと協力して対戦レベル「0」の対戦相手に勝利すると、ユーザU1の対戦レベルが「1」に更新される。この場合、ユーザU1は対戦レベル「1」のチームに参加できるようになる。また、その状態でユーザU1がチームを作成すると、チームの対戦レベルが「1」に設定される。
待受画像G180のホスト領域A182は、チームのホストであるユーザU1の情報を示す。図12に示す例ではユーザU1の名称のみが表示されているが、名称以外の情報が表示されるようにしてもよい。また、待受画像G180の参加者領域A183−1,A183−2は、それぞれ、チームへの参加申込みの受付状況を示す。例えば、チームへの参加申込みを受け付けている状態(すなわち、チームへの参加を希望する他のユーザが現れるのを待っている状態)では「受付中」と表示される。また例えば、チームへの参加申込みを他のユーザから受け付けた場合、当該他のユーザの情報が表示される。
野球ゲームXでは最大3名のユーザでチームを組むため、チームへの参加申込みの受付状況を示す領域が2つ設けられている。ただし、チームの上限人数は3名に限られず、4名以上のユーザでチームを組むことができるようにしてもよいし、2名のユーザでチームを組むことができるようにしてもよい。
また、待受画像G180は要素P184を含む。要素P184には、助っ人要請を行うための処理が関連付けられている。「助っ人要請」とは、ユーザU1よりも対戦レベルの高い他のユーザに対してチームへの参加を積極的に求めるものである。後述するように、野球ゲームXでは、チームに参加したユーザに対して対戦相手との対戦後に報酬(貢献ポイント)が付与されるが、助っ人要請に応じてチームに参加した場合には、通常の参加者として参加した場合に比べて報酬が多くなり、その分、ホストであるユーザU1の報酬が減るようになっている。このため、「助っ人要請」は、ホストであるユーザU1が自分の報酬を減るのと引き換えにして、自分よりも対戦レベルの高い他のユーザに対してチームへの参加を求める機能である。なお以下では、助っ人要請に応じてチームに参加したユーザを「助っ人参加者」と記載し、通常の参加者を「通常参加者」と記載する。
ユーザU1は要素P184を選択することによって、助っ人要請を行うことができる。ユーザU1が要素P184を選択すると、チームへの助っ人参加申込み(助っ人参加者として参加することを申込むこと)の受付が開始される。この場合、要素P184は選択不可の状態(例えばグレーアウトの状態又は非アクティブの状態等)に変わる(後述の図17参照)。なお、要素P184を選択不可の状態に変えるのではなく、助っ人要請を取り消すためのものに要素P184を変えてもよい。そして、この要素P184が選択された場合には、チームへの助っ人参加申込みの受付が中止されるようにしてもよい。
次に、他のユーザによって作成されたチームに通常参加者として参加する場合について説明する。ここでは、ユーザU2が他のユーザと協力して対戦相手と対戦すべく、他のユーザによって作成されたチームに通常参加者として参加する場合を想定する。
この場合、ユーザU2は他のユーザによって作成されたチームのうちから所望のチームを選択して(PH204)、当該チームへの参加を申し込む(PH205)。
まず、ユーザU2はチームリスト画像をゲーム端末30−2の表示部35に表示させるための操作を行う。チームリスト画像は、ユーザU2が参加可能なチームのリストを示す画面画像である。図13はチームリスト画像の一例を示す。例えば、ユーザU2の対戦レベルが「0」である場合、ユーザU2が参加可能なチームは対戦レベル「0」のチームであるため、図13に示す例のように、対戦レベル「0」のチームのリストがチームリスト画像G190に表示される。図13に示すチームリスト画像G190では、各チームにそれぞれ対応する要素P191−1,P191−2,P191−3,P191−4が表示されている。要素P191−1〜P191−4は、それぞれ、チームのホストであるユーザの情報やチームへの参加受付状況を示している。
ユーザU2が要素P191−1〜P191−4のいずれかを選択すると(例えば、要素P191−1〜P191−4のいずれかに対してタップ操作を行うと)、当該要素に対応するチームへの参加を申込むための画面画像である参加申込画像がユーザU2のゲーム端末30−2の表示部35に表示される。図14は参加申込画像の一例を示す。図14に示す参加申込画像G200は、チームリスト画像G190に表示されるチームのうちから、ホストがユーザU1であるチームがユーザU2によって選択された場合を示す。
参加申込画像G200の要素P201、ホスト領域A202、及び参加者領域A203−1,A203−2は、図12に示す待受画像G180の要素P181、ホスト領域A182、及び参加者領域A183−1,A183−2と同様である。
参加申込画像G200は要素P204,P205を含む。ユーザU2が要素P204を選択すると、参加申込画像G200からチームリスト画像G190へと遷移し、ユーザU2はチームを選択し直すことができる。
要素P205には、通常参加者としてチームに参加することを申し込むための処理が関連付けられている。このため、ユーザU2が要素P205を選択すると、ユーザU2が通常参加者として登録される。ユーザU2が通常参加者として登録されると、図12に示した待受画像G180と同様の待受画像がユーザU2のゲーム端末30−2の表示部35に表示される。この場合、ユーザU2の情報が参加者領域A183−1に表示される。またこの場合、ユーザU2から参加申込みを受け付けたことがユーザU1に通知される。すなわち、ユーザU1のゲーム端末30−1の表示部35に表示されている待受画像G180も更新され、ユーザU2の情報が参加者領域A183−2に表示される。
次に、他のユーザによって作成されたチームに助っ人参加者として参加する場合について説明する。ここでは、ユーザU3が他のユーザによって作成されたチームに助っ人参加者として参加する場合を想定する。
この場合、ユーザU3は、助っ人要請がなされているチームのうちから所望のチームを選択して(PH204)、当該チームへの参加を申し込む(PH205)。
まず、ユーザU3は助っ人要請リスト画像をゲーム端末30−3の表示部35に表示させるための操作を行う。助っ人要請リスト画像は、ユーザU3が応えることが可能な助っ人要請のリスト(言い換えれば、ユーザU3が助っ人要請参加者として参加可能なチームのリスト)を示す画面画像である。図15は助っ人要請リスト画像の一例を示す。ユーザU3は自分の対戦レベルよりも低い対戦レベルのチームに助っ人参加者として参加できるため、例えば、ユーザU3の対戦レベルが「1」である場合、ユーザU3が助っ人参加者として参加可能なチームは対戦レベル「0」のチームである。このため、図15に示す例のように、助っ人要請がなされているチームのうちの、対戦レベル「0」のチームのリストが助っ人要請リスト画像G210に表示される。図15に示す助っ人要請リスト画像G210では、各チームにそれぞれ対応する要素P211−1,P211−2が表示されている。要素P211−1,P211−2は、それぞれ、チームのホストであるユーザの情報やチームへの参加受付状況を示している。
ユーザU3が助っ人要請リスト画像G210の要素P211−1,P211−2のいずれかを選択すると(例えば、要素P211−1,P211−2のいずれかに対してタップ操作を行うと)、当該要素に対応するチームに助っ人参加者として参加することを申込むための画面画像である助っ人参加申込画像がユーザU3のゲーム端末30−3の表示部35に表示される。図16は助っ人参加申込画像の一例を示す。図16に示す助っ人参加申込画像G220は、助っ人要請リスト画像G210に表示されるチームのうちから、ホストがユーザU1であるチームがユーザU3によって選択された場合を示す。
助っ人参加申込画像G220の要素P221、ホスト領域A222、参加者領域A223−1,A223−2は、図12に示す待受画像G180の要素P181、ホスト領域A182、参加者領域A183−1,A183−2と同様である。
助っ人参加申込画像G220は要素P224,P225を含む。ユーザU3が要素P224を選択すると、助っ人参加申込画像G220から助っ人要請リスト画像G210へと遷移し、ユーザU3はチームを選択し直すことができる。
要素P225には、助っ人参加者としてチームに参加することを申し込むための処理が関連付けられている。このため、ユーザU3が要素P225を選択すると、ユーザU3が助っ人参加者として登録される。ユーザU3が助っ人参加者として登録されると、図12に示した待受画像G180と同様の待受画像がユーザU3のゲーム端末30−3の表示部35に表示される。この場合、ユーザU3の情報が領域A183−2に表示される。またこの場合、ユーザU3から参加申込みを受け付けたことがユーザU1(チームのホスト)やユーザU2(他の参加者)に通知される。すなわち、ユーザU1のゲーム端末30−1やユーザU2のゲーム端末30−2の表示部35に表示されている待受画像G180も更新され、ユーザU3の情報が参加者領域A183−3に表示される。
図17は、この場合にユーザU1のゲーム端末30−1の表示部35に表示される待受画像G180の一例を示す。図17に示す待受画像G180では、参加者であるユーザU2,U3の情報がそれぞれ参加者領域A183−1,A183−2に表示されている。ユーザU3は助っ人参加者であるため、その旨が参加者領域A183−2に表示されている。なお、この場合、すべての参加者が決まり、これ以上、このチームへの参加申込みを受け付けることができないため、このチームはチームリスト画像G190や助っ人要請リスト画像G210に表示されなくなる。
図12,17に示すように、待受画像G180は要素P185を含む。要素P185は、ユーザU1〜U3と対戦相手(CPU)との対戦を開始するための処理が関連付けられている。このため、ユーザU1が要素P185を選択すると、ユーザU1〜U3と対戦相手との対戦を開始するための処理が実行される。
具体的には、オーダーの設定・確認が実行される(PH206)。まず、ユーザU1〜U3のチーム(ユーザチーム)のスターティングオーダー及び控え選手が決定される。例えば、ユーザU1〜U3の各々が所有するオリジナルキャラクタを用いて、ユーザチームのスターティングオーダー及び控え選手が決定される。具体的には、ユーザU1によって選手キャラクタ設定画像G150で選手キャラクタとして設定されたオリジナルキャラクタと、ユーザU2によって選手キャラクタ設定画像G150で選手キャラクタとして設定されたオリジナルキャラクタと、ユーザU3によって選手キャラクタ設定画像G150で選手キャラクタとして設定されたオリジナルキャラクタとのうちから、ユーザチームのスターティングオーダー及び控え選手が自動的に選出される。なおこの場合、ユーザU1の所有するオリジナルキャラクタと、ユーザU2の所有するオリジナルキャラクタと、ユーザU3の所有するオリジナルキャラクタとから均等に選出される。また、対戦相手チーム(CPUチーム)のスターティングオーダー及び控え選手も決定される。対戦相手チームのスターティングオーダー及び控え選手はユーザチームの対戦レベルに合わせて決定される。
ユーザチーム及び対戦相手チームの各々のスターティングオーダー及び控え選手が決定された後、両チームのスターティングオーダーを示す画面画像であるオーダー確認画像がユーザU1〜U3の各々のゲーム端末30−1〜30−3の表示部35に表示される。図18はオーダー確認画像の一例を示す。図18は、ユーザU1のゲーム端末30−1の表示部35に表示されるオーダー確認画像G230の一例を示す。
図18に示すように、オーダー確認画像G230はホスト領域A231を含む。ホスト領域A231には、チームのホストであるユーザU1に関連する情報や要素等が表示される。なお、ユーザU1によって入力(選択)されたメッセージをホスト領域A231に表示するようにしてもよい。
また、オーダー確認画像G230は参加者領域A232−1,A232−2を含む。参加者領域A232−1,A232−2には、それぞれ、チームへの参加者であるユーザU2,U3に関連する情報や要素等が表示される。なお、ユーザU2,U3によって入力(選択)されたメッセージを参加者領域A232−1,A232−2にそれぞれ表示するようにしてもよい。
また、オーダー確認画像G230の要素P233は、ユーザチーム及び対戦相手チームの各々のスターティングオーダーを示す。また、要素P234は、ユーザチームの勢いポイントと対戦相手チームの勢いポイントとの間の比較(大小,高低)を示す。「勢いポイント」はユーザチーム又は対戦相手チームの勢いを示す。
ユーザチームの場合、勢いポイントがユーザU1〜U3の各々ごとに算出される。例えば、ユーザU1の勢いポイントの初期値は、ユーザチームの選手キャラクタのうちの、ユーザU1の所有する選手キャラクタの能力に基づいて算出される。選手キャラクタの能力が高いほど、勢いポイントの初期値は大きくなる。ユーザU2,U3の各々の勢いポイントの初期値も同様にして算出される。そして、このようにして算出されたユーザU1〜U3の各々の勢いポイントの初期値を合計することによって、ユーザチームの勢いポイントの初期値が算出される。
ユーザU1の勢いポイントは、アクションパートにおけるユーザU1のプレイ結果に基づいて増加される。例えば、ユーザU1が操作した選手キャラクタの活躍の程度に応じて、ユーザU1の勢いポイントが増加される。例えば、ユーザU1がアクションパートで打者キャラクタを操作する場合であれば、当該打者キャラクタが安打を打ったり、打点をあげたりすることによって、ユーザU1の勢いポイントが増加される。また例えば、ユーザU1がアクションパートで投手キャラクタを操作する場合であれば、当該投手キャラクタが打者キャラクタを三振に抑えることによって、ユーザU1の勢いポイントが増加される。なお、ユーザU1の勢いポイントが増加される結果としてユーザチームの勢いポイントも増加される。
同様に、ユーザU2,U3の各々の勢いポイントは、それぞれ、アクションパートにおけるユーザU2,U3のプレイ結果に基づいて上昇する。また、ユーザU2,U3の勢いポイントが増加される結果としてユーザチームの勢いポイントも増加される。
なお、以上のようにしてユーザU1〜U3の各々の勢いポイントは設定・更新されるため、ユーザU1〜U3の各々の勢いポイントはユーザU1〜U3の各々の試合への貢献度を示している。
オーダー確認画像G230の要素P234は、棒状の要素P234−1と、ユーザチームの勢いポイントを示す要素P234−2と、対戦相手チーム(CPUチーム)の勢いポイントを示す要素P234−3とを含む。要素P234−2内に表示された数値(25000)はユーザチームの勢いポイントを示し、要素P234−3内に表示された数値(25800)は対戦相手チームの勢いポイントを示す。図18に示す例では右方向に行くほど勢いポイントが大きいことを示している。また、要素P234−2は、要素P234−1上の、ユーザチームの勢いポイントの値に対応する位置と関連付けて表示され、要素P234−3は、要素P234−1上の、対戦相手チームの勢いポイントの値に対応する位置と関連付けて表示される。ユーザは要素P234−2と要素P234−3との位置を比較することによって、一見して、ユーザチームと対戦相手チームとの間の勢いポイントの大小(高低)を把握できる。
なお、要素P234−2は、ユーザU1〜U3の各々に対応する要素P234−4,P234−5,P234−6を含む。ユーザU1に対応する要素P234−4は矢印を含んでおり、当該矢印の長さは、ユーザチームの勢いポイントのうちの、ユーザU1の勢いポイントの占める割合を示す。同様に、ユーザU2に対応する要素P234−5も矢印を含んでおり、当該矢印の長さは、ユーザチームの勢いポイントのうちの、ユーザU2の勢いポイントの占める割合を示す。また、ユーザU3に対応する要素P234−6も矢印を含んでおり、当該矢印の長さは、ユーザチームの勢いポイントのうちの、ユーザU3の勢いポイントの示す割合を示す。このため、ユーザは他のユーザとの間の勢いポイントの大小(高低)を把握できる。
また、要素P234では、要素P234−1上の、報酬を獲得するために必要なポイントの量に対応する位置に関連付けて、要素P234−7,P234−8が表示される。ユーザチームの勢いポイントが要素P234−7,P234−8の示す量まで達すると、ユーザU1〜U3に報酬(例えばゲームアイテム、ゲームポイント(ゲーム貨幣)、イベントキャラクタ等)が付与される。
図18に示すオーダー確認画像G230では要素P235がホスト領域A231に表示されている。オーダーを確認した後でユーザU1は要素P235を選択する。なお、ユーザU2のゲーム端末30−2で表示されるオーダー確認画像G230では要素P235が参加者領域A232−1に表示され、ユーザU3のゲーム端末30−3で表示されるオーダー確認画像G230では要素P235が参加者領域A232−2に表示される。
ユーザU1〜U3のすべてがオーダーの確認を完了すると、プレフェーズPH20が完了し、図8に示すように、試合フェーズが開始される(PH21)。
試合フェーズPH21では、基本的に、ユーザが操作(打撃操作又は投球操作等)を行うことなく試合が自動的に進行する(自動進行パート)。そして、試合状況が所定状況になった場合に限って、選手キャラクタを操作することが可能な機会がユーザに提供される(アクションパート)。このように、試合フェーズPH21は自動進行パート及びアクションパートの2つのパートを含む。
自動進行パートでは、ユーザが操作(打撃操作又は投球操作等)を行うことなく、自動的に試合状況が更新されていく。言い換えれば、自動進行パートでは、ユーザチームに関するパラメータ(例えばユーザチームの選手キャラクタの能力パラメータ等)と、対戦相手チームに関するパラメータ(例えば対戦相手チームの選手キャラクタの能力パラメータ等)とに基づいて、試合経過がコンピュータによって自動的に生成(決定)される。自動進行パートでは、ユーザはコンピュータによって自動的に生成される試合経過を見ることになる。
一方、アクションパートは、ユーザが操作(打撃操作又は投球操作等)を行うパートである。すなわち、アクションパートでは、ユーザの操作に応じて選手キャラクタが動作を行う。攻撃時であれば、ユーザの操作(打撃操作等)に応じて選手キャラクタが打撃等を行い、守備時であれば、ユーザの操作(投球操作等)に応じて選手キャラクタが投球等を行う。このように、アクションパートでは、選手キャラクタに対するユーザの操作に基づいて試合状況が更新されていく。
先述のように、自動進行パートでは、ユーザが操作を行うことなく、試合が自動的に進行していく。また後述のように(図19参照)、自動進行パートでは試合経過の概要(試合のポイント)のみが表示部35に表示される。このようにして試合が進行することによって、一つの試合を完了するためにかかる時間が短縮される。例えば、ユーザが多忙である場合等、ユーザがゲームをプレイする時間として少ない時間しか確保できない場合がある。このため、ユーザがゲームをプレイする時間として少ない時間しか確保できない場合であっても、当該時間内に他のユーザと協力して一つの試合を完了できるようにすべく、上記のようにして、一つの試合を完了するためにかかる時間を短縮している。
図19は、自動進行パート中にゲーム端末30−1〜30−3の各々の表示部35に表示される画面画像である自動進行パート画像の一例を示す。図19に示す自動進行パート画像G240は、2回表にユーザチームが攻撃を行っている状態を示している。
図19に示すように、自動進行パート画像G240はホスト領域A241と参加者領域A242−1,A242−2とを含む。これらはオーダー確認画像G230のホスト領域A231、参加者領域A232−1,A232−2と同様である。
また、自動進行パート画像G240は要素P243,P244,P245,P246,P247,P248を含む。これらは試合状況の概要を示す。
例えば、要素P243は試合経過を表すスコアボードを示す。要素P244はスコアボード(要素P243)に関連付けて表示され、現在のイニングの一つ前のイニングにおける出来事を示す。図19では、現在のイニングが「2回表」であるため、要素P244は「1回裏」での出来事を示している。要素P245はユーザチーム及び対戦相手チーム(CPUチーム)の現在の得点を示し、要素P246は現在のイニング、出塁状況、ボールカウント、アウトカウント、及び得点を示す。要素P247は、現在打席に立っているユーザチームの選手キャラクタ(佐藤)と、これに続いて打席に立つことになるユーザチームの選手キャラクタ(高橋、鹿野)とを示し、要素P248は、現在投球を行っている対戦相手チームの選手キャラクタ(山田)を示す。
また、要素P249はユーザチーム及び対戦相手チームの勢いポイントを示す。要素P249はオーダー確認画像G230の要素P234と同様である。
自動進行パートでは、コンピュータが、仮想空間内において、ユーザチームに所属する選手キャラクタと対戦相手チームに所属する選手キャラクタとの両方を、それらの選手キャラクタの能力パラメータに基づいて仮想的に動作させることによって、試合経過が自動的に生成されていく。なお、コンピュータが、ユーザチームに関するパラメータと対戦相手チームに関するパラメータとを単に比較することによって、試合経過が自動的に生成されていくようにしてもよい。
また自動進行パートでは、以上のようにして自動的に生成される試合経過に応じて、自動進行パート画像G240の表示内容が更新されていく。すなわち、以上のようにして自動的に生成される試合経過に応じて、要素P243〜P248が更新されていく。ユーザU1〜U3は自動更新される要素P243〜P248を眺めながら、自動的に進行する試合の概要を見ることになる。
自動進行パート中に試合状況が所定状況になった場合に、自動進行パートからアクションパートに切り替わり、選手キャラクタに対する操作を行うことが可能な操作機会がユーザに提供される。ここで、「所定状況」とは、例えば、ユーザチームにとって得点チャンスの状況(例えば、ユーザチームの攻撃時で走者がいる状況)、ユーザチームにとって得点チャンスを作りやすい状況(例えば、ユーザチームの攻撃時でノーアウト・走者なしの状況)、又はユーザチームにとって失点ピンチの状況(例えば、対戦相手チームの攻撃時で三塁又は二塁に走者がいる状況)等である。なお、試合状況に関係なく、予め定められたタイミング(例えば3回、6回、9回の開始時等)で自動進行パートからアクションパートに切り替わるようにしてもよい。
一つの試合では予め定められた回数のアクションパートが設定される。図8に示す例では、時点T1,T3,T5で自動進行パートからアクションパートへの切り替えが行われている。すなわち、図8に示す例では一つの試合中に3回のアクションパートが設定されている。この場合、例えば、1回表〜3回裏の間で1回のアクションパートが提供され、4回表〜6回裏の間で1回のアクションパートが提供され、7回表〜9回裏の間で1回のアクションパートが提供される。なお、一つの試合におけるアクションパートの回数は上記例に限られず、2回以下であってもよいし、4回以上であってもよい。また、一つの試合におけるアクションパートの回数は固定でなくてもよく、試合毎に変化するようにしてもよい。アクションパートへの切替タイミングも上記例に限られない。
またアクションパートでは、原則として、いずれか1人のユーザが1打席分の操作を行う。例えば、ユーザチームの攻撃時にアクションパートに切り替わった場合、打者キャラクタの所有者であるユーザが当該打者キャラクタの操作(打撃操作)を行うことになる。そして、当該打者キャラクタの打席が終了すると、アクションパートも終了する。また例えば、ユーザチームの守備時にアクションパートに切り替わった場合、投手キャラクタの所有者であるユーザが当該投手キャラクタの操作(投球操作)を行うことになる。そして、対戦相手チームの1人の選手キャラクタの打席が終了すると、アクションパートも終了する。
図20は、アクションパートの開始時にゲーム端末30−1〜30−3の各々の表示部35に表示される画面画像であるアクションパート開始画像の一例を示す。図20に示すアクションパート開始画像G250は、ユーザチームの攻撃時であって、かつ、「3回表/ノーアウト/走者なし」の場面でアクションパートに切り替わった場合を示す。
図20に示すように、アクションパート開始画像G250はホスト領域A251と参加者領域A252−1,A252−2とを含む。これらはオーダー確認画像G230のホスト領域A231や参加者領域A232−1,A232−2と同様である。また、アクションパート開始画像G250は要素P253,P254,P255,P256を含む。これらは自動進行パート画像G240の要素P243〜P246と同様である。
アクションパート開始画像G250は要素P257,P258,P259を含む。要素P257は現在の場面を示す。要素P258は、今回のアクションパートでの主要操作者(主に操作を行うユーザ)を示す。図20に示す例の場合、ユーザU1の所有する選手キャラクタが打者キャラクタであり、今回のアクションパートでの主要操作者がユーザU1であることを要素P258は示している。要素P259は、今回のアクションパートで操作される打者キャラクタ(田中)や対戦相手の投手キャラクタ(山田)を示す。
アクションパート開始画像G250が表示された後、今回のアクションパートで使用する応援キャラクタを選択するための画面画像である応援キャラクタ選択画像がゲーム端末30−1〜30−3の各々の表示部35に表示され、今回のアクションパートで使用する応援キャラクタの選択をユーザU1〜U3の各々から受け付ける。
図21は応援キャラクタ選択画像の一例を示す。なお、図21は、ユーザU2のゲーム端末30−2の表示部35に表示される応援キャラクタ選択画像G260を示している。
図21に示すように、応援キャラクタ選択画像G260はホスト領域A261と参加者領域A262−1,A262−2とを含む。基本的に、これらはオーダー確認画像G230のホスト領域A231や参加者領域A232−1,A232−2と同様である。応援キャラクタ選択画像G260の場合、ホスト領域A231には、ホストであるユーザU1によって今回のアクションパートでの使用対象として選択された応援キャラクタの情報(画像や応援効果等)が表示される。同様に、参加者領域A232−1には、参加者であるユーザU2によって今回のアクションパートでの使用対象として選択された応援キャラクタの情報が表示される。また、参加者領域A232−2には、参加者であるユーザU3によって今回のアクションパートでの使用対象として選択された応援キャラクタの情報が表示される。図21に示す例では、ホスト領域A231及び参加者領域A232−2には、ユーザU1,U3によって使用対象として選択された応援キャラクタの情報が表示されており、参加者領域A232−1には、ユーザU2によって使用対象として選択された応援キャラクタの情報が表示されていないため、図21は、ユーザU1,U3による使用対象の応援キャラクタの選択が完了し、ユーザU2による使用対象の応援キャラクタの選択が完了していない状態を示している。
また、応援キャラクタ選択画像G260は要素P263を含む。要素P263は自動進行パート画像G240の要素P246と同様である。
さらに、応援キャラクタ選択画像G260には、ユーザ(図21に示す例ではユーザU2)によって予め設定されていた応援キャラクタのリストが表示される。ここで、「ユーザによって予め設定されていた応援キャラクタのリスト」とは、応援キャラクタ設定画像G160(すなわち、図8に示すフェーズPH201)で応援キャラクタとして設定されたイベントキャラクタのリストである。
図21に示す例では、ユーザU2によって予め設定されていた応援キャラクタにそれぞれ対応する要素P264−1,P264−2,P264−3が表示されている。要素P264−1〜P264−3の各々は、応援キャラクタとして設定されたイベントキャラクタの名称、レアリティ、及び画像とともに、当該イベントキャラクタの有する応援効果を示す。
図21に示す例では、要素P264−1に対応する応援キャラクタが応援効果として「ミート+1」、「パワー+2」、「ピンチ○無効」、及び「ピストル打線」を有している。
「ミート+1」は、ユーザチームの選手キャラクタのミートパラメータの値を1ポイント上げるという応援効果である。同様に、「パワー+2」は、ユーザチームの選手キャラクタのパワーパラメータの値を2ポイント上げるという応援効果である。
「ピンチ○無効」は、対戦相手チームの投手キャラクタが特殊能力「ピンチ○」を修得していたとしてもそれを無効にするという応援効果である。なお、「ピンチ○」はピンチに強いという投手用の特殊能力である。投手キャラクタが「ピンチ○」を修得していると、ピンチの際に当該投手キャラクタの基本能力が上昇するが、応援効果「ピンチ○無効」が発動すると、対戦相手チームの投手キャラクタが「ピンチ○」を修得していたとしても、ピンチの際に当該投手キャラクタの基本能力が上昇しなくなる。
「ピストル打線」は、連係アクション「ピストル打線」を発動させることが可能になるという応援効果である。連係アクション「ピストル打線」については後述する。
また図21に示す例では、要素P264−2に対応する応援キャラクタは応援効果として「ミート+1」、「パワー+1」、及び「盗塁援護」を有している。「パワー+1」は、ユーザチームの選手キャラクタのパワーパラメータの値を1ポイント上げるという応援効果である。「盗塁援護」は、連係アクション「盗塁援護」を発動させることが可能になるという応援効果である。連係アクション「盗塁援護」については後述する。
さらに図21に示す例では、要素P264−3に対応する応援キャラクタは応援効果として「球速+1」及び「制球+1」を有している。「球速+1」は、ユーザチームの投手キャラクタの球速パラメータの値を1ポイント上げるという応援効果である。「制球+1」は、ユーザチームの投手キャラクタの制球パラメータの値を1ポイント上げるという応援効果である。なお、これらの応援効果は、アクションパートがユーザチームの守備時である場合に有益なものである。このため、図20に示す例のように、ユーザチームの攻撃時には要素P264−3を選択できないようにしてもよい。
ここで、「連係アクション」について説明しておく。先述したように、原則として、各アクションパートは1打席分の操作に限られている。すなわち、各アクションパートでは、いずれか1人のユーザが1人の選手キャラクタ(打者キャラクタ又は投手キャラクタ)を操作することのみが可能である。しかしながら、連係アクションが発動すると、アクションパートで3打席連続して操作を行うことが可能になったり、攻撃時に走者がいる場面で打者キャラクタの操作と走者キャラクタの操作とを2人のユーザが分担して行うことが可能になったりする。
図22は連係アクション「ピストル打線」及び「盗塁援護」について説明するための図である。図22では、連係アクション「ピストル打線」及び「盗塁援護」の各々の発動条件、効果、ボーナス獲得条件、ボーナスポイントを示している。なお、連係アクションは図22に示したものに限られない。
まず、「ピストル打線」について説明する。図22に示すように、「ピストル打線」には発動条件が設定されていない。このため、「ピストル打線」はどのような場面でも発動することが可能である。
「ピストル打線」には効果として「3打席連続の操作が可能」が設定されている。このため、「ピストル打線」が発動すると、アクションパートで3打席連続の操作が可能になる。例えば、図20に示す場面はユーザU1の所有する選手キャラクタの打席の場面であるが(要素P258参照)、例えば、この次の打席がユーザU2の所有する選手キャラクタの打席であり、さらにその次の打席がユーザU3の所有する選手キャラクタの打席であるならば、ユーザU1〜U3の3人による3打席連続の操作が可能になる。
また、「ピストル打線」には、効果として、「ミート+3」、「連打○」、及び「アベレージヒッター」が設定されている。このため、「ピストル打線」が発動すると、ユーザチームの選手キャラクタのミートパラメータの値が3ポイント上がる。さらに、ユーザチームの選手キャラクタに特殊能力「連打○」及び「アベレージヒッター」が一時的に付与される。すなわち、ユーザチームの選手キャラクタが「連打○」及び「アベレージヒッター」を修得していなかったとしても、「ピストル打線」が発動すると、当該選手キャラクタが一時的に「連打○」及び「アベレージヒッター」を修得した状態になる。なお、「連打○」は、直前の打者がヒットを打った場合にヒットを打ち易くなるという特殊能力である。また、「アベレージヒッター」は、ヒットを打ち易くなるという特殊能力である。
さらに、「ピストル打線」には、ボーナス条件及びボーナスポイントとして、「2安打」及び「30ポイント」が設定されている。これは、「ピストル打線」が発動したアクションパートでのユーザチームの安打数が2安打以上になると、ユーザU1〜U3の各々の勢いポイントにボーナスポイント「30ポイント」が加算されることを示している。
次に、「盗塁援護」について説明する。図22に示すように、「盗塁援護」には発動条件が設定されており、「盗塁援護」は、一塁、二塁の少なくとも一方に走者がいる場合にのみ発動することが可能である。
「盗塁援護」には、効果として、「打者及び走者の操作が可能」、「走力+5」、及び「盗塁○」が設定されている。このため、「盗塁援護」が発動すると、アクションパートでは打者キャラクタだけでなく、走者キャラクタの操作も可能になる。例えば、ユーザU3の所有する選手キャラクタが打者であり、かつ、ユーザU2の所有する選手キャラクタが走者として一塁又は二塁にいる状態のアクションパートで「盗塁援護」が発動すると、ユーザU3が打者キャラクタを操作し、ユーザU2が走者キャラクタを操作することになる。また、「盗塁援護」が発動すると、ユーザチームの選手キャラクタの走力パラメータの値が5ポイント上がる。さらに、ユーザチームの選手キャラクタに特殊能力「盗塁○」が一時的に付与される。すなわち、ユーザチームの選手キャラクタが「盗塁○」を修得していなかったとしても、「盗塁援護」が発動すると、当該選手キャラクタが一時的に「盗塁○」を修得した状態になる。なお、「盗塁○」は、盗塁に成功し易くなるという特殊能力である。
さらに、「盗塁援護」には、ボーナス条件及びボーナスポイントとして、「打者が空振りして、走者が盗塁成功」及び「20ポイント」が設定されている。これは、「盗塁援護」が発動したアクションパートにおいて、走者キャラクタを援護すべく(言い換えれば、対戦相手チームの捕手キャラクタが送球し難くなるようにすべく)打者キャラクタが空振りして、走者キャラクタが盗塁に成功すると、ユーザU1〜U3の各々の勢いポイントにボーナスポイント「20ポイント」が加算されることを示している。
ユーザU1〜U3のすべてが応援キャラクタを選択した場合、ユーザU1〜U3によって選択された応援キャラクタのうちに、発動可能な連係アクションが設定された応援キャラクタが含まれていると、当該連係アクションを発動するか否かを選択するための画面画像である発動選択画像が、アクションパートでの主要操作者であるユーザのゲーム端末30の表示部35に表示される。なお、当該発動選択画像は、チームのホストであるユーザのゲーム端末30の表示部35に表示されるようにしてもよい。
図23は発動選択画像の一例を示す。図23に示すように、発動選択画像G270はホスト領域A271と参加者領域A272−1,A272−2とを含む。これらは応援キャラクタ選択画像G260のホスト領域A261や参加者領域A262−1,A262−2と同様である。また、発動選択画像G270は要素P273を含む。要素P273は自動進行パート画像G240の要素P246と同様である。
発動選択画像G270は要素P274,P275を含む。要素P274は発動可能な連係アクションを示し、要素P275は当該連係アクションを発動するか否かをユーザに問い合わせるメッセージを示す。また、発動選択画像G270は要素P276,P277を含む。要素P276には、連係アクションを発動させないための処理が関連付けられており、ユーザが要素P276を選択すると、連係アクションが発動されないようになる。一方、要素P277には、連係アクションを発動させるための処理が関連付けられており、ユーザが要素P277を選択すると、連係アクションが発動されるようになる。
なお、野球ゲームXでは、1回のアクションパートで発動できるのが1つの連係アクションに限られている。このため、ユーザU1〜U3によって選択された応援キャラクタのうちに、発動可能な連係アクションが設定された応援キャラクタが複数含まれている場合、発動選択画像G270ではどの連係アクションを発動させるのかの選択も行われる。
発動選択画像G270の要素P276,P277のいずれかが選択された場合、アクションパートが開始される。なお、ユーザU1〜U3によって選択された応援キャラクタのうちに、発動可能な連係アクションが設定された応援キャラクタが含まれていない場合には、発動選択画像G270が表示されることなく、アクションパートが開始される。
なお、以上に説明した態様では、すべてのユーザU1〜U3がそれぞれ応援キャラクタを選択できるようになっているが、アクションパートでの主要操作者であるユーザ以外のユーザのみが応援キャラクタを選択できるようにしてもよい。例えば、図20に示すアクションパートでの主要操作者はユーザU1であるため(要素P258参照)、ユーザU2,U3のみが応援キャラクタを選択できるようにし、ユーザU1は応援キャラクタを選択できないようにしてもよい。なお、チームのホストであるユーザ以外のユーザのみが応援キャラクタを選択できるようにしてもよい。
図24は、アクションパート中にユーザU1〜U3の各々のゲーム端末30の表示部35に表示される画面画像であるアクションパート画像の一例を示す。図24はユーザチームの攻撃時のアクションパート画像を示している。具体的には、図24は、打者キャラクタPC1に対する操作をユーザU1が行う場面を示している。
図24に示すように、アクションパート画像G280は要素P281,P282を含む。要素P281は自動進行パート画像G240の要素P246と同様である。要素P282は発動中の連係アクションを示す。なお、図24では省略しているが、打者キャラクタPC1や投手キャラクタPC2の名称・能力等を表示するようにしてもよい。
アクションパート画像G280には、ユーザU1の操作する打者キャラクタPC1や、対戦相手チームの投手キャラクタPC2が表示される。この場合、ユーザU1〜U3の各々によって選択された応援キャラクタの応援効果によって打者キャラクタPC1が向上されている。例えば、図24に示す例では、連係アクション「ピストル打線」が発動しているため、打者キャラクタPC1のミートパラメータの値が3ポイント上がっており、さらに、特殊能力「連打○」及び「アベレージヒッター」が打者キャラクタPC1に付与されている。
またアクションパート画像G280には、打者キャラクタPC1に打撃を行わせるための操作要素として、枠F及びミートカーソルMが表示される。枠Fはホームベース上に表示され、ストライクゾーンを示す。ミートカーソルMはユーザの移動指示操作に応じて移動し、打撃位置を示す。ユーザU1がスイング指示操作を行うと、打者キャラクタPC1がミートカーソルMによって示される打撃位置に向けてバットを振る。
投手キャラクタPC2が投げたボールBが枠Fを含む平面を通過するタイミング又はその近傍タイミングでユーザU1がスイング指示操作を行うと、ミートカーソルMとボールBとの位置関係に応じて、打者キャラクタPC1がボールBを打つ。例えば、ミートカーソルMがボールBに重なっていると、ボールBが打撃される。この場合、ミートカーソルMの芯MCがボールBに重なっていると強い打球が飛ぶ。一方、ミートカーソルMがボールBに重なっていないと空振りとなる。なお、枠Fを含む平面をボールBが通過するタイミングと離れたタイミングでスイング指示操作が行われた場合にも空振りとなる。
なお、図24ではユーザチームの攻撃時のアクションパート画像G280について示したが、ユーザチームの守備時には、投手キャラクタに対する操作をユーザが行うためのアクションパート画像G280が表示されることになる。
アクションパートは終了条件が満足された場合に終了する。通常、1つの打席が終了した場合にアクションパートは終了する。しかしながら、図24に示す例の場合、連係アクション「ピストル打線」が発動しているため、3つの打席が終了した場合にアクションパートが終了する。
アクションパートの終了時には、アクションパートの結果を示す画面画像であるアクションパート結果画像がユーザU1〜U3の各々のゲーム端末30の表示部35に表示される。図25はアクションパート結果画像の一例を示す。図25は、ユーザU1のゲーム端末30−1の表示部35に表示されるアクションパート結果画像G290を示す。
図25に示すように、アクションパート結果画像G290はホスト領域A291と参加者領域A292−1,A292−2とを含む。これらはオーダー確認画像G230のホスト領域A231や参加者領域A232−1,A232−2と同様である。
アクションパート結果画像G290の領域A293には、アクションパートでのプレイ結果に応じてユーザU1の勢いポイントに加算されるポイント量が表示される。図25に示す例では、アクションパートでのユーザU1個人のプレイ結果として50ポイントがユーザU1の勢いポイントに加算され、さらに、連係アクションのボーナス条件が満足されたことによって、ボーナスポイントとして60ポイントがユーザU1の勢いポイントに加算されたことを示している。そして、その結果として、ユーザU1の勢いポイントが8000ポイントから8110ポイントまで増えたことを示している。
また、アクションパート結果画像G290は要素P294を含む。要素P294はオーダー確認画像G230の要素P234と同様である。要素P294は要素P294−1,P294−2,P294−3,P294−4,P294−5,P294−6,P294−7,P294−8を含む。これらもオーダー確認画像G230のP234−1〜P234−8と同様である。
図25に示す例では、ユーザU1〜U3の各々の勢いポイントが増えたことによって、ユーザチームの勢いポイントが25280まで増えており、その結果として、要素P294−2内に表示されているユーザチームの勢いポイントの量や、要素P294−2の位置が更新されている。また、ユーザU1〜U3の各々の勢いポイントが更新されたことによって、要素P294−4,P294−5,P294−6の各々に含まれる矢印の長さも更新される。
アクションパートの終了後、自動進行パートが再開される。なお、勢いポイントの増加は自動進行パートに影響を及ぼす。すなわち、アクションパートの結果としてユーザチーム(ユーザU1〜U3)の勢いポイントが増加されると、その分、それ以降の自動進行パートでユーザチームが有利となる。例えば、ユーザU1の勢いポイントが増加されると、その分、ユーザU1の所有する選手キャラクタの能力が上昇する。同様に、ユーザU2,U3の各々の勢いポイントが増加されると、その分、ユーザU2,U3の各々の所有する選手キャラクタの能力が上昇する。そして、選手キャラクタの能力が上昇した状態で自動進行パートが進行する。また、自動進行パート中に試合状況が所定状況になると、再び自動進行パートからアクションパートに切り替わる。このようにして試合は進行していく。
図26は、図20に示すアクションパートよりも後のアクションパートの開始時に表示されるアクションパート開始画像G250を示す。図26に示すアクションパート開始画像G250は、ユーザチームの攻撃時であって、かつ、「5回表/ノーアウト/走者一塁」の場面でアクションパートに切り替わった場合を示す。
図26に示す例は、要素P258,P259によって示されているように、ユーザU3の所有する選手キャラクタ(中村)が打席に立つ場面であり、今回のアクションパートでの主要操作者がユーザU3である場面である。
図27は、上記のアクションパートの開始前に表示される応援キャラクタ選択画像G260を示す。図21と同様に、図27も、ユーザU2のゲーム端末30−2の表示部35に表示される応援キャラクタ選択画像G260を示している。
野球ゲームXでは、一つの試合中において、一度使用した応援キャラクタを再度使用できないようになっている。この点、要素P264−1に対応する応援キャラクタは使用済みであるため(図23参照)、図21と異なり、図27では、要素P264−1に対応する応援キャラクタを選択できないようになっている。
図28は、図27に示す応援キャラクタ選択画像G260で要素P264−2に対応する応援キャラクタ(香本)が選択された場合の発動選択画像G270を示す。上記の応援キャラクタ(香本)は応援効果として連係アクション「盗塁援護」を有しているため、図28に示す発動選択画像G270では、「盗塁援護」を発動するか否かの選択を受け付けるようになっている。先述したように、ユーザが要素P277を選択すると、アクションパートで「盗塁援護」が発動される。
「盗塁援護」が発動したアクションパートでは、打者及び走者の操作を2人のユーザが分担して行うことができる。例えば、図26に示す場面で一塁にいる走者キャラクタがユーザU2の所有する選手キャラクタである場合、本アクションパートでは、ユーザU3が打者キャラクタを操作し、ユーザU2が走者キャラクタを操作することになる。そして、この場合、ユーザU3によって操作される打者キャラクタが空振りすることによって走者キャラクタの盗塁を援護して、ユーザU2によって操作される走者キャラクタが盗塁に成功すると、ボーナス条件が満足されたことになる。
試合が終了した場合、試合結果を示す画面画像である試合結果画像がユーザU1〜U3のゲーム端末30−1〜30−3の各々の表示部35に表示される。図29は試合結果画像の一例を示す。図29に示すように、試合結果画像G300は要素P301,P302を含む。要素P301は試合結果(勝敗や両チームの得点等)を示し、要素P302は、試合への貢献度に関するユーザランキングを示す。
先述のように、ユーザU1の勢いポイントの初期値は、ユーザチームの選手キャラクタのうち、ユーザU1の所有する選手キャラクタの能力(すなわち、ゲーム開始時点における能力)に基づいて算出される。そして、ユーザU1の勢いポイントは、アクションパートにおけるユーザU1個人のプレイ結果や、アクションパートにおける連係アクションの成否結果に基づいて加算される。このため、試合終了時におけるユーザU1の勢いポイントはユーザU1の貢献度を示している。同様に、試合終了時におけるユーザU2,U3の勢いポイントはユーザU2,U3の各々の貢献度を示している。
そこで、野球ゲームXでは、ユーザU1〜U3の各々の貢献度を示す貢献ポイントが試合終了時におけるユーザU1〜U3の各々の勢いポイントに基づいて決定される。例えば、ユーザU1の貢献ポイントは、試合終了時のユーザU1の勢いポイントと試合終了時のユーザU2,U3の各々の勢いポイントとの比較に基づいて決定される。例えば、下記の算出式(1)に従って個々のユーザの貢献ポイントが算出される。
Pc=Pb*(Pu/Psum) ・・・ (1)
上記の算出式(1)において、「Pb」はベースポイントを示す。ベースポイントは試合結果に応じて変わる。例えば、試合に敗北した場合のベースポイント(例えば50ポイント)は、試合に勝利した場合のベースポイント(例えば100ポイント)よりも少なくなる。
また、「Pu」は試合終了時におけるユーザの勢いポイントを示し、「Psum」は試合終了時における全ユーザの勢いポイントの和を示す。
上記の算出式(1)では、個々のユーザの貢献ポイントが、全ユーザの勢いポイントの合計に対して個々のユーザの勢いポイントの占める割合をベースポイントに乗じることによって算出されている。
ユーザU2,U3が通常参加者であり、助っ人参加者でない場合には、上記の算出式(1)によって算出される貢献ポイントがそのまま用いられる。しかしながら、ユーザU2,U3の少なくとも一方が助っ人参加者である場合には貢献ポイントが補正される。
ここで、ユーザU2が通常参加者であり、ユーザU3が助っ人参加者である場合を想定する。この場合、助っ人参加者であるユーザU3には助っ人ボーナスが加えられる。例えば、ベースポイントの10%が助っ人ボーナスとしてユーザU3の貢献ポイントに加えられる。すなわち、ベースポイントが100ポイントである場合には、助っ人ボーナスとして10ポイントがユーザU3の貢献ポイントに加えられる。一方、ユーザU3の貢献ポイントに加算された助っ人ボーナスに相当するポイントがユーザU3以外のユーザU1,U2の貢献ポイントから減らされる。例えば、助っ人ボーナスとして10ポイントがユーザU3の貢献ポイントに加えられた場合には、ユーザU1,U2の貢献ポイントがそれぞれ5ポイントずつ減らされる。例えば、上記の算出式(1)によって算出されるユーザU1〜U3の各々の貢献ポイントがそれぞれ30ポイント、20ポイント、50ポイントであるとすると、この場合、助っ人ボーナスがユーザU3に付与される結果として、ユーザU3の貢献ポイントは60ポイントに増加され、ユーザU1,U2の貢献ポイントはそれぞれ25ポイント、15ポイントに減少される。
以上のようにして算出されたユーザU1〜U3の各々の貢献ポイントは報酬としてユーザU1〜U3にそれぞれ付与される。なお、ユーザに付与された貢献ポイントの用途としては様々なものが考えられる。例えば、各ユーザは獲得した貢献ポイントと引き換えにしてゲームキャラクタ(イベントキャラクタ)、ゲームアイテム、又はゲーム通貨等を入手できるようにしてもよい。また例えば、各ユーザが獲得した貢献ポイントの累計で全ユーザのランキングを作成して各ユーザに提示するようにしてもよい。
以上に説明した野球ゲームXでは、例えば、ユーザU1が操作を行うことが可能なアクションパートにおいて、ユーザU2,U3によって選択された応援キャラクタに基づいて、ユーザU1が操作する選手キャラクタの能力が上がる。このため、ユーザU2,U3は応援キャラクタを選択することによって、ユーザU1のアクションパートに関与できるようになる。すなわち、ユーザU1のアクションパートにおいて、主要な操作を行うユーザU1以外のユーザU2,U3が試合の進行に関与する度合いを向上できる。
また野球ゲームXでは、ユーザU1〜U3の各々の所有する応援キャラクタに基づいて、アクションパートで応援効果(連係アクション「ピストル打線」又は「盗塁援護」等)が発動することによって、アクションパートで操作を行うことが可能なユーザの人数が増加する。その結果として、ユーザ同士で協力して対戦相手と対戦する興趣をユーザU1〜U3に実感させることが可能になる。
また野球ゲームXでは、ユーザU1の作成したチーム(言い換えれば、ユーザU1がホストとなって行われる対戦相手との試合)への参加申込みをユーザU2,U3から受け付けた場合にユーザU1〜U3と対戦相手との試合が実行され、当該試合の実行に応じて、ユーザU1〜U3の各々に貢献ポイントが付与される。特に野球ゲームXでは、例えば、ユーザU3が助っ人参加者である場合に、ユーザU1の貢献ポイントの少なくとも一部を減らして、当該減らした分をユーザU3の貢献ポイントに加えるようにして、ユーザU3の貢献ポイントが決定される。このため、ユーザU3は本来得ることができる貢献ポイントよりも多くの貢献ポイントを得ることができる。このため、ゲームシステム1によれば、ユーザU1の作成したチームに参加しようとする動機付けを他のユーザに与えることが可能になり、その結果として、ユーザU1の作成したチームに参加しようとする他のユーザが現れ易くすることが可能になる。
また野球ゲームXでは、ユーザの所有する選手キャラクタの能力(試合開始時の能力)が高いほど、ユーザの勢いポイントの初期値が大きくなる。そして、ユーザの勢いポイントが大きいほど、ユーザに付与される貢献ポイントが多くなる。その結果、野球ゲームXでは、ユーザの所有する選手キャラクタの能力(試合開始時の能力)が高いほど、ユーザに付与される貢献ポイントが多くなる。このため、能力の高い選手キャラクタを所有しているユーザに対して試合に参加する動機付けを与えることが可能になり、当該試合への参加を促すことが可能になる。
[3.機能ブロック]ゲームシステム1で実現される機能ブロックについて説明する。図30は、ゲームシステム1で実現される機能ブロックの一例を示す機能ブロック図である。また図31は、ゲームシステム1に含まれる後述のゲーム実行部130に含まれる機能ブロックの一例を示す機能ブロック図である。
[3−1]図30に示すように、ゲームシステム1はデータ記憶部100を含む。例えば、データ記憶部100はデータベース14、記憶部12、及び記憶部32の少なくとも一つによって実現される。データ記憶部100はゲームを提供するために必要なデータを記憶する。図32〜図38はデータ記憶部100に記憶されるデータの一例を示す。図32〜図38は、野球ゲームXを実現する場合にデータ記憶部100に記憶されるデータの一例を示す。
[3−1−1]図32はユーザテーブルの一例を示す。ユーザテーブルTBL101は、ゲームシステム1でゲームをプレイするユーザのリストを示すデータである。図32に示すように、ユーザテーブルTBL101は「ユーザID」、「ユーザ名」、「フレンド」、「ゲームアイテム」、「対戦レベル」、及び「貢献ポイント」フィールドを含む。
「ユーザID」フィールドは各ユーザを一意に特定するための識別情報を示す。「ユーザ名」フィールドはユーザの名前を示す。「フレンド」フィールドは、ユーザと友人関係にある他のユーザのリストを示す。「ゲームアイテム」フィールドは、ユーザの所有しているゲームアイテムのリストを示す。なお、「ユーザの所有しているゲームアイテム」とは、ユーザが任意に使用することが可能な状態にあるゲームアイテムである。「対戦レベル」フィールドはユーザの対戦レベルを示す。「貢献ポイント」フィールドは、ユーザが獲得した貢献ポイントの累計を示す。
[3−1−2]図33はイベントキャラクタテーブルの一例を示す。イベントキャラクタテーブルTBL102は、ユーザの所有しているイベントキャラクタのリストを示す。「ユーザの所有しているイベントキャラクタ」とは、ユーザが任意に使用することが可能な状態にあるイベントキャラクタである。イベントキャラクタテーブルTBL102はユーザごとに記憶される(各ユーザIDに関連付けて記憶される)。図33に示すように、イベントキャラクタテーブルTBL102は下記に説明するフィールドを含む。
「イベントキャラクタID」フィールドは、ユーザの所有しているイベントキャラクタを特定するための識別情報を示す。「名称」フィールドはイベントキャラクタの名称を示す。「レアリティ」フィールドはイベントキャラクタのレアリティを示す。「適正ポジション」フィールドはイベントキャラクタが得意な野球のポジションを示す。「得意練習」フィールドはイベントキャラクタが得意な練習項目を示す。「レベル」フィールドはイベントキャラクタのレベルを示す。
「能力パラメータ」フォールドはイベントキャラクタの能力パラメータを示す。例えば、育成フェーズで試合イベントが発生した場合には、イベントデッキに組み込まれているイベントキャラクタが主人公キャラクタのチームメイトとして試合に参加する。このような試合イベントではイベントキャラクタの能力パラメータが参照される。
「イベント効果」フィールドは、イベントキャラクタに関連付けられたイベント効果を示す。例えば、「イベント効果」フィールドは、イベントキャラクタがイベントデッキに組み込まれた場合に育成フェーズで発生し得る効果に関する情報を示す。イベントキャラクタがイベントデッキに組み込まれた場合に育成フェーズで発生し得るイベント又はボーナスの名称や内容を示す情報が「イベント効果」フィールドに登録される。
「応援効果」フィールドは、イベントキャラクタに関連付けられた応援効果を示す。例えば、「応援効果」フィールドは、イベントキャラクタが応援キャラクタとして使用された場合にアクションパートで発生し得る効果に関する情報を示す。
「使用状態」フィールドは、イベントキャラクタの使用状態を示す。例えば、「使用状態」フィールドは、イベントキャラクタがイベントデッキに組み込まれているか否かや、イベントキャラクタが応援キャラクタとして設定されているか否か等を示す。
[3−1−3]図34はオリジナルキャラクタテーブルの一例を示す。オリジナルキャラクタテーブルTBL103は、ユーザの所有しているオリジナルキャラクタ(ユーザが作成したオリジナルキャラクタ)のリストを示す。「ユーザの所有しているオリジナルキャラクタ」とは、ユーザが任意に使用することが可能な状態にあるオリジナルキャラクタである。オリジナルキャラクタテーブルTBL103はユーザごとに記憶される(各ユーザIDに関連付けて記憶される)。図34に示すように、オリジナルキャラクタテーブルTBL103は下記に説明するフィールドを含む。
「オリジナルキャラクタID」フィールドは、ユーザの所有しているオリジナルキャラクタを特定するための識別情報を示す。「名称」フィールドはオリジナルキャラクタの名称を示す。「適正ポジション」フィールドはオリジナルキャラクタが得意な野球のポジションを示す。「利き腕」フィールドはオリジナルキャラクタの利き腕を示す。「フォーム」フィールドはオリジナルキャラクタの打撃フォーム又は投球フォームを示す。オリジナルキャラクタが野手である場合には打撃フォームが「フォーム」フィールドに登録され、オリジナルキャラクタが投手である場合には投球フォームが「フォーム」フィールドに登録される。「ランク」フィールドはオリジナルキャラクタのランクを示す。
「オリジナル能力パラメータ」フィールドはオリジナルキャラクタの能力パラメータのオリジナル値を示す。先述の通り、試合フェーズのアクションパートではオリジナルキャラクタの能力パラメータが応援効果等によって変更される場合があるが、「オリジナル能力パラメータ」フィールドは、試合開始時の能力パラメータの値(言い換えれば、変更されていない状態の能力パラメータの値)を示す。例えば、基本能力パラメータ及び特殊能力パラメータのオリジナル値が「オリジナル能力パラメータ」フィールドに登録される。
「使用状態」フィールドは、オリジナルキャラクタの使用状態を示す。例えば、「使用状態」フィールドは、オリジナルキャラクタが選手キャラクタ設定画像G150でいずれかのポジションの選手キャラクタとして割り当てられたか否かや、オリジナルキャラクタが割り当てられたポジション等を示す。
[3−1−4]図35はチームテーブルの一例を示す。チームテーブルは、現在存在しているチームのリストを示す。図35に示すように、チームテーブルTBL104は下記に説明するフィールドを含む。
「チームID」フィールドは、チームを一意に特定するための識別情報を示す。「ホストユーザ」フィールドは、チームのホストであるユーザ(すなわち、チームを作成したユーザ)を示す。「対戦レベル」フィールドはチームの対戦レベルを示す。
「参加者ユーザ1」フィールドはチームへの1人目の参加者を示す。「参加者ユーザ1」フィールドは「ユーザID」及び「助っ人フラグ」サブフィールドを含む。「ユーザID」サブフィールドは、1人目の参加者であるユーザのユーザIDを示し、「助っ人フラグ」サブフィールドは、1人目の参加者であるユーザが助っ人参加者であるか否かを示す。例えば、値「0」又は「1」が「助っ人フラグ」サブフィールドに登録される。値「0」は、ユーザが助っ人参加者でなく、通常参加者であることを示し、値「1」は、ユーザが助っ人参加者であることを示す。「参加者ユーザ2」フィールドはチームへの2人目の参加者を示す。「参加者ユーザ2」フィールドは「参加者ユーザ1」フィールドと同様である。
「助っ人要請フラグ」フィールドは、助っ人要請が行われたか否かを示す。例えば、値「0」又は「1」が「助っ人要請フラグ」フィールドに登録される。例えば、値「0」は、助っ人要請が行われていない状態であることを示し、値「1」は、助っ人要請が行われた状態であることを示す。
「受付完了フラグ」フィールドは、チームへの参加申込みの受付が完了したか否かを示す。例えば、値「0」又は「1」が「受付完了フラグ」フィールドに登録される。例えば、値「0」は、チームへの参加申込みの受付が完了しておらず、現在受付中であることを示し、値「1」は、チームへの参加申込みの受付が完了したことを示す。
[3−1−5]図36は試合状況テーブルの一例を示す。試合状況テーブルTBL105は現在の試合状況を示すデータである。試合状況テーブルTBL105は各試合ごとに生成される。
図36に示すように、試合状況テーブルTBL105は「現在イニング」、「攻撃中チーム」、「現在打者」、「ボールカウント」、「アウトカウント」、「一塁走者」、「二塁走者」、及び「三塁走者」フィールドを含む。これらのフィールドは、現在のイニング、現在攻撃中のチーム、現在打席に立っている選手キャラクタ、現在のボールカウント、現在のアウトカウント、現在の出塁状況(一塁、二塁、三塁にいる選手キャラクタ)を示す。
また、試合状況テーブルTBL105は「先攻」、「後攻」、及び「スコアブック」フィールドを含む。「先攻」フィールドは、先攻のチーム、先攻のチームの現在の勢いポイント、得点、安打数、及び失策数や、先攻のチームで次に打席に立つことになる選手キャラクタを示す。なお、勢いポイントに関しては、各ユーザの勢いポイントとそれらの合計(すなわちユーザチームの勢いポイント)とが登録される。同様に、「後攻」フィールドは、後攻のチーム、後攻のチームの現在の勢いポイント、得点、安打数、及び失策数や、後攻のチームで次に打席に立つことになる選手キャラクタを示す。「スコアブック」フィールドは試合のスコアブック(試合経過)を示す。
[3−1−6]図37は選手キャラクタテーブルTBL106の一例を示す。選手キャラクタテーブルTBL106は、ユーザチーム又は対戦相手チームのスターティングオーダー及び控え選手として設定された選手キャラクタのリストを示す。選手キャラクタテーブルTBL106も各試合ごとに生成される。選手キャラクタテーブルTBL106はユーザチーム及び対戦相手チームの各々ごとに記憶される。図37に示すように、選手キャラクタテーブルTBL106は下記に説明するフィールドを含む。
「選手キャラクタID」フィールドは、選手キャラクタを一意に特定するための識別情報を示す。「所有ユーザ」フィールドは、選手キャラクタの所有者であるユーザを示し、「オリジナルキャラクタID」フィールドは、選手キャラクタとして設定されたオリジナルキャラクタのオリジナルキャラクタIDを示す。
「現在能力パラメータ」フィールドは選手キャラクタの能力パラメータの現在値を示す。例えば、基本能力パラメータ及び特殊能力パラメータの現在値が「現在能力パラメータ」フィールドに登録される。試合開始当初、「現在能力パラメータ」フィールドの内容はオリジナルキャラクタテーブルTBL103の「オリジナル能力パラメータ」フィールドの内容と同じである。試合中に選手キャラクタの能力パラメータが応援キャラクタの応援効果等によって変更される場合に「現在能力パラメータ」フィールドの内容が変更される。
「出場状態フラグ」フィールドは選手キャラクタの試合への出場状態を示す。例えば、値「0」,「1」,「2」のいずれかが「出場状態」フィールドに登録される。値「0」は、選手キャラクタが試合に出場しておらず、交代によって試合に出場可能であることを示す。値「1」は、選手キャラクタが試合に出場中であることを示す。値「2」は、選手キャラクタが試合に出場していたが、交代によって現在は試合に出場していないことを示す。「打順」及び「ポジション」フィールドは、試合に出場している選手キャラクタに関して打順及びポジションを示す。
[3−1−7]図38は応援キャラクタテーブルTBL107の一例を示す。応援キャラクタテーブルTBL107は、試合に参加するユーザ(ホスト及び参加者)によって設定された応援キャラクタのリストを示す。応援キャラクタテーブルTBL107も各試合ごとに生成される。図38に示すように、応援キャラクタテーブルTBL107は「応援キャラクタID」、「イベントキャラクタ」、「所有ユーザ」、及び「使用済み」フィールドを含む。
「応援キャラクタID」フィールドは、応援キャラクタを一意に特定するための識別情報を示す。「所有ユーザ」フィールドは、応援キャラクタの所有者であるユーザを示し、「イベントキャラクタID」フィールドは、応援キャラクタとして設定されたイベントキャラクタのイベントキャラクタIDを示す。「使用済みフラグ」フィールドは、応援キャラクタが試合で使用済みであるか否かを示す。例えば、値「0」又は「1」が「使用済みフラグ」フィールドに登録される。例えば、値「0」は、応援キャラクタが試合で使用済みでなく、使用可能であることを示し、値「1」は、応援キャラクタが試合で使用済みであることを示す。
[3−2]図30に示すように、ゲームシステム1は参加要請受付部110を含む。例えば、参加要請受付部110はサーバ10の制御部11によって実現される。
参加要請受付部110は、第1ユーザのプレイするゲームへの参加要請を第1ユーザから受け付ける。
ここで、「第1ユーザのプレイするゲーム」とは、第1ユーザが主となって行われるゲームである。言い換えれば、「第1ユーザのプレイするゲーム」とは、第1ユーザが必ず参加し、他のユーザが任意に参加可能なゲームである。また、「第1ユーザのプレイするゲーム」とは、第1ユーザがこれからプレイするゲームである。なお、「第1ユーザのプレイするゲーム」とは、第1ユーザが現在プレイしているゲームであってもよい。
「参加要請を第1ユーザから受け付ける」とは、第1ユーザのゲーム端末30から送信される、ゲームへの参加要請を示すデータを受信することである。または、「参加要請を第1ユーザから受け付ける」とは、第1ユーザによって行われる、ゲームへの参加要請を示す操作を受け付けることであってもよい。なお、参加要請の受付はゲームの開始前に行われる。参加要請の受付はゲームの実行中に行われるようにしてもよい。後述の参加申込受付部120(第2参加申込受付部122)による参加申込みの受付は参加要請の受付後に実行されるようにしてもよい。
「参加要請」とは、第1ユーザのプレイするゲームに他のユーザが参加することを要請することである。「他のユーザ」は不特定の他のユーザであってもよいし、特定の他のユーザ(例えば、第1ユーザによって指定された他のユーザ)であってもよい。
なお、「参加要請」は、第1ユーザのプレイするゲームへの、第1ユーザよりもゲームにおける能力が高い他のユーザの参加を要請することであってもよい。
ここで、「ゲームにおける能力」とはユーザ自身の能力である。例えば、ユーザのゲームの熟練度、又はユーザのゲームのプレイ実績である。または、「ゲームにおける能力」とは、ユーザの所有するゲームオブジェクトの能力であってもよい。なお、ゲームオブジェクトは、ゲームで利用され得るものであり、例えばゲームキャラクタ又はゲームアイテム等である。
先述の野球ゲームXでは、助っ人要請が「参加要請」の一例に相当する。先述の通り、「助っ人要請」は、例えば、ユーザU1の作成したチーム(言い換えれば、ユーザU1がホストとして行われる対戦)に助っ人参加者として参加することを要請することである。参加要請受付部110はこのような助っ人要請をユーザU1から受け付ける。
[3−3]図30に示すように、ゲームシステム1は参加申込受付部120を含む。例えば、参加申込受付部120はサーバ10の制御部11によって実現される。
参加申込受付部120は、第1ユーザのプレイするゲームへの参加申込みを第1ユーザ以外のユーザ(第2ユーザ又は第3ユーザ等)から受け付ける。
ここで、「参加申込み」とは、第1ユーザのプレイするゲームに参加することを申し込むことである。なお、第2ユーザから参加申込みを受けつけた場合、無条件に、第2ユーザが第1ユーザのプレイするゲームに参加できるようにしてもよいし、所定の条件の下で、第2ユーザが第1ユーザのプレイするゲームに参加できるようにしてもよい。後者の場合、例えば、第1ユーザの承諾を条件として、第1ユーザによって承諾された場合に、第2ユーザが第1ユーザのプレイするゲームに参加できるようにしてもよい。
「参加申込みを第2ユーザから受け付ける」とは、第2ユーザのゲーム端末30から送信される、ゲームへの参加申込みを示すデータを受信することである。または、「参加申込みを第2ユーザから受け付ける」とは、第2ユーザによって行われる、ゲームへの参加申込みを示す操作を受け付けることであってもよい。参加申込みの受付はゲームの開始前に行われる。なお、参加申込みの受付はゲームの実行中に行われるようにしてもよい。
例えば、参加申込受付部120は第1参加申込受付部121と第2参加申込受付部122とを含む。第1参加申込受付部121は、ゲームへの第1種参加者としての参加申込みである第1参加申込みを第1ユーザ以外のユーザ(第2ユーザ又は第3ユーザ等)から受け付ける。第2参加申込受付部122は、ゲームへの第2種参加者としての参加申込みである第2参加申込みを第1ユーザ以外のユーザ(第2ユーザ又は第3ユーザ等)から受け付ける。例えば、第2参加申込受付部122は参加要請に応じて第2参加申込みの受付を開始する。
ここで、「第1種参加者」とは通常の参加者である。言い換えれば、「第1種参加者」とは、所定の規則に則った通常の報酬を得ることが可能な参加者である。これに対し、「第2種参加者」とは特別の参加者である。言い換えれば、「第2種参加者」とは、上記所定の規則に則った通常の報酬よりも多い報酬を得ることが可能な参加者である。後述するように、「第2種参加者」とは、例えば、第1ユーザへの報酬の少なくとも一部を通常の報酬に加えて得ることが可能な参加者である。
「第1参加申込み」とは、第1ユーザのプレイするゲームに第1種参加者として参加することを申し込むことである。一方、「第2参加申込み」とは、第1ユーザのプレイするゲームに第2種参加者として参加することを申し込むことである。
例えば、参加申込受付部120は、第1ユーザの選択操作に応じて、第2参加申込受付部122による受付を行うか否かを設定する。
ここで、「選択操作」とは、第2参加申込受付部122による参加受付を行うか否かを選択する操作(言い換えれば、第2参加申込受付部122による参加受付を行うか否かを示す操作)である。
「選択操作に応じて、第2参加申込受付部122による受付を行うか否かを設定する」とは、選択操作を受け付けた場合に、当該選択操作が、第2参加申込受付部122による受付を行うことを選択することを示すのであれば、第2参加申込受付部122による受付を行うように設定し、当該選択操作が、第2参加申込受付部122による受付を行わないことを選択することを示すのであれば、第2参加申込受付部122による受付を行わないように設定することである。
例えば、「選択操作」は、第1ユーザのプレイするゲームへの第2種参加者の参加を要請することを選択する操作である。例えば、第1ユーザのプレイするゲームへの参加要請を第1ユーザから受け付けた場合に第2参加申込受付部122による受付が開始するようになっているのであれば、上記参加要請を行う操作は、第2参加申込受付部122による参加受付を行うことを選択する操作に相当するため、「選択操作」の一例に相当する。この場合、第2参加申込受付部122は、第1ユーザのプレイするゲームへの第2種参加者の参加を要請することが選択された場合に、第2参加申込みを受け付けることになる。
なお、参加申込受付部120は、第2ユーザのゲームにおける能力が第1ユーザよりも高い場合に、参加申込みを第2ユーザから受け付けるようにしてもよい。例えば、参加申込受付部120は、第1ユーザのゲームにおける能力に関するゲーム能力情報と、第2ユーザのゲームにおける能力に関するゲーム能力情報とに基づき、第2ユーザのゲームにおける能力が第1ユーザよりも高いと判定される場合に、第1ユーザの参加するゲームへの参加申込みを第2ユーザから受け付けるようにしてもよい。より具体的には、例えば、第2参加申込受付部122は、第1ユーザのゲームにおける能力に関するゲーム能力情報と、第2ユーザのゲームにおける能力に関するゲーム能力情報とに基づき、第2ユーザのゲームにおける能力が第1ユーザよりも高いと判定される場合に、第2参加申込みを第2ユーザから受け付けるようにしてもよい。
ここで、「ゲーム能力情報」とは、ゲームにおける能力に関する情報である。「ゲームにおける能力」とは、ユーザ自身の能力であってもよい。すなわち、「ゲーム能力情報」は、例えば、ユーザのゲームの熟練度を示す情報であってもよいし、ユーザのゲームのプレイ実績(例えばゲームのプレイ回数又はゲームの進行状況)を示す情報であってもよい。例えば、ユーザのレベルが「ゲーム能力情報」の一例に相当する。
または、「ゲームにおける能力」とは、ユーザの所有するゲームオブジェクトの能力であってもよい。すなわち、「ゲーム能力情報」は、ユーザの識別情報に関連付けられたゲームオブジェクトの能力を示す情報であってもよい。なお、「ユーザの識別情報」とは、ユーザを一意に識別(特定)するための情報である。例えば、ユーザID、ユーザの名前、ユーザアカウント、又は電子メールアドレス等が「ユーザの識別情報」の一例に相当する。また、「ゲームオブジェクト」は、ゲームで利用され得るものであり、例えばゲームキャラクタ又はゲームアイテム等である。例えば、ユーザの所有するゲームキャラクタの能力パラメータが「ゲーム能力情報」の一例に相当する。「能力パラメータ」は数値情報であってもよいし、数値情報以外の情報であってもよい。
また、「第2ユーザのゲームにおける能力が第1ユーザよりも高いと判定される場合に、第1ユーザの参加するゲームへの参加申込みを第2ユーザから受け付ける」とは、第2ユーザのゲームにおける能力が第1ユーザよりも低いと判定される場合に、第2ユーザから参加申込みを受け付けることを制限し、第2ユーザのゲームにおける能力が第1ユーザよりも高いと判定される場合に、第2ユーザから参加申込みを受け付けることである。また、第2ユーザのゲームにおける能力が第1ユーザと同じである場合に関しては、第2ユーザから参加申込みを受け付けるようにしてもよいし、受け付けることを制限するようにしてもよい。なお、「ユーザから参加申込みを受け付けることを制限する」とは、ユーザが参加申込みを行うことができないようにすることや、ユーザからの参加申込みを正式に受け付けない(例えば無視する、却下する、又はエラーとする)こと等である。
先述の野球ゲームXでは、通常参加者が「第1種参加者」の一例に相当し、助っ人参加者が「第2種参加者」の一例に相当する。このため、第1参加申込受付部121は、ユーザU1の作成したチーム(言い換えれば、ユーザU1がホストとして行われる対戦)への通常参加者としての参加申込み(第1参加申込みの一例)を他のユーザから受け付ける。また、第2参加申込受付部122は、ユーザU1の作成したチームへの助っ人参加者としての参加申込み(第2参加申込みの一例)を他のユーザから受け付ける。
また、先述の野球ゲームXでは、ユーザの対戦レベルが「ゲーム能力情報」の一例に相当する。このため、第2参加申込受付部122は、ユーザU1の作成したチームへの助っ人参加者としての参加申込みを、ユーザU1よりも対戦レベルの高い他のユーザから受け付ける。
[3−4]図30に示すように、ゲームシステム1はゲーム実行部130を含む。例えば、ゲーム実行部130はサーバ10の制御部11又はゲーム端末30の制御部31によって実現される。なお、ゲーム実行部130はサーバ10の制御部11とゲーム端末30の制御部31との協働によって実現されるようにしてもよい。
ゲーム実行部130は、第1ユーザのプレイするゲームへの参加申込み(第1参加申込み又は第2参加申込み)を第2ユーザから受け付けた場合に、第1ユーザと第2ユーザとが参加するゲームを実行する。
ここで、「第1ユーザと第2ユーザとが参加するゲーム」とは、第1ユーザ及び第2ユーザのみが参加するゲームであってもよいし、第1ユーザと第2ユーザと1又は複数の他のユーザとが参加するゲームであってもよい。
「ゲームへの参加申込みを第2ユーザから受け付けた場合に、第1ユーザと第2ユーザとが参加するゲームを実行する」とは例えば下記のような場合である。
(例1)参加申込みを受け付けるための所定の受付期間内に、第2ユーザから参加申込みを受け付け、かつ、1又は複数の他のユーザからも参加申込みを受け付けて、受付期間が終了した場合に、第1ユーザと第2ユーザと1又は複数の他のユーザが参加するゲームを実行する。
(例2)参加申込みを受け付けるための所定の受付期間内に、第2ユーザから参加申込みを受け付け、かつ、他のユーザから参加申込みを受け付けることなく、受付期間が終了した場合に、第1ユーザと第2ユーザとが参加するゲームを実行する。
(例3)第2ユーザから参加申込みを受け付け、かつ、1又は複数の他のユーザからも参加申込みを受け付けたことによって、ゲームに参加可能な上限人数のユーザから参加申込みを受け付けた場合に、第1ユーザと第2ユーザと1又は複数のユーザとが参加するゲームを実行する。
(例4)第2ユーザから参加申込みを受け付けた場合に、直ちに(又は第1ユーザ及び第2ユーザの少なくとも一方の指示により)、第1ユーザと第2ユーザとが参加するゲームを実行する。
先述の野球ゲームXでは、ユーザU1〜U3と対戦相手との対戦(協力プレイパート)が「第1ユーザと第2ユーザとが参加するゲーム」の一例に相当する。このため、ゲーム実行部130はユーザU1〜U3と対戦相手との対戦(協力プレイパート)を実行する。
ゲーム実行部130に含まれる機能ブロックの一例については後述する。
[3−5]図30に示すように、ゲームシステム1は報酬決定部140を含む。例えば、報酬決定部140はサーバ10の制御部11又はゲーム端末30の制御部31によって実現される。なお、報酬決定部140はサーバ10の制御部11とゲーム端末30の制御部31との協働によって実現されるようにしてもよい。
報酬決定部140はゲームに参加したユーザへの報酬を決定する。
ここで、「ユーザへの報酬」とは、ユーザに付与する報酬である。言い換えれば、「ユーザへの報酬」とは、ユーザの識別情報に関連付ける報酬である。例えば、ゲームポイント(ゲーム内通貨等)が報酬としてユーザに付与される。また例えば、ゲームオブジェクト(ゲームキャラクタ又はゲームアイテム等)が報酬としてユーザに付与される。「ユーザへの報酬」は、ゲームポイントやゲームオブジェクトに限られず、ゲームの内容に合わせて種々の報酬を設定することが可能である。例えば、「ユーザへの報酬」は、ユーザのパラメータ、又は、ユーザの所有するゲームオブジェクトのパラメータをユーザにとって有利となるように一時的又は永続的に変化させることであってもよい。
[3−5−1]報酬決定部140は、ゲーム開始時のユーザのゲームにおける能力に関するゲーム能力情報に基づいて、当該ユーザへの報酬を決定するようにしてもよい。具体的には、報酬決定部140は、ゲーム開始時のユーザのゲームにおける能力が高い場合にはゲーム開始時のユーザのゲームにおける能力が低い場合に比べて報酬の価値が高くなるようにして、当該ユーザへの報酬を決定するようにしてもよい。
ここで、「ゲーム能力情報」に関しては、参加申込受付部120を説明した際にすでに説明したため、ここでは説明を省略する。
「報酬の価値が高くなるようにして」とは、例えば、「報酬(ゲームポイント又はゲームオブジェクト等)の量が多くなるようにして」を意味する。また例えば、「報酬として付与される対象(ゲームオブジェクト等)の有用性又は稀少性が高くなるようにして」を意味するようにしてもよい。より具体的には、例えば、「より能力の高いゲームオブジェクトが報酬として付与されるようにして」、又は、「より稀少性の高いゲームオブジェクトが報酬として付与されるようにして」等を意味するようにしてもよい。
「能力が高い場合には能力が低い場合に比べて報酬の価値が高くなるようにして」とは、例えば、能力を含む複数の要素に基づいて報酬が決定されるような場合にあれば、能力以外の要素が同一であると仮定した場合において、能力が高い場合には能力が低い場合に比べて報酬の価値が高くなるようになっていることである。
先述の野球ゲームXでは、貢献ポイントが「報酬」の一例に相当する。また、選手キャラクタのオリジナル能力パラメータが「ゲーム開始時のゲーム能力情報」の一例に相当する。野球ゲームXでは、ユーザチームの選手キャラクタのうちの、ユーザU1の所有する選手キャラクタのオリジナル能力パラメータに基づいて、ユーザU1の勢いポイントの初期値が算出され、報酬決定部140は、ユーザU1の勢いポイントに基づいて、ユーザU1に付与する貢献ポイントを決定する。その結果、ユーザU1の所有する選手キャラクタのオリジナル能力が高い場合には当該オリジナル能力が低い場合に比べて、ユーザU1に付与する貢献ポイントが多くなる。
[3−5−2]ゲームに参加した複数のユーザに第1ユーザと第2ユーザとが含まれる場合に、報酬決定部140は、ゲーム開始時の第1ユーザのゲームにおける能力に関するゲーム能力情報とゲーム開始時の第2ユーザのゲームにおける能力に関するゲーム能力情報とに基づいて、第2ユーザへの報酬を決定するようにしてもよい。具体的には、報酬決定部140は、ゲーム開始時の第2ユーザのゲームにおける能力がゲーム開始時の第1ユーザのゲームにおける能力よりも高い場合には、ゲーム開始時の第2ユーザのゲームにおける能力がゲーム開始時の第1ユーザのゲームにおける能力よりも高くない場合に比べて、第2ユーザへの報酬の価値が高くなるようにして、第2ユーザへの報酬を決定するようにしてもよい。
例えば、ゲーム開始時のゲーム能力(ゲームにおける能力)を含む複数の要素に基づいて報酬が決定されるような場合であれば、ゲーム能力以外の要素が同一であると仮定した場合において、ゲーム開始時の第2ユーザのゲーム能力がゲーム開始時の第1ユーザのゲーム能力よりも高い場合には、ゲーム開始時の第2ユーザのゲーム能力がゲーム開始時の第1ユーザのゲーム能力よりも高くない場合に比べて、第2ユーザへの報酬の価値が高くなるようにして、第2ユーザへの報酬が決定される。
先述の野球ゲームXでは、貢献ポイントが「報酬」の一例に相当する。また、選手キャラクタのオリジナル能力パラメータが「ゲーム開始時のゲーム能力情報」の一例に相当する。野球ゲームXでは、ユーザチームの選手キャラクタのうちの、ユーザU3の所有する選手キャラクタのオリジナル能力パラメータに基づいて、ユーザU3の勢いポイントの初期値が算出され、ユーザU1の所有する選手キャラクタのオリジナル能力パラメータに基づいて、ユーザU1の勢いポイントの初期値が算出される。そして、報酬決定部140は、ユーザU3の勢いポイントがユーザU1の勢いポイントよりも大きい場合には、ユーザU3の勢いポイントがユーザU1の勢いポイントよりも大きくない場合に比べて、ユーザU3に付与する貢献ポイントを多くする(先述の算出式(1))。
[3−5−3]報酬決定部140は、ゲーム能力情報と、ゲームにおけるユーザのプレイ結果に関するプレイ結果情報とに基づいて、ユーザへの報酬を決定するようにしてもよい。
ここで、「プレイ結果情報」とは、ゲームにおいてユーザによって行われたプレイの結果を示す情報である。例えば、ゲームにおいてユーザ個人が収めた成績に関する情報が「プレイ結果情報」の一例に相当する。例えば、野球ゲームの場合であれば、ユーザの打撃成績(又は投手成績)が「プレイ結果情報」の一例に相当する。例えば、サッカーゲームの場合であれば、ユーザの得点数、アシスト数、又はパス成功率等が「プレイ結果情報」の一例に相当する。また例えば、敵を退治するゲームの場合であれば、ユーザが倒した敵の数、又はユーザが敵に与えたダメージの量等が「プレイ結果情報」の一例に相当する。
「ゲーム能力情報とプレイ結果情報とに基づいて報酬を決定する」とは、例えば、ゲーム能力情報が示す能力が高い場合には当該能力が低い場合に比べて報酬の価値が高くなるように、かつ、プレイ結果情報が示すプレイ結果が良い場合には当該プレイ結果が悪い場合に比べて報酬の価値が高くなるようにして、報酬を決定することである。より具体的には、まず、プレイ結果情報に基づいて、ゲームに参加したユーザ全体への報酬を決定し、その後、当該報酬を各ユーザのゲーム能力情報に応じて各ユーザに分配することによって、各ユーザへの報酬を決定することである。または、まず、ゲーム能力情報に基づいて、ゲームに参加した各ユーザへの報酬を仮決定し、その後、各ユーザへの報酬を、各ユーザのプレイ結果情報に応じて増加又は減少することによって、各ユーザへの報酬を決定することである。
先述の野球ゲームXでは、貢献ポイントが「報酬」の一例に相当する。また、選手キャラクタのオリジナル能力パラメータが「ゲーム開始時のゲーム能力情報」の一例に相当し、アクションパートにおけるユーザのプレイ結果(ユーザの操作する打者キャラクタがヒットを打ったか否か等)が「プレイ結果情報」の一例に相当する。
野球ゲームXでは、ユーザチームの選手キャラクタのうちの、ユーザU1の所有する選手キャラクタのオリジナル能力パラメータに基づいて、ユーザU1の勢いポイントの初期値が算出され、アクションパートにおけるユーザU1のプレイ結果に基づいて、ユーザU1の勢いポイントが増加される。そして、報酬決定部140は、このようにして増加されたユーザU1の勢いポイントに基づいて、ユーザU1に付与する貢献ポイントを決定する(先述の算出式(1))。その結果、ユーザU1の所有する選手キャラクタのオリジナル能力が高いほど、ユーザU1に付与する貢献ポイントは多くなり、かつ、アクションパートにおけるユーザU1のプレイ結果が良いほど、ユーザU1に付与する貢献ポイントは多くなる。
[3−5−4]報酬決定部140は、ゲーム能力情報と、ゲームの結果に関するゲーム結果情報とに基づいて、ユーザへの報酬を決定するようにしてもよい。
ここで、「ゲーム結果情報」とは、ゲームの結果に関する情報である。例えば、複数ユーザが協力して目的を達成することを目指すゲームの場合であれば、目的を達成することができたか否かを示す情報、又は、目的の達成度に関する情報が「ゲーム結果情報」の一例に相当する。
「ゲーム能力情報とゲーム結果情報とに基づいて報酬を決定する」とは、例えば、ゲーム能力情報が示す能力が高い場合には当該能力が低い場合に比べて報酬の価値が高くなるように、かつ、ゲーム結果情報が示すゲーム結果が良い場合には当該ゲーム結果が悪い場合に比べて報酬の価値が高くなるようにして、報酬を決定することである。より具体的には、まず、ゲーム結果情報に基づいて、ゲームに参加したユーザ全体への報酬を決定し、その後、当該報酬を各ユーザのゲーム能力情報に応じて各ユーザに分配することによって、各ユーザへの報酬を決定することである。または、まず、ゲーム能力情報に基づいて、ゲームに参加した各ユーザへの報酬を仮決定し、その後、各ユーザへの報酬をゲーム結果情報に応じて増加又は減少することによって、各ユーザへの報酬を決定することである。
先述の野球ゲームXでは、貢献ポイントが「報酬」の一例に相当する。また、選手キャラクタのオリジナル能力パラメータが「ゲーム開始時のゲーム能力情報」の一例に相当し、試合結果(対戦相手に勝利したか否か等)が「ゲーム結果情報」の一例に相当する。
先述の野球ゲームXでは、ユーザチームの選手キャラクタのうちの、ユーザU1の所有する選手キャラクタのオリジナル能力パラメータに基づいて、ユーザU1の勢いポイントの初期値が算出される。また、試合結果に基づいて、貢献ポイントのベースポイントが設定される。そして、報酬決定部140は、ユーザU1の勢いポイントと当該ベースポイントとに基づいて、ユーザU1に付与する貢献ポイントを決定する(先述の算出式(1))。その結果、ユーザU1の所有する選手キャラクタのオリジナル能力が高いほど、ユーザU1に付与する貢献ポイントは多くなり、かつ、試合結果が良いほど、ユーザU1に付与する貢献ポイントは多くなる。
[3−5−5]ゲームに参加した複数のユーザに第1ユーザと第2ユーザとが含まれる場合に、報酬決定部140は、第1ユーザへの報酬の少なくとも一部を減らして、当該減らした分を第2ユーザへの報酬に加えるようにして、第1ユーザへの報酬と、第2ユーザへの報酬とを決定するようにしてもよい。
ここで、「第1ユーザへの報酬の少なくとも一部を減らして、当該減らした分を第2ユーザへの報酬に加える」とは、第2ユーザへの報酬に加えるために、第1ユーザへの報酬を減らすことである。例えば、報酬がゲームポイントである場合であれば、第1ユーザに付与するゲームポイントを減らし、その分、第2ユーザに付与するゲームポイントを増やすことである。また例えば、報酬がゲームオブジェクトである場合であれば、第1ユーザに付与するゲームオブジェクトの数を減らし、その分、第2ユーザに付与するゲームオブジェクトの数を増やすことである。
なお、第1ユーザへの報酬を減らす程度は、ゲーム開発者(ゲーム提供者)によって予め定められていてもよいし、第1ユーザによって設定されるようにしてもよい。すなわち、報酬決定部15は、第1ユーザの設定操作に応じて、第1ユーザへの報酬を減らす程度を設定するようにしてもよい。ここで、「設定操作」とは、第1ユーザへの報酬を減らす程度を設定する操作である。また、「設定操作に応じて、第1ユーザへの報酬を減らす程度を設定する」とは、設定操作を受け付けた場合に、第1ユーザへの報酬を減らす程度を示す情報を、当該設定操作によって指定された程度を示すように更新することである。
報酬決定部140は、第2ユーザのゲームにおける能力に関するゲーム能力情報が示す能力が、第1ユーザのゲームにおける能力に関するゲーム能力情報が示す能力よりも高い場合に、第1ユーザへの報酬の少なくとも一部を減らして、当該減らした分を第2ユーザへの報酬に加えるようにして、第1ユーザへの報酬と第2ユーザへの報酬とを決定するようにしてもよい。
報酬決定部140は第1報酬決定部141と第2報酬決定部142とを含むようにしてもよい。第1報酬決定部141は、第2ユーザが第1種参加者としてゲームに参加した場合に、所定の規則に則って、第1ユーザへの報酬と第2ユーザへ報酬とを決定するようにしてもよい。第2報酬決定部142は、第2ユーザが第2種参加者としてゲームに参加した場合に、所定の規則に則った第1ユーザへの報酬の少なくとも一部を減らして、当該減らした分を所定の規則に則った第2ユーザへの報酬に加えるようにして、第1ユーザへの報酬と第2ユーザへの報酬とを決定するようにしてもよい。
ゲームに第2ユーザが第2種参加者として参加し、かつ、第3ユーザが第1種参加者として参加した場合に、第2報酬決定部142は、所定の規則に則った第1ユーザへの報酬の少なくとも一部と、所定の規則に則った第3ユーザへの報酬の少なくとも一部とを減らして、当該減らした分を所定の規則に則った第2ユーザへの報酬に加えるようにして、第1ユーザへの報酬と、第2ユーザへの報酬と、第3ユーザへの報酬とを決定するようにしてもよい。
先述の野球ゲームXでは、通常参加者が「第1種参加者」の一例に相当し、助っ人参加者が「第2種参加者」の一例に相当する。また、貢献ポイントが「報酬」の一例に相当し、先述の算出式(1)が「所定の規則」の一例に相当する。
野球ゲームXでは、ユーザU2,U3が通常参加者として試合に参加した場合に、第1報酬決定部141は先述の算出式(1)に従ってユーザU1,U2,U3の各々に付与する貢献ポイントを決定する。
また、ユーザU2が通常参加者として、かつ、ユーザU3が助っ人参加者として試合に参加して試合に勝利した場合(ベースポイントが100ポイントである場合)に、第2報酬決定部142は、先述の算出式(1)に従って算出されたユーザU1の貢献ポイントと、先述の算出式(1)に従って算出されたユーザU2の貢献ポイントとをそれぞれ5ポイントずつ減らして、それらを足した10ポイント(ベースポイントの10%に相当)を、上記式(1)に従って算出されたユーザU3の貢献ポイントに加えるようにして、ユーザU1,U2,U3の各々に付与する貢献ポイントを決定する。
なお、ユーザU2,U3が助っ人参加者として試合に参加して試合に勝利した場合(ベースポイントが100ポイントである場合)に、第2報酬決定部142は、先述の算出式(1)に従って算出されたユーザU1の貢献ポイントを20ポイント減らして、先述の算出式(1)に従って算出されたユーザU2,U3の各々の貢献ポイントに対してそれぞれ10ポイント(ベースポイントの10%に相当)を加えるようにして、ユーザU1,U2,U3の各々に付与する貢献ポイントを決定する。
[3−6]図30に示すように、ゲームシステム1は報酬関連付け部150を含む。例えば、報酬関連付け部150はサーバ10の制御部11又はゲーム端末30の制御部31によって実現される。なお、報酬関連付け部150はサーバ10の制御部11とゲーム端末30の制御部31との協働によって実現されるようにしてもよい。
報酬関連付け部150は報酬をユーザの識別情報に関連付ける。ここで、「ユーザの識別情報に報酬を関連付ける」とは、識別情報によって識別されるユーザに報酬を付与することである。
例えば、「ユーザの識別情報に報酬を関連付ける」とは、ユーザにゲームポイント(又はゲーム内通貨)を付与することである。すなわち、ユーザの保有するゲームポイントを増加することである。言い換えれば、ユーザの識別情報とゲームポイントが関連付けられた状態でさらにゲームポイントを関連付けることによって、ユーザの識別情報と関連付けられたゲームポイントを増加することである。
また例えば、「ユーザの識別情報に報酬を関連付ける」とは、ユーザにゲームオブジェクトを付与することである。すなわち、ユーザが保有していない新たなゲームオブジェクトをユーザに付与することや、ユーザがすでに保有しているゲームオブジェクトをさらにユーザに付与することによって、ユーザが保有している当該ゲームオブジェクトの数を増加することである。言い換えれば、新たなゲームオブジェクトをユーザの識別情報と関連付けることや、ユーザの識別情報とゲームオブジェクトが関連付けられた状態でさらに当該ゲームオブジェクトをユーザの識別情報と関連付けることによって、ユーザの識別情報と関連付けられたゲームオブジェクトの数を増加することである。
先述の通り、「報酬」は、ゲームポイントやゲームオブジェクトに限られず、ゲームの内容に合わせて種々の報酬を設定することが可能である。例えば、「報酬」は、ユーザと関連付けられたパラメータ(ゲームポイント以外のパラメータ)をユーザにとって有利となるように一時的又は永続的に変化させることであってもよい。
ただし、「報酬」はゲームのバランスを崩さないように配慮しつつ設定する必要がある。例えば、ユーザのレベルを上昇させるという報酬を付与してしまうと、ゲームによってはバランスを崩してしまうおそれがある。このような場合には、このような報酬を付与しないようにするとよい。また、ゲームオブジェクト(ゲームキャラクタ又はゲームアイテム)やゲームポイントに関しても、多く付与しすぎるとゲームのバランスを崩してしまうおそれがあるため、例えばゲームのバランスを崩さないようにすべく上限を設けるようにするとよい。
報酬関連付け部150は、報酬決定部140によって決定された報酬をユーザの識別情報に関連付ける。報酬関連付け部150は、第1ユーザと第2ユーザとが参加するゲームの実行に応じて、報酬決定部140によって決定された第1ユーザへの報酬を第1ユーザの識別情報に関連付け、報酬決定部140によって決定された第2ユーザへの報酬を第2ユーザの識別情報に関連付ける。
「ゲームの実行に応じて、ユーザの識別情報に報酬を関連付ける」とは、ゲームが実行された場合に報酬をユーザの識別情報に関連付けることである。例えば、ゲームの実行後に報酬をユーザの識別情報に関連付けることである。なお、ゲームの実行前又は実行中に報酬をユーザの識別情報に関連付けることであってもよい。
先述の野球ゲームXでは、貢献ポイントが「報酬」の一例に相当する。報酬関連付け部150はユーザU1〜U3の各々に貢献ポイントを付与する。
[3−7]ここで、ゲーム実行部130に含まれる機能ブロックの一例について説明する。図31に示すように、ゲーム実行部130は、選択受付部1301、候補選択受付部1302、選択制限部1303、操作期間設定部1304、制御実行部1305、課題設定部1306、ゲーム進行部1307、及び達成結果判定部1308を含む。
[3−7−1]。選択受付部1301はゲームオブジェクトの選択をユーザから受け付ける。例えば、選択受付部1301は、第1ユーザが操作を行うことが可能な操作期間の開始前又は操作期間中において、第1ユーザを支援するための支援ゲームオブジェクトとして少なくとも一つのゲームオブジェクトの選択を第2ユーザから受け付ける。
ここで、「操作」とは、ゲームの進行に影響を与える操作である。例えば、第1ユーザが操作対象オブジェクトを操作することによってゲームが進行する場合、操作対象オブジェクトに対する操作が「操作」に相当する。「操作対象オブジェクトに対する操作」とは、操作対象オブジェクトを動作させるために第1ユーザによって行われる操作である。例えば、操作対象オブジェクトが行うべき動作の種類、当該動作を行うべきタイミング、当該動作に関する位置又は方向等を指示する操作である。操作対象オブジェクトに対する第1ユーザの操作が可能な操作期間では、操作対象オブジェクトが第1ユーザによって行われた操作に対応する動作を行うことになる。なお、ゲームキャラクタ等が「操作対象オブジェクト」の一例に相当する。また、「操作」は操作部(タッチパネル、ボタン、キー、スティック(レバー)等)を用いて行われる。
「操作期間」とは、ゲームの実行中においてユーザが操作を行うことが可能な期間である。言い換えれば、「操作期間」とは、コンピュータがユーザによる操作を受け付ける期間である。
「支援ゲームオブジェクト」とは、操作期間において第1ユーザが有利となるように第1ユーザを支援する役割を果たすゲームオブジェクトである。なお、「ゲームオブジェクト」とは、ゲームで使用され得る対象である。例えば、ゲームキャラクタ又はゲームアイテム等が「ゲームオブジェクト」の一例に相当する。
「ユーザからゲームオブジェクトの選択を受け付ける」とは、ユーザによる選択結果を示すデータを受け取ることである。例えば、ユーザによる選択結果を示すデータをユーザのゲーム端末30から受信することである。または、「ユーザからゲームオブジェクトの選択を受け付ける」とは、ユーザによって行われる選択操作(ゲームオブジェクトを選択するための操作)を受け付けることであってもよい。
「操作期間中において選択を受け付ける」とは、操作期間全体にわたって選択を受け付けることであってもよいし、操作期間中の一部期間(例えば操作期間の開始時点から所定時間以内の期間等)又は特定時点のみにおいて選択を受け付けることであってもよい。
例えば、選択受付部1301は、支援ゲームオブジェクトとして、第2ユーザの識別情報と関連付けられたゲームオブジェクトのうちから少なくとも一つの選択を、第2ユーザから受け付けるようにしてもよい。
ここで、「ユーザの識別情報」に関しては、参加申込受付部120を説明した際にすでに説明しているため、ここでは説明を省略する。
「ユーザの識別情報と関連付けられたゲームオブジェクト」とは、ユーザの識別情報と結びつけて記憶装置に記憶されるゲームオブジェクトである。すなわち、ユーザの所有しているゲームオブジェクトである。言い換えれば、ユーザが任意に利用することが可能な状態にあるゲームオブジェクトである。
要するに、支援ゲームオブジェクトは、第2ユーザの所有する複数のゲームオブジェクト(すなわち、第2ユーザのみが利用することが可能な複数のゲームオブジェクト)のうちから選択されるようにしてもよい。なお、支援ゲームオブジェクトは、複数のユーザが共通に利用することが可能な複数のゲームオブジェクトのうちから選択されるようにしてもよい。
[3−7−2]候補選択受付部1302は、ゲームの開始前において、支援ゲームオブジェクトの候補として複数のゲームオブジェクトの選択を第2ユーザから受け付ける。例えば、候補選択受付部1302は、ゲームの開始前において、支援ゲームオブジェクトの候補として、第2ユーザの識別情報と関連付けられたゲームオブジェクトのうちから複数のゲームオブジェクトの選択を第2ユーザから受け付けるようにしてもよい。
ここで、「候補」とは、支援ゲームオブジェクトとして選択されることが可能なゲームオブジェクトである。言い換えれば、候補として選択されなかったゲームオブジェクトはゲーム中においては支援ゲームオブジェクトとして選択されることができなくなる。
この場合、選択受付部1301は、操作期間ごとに、当該操作期間の開始前又は当該操作期間中において、支援ゲームオブジェクトとして、上記候補として選択された複数のゲームオブジェクトのうちから少なくとも一つの選択を、第2ユーザから受け付けるようにしてもよい。
[3−7−3]選択制限部133は、ゲームの実行中において、複数のユーザの各々によって選択されたゲームオブジェクトが複数のユーザの各々によって再度選択されることを制限する。
例えば選択受付部1301が、操作期間ごとに、当該操作期間の開始前又は当該操作期間中において、支援ゲームオブジェクトの選択を受け付けるようになっている場合において、選択制限部1303は、支援ゲームオブジェクトとして選択されたことのあるゲームオブジェクトが支援ゲームオブジェクトとして再度選択されることを制限する。
ここで、「ゲームオブジェクトが再度選択されることを制限する」とは、例えば、ゲームオブジェクトが選択された場合に、当該ゲームオブジェクトが再度選択されることを禁止することである。ただし、ゲームオブジェクトが再度選択されることを完全に禁止することに限られない。例えば、ゲームオブジェクトが連続して選択されることを禁止するようにしてもよい。すなわち、ゲームオブジェクトが選択された場合に、次の選択機会では、当該ゲームオブジェクトが選択されることを禁止し、その次の選択機会では、当該ゲームオブジェクトが選択されることを可能にしてもよい。または、例えば、ゲームオブジェクトが選択された後の所定期間にわたって、当該ゲームオブジェクトが再度選択されることを禁止するようにしてもよい。あるいは、例えば、ゲームオブジェクトが選択された後の所定回数の選択機会において、当該ゲームオブジェクトが再度選択されることを禁止するようにしてもよい。「制限」は「禁止」に限られない。ゲームオブジェクトが再度選択され難くすることであってもよい。例えば、ゲームオブジェクトが再度選択される確率を下げることであってもよい。
[3−7−4]先述の野球ゲームXでは、個々のアクションパートが「操作期間」の一例に相当する。また、応援キャラクタ設定画像G160において応援キャラクタとして設定されたイベントキャラクタが「候補」の一例に相当する。さらに、応援キャラクタ選択画像G260において、アクションパートでの使用対象として選択された応援キャラクタが「支援ゲームオブジェクト」の一例に相当する。
このため、候補選択受付部1302は、ユーザU1〜U3と対戦相手との対戦の開始前において、応援キャラクタとして、ユーザU1〜U3の各々の所有するイベントキャラクタのうちから複数のイベントキャラクタの設定(選択)を、ユーザU1〜U3の各々から受け付ける。また、選択受付部1301は、アクションパートの開始前において、アクションパートでの使用対象の応援キャラクタの選択をユーザU1〜U3の各々から受け付ける。さらに、選択制限部1303は、ユーザU1〜U3と対戦相手との対戦中において、ユーザU1〜U3の各々によって選択された応援キャラクタがユーザU1〜U3の各々によって再度選択されることを制限する。
[3−7−5]操作期間設定部1304はユーザが操作可能な操作期間を設定する。
[3−7−5−1]操作期間設定部1304は、複数のユーザが参加するゲームの実行中において、当該複数のユーザのうちの少なくとも一人が操作を行うことが可能な操作期間を設定する。例えば、操作期間設定部1304は、第1ユーザと第2ユーザとを含む複数のユーザが参加するゲームの実行中において、第1ユーザが操作を行うことが可能な操作期間を設定する。例えば、ゲームでは複数ユーザと対戦相手との対戦が行われ、操作期間設定部1304は上記操作期間を対戦中において設定する。
ここで、「操作」に関しては、選択受付部1301を説明した際にすでに説明しているため、ここでは省略する。
「複数のユーザのうちの少なくとも一人が操作を行うことが可能な操作期間」とは、例えば下記のような操作期間である。
(例1)複数のユーザのうちのいずれか一人のユーザのみがゲーム操作を行うことが可能な操作期間
(例2)複数のユーザのうちの複数のユーザがゲーム操作を行うことが可能な操作期間
(例2−1)例えば、第1ユーザと第2ユーザとの両方が同時にゲーム操作を行うことが可能な操作期間
(例2−2)また例えば、第1ユーザがゲーム操作を行うことが可能な第1操作期間と、当該第1操作期間の後に続けて設けられる操作期間であって、かつ、第1ユーザがゲーム操作を行うことが可能な第2操作期間とを含んでなる操作期間(すなわち、第1ユーザがゲーム操作を行った後で、第2ユーザがゲーム操作を行うような一連の操作期間)
「操作期間を設定する」とは、ゲームの途中において操作期間を設定することである。すなわち、ゲームの開始時よりも後であって、かつ、完了時よりも前の時点(場面又は期間等)において、ユーザがゲーム操作を行うことが可能な状態にすることである。
例えば、操作期間設定部1304は、所定の状況(所定条件を満足する状況)になった場合に操作期間を設定する。または、操作期間設定部1304は、ランダムに操作期間を設定するようにしてもよい。すなわち、操作期間設定部1304は、各時点(場面又は期間等)ごとに、操作期間として設定するか否かを所定の確率に基づいて決定するようにし、操作期間として設定すると決定された場合に操作期間を設定するようにしてもよい。なお、操作期間はゲーム中に複数回設定されるようにしてもよいし、1回のみ設定されるようにしてもよい。
操作期間設定部1304は特定の場面を操作期間として設定するようにしてもよい。例えば、野球ゲームの場合であれば、操作期間設定部1304は、特定選手の打席の場面や、ユーザのチームにとってチャンス又はピンチの場面を操作期間として設定するようにしてもよい。なお、操作期間設定部1304は打席単位で操作期間を設定してもよいし、イニング単位で操作期間を設定してもよい。例えば、操作期間設定部1304は、所定のイニング(所定条件を満足するイニング:特定打者から始まるイニング又は特定打者に打席がまわるイニング等)を操作期間として設定するようにしてもよい。また例えば、野球ゲーム以外のゲームであれば、操作期間設定部1304は、所定の時間長(例えば1分間等)を有する期間を操作期間として設定するようにしてもよい。
[3−7−5−2]操作期間設定部1304は、操作期間において操作を行うことが可能なユーザの人数を、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトに基づいて増加させる。
ここで、「ユーザの識別情報」に関しては、参加申込受付部120を説明した際にすでに説明しており、「ゲームオブジェクト」、及び「ユーザの識別情報と関連付けられたゲームオブジェクト」に関しては、選択受付部1301を説明した際にすでに説明しているため、ここでは省略する。
「操作期間において操作を行うことが可能なユーザの人数を、複数のユーザの各々のうちの識別情報と関連付けられたゲームオブジェクトに基づいて増加させる」とは、例えば、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトが所定条件を満足するか否かに基づいて、操作機会においてゲーム操作を行うことが可能なユーザの人数を増加させることである。より具体的には、例えば、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトが所定条件を満足する場合に、所定条件を満足しない場合に比べて、操作機会においてゲーム操作を行うことが可能なユーザの人数を増加することである。ここで、「所定条件」とは、例えば、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトのうちに特定のゲームオブジェクト(例えば、特定の能力を有するゲームオブジェクト)が含まれるか否かの条件である。なお、ゲームオブジェクトが特定の能力を有するか否かは、ゲームオブジェクトのデータ(パラメータ等)に基づいて判定される。
操作期間設定部1304は、操作期間において操作を行うことが可能なユーザの人数を、複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づいて増加させるようにしてもよい。例えば、操作期間設定部1304は、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトのうちから複数のユーザの各々によって選択されたゲームオブジェクトを取得し、当該取得されたゲームオブジェクトのうちの少なくとも一つに基づいて、操作期間において操作を行うことが可能なユーザの人数を増加させるようにしてもよい。
例えば、操作期間は、複数のユーザのうちの第1ユーザが操作を行うことが可能な第1操作期間を含む。そして、操作期間設定部1304は、複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づき、第1操作期間において、第1ユーザ以外の第2ユーザが操作を行うことも可能にする。または、操作期間設定部1304は、複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づき、第1操作期間に続けて、第1ユーザ以外の第2ユーザが操作を行うことが可能な第2操作期間を設定する。
ここで、「第1操作期間において、第1ユーザ以外の第2ユーザが操作を行うことも可能にする」とは、第1ユーザによる操作と第2ユーザによるゲーム操作との両方が受け付けられ、かつ、第1ユーザによる操作と第2ユーザによる操作とに基づいてゲームが進行されるような第1操作期間を設定することである。
また、「第1操作期間に続けて、第1ユーザ以外の第2ユーザがゲーム操作を行うことが可能な第2操作期間を設定する」とは、第1操作期間が完了した後に続けて、第2ユーザによる操作を受け付ける第2操作期間を設定することによって、第1操作期間と第2操作期間とを含んでなるような操作期間を設定することである。すなわち、第1ユーザによる操作が完了した後で、第2ユーザによる操作が行われるような一連の操作期間を設定することである。
例えば、操作期間設定部1304は、操作期間において操作を行うことが可能なユーザの人数を、支援ゲームオブジェクトとして選択されたゲームオブジェクトに基づいて増加させる。
先述の野球ゲームXでは、個々のアクションパートが「操作期間」の一例に相当し、アクションパートでの使用対象として選択された応援キャラクタが「支援ゲームオブジェクト」の一例に相当する。
操作期間設定部1304は、ユーザU1〜U3の少なくとも一人によってアクションパートでの使用対象として選択された応援キャラクタが応援効果として連係アクションを有する場合に、アクションパートで操作を行うことが可能なユーザの人数を増加させる。
すなわち、通常は、アクションパートにおいて、打者キャラクタの所有者であるユーザのみが操作(打者キャラクタに対する操作)を行うことができるところ、例えば、ユーザU1〜U3の少なくとも一人によって選択された応援キャラクタが応援効果として連係アクション「盗塁援護」を有する場合には、操作期間設定部1304は、アクションパートにおいて、打者キャラクタの所有者であるユーザと走者キャラクタの所有者であるユーザとがそれぞれ操作(打者キャラクタの操作と走者キャラクタの操作)を行うことができるようにする。また例えば、ユーザU1〜U3の少なくとも一人によって選択された応援キャラクタが応援効果として連係アクション「ピストル打線」を有する場合には、操作期間設定部1304は、アクションパートにおいて、打者キャラクタの所有者であるユーザと、その次の打者キャラクタの所有者であるユーザと、さらにその次の打者キャラクタの所有者であるユーザとがそれぞれ操作を行うことができるようにする。
[3−7−6]制御実行部1305は、複数のユーザが協力して目的の達成を目指すゲームに関して、目的の達成を目指す上で操作期間において有利となるようにするための制御を、当該複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトに基づいて実行する。例えば、制御実行部1305は、上記制御を、当該複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づいて実行する。具体的には、制御実行部1305は、上記制御を、支援ゲームオブジェクトとして選択されたゲームオブジェクトに基づいて実行する。
ここで、「目的の達成を目指す上で操作期間において有利となるようにするための制御を実行する」とは、目的の達成を目指す上でユーザが有利となるようにするための制御を実行することである。言い換えれば、目的が達成され易くなるように制御することである。
例えば、上記「制御を実行する」とは、目的の達成のしやすさに影響を及ぼすゲームパラメータを、目的が達成されやすくなるように変更することである。
具体的には、例えば、操作期間が「ユーザがゲームオブジェクトを操作するような操作期間」である場合、上記「制御を実行する」とは、ゲームオブジェクトの能力が向上するようにゲームオブジェクトのパラメータを向上させることである。
また、例えば、操作期間が「ユーザが第1ゲームオブジェクトを操作して、対戦相手によって操作される第2ゲームオブジェクトと対戦するような操作期間」である場合、上記「制御を実行する」とは、第2ゲームオブジェクトの能力が低下するように第2ゲームオブジェクトのパラメータを低下させることであってもよい。また、上記「制御を実行する」とは、ゲーム空間における環境に関する環境パラメータを、目的が達成しやすくなるように変更することであってもよい。
操作期間が「野球ゲームにおいてユーザが打者キャラクタを操作して、対戦相手によって操作される投手キャラクタが投げる球を打つような操作期間」である場合を想定する。この場合、上記「制御を実行する」とは、打者キャラクタの能力が向上するように打者キャラクタのパラメータを向上させること、投手キャラクタの能力が低下するように投手キャラクタのパラメータを低下させること、又は、球場の風向きや強さが打者キャラクタによって有利になるように(例えば風がスタンド方向に向かって吹くように、又は、スタンド方向に向かって吹く風が強くなるように)設定すること等である。
また、「支援ゲームオブジェクトとして選択されたゲームオブジェクトに基づいて制御を実行する」とは、制御内容(例えば、操作期間においてユーザを有利にする仕方又は程度)を、支援ゲームオブジェクトとして選択されたゲームオブジェクトに基づいて変えることである。例えば、支援ゲームオブジェクトとして選択されたゲームオブジェクトの性能(能力)に応じた仕方又は程度で、操作期間においてユーザを有利にすることである。
あるいは、「支援ゲームオブジェクトとして選択されたゲームオブジェクトに基づいて制御を実行する」とは、制御を実行するか否か(すなわち、操作期間においてユーザを有利にするか否か)を、支援ゲームオブジェクトとして選択されたゲームオブジェクトに基づいて決定することであってもよい。具体的には、例えば、支援ゲームオブジェクトとして選択されたゲームオブジェクトが所定条件を満足する場合に、操作期間においてユーザを有利にし、支援ゲームオブジェクトとして選択されたゲームオブジェクトが所定条件を満足しない場合に、操作期間においてユーザを有利にしないことであってもよい。より具体的には、支援ゲームオブジェクトとして選択されたゲームオブジェクトが特定の性能(能力)を有する場合に、操作期間においてユーザを有利にし、支援ゲームオブジェクトとして選択されたゲームオブジェクトが特定の性能(能力)を有しない場合に、操作期間においてユーザを有利にしないことである。
先述の野球ゲームXでは、個々のアクションパートが「操作期間」の一例に相当し、アクションパートでの使用対象として選択された応援キャラクタが「支援ゲームオブジェクト」の一例に相当する。
制御実行部1305は、ユーザU1〜U3の少なくとも一人によってアクションパートでの使用対象として選択された応援キャラクタの応援効果に基づいて、打者キャラクタや走者キャラクタの基本能力を一時的に上昇させたり、打者キャラクタや走者キャラクタに特殊能力を一時的に付与したりする。
[3−7−8]課題設定部1306は操作期間において達成されるべき課題を設定する。課題設定部1306は、複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づいて課題を設定する。例えば、課題設定部1306は、複数のユーザの各々によって選択されたゲームオブジェクトに基づいて課題を設定する。すなわち、課題設定部1306は、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトのうちから前記複数のユーザの各々によって選択されたゲームオブジェクトを取得し、当該取得されたゲームオブジェクトに基づいて課題を設定する。
ここで、「課題」とは、操作期間において操作を行うユーザが達成すべき課題である。また、「複数のユーザの各々によって選択されたゲームオブジェクトに基づいて課題を設定する」とは、複数のユーザの各々によって選択されたゲームオブジェクトに基づいて設定される、操作期間においてゲーム操作を行うことが可能なユーザの人数に合わせて課題を設定することである。すなわち、当該人数のユーザによって達成され得るような課題を設定することである。言い換えれば、当該人数のユーザが連係することによって達成され得るような課題を設定することである。
例えば、課題設定部1306は、支援ゲームオブジェクトとして選択されたゲームオブジェクトに基づいて課題を設定する。
先述の野球ゲームXでは、連係アクションのボーナス条件が「課題」の一例に相当する。ユーザU1〜U3の少なくとも一人によってアクションパートでの使用対象として選択された応援キャラクタが応援効果として連係アクションを有する場合に、課題設定部1306は当該連係アクションのボーナス条件を上記課題として設定する。
[3−7−9]ゲーム進行部1307は複数のユーザが参加するゲームを進行させる。
例えば、操作期間以外の期間において、ゲーム進行部1307は自動的にゲームを進行させる。言い換えれば、操作期間以外の期間において、ゲーム進行部1307は、上記複数のユーザのうちのすべてのユーザの操作を制限した状態でゲームを進行させる。
一方、上記複数のユーザのうちの一人のユーザが操作を行うことが可能な操作期間において、ゲーム進行部1307は、当該操作期間において当該少なくとも一人のユーザによって行われた操作に基づいて、ゲームを進行させる。例えば、第1ユーザが操作を行うことが可能な操作期間において、ゲーム進行部1307は、当該操作期間において第1ユーザによって行われた操作に基づいて、ゲームを進行させる。
ここで、「操作に基づいてゲームを進行させる」とは、操作がゲームの進行に影響を及ぼすようになっており、その結果、操作が、最終的に目的を達成できるか否かにも影響を及ぼすようになっていることである。
先述の野球ゲームXでは、ユーザU1〜U3と対戦相手との試合が「複数のユーザが参加するゲーム」の一例に相当し、アクションパートが「操作期間」の一例に相当する。このため、先述の野球ゲームXでは、ゲーム進行部1307は、自動進行パートにおいて試合を自動的に進行させ、アクションパートにおいてユーザの操作に基づいて試合を進行させる。例えば、ユーザU1が打者キャラクタ(又は投手キャラクタ)を操作可能なアクションパートにおいて、ゲーム進行部1307はユーザU1の操作に基づいて打者キャラクタ(又は投手キャラクタ)を動作させることによって、試合を進行させる。
[3−7−10]達成結果判定部1308は、操作期間における課題(すなわち、課題設定部1306によって設定された課題)の達成結果を判定する。
ここで、「課題の達成結果」とは、課題が達成されたか否かである。なお、「課題の達成結果」とは、課題の達成度(課題の達成の程度)であってもよい。
また、報酬関連付け部150は、達成結果判定部1308によって判定された課題の達成結果に基づいて、ゲームに参加した複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付けるようにしてもよい。
ここで、「課題の達成結果に基づいて、複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付ける」とは、例えば、複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付けるか否かを課題の達成結果に基づいて決定することである。具体的には、課題が達成された場合(又は課題の達成度が閾値以上である場合)に、複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付けると決定し、課題が達成されなかった場合(又は課題の達成度が閾値以上でない場合)に、複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付けないと決定することである。
また、「課題の達成結果に基づいて、複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付ける」とは、例えば、報酬の価値、種類、又は量等を課題の達成結果に基づいて決定することであってもよい。具体的には、課題の達成度が高いほど、報酬の価値が高くなるようにして、報酬を決定することであってもよい。すなわち、課題の達成度が高い場合には課題の達成度が低い場合に比べて報酬の価値が高くなるようにして、報酬を決定することであってもよい。または、課題の達成度が高いほど、報酬がユーザによってより有益になるようにして、報酬の種類を決定することであってもよい。すなわち、課題の達成度が高い場合には課題の達成度が低い場合に比べて報酬がユーザによってより有益になるようにして、報酬の種類を決定することであってもよい。あるいは、課題の達成度が高いほど、報酬の量が多くなるようにして、報酬の量を決定することであってもよい。すなわち、課題の達成度が高い場合には課題の達成度が低い場合に比べて報酬の量が多くなるようにして、報酬の量を決定することであってもよい。
また、「課題の達成結果に基づいて、複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付ける」とは、例えば、報酬を関連付けるユーザの人数(報酬を付与するユーザの人数)を課題の達成結果に基づいて決定することであってもよい。具体的には、課題の達成度が高いほど、報酬を関連付けるユーザの人数が多くなるようにして、報酬を関連付けるユーザの人数を決定することであってもよい。すなわち、課題の達成度が高い場合には課題の達成度が低い場合に比べて、報酬を関連付けるユーザの人数を多くすることであってもよい。
先述の野球ゲームXでは、連係アクションのボーナス条件が「課題」の一例に相当する。このため、達成結果判定部1308は、アクションパートにおけるプレイ結果に基づいて、ボーナス条件が満足されたか否かを判定する。そして、連係アクションのボーナス条件が満足された場合に、報酬関連付け部150は、ユーザU1〜U3のうちの連係アクションに関わったユーザに対して、連係アクションのボーナスポイントを付与する。
[4.処理]次に、上記に説明した機能ブロックを実現するためにゲームシステム1で実行される処理について説明する。
図39は、応援キャラクタを設定する際(図8のPH201)に実行される処理の一例を示す。具体的には、図10に示した応援キャラクタ設定画像G160の要素P162が選択された場合に実行される処理の一例を示す。図39に示す処理がプログラムに従って実行されることによって候補選択受付部1302が実現される。以下では、ユーザU1が要素P162を選択した場合を想定する。
図39に示すように、まず、ユーザU1のゲーム端末30−1の制御部31は応援キャラクタ登録要求を通信部33を介してサーバ10に送信し(S300)、サーバ10の制御部11は当該要求を通信部13を介して受信する(S100)。
「応援キャラクタ登録要求」は、応援キャラクタ設定画像G160で応援キャラクタとして設定されたイベントキャラクタを応援キャラクタとして登録することを要求するものである。例えば、ユーザU1のユーザIDと、応援キャラクタとして設定されたイベントキャラクタのイベントキャラクタIDとが応援キャラクタ登録要求としてゲーム端末30−1からサーバ10に送信される。
応援キャラクタ登録要求が受信された場合、制御部11はイベントキャラクタを応援キャラクタとして登録する(S102)。例えば、制御部11は、ユーザU1のイベントキャラクタテーブルTBL102にアクセスして「使用状態」フィールドを更新することによって、イベントキャラクタを応援キャラクタとして登録する。
ステップS102の実行後、制御部11は、応援キャラクタの登録が完了したことを示す完了画像のデータを通信部13を介してゲーム端末30−1に送信し(S104)、ゲーム端末30−1の制御部31は当該データを通信部33を介して受信する(S302)。そして、当該データに基づいて、制御部31は完了画像を表示部35に表示する(S304)。なお、「画像のデータ」とは、画像自体を示すデータであってもよいし、画像を生成するために必要な情報を示すデータであってもよい。以下でも同様である。
図40は、チームを作成する際(図8のPH202)に実行される処理の一例を示す。以下では、ユーザU1がチームを作成する場合を想定する。
図40に示すように、まず、ユーザU1のゲーム端末30−1の制御部31はチーム作成要求を通信部33を介してサーバ10に送信し(S310)、サーバ10の制御部11は当該要求を通信部13を介して受信する(S110)。例えば、ユーザU1のユーザIDがチーム作成要求としてゲーム端末30−1からサーバ10に送信される。
チーム作成要求が受信された場合、制御部11はチームを新規作成する(S112)。例えば、制御部11はチームテーブルTBL104にアクセスして新規レコードを追加する。この場合、既存のチームIDと重複しないようにして生成されるチームIDが新規レコードの「チームID」フィールドに登録される。また、ユーザU1のユーザID及び対戦レベルが新規レコードの「ホストユーザ」及び「対戦レベル」フィールドにそれぞれ登録される。さらに、値「0」が新規レコードの「助っ人要請フラグ」及び「受付完了フラグ」フィールドにそれぞれ登録される。
ステップS112の実行後、制御部11は待受画像G180のデータを通信部13を介してゲーム端末30−1に送信し(S114)、ゲーム端末30−1の制御部31は当該データを通信部33を介して受信する(S312)。そして、当該データに基づいて、制御部31は待受画像G180を表示部35に表示する(S314)。
図41は、助っ人要請を行う際に実行される処理の一例を示す。具体的には、図12に示した待受画像G180の要素P184が選択された場合に実行される処理の一例を示す。図41に示す処理がプログラムに従って実行されることによって参加要請受付部110が実現される。以下では、ユーザU1が要素P184を選択した場合を想定する。
図41に示すように、まず、ユーザU1のゲーム端末30−1の制御部31は助っ人要請を通信部33を介してサーバ10に送信し(S320)、サーバ10の制御部11は当該要請を通信部13を介して受信する(S120)。例えば、ユーザU1のユーザIDや、助っ人要請の対象のチームのチームIDが助っ人要請としてゲーム端末30−1からサーバ10に送信される。
助っ人要請が受信された場合、制御部11は助っ人要請を登録する(S122)。例えば、制御部11はチームテーブルTBL104にアクセスして、助っ人要請の対象のチームの助っ人要請フラグを「1」に更新する。
ステップS122の実行後、制御部11は、助っ人要請の登録が完了したことを示す完了画像のデータを通信部13を介してゲーム端末30−1に送信し(S124)、ゲーム端末30−1の制御部31は当該データを通信部33を介して受信する(S322)。そして、当該データに基づいて、制御部31は完了画像を表示部35に表示する(S324)。
図42は、通常参加者としての参加申込みを受け付ける際(図8のPH203)に実行される処理の一例を示す。図42に示す処理がプログラムに従って実行されることによって参加申込受付部120(第1参加申込受付部121)が実現される。以下では、ユーザU2が他のユーザの作成したチームに通常参加者として参加しようとする場合を想定する。
図42に示すように、まず、ユーザU2のゲーム端末30−2の制御部31はチームリスト要求を通信部33を介してサーバ10に送信し(S330)、サーバ10の制御部11は当該要求を通信部13を介して受信する(S130)。「チームリスト要求」は、ユーザU2が参加可能なチームのリストを要求するものである。例えば、ユーザU2のユーザIDがチームリスト要求としてゲーム端末30−2からサーバ10に送信される。
チームリスト要求が受信された場合、制御部11はユーザテーブルTBL101にアクセスし、ユーザU2の対戦レベルを取得する(S132)。その後、制御部11はチームテーブルTBL104にアクセスし、ユーザU2が参加可能なチームのリストを取得する(S134)。具体的には、制御部11は、対戦レベルがユーザU2の対戦レベル以下であり、かつ、受付完了フラグが「0」であるチームのリストを取得する。
ステップS134の実行後、制御部11は、ステップS134で取得されたチームのリストを示すチームリスト画像G190のデータを通信部13を介してゲーム端末30−2に送信し(S136)、ゲーム端末30−2の制御部31は当該データを通信部33を介して受信する(S332)。そして、当該データに基づいて、制御部31はチームリスト画像G190を表示部35に表示する(S334)。
チームリスト画像G190に表示されるいずれかのチーム(すなわち、要素P191−1〜P191−4のいずれか)がユーザU2によって選択された場合、ゲーム端末30−2の制御部31は、選択されたチームのチームIDを通信部33を介してサーバ10に通知し(S336)、サーバ10の制御部11は当該通知を通信部13を介して受信する(S138)。
上記通知が受信された場合、制御部11は、ユーザU2によって選択されたチームへの参加を申し込むことが可能な参加申込画像G200のデータを通信部13を介してゲーム端末30−2に送信し(S140)、ゲーム端末30−2の制御部31は当該データを通信部33を介して受信する(S338)。そして、当該データに基づいて、制御部31は参加申込画像G200を表示部35に表示する(S340)。
参加申込画像G200の要素P205がユーザU2によって選択された場合、ゲーム端末30−2の制御部31は参加申込みを通信部33を介してサーバ10に送信し(S342)、サーバ10の制御部11は当該参加申込みを通信部13を介して受信する(S142)。例えば、ユーザU2のユーザIDと、参加申込みの対象のチームのチームIDと、通常参加者としての参加申込みであることを示す情報とが参加申込みとしてゲーム端末30−2からサーバ10に送信される。
参加申込みが受信された場合、制御部11は、参加申込みの対象のチームへの通常参加者としてユーザU2を登録する(S144)。例えば、制御部11はチームテーブルTBL104にアクセスし、参加申込みの対象のチームの「参加者1」フィールドに他のユーザが登録されていなければ、当該「参加者1」フィールドにユーザU2を登録し、当該「参加者1」フィールドに他のユーザが登録されていれば、「参加者2」フィールドにユーザU2を登録する。この際、ユーザU2のユーザIDを「ユーザID」サブフィールドに登録し、値「0」を「助っ人フラグ」サブフィールドに登録する。
ステップS144の実行後、制御部11は待受画像G180のデータを通信部13を介してゲーム端末30−2に送信し(S146)、ゲーム端末30−2の制御部31は当該データを通信部33を介して受信する(S344)。そして、当該データに基づいて、制御部31は待受画像G180を表示部35に表示する(S346)。
図43は、助っ人参加者としての参加申込みを受け付ける際(図8のPH203)に実行される処理の一例を示す。図43に示す処理がプログラムに従って実行されることによって参加申込受付部120(第2参加申込受付部122)が実現される。以下では、ユーザU3が他のユーザが作成したチームに助っ人参加者として参加しようとする場合を想定する。
図43に示すように、まず、ユーザU3のゲーム端末30−3の制御部31は助っ人要請リスト要求を通信部33を介してサーバ10に送信し(S350)、サーバ10の制御部11は当該要求を通信部13を介して受信する(S150)。「助っ人要請リスト要求」は、ユーザU3が応じることが可能な助っ人要請のリストを要求するものである。例えば、ユーザU3のユーザIDが助っ人要請リスト要求としてゲーム端末30−3からサーバ10に送信される。
助っ人要請リスト要求が受信された場合、制御部11はユーザテーブルTBL101にアクセスし、ユーザU3の対戦レベルを取得する(S152)。その後、制御部11はチームテーブルTBL104にアクセスし、ユーザU3が応じることが可能な助っ人要請のリストを取得する(S154)。具体的には、制御部11は、対戦レベルがユーザU3の対戦レベル未満であり、助っ人要請フラグが「1」であり、かつ、受付完了フラグが「0」であるチームのリストを取得する。
ステップS154の実行後、制御部11は、ステップS154で取得されたチームのリストを示す助っ人要請リスト画像G210のデータを通信部13を介してゲーム端末30−3に送信し(S156)、ゲーム端末30−3の制御部31は当該データを通信部33を介して受信する(S352)。そして、当該データに基づいて、制御部31は助っ人要請リスト画像G210を表示部35に表示する(S354)。
助っ人要請リスト画像G210に表示されるいずれかのチーム(すなわち、要素P211−1,P211−2のいずれか)がユーザU3によって選択された場合、ゲーム端末30−3の制御部31は、選択されたチームのチームIDを通信部33を介してサーバ10に通知し(S356)、サーバ10の制御部11は当該通知を通信部13を介して受信する(S158)。これらの処理は図42のステップS336及びステップS138と同様である。
上記通知が受信された場合、制御部11は、ユーザU3によって選択されたチームへの参加を申し込むことが可能な助っ人参加申込画像G220のデータを通信部13を介してゲーム端末30−3に送信し(S160)、ゲーム端末30−3の制御部31は当該データを通信部33を介して受信する(S358)。そして、当該データに基づいて、制御部31は助っ人参加申込画像G220を表示部35に表示する(S360)。
助っ人参加申込画像G220の要素P225がユーザU3によって選択された場合、ゲーム端末30−3の制御部31は参加申込みを通信部33を介してサーバ10に送信し(S362)、サーバ10の制御部11は当該参加申込みを通信部13を介して受信する(S162)。例えば、ユーザU3のユーザIDと、参加申込みの対象のチームのチームIDと、助っ人参加者としての参加申込みであることを示す情報とが参加申込みとしてゲーム端末30−3からサーバ10に送信される。
参加申込みが受信された場合、制御部11は、参加申込みの対象のチームへの助っ人参加者としてユーザU3を登録する(S164)。例えば、制御部11はチームテーブルTBL104にアクセスし、参加申込みの対象のチームの「参加者1」フィールドに他のユーザが登録されていなければ、当該「参加者1」フィールドにユーザU3を登録し、当該「参加者1」フィールドに他のユーザが登録されていれば、「参加者2」フィールドにユーザU3を登録する。この際、ユーザU3のユーザIDを「ユーザID」サブフィールドに登録し、値「1」を「助っ人フラグ」サブフィールドに登録する。
ステップS164の実行後、制御部11は待受画像G180のデータを通信部13を介してゲーム端末30−2に送信し(S166)、ゲーム端末30−2の制御部31は当該データを通信部33を介して受信する(S364)。そして、当該データに基づいて、制御部31は待受画像G180を表示部35に表示する(S366)。
図44及び図45は、試合フェーズ(図8のPH21)においてゲームシステム1で実行される処理の一例を示す。すなわち、試合を開始してから終了するまでに実行される処理の一例を示す。図44及び図45に示す処理がプログラムに従って実行されることによってゲーム実行部130、報酬決定部140、及び報酬関連付け部150が実現される。以下では、ユーザU1〜U3と対戦相手(CPU)との試合が実行される場合を想定する。
なお、図44及び図45に示す処理は、ユーザU1〜U3のゲーム端末30−1〜30−3のいずれか又はサーバ10がマスター装置として機能することによって実行される。ここで、「マスター装置」とはスレーブ装置を制御する装置である。例えば、ゲーム端末30−1〜30−3のいずれかがマスター装置として機能する場合には他のゲーム端末30がスレーブ装置となる。また例えば、サーバ10がマスター装置として機能する場合にはゲーム端末30−1〜30−3の各々がスレーブ装置となる。マスター装置はゲームサーバの役割を担う。例えば、ゲーム端末30−1〜30−3のいずれかがマスター装置として機能する場合、マスター装置は、各スレーブ装置で行われた操作に関する情報を各スレーブ装置から受信し、マスター装置で行われた操作と、各スレーブ装置で行われた操作とに基づいて、現在の試合状況を更新し、更新された状況を示す情報を各スレーブ装置に送信する。このようにすることによって、ゲーム端末30−1〜30−3で試合状況が共有される。以下では、ホストであるユーザU1のゲーム端末30−1がマスター装置として機能し、ユーザU2,U3のゲーム端末30−2,30−3がスレーブ装置として機能する場合について説明する。
図44に示すように、まず、ゲーム端末30−1の制御部31は、試合状況テーブルTBL105、選手キャラクタテーブルTBL106、及び、応援キャラクタテーブルTBL107を初期設定する(S1000)。そして、制御部31はユーザU1〜U3の各々の勢いポイントの初期値を算出する(S1002)。
例えば、制御部31は、ユーザチームの選手キャラクタのうちの、ユーザU1の所有する選手キャラクタのオリジナル能力パラメータに基づいて、ユーザU1の勢いポイントの初期値を算出する。ユーザU1の所有する選手キャラクタの能力が高いほど、ユーザU1の勢いポイントの初期値が大きくなるようにして、ユーザU1の勢いポイントの初期値が算出される。すなわち、ユーザU1の所有する選手キャラクタの能力が高い場合には、当該能力が低い場合に比べて、ユーザU1の勢いポイントの初期値が大きくなるようにして、ユーザU1の勢いポイントの初期値が算出される。ユーザU2,U3の各々の勢いポイントの初期値も同様にして算出される。なお、制御部11は、ユーザU1〜U3の各々の勢いポイントの和をユーザチームの勢いポイントとして取得する。また、制御部11は、CPUチームの選手キャラクタのオリジナル能力パラメータに基づいて、対戦相手チームの勢いポイントとして算出する。
ステップS1002の実行後、制御部31は試合開始画像を表示部35に表示する(S1004)。この際、制御部31は、試合開始画像を表示部35に表示するようにゲーム端末30−2,30−3にも指示する。その後、制御部31は自動進行パート画像G240を表示部35に表示する(S1006)。この際、制御部31は、自動進行パート画像G240を表示部35に表示するようにゲーム端末30−2,30−3にも指示する。
そして、制御部31は試合を自動進行させる(S1008)。例えば、制御部31は、仮想空間内で、ユーザチームの選手キャラクタと対戦相手チームの選手キャラクタとの両方を、それらの選手キャラクタの能力パラメータ(現在能力パラメータ)に基づいて仮想的に動作させることによって、試合状況を自動的に更新していく。制御部31はこのようにして自動的に更新される試合状況を自動進行パート画像G240に表示する。また、制御部31はこのようにして自動的に更新される試合状況をゲーム端末30−2,30−3にも伝える。これにより、ゲーム端末30−2,30−3の表示部35に表示される自動進行パート画像G240も更新される。
試合の自動進行中、制御部31は試合の状況が所定の状況になったか否かを監視する(S1010)。ここで、「所定の状況」とは、アクションパートに切り替えるべき状況である。試合の状況が所定の状況になっていない場合、制御部31は試合が終了したか否かを判定する(S1012)。
試合が終了した場合、制御部31はユーザU1〜U3の各々の貢献ポイントを決定する(S1014)。例えば、ユーザU1〜U3の各々の貢献ポイントは、試合終了時のユーザU1〜U3の各々の勢いポイントに基づき、先述の算出式(1)に従って算出される。なお、算出されたユーザU1〜U3の各々の貢献ポイントはサーバ10に通知され、サーバ10では、ユーザテーブルTBL101にアクセスして、算出されたユーザU1〜U3の各々の貢献ポイントがユーザU1〜U3の各々の「貢献ポイント」フィールドの値に加算される。そして、ステップS1014の実行後、制御部31は試合結果画像G300を表示部35に表示する(S1016)。この際、制御部31は、試合結果画像G300を表示部35に表示するようにゲーム端末30−2,30−3にも指示する。この場合、本処理は終了する。
一方、試合が終了していない場合、制御部31はステップS1008に戻り、試合を自動進行し続ける。すなわち、制御部31は自動進行パートを続行する。
現在の試合状況が所定の状況である場合、図45に示すように、制御部31はアクションパートに切り替えるか否かを決定する(S1018)。例えば、制御部31はアクションパートに切り替えるか否かを確率情報に基づいて決定する。アクションパートに切り替えると決定される確率は、アクションパートに切り替えないと決定される確率よりも低く設定される。このように設定された確率情報に基づいて、制御部31はアクションパートに切り替えるか否かを決定する。
ステップS1018では、一つの試合中におけるアクションパートの回数が所定回数になるように制御される。また、一つの試合中におけるユーザU1〜U3の各々のアクションパートの回数が等しくなるように制御される。
例えば、一つの試合中におけるアクションパートの回数が3回になるように制御される。具体的には、例えば、1回表〜3回裏の間で1回のアクションパートが必ず発生し、4回表〜6回裏の間で1回のアクションパートが必ず発生し、7回表〜9回裏の間で1回のアクションパートが発生するように制御される。
1回表〜3回裏のうちのいずれかのタイミングでアクションパートが発生した場合には、それ以降、3回裏が終了するまでの間、ステップS1018では、確率情報に関係なく、アクションパートに切り替えないと決定される。4回表〜6回裏の間や7回表〜9回裏の間も同様である。
また、1回表〜3回裏のうちのいずれかのタイミングでユーザU1のアクションパートが発生した場合には、それ以降、ステップS1018では、ユーザU1の所有する選手キャラクタが打者又は投手である状況では、確率情報に関係なく、アクションパートに切り替えないと決定される。
また、1回表〜3回裏の間でアクションパートが発生する可能性が低い状況になった場合には、アクションパートが発生し易くなるように制御するようにしてもよい。例えば、3回表の開始時までアクションパートが発生していない場合には、1回表〜3回裏の間でアクションパートが発生する可能性が低い状況になったとみなして、アクションパートに切り替えると決定される確率を通常よりも高めるようにしてもよい。4回表〜6回裏の間や7回表〜9回裏の間も同様である。
また、いずれかのユーザのアクションパートが発生する可能性が低い状況になった場合には、アクションパートが発生し易くなるように制御するようにしてもよい。すなわち、当該ユーザの所有する選手キャラクタが打者又は投手である状況で、アクションパートに切り替えると決定される確率を通常よりも高めるようにしてもよい。
1回表〜3回裏の間で1回のアクションパートが必ず発生するように制御することは必須ではない。すなわち、1回表〜3回裏の間でアクションパートが発生しない場合が生じるようにしてもよい。1回表〜3回裏の間でアクションパートが発生しなかった場合には、4回表〜9回裏の間で3回のアクションパートが発生するようにすればよい。またこの場合、4回表〜9回裏の間で3回のアクションパートが発生しなくなってしまうことを避けるべく、4回表〜9回裏の間ではアクションパートが発生し易くなるようにしてもよい。また、一つの試合中におけるユーザU1〜U3の各々のアクションパートの回数が等しくなるように制御することも必須ではない。
なお、ステップS1010,S1018では、試合状況が所定の状況になったか否かを判定し、試合状況が所定の状況になったら、アクションパートに切り替えるか否かを決定するようになっていたが、このような処理に代えて、試合状況に関係なく、特定のタイミング(例えば3回、6回、9回の開始時等)になった場合にアクションパートに切り替えると決定するような処理を実行するようにしてもよい。
ステップS1018でアクションパートに切り替えないと決定された場合、制御部31はステップS1008に戻って自動進行パートを続行する。一方、ステップS1018でアクションパートに切り替えると決定された場合、制御部31はアクションパート開始画像G250を表示部35に表示する(S1020)。この際、制御部31は、アクションパート開始画像G250を表示部35に表示するようにゲーム端末30−2,30−3にも指示する。
その後、制御部31はユーザU1〜U3の各々から応援キャラクタの選択を受け付ける(S1022)。すなわち、制御部31は応援キャラクタ選択画像G260を表示部35に表示させる。この際、制御部31は、応援キャラクタ選択画像G260を表示部35に表示するようにゲーム端末30−2,30−3にも指示する。
なお、ゲーム端末30−1で表示される応援キャラクタ選択画像G260では、事前にユーザU1によって応援キャラクタとして設定されたイベントキャラクタが、ユーザU1によって選択可能な応援キャラクタとして表示される。
同様に、ゲーム端末30−2で表示される応援キャラクタ選択画像G260では、事前にユーザU2によって応援キャラクタとして設定されたイベントキャラクタが、ユーザU2によって選択可能な応援キャラクタとして表示される。また、ユーザU2によっていずれかの応援キャラクタが選択された場合、ユーザU2の選択結果(ユーザU2によって選択された応援キャラクタのイベントキャラクタID)がゲーム端末30−2からゲーム端末30−1に通知される。ユーザU3及びゲーム端末30−3に関しても同様である。
ユーザU1〜U3のすべてが応援キャラクタの選択を完了した場合、制御部31は、応援効果として連係アクションが設定された応援キャラクタが選択され、かつ、当該連係アクションの発動条件が満足されているか否かを判定する(S1024)。
例えば、応援効果として連係アクション「ピストル打線」が設定された応援キャラクタが選択された場合を想定する。「ピストル打線」には発動条件が設定されていないため、この場合、制御部11は、応援効果として連係アクションが設定された応援キャラクタが選択され、かつ、当該連係アクションの発動条件が満足されていると判定する。
また例えば、応援効果として連係アクション「盗塁援護」が設定された応援キャラクタが選択された場合を想定する。「盗塁援護」には発動条件として「一塁、二塁の少なくとも一方に走者がいる」が設定されているため、制御部31は、現在の状況が一塁、二塁の少なくとも一方に走者がいる状況であるか否かを判定する。現在の状況が一塁、二塁の少なくとも一方に走者がいる状況であれば、制御部31は、応援効果として連係アクションが設定された応援キャラクタが選択され、かつ、当該連係アクションの発動条件が満足されていると判定する。
応援効果として連係アクションが設定された応援キャラクタが選択され、かつ、当該連係アクションの発動条件が満足されている場合、制御部31は、連係アクションの発動の有無の選択を受け付ける(S1026)。制御部31は、発動選択画像G270を、連係アクションを発動させるか否かを選択可能なユーザのゲーム端末30の表示部35に表示する。例えば、ホストであるユーザU1が連係アクションを発動させるか否かを選択可能である場合には、制御部31は発動選択画像G270をゲーム端末30−1の表示部35に表示する。なお、この場合、ゲーム端末30−2,30−3の表示部35にも、発動選択画像G270を、ユーザU2,U3による選択を不可の状態で表示することによって、ユーザU1による選択をユーザU2,U3が見ることができるようにしてもよい。
ステップS1026の実行後、制御部31は、ステップS1022で選択された応援キャラクタに設定された応援効果を発生させる(S1028)。
例えば、ステップS1022で選択された応援キャラクタがユーザチームの選手キャラクタの基本能力を上げる応援効果を有している場合、制御部31はユーザチームの選手キャラクタテーブルTBL106にアクセスし、「現在能力パラメータ」フィールドに記憶された基本能力パラメータの値を上げる。
また例えば、ステップS1022で選択された応援キャラクタがユーザチームの選手キャラクタに特殊能力を付与する応援効果を有している場合、制御部31はユーザチームの選手キャラクタテーブルTBL106にアクセスし、「現在能力パラメータ」フィールドに記憶された特殊能力パラメータを更新する。
なお、これらの場合、アクションパートでユーザによって操作される選手キャラクタの基本能力パラメータや特殊能力パラメータを更新するようにすればよい。すなわち、ユーザチームの攻撃時であれば、打者である選手キャラクタの基本能力パラメータ又は特殊能力パラメータを更新し、ユーザチームの守備時であれば、投手である選手キャラクタの基本能力パラメータ又は特殊能力パラメータを更新するようにすればよい。
また例えば、ステップS1022で選択された応援キャラクタが対戦相手チームの選手キャラクタの基本能力を下げる応援効果を有している場合、制御部31は対戦相手ユーザチームの選手キャラクタテーブルTBL106にアクセスし、「現在能力パラメータ」フィールドに記憶された基本能力パラメータの値を下げる。
また例えば、ステップS1022で選択された応援キャラクタが対戦相手チームの選手キャラクタに特殊能力を無効にする応援効果を有している場合、制御部31は対戦相手チームの選手キャラクタテーブルTBL106にアクセスし、「現在能力パラメータ」フィールドに記憶された特殊能力パラメータを更新する。
なお、アクションパートがユーザチームの攻撃時であれば、対戦相手チームの投手の選手キャラクタの基本能力パラメータ又は特殊能力パラメータを更新し、ユーザチームの守備時であれば、対戦相手チームの打者である選手キャラクタの基本能力パラメータ又は特殊能力パラメータを更新するようにすればよい。
また、連係アクションが発動された場合(すなわち、ステップS1022で選択された応援キャラクタが応援効果として連係アクションを有しており、かつ、ステップS1026で当該連係アクションを発動することが選択された場合)、制御部31は、発動された連係アクションに応じてアクションパートの設定を変更する。
例えば、発動された連係アクションが「ピストル打線」である場合、制御部31は、当該アクションパートにおいて、1打席の操作だけではなく、連続して3打席の操作を行うことができるようにアクションパートの終了条件を変更する。
また例えば、発動された連係アクションが「盗塁援護」である場合、制御部31は、当該アクションパートにおいて、打者キャラクタの操作だけでなく、走者キャラクタの操作も行うことができるようにアクションパートにおける操作対象を変更する。
なお、発動された連係アクションには、ユーザチームの選手キャラクタの基本能力を上げる応援効果、ユーザチームの選手キャラクタに特殊能力に付与する応援効果、対戦相手チームの選手キャラクタの基本能力を下げる応援効果、又は、対戦相手チームの選手キャラクタの特殊能力を無効にする応援効果等が設定されている場合がある(図22参照)。このような場合には、先述の場合と同様して、ユーザチーム又は対戦相手チームの選手キャラクタテーブルTBL106の「現在能力パラメータ」フィールドに記憶された基本能力パラメータ又は特殊能力パラメータが更新される。
ステップS1028の実行後、制御部31はアクションパート画像G280を表示部35に表示する(S1030)。アクションパート画像G280の表示中、制御部31はアクションパートを実行する。この際、制御部31は、アクションパート画像G280を表示部35に表示するようにゲーム端末30−2,30−3にも指示する。
例えば、図24に示すアクションパート画像G280が表示されている場合、制御部31は、所定のアルゴリズム(AI等)に従って、対戦相手チームの投手キャラクタPC2に動作(投球動作等)を行わせる。また、ユーザチームの打者キャラクタPC1がユーザU1によって操作される場合、制御部31は操作部34を用いて行われるユーザU1の操作を受け付け、当該操作に応じて、打者キャラクタPC1に動作(打撃動作等)を行わせる。なお、打者キャラクタPC1がユーザU2又はU3によって操作される場合、制御部31は、ゲーム端末30−2又は30−3の操作部34を用いて行われたユーザU2又はU3の操作を示すデータをゲーム端末30−2又は30−3から受信し、当該操作に応じて、打者キャラクタPC1に動作(打撃動作等)を行わせる。なお、この場合、試合状況の変化がゲーム端末30−2,30−3に通知されることによって、ゲーム端末30−2,30−3の表示部35に表示されるアクションパート画像G280が更新される。あるいは、更新されたアクションパート画像G280がゲーム端末30−2,30−3に送信されることによって、ゲーム端末30−2,30−3の表示部35に表示されるアクションパート画像G280が更新される。
制御部31はアクションパートが終了したか否かを監視する(S1032)。アクションパートが終了した場合、制御部11は、発動された連係アクションのボーナス条件が満足されたか否かを判定する(S1034)。
例えば、発動された連係アクションが「ピストル打線」である場合、「ピストル打線」のボーナス条件は「2安打」であるため、アクションパートにおけるユーザチームの安打数が2安打以上であるか否かが判定される。そして、アクションパートにおけるユーザチームの安打数が2安打以上であれば、「ピストル打線」のボーナス条件が満足されたと判定される。
また例えば、発動された連係アクションが「盗塁援護」である場合、「盗塁援護」のボーナス条件は「打者が空振りして、走者が盗塁に成功」であるため、アクションパートにおいて、走者キャラクタが盗塁した際にユーザチームの打者キャラクタが空振りし、かつ、走者キャラクタが盗塁に成功すれば、「盗塁援護」のボーナス条件が満足されたと判定される。
そして、制御部31は試合状況テーブルTBL105にアクセスし、アクションパートで操作を行ったユーザの勢いポイントを増加させる(S1036)。
ここで、アクションパートでユーザU1が打者キャラクタを操作した場合を想定する。この場合、ユーザU1の勢いポイントは、アクションパートでのユーザU1の操作結果(プレイ結果)に基づいて増加される。すなわち、ユーザU1の勢いポイントは、アクションパートでユーザU1が収めた成績に基づいて増加される。例えば、成績が良い場合には、成績が悪い場合に比べて、ユーザU1の勢いポイントの増加量が多くなる。また例えば、成績が良い場合にはユーザU1の勢いポイントが増加され、成績が悪い場合にはユーザU1の勢いポイントが増加されない。
具体的には、例えば、打者キャラクタが安打を打った場合にはユーザU1の勢いポイントが増加され、打者キャラクタがアウトになった場合にはユーザU1の勢いポイントが増加されない。また例えば、打者キャラクタが本塁打を打った場合には、打者キャラクタが単打を打った場合に比べて、ユーザU1の勢いポイントの増加量が多くなる。
さらに、発動された連係アクションが成功した場合、連係アクションに関わったユーザの勢いポイントに成功ボーナスポイントが加算される。例えば、発動された連係アクションが「ピストル打線」であれば、3打席の各々において打者キャラクタの操作を行った各ユーザの勢いポイントに成功ボーナスポイント(60)が加算される(図22参照)。また例えば、発動された連係アクションが「盗塁援護」であれば、打者キャラクタの操作を行ったユーザと、走者キャラクタの操作を行ったユーザとの勢いポイントに成功ボーナス(50)が加算される(図22参照)。
ステップS1036の実行後、制御部31はアクションパート結果画像G290を表示する(S1038)。この際、制御部31は、アクションパート結果画像G290を表示部35に表示するようにゲーム端末30−2,30−3にも指示する。その後、制御部31はステップS1006を実行する。つまり、制御部31は自動進行パートを再開する。
[5.まとめ]以上に説明したゲームシステム1では、ユーザU1が操作を行うことが可能なアクションパートにおいて、ユーザU2によって選択された応援キャラクタに基づいて、ユーザU1が操作する選手キャラクタの能力が上がる。このため、ユーザU2は応援キャラクタを選択することによって、ユーザU1のアクションパートに関与できる。すなわち、ユーザU1のアクションパートにおいて、主要な操作を行うユーザU1以外のユーザU2が試合の進行に関与する度合いを向上させることが可能になる。
またゲームシステム1では、ユーザU2は自分の所有するイベントキャラクタのうちから少なくとも一つを応援キャラクタとして選択できる。その結果、ユーザU1のアクションパートでユーザU1をより有利にするようなイベントキャラクタを入手しようとする動機付けをユーザU2に与えることが可能になる。
またゲームシステム1では、一人プレイパートがユーザによってプレイされる場合、ユーザの所有するイベントキャラクタが当該一人プレイパートで利用され、協力プレイパートがユーザによってプレイされる場合にもユーザの所有するイベントキャラクタが当該協力プレイパートで利用される。すなわち、イベントキャラクタが、一人プレイパートではイベントデッキに組み込んで利用され、協力対戦パートでは応援キャラクタとして利用される。ゲームシステム1によれば、一人プレイパートで利用されるイベントキャラクタが協力対戦パートで応援キャラクタとして流用できるようになる。
またゲームシステム1では、例えば、ユーザU2によって、試合の開始前に、応援キャラクタとして複数のイベントキャラクタが設定され(図10)、アクションパートごとに、当該アクションパートで使用する応援キャラクタとして、それら複数の応援キャラクタのうちから少なくとも一つが選択される(図21,27)。このため、ゲームシステム1によれば、事前に試合の展開を予測して応援キャラクタを設定するという興趣と、それら事前に設定した応援キャラクタのうちから、アクションパートごとに、当該アクションパートの場面に合わせて、当該アクションパートで使用する応援キャラクタを選択するという興趣とをユーザU2に提供することが可能になり、応援キャラクタの設定・選択に関する興趣を向上することが可能になる。
またゲームシステム1では、ユーザU1〜U3の各々の所有する応援キャラクタに基づいて、アクションパートで応援効果(連係アクション「ピストル打線」又は「盗塁援護」等)が発動することによって、アクションパートで操作を行うことが可能なユーザの人数が増加する。その結果として、ユーザ同士で協力して対戦相手と対戦する興趣をユーザU1〜U3に実感させることが可能になる。
具体的には、ユーザU1〜U3の各々の所有する応援キャラクタのうちから、ユーザU1〜U3のうちの少なくとも一人によって選択された応援キャラクタの有する応援効果(連係アクション「ピストル打線」又は「盗塁援護」等)に基づいて、アクションパートで操作を行うことが可能なユーザの人数が増加される。その結果、アクションパートの場面に合わせて、上記のような応援効果を有するような応援キャラクタを選択するという興趣を提供することが可能になる。
例えば、連係アクション「盗塁援護」が発動されると、ユーザU1が打者キャラクタを操作するアクションパートでユーザU2が走者キャラクタを操作することが可能になり、ユーザU1,U2が連係して操作を行うことが可能になる。その結果として、ユーザ同士で連係して勝利を目指す興趣をユーザU1,U2に実感させることが可能になる。
また例えば、連係アクション「ピストル打線」が発動されると、3打席連続のプレイが可能になり、その結果、例えば、ユーザU1の所有する選手キャラクタの次の打者がユーザU2の所有する選手キャラクタであり、かつ、さらにその次の打者がユーザU3の所有する選手キャラクタである場合に、ユーザU1による打者キャラクタの操作に続けて、ユーザU2による打者キャラクタの操作が行われ、さらにそれに続けて、ユーザU3による打者キャラクタの操作が行われるようになる。すなわち、ユーザU1とユーザU2とユーザU3とが続けて操作を行うことが可能になり、その結果として、ユーザ同士で連係して勝利を目指す興趣をユーザU1,U2,U3に実感させることが可能になる。
またゲームシステム1では、例えば、ユーザU1〜U3のいずれかによって選択された応援キャラクタが連係アクション「ピストル打線」又は「盗塁援護」を有していると、「ピストル打線」又は「盗塁援護」を発動させることが可能になり、「ピストル打線」又は「盗塁援護」が発動されるとボーナス条件が設定され、ボーナス条件が達成されると、当該連係アクションに関わったユーザの勢いポイントにボーナスポイントが付与される。ゲームシステム1によれば、ボーナス条件を踏まえて応援キャラクタを選択するという興趣をユーザに提供することが可能になる。また、ユーザ同士が連係してボーナス条件の達成を目指すという興趣をユーザに提供することが可能になる。
またゲームシステム1では、一つの試合中において、アクションパートで使用された応援キャラクタを再度使用することが制限されるため(図27)、例えば、ユーザはそれを踏まえた上で応援キャラクタの選択を行う必要が生じる。その結果、応援キャラクタの選択に関する興趣を向上することが可能になる。
またゲームシステム1では、ユーザU1の作成したチーム(言い換えれば、ユーザU1がホストとなって行われる対戦相手との試合)への参加申込みをユーザU2,U3から受け付けた場合にユーザU1〜U3と対戦相手との試合が実行され、当該試合の実行に応じて、ユーザU1〜U3の各々に貢献ポイントが付与される。例えば、ユーザU3が通常参加者としてチームに参加した場合には、ユーザU3の貢献ポイントが先述の算出式(1)に従って算出される。一方、ユーザU3が助っ人参加者としてチームに参加した場合には、先述の算出式(1)に従って算出されたユーザU1の貢献ポイントの一部が減らされて、当該減らされた分が、先述の算出式(1)に従って算出されたユーザU3の貢献ポイントに加えられる。このため、ユーザU3は本来得ることができる貢献ポイントよりも多くの貢献ポイントを得ることができる。このため、ゲームシステム1によれば、ユーザU1の作成したチームに参加しようとする動機付けを他のユーザに与えることが可能になり、その結果として、ユーザU1の作成したチームに参加しようとする他のユーザが現れ易くすることが可能になる。
またゲームシステム1では、ユーザU2が通常参加者として参加し、かつ、ユーザU3が助っ人参加者として参加した場合に、ユーザU1の貢献ポイントの少なくとも一部と、ユーザU2の貢献ポイントの少なくとも一部とが減らされて、当該減らされた分が、ユーザU3の貢献ポイントに加えられる。このため、ユーザU3は本来得ることができる貢献ポイントよりも多くの貢献ポイントを得ることができる。このため、ゲームシステム1によれば、ユーザU1,U2が参加するチームに参加しようとする動機付けをユーザU3に与えることが可能になり、その結果として、ユーザU1,U2が参加するチームに参加しようとする他のユーザが現れ易くなるように促すことが可能になる。
またゲームシステム1では、ユーザU1の作成したチームへの助っ人要請をユーザU1から受け付けた場合に、当該チームへの助っ人参加申込みの受付が開始される。ゲームシステム1によれば、ユーザU1は助っ人要請を行うことによって、他のユーザに自分の作成したチームに参加してもらうことが可能になるが、その場合には、自分の貢献ポイントが減らされることになる。すなわち、ゲームシステム1では、ユーザU1は自分への報酬が減らされるのと引き換えにして、他のユーザに自分の作成したチームに参加してもらうか否かを選択することが可能になる。
またゲームシステム1では、ユーザU1の作成したチームへの助っ人参加申込みが、ユーザU1よりも対戦レベルの高い他のユーザから受け付けられる。このため、ゲームシステム1によれば、ユーザU1は、自分の貢献ポイントを減らされるのと引き換えにして、自分よりも対戦レベルの高い他のユーザに自分の作成したチームに参加してもらうことが可能になる。
またゲームシステム1では、ユーザU1よりも対戦レベルの高いユーザU3がユーザU1の作成したチームに助っ人参加者として参加すると、ユーザU1の貢献ポイントの少なくとも一部が減らされて、当該減らした分がユーザU3の貢献ポイントに加えられるため、ユーザU3は本来得ることができる貢献ポイントよりも多くの貢献ポイントを得ることができる。その結果、自分よりも能力の低いユーザの作成したチームに参加しようとする動機付けを他のユーザに与えることが可能になるため、自分よりも能力の低いユーザの作成したチームに参加しようとする他のユーザが現れ易くすることが可能になる。
なお、ゲームシステム1では、ユーザU1は、自分の貢献ポイントをどの程度減らしてユーザU3の貢献ポイントに加えるのかを設定できるようにしてもよい。このようにすれば、ユーザU1は自分の作成したチームへの他のユーザの参加状況に合わせて上記の程度を変えることが可能になる。例えば、自分の作成したチームに参加しようとする他のユーザがなかなか現れない場合には、上記の程度を大きくすることによって、自分の作成したチームに参加する他のユーザが現れ易くすることが可能になる。
またゲームシステム1では、ユーザの所有する選手キャラクタの能力(試合開始時の能力)が高いほど、ユーザの勢いポイントの初期値が大きくなる。そして、ユーザの勢いポイントが大きいほど、ユーザに付与される貢献ポイントが多くなる。その結果、ゲームシステム1では、ユーザの所有する選手キャラクタの能力(試合開始時の能力)が高いほど、ユーザに付与される貢献ポイントが多くなる。このため、能力の高い選手キャラクタを所有しているユーザに対して試合に参加する動機付けを与えることが可能になり、当該試合への参加を促すことが可能になる。
またゲームシステム1では、例えば、ユーザU3の所有する選手キャラクタの能力(試合開始時の能力)が、ユーザU1の所有する選手キャラクタの能力(試合開始時の能力)よりも高い場合には、ユーザU3の所有する選手キャラクタの能力がユーザU1の所有する選手キャラクタの能力よりも高くない場合に比べて、ユーザU3の勢いポイントの初期値が大きくなり、その結果として、ユーザU3に付与される貢献ポイントが多くなる。本発明によれば、同じゲームに参加した他のユーザの所有している選手キャラクタよりも能力の高い選手キャラクタを所有しているユーザに対して、より多くの貢献ポイントが付与されるため、能力の高い選手キャラクタを所有しているユーザに対して、自分の所有している選手キャラクタよりも能力の低い選手キャラクタを所有しているユーザが参加する試合に参加する動機付けを与えることが可能になり、当該試合への参加を促すことが可能になる。
またゲームシステム1では、ユーザU1の作成したチームに参加したユーザU3の所有する選手キャラクタの能力(試合開始時の能力)が、ユーザU1の所有する選手キャラクタの能力(試合開始時の能力)よりも高い場合には、ユーザU3の勢いポイントの初期値がユーザU1の勢いポイントの初期値よりも大きくなる結果として、より多くの貢献ポイントがユーザU3に付与され易くなる。このため、ユーザU1の所有する選手キャラクタの能力よりも高い能力の選手キャラクタを所有している他のユーザに対して、ユーザU1の作成したチームに参加する動機付けを与えることが可能になり、当該チームへの参加を促すことが可能になる。
またゲームシステム1では、ユーザU1から助っ人要請を受け付けた場合に、ユーザU1の作成したチームへの助っ人参加申込みの受付が開始される。ゲームシステム1によれば、ユーザU1は助っ人要請を行うことによって、自分の作成したチームに他のユーザに助っ人参加者として参加してもらうことが可能になる。すなわち、対戦レベルが自分よりも高いユーザ(すなわち、自分よりも能力の高い選手キャラクタを所有している可能性の高い他のユーザ)に自分の作成したチームに参加してもらうことが可能になる。なお、一般的に、能力の高い選手キャラクタを所有しているユーザは、自分よりも能力の低い選手キャラクタを所有しているユーザの作成したチームへの参加を避ける傾向がある。このため、例えば、ユーザU3の所有している選手キャラクタの能力がユーザU1よりも高い場合には、ユーザU3の所有している選手キャラクタの能力がユーザU1よりも高くない場合に比べて、ユーザU1の作成したチームへの助っ人参加要請にユーザU3に応じてもらい難くなる。しかしながら、ゲームシステム1によれば、ユーザU3の所有している選手キャラクタの能力がユーザU1よりも高い場合には、ユーザU3に対して、より多くの貢献ポイントが付与されるため、ユーザU3の所有している選手キャラクタの能力がユーザU1よりも高い場合であっても、ユーザU3に助っ人参加要請に応じてもらい易くなる。
またゲームシステム1では、試合におけるユーザのプレイ結果に応じて当該ユーザの勢いポイントが増加される。先述の通り、ユーザに付与される貢献ポイントは当該ユーザの勢いポイントに基づいて決定されるため、ゲームシステム1では、ユーザに付与される貢献ポイントが、試合における当該ユーザのプレイ結果も考慮して決定される。例えば、ユーザのプレイ結果が良かった場合には、ユーザのプレイ結果が良くなかった場合に比べて、より多くの貢献ポイントがユーザに付与される。その結果、プレイ結果がより良くなるように目指す動機付けをユーザに与えることが可能になる。
またゲームシステム1では、各ユーザの貢献ポイントを算出する際のベースポイントが試合結果に基づいて設定される。このため、ゲームシステム1では、ユーザに付与される貢献ポイントが試合結果も考慮して決定される。例えば、試合結果が良かった場合(例えば試合に勝利した場合)には、試合結果が良くなかった場合(例えば試合に敗北した場合に比べて、ベースポイントが多くなり、その結果として、ユーザに付与される貢献ポイントが多くなる。このため、ゲームシステム1によれば、試合結果がより良くなるように目指す動機付けをユーザに与えることが可能になる。
[6.変形例]本発明は以上に説明した実施形態に限定されるものではない。
[6−1]試合が行われる環境に関する環境パラメータが試合状況テーブルTBL105に記憶されるようにしてもよい。例えば、試合会場における風の向き又は強さを示す環境パラメータが試合状況テーブルTBL105に記憶されるようにしてもよい。そして、ユーザにとって有利となるように環境パラメータを変更するような応援効果を設けるようにしてもよい。例えば、ユーザチームの攻撃時において、風がホームベースからスタンドに向かって吹くようにしたり、ホームベースからスタンドに向かって吹く風の強さを強くしたりするような応援効果を設けるようにしてもよい。また例えば、ユーザチームの守備時において、ホームベースからスタンドに向かって吹く風の強さを弱くしたり、風がスタンドからホームベースに向かって吹くようにしたり、スタンドからホームベースに向かって吹く風の強さを強くしたりするような応援効果を設けてもよい。
[6−2]一人プレイパートと協力プレイパートとは別個のゲーム(すなわち、別個に提供されるゲームプログラムによって実行されるゲーム)として実現するようにしてもよい。
[6−3]応援キャラクタはイベントキャラクタと別個のゲームキャラクタとしてもよい。また、一人プレイパートは必須ではなく、省略してもよい。
[6−4]通常参加者は設けず、助っ人参加者のみを設けるようにしてもよい。
[6−5]以上では、本発明を野球を題材としたゲームに適用した例について主に説明したが、本発明は他のゲームにも適用することが可能である。本発明は、複数のユーザが参加するゲームに適用することが可能である。例えば、本発明は、複数のユーザが協力して所定の目的を達成することを目指すゲームに適用することが可能である。
[7.付記]以上のような記載から、本発明は例えば以下のように把握される。なお、本発明の理解を容易にするために、適宜図面に記載された符号を括弧書きで記載するが、それにより本発明が図示の態様に限定されるものではない。
1)本発明の一態様に係るゲームシステム(1)は、複数のユーザが協力して目的の達成を目指すゲームを実行するゲームシステム(1)において、前記ゲームの実行中において、前記複数のユーザのうちの少なくとも一人が操作を行うことが可能な操作期間(例えばアクションパート)を設定する操作期間設定手段(1304)と、前記操作期間において前記少なくとも一人のユーザによって行われた操作に基づいて、前記ゲームを進行させるゲーム進行手段(1307)と、を含み、前記操作期間設定手段(1304)は、前記操作期間において操作を行うことが可能なユーザの人数を、前記複数のユーザの各々の識別情報と関連付けられたゲームオブジェクト(例えば応援キャラクタ)に基づいて増加させる。
8)本発明の一態様に係るゲーム制御装置(10又は30)は、複数のユーザが協力して目標の達成を目指すゲームに関する制御を行うゲーム制御装置(10又は30)において、前記ゲームの実行中において、前記複数のユーザのうちの少なくとも一人が操作を行うことが可能な操作期間を設定する操作期間設定手段(1304)を含み、前記操作期間設定手段(1304)は、前記操作期間において操作を行うことが可能なユーザの人数を、前記複数のユーザの各々の識別情報に関連付けられたゲームオブジェクトに基づいて増加させる。
9)また、本発明の一態様に係るプログラムは、1)〜7)のいずれかに記載のゲームシステム(1)、又は、8)に記載のゲーム制御装置(10又は30)としてコンピュータを機能させるためのプログラムである。
10)また、本発明の一態様に係る情報記憶媒体は、9)に記載のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。
11)また、本発明の一態様に係るゲームシステム(1)の制御方法は、前記ゲームの実行中において、前記複数のユーザのうちの少なくとも一人が操作を行うことが可能な操作期間を設定する操作期間設定ステップ(S1018〜S1028)と、前記操作期間において前記少なくとも一人のユーザによって行われた操作に基づいて、前記ゲームを進行させるゲーム進行ステップ(S1030〜S1032)と、を含み、前記操作期間設定ステップ(S1028)では、前記操作期間において操作を行うことが可能なユーザの人数を、前記複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトに基づいて増加させる。
12)また、本発明の一態様に係るゲーム制御装置(10又は30)の制御方法は、複数のユーザが協力して目標の達成を目指すゲームに関する制御を行うゲーム制御装置(10又は30)の制御方法において、前記ゲームの実行中において、前記複数のユーザのうちの少なくとも一人が操作を行うことが可能な操作期間を設定する操作期間設定ステップ(S1018〜S1028)を含み、前記操作期間設定ステップ(S1028)では、前記操作期間において操作を行うことが可能なユーザの人数を、前記複数のユーザの各々の識別情報に関連付けられたゲームオブジェクトに基づいて増加させる。
上記1)、8)〜12)に記載の発明によれば、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトに基づいて、操作期間において操作を行うことが可能なユーザの人数が増加するようになる。その結果として、複数のユーザが協力して目標の達成を目指す興趣をユーザが実感させることが可能になる。
2)本発明の一態様では、前記複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトのうちから前記複数のユーザの各々によって選択されたゲームオブジェクトを取得する取得手段(1304)を含み、前記操作期間設定手段(1304)は、前記操作期間において操作を行うことが可能なユーザの人数を、前記複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づいて増加させるようにしてもよい。
2)に記載の発明によれば、複数のユーザの各々の識別情報と関連付けられたゲームオブジェクトのうちから複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトのデータに基づいて、操作期間において操作を行うことが可能なユーザの人数が増加されるようになる。その結果、例えば、操作期間において操作を行うことが可能なユーザの人数の増加につながるようなゲームオブジェクトを選択する興趣を提供することが可能になる。
3)本発明の一態様では、前記操作期間は、前記複数のユーザのうちの第1ユーザが操作を行うことが可能な第1操作期間を含み、前記操作期間設定手段(1304)は、前記複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づき、前記第1操作期間において、前記第1ユーザ以外の第2ユーザが操作を行うことも可能にするようにしてもよい。
3)に記載の発明によれば、第1ユーザが操作を行うことが可能な第1操作期間において、第2ユーザも操作を行うことができるようにすることが可能になり、第1ユーザと第2ユーザとが連係して操作を行うことが可能になる。その結果として、複数のユーザが連係して目標の達成を目指す興趣をユーザが実感させることが可能になる。
4)本発明の一態様では、前記操作期間は、前記複数のユーザのうちの第1ユーザが操作を行うことが可能な第1操作期間を含み、前記操作期間設定手段(1304)は、前記複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づき、前記第1操作期間に続けて、前記第1ユーザ以外の第2ユーザが操作を行うことが可能な第2操作期間を設定するようにしてもよい。
4)に記載の発明によれば、第1ユーザが操作を行うことが可能な第1操作期間に続けて、第2ユーザが操作を行うことが可能な第2操作期間が設定されるため、第1ユーザと第2ユーザとが続けて操作を行うことができるようにすることが可能になり、その結果として、複数のユーザが連係して目標の達成を目指す興趣をユーザが実感させることが可能になる。
5)本発明の一態様では、前記ゲームの実行中において、前記複数のユーザの各々によって選択されたゲームオブジェクトが前記複数のユーザの各々によって再度選択されることを制限する選択制限手段(1303)を含むようにしてもよい。
5)に記載の発明によれば、複数のユーザの各々によって選択されたゲームオブジェクトが複数のユーザの各々によって再度選択されることを制限されるため、各ユーザはそれを踏まえた上でゲームオブジェクトの選択を行う必要が生じる。その結果、ゲームオブジェクトの選択に関する興趣を向上することが可能になる。
6)本発明の一態様では、前記操作期間において達成されるべき課題(例えばボーナス条件)を設定する課題設定手段(1306)と、前記操作期間における前記課題の達成結果を判定する達成結果判定手段(1308)と、前記課題の達成結果に基づいて、前記複数のユーザのうちの少なくとも一人の識別情報と報酬を関連付ける報酬関連付け手段(150)と、を含むようにしてもよい。
6)に記載の発明によれば、操作期間において達成されるべき課題が設定され、当該課題の達成結果に基づいて、複数のユーザのうちの少なくとも一人に報酬を付与されるようになるため、操作期間において複数のユーザが連係して課題の達成を目指す興趣を提供できるようになる。
7)本発明の一態様では、前記課題設定手段(1306)は、前記複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づいて、前記課題を設定するようにしてもよい。
7)に記載の発明によれば、操作期間において達成されるべき課題が、複数のユーザのうちの少なくとも一人によって選択されたゲームオブジェクトに基づいて設定されるため、各ユーザはそれを踏まえた上でゲームオブジェクトの選択を行う必要が生じる。その結果、ゲームオブジェクトの選択に関する興趣を向上することが可能になる。