JP2020157068A - ゲームプログラム、ゲーム処理方法、及びゲーム装置 - Google Patents

Abstract

【課題】複数の構成要素が含まれる集合体を効率的に強化すること。【解決手段】ゲームプログラムは、コンピュータに、集合体に含まれる複数の構成要素に関連付けられるデータの更新を指示するステップと、指示するステップによる１回の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新するステップと、指示するステップによる１回の指示機会を、ユーザに所定回数を上限とした複数回提供するステップと、を実行させる。【選択図】図２５

Description

本発明は、ゲームプログラム、ゲーム処理方法、及びゲーム装置に関する。

集合体（例えばチーム）に含まれる構成要素（例えばゲームキャラクタ）を育成する育成パートと、当該育成パートによって育成された構成要素を複数用いて編成された集合体を使用して対戦プレイをする対戦パートとを含むゲームの処理を実行するゲームプログラムが知られている（例えば、特許文献１参照）。

特開２０１６−１６３６７９号公報

従来は、構成要素（例えばゲームキャラクタ）を１人ずつ育成するため、集合体（例えばチーム）を強化するには、多くの構成要素をそれぞれ育成する必要があった。

本発明のいくつかの態様は、複数の構成要素が含まれる集合体を効率的に強化するゲームプログラム、ゲーム処理方法、及びゲーム装置を提供することを目的の一つとする。

また、本発明の他の態様は、後述する実施形態に記載した作用効果を奏することを可能にするゲームプログラム、ゲーム処理方法、及びゲーム装置を提供することを目的の一つとする。

上述した課題を解決するために、本発明の一態様は、コンピュータに、集合体に含まれる複数の構成要素に関連付けられるデータの更新を指示するステップと、前記指示するステップによる１回の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新するステップと、前記指示するステップによる１回の指示機会を、ユーザに所定回数を上限とした複数回提供するステップと、を実行させるためのゲームプログラムである。

また、本発明の一態様は、コンピュータにより実行されるゲーム処理方法であって、集合体に含まれる複数の構成要素に関連付けられるデータの更新を指示するステップと、前記指示するステップによる１回の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新するステップと、前記指示するステップによる１回の指示機会を、ユーザに所定回数を上限とした複数回提供するステップと、を含むゲーム処理方法である。

また、本発明の一態様は、ゲームプログラムを実行するゲーム装置であって、集合体に含まれる複数の構成要素に関連付けられるデータの更新を指示する指示部と、前記指示部による１回の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新する更新部と、前記指示部による１回の指示機会を、ユーザに所定回数を上限とした複数回提供する提供部と、を備えるゲーム装置である。

実施形態に係るゲームの全体流れを示すフローチャート。 ホーム画面の一例を示す図。 キャラクタ一覧画面の一例を示す図。 キャラクタ詳細画面の一例を示す図。 育成パートの工程の流れを示す図。 高校選択画面の一例を示す図。 育成期間と所属メンバの増減を示す図。 育成期間におけるターンを示す図。 イベント発生時のイベント画面の一例を示す図。 イベント発生スケジュールの一例を示す図。 監督メニュー画面の一例を示す図。 キャラクタデータの一例を説明する図。 練習メニュー画面の一例を示す図。 仮選択に応じた更新条件の変化を説明する模式図。 ミッション画面の一例を示す図。 監督スキル画面の一例を示す図。 伝授画面の一例を示す図。 伝授キャラクタ選択画面の一例を示す図。 高校ごとの育成状況の一例を示す図。 対戦用チームの利用設定例を示す図。 対戦用チームの利用設定を行う利用設定画面の一例を示す図。 チームのオーダー設定を行うオーダー設定画面の一例を示す図。 実施形態に係るゲームシステムの構成の一例を示すブロック図。 実施形態に係るゲーム端末のハードウェア構成の一例を示す図。 実施形態に係るゲーム端末の機能構成の一例を示す図。 記憶部に記憶されているキャラクタデータの一例を示す図。 記憶部に記憶される所有キャラクタデータの一例を示す図。 記憶部に記憶される高校データの一例を示す図。 記憶部に記憶される育成データの一例を示す図。 記憶部に記憶されるチームデータの一例を示す図。 記憶部に記憶されるチームメンバデータの一例を示す図。 実施形態に係る育成パート処理の一例を示すフローチャート。 実施形態に係る育成対象の設定処理の一例を示すフローチャート。 実施形態に係る1ターン処理の一例を示すフローチャート。 実施形態に係る練習処理の一例を示すフローチャート。 実施形態に係る育成対象変更処理の一例を示すフローチャート。 実施形態に係る対戦パート処理の一例を示すフローチャート。 実施形態に係る利用設定処理の一例を示すフローチャート。 実施形態に係る強化アイテム処理の一例を示すフローチャート。

以下、本発明の一実施形態について、図面を参照して説明する。
〔１．ゲームの概要〕
まず、本実施形態に係るゲームシステムで実行されるゲームの一例について、その概要を説明する。本実施形態に係るゲームは、複数のキャラクタを用いて行うゲームである。キャラクタとは、ゲームに登場する人物、動物、物体（例えば、乗り物）等のゲームキャラクタであり、ゲーム画面内で画像（キャラクタ画像）として表示される。具体的には、本実施形態に係るゲームの例は、育成パートと対戦パートとを備える野球ゲームである。

育成パートは、複数の選手に相当するキャラクタを含んで構成される野球チームをチーム単位で育成するゲームパートである。育成パートでは、チームに含まれるキャラクタの能力を向上させることでチームの育成を行うことができる。例えば、育成パートでは、ユーザは、複数のキャラクタをメンバとする育成対象のチームを編成し、シナリオを進めながら複数のキャラクタに練習などを実行させる。それにより、育成対象であるチームに含まれる複数のキャラクタの能力が向上し、チームを強化していくことができる。以下では、育成パートにおけるシナリオの一例として、ユーザが監督等の指導者の立場で、所定の期間（例えば２年半）にわたって、高校の野球部（育成対象チーム）を指導（育成）し、野球の大会で優勝することを目指すというシナリオについて説明する。なお、シナリオは高校の野球部に関するものに限られず、例えば、大学又は企業の野球部又はプロ野球チームに関するものであってもよい。本実施形態に係るゲームの例では、ユーザが監督の立場として育成パートを実行する高校の種類別にその内容の異なる複数のシナリオが用意されており、育成パートに適用するシナリオをユーザが任意に選択可能としている。一方、対戦パートは、育成パートで育成されたチーム（即ち、育成パートでそれぞれ能力が向上された複数のキャラクタを含んだチーム）を使用して対戦相手のチームと野球の試合で対戦を行うゲームパートである。例えば、ユーザと他ユーザとのそれぞれで育成パートにより育成したチーム同士での対戦が行われる。

図１は、本実施形態に係るゲームの全体流れを示すフローチャートである。ゲームを開始すると、ホーム画面に遷移する（ステップＳ１）。ホーム画面とは、このゲームの起点となるメインメニューに相当するホーム画像が表示される画面である。

図２は、ホーム画面の一例を示す図である。図示するホーム画面Ｇ１００には、ユーザの操作を受け付ける操作子としての機能を有するアイコンＰ１１０、Ｐ１２０、Ｐ１３０、Ｐ１４０、Ｐ１５０、Ｐ１６０が表示されている。各アイコンは、ホーム画像の一部として表示される画像である。各アイコンのそれぞれには、操作を受け付けたことに応じて実行する処理と関連付けられており、関連付けられた処理に対応する内容（テキスト、画像など）が表示されている。

アイコンＰ１１０には「育成」と表示されており、育成パートのプレイを開始するための処理が関連付けられている。アイコンＰ１１０を選択する操作がされた場合（図１のステップＳ１１：ＹＥＳ）、育成パートの処理が実行される（図１のステップＳ１３）。

アイコンＰ１２０には「試合」と表示されており、対戦パートのプレイを開始するための処理が関連付けられている。アイコンＰ１３０を選択する操作がされた場合（図１のステップＳ２１：ＹＥＳ）、対戦パートの処理が実行される（図１のステップＳ２３）。

アイコンＰ１３０には「キャラクタ一覧」と表示されており、所有キャラクタの一覧を示す所有キャラクタ一覧画像を表示するためのキャラクタ一表示処理が関連付けられている。所有キャラクタとは、ユーザが所有するキャラクタのことである。ユーザは、ゲーム内の抽選やゲームの進行（例えば、試合に勝った、ゲームのプレイ回数が所定回数に達した等）に応じてキャラクタを取得（所有）することができる。所有キャラクタは、育成パートにおいて育成対象のチームの設定に利用することができる。アイコンＰ１３０を選択する操作がされた場合（図１のステップＳ３１：ＹＥＳ）、所有キャラクタ一覧画像を表示するための処理が実行される（図１のステップＳ３３）。

アイコンＰ１４０には「マイチーム」と表示されており、ユーザが育成パートで育成したチーム等に関する情報（画像）や当該チームに対する各種の設定を行うチーム処理が関連付けられている。アイコンＰ１４０を選択する操作がされた場合（図１のステップＳ４１：ＹＥＳ）、チーム処理が実行され、チームに関する情報（画像）やチームに対する設定を行うための選択肢が表示されるチームメニュー画面に遷移する（図１のステップＳ４３）。例えば、「マイチーム」では、チームの所属メンバ（育成パートにより育成されたキャラクタ）の情報やチームの対戦成績等のチーム情報の表示が可能である。ユーザは、育成パートを複数回実行することで、複数のチームを育成（所有）することができるが、「マイチーム」においては、ユーザが所有する複数のチームの中から試合に使用するチームの設定や、所有チームのそれぞれについて、チームの所属メンバのうち試合に出場するメンバのオーダー設定等も可能である。例えば、チームメニュー画面には、チームの所属メンバの情報の表示、試合に使用するチームの設定（利用設定）、及びオーダー設定等を選択するための選択肢を含むチームメニュー画像が表示される。

アイコンＰ１５０には「抽選」と表示されており、ユーザが取得するキャラクタを抽選により決定する抽選処理が関連付けられている。アイコンＰ１５０を選択する操作がされた場合（図１のステップＳ５１：ＹＥＳ）、抽選を行うための抽選画面に遷移する（図１のステップＳ５３）。抽選処理では、予め定められた複数の種類のキャラクタのうちから少なくとも一のキャラクタが抽選によって選出され、選出されたキャラクタがユーザの所有キャラクタとして追加される。例えば、遊技価値（またはゲームの進行に応じて入手されるゲーム内のコインやメダル、ポイント、チケット、またはアイテム等）の消費と引き換えに抽選が行われる。なお、ゲーム内のコイン、ポイント、チケット、またはアイテム等は、ユーザがゲームの進行に応じて取得するものであってもよいし、課金によって取得するものであってもよい。

アイコンＰ１６０には「ショップ」と表示されており、コインやメダル、ポイント等の遊技価値を消費することでアイテム等を購入（取得）するための購入処理が関連付けられている。アイコンＰ１６０を選択する操作がされた場合（図１のステップＳ６１：ＹＥＳ）、アイテム等を購入（取得）するための購入画面に遷移する（図１のステップＳ６３）。

なお、アイコンを選択する操作がされない場合（図１のステップＳ１１、Ｓ２１、Ｓ３１、Ｓ４１、Ｓ５１、Ｓ６１：ＮＯ）、ホーム画面のまま継続し、ゲームの終了条件を満たすと（例えば、ゲームを終了する操作がされると）（図１のステップＳ７１：ＹＥＳ）、ゲームが終了する。

図３は、キャラクタ一覧画面の一例を示す図である。図示するキャラクタ一覧画面Ｇ２００は、アイコンＰ１３０を選択する操作がされた場合に、所有キャラクタ一覧画像を表示される画面である。キャラクタ一覧画面Ｇ２００において、キャラクタリストＲ２０１には、ユーザの所有キャラクタのそれぞれのキャラクタ画像が並んで表示される。キャラクタリストＲ２０１に表示されたキャラクタ画像のうちのいずれかが選択され、「確認」が表示されたアイコンＰ２０１に対する操作がされた場合、選択されたキャラクタ画像のキャラクタについての詳細情報が表示される。なお、「戻る」が表示されたアイコンＰ２０２に対する操作がされた場合、キャラクタ一覧画面Ｇ２００からホーム画面Ｇ１００へ遷移する（戻る）。

図４は、キャラクタ詳細画面の一例を示す図である。図示するキャラクタ詳細画面Ｇ２１０は、図３に示すキャラクタ一覧画面Ｇ２００で選択されたキャラクタの詳細情報を示すキャラクタ詳細画像が表示される画面である。ここでは、「野手能力」のタブが選択されているため、詳細情報のうちの野手能力に関する情報が表示されている。図示する例では、キャラクタ画像Ｒ２１０と、キャラクタの名称（キャラクタ名）Ｒ２２０と、守備位置Ｒ２３０と、基本情報Ｒ２４０と、能力パラメータＲ２５０と、特殊能力Ｒ２６０とが表示されている。基本情報Ｒ２４０には、キャラクタの成績（打率、ホームラン数、打点）、フォーム（打撃フォーム）、及び投打の利き腕を示す情報（例えば、「右投左打」）が表示される。

能力パラメータＲ２５０には、キャラクタの基本能力として、弾道、ミート、パワー、走力、肩力、守備力、捕球等の能力のパラメータが表示される。パラメータとしては、各能力を示す数値と、当該数値に応じた能力の高さのランク（段階）を示すアルファベット（例えば、Ｓ、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ）等で示される。「Ｓ」は能力が最も高ランクであることを示し、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆの順に能力が低くなり、「Ｇ」は能力が最も低いランクであることを示す。

弾道パラメータの値が高いほど、打球が高く上がることを示す。ミートパラメータの値が高いほど、ミート力（投手が投げたボールにバットを当てる能力）が高いことを示す。パワーパラメータの値が高いほど、パワー（投手が投げたボールをバットで打つことによって遠くに飛ばす能力）が高いことを示す。走力パラメータの値が高いほど、足が速いことを示す。肩力パラメータの値が高いほど、送球が速いことを示す。守備力パラメータの値が高いほど、守備が巧いことを示す。捕球パラメータの値が高いほど、捕球が巧い（エラーし難い）ことを示す。

特殊能力Ｒ２６０には、キャラクタの有する特殊能力が表示される。図示する例では、特殊能力として、「パワーヒッター」、「広角打法」、「盗塁」が、キャラクタの有する特殊能力として表示されている。「パワーヒッター」は、投手が投げたボールをバットで打ったときに、より遠くに飛ばす能力を高める特殊能力である。「広角打法」は、流し打ちの能力を高める特殊能力である。「盗塁」は、盗塁に成功し易くなるという特殊能力である。

なお、右（Ｒ）矢印のアイコンＰ２１０または左（Ｌ）矢印のアイコンＰ２１１に対する操作でタブを切替えることにより、「野手能力」から、「選手能力」、「投手能力」、「守備・起用」、「プロフィール」に表示を切り替えることができる。「選手能力」は、そのキャラクタの選手としての能力であり、野手の場合には「野手能力」の情報に基づく情報が表示され、投手の場合には「投手能力」の情報に基づく情報が表示される。「投手能力」は、キャラクタが投手の場合に、投手に関する情報（投球フォームや先発／抑えの適正、基本能力パラメータ（球速、コントロール、スタミナ等）、習得している特殊能力等）が表示される。「守備・起用」には、守備位置、基本能力パラメータ（走力、肩力、守備力等）、起用法等が表示される。「プロフィール」には、キャラクタの氏名、誕生日、年齢、プロ年数等のプロフィール情報等、ゲームで設定されているプロフィール情報が表示される。また、「戻る」が表示されたアイコンＰ２２０に対する操作がされた場合、キャラクタ詳細画面Ｇ２１０からキャラクタ一覧画面Ｇ２００へ遷移する（戻る）。

〔２．育成パート〕
次に、育成パートについて詳しく説明する。育成パートは、複数のキャラクタを含んで構成される一のチームに関連付けられるデータ（例えば、チームに含まれるキャラクタの能力パラメータ）を更新して、チームの戦力（能力）を強化するものであり、「育成対象の設定」、「育成」、「育成結果の反映」の３つの工程に大別される。以下、育成パートにおいて育成（関連するデータの更新）される対象のチームを「育成対象チーム」、当該チームに含まれるキャラクタを「育成対象キャラクタ」という。

図５は、育成パートの工程の流れを示す図である。まず、「育成対象の設定」で、育成する育成対象チームの高校（シナリオ）を選択し、育成対象チームの所属メンバとしての複数の育成対象キャラクタを設定する（ステップＳ１００）。所属メンバ（育成対象キャラクタ）を設定した後、育成対象チームの「育成」に移行する。「育成」では、監督メニュー(監督の立場として育成対象チームを育成するための行動指示機会)を含んだ１回のターンを、終了条件が充足するまで繰り返し実行する（ステップＳ１１０）。終了条件とは、例えば、育成期間が終了することである。終了条件が充足すると（ステップＳ１４０：ＹＥＳ）、「育成結果の反映」に移行し、育成対象チームの育成結果（以下、「育成済チーム」といい、育成済チームに含まれる育成対象キャラクタのことを「育成済キャラクタ」という）を保存して育成パートを完了する。以降、保存された育成済チームを使用して他ユーザの育成済チームと試合で対戦することが可能となる。以下、「育成対象の設定」、「育成」、「育成結果の反映」の各工程について詳しく説明する。

〔２−１．育成対象の設定〕
まずユーザは、育成する育成対象チームの高校（シナリオ）を選択する。なお、初期の時点では高校は１つのみで、後から複数の高校から選択できるようにしてもよい。
図６は、高校選択画面の一例を示す図である。ここでは、ある高校の野球部に関するシナリオが育成パートで実行されることを想定しており、複数の高校（Ａ高校、Ｂ高校、Ｃ高校、Ｄ高校、Ｅ高校）が選択肢として表示されている。図示する高校選択画面Ｇ３００には、複数の高校（Ａ高校、Ｂ高校、Ｃ高校、Ｄ高校、Ｅ高校）のそれぞれを選択するための操作子としての機能を有するアイコンＰ３１１、Ｐ３１２、Ｐ３１３、Ｐ３１４、Ｐ３１５が表示されている。例えば、アイコンＰ３１１を選択する操作がされた場合には、Ａ高校（Ａ高校に関するシナリオ）が選択されたと判定される。

高校（シナリオ）が選択されると、その高校に予め関連付けられたキャラクタとして設定される育成対象キャラクタ（例えば８人。以下、「高校キャラクタ」ともいう。）が、育成対象チームの所属メンバとして設定される。育成対象チームには、高校キャラクタの他に、ユーザの所有するキャラクタの中からユーザにより選択された複数のキャラクタに基づいて設定される育成対象キャラクタ（例えば４人。以下、「任意キャラクタ」ともいう。）と、それ以外の複数の育成対象キャラクタ(例えば１５人。以下、「エキストラキャラクタ」ともいう。)とが設定される。例えば、エキストラキャラクタは、予め定められた複数のエキストラ用のキャラクタのうちから確率情報等に基づいてランダムに選択されて設定される。上記の高校キャラクタ、任意キャラクタ、及びエキストラキャラクタにより構成されるチームが、育成パートにおける育成対象チームとして設定される。

高校キャラクタ、任意キャラクタ、及びエキストラキャラクタの各キャラクタは、学年のパラメータを有しており、育成パートにおける育成期間の進行にともない学年が変化する。ここでは、高校の野球部を育成する例として、育成パートにおける育成期間をゲーム内の２年半の期間（１年生で入部した部員（キャラクタ）は３年生の秋に卒部）としている。育成パートにおける育成期間に対して、所属メンバに設定されるキャラクタは、学年及び入部・卒部の時期により育成期間が異なる。

図７は、育成パートにおける育成期間と所属メンバ（育成対象キャラクタ）の増減を示す図である。図示するように、所属メンバに設定される育成対象キャラクタの育成期間は、学年及び入部・卒部の時期により以下に示す（ａ）〜（ｄ）に分類される。
（ａ）育成期間の開始時点に１年生で入部し、育成期間の３年目の秋に卒部。
（ｂ）育成期間の開始時点に２年生であるため、育成期間の２年目の秋に卒部。
（ｃ）育成期間の開始時点に３年生であるため、育成期間の１年目の秋に卒部。
（ｄ）育成期間の２年目の春に１年生として入部し、育成期間の３年目の秋に終了。
（ｅ）育成期間の３年目の春に１年生として入部し、育成期間の３年目の秋に終了。

育成パート開始時点では、ユーザの所有するキャラクタの中から、ユーザは１年生の属性を有するキャラクタのみが選択可能であり、選択されたキャラクタに基づいて、任意キャラクタ（育成対象キャラクタ）が設定される。また、育成期間の２年目の春、３年目の春のそれぞれの段階で、それぞれの段階の時点で１年生の属性を有するキャラクタをユーザの所有するキャラクタの中から再度設定する機会がユーザに設けられる。育成期間の終了にともない、育成期間の終了時点で在籍しているメンバ（育成済キャラクタ）と、育成期間の途中で卒部したメンバ（育成済キャラクタ）とを含んだチーム（育成済チーム）が育成結果として保存される。なお、ユーザの所有するキャラクタについては、育成パートにおける育成期間の進行に応じて変化する学年のパラメータの代わりに、育成期間の進行に応じて変化しない固定的なパラメータを有していても良い（例えば、育成パートの開始時点で選択可能なキャラクタであること示すパラメータ、育成期間の２年目の春に選択可能なキャラクタであること示すパラメータ、育成期間の３年目の春に選択可能なキャラクタであること示すパラメータ）。

〔２−２．育成〕
「育成」は、「午前イベント」、「監督メニュー」、及び「午後イベント」の３ステップを含む１ターン（図５参照）を、最大で１２０ターン繰り返す。なお、「午前イベント」及び「午後イベント」は、毎回のターンで発生するとは限らず、ターンごとに発生するときと発生しないときがある。図８は、育成期間におけるターンを示す図である。育成パートの開始時に１年生で入部（育成対象チームに加入）した部員(育成対象キャラクタ)が、３年生の秋に卒部（育成終了）するまでのゲーム内の２年半が１２０ターンで表現される。１ターンがゲーム内の１週間、４ターンがゲーム内の１ヶ月に相当し、４(週)×１２(月)×２．５(年)＝１２０ターンとなる。全１２０ターンのなかに、試合を行うターンが含まれており、試合に負けた場合には途中で育成パートが終了する場合もある。

〔２−２−１．育成（イベント）〕
イベント（「午前イベント」及び「午後イベント」）は、高校ごとに予め定められた規定のシナリオに対して追加的に発生するものである。なお、イベントには、高校固有（シナリオ固有）のイベントと、高校共通（シナリオ共通）のイベントと、イベントキャラクタ（以下「イベキャラ」という）によるイベントが存在する。イベキャラとは、イベントが関連付けられているキャラクタのことをいい、上述した育成対象チームに含まれる育成対象キャラクタとして設定される高校キャラクタ、任意キャラクタ、及びエキストラキャラクタの各キャラクタは、同時にイベキャラとしての性質も兼ね備える。イベントは、育成パートの進行にともない、イベント毎に定められた発生条件の成立に応じて(つまり、ユーザの意思によらず)発生する。イベントの結果として、メンバ（育成対象キャラクタ）の能力パラメータ等、各種のパラメータに変化をもたらす。高校固有（シナリオ固有）のイベント、高校共通（シナリオ共通）のイベント、及びイベキャラによるイベントのそれぞれに、種類の異なる複数のイベントが存在しており、イベントの内容は、イベントの種類ごとに異なる。

図９は、イベント発生時のイベント画面の一例を示す図である。図示するイベント画面Ｇ４００は、育成期間の最初のターン（１年目４月１週）の「午前イベント」の一例を示している。イベント画面Ｇ４００には、現在のターンを示す情報Ｒ４１０、イベントの内容に応じたイベント画像Ｒ４２０、イベントに登場するキャラクタの台詞やイベント内容に応じた言葉等のテキスト情報Ｒ４３０等が表示される。各イベントは、育成パートにおけるシナリオを構成する最小単位のストーリー要素として機能し、上述したキャラクタ、キャラクタの台詞、及びイベント内容に応じた言葉等のテキスト情報Ｒ４３０に関連するイベント画像Ｒ４２０を表示することにより、そのストーリー性が表現される。なお、イベントの中には、ユーザによる選択肢の選択を伴うものがあり、その選択結果に応じてイベントの結果も異なるものも含まれている。

イベントは、シナリオイベント（高校固有（シナリオ固有）のイベント又は高校共通（シナリオ共通）のイベント）とイベキャライベント（イベキャラによるイベント）とに区別される。シナリオイベントは、育成パートに適用されたシナリオに対して予め定められた発生条件の成立により発生する。例えば、シナリオイベントは、イベント発生スケジュールが予め設定されており、特定のターン数に到達することを発生条件としてもよい。図１０は、イベント発生スケジュールの一例を示す図である。例えば、１年目の４月の２週目の午前にイベントＸ、１年目の４月の４週目の午後にイベントＹ、・・・、３年目の９月の３週目の午後にイベントＺ、といったようにイベントの発生するタイミングが設定されている。イベントが設定されたターンに到達すると、設定されたイベントが発生する。

イベキャライベントは、イベントの種類ごとに予め定められた発生条件の成立により発生する。例えば、イベキャライベントは、育成対象チームに含まれるイベキャラ（育成対象キャラクタ）に対して関連付けられており、例えば当該イベキャラ（育成対象キャラクタ）の特定のパラメータが特定の値に達したことを条件として発生する。また、イベキャライベントの発生条件にも、特定のターン数に到達することが含まれてもよい。例えば、特定のターン数に到達し、且つ特定のパラメータが特定の値に達したことを条件として、イベキャライベントが発生してもよい。

〔２−２−２．育成（監督メニュー）〕
監督メニューでは、各ターンにおいてユーザが監督の立場として行動する内容（項目）をユーザが選択する。例えば、選択肢の項目には、「練習」、「建設」、「ミッション」、「監督スキル」、及び「伝授」が含まれる。そのそれの項目は、「練習」は、育成対象チームに対して練習を指示する。「建設」は、専用のポイントを消費して建物を建設したり、建設した建物をレベルアップさせる。「ミッション」は、各育成対象キャラクタ（イベキャラ）の育成状態（成長度合い）として、各育成対象キャラクタ（イベキャラ）ごとの、当該育成対象キャラクタ（イベキャラ）に対応するイベントの発生状況を確認できる。「監督スキル」は、監督ポイントを消費して監督能力（指導スキル）を向上させる。「伝授」は、アイテムを消費して育成対象キャラクタの能力を向上させる。

図１１は、監督メニュー画面Ｇ５００の一例を示す図である。図示する監督メニュー画面Ｇ５００には、育成パートにおける現在の時点（現在のターン）を示す情報Ｒ５１０（ここでは、「１年目７月１週」）と、他チームとの試合をするターンまでの期間を示す情報Ｒ５２０（ここでは、「試合まで２週」）と、今後のターンで行われるスケジュールＲ５３０と、育成対象チームの現在の戦力Ｒ５４０（育成状態）とが表示される。戦力としては、育成対象チーム全体としての打撃力、守備力、機動力、球速、制球力、変化球等の能力の高さのランク（段階）を示すアルファベット（例えば、Ｓ、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ）及びレーダーチャートが表示される。各能力のランクは、育成対象チームの所属メンバ（育成対象キャラクタ）のそれぞれの育成状態（能力パラメータ等）に応じて定まる。また、戦力として、各能力のランクを総合した育成対象チーム全体としての能力を示す総合戦力の高さのランク（段階）を示すアルファベット（ここでは「Ａ++」）が表示される。

また、監督メニュー画面Ｇ５００には、ユーザが監督の立場として行動する内容（項目）を選択するための操作子としての機能を有するアイコンＰ５１０、Ｐ５２０、Ｐ５３０、Ｐ５４０、Ｐ５５０が表示されている。アイコンＰ５１０には「練習」と表示されており、育成対象チームに対して練習を指示するための練習処理が関連付けられている。アイコンＰ５２０、には「建設」と表示されており、専用のポイントを消費して建物を建設したり、建設した建物をレベルアップさせるための建設処理が関連付けられている。アイコンＰ５３０には「ミッション」と表示されており、各育成対象キャラクタ（イベキャラ）におけるミッションの達成状況(イベントの発生状況)を確認できるミッション処理が関連付けられている。アイコンＰ５４０、には「監督スキル」と表示されており、監督ポイントを消費して監督能力（指導スキル）を向上させるための監督スキル処理が関連付けられている。アイコンＰ５５０には「伝授」と表示されており、アイテムを消費して育成対象キャラクタの能力を向上させるための伝授処理が関連付けられている。

なお、「練習」を選択した場合のみターン内のステップが進行し、練習処理が終了すると、午後イベントが発生する場合には午後イベントが行われてから現在のターンを終了し、午後イベントが発生しない場合には現在のターンが終了する。「練習」以外の選択項目ではターン内のステップが進行しないため、一つのターン内で何度でも選択することができる。なお、「練習」を選択した後に具体的な練習内容を選択して練習が実施（練習処理が実行）されるまでの間は、「練習」の選択をキャンセルして他の選択肢を選択することができる状態に戻れるようにしても良い。

〔２−２−２（１）．育成（監督メニュー：練習）〕
監督メニュー画面Ｇ５００において、アイコンＰ５１０（「練習」）を選択する操作がされ、練習項目（練習内容）が指示（選択）されると、練習処理が実行される。練習処理では、育成対象チームに対してユーザが指示（選択）した練習内容に応じた練習効果が、当該育成対象チームの所属メンバ（育成対象キャラクタ）に得られる。練習効果とは、育成対象キャラクタに関連付けられているデータ（育成対象キャラクタに関連付けられた各種パラメータ）が更新されることである。例えば、練習効果として、育成対象キャラクタの能力を示す能力パラメータが更新される。

図１２は、キャラクタデータの一例を説明する図である。キャラクタデータ（育成対象キャラクタに関連付けられた各種パラメータ）には、「全体」の能力を示す全体データ、「基本能力」を示す基本能力データ、「特殊能力」を示す特殊能力データ等が含まれる。全体データには、「練習」や「イベント」などに応じて増加（または、減少）する「経験値」、及び「経験値」に応じて決定される「レベル」の能力パラメータが含まれる。基本能力データには、例えば投手に関連する能力としては、コントロール、スタミナ、球速等のそれぞれの「練習値」及び「ランク」の能力パラメータが含まれる。「練習値」は、「練習」や「イベント」などに応じて増加（または、減少）する。「ランク」は、アルファベット（例えば、Ｓ、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ）等で示され、「練習値」が所定値に達するごとに上昇する。なお、「練習値」は、「ランク」の上昇に応じて、都度リセットされる。特殊能力データには、各特殊能力について育成対象キャラクタが修得しているか否か（修得の有無）を示すパラメータが含まれる。各特殊能力のパラメータは、「イベント」や「伝授」等により「無」から「有」に変化する。

例えば、「練習」によって、育成対象キャラクタの「経験値」や「経験値」のパラメータが更新される。ユーザが指示する練習内容は、複数の練習項目の中から選択可能なように予め用意されている。図１３は、練習メニュー画面の一例を示す図である。図示する練習メニュー画面Ｇ６００には、練習項目の選択肢や練習の効果を示す情報等が含まれる練習メニュー画像が表示される。図示する練習メニュー画面Ｇ６００は、「投手練習」を指示する画面の一例である。右（Ｒ）矢印のアイコンＰ６１０または左（Ｌ）矢印のアイコンＰ６１１に対する操作により、「野手練習」等の他の練習に切り替えることができる。

練習メニュー画面Ｇ６００には、育成対象チームに指示する練習項目を選択するための練習メニューＲ６１０が表示される。ここでは、練習メニューＲ６１０には、「投手練習」としての練習項目を選択するための操作子としての機能を有するアイコンＰ６３１、Ｐ６３２、Ｐ６３３、Ｐ６３４が表示されている。アイコンＰ６３１には「球速練習」と表示されており、球速練習を指示することにより練習効果が得られる球速練習処理が関連付けられている。アイコンＰ６３２には「コントロール練習」と表示されており、コントロール練習を指示することにより練習効果が得られるコントロール練習処理が関連付けられている。アイコンＰ６３３には「スタミナ練習」と表示されており、スタミナ練習を指示することにより練習効果が得られるスタミナ練習処理が関連付けられている。アイコンＰ６３２には「変化球練習」と表示されており、変化球練習を指示することにより練習効果が得られる変化球練習処理が関連付けられている。

各練習項目のアイコンには、練習効果としての「経験値」の増加量と、練習内容に応じた「練習値」の増加量と、一または複数の育成対象キャラクタ（キャラクタ画像）とが関連付けられて表示されている。各練習項目に関連付けられる育成対象キャラクタは、育成対象チームに含まれる所属メンバ（育成対象キャラクタ）の中からランダムに選択される。なお、各練習項目のアイコンには、育成対象キャラクタが関連付けられていないものが含まれてもよい。また、練習項目のアイコン（選択肢）の数は、育成対象チームに含まれる全ての育成対象キャラクタの数よりも少ない。アイコン（練習項目）に対応する練習処理により、アイコンに関連付けられている経験値及び練習値に基づいて、当該アイコンに関連付けられている育成対象キャラクタのパラメータ（経験値及び練習値）の値が上昇する。これにより、育成対象キャラクタの能力が上昇し、育成対象チームの戦力が上昇することになる。なお、育成対象キャラクタが関連付けられていない練習項目については、当該練習項目に関連付けられている経験値及び練習値の増加量は、いずれの育成対象キャラクタに対しても反映されない。

具体的には、選択された練習項目（例えば「コントロール練習」）に対応する「経験値」及び「練習値」に＋アルファされた値が、練習項目に関連付けられている育成対象キャラクタのそれぞれの「経験値」及び「練習値」に対して加算される(これを「直接指導」という)。一方、選択されなかった練習項目（例えば「球速練習」、「スタミナ練習」、「変化球練習」）についても、各練習項目に対応する「経験値」及び「練習値」が、各練習項目に関連付けられている育成対象キャラクタの「経験値」及び「練習値」に対して加算される(＋アルファはない)。このように、選択された練習項目に関連付けられている育成対象キャラクタと、選択されなかった練習項目に関連付けられている育成対象キャラクタとの両方とも練習効果を得ることができるが、選択された練習項目に関連付けられている育成対象キャラクタに対してのみ、元の設定値(練習項目ごとに予め設定された値)に＋アルファされた値が加算される。

図示する練習メニュー画面Ｇ６００では、アイコンＰ６３２（「コントロール練習」）が仮選択されている状態である。仮選択とは、その選択が決定されておらず、他のアイコンの選択に変更可能であることを示す。仮選択の状態から選択決定する操作がされると、仮選択されていたアイコンの選択が決定し、当該アイコンに対応する練習項目の練習処理が実行される。選択決定する操作とは、例えば「決定」が表示されたアイコンＰ６２３に対する操作である。なお、タッチパネルに対する操作の場合には、アイコンに対する1回目のタッチ操作により、当該アイコンが仮選択され、仮選択された状態で当該アイコンに対して２回目のタッチ操作を行うことにより、当該アイコンの選択が決定されてもよい。

仮選択された練習項目に対応する「経験値」及び「練習値」には、＋アルファされた値が表示される。図示するアイコンＰ６３２（「コントロール練習」）に対応して表示されている「経験値：＋２３２」及び「練習値：+８２」は、元の設定値に対して＋アルファされた値である。一方、選択されていない練習項目に対応する「経験値」及び「練習値」は、＋アルファされていない元の設定値が表示される。例えば、アイコンＰ６３１（「球速練習」）に対応して表示されている「経験値：＋９３」及び「練習値：+４０」は、＋アルファされていない元の設定値である。仮選択されているアイコンが、アイコンＰ６３２（「コントロール練習」）からアイコンＰ６３１（「球速練習」）に変更された場合には、アイコンＰ６３２（「コントロール練習」）に対応して表示される「経験値」及び「練習値」は＋アルファされていない元の設定値に変更され、アイコンＰ６３１（「球速練習」）に対応して表示される「経験値」及び「練習値」は元の設定値に対して＋アルファされた値に変更される。

上述した「練習」による練習効果（練習項目に対応する「経験値」及び「練習値」が、当該練習項目に対応する各育成対象キャラクタに対して加算されること）によって、育成対象キャラクタの能力を示すパラメータ等のデータが更新される。各練習項目の「経験値」及び「練習値」の増加量は、育成対象キャラクタの能力を示すパラメータ等のデータが「練習」による練習効果により更新される際の「更新条件」の一例である。この更新条件は、「経験値」及び「練習値」の増加量に限られず、他のパラメータの増加（増加量）であってよいし、何らかの特殊能力の取得であってもよい。

図１４は、仮選択に応じた更新条件の変化を説明する模式図である。ここでは、Ａ練習、Ｂ練習、Ｃ練習の３つの練習項目が選択肢の例とし、更新条件としてパラメータの増加量を対応付けている。（１）では、いずれの選択肢も仮選択されていない状態であり、Ａ練習の更新条件が「＋８０」、Ｂ練習の更新条件が「＋４５」、Ｃ練習の更新条件が「＋６０」である。これらの更新条件が、各練習項目の元の設定値である。（２）では、Ａ練習が仮選択されたため、Ａ練習の更新条件のみ＋アルファされた値（「＋８０＋３０」）に変更される。（３）では、仮選択がＡ練習からＢ練習に変更されたため、Ａ練習の更新条件は元の設定値（「＋８０」）に戻り、Ｂ練習の更新条件のみ＋アルファされた値（「＋４５＋１５」）に変更される。（４）では、仮選択がＢ練習からＣ練習に変更されたため、Ｂ練習の更新条件は元の設定値（「＋４５」）に戻り、Ｃ練習の更新条件のみ＋アルファされた値（「＋６０＋２０」）に変更される。なお、変更後の更新条件は、図１３に示すように＋アルファされた後の合計値が表示されてもよいし、図１４に示すように元の設定と＋アルファの値とが表示されてもよい。

なお、仮選択された練習項目の更新条件（パラメータの増加量）が元の設定値に対して増加（＋アルファされる）する例を説明したが、仮選択された練習項目の更新条件は変わらずに、仮選択されていない練習項目の更新条件（パラメータの増加量）が元の設定値に対して減少するにしてもよい。また、仮選択された練習項目の更新条件（パラメータの増加量）が元の設定値に対して増加するとともに、仮選択されていない練習項目の更新条件（パラメータの増加量）が元の設定値に対して減少するにしてもよい。

なお、「経験値」及び「練習値」の元の設定値は、対応する練習項目に関連付けられた育成対象キャラクタと、当該練習項目に対応する監督スキル（監督の能力パラメータ）に基づいて決定されるが、これに加えて（またはこれとは関係なく）、例えば、ゲーム中に獲得したアイテムに基づく値やマネージャスキル等、他の要素に基づいて決定されてもよい。マネージャスキルとは、育成対象チームの所属メンバ（育成対象キャラクタ）のうちマネージャの役割を担うキャラクタに関連付けられたパラメータの一つである。なお、更新条件には、「経験値」及び「練習値」の増加量に限らず、減少量であっても良く、育成対象キャラクタに関連付けられる他のデータ（パラメータ）に対する追加、削除、変更等を示す条件であってもよい。

図１３に戻り、練習メニュー画面Ｇ６００において、練習対象リストＲ６２０は、仮選択された練習項目に関連付けられている育成対象キャラクタのリストがユーザに選択可能に表示される。この練習対象リストＲ６２０において選択された育成対象キャラクタについて、ミッションの達成状況(イベントの発生状況)と能力の詳細を確認できる。「ミッション詳細」と表示されているアイコンＰ６２０に対する操作がされた場合、練習対象リストＲ６２０で選択されている育成対象キャラクタ（イベキャラ）に対応するイベントの発生状況が表示される。「能力詳細」と表示されているアイコンＰ６２１に対する操作がされた場合、練習対象リストＲ６２０で選択されている育成対象キャラクタの能力パラメータ等が表示される。「戻る」が表示されたアイコンＰ６２２に対する操作がされた場合、練習メニュー画面Ｇ６００から監督メニュー画面Ｇ５００へ遷移する（戻る）。

〔２−２−２（２）．育成（監督メニュー：建設）〕
「建設」では、監督ポイントを消費することにより、各種の建物(例えばトレーニング施設)を建設または建設した建物をレベルアップさせることができる。建物の種類及び建設レベルは練習効果や監督スキル等に影響を与える。なお、この「建設」は、高校（シナリオ）固有のメニューであり、高校によって有る場合と無い場合がある。「建設」が無い高校には、「建設」に代わるメニューがあってもよい。

〔２−２−２（３）．育成（監督メニュー：ミッション）〕
「ミッション」では、ミッションの達成状況(イベントの発生状況)を確認できる。即ち、発生し得るイベントがどれだけ発生しているかを確認できる。「ミッション」と称しているのは、育成パートにおいて育成対象チームに含まれる育成対象キャラクタ（イベキャラ）の能力をより多く向上させるためには、イベントをより多く発生させる必要があることから、イベントを発生させることが育成パートにおいてユーザに課せられたミッションと捉えることができるためである。

図１５は、ミッション画面の一例を示す図である。図示するミッション画面Ｇ７００には、イベント発生状況Ｒ７１０と、イベント詳細情報Ｒ７２０とが表示される。前述したように、イベントには、シナリオイベントとイベキャライベントとがある。図示する例では、「イベキャラ」のタブが選択されているため、イベント発生状況Ｒ７１０には、イベキャライベントの発生状況が表示されている。

イベント発生状況Ｒ７１０には、イベキャラリストＲ７１１と、イベントリストＲ７１２とが表示される。イベキャラリストＲ７１１には、イベキャラ（育成対象キャラクタ）のキャラクタ画像が複数表示される。各キャラクタ画像は選択可能であり、選択されたキャラクタ画像は、キャラクタ名（ここでは、「キャラクタＢ１」）が表示されるとともに、他のキャラクタ画像と区別可能な表示態様となる。イベントリストＲ７１２には、イベキャラリストＲ７１１で選択されているキャラクタ画像が示すイベキャラに関連付けられているイベキャライベントの一覧が表示される。例えば、イベキャライベントは、初期時点ではイベントが発生し得ないロック状態（図示では、イベント＃５及びイベント＃６）であり、鍵マークが関連付けて表示されている。イベキャラのレベルが一定レベルを超えると、ロック状態からアンロック状態（図示では、イベント＃２及びイベント＃４）へ移行し、鍵マークが非表示となる。アンロック状態は、イベントが発生し得る状態である。アンロック状態となったイベントは、そのイベントに予め定められた発生条件（例えば、イベキャラの特定のパラメータが特定の値に達すること）をさらに満たすことにより発生する。また、発生済みのイベントには「達成！」が表示される（図示では、イベント＃１及びイベント＃３）。

また、イベントリストＲ７１２には、イベキャラリストＲ７１１に表示されているイベキャライベントのうち選択されたイベキャライベントの詳細情報が表示される。図示では、イベント＃２が選択されているため、イベント＃２の内容についての説明情報Ｒ７２１と、イベント＃２の発生条件Ｒ７２２と、イベント＃２により得られる報酬情報Ｒ７２３とが表示される。

なお、右（Ｒ）矢印のアイコンＰ７１０または左（Ｌ）矢印のアイコンＰ７１１に対する操作によりタブを「イベキャラ」から「シナリオ」に切替えると、イベント発生状況Ｒ７１０に表示される内容が、イベキャライベントの発生状況からシナリオイベントの発生状況に切り替わる。

〔２−２−２（４）．育成（監督メニュー：監督スキル）〕
「監督スキル」では、監督ポイントを消費することにより監督スキル(監督としての指導スキル)を向上（獲得）させることができる。例えば、監督スキルには、速球派を指導するスキル、技巧派を指導するスキル、打撃を指導するスキル等がある。監督スキルの向上（獲得）にともない、「練習」メニューにおいて監督スキルの種別に対応する練習項目についての練習効果が向上する。

図１６は、監督スキル画面の一例を示す図である。図示する監督スキル画面Ｇ８００には、監督スキルを選択するためのスキルリストＲ８１０が表示される。スキルリストＲ８１０には、予め設定された複数の監督スキルが表示されている。監督スキルにも、ロック状態とアンロック状態とがある。アンロック状態の監督スキル（図示では、スキル＃１、＃３、＃５、＃６、＃７、＃８）は選択可能である。ロック状態の監督スキル（図示では、スキル＃２、＃４）には鍵マークが表示されるとともにグレー表示されており、選択することができない。例えば、監督のレベルが一定レベルを超えると、ロック状態からアンロック状態へ移行し、選択可能となる。また、各監督スキルには、向上させる（獲得する）各監督スキルと引き換えに消費する監督ポイントの値が表示されている。所有している監督ポイントでは足りない監督スキル（図示では、スキル＃９）は、鍵マークは表示されないが、選択できない状態でグレー表示される。

スキルリストＲ８１０に表示されている複数の監督スキルのうち向上させたい（獲得したい）監督スキルを選択し、「決定」が表示されたアイコンＰ８２０に対する操作を行うことにより、選択した監督スキルを、監督ポイントを消費することにより向上させる（獲得する）ことができる。「戻る」が表示されたアイコンＰ８２１に対する操作がされた場合、監督スキル画面Ｇ８００から監督メニュー画面Ｇ５００へ遷移する（戻る）。

〔２−２−２（５）．育成（監督メニュー：伝授）〕
「伝授」では、アイテムを消費して任意の選手（育成対象キャラクタ）の能力を向上させることができる。アイテムには、「レベル経験値」と、野手用／投手用のそれぞれの「コツ」及び「練習値」との５種類に分類される。「レベル経験値」は、育成対象キャラクタの「経験値」（及び「経験値」に応じて「レベル」）を増加させるものである。「コツ」は、アイテムとして特殊能力を育成対象キャラクタに付与するものである。「練習値」は、育成対象キャラクタの「練習値」を増加させるものである。なお、「コツ」(特殊能力)にはランク（例えば、Ｓ、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ）があり、段階的に効果が変化する。

図１７は、伝授画面の一例を示す図である。図示する伝授画面Ｇ９００には、伝授するアイテムを選択するための伝授画像が表示される。伝授画面Ｇ９００において、伝授アイテムリストＲ９０１には、「伝授」するアイテムがタブを切替えることにより種類ごとに表示される。図示する例では、「野手コツ」のタブが選択され、野手用の「コツ」(特殊能力)のアイテムと、そのアイテムの所持数とが表示されている。所持数分の伝授が可能である。右（Ｒ）矢印のアイコンＰ９０１または左（Ｌ）矢印のアイコンＰ９０２に対する操作によりタブを切替えることにより、「投手コツ」（投手用の「コツ」）、「野手練習値」（野手用の「練習値」）、「投手練習値」（投手用の「練習値」）、「レベル経験値」のそれぞれのアイテムリストを伝授アイテムリストＲ９０１に表示させることができる。

図示する例では、野手用の「コツ」(特殊能力)のアイテムである「チャンス」が選択されている。「チャンス」は、チャンスの際に基本能力の能力パラメータが上昇し、チャンスに強くなるという特殊能力である。「決定」が表示されたアイコンＰ９０３に対する操作を行うことにより、選択されている「チャンス」をどの育成対象キャラクタに付与するかを選択するための伝授キャラクタ選択画面へ遷移する。なお、「戻る」が表示されたアイコンＰ９０４に対する操作がされた場合、伝授画面Ｇ９００から監督メニュー画面Ｇ５００へ遷移する（戻る）。

図１８は、伝授キャラクタ選択画面の一例を示す図である。図示する伝授キャラクタ選択画面Ｇ９１０には、伝授画面Ｇ９００で選択されたアイテムを付与する育成対象キャラクタを選択するための画像が表示される。伝授キャラクタ選択画面Ｇ９１０において、キャラクタ選択リストＲ９１１には、複数のキャラクタ画像が選択肢として表示されている。ここで、表示されるキャラクタ画像は、選択されたアイテムの種類に応じて決定されてもよい。例えば、野手用のアイテムの場合には野手の育成対象キャラクタを優先し、投手用のアイテムの場合には投手の育成対象キャラクタを優先した表示順としてもよい。また、野手用のアイテムの場合には野手のキャラクタ画像のみが表示され、投手用のアイテムの場合には投手のキャラクタ画像のみが表示されてもよい。図示する例では、「キャラクタＢ１」が選択されている。「決定」が表示されたアイコンＰ９１１に対する操作を行うことにより、選択されている「キャラクタＢ１」に、伝授するアイテムとして選択された「チャンス」に関する特殊能力が付与される。なお、「戻る」が表示されたアイコンＰ９１２に対する操作がされた場合、伝授キャラクタ選択画面Ｇ９１０から伝授画面Ｇ９００へ遷移する（戻る）。

〔２−３．育成結果の反映〕
育成パートが終了し、育成対象チームの「育成」が終了すると、終了時点で育成対象チームに在籍するメンバ（育成対象キャラクタ）に、育成期間の途中で卒部したメンバ（育成対象キャラクタ）を加えた育成対象チームが、育成済チームとして保存される。保存される育成済チーム及び育成済チームに含まれる育成済キャラクタのデータは、育成パートにおける「育成」の育成結果が反映された更新後のデータである。育成した育成済チームは、高校（シナリオ）ごとに複数保持することが可能である。図１９は、高校ごとの育成状況の一例を示す図である。図示する例では、Ａ高校（Ａ高校に関するシナリオ）にて育成パートを３回実施した結果として３つの育成済チームを保持し、Ｂ高校（Ｂ高校に関するシナリオ）での育成パートの実績はなく、Ｃ高校（Ｃ高校に関するシナリオ）にて育成パートを４回実施した結果として４つの育成済チームを保持している状況を示している。保持された育成済チームは、他のユーザの育成済チームと対戦のために使用される。複数の育成済チームを保持している場合、その中から選択された１つのチーム（育成済チーム）を対戦に使用することができる。

〔３．対戦用チームの設定〕
育成パートにより育成された高校（シナリオ）ごとの育成済チームは、対戦パートで使用するチームとして、高校ごとに１つ指定可能である。対戦パートをプレイする前に予め指定しておくことにより、対戦のたびに対戦に使用するチーム（育成済チーム）を選択する必要が無く、利便性が良い。ここで、対戦パートをプレイする前に予め対戦に使用するチーム（育成済チーム）を指定しておく設定のことを、「利用設定」ということとする。なお、対戦パートにおける対戦は、非同期で実施されるため、対戦を実施しようとするユーザの対戦相手としてマッチングされる側のユーザの立場としても、マッチングされる側のユーザより利用設定されたチーム（育成済チーム）が対戦に使用されることとなり、対戦に使用するチーム（育成済チーム）の選択にユーザの意思を反映させることができる。また、各高校には育成パートが実施される前からデフォルトチームが予め用意されており、利用設定がなされている。このため、育成実績（育成パートの実施実績）のない高校についてはデフォルトチームを対戦に使用することができる。但し、デフォルトチームは、基本的には育成パートにより育成された育成済チームよりも能力的に不利である。

図２０は、対戦用チームの利用設定例を示す図である。図示する例は、図１９に示す高校（シナリオ）ごとの育成状況の例に対応しており、利用設定可能なチームを示している。Ａ高校（Ａ高校に関するシナリオ）は、育成パートにより育成した３つの育成済チーム（チーム＃１、＃２、＃３）を保持しているため、この３チームの中のいずれかを利用設定が可能である。Ｂ高校（Ｂ高校に関するシナリオ）は、育成パートによる育成実績がないため、デフォルトチームのみ利用設定が可能である。デフォルトチームのみの高校（シナリオ）については、当該デフォルトチームが予め利用設定されていてもよい。Ｃ高校（Ｃ高校に関するシナリオ）は、育成パートにより育成した４つの育成済チーム（チーム＃１、＃２、＃３、＃４）を保持しているため、この４チームの中のいずれかを利用設定が可能である。図示する例では、Ａ高校（Ａ高校に関するシナリオ）ではチーム＃２、Ｂ高校（Ｂ高校に関するシナリオ）ではデフォルトチーム、Ｃ高校（Ｃ高校に関するシナリオ）ではチーム＃３がそれぞれ対戦に使用するチーム（育成済チーム）として利用設定されている。また、各チームにおいて、チーム内のメンバ（育成済キャラクタ）は、試合に出場するメンバで構成されたオーダーと、それ以外とに区別される。オーダーは、スターティングオーダーとベンチ(控え)とに区別される。メンバ（育成済キャラクタ）の入れ替えはいつでも自由に行なうことができる。

図２１は、対戦用チームの利用設定を行う利用設定画面の一例を示す図である。図示する利用設定画面Ｇ１０００は、図２に示すホーム画面Ｇ１００において、アイコンＰ１４０（「マイチーム」）を選択する操作がされた場合に表示されるチームメニュー画面において、さらに「利用設定」を選択する操作がされた場合に表示される。利用設定画面Ｇ１０００には、現在利用設定されているチーム（育成済チーム）を示す「現在のチーム」の情報Ｒ１０１０、及び現在利用設定されているチームに代えて新たに利用設定するチームを示す「入れ替えるチーム」の情報Ｒ１０２０が表示される。図示する例では、「現在のチーム」の情報Ｒ１０１０には、Ａ高校（Ａ高校に関するシナリオ）のチーム＃１が利用設定されている。一方、「入れ替えるチーム」の情報Ｒ１０２０には、同じＡ高校（Ａ高校に関するシナリオ）のチーム＃２、＃３が入れ替えの候補として表示される。なお、入れ替えの候補が一つのチームしかない場合にはその一つのチームのみが候補として表示され、入れ替えの候補が他にない場合（その高校（シナリオ）のチームが１つのみの場合）には候補は表示されない。

「入れ替えるチーム」の情報Ｒ１０２０に表示されているチーム（育成済チーム）の中から新たに利用設定したいチーム（育成済チーム）を選択する操作がされ、且つ「入れ替える」が表示されたアイコンＰ１０１０に対する操作がされた場合、「現在のチーム」の情報Ｒ１０１０に表示されているチームと「入れ替えるチーム」の情報Ｒ１０２０に表示されているチームとが入れ替わる。そして、「ＯＫ」が表示されたアイコンＰ１０１１に対する操作がされた場合、利用設定の変更が確定する。一方、「キャンセル」が表示されたアイコンＰ１０１２に対する操作がされた場合、「現在のチーム」の情報Ｒ１０１０に表示されているチームと「入れ替えるチーム」の情報Ｒ１０２０に表示されているチームとが入れ替え前の元の状態に戻る。

また、高校選択Ｒ１０３０には、各高校（シナリオ）に対応するアイコンが表示されており、当該アイコンのいずれかを選択する操作により、利用設定を行う高校を切替えることができる。なお、「戻る」が表示されたアイコンＰ１０１３に対する操作がされた場合、利用設定画面Ｇ１０００からチームメニュー画面へ遷移する（戻る）。

図２２は、チーム（育成済チーム）のオーダー設定を行うオーダー設定画面の一例を示す図である。図示するオーダー設定画面Ｇ１１００には、オーダーメンバリストＲ１１１０と、ベンチ外メンバリストＲ１１２０とが表示される。オーダーメンバリストＲ１１１０には、レギュラー（スターティングオーダー）のメンバ（育成済キャラクタ）９人と、ベンチ入りメンバ（育成済キャラクタ）９人とが区別されて表示される。ベンチ外メンバリストＲ１１２０には、オーダーに入っていないベンチ外メンバ（育成済キャラクタ）５人が表示される。

例えば、レギュラーメンバを変更したい場合、オーダーメンバリストＲ１１１０において、変更したいレギュラーメンバが選択され、且つ「変更」が表示されたアイコンＰ１１１０に対する操作がされると、ベンチ入りメンバのリストから変更するメンバの選択が可能となる。そして、ベンチ入りメンバのリストから変更するメンバが選択され、且つ「ＯＫ」が表示されたアイコンＰ１１１１に対する操作がされると、選択されたレギュラーメンバと選択されたベンチ入りメンバとが入れ替わる。また、ベンチ外メンバをオーダーに入れたい場合、ベンチ外メンバリストＲ１１２０において、オーダーに入れたいベンチ外メンバが選択され、且つ「変更」が表示されたアイコンＰ１１１０に対する操作がされると、オーダーメンバリストＲ１１１０の中から代わりにオーダーからが外すメンバの選択が可能となる。そして、オーダーメンバリストＲ１１１０の中からオーダーからが外すメンバが選択され、且つ「ＯＫ」が表示されたアイコンＰ１１１１に対する操作がされると、選択されたオーダーメンバとベンチ外メンバとが入れ替わる。このように、育成済チームにおいて、レギュラー（スターティングオーダー）メンバ、ベンチ入りメンバ、ベンチ外メンバの間で、メンバ（育成済キャラクタ）の入れ替えはいつでも自由に行うことができる。しかし、チーム（育成対象チーム）を跨いたメンバの入れ替えはできず、あるチーム（育成済チーム）から別のチーム（育成済チーム）にメンバ（育成済キャラクタ）を移動させる（入れ替える）ことは出来ない。

〔４．対戦パート（対戦相手のチームのマッチング）〕
対戦パートでは、他のチームとの対戦の実行を指示する(例えば、図２に示すホーム画面Ｇ１００のアイコンＰ１２０（「試合」）に対する操作を行う)と、対戦相手とのマッチングが行われる。マッチングでは、総合力の近いユーザ同士のチーム（育成済チーム）がマッチング対象となる。総合力は、高校（シナリオ）ごとに対戦に使用するための利用設定がされたチームの総合力（総合戦力）の合計として算出される。例えば、図２０に示す例では、Ａ高校のチーム＃２の総合力（総合戦力）とＢ高校のデフォルトチームの総合力（総合戦力）とＣ高校のチーム＃３の総合力（総合戦力）との合計が、このユーザの総合力としてマッチングに利用される。例えば、ユーザが対戦の実行を指示すると、ユーザの総合力と近い総合力（ユーザの総合力±所定値の範囲内）を有する複数の他のユーザが、ユーザの対戦相手の候補として抽出される。ユーザは、抽出された複数の他のユーザの中から対戦相手を任意に選択することで、ユーザのチームと対戦相手のユーザのチームとで対戦が行われる。チームの総合力（総合戦力）は、例えば、チームに含まれる所属メンバ（各育成済キャラクタ）の能力パラメータの値に基づいて算出（例えば、合計）される。チームの総合力（総合戦力）は、好適にはチームに含まれる全ての所属メンバ（育成済キャラクタ）の能力パラメータの値に基づいて算出されるが、オーダーメンバ等の特定のグループに含まれる所属メンバ（育成済キャラクタ）のみの能力パラメータの値に基づいて算出されてもよい。マッチングにより対戦相手のユーザが決定すると、決定された対戦相手のユーザと、同一の高校（シナリオ）でそれぞれ利用設定されたチーム同士で対戦が行われる。対戦に使用されるチームの属する高校（シナリオ）はユーザの選択によらず予め決定される。このため、ユーザの総合力と近い総合力を有する他のユーザであっても、決定された高校（シナリオ）において利用設定されたチーム同士のチームの総合力が近いとは限らない。従って、対戦においてどの高校が決定された場合でも対戦を有利に進めるためには、全ての高校において育成パートにより強いチームを育成しておく必要がある。

〔５．ゲームシステムの構成〕
次に、本実施形態に係るゲームシステム１の構成について説明する。
図２３は、本実施形態に係るゲームシステム１の構成の一例を示すブロック図である。ゲームシステム１は、複数の端末装置１０−１、１０−２、・・・、１０−ｎ（ｎは自然数）と、サーバ装置３０から構成されており、これらの装置は通信ネットワークＮＷを介して接続される。端末装置１０−１、１０−２、・・・、１０−ｎは同様の構成であるため、特に区別しない場合には単に端末装置１０として説明する。

端末装置１０は、ゲーム制御プログラムを実行することによりゲーム装置として機能する。例えば、端末装置１０は、ユーザが利用するコンピュータ装置であり、ゲーム機、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレットＰＣ、スマートフォンやフィーチャーフォン等の携帯電話機等が適用できる。

サーバ装置３０は、端末装置１０でゲーム制御プログラムを実行するために必要なゲームデータやゲーム制御プログラムを管理する。例えば、サーバ装置３０は、ゲーム運営会社が管理するコンピュータ装置であり、複数のサーバマシン、ストレージ、ネットワークスイッチ、ルーター・ファイアウォール等で構成されたシステムとして捉えることもできる。サーバ装置３０で管理するゲームデータは、端末装置１０でゲーム制御プログラムを実行する場合に利用されたり、あらかじめ端末装置１０に送信して利用されたりする。また、ゲームデータには、ゲーム中に表示される広告データ（他のゲームの情報）が含まれる。例えば、端末装置１０の画面に表示される画像は、ゲームデータの一部である。サーバ装置３０で管理するゲーム制御プログラムは、ゲーム制御の一部のプログラムが含まれる。ゲーム制御プログラムには、ゲーム開始前に端末装置１０にダウンロードされるものだけなく、ゲーム開始後に端末装置１０にダウンロードされるものを含む。なお、ゲーム開始前に端末装置１０にダウンロードされるゲーム制御プログラムは、サーバ装置３０でなく、端末装置１０で動作するプログラムを配信しているサーバ装置で管理されているものであってもよい。

〔５−１．ゲーム端末のハードウェア構成〕
次に、本実施形態に係る端末装置１０の構成について詳しく説明する。
図２４は、本実施形態に係る端末装置１０のハードウェア構成の一例を示す図である。端末装置１０は、例えば、通信部１１と、入力部１２と、表示部１３と、音声出力部１４と、記憶部１５と、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１６を含んで構成される。端末装置１０は、汎用的なスマートフォンを利用でき、ＣＰＵの処理能力を問わなければ、ゲーム制御プログラムを実行するための特別なハードウェアを必要としない。すなわち、ゲーム制御プログラムが実行される端末装置１０のハードウェア構成に合わせて適正に作成されたプログラムを用いれば、ハードウェア構成の一部が本実施形態と異なっても構わない。

通信部１１は、端末装置１０とサーバ装置３０が通信可能な無線ＬＡＮ、有線ＬＡＮ、移動体通信（ＬＴＥ）等の通信ネットワークＮＷの通信規格に対応した通信を行うデバイスである。

入力部１２は、ゲーム実行中にインタラクティブな情報を受取ることが可能なデバイスである。インタラクティブな情報とは、例えば、端末装置１０に対するユーザの操作情報である。入力部１２として、ボタン、キーボード、レバーなどの機械的操作による物理デバイス、ＧＵＩによるポインティングデバイス（マウスやタッチパネル）、音声やジェスチャによる認識デバイス（マイク、カメラ）が例示できる。入力部１２は、端末装置１０と一体に構成されてもよいし、有線または無線で接続される別体として構成されてもよい。入力部１２は、操作に基づいて入力された操作信号を出力する。

表示部１３は、画像やテキスト等の情報を表示するディスプレイであり、例えば、液晶ディスプレイパネル、有機ＥＬ（ＥｌｅｃｔｒｏＬｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイパネルなどを含んで構成される。なお、表示部１３は端末装置１０と別体として構成されてもよく、例えば、テレビ、外付けモニター、ヘッドマウントディスプレイ（ＨＭＤ）でもよい。

音声出力部１４は、例えば、スピーカや、ヘッドフォン等に音声を出力する音声出力端子などを含んで構成されている。

記憶部１５は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などを含み、端末装置１０が処理に用いる各種情報や画像、プログラム等を記憶する。なお、記憶部１５は、端末装置１０に内蔵されるものに限らず、ＵＳＢ等のデジタル入出力ポート等によって接続された外付け型の記憶装置でもよい。

ＣＰＵ１６は、記憶部１５に記憶された各種プログラムを実行し、端末装置１０の各部を制御する。なお、ＣＰＵ１６は、端末装置１０で処理を実行するプロセッサの一例である。

なお、端末装置１０は、不図示のカメラ、ジャイロセンサ、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）チップを含んで構成されてもよい。

〔５−２．ゲーム端末の機能構成〕
図２５は、本実施形態に係る端末装置１０の機能構成の一例を示す図である。この図では、端末装置１０機能構成として、データ記憶部１５０と、制御部１６０とを示している。データ記憶部１５０は、図２４に示す記憶部１５に対応する機能構成である。制御部１６０は、記憶部１５に記憶されているゲーム制御プログラムをＣＰＵ１６が実行することにより実現される機能構成である。

データ記憶部１５０は、ゲーム処理を実行する際に必要なデータを記憶する構成として、例えば、キャラクタデータ記憶部１５１と、ユーザデータ記憶部１５２と、所有キャラクタデータ記憶部１５３と、高校データ記憶部１５４と、育成データ記憶部１５５と、チームデータ記憶部１５６と、チームメンバデータ記憶部１５７とを備えている。

キャラクタデータ記憶部１５１には、ゲームで利用可能な複数のキャラクタのデータが記憶されている。図２６は、キャラクタデータ記憶部１５１に記憶されているキャラクタデータの一例を示す図である。キャラクタデータＤ１５１には、キャラクタＩＤ、キャラクタ名、キャラクタの能力を示すデータ等が関連付けられている。キャラクタＩＤは、各キャラクタを識別する識別情報である。キャラクタ名は、キャラクタの名称である。キャラクタの能力を示すデータには、図１２を参照して説明したように「全体」の能力を示す全体データ、「基本能力」を示す基本能力データ、「特殊能力」を示す特殊能力データ等が含まれる。全体データには、「レベル」と「経験値」のそれぞれの能力パラメータが含まれる。基本能力データには、「コントロール」、「スタミナ」、「球速」等に対応する「ランク」と「練習値」のそれぞれの能力パラメータが含まれる。特殊能力データには、「特殊能力＃１」、「特殊能力＃２」、「特殊能力＃３」等に対応する特殊能力の有無を示すパラメータが含まれる。なお、これらのデータは一例であって、キャラクタデータＤ１５１には、各キャラクタのキャラクタ画像や、守備位置、フォーム等の各種のキャラクタに関するデータが関連付けられていてもよい。

ユーザデータ記憶部１５２には、端末装置１０を利用するユーザのユーザデータが記憶される。ユーザデータには、ユーザを識別するユーザＩＤ、ゲーム内でのユーザの名称を示すユーザ名等が関連付けられている。また、ユーザデータには、ユーザが取得したコインやメダル、ポイント、チケット、またはアイテム等のデータも関連付けられる。

所有キャラクタデータ記憶部１５３には、ゲームで用意されている複数のキャラクタのうちユーザが抽選等により取得した所有キャラクタのキャラクタデータが記憶される。なお、例えば抽選処理はサーバ装置３０で行われ、抽選結果（抽選されたキャラクタのデータ）をサーバ装置３０から取得することにより、所有キャラクタのキャラクタデータが追加される。図２７は、所有キャラクタデータ記憶部１５３に記憶される所有キャラクタデータの一例を示す図である。図示する所有キャラクタデータＤ１５３には、ユーザＩＤと、所有ＩＤと、キャラクタＩＤ、キャラクタ名等が関連付けられている。所有ＩＤは、キャラクタデータの管理上における所有キャラクタの所有（ユーザに対する付与）に係る事象を識別する識別情報である。例えば、ユーザがキャラクタを取得することに応じて、新たに所有ＩＤが発行され、当該所有ＩＤと、取得したキャラクタのキャラクタＩＤ及びキャラクタ名等が関連付けられて記憶される。ユーザが同一のキャラクタを所有する場合があるが、この場合、キャラクタＩＤ及びキャラクタ名は同一であるが、所有ＩＤは異なる。なお、この所有キャラクタデータは、サーバ装置３０に送信され、サーバ装置３０で複数のユーザの所有キャラクタデータがユーザごと（ユーザＩＤごと）に関連付けられて管理される。

高校データ記憶部１５４には、ゲームで用意されている高校（シナリオ）の高校データ（シナリオデータ）が記憶されている。図２８は、高校データ記憶部１５４に記憶される高校データの一例を示す図である。図示する高校データＤ１５４には、高校ＩＤ（シナリオＩＤ）、高校名（シナリオ名）、高校キャラクタ、デフォルトチームＩＤ等が関連付けられている。高校ＩＤ（シナリオＩＤ）は、高校（シナリオ）を識別する識別情報である。高校名（シナリオ名）は、高校（シナリオ）の名称である。高校キャラクタには、ゲームで用意されている複数のキャラクタのうちの高校ごとに予め設定されている高校キャラクタのキャラクタＩＤが関連付けられている。デフォルトチームＩＤは、高校ごとに予め設定されているデフォルトチームを識別する識別情報である。なお、高校データは、ゲームの開始時点では限定された数の高校のみとし、ゲームの進行に応じて追加されてもよい。この場合、追加される高校データは、サーバ装置３０から取得して高校データ記憶部１５４に記憶される。または、後から追加される分の高校データも高校データ記憶部１５４に記憶しておき、ゲームの開始時点ではユーザが選択できる高校を限定し、ゲームの進行に応じて選択できる高校を増加させるようにしもよい。なお、ユーザによるゲームの進行状況とは別に、高校データ（シナリオデータ）や関連するデータをユーザに利用可能なようにゲームサービスの運営者の都合に応じて順次に提供されるようにゲームサービスが運営されてもよい。この場合、ユーザによるゲームの進行状況に関わらず、本ゲームの全てのユーザに対して同じタイミングで追加のコンテンツ（高校データ及び関連データ）が利用可能となる。

育成データ記憶部１５５には、育成パートで育成している育成対象チームの育成状態に関する育成データが記憶される。図２９は、育成データ記憶部１５５に記憶される育成データの一例を示す図である。図示する育成データＤ１５５には、育成している育成対象チームの高校ＩＤ（シナリオＩＤ）及びチームＩＤ（育成対象チームのＩＤ）と、メンバＩＤ（育成対象チームに含まれる各育成対象キャラクタのメンバＩＤ）と、所属メンバ（育成対象チームに含まれる育成対象キャラクタ）のキャラクタデータ（全体データ、基本能力データ、特殊能力データ等）と、学年と、卒部フラグとが関連付けられる。メンバＩＤは、このチーム（育成対象チーム）に所属するメンバ（育成対象キャラクタ）を識別する識別情報である。所属メンバのキャラクタデータは、このチームに所属する高校キャラクタ、任意キャラクタ、及びエキストラキャラクタのキャラクタデータである。育成パートにおいて、ユーザが育成パートを実施する高校（シナリオ）を選択すると、チームＩＤが発行されて高校ＩＤと関連付けられ、育成対象の設定（育成パートでの育成対象チームに含まれる育成対象キャラクタの設定）さらに所属メンバ（育成対象キャラクタ）のキャラクタデータがキャラクタデータ記憶部１５１に記憶されているキャラクタデータＤ１５１からコピーされて関連付けられて、新たに育成する育成対象チームの育成データＤ１５５が生成される。また、育成期間の途中でメンバが入部すると、入部したメンバのメンバＩＤが発行され、当該メンバのキャラクタデータがキャラクタデータＤ１５１からコピーされて育成データに追加される。学年は、所属メンバの学年を示し、育成パートの進行に伴い変化する。上述した通り、学年を示す可変なパラメータの代わりに、育成期間の進行によらず固定的なパラメータを用いても良い。卒部フラグは、卒部したか否かを示すフラグ情報であり、初期値は「０」で卒部すると「１」に変更される。育成パートでは、この育成データＤ１５５のデータ（能力パラメータ等）が更新され、キャラクタデータ記憶部１５１に記憶されているキャラクタデータＤ１５１のデータは更新されない。

チームデータ記憶部１５６には、高校（シナリオ）ごとに保持しているチーム（育成済チーム）のチームデータが記憶される。このチームデータには、ユーザが育成した育成済チームと、高校ごとに設定されているデフォルトチームとの両方が含まれる。図３０は、チームデータ記憶部１５６に記憶されるチームデータの一例を示す図である。図示するチームデータＤ１５６には、高校ＩＤ、高校名、チームＩＤ、チーム名、選択肢フラグ、利用フラグ、チームの戦力（能力）としての総合戦力、打撃力、守備力、機動力、球速、制球力、変化球等が関連付けられている。選択肢フラグは、利用設定の際に選択肢となるか否かを示すフラグ情報である。選択肢となるチームには「１」が設定され、選択肢とならないチームには「０」が設定される。基本的には、育成済チームと育成実績のない高校のデフォルトチームとには「１」が設定され、育成実績のある高校のデフォルトチームには「０」が設定される。利用フラグは、利用設定されているか否かを示すフラグ情報であり、利用設定されているチームに「１」が設定され、利用設定されていないチームには「０」が設定される。また、チームデータＤ１５６には、上記情報以外のチームに関する情報（例えば、チームの対戦成績等）も含まれる。なお、このチームデータは、サーバ装置３０に送信され、サーバ装置３０で複数のユーザのチームデータがユーザごと（ユーザＩＤごと）に関連付けられて管理される。

チームメンバデータ記憶部１５７には、各チーム（育成済チーム）の所属メンバ（育成済キャラクタ）のキャラクタデータが含まれるチームメンバデータが記憶される。図３１は、チームメンバデータ記憶部１５７に記憶されるチームメンバデータの一例を示す図である。図示するチームメンバデータＤ１５７には、チームデータＤ１５６（図３０参照）に含まれるチームについての所属メンバに関する情報が記憶される。例えば、チームメンバデータＤ１５７には、チームＩＤごとに、メンバＩＤと、所属メンバ（キャラクタ）のキャラクタデータ（全体データ、基本能力データ、特殊能力データ等）と、オーダーフラグとが関連付けられている。ここで、育成済チームの所属メンバ（育成済キャラクタ）のキャラクタデータ（全体データ、基本能力データ、特殊能力データ等）は、育成パートが終了した育成済チームの育成データＤ１５５のキャラクタデータをコピーしたものである。即ち、チームメンバデータＤ１５７には、育成が完了した更新済みの確定されたキャラクタデータが育成済チームの所属メンバ（育成済キャラクタ）のキャラクタデータとして保持される。一方、デフォルトチームの所属メンバ（キャラクタ）のキャラクタデータ（全体データ、基本能力データ、特殊能力データ等）には、デフォルトチームとして予め設定されたキャラクタデータが保存されている。オーダーフラグは、チームのオーダー設定に応じて設定されるフラグ情報である。例えば、オーダーフラグには、レギュラー（スターティングオーダー）メンバには「１」が設定され、ベンチ入りメンバには「２」が設定され、ベンチ外メンバには「０」が設定される。なお、このチームメンバデータは、サーバ装置３０に送信され、サーバ装置３０で複数のユーザのチームメンバデータがユーザごと（ユーザＩＤごと）に関連付けられて管理される。

図２５に戻り、制御部１６０は、操作受付部１６１と、表示制御部１６２と、育成パート処理部１６３と、利用チーム設定部１６４と、オーダー設定部１６５と、対戦パート処理部１６６とを備えている。

操作受付部１６１は、入力部１２に対する操作を受け付ける。操作受付部１６１は、前述した各種のゲーム画面におけるユーザの操作に基づいて、入力部１２に対して入力された操作信号を取得する。例えば、操作受付部１６１は、ユーザの操作に基づいて、複数の選択肢のいずれかを仮選択する操作と、仮選択された選択肢を選択決定する操作とを受け付ける。具体的には、例えば図１３に示す練習メニュー画面Ｇ６００において、アイコンＰ６３２（「コントロール練習」）に対する操作に基づいて、アイコンＰ６３２を仮選択する操作を受け付ける。また、例えば図１３に示す練習メニュー画面Ｇ６００において、アイコンＰ６３２（「コントロール練習」）が仮選択されている状態で、「決定」が表示されたアイコンＰ６２３に対する操作に基づいて、アイコンＰ６３２を選択決定する操作を受け付ける。

表示制御部１６２は、前述した各種のゲーム画面に対応する画像を表示部１３に表示させる。例えば、表示制御部１６２は、図１３に示す練習メニュー画面Ｇ６００において、複数の選択肢のそれぞれに対して設定された更新条件を、ユーザの選択に先立ち予めユーザに認識可能に表示させることにより、ユーザに提示する（例えば、図１３のアイコンＰ６３１、Ｐ６３２、Ｐ６３３、Ｐ６３４参照）。また、表示制御部１６２は、いずれかの選択肢がユーザの操作に基づいて仮選択された場合、少なくとも一方の選択肢に設定された更新条件が変更されたそれぞれの更新条件をユーザに認識可能に表示させることにより、ユーザに提示する。例えば、図１３に示すように、表示制御部１６２は、ユーザの操作に基づいて仮選択された選択肢（例えば、アイコンＰ６３２）に設定された更新条件を＋アルファした値に変更された更新条件で表示させ、仮選択されていない選択肢に設定された更新条件は変更せずに表示させる。

育成パート処理部１６３は、育成パートの処理を実行する。例えば、育成パート処理部１６３は、選択部１６３１と、更新指示部１６３２と、更新部１６３３と、育成提供部１６３４と、データ管理部１６３５と、育成キャラクタ設定部１６３６とを備えている。

選択部１６３１は、育成パートで育成する育成対象チームの高校をユーザに選択させる。例えば、選択部１６３１は、図６に示す高校選択画面Ｇ３００において、複数の高校の選択肢の中から選択された高校を、育成パートで育成する育成対象チームの高校として選択する。なお、育成パートにおける高校の選択は、育成パートにおけるシナリオの選択に相当する。

更新指示部１６３２は、チーム（育成対象チーム）に含まれる複数のキャラクタ（育成対象キャラクタ）に関連付けられるデータの更新を指示する。例えば、更新指示部１６３２は、チームに含まれる複数のキャラクタのいずれかが関連付けられた選択肢を含む複数の選択肢（例えば、図１３に示す練習メニュー画面Ｇ６００における各練習項目のアイコンＰ６３１、Ｐ６３２、Ｐ６３３、Ｐ６３４）のうち、ユーザにより選択された選択肢に関連付けられたキャラクタに対してデータの更新を指示する。具体的には、更新指示部１６３２は、複数の選択肢のそれぞれに対して設定された更新条件に基づいて、ユーザにより選択された選択肢に関連付けられたキャラクタのそれぞれに対して、当該選択肢に設定された更新条件に基づく更新を指示する。つまり、更新指示部１６３２は、同一の選択肢に関連付けられたキャラクタには、当該選択肢に設定された同一の更新条件に基づく更新を指示する。ここで、例えば、更新条件は、対応する選択肢に関連付けられたキャラクタに基づいて設定される。

また、更新指示部１６３２は、ユーザにより選択された選択肢に設定された更新条件とユーザにより選択されなかった選択肢に設定された更新条件とのうちの少なくとも一方を変更した更新条件のそれぞれに基づいて、ユーザにより選択された選択肢に関連付けられたキャラクタ（育成対象キャラクタ）のそれぞれに対して更新を指示するとともに、ユーザにより選択されなかった選択肢に関連付けられたキャラクタ（育成対象キャラクタ）のそれぞれに対しても更新を指示する。ここで、上記の「少なくとも一方の更新条件の変更」は、ユーザにより選択された選択肢の方がユーザにより選択されなかった選択肢より有利な変更である。例えば、更新指示部１６３２は、ユーザの操作に基づいて選択された選択肢に関連付けられたキャラクタのそれぞれに対しては、元の更新条件（元の設定値）に＋アルファされた値でデータの更新を指示する。一方、更新指示部１６３２は、選択されていない選択肢に関連付けられたキャラクタのそれぞれに対しては、元の更新条件（元の設定値）でデータの更新を指示する。

更新部１６３３は、育成パートにおいて、チーム（育成対象チーム）に関連付けられるデータを更新する。例えば、更新部１６３３は、ユーザにより選択された高校（シナリオ）に応じた育成対象チームに関連付けられるデータを更新する。育成対象チームに関連付けられるデータとは、育成対象チームに含まれるキャラクタ（育成対象キャラクタ）の全体データ、基本能力データ、及び特殊能力データや、当該キャラクタのデータに伴って変化するチームのデータ（総合戦力や各能力のデータ）等である。具体的には、更新部１６３３は、更新指示部１６３２による１回（例えば、１ターン）の指示に応じて、育成対象チームに含まれる２以上のキャラクタ（育成対象キャラクタ）のそれぞれに関連付けられるデータ（図２９の育成データＤ１５５）を更新する。

なお、更新部１６３３は、育成期間（所定の期間）において、育成対象チームに関連付けられるデータを更新する。具体的には、更新部１６３３は、育成期間（所定の期間）内の育成パートの進行に従って、育成対象チームに含まれるキャラクタ（育成対象キャラクタ）に関連付けられるデータを更新する。なお、更新部１６３３は、ユーザに関連付けられたデータ（即ち、所有キャラクタ）に基づいて育成対象チームに含まれるキャラクタとして設定された育成対象キャラクタに関連付けられるデータも更新する。育成パートにおいては、ユーザに関連付けられたデータ（即ち、所有キャラクタ）そのものは更新されない。

育成提供部１６３４は、更新指示部１６３２による１回（例えば、１ターン）の指示機会を、ユーザに所定回数（例えば、１２０ターン）を上限とした複数回提供する。

データ管理部１６３５は、データ記憶部１５０に記憶される各種データの保存、更新等を管理する。例えば、データ管理部１６３５は、育成パートにおいて更新された育成済チームを複数管理する。具体的には、データ管理部１６３５は、育成パートにおいて更新された複数の育成済チームのチームデータ、及び育成済チームに含まれるキャラクタ（育成済キャラクタ）に関連付けられるデータが更新されたチームメンバデータのそれぞれを、チームデータ記憶部１５６及びチームメンバデータ記憶部１５７のそれぞれに記憶させて管理する。なお、データ管理部１６３５がチームデータ記憶部１５６及びチームメンバデータ記憶部１５７のそれぞれに記憶させるデータは、育成パートの終了に応じて更新が完了した育成済チームのデータである。データ管理部１６３５は、複数の育成済チームのそれぞれを高校（シナリオ）ごとに管理する。なお、データ管理部１６３５により管理されている上記更新が完了した育成済チームのデータについては、再び更新されることはない。

また、データ管理部１６３５は、育成パートによる育成対象チームの育成（データの更新）が行われる前から、高校（シナリオ）ごとにデフォルトチームを対戦パートで対戦に使用されるチームとして予め関連付けて管理している。例えば、データ管理部１６３５は、デフォルトチームのチームデータ及びチームメンバデータのそれぞれを、育成済チームのチームデータ及びチームメンバデータのそれぞれと同様に、チームデータ記憶部１５６及びチームメンバデータ記憶部１５７のそれぞれに記憶させて管理している。

また、データ管理部１６３５は、遊技価値（課金またはゲームの進行に応じて入手されるゲーム内コインやチケット等）の消費と引換えにキャラクタを示すデータをユーザに関連付けて、所有キャラクタデータ記憶部１５３に記憶させて管理する。例えば、データ管理部１６３５は、サーバ装置３０で行われる抽選処理の抽選結果に応じて、抽選されたイベキャラを示すデータをサーバ装置３０から取得する。

育成キャラクタ設定部１６３６は、育成パートにおいて、ユーザにより選択された高校（シナリオ）に応じて定まる高校キャラクタと、ユーザに関連付けられているデータ（ユーザの所有キャラクタ）のうちからユーザにより選択されたデータに基づいて設定される任意キャラクタとを、育成対象チームに含まれる所属メンバ（育成対象キャラクタ）として設定する。また、育成キャラクタ設定部１６３６は、高校キャラクタ及び任意キャラクタ以外にエキストラキャラクタも、育成対象チームに含まれる所属メンバ（育成対象キャラクタ）として設定する。育成キャラクタ設定部１６３６は、設定したデータを、育成データ（図２９参照）として育成データ記憶部１５５にデータ管理部１６３５を介して記憶させる。

また、育成キャラクタ設定部１６３６は、追加部１６３７と、解除部１６３８とを備えている。追加部１６３７は、育成パートにおいて、育成期間の途中に入部するキャラクタ（育成対象キャラクタ）がある場合、育成対象（更新の対象）として育成対象チームに含まれる育成対象キャラクタとして、育成データＤ１５５（図２９参照）に追加する。解除部１６３８は、育成パートにおいて、育成期間の途中に卒部する育成対象キャラクタがある場合、育成対象（更新の対象）として育成対象チームに含まれる卒部する育成対象キャラクタを育成対象（更新の対象）から除外する（卒部フラグを「０」から「１」に変更する）（図２９参照）。なお、育成対象チームに含まれる卒部する育成対象キャラクタを育成対象（更新の対象）から除外するとは、一時的に育成対象（更新の対象）ではなくなるだけであり、当該育成対象チームとの関連付けがなくなるわけではない。

なお、育成対象チームに含まれる育成対象キャラクタには、育成パートの開始時点で、育成パートにより更新される期間（育成期間）が異なることにより初期状態のデータが異なる複数のキャラクタ（育成パートの開始時点で１年生、２年生、及び３年生のキャラクタ）が含まれてもよい。好適には、育成パートの開始時点で２年生の状態である育成対象キャラクタは、育成パートの開始時点で１年生の状態である育成対象キャラクタよりも、全般的に能力パラメータが高く、育成パートの開始時点で３年生の状態である育成対象キャラクタは、育成パートの開始時点で２年生の状態である育成対象キャラクタよりも、全般的に能力パラメータが高くなるように、各育成対象キャラクタの初期状態のキャラクタデータが設定される。

利用チーム設定部１６４は、ユーザの操作に基づいて、他ユーザにより実行される対戦パートで当該他ユーザの対戦相手として使用され得るチーム（育成済チーム）を、ユーザの所有する複数のチーム（育成済チーム）のうちから予め設定（利用設定）する。例えば、利用チーム設定部１６４は、ユーザの操作に基づいて、他ユーザの対戦相手として使用され得るチームを異なる高校（シナリオ）のそれぞれにおいて、複数のチーム（育成済チーム）のうちから予め設定（利用設定）する。具体的には、利用チーム設定部１６４は、図２１に示す利用設定画面Ｇ１０００に対するユーザの操作に基づいて高校ごとにチームの利用設定を行い、チームデータ記憶部１５６に記憶されているチームデータＤ１５６（図３０参照）の利用フラグを、データ管理部１６３５を介して設定する。他ユーザにより実行される対戦パートで当該他ユーザの対戦相手として、当該他ユーザに使用されるチームと同一の高校で利用設定されているチームが対戦相手として選択される。

オーダー設定部１６５は、ユーザの操作に基づいて、育成済チームに含まれる複数のキャラクタ（育成済キャラクタ）のうち対戦パートで使用するチーム（育成済チーム）のオーダー（レギュラー及びベンチ入りのキャラクタ）を設定する。例えば、オーダー設定部１６５は、図２２に示すオーダー設定画面Ｇ１１００に対するユーザの操作に基づいてオーダーを設定し、チームメンバデータ記憶部１５７に記憶されているチームメンバデータＤ１５７のオーダーフラグ（図３１参照）を、データ管理部１６３５を介して設定する。

ここで、育成済チームのオーダーには、育成パートでデータが更新された高校キャラクタ、任意キャラクタ、エキストラキャラクタのいずれが含まれてもよい。なお、オーダー設定部１６５は、対戦パートで使用するチームに含まれるオーダーとして設定することができる育成済キャラクタの数を、育成済キャラクタの種類（高校キャラクタ／任意キャラクタ／エキストラキャラクタ）に応じて制限してもよい。例えば、オーダーに設定可能な高校キャラクタとしての育成済キャラクタの数を、予め設定された数（或いは、全所属メンバ数に対して予め設定された割合）を上限としてもよい。

対戦パート処理部１６６は、対戦パートの処理を実行する。対戦パート処理部１６６は、チーム選択部１６６１と、対戦相手決定部１６６２と、対戦処理部１６６３と、アイテム処理部１６６４とを備えている。

チーム選択部１６６１は、ユーザの操作に基づいて、データ管理部１６３５により管理されている複数のチーム（育成済チーム）のうちから対戦で使用する一のチーム（育成済チーム）を選択する。例えば、チーム選択部１６６１は、ユーザの操作に基づいて、まず対戦で使用する高校（シナリオ）を選択し、次に、選択された高校に対戦で使用するチームとして選択可能なチームが複数ある場合、ユーザの操作に基づいて対戦で使用するチームを選択してもよい。対戦で使用するチームとして選択可能なチームは、チームデータ記憶部１５６に記憶されているチームデータＤ１５６で選択肢フラグに「１」が設定されているチームである。なお、チーム選択部１６６１は、ユーザの操作に基づいて対戦で使用する高校を選択した後、チームデータＤ１５６を参照して、選択された高校で利用設定されているチーム（利用フラグに「１」が設定されているチーム）を対戦で使用するチームを選択してもよい。また、対戦における高校をユーザの選択によらず自動的に決定されるようにしてもよい。この場合、対戦における高校（シナリオ）が予め決定された前提で、試合に使用されるチーム（育成済チーム）が選択されるようにしてもよい。

対戦相手決定部１６６２は、対戦パートにおける試合の対戦相手のマッチングを行う。例えば、対戦相手決定部１６６２は、利用チーム設定部１６４により高校（シナリオ）ごとに利用設定されたチーム（育成済チーム）に基づいて、複数の他ユーザのうちから対戦相手となるユーザを決定する。具体的には、例えば、対戦相手決定部１６６２は、チームデータＤ１５６（図３０）を参照して、高校ごとに利用設定されたチームの能力を総合した値（例えば、総合戦力の合計値）に基づいて、複数の他ユーザのうちから当該合計値が相対的に近いユーザを対戦相手となるユーザとして決定する。また、対戦相手決定部１６６２は、対戦相手として同一の高校のチームを選択する。つまり、対戦相手決定部１６６２は、対戦相手として決定したユーザのチームのうち同一の高校で利用設定されているチームを対戦相手のチームとして選択する。なお、他ユーザのデータは、通信部１１を介してサーバ装置３０から取得される。

なお、対戦パートにおける試合の対戦相手のマッチングは、サーバ装置３０で行われてもよい。その場合、対戦相手決定部１６６２は、対戦相手のマッチングの結果をサーバ装置３０から通信部１１を介して取得する。

対戦処理部１６６３は、対戦パートにおいて、管理されているチーム（育成済チーム）を使用した対戦処理を、育成パートにおいて更新が完了したデータに基づいて行なう。例えば、対戦処理部１６６３は、対戦に使用するチームとして選択されたチームに含まれる複数のキャラクタ（育成済キャラクタ）のうちの少なくとも一部（例えば、オーダー設定されているキャラクタ）を使用して対戦処理を行なう。また、対戦処理部１６６３は、対戦に使用するチームとして選択されたチームと、対戦相手決定部１６６２により決定された対戦相手のチームとの対戦処理を、それぞれのデータ（能力パラメータ等）に基づいて実行し、対戦結果（勝敗等）に基づく情報を出力する。

アイテム処理部１６６４は、対戦パートにおいて試合を開始する際にユーザの操作に基づいてユーザの所有するアイテムの使用が指示された場合、使用するアイテムの種類に基づいて、対戦パートにおいて使用するチーム（育成済キャラクタ）に関連付けられたデータを一時的に変更する。例えば、アイテム処理部１６６４は、特定のアイテム（強化アイテム）の消費と引き換えに、対戦パートにおいて使用するチーム（育成済チーム）に関連付けられた能力パラメータの値、または当該チームに含まれるキャラクタ（育成済キャラクタ）に関連付けられた能力パラメータの値等を、その対戦のみに限って向上させる。

〔６．ゲーム処理の動作〕
次に、図３２から図３９を参照して、端末装置１０のＣＰＵ１６がゲーム制御プログラムに基づいて実行するゲーム処理の動作について説明する。

〔６−１．育成パート処理の動作〕
図３２は、本実施形態に係る育成パート処理の一例を示すフローチャートである。この図において、図５の各処理に対応する処理には、同一の符号を付している。

ＣＰＵ１６は、育成対象の設定処理を実行する(ステップＳ１００)。具体的には、図３３を参照して説明する。図３３は、本実施形態に係る育成対象の設定処理の一例を示すフローチャートである。

ＣＰＵ１６は、ユーザにチームの高校（シナリオ）を選択させる処理を実行する(ステップＳ１０１)。このチームとは、育成パートで育成するチーム（育成対象チーム）である。例えばＣＰＵ１６は、表示部１３の表示画面を図６に示す高校選択画面Ｇ３００に遷移させる。ＣＰＵ１６は、高校選択画面Ｇ３００に表示された複数の高校のそれぞれを選択するためのアイコンＰ３１１、Ｐ３１２、Ｐ３１３、Ｐ３１４、Ｐ３１５のいずれかが選択されたか否かを判定する(ステップＳ１０３)。ＣＰＵ１６は、いずれの高校（アイコン）も選択されていないと判定した場合には（ステップＳ１０３：ＮＯ）、ステップＳ１０３の判定処理を継続する。

一方、ＣＰＵ１６は、いずれかの高校（アイコン）が選択されたと判定した場合には（ステップＳ１０３：ＹＥＳ）、選択された高校に応じて定まる高校キャラクタと、ユーザに関連付けられているデータ（ユーザが所有キャラクタ）のうちからユーザにより選択されたデータに基づいて設定される任意キャラクタとを育成対象チームに含まれる所属メンバ（育成対象キャラクタ）として設定する処理を実行する(ステップＳ１０５)。また、ＣＰＵ１６は、エキストラキャラクタを育成対象チームに含まれる所属メンバ（育成対象キャラクタ）として設定する処理を実行する(ステップＳ１０７)。育成対象チームに含まれる構成要素には、育成パートの開始時点で、育成パートにより更新される期間（育成期間）が異なることにより初期状態のデータが異なる複数のキャラクタ（育成パートの開始時点で１年生、２年生、及び３年生のキャラクタ）が含まれてもよい。ＣＰＵ１６は、選択された高校の育成対象チームの育成データとして、上記高校キャラクタと任意キャラクタとエキストラキャラクタと含む育成対象チームの育成データ（図２９の育成データＤ１５５参照）を生成する。

図３２に戻り、ＣＰＵ１６は、「育成」の１ターンの処理を実行する(ステップＳ１１０)。１ターンの処理では、ＣＰＵ１６は、育成対象チームに含まれる複数のキャラクタ（育成対象キャラクタ）に関連付けられるデータの更新を指示する処理と、当該指示に応じて、育成対象チームに関連付けられるデータを更新する処理とを実行する。例えば、ＣＰＵ１６は、１回（１ターン）の指示に応じて、育成対象チームに含まれる２以上のキャラクタ（育成対象キャラクタ）のそれぞれに関連付けられるデータを更新する処理を実行する。また、ＣＰＵ１６は、育成期間（所定の期間）内の育成パートの進行に従って、育成対象チームに含まれるキャラクタ（育成対象キャラクタ）に関連付けられるデータを更新する。例えば、ＣＰＵ１６は、ユーザに関連付けられたデータ（所有キャラクタからユーザに選択されたキャラクタ）に基づいて育成対象チームに含まれるキャラクタ（任意キャラクタ）として設定された育成対象キャラクタに関連付けられるデータを更新する処理を実行する。

ＣＰＵ１６は、育成パートの終了条件が充足されたか否かを判定する(ステップＳ１４０)。ステップＳ１４０の処理には、ステップＳ１４１及びステップＳ１４３の処理が含まれる。例えば、ＣＰＵ１６は、育成パートの終了条件として、育成期間中の特定のターンで行わる試合で敗戦したか否かを判定する(ステップＳ１４１)。ＣＰＵ１６は、試合で敗戦していないと判定した場合（ステップＳ１４１：ＮＯ）、育成パートの終了条件が充足されていないと判定する。一方、ＣＰＵ１６は、試合で敗戦したと判定した場合（ステップＳ１４１：ＹＥＳ）、育成パートの終了条件が充足されたと判定し、育成結果を反映（その時点で育成対象チームに在籍するメンバ（育成対象キャラクタ）に、育成期間の途中で卒部したメンバ（育成対象キャラクタ）を加えた育成対象チームを、育成済チームとして保存）して、育成パートの処理を終了する(ステップＳ１５０)。

また、ＣＰＵ１６は、育成パートの終了条件として、所定回数のターン処理（例えば、１２０ターン）が終了したか否かを判定する(ステップＳ１４３)。ＣＰＵ１６は、所定回数のターン処理（例えば、１２０ターン）が終了していないと判定した場合（ステップＳ１４３：ＮＯ）、育成パートの終了条件が充足されていないと判定する。一方、ＣＰＵ１６は、所定回数のターン処理（例えば、１２０ターン）が終了したと判定した場合（ステップＳ１４３：ＹＥＳ）、育成結果を反映して（その時点で育成対象チームに在籍するメンバ（育成対象キャラクタ）に、育成期間の途中で卒部したメンバ（育成対象キャラクタ）を加えた育成対象チームを、育成済チームとして保存して）、育成パートの処理を終了する(ステップＳ１５０)。

このように、ＣＰＵ１６は、ステップ１１０及びステップＳ１４０（ステップＳ１４３）の処理により、１回（１ターン）の指示機会を、ユーザに所定回数（例えば、１２０ターン）を上限とした複数回提供する処理を実行する。即ち、ＣＰＵ１６は、所定回数（例えば、１２０ターン）を上限とした所定の期間（育成期間）、育成対象チームに関連付けられるデータを更新する処理を繰り返し実行する。

なお、ステップＳ１４１の処理とステップＳ１４３の処理とは、順序を入れ替えてもよいし、平行処理としてもよい。また、育成パートの終了条件に、ユーザの意思で中断することが含まれてもよい。例えば、ＣＰＵ１６は、育成期間中にユーザの操作により育成を中断する指示を受け付けた場合、育成結果を反映せずに育成パートの処理を終了してもよい。

ＣＰＵ１６は、育成パートの終了条件が充足されていないと判定した場合（ステップＳ１４１：ＮＯ、またはステップＳ１４３：ＮＯ）、育成対象の変更タイミングであるか否かを判定する(ステップＳ１４５)。育成対象の変更タイミングとは、２年目及び３年目の春（４月１週）と、１年目、２年目、及び３年目の秋（９月４週）である。ＣＰＵ１６は、育成対象の変更タイミングではないと判定した場合（ステップＳ１４５：ＮＯ）、ステップＳ１１０に戻り、次のターンの処理を実行する。一方、ＣＰＵ１６は、育成対象の変更タイミングであると判定した場合（ステップＳ１４５：ＹＥＳ）、育成対象を変更する処理（育成対象変更処理）を実行する(ステップＳ１４７)。この育成対象変更処理については、図３６を参照して後述する。

ステップＳ１５０の育成結果を反映する処理において、ＣＰＵ１６は、育成パートにおいて更新を完了した育成済チームを複数管理する処理を実行する。例えば、ＣＰＵ１６は、育成パートの終了に応じて更新が完了した育成済チームのデータを管理する処理を実行する。この管理されている更新が完了した育成済チームのデータについては、育成パートの終了の後には再び更新されることはない。また、ＣＰＵ１６は、複数の育成済チームのそれぞれを高校（シナリオ）ごとに管理する処理を実行する。また、ＣＰＵ１６は、育成済チームに含まれるキャラクタ（育成済キャラクタ）に関連付けられるデータが更新された育成済チームを、複数管理する処理を実行する。

また、ＣＰＵ１６は、育成パートによる育成対象チームの更新（育成）が行われる前から、高校（シナリオ）ごとにデフォルトチームを対戦パートで対戦に使用されるチームとして予め関連付けて管理する処理を実行する。

なお、ＣＰＵ１６は、遊技価値（課金またはゲームの進行に応じて入手されるゲーム内コインやチケット）の消費と引換えにキャラクタを示すデータをユーザに関連付ける処理を実行してもよい。具体的には、ＣＰＵ１６は、キャラクタを示すデータをユーザに関連付けて所有キャラクタデータ記憶部１５３に記憶させて管理してもよい。

〔1ターン処理の動作〕
次に、図３４を参照して、図３２のステップＳ１１０における１ターン処理の動作の詳細について説明する。図３４は、本実施形態に係る1ターン処理の一例を示すフローチャートである。

ＣＰＵ１６は、午前イベントが設定されているターン（図１０のイベント発生スケジュール参照）では、設定されているイベントの処理を実行する(ステップＳ１１１)。ここでは、シナリオイベント（高校固有（シナリオ固有）のイベントと、高校共通（シナリオ共通）のイベント）とイベキャライベント（イベキャラによるイベント）のうち、予め定められた発生条件の成立している全てのイベントが、処理の実行の対象として設定される。例えば、ＣＰＵ１６は、設定されているイベントに対応するイベント画面（例えば、図９のイベント画面Ｇ４００）に遷移させ、イベントのストーリーに応じた複数のイベント画像を順に表示させる。このとき、処理を実行したイベントの結果として、育成対象チームに含まれる育成対象キャラクタの能力パラメータ等、各種のパラメータに変化をもたらす。複数のイベントが発生する場合には、複数のイベントの結果がそれぞれ反映される。イベント処理が終了すると、ＣＰＵ１６は、表示部１３の表示画面を監督メニュー画面Ｇ５００（図１１参照）に遷移させる(ステップＳ１１３)。なお、午前イベントが設定されていないターンでは、ＣＰＵ１６は、イベント処理を行なわずにステップＳ１１３の処理に進む。

ＣＰＵ１６は、監督メニュー画面Ｇ５００において、入力部１２からの操作信号に基づいて、メニュー項目（「練習」、「建設」、「ミッション」、「監督スキル」、「伝授」）のいずれかを選択する操作を受け付けたか否かを判定する。具体的には、ステップＳ１１５において、ＣＰＵ１６は、アイコンＰ５２０（「建設」）を選択する操作を受け付けたか否かを判定する。ＣＰＵ１６は、アイコンＰ５２０（「建設」）を選択する操作を受け付けたと判定した場合（ステップＳ１１５：ＹＥＳ）、前述した「建設」についての建設処理を実行する(ステップＳ１１７)。ＣＰＵ１６は、建設処理が終了すると監督メニュー画面Ｇ５００（図１１参照）に戻す（ステップＳ１１３）。

一方、ＣＰＵ１６は、アイコンＰ５２０（「建設」）を選択する操作を受け付けていないと判定した場合（ステップＳ１１５：ＮＯ）、ステップＳ１１９において、アイコンＰ５３０（「ミッション」）を選択する操作を受け付けたか否かを判定する。ＣＰＵ１６は、アイコンＰ５３０（「ミッション」）を選択する操作を受け付けたと判定した場合（ステップＳ１１９：ＹＥＳ）、前述した「ミッション」についてのミッション処理を実行する(ステップＳ１２１)。例えば、ＣＰＵ１６は、表示部１３の表示画面をミッション画面Ｇ７００（図１５参照）に遷移させる。ＣＰＵ１６は、ミッション処理が終了すると監督メニュー画面Ｇ５００（図１１参照）に戻す（ステップＳ１１３）。

一方、ＣＰＵ１６は、アイコンＰ５３０（「ミッション」）を選択する操作を受け付けていないと判定した場合（ステップＳ１１９：ＮＯ）、ステップＳ１２３において、アイコンＰ５４０（「監督スキル」）を選択する操作を受け付けたか否かを判定する。ＣＰＵ１６は、アイコンＰ５４０（「監督スキル」）を選択する操作を受け付けたと判定した場合（ステップＳ１２３：ＹＥＳ）、前述した「監督スキル」についての監督スキル処理を実行する(ステップＳ１２５)。例えば、ＣＰＵ１６は、表示部１３の表示画面を監督スキル画面Ｇ８００（図１６参照）に遷移させる。ＣＰＵ１６は、監督スキル処理が終了すると監督メニュー画面Ｇ５００（図１１参照）に戻す（ステップＳ１１３）。

一方、ＣＰＵ１６は、アイコンＰ５４０（「監督スキル」）を選択する操作を受け付けていないと判定した場合（ステップＳ１２３：ＮＯ）、ステップＳ１２７において、アイコンＰ５５０（「伝授」）を選択する操作を受け付けたか否かを判定する。ＣＰＵ１６は、アイコンＰ５５０（「伝授」）を選択する操作を受け付けたと判定した場合（ステップＳ１２７：ＹＥＳ）、前述した「伝授」についての伝授処理を実行する(ステップＳ１２９)。例えば、ＣＰＵ１６は、表示部１３の表示画面を伝授画面Ｇ９００（図１６参照）に遷移させる。ＣＰＵ１６は、伝授処理が終了すると監督メニュー画面Ｇ５００（図１１参照）に戻す（ステップＳ１１３）。

一方、ＣＰＵ１６は、アイコンＰ５５０（「伝授」）を選択する操作を受け付けていないと判定した場合（ステップＳ１２７：ＮＯ）、ステップＳ１３１においてアイコンＰ５１０（「練習」）を選択する操作を受け付けたか否かを判定する。ＣＰＵ１６は、アイコンＰ５１０（「練習」）を選択する操作を受け付けたと判定した場合（ステップＳ１３１：ＹＥＳ）、前述した「練習」に関する練習処理を実行する(ステップＳ１３３)。例えば、ＣＰＵ１６は、表示部１３の表示画面を練習メニュー画面Ｇ６００（図１３参照）に遷移させる。一方、ＣＰＵ１６は、アイコンＰ５１０（「練習」）を選択する操作を受け付けていないと判定した場合（ステップＳ１３１：ＮＯ）、監督メニュー画面Ｇ５００（図１１参照）に戻すまたは継続する（ステップＳ１１３）。

ＣＰＵ１６は、練習処理が終了すると、午後イベントが設定されているターン（図１０のイベント発生スケジュール参照）では、午前イベントに関する処理と同様に、設定されているイベントの処理を実行する(ステップＳ１３５)。イベント処理が終了すると、ＣＰＵ１６は、１ターン処理を終了する。なお、午後イベントが設定されていないターンでは、ＣＰＵ１６は、練習処理が終了すると、イベント処理を行なわずに１ターン処理を終了する。

なお、ステップＳ１１５、Ｓ１１９、Ｓ１２３、Ｓ１２７、Ｓ１３１の判定処理は、順序を入れ替えてもよいし、平行処理としてもよい。

〔練習処理の動作〕
次に、図３５を参照して、図３４のステップＳ１３３における練習処理の動作の詳細について説明する。図３５は、本実施形態に係る練習処理の一例を示すフローチャートである。
ＣＰＵ１６は、表示部１３の表示ｖを練習メニュー画面Ｇ６００（図１３参照）に遷移させ、複数の選択肢（例えば、図１３のアイコンＰ６３１、Ｐ６３２、Ｐ６３３、Ｐ６３４参照）(ステップＳ１３３１)のそれぞれに対して設定された更新条件を、ユーザに認識可能に提示する処理を実行する。即ち、ＣＰＵ１６は、複数の選択肢のそれぞれに対して設定された更新条件を、ユーザの選択に先立ち予めユーザに認識可能なように表示部１３に表示させる。

ＣＰＵ１６は、ユーザの操作に基づいて、複数の選択肢（例えば、図１３のアイコンＰ６３１、Ｐ６３２、Ｐ６３３、Ｐ６３４）のいずれかを仮選択する操作を受け付ける処理を実行する。また、ＣＰＵ１６は、ユーザの操作に基づいて、複数の選択肢のいずれかが仮選択されたか否かを判定する(ステップＳ１３３３)。ＣＰＵ１６は、いずれの選択肢もユーザの操作に基づいて仮選択されていないと判定された場合(ステップＳ１３３３：ＮＯ)、ステップＳ１３３３の判定処理を継続する。

一方、ＣＰＵ１６は、いずれかの選択肢がユーザの操作に基づいて仮選択されたと判定された場合(ステップＳ１３３３：ＹＥＳ)、仮選択された選択肢と、仮選択されていない選択肢とのうち、少なくとも一方の選択肢に設定された更新条件が変更されたそれぞれの更新条件をユーザに認識可能に提示する処理を実行する(ステップＳ１３３５)。例えば、図１３に示すように、ユーザの操作に基づいて仮選択された選択肢（例えば、アイコンＰ６３２）に設定された更新条件（元の更新条件）に＋アルファされた値に変更された更新条件で表示させ、仮選択されていない選択肢（例えば、アイコンＰ６３１、Ｐ６３３、Ｐ６３４）に設定された更新条件（元の更新条件）は変更せずに表示させる。

ＣＰＵ１６は、ユーザの操作に基づいて、仮選択された選択肢（例えば、アイコンＰ６３２）を選択決定する操作を受け付ける処理を実行する(ステップＳ１３３７)。また、ＣＰＵ１６は、ユーザの操作に基づいて、仮選択された選択肢が選択決定されたか否かを判定する。ＣＰＵ１６は、仮選択された選択肢が選択決定されていないと判定された場合(ステップＳ１３３７：ＮＯ)、ステップＳ１３３３の処理に戻り、仮選択する操作を受け付ける処理を実行し、他の選択肢が仮選択された場合には更新条件の表示を変更する(ステップＳ１３３５)。

一方、ＣＰＵ１６は、仮選択された選択肢（例えば、アイコンＰ６３２）が選択決定されたと判定された場合(ステップＳ１３３７：ＹＥＳ)、当該選択肢に関連付けられた育成対象キャラクタに対してデータの更新を指示する(ステップＳ１３３９)。即ち、ＣＰＵ１６は、育成対象チームに含まれる複数のキャラクタ（育成対象キャラクタ）のいずれかが関連付けられた選択肢を含む複数の選択肢のうち、ユーザにより選択（選択決定）された選択肢（例えば、アイコンＰ６３２）に関連付けられたキャラクタ（育成対象キャラクタ）に対してデータの更新を指示する。例えば、ＣＰＵ１６は、複数の選択肢のそれぞれに対して設定された更新条件に基づいて、ユーザにより選択（選択決定）された選択肢に関連付けられたキャラクタ（育成対象キャラクタ）のそれぞれに対して、当該選択肢に設定された更新条件（同一の更新条件）に基づく更新を指示する。この更新条件は、（元の更新条件）に＋アルファされた値に変更された更新条件である。一方、ＣＰＵ１６は、ユーザにより選択（選択決定）されていない選択肢（例えば、アイコンＰ６３１、Ｐ６３２、Ｐ６３３、Ｐ６３４）に関連付けられたキャラクタ（育成対象キャラクタ）のそれぞれに対しては、元の更新条件（元の設定値）でデータの更新を指示する。このように、ＣＰＵ１６は、ユーザにより選択された選択肢に設定された更新条件とユーザにより選択されなかった選択肢に設定された更新条件とのうちの少なくとも一方を変更した更新条件のそれぞれに基づいて、ユーザにより選択された選択肢に関連付けられたキャラクタ（育成対象キャラクタ）のそれぞれに対してデータの更新を指示するとともに、ユーザにより選択されなかった選択肢に関連付けられたキャラクタ（育成対象キャラクタ）のそれぞれに対してもデータの更新を指示する。

ＣＰＵ１６は、ステップＳ１３３９における指示に応じて、育成対象チームに関連付けられるデータ（例えば、育成対象キャラクタの全体データ、基本能力データ、及び特殊能力データや、育成対象キャラクタのデータに伴って変化する育成対象チームのデータ等）を更新する処理を実行する(ステップＳ１３４１)。例えば、ＣＰＵ１６は、それぞれの選択肢に設定された更新条件に基づいて、それぞれの選択肢に関連付けられた一又は複数のキャラクタ（育成対象キャラクタ）のそれぞれに関連付けられるデータ（図２９の育成データＤ１５５）を更新する。

〔育成対象変更処理の動作〕
次に、図３６を参照して、図３２のステップＳ１４７における育成対象変更処理の動作の詳細について説明する。図３６は、本実施形態に係る育成対象変更処理の一例を示すフローチャートである。この育成対象変更処理は、２年目及び３年目の春（４月１週）と、１年目、２年目、及び３年目の秋（９月４週）のタイミングで行われる。

ＣＰＵ１６は、育成期間の途中に、更新の対象として育成対象チームに含まれる育成対象キャラクタをデータの更新の対象から除外（卒部）する処理を実行する。具体的には、ＣＰＵ１６は、育成データＤ１５５（図２９参照）を参照して、１年目、２年目、及び３年目の秋（９月４週）のタイミングでは、卒部対象の育成対象キャラクタ（即ち、３年生の育成対象キャラクタ）の有無を判定する(ステップＳ１４７１)。ＣＰＵ１６は、１年目、２年目、及び３年目の秋（９月４週）のタイミングで卒部対象の育成対象キャラクタがある場合（ステップＳ１４７１：ＹＥＳ）、育成データＤ１５５における卒部対象の育成対象キャラクタの卒部フラグを「０」から「１」に変更し、育成対象（更新の対象）から除外する(ステップＳ１４７３)。

一方、ＣＰＵ１６は、１年目、２年目、及び３年目の秋（９月４週）のタイミングではない、或いは、１年目、２年目、及び３年目の秋（９月４週）のタイミングであっても卒部対象の育成対象キャラクタがない場合（ステップＳ１４７１：ＮＯ）、ＣＰＵ１６は、ステップＳ１４７５以降の処理により、育成期間（所定の期間）の途中に、データの更新の対象として育成対象チームに含まれる育成対象キャラクタを追加（入部）する処理を実行する。

ステップＳ１４７５において、ＣＰＵ１６は、２年目及び３年目の春（４月１週）のタイミングでは、育成対象キャラクタの追加（入部）の有無を判定する。例えば、１２年目及び３年目の春（４月１週）のタイミングで追加（入部）する育成対象キャラクタがあった場合、卒部した人数分の育成対象キャラクタを入部させることができる。なお、卒部の人数に関係なく、所定の人数を入部させることが可能であってもよい。ＣＰＵ１６は、２年目及び３年目の春（４月１週）のタイミングで育成対象キャラクタの追加（入部）がない場合（ステップＳ１４７５：ＮＯ）、育成対象変更処理を終了させる。一方、ＣＰＵ１６は、２年目及び３年目の春（４月１週）のタイミングで育成対象キャラクタの追加（入部）がある場合（ステップＳ１４７５：ＹＥＳ）、所有キャラクタデータＤ１５３（図２７参照）を参照して、入部させる育成対象キャラの元データとなるキャラクタをユーザの所有キャラクタの中からユーザに選択させるための所有キャラクタの選択肢（リスト）を表示部１３に表示させる(ステップＳ１４７７)。

ＣＰＵ１６は、ユーザの所有キャラクタの中からユーザにより選択されたキャラクタに基づいて入部対象のキャラクタを設定する(ステップＳ１４７９)。ＣＰＵ１６は、選択されたキャラクタに基づいて設定された入部対象のキャラクタのデータを育成データＤ１５５（図２９参照）に追加し、育成対象キャラとして育成対象チームに追加する(ステップＳ１４８１)。

なお、卒部の処理（ステップＳ１４７１〜Ｓ１４７３）と、入部の処理（ステップＳ１４７５〜Ｓ１４８１）とは、順序を入れ替えてもよいし、平行処理としてもよい。

〔６−２．対戦パート処理の動作〕
次に、本実施形態に係る対戦パート処理の動作の詳細を説明する。
図３７は、本実施形態に係る対戦パート処理の一例を示すフローチャートである。
ＣＰＵ１６は、チームデータＤ１５６を参照して、対戦に使用するチーム（育成済チーム）の高校（シナリオ）の選択肢を表示部１３に表示させる(ステップＳ２００)。これにより、ＣＰＵ１６は、ユーザに高校を選択させる。高校の選択肢が表示される画面は、図６に示す高校選択画面Ｇ３００と同様の画面であってもよい。

ＣＰＵ１６は、いずれかの高校（シナリオ）の選択肢が選択された場合、ユーザの操作に基づいて選択された高校を対戦に使用する高校として選択する(ステップＳ２１０)。ＣＰＵ１６は、チームデータＤ１５６を参照して、選択された高校に関連付けられているチーム（育成済チーム）の選択肢を表示部１３に表示させる(ステップＳ２２０)。これにより、ＣＰＵ１６は、ユーザに高校のチームを選択させる。ＣＰＵ１６は、いずれかのチームの選択肢が選択された場合、ユーザの操作に基づいて選択されたチームを、複数のチームのうちから対戦で使用する一のチームとして選択する (ステップＳ２３０)。

なお、選択された高校（シナリオ）に対戦に使用可能なチーム（育成済チーム）が一つしかない場合には、ＣＰＵ１６は、ステップＳ２２０の処理を省略して、その一つのチームを対戦で使用するチームとして選択してもよい。また、選択された高校に対戦で使用するチームが利用設定されている場合には、ＣＰＵ１６は、ステップＳ２２０の処理を省略して、利用設定されているチームを対戦で使用するチームとして選択してもよい。

ＣＰＵ１６は、ユーザの操作に基づいて、オーダー変更の要求の有無を判定する(ステップＳ２４０)。ＣＰＵ１６は、オーダー変更の要求があったと判定した場合（ステップＳ２４０：ＹＥＳ）にはステップＳ２５０のオーダー設定処理を実行し、オーダー変更の要求がないと判定した場合（ステップＳ２４０：ＮＯ）にはステップＳ２５０のオーダー設定処理を実行せずにステップＳ２６０の処理に進む。

ステップＳ２５０のオーダー設定処理において、ＣＰＵ１６は、ユーザの操作に基づいて、選択された育成済チームに含まれる複数のキャラクタ（育成対象キャラクタ）のうち対戦パートで使用するキャラクタを設定（オーダーに設定）する処理を実行する (ステップＳ２５０)。例えば、ＣＰＵ１６は、表示部１３の表示画面を図２２に示すオーダー設定画面Ｇ１１００に遷移させる。また、ＣＰＵ１６は、オーダー設定画面Ｇ１１００に対するユーザの操作に基づいてオーダーを設定し、チームメンバデータ記憶部１５７に記憶されているチームメンバデータＤ１５７のオーダーフラグ（図３１参照）を設定する。

なお、ＣＰＵ１６は、高校キャラクタ、任意キャラクタ、及びエキストラキャラクタのいずれをも対戦パートで使用するキャラクタとして設定してもよい。例えば、ＣＰＵ１６は、対戦パートで使用するチームに含まれるオーダーとして設定することができる育成済キャラクタの数を、育成済キャラクタの種類（高校キャラクタ／任意キャラクタ／エキストラキャラクタ）に応じて制限してもよい。例えば、オーダーに設定可能な高校キャラクタとしての育成済キャラクタの数を、予め設定された数（或いは、全所属メンバ数に対して予め設定された割合）を上限としてもよい。オーダー設定処理が終了すると、ステップＳ２６０の処理に進む。

ステップＳ２６０において、ＣＰＵ１６は、ステップＳ２３０において選択されたチーム（育成済チーム）の対戦相手を決定する処理を実行する(ステップＳ２６０)。例えば、ＣＰＵ１６は、高校（シナリオ）ごとに利用設定されたチームに基づいて、複数の他ユーザのうちから対戦相手となるユーザを決定する。具体的には、例えば、ＣＰＵ１６は、チームデータＤ１５６（図３０）を参照して、高校ごとに利用設定されたチームの能力を総合した値（例えば、総合戦力の合計値）に基づいて、複数の他ユーザのうちから当該合計値が相対的に近いユーザを対戦相手となるユーザとして決定する。また、ＣＰＵ１６は、ステップＳ２３０で選択されたチームの対戦相手として、当該チームと同一の高校の他ユーザにより予め利用設定されたチームを選択する。つまり、ＣＰＵ１６は、対戦相手として決定したユーザのチームのうち、ステップＳ２３０で選択されたチームと同一の高校で予め利用設定されたチームを対戦相手のチームとして選択する。なお、他ユーザのデータは、通信部１１を介してサーバ装置３０から取得される。

なお、この対戦相手を決定する処理は、サーバ装置３０で行われてもよい。その場合、ＣＰＵ１６は、対戦相手の決定結果をサーバ装置３０から通信部１１を介して取得する。

対戦相手が決定すると、ＣＰＵ１６は、ステップＳ２３０で選択されたチーム（育成済チーム）と、ステップＳ２６０で決定したチーム（育成済チーム）との対戦処理を実行する(ステップＳ２７０)。例えば、ＣＰＵ１６は、上記チームを使用した対戦処理を、育成パートにおいて更新が完了したデータに基づいて実行する。また、ＣＰＵ１６は、上記チームに含まれる複数のキャラクタ（育成済キャラクタ）のうちの少なくとも一部（例えば、オーダー設定されているキャラクタ）を使用した対戦処理を実行する。

対戦が終了すると、ＣＰＵ１６は、対戦結果（勝敗等）に基づく情報の出力とデータの更新を行う(ステップＳ２８０)。例えば、ＣＰＵ１６は、対戦結果（勝敗等）に基づく情報を表示部１３に表示させる。また、ＣＰＵ１６は、対戦結果（勝敗等）に基づいて、チームデータを更新する。

なお、ステップＳ２４０、Ｓ２５０のオーダー設定（オーダー変更）の処理は、ステップＳ２７０の対戦処理の中で実行されてもよい。

〔６−３．利用設定処理の動作〕
次に、本実施形態に係る利用設定処理の動作を説明する。
図３８は、本実施形態に係る利用設定処理の一例を示すフローチャートである。
ＣＰＵ１６は、表示部１３の表示画面を利用設定画面Ｄ１０００（図２１参照）に遷移させ、利用設定を行う高校（シナリオ）及びチーム（育成済チーム）を提示する(ステップＳ４３０１)。

ＣＰＵ１６は、利用設定画面Ｄ１０００において、高校選択Ｒ１０３０に表示されている各高校（シナリオ）に対応するアイコンのいずれかを選択する操作に基づいて、選択された高校で利用設定可能なチーム（育成済チーム）の選択肢を表示させる(ステップＳ４３０３)。例えば、ＣＰＵ１６は、利用設定画面Ｄ１０００において、選択された高校で利用設定可能なチームの選択肢を、「現在のチーム」の情報Ｒ１０１０、及び「入れ替えるチーム」の情報Ｒ１０２０に表示させる。

ＣＰＵ１６は、上記ユーザの操作に基づいて、他ユーザにより実行される対戦パートで当該他ユーザの対戦相手として使用され得るチームを、複数のチーム（育成済チーム）のうちから予め設定（利用設定）する処理を実行する(ステップＳ４３０５)。例えば、ＣＰＵ１６は、図２１を参照して前述した利用設定画面Ｇ１０００に対するユーザの操作に基づいて、高校ごとにチームの利用設定を行い、チームデータＤ１５６（図３０参照）の利用フラグを設定する。

なお、この利用設定処理においても、オーダー設定処理が可能であってもよい。例えば、ＣＰＵ１６は、利用設定したチーム（育成済チーム）のオーダー設定を、ステップＳ４３０７及びステップＳ４３０９の処理で実行してもよい。このステップＳ４３０７及びステップＳ４３０９の処理は、図３７に示すステップＳ２４０及びステップＳ２５０の処理と同様であり、その説明を省略する。

ＣＰＵ１６は、ユーザの操作に基づいて、利用設定を終了する充足されたか否かを判定する(ステップＳ４３１１)。ＣＰＵ１６は、終了条件が充足されていないと判定された場合(ステップＳ４３１１：ＮＯ)、利用設定処理を継続する。一方、ＣＰＵ１６は、終了条件が充足されたと判定された場合(ステップＳ４３１１：ＹＥＳ)、利用設定を終了する。例えば、ＣＰＵ１６は、利用設定画面Ｄ１０００において、「戻る」が表示されたアイコンＰ１０１３に対する操作がされた場合(ステップＳ４３１１：ＹＥＳ)、利用設定を終了する。

〔６−４．強化アイテム処理の動作〕
次に、対戦パートにおいて、一時的に（その対戦のみに限って）チーム（育成済チーム）に関連付けられたデータを変更する強化アイテム処理の動作を説明する。
図３９は、本実施形態に係る強化アイテム処理の一例を示すフローチャートである。
ＣＰＵ１６は、対戦処理中に、所定のユーザの操作に基づいて、対戦中のキャラクタを選択する (ステップＳ２７１１)。また、ＣＰＵ１６は、ユーザデータＤ１５２を参照して、ユーザに関連付けられているアイテムのリストをユーザに提示(表示)し、所定のユーザの操作に基づいてアイテム（強化アイテム）を選択する(ステップＳ２７１３)。

ＣＰＵ１６は、対戦パートにおいて使用するチーム（育成済チーム）に関連付けられたデータを一時的に変更する処理を実行する(ステップＳ２７１５)。例えば、ＣＰＵ１６は、選択されたアイテム（強化アイテム）に関連付けられた強化条件に基づいて、選択された育成済キャラクタの能力パラメータを一時的に向上させる。このとき、ＣＰＵ１６は、チームメンバデータＤ１５７のデータは変更せずに、対戦処理においてのみ変更したデータを保持する。

ＣＰＵ１６は、対戦が終了したか否かを判定する(ステップＳ２７１７)。ＣＰＵ１６は、対戦が終了していないと判定した場合(ステップＳ２７１７：ＮＯ)、ステップＳ２７１７の判定処理を継続する。一方、ＣＰＵ１６は、対戦が終了したと判定した場合(ステップＳ２７１７：ＹＥＳ)、保持した変更データをクリアして強化アイテム処理を終了する(ステップＳ２７１９)。

なお、強化アイテムを用いて一時的に変更するデータは、キャラクタの能力パラメータに限られるものではなく、キャラクタの特殊能力データであってもよいし、チームの能力パラメータであってもよい。また、１つのアイテムの使用により対戦に使用されるチーム（育成済チーム）に含まれる育成済キャラクタの全てに、同一の効果が付与されるようにしてもよい。

〔７．変形例〕
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成は上述の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。例えば、上述の実施形態において説明した各構成または処理は、任意に組み合わせることができる。

なお、上記実施形態において、本発明を野球ゲームに適用した例について主に説明したが、野球ゲーム以外のゲームにも本発明を適用できる。例えば、サッカーゲーム、バスケットボールゲーム、又はアイスホッケーゲーム等の野球ゲーム以外のスポーツゲームにも本発明を適用できる。また、スポーツゲーム以外のゲームにも本発明を適用できる。スポーツゲームおける集合体は主にチームであるが、チームに限られるもではなく、グループ、団体、班、組、または地域や国であってもよい。また、集合体に含まれる構成要素は、人物（または、動物、物体（例えば、乗り物））等のキャラクタに限られるもではなく、パーツ（部品）や、アイテム等であってもよい。例えば、本発明は、戦車に含まれる構成要素である複数のパーツ（部品）に関連付けられたデータを第１パートで更新（例えば、強化）することにより、当該複数のパーツ（部品）が含まれる集合体である戦車に関連付けられたデータを更新（例えば、強化）し、第２パートでは、第１パートでデータを更新した戦車を使用して対戦相手（例えば、敵の戦車等）と対戦処理を行なうようなゲームに適用することもできる。また、第２パートは、対戦処理を行なうゲームに限られるものではなく、第１パートでデータを更新した集合体を使用する処理であれば、どのような処理であってもよい。例えば、第２パートは、第１パートでデータを更新した集合体（例えば、チーム）を使用して、探検、謎解き、クイズ、または何らかの課題（お題）に挑戦する処理を行なうようなアドベンチャーゲーム、ロールプレイングゲーム、クイズゲーム、チャレンジゲーム、教育（知育）ゲーム等、或いはそれらを複合したゲームであってもよい。

また、上記実施形態では、チームの属性が、高校である例を説明したが、これに限られるものではない。属性は、大学又は企業、又はプロ野球のリーグであってもよい。または、属性は、軍隊、地域、国等であてもよい。

上記実施形態では、例えば上述の制御部１６０の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより制御部１６０としての処理を行う。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であってもよい。また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部または外部に設けられた記録媒体も含まれる。配信サーバの記録媒体に記憶されるプログラムのコードは、端末装置１０で実行可能な形式のプログラムのコードと異なるものでもよい。すなわち、配信サーバからダウンロードされて端末装置１０で実行可能な形でインストールができるものであれば、配信サーバで記憶される形式は問わない。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に端末装置１０で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

また、上述の制御部１６０の一部または全部の機能を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

また、上述の制御部１６０の一部の機能を、サーバ装置３０が備えてもよい。例えば、育成パート処理部１６３、利用チーム設定部１６４、オーダー設定部１６５、対戦パート処理部１６６の一部または全部をサーバ装置３０が備え、端末装置１０は、育成パート処理部１６３、利用チーム設定部１６４、オーダー設定部１６５、対戦パート処理部１６６の一部または全部の処理結果をサーバ装置３０から取得してもよい。例えば、サーバ装置３０が処理を行なうゲーム処理の表示画像の取得と、当該ゲーム処理における操作を受け付けてサーバ装置３０へ送信する処理を端末装置１０が行うような所謂ブラウザゲームであってもよい。

〔８．付記〕
以上の記載から本発明は例えば以下のように把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。

（付記Ａ１）本発明の一態様に係るゲームプログラムは、コンピュータに、集合体（例えば、チーム（育成対象チーム））に含まれる複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））に関連付けられるデータの更新を指示するステップ（Ｓ１１０、Ｓ１３３９）と、前記指示するステップによる１回（例えば、１ターン）の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新するステップ（Ｓ１１０、Ｓ１３４１）と、前記指示するステップによる１回の指示機会を、ユーザに所定回数（例えば、１２０ターン）を上限とした複数回提供するステップ（Ｓ１１０、Ｓ１４０、Ｓ１４３）と、を実行させる。

付記Ａ１の構成によれば、集合体の単位で構成要素のデータを更新（例えば、強化、育成）するため、効率的に集合体を強化（育成）することができる。

（付記Ａ２）また、本発明の一態様は、付記Ａ１に記載のゲームプログラムであって、前記指示するステップ（Ｓ１１０、Ｓ１３３９）において、前記集合体（例えば、チーム（育成対象チーム））に含まれる複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））のいずれかが関連付けられた選択肢（例えば、練習項目のアイコンＰ６３１、Ｐ６３２、Ｐ６３３、Ｐ６３４）を含む複数の選択肢のうち、ユーザにより選択された選択肢に関連付けられた構成要素に対して前記更新を指示する。

付記Ａ２の構成によれば、ユーザが複数の選択肢の中から練習項目を選択することができるため、集合体の強化したいデータや強化したい構成要素を効率的に強化（育成）することができる。

（付記Ａ３）また、本発明の一態様は、付記Ａ２に記載のゲームプログラムであって、前記指示するステップ（Ｓ１１０、Ｓ１３３９）において、前記複数の選択肢のそれぞれに対して設定された更新条件（例えば、「経験値」及び「練習値」の増加量）に基づいて、ユーザにより選択された選択肢に関連付けられた構成要素（例えば、キャラクタ（育成対象キャラクタ））のそれぞれに対して、当該選択肢に設定された更新条件に基づく前記更新を指示する。

付記Ａ３の構成によれば、ユーザにより選択された選択肢の更新条件で当該選択肢に関連付けられた構成要素のデータを更新するため、集合体単位でデータを更新する際にも、更新条件及び更新する構成要素についてバリエーションを持たすことができる。

（付記Ａ４）また、本発明の一態様は、付記Ａ３に記載のゲームプログラムであって、前記更新条件は、対応する選択肢に関連付けられた構成要素に基づいて設定される。

付記Ａ４の構成によれば、構成要素の種類（例えば、投手、野手等）や特性（例えば、コントロール重視の投手等）に応じて効率的に集合体を強化（育成）することができる。

（付記Ａ５）また、本発明の一態様は、付記Ａ３または付記Ａ４に記載のゲームプログラムであって、前記コンピュータに、前記複数の選択肢のそれぞれに対して設定された更新条件を、ユーザに認識可能に提示するステップ（Ｓ１３３１）、を実行させる。

付記Ａ５の構成によれば、ユーザが更新条件を考慮して複数の選択肢の中から練習項目を選択することができるため、効率的に集合体を強化（育成）することができる。

（付記Ａ６）また、本発明の一態様は、付記Ａ３から付記Ａ５のいずれか一に記載のゲームプログラムであって、前記指示するステップ（Ｓ１１０、Ｓ１３３９）において、ユーザにより選択された選択肢に設定された更新条件とユーザにより選択されなかった選択肢に設定された更新条件とのうちの少なくとも一方を変更した更新条件のそれぞれに基づいて、ユーザにより選択された選択肢に関連付けられた構成要素（例えば、キャラクタ（育成対象キャラクタ））のそれぞれに対して前記更新を指示するとともに、ユーザにより選択されなかった選択肢に関連付けられた構成要素のそれぞれに対して前記更新を指示し、前記少なくとも一方の更新条件の変更は、ユーザにより選択された選択肢の方がユーザにより選択されなかった選択肢より有利な変更である。

付記Ａ６の構成によれば、選択の有無に関わらず複数の選択肢に関連付けられた構成要素を強化（育成）できるとともに、選択された選択肢に関連付けられた構成要素をより強化（育成）できるため、ユーザの意思を尊重しつつ効率的に集合体を強化（育成）することができる。

（付記Ａ７）また、本発明の一態様は、付記Ａ６に記載のゲームプログラムであって、前記コンピュータに、ユーザの操作に基づいて、前記複数の選択肢のいずれかを仮選択する操作と仮選択された選択肢を選択決定する操作とを受け付けるステップ（Ｓ１３３３、Ｓ１３３７）と、前記複数の選択肢のそれぞれに設定された更新条件をユーザに認識可能に提示するとともに、いずれかの選択肢がユーザの操作に基づいて仮選択された場合、前記少なくとも一方の選択肢に設定された更新条件が変更されたそれぞれの更新条件をユーザに認識可能に提示するステップ（Ｓ１３３５）と、を実行させる。

付記Ａ７の構成によれば、ユーザが、選択することにより変更される更新条件を確認した上でどの選択肢（練習項目）を選択するかを決定できる。

（付記Ａ８）また、本発明の一態様は、付記Ａ１から付記Ａ７のいずれか一に記載のゲームプログラムであって、前記コンピュータに、ユーザに前記集合体（例えば、チーム（育成対象チーム））の属性（例えば、高校（シナリオ））を選択させるステップ（Ｓ１０１、Ｓ１０３）と、ユーザにより選択された前記集合体の属性に応じて定まる構成要素（例えば、高校キャラクタ）と、ユーザに関連付けられているデータのうちからユーザにより選択されたデータに応じて定まる構成要素（例えば、任意キャラクタ）とを、前記集合体に含まれる複数の構成要素として設定するステップ（Ｓ１０５）と、を実行させる。

付記Ａ８の構成によれば、第１パート（例えば、育成パート）でデータを更新する集合体に、ユーザが選択した属性に特有の構成要素とユーザに関連付けられているデータから選択した構成要素とを含めることができるため、属性の特徴を持たせつつユーザの意思も入れた集合体作りを行うことができる。また、ユーザに関連付けられている構成要素から集合体に含まれる構成要素の一部を選択するため、構成要素を取得するための抽選を行う動機付けをユーザに持たせることもできる。

（付記Ａ９）また、本発明の一態様は、付記Ａ１から付記Ａ８のいずれか一に記載のゲームプログラムであって、前記コンピュータに、前記更新するステップ（Ｓ１１０、Ｓ１３４１）により構成要素に関連付けられるデータが更新された前記集合体（例えば、チーム（育成済チーム））を、複数管理するステップ（Ｓ１５０）と、ユーザの操作に基づいて、前記管理された複数の前記集合体のうちから対戦で使用する一の集合体を選択するステップ（Ｓ２１０、Ｓ２３０）と、前記選択された前記集合体に含まれる複数の構成要素（例えば、キャラクタ（育成済キャラクタ））のうちの少なくとも一部を使用して対戦処理を行なうステップ（Ｓ２７０）と、を実行させる。

付記Ａ９の構成によれば、集合体単位で構成要素のデータを更新（例えば、強化、育成）した複数の集合体を保持し、その中から対戦に使用する構成要素を選択できるため、データを更新した構成要素を用いて編成された集合体を使用したプレイを多様化することができる。また、集合体単位で複数の集合体を効率的に強化（育成）することができる。

（付記Ａ１０）また、本発明の一態様は、付記Ａ９に記載のゲームプログラムであって、前記管理するステップ（Ｓ１５０）において、前記更新が完了した前記集合体（例えば、チーム（育成済チーム））のデータを管理し、前記対戦処理を行なうステップ（Ｓ２７０）において、前記管理されている前記集合体を使用した対戦処理を前記更新が完了したデータに基づいて行ない、前記管理するステップにより管理されている前記更新が完了した前記集合体のデータについては、再び更新されない。

付記Ａ１０の構成によれば、第１パートにおいて、集合体に含まれる構成要素をまとめてデータの更新（例えば、強化、育成）ができる反面、個々の構成要素をそれぞれ更新できないため、集合体に含まれるすべての構成要素を高いレベルにして強力な集合体を作り上げることの困難性が上がり、第１パートをプレイする動機付けを高めることができる。また、第１パートで一旦データの更新が完了した集合体は、それ以降はデータの更新ができないため、より強力な集合体を作るためには、繰り返し第１パートをプレイする必要があるため、第１パートをプレイする動機付けを高めることができる。また、第１パートにおいて、集合体単位で複数の集合体を効率的に強化（育成）することができる。

（付記Ａ１１）本発明の一態様に係るゲーム処理方法は、コンピュータにより実行されるゲーム処理方法であって、集合体（例えば、チーム（育成対象チーム））に含まれる複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））に関連付けられるデータの更新を指示するステップ（Ｓ１１０、Ｓ１３３９）と、前記指示するステップによる１回（例えば、１ターン）の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新するステップ（Ｓ１１０、Ｓ１３４１）と、前記指示するステップによる１回の指示機会を、ユーザに所定回数（例えば、１２０ターン）を上限とした複数回提供するステップ（Ｓ１１０、Ｓ１４０、Ｓ１４３）と、を含む。

付記Ａ１１の構成によれば、集合体の単位で構成要素のデータを更新（例えば、強化、育成）するため、効率的に集合体を強化（育成）することができる。

（付記Ａ１２）本発明の一態様に係るゲーム装置（１０）は、ゲームプログラムを実行するゲーム装置であって、集合体（例えば、チーム（育成対象チーム））に含まれる複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））に関連付けられるデータの更新を指示する指示部（１６３２）と、前記指示部による１回（例えば、１ターン）の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新する更新部（１６３３）と、前記指示部による１回の指示機会を、ユーザに所定回数（例えば、１２０ターン）を上限とした複数回提供する提供部（１６３４）と、を備える。

付記Ａ１２の構成によれば、集合体の単位で構成要素のデータを更新（例えば、強化、育成）するため、効率的に集合体を強化（育成）することができる。

（付記Ｂ１）本発明の一態様に係るゲームプログラムは、複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））を含んで構成される一の集合体（例えば、チーム（育成対象チーム））に関連付けられるデータを更新する第１パート（例えば、育成パート）と、前記第１パートにより更新された前記集合体（例えば、チーム（育成済チーム））同士で対戦する第２パート（例えば、対戦パート）を含むゲームのゲームプログラムであって、コンピュータに、前記第１パートにおいて、前記集合体に関連付けられるデータを更新するステップ（Ｓ１１０、Ｓ１３４１）と、前記第１パートにおいて更新した前記集合体を複数管理するステップ（Ｓ１５０）と、ユーザの操作に基づいて、前記管理された複数の前記集合体のうちから前記第２パートで対戦に使用する一の集合体を選択するステップ（Ｓ２１０、Ｓ２１３）と、を実行させる。

付記Ｂ１の構成によれば、集合体単位で構成要素のデータを更新（例えば、強化、育成）した複数の集合体を保持し、その中から対戦に使用する集合体を選択できるため、育成した構成要素を用いて編成された集合体を使用したプレイを多様化することができる。

（付記Ｂ２）また、本発明の一態様は、付記Ｂ１に記載のゲームプログラムであって、前記コンピュータに、ユーザの操作に基づいて、他ユーザにより実行される前記第２パートで当該他ユーザの対戦相手として使用され得る集合体（例えば、チーム（育成済チーム））を、複数の前記集合体のうちから予め設定するステップ（Ｓ４３０５）、を実行させる。

付記Ｂ２の構成によれば、非同期で行われる他ユーザにより実行される対戦処理において、対戦に使用される集合体をユーザが予め決めておくことができる。

（付記Ｂ３）また、本発明の一態様は、付記Ｂ２に記載のゲームプログラムであって、前記コンピュータに、ユーザに前記集合体（例えば、チーム（育成対象チーム））の属性（例えば、高校（シナリオ））を選択させるステップ（Ｓ１０１、Ｓ１０３）を実行させ、更新するステップ（Ｓ１１０、Ｓ１３４１）において、前記選択された属性に応じた集合体に関連付けられるデータを更新し、前記管理するステップ（Ｓ１５０）において、複数の前記集合体（例えば、チーム（育成済チーム））のそれぞれを前記属性ごとに管理し、前記設定するステップ（Ｓ４３０５）において、ユーザの操作に基づいて、他ユーザにより実行される前記第２パートで他ユーザの対戦相手として使用され得る集合体を、異なる前記属性のそれぞれにおいて、複数の前記集合体（例えば、チーム（育成済チーム））のうちから予め設定する。

付記Ｂ３の構成によれば、属性ごとに集合体に関連付けられるデータを更新（例えば、強化、育成）した複数の集合体を保持し、その中から他ユーザにより実行される対戦処理において対戦に使用される集合体を属性ごとにユーザが予め決めておくことができる。

（付記Ｂ４）また、本発明の一態様は、付記Ｂ３に記載のゲームプログラムであって、前記選択するステップ（Ｓ１０１、Ｓ１０３）において選択された集合体（例えば、チーム（育成済チーム））の対戦相手として、当該選択された集合体と同一の属性を有する他ユーザにより予め設定された集合体を決定するステップ（Ｓ２６０）、を実行させる。

付記Ｂ４の構成によれば、同一属性の他ユーザの集合体と対戦が行われることにより、ユーザが強化（育成）した集合体の能力が対戦結果に影響することとなるため、第１パートをプレイする動機付けを高めることができる。

（付記Ｂ５）また、本発明の一態様は、付記Ｂ４に記載のゲームプログラムであって、 前記決定するステップ（Ｓ２６０）において、前記設定するステップにより前記属性ごとに設定された集合体（例えば、チーム（育成済チーム））に基づいて、複数の他ユーザのうちから対戦相手となるユーザを決定する。

付記Ｂ５の構成によれば、対戦相手との能力差が大きくなりすぎないように対戦相手を決定することができる。

（付記Ｂ６）また、本発明の一態様は、付記Ｂ３から付記Ｂ５のいずれか一に記載のゲームプログラムであって、前記管理するステップ（Ｓ１５０）において、前記第１パートによる前記集合体（例えば、チーム（育成対象チーム））の更新が行われる前から、前記属性ごとに所定の集合体（例えば、デフォルトチーム）を前記第２パートで対戦に使用される集合体として予め関連付けて管理している。

付記Ｂ６の構成によれば、第１パートにおいて集合体の更新実績がない高校（シナリオ）についても、他ユーザと対戦することができる。

（付記Ｂ７）また、本発明の一態様は、付記Ｂ１から付記Ｂ６のいずれか一に記載のゲームプログラムであって、前記集合体（例えば、チーム（育成対象チーム））に含まれる構成要素（例えば、キャラクタ（育成対象キャラクタ））には、前記第１パートの開始時点で、前記第１パートにより更新される期間（例えば、育成期間）が異なることにより初期状態のデータが異なる複数の構成要素が含まれる。

付記Ｂ７の構成によれば、第１パートの開始時点で、第１パートにより更新される期間及びデータが異なる構成要素が含まれるため、集合体に含まれる構成要素を多様化することができる。

（付記Ｂ８）本発明の一態様に係るゲーム処理方法は、複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））を含んで構成される一の集合体（例えば、チーム（育成対象チーム））に関連付けられるデータを更新する第１パート（例えば、育成パート）と、前記第１パートにより更新された前記集合体（例えば、チーム（育成済チーム））同士で対戦する第２パート（例えば、対戦パート）を含むゲームのゲームプログラムに基づいてコンピュータにより実行されるゲーム処理方法であって、前記第１パートにおいて、前記集合体に関連付けられるデータを更新するステップ（Ｓ１１０、Ｓ１３４１）と、前記第１パートにおいて更新した前記集合体を、複数管理するステップ（Ｓ１５０）と、ユーザの操作に基づいて、前記管理された複数の前記集合体のうちから前記第２パートで対戦に使用する一の集合体を選択するステップ（Ｓ２１０、Ｓ２１３）と、を含む。

付記Ｂ８の構成によれば、集合体単位で構成要素のデータを更新（例えば、強化、育成）した複数の集合体を保持し、その中から対戦に使用する集合体を選択できるため、育成した構成要素を用いて編成された集合体を使用したプレイを多様化することができる。

（付記Ｂ９）本発明の一態様に係るゲーム装置（１０）は、複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））を含んで構成される一の集合体（例えば、チーム（育成対象チーム））に関連付けられるデータを更新する第１パート（例えば、育成パート）と、前記第１パートにより更新された前記集合体（例えば、チーム（育成済チーム））同士で対戦する第２パート（例えば、対戦パート）を含むゲームのゲームプログラムを実行するゲーム装置であって、前記第１パートにおいて、前記集合体に関連付けられるデータを更新する更新部（１６３３）と、前記第１パートにおいて更新した前記集合体を、複数管理する管理部（１６３５）と、ユーザの操作に基づいて、前記管理された複数の前記集合体のうちから前記第２パートで対戦に使用する一の集合体を選択する選択部（１６６１）と、を備える。

付記Ｂ９の構成によれば、集合体単位で構成要素のデータを更新（例えば、強化、育成）した複数の集合体を保持し、その中から対戦に使用する集合体を選択できるため、育成した構成要素を用いて編成された集合体を使用したプレイを多様化することができる。

（付記Ｃ１）本発明の一態様に係るゲームプログラムは、複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））を含んで構成される一の集合体（例えば、チーム（育成対象チーム））に関連付けられるデータを更新する第１パート（例えば、育成パート）と、前記第１パートにより更新された前記集合体（例えば、チーム（育成済チーム））を使用する第２パート（例えば、対戦パート）を含むゲームのゲームプログラムであって、コンピュータに、前記第１パートにおいて、前記集合体に関連付けられるデータを更新するステップ（Ｓ１１０、Ｓ１３４１）と、前記第１パートの終了に応じて更新が完了した前記集合体（例えば、チーム（育成済チーム））のデータを管理するステップ（Ｓ１５０）と、前記第２パートにおいて、前記管理されている前記集合体を使用した処理を前記更新が完了したデータに基づいて行なうステップ（Ｓ２７０）と、を実行させ、前記管理するステップにより管理されている前記更新が完了した前記集合体のデータについては、再び更新されない。

付記Ｃ１の構成によれば、第１パートにおいて、集合体に含まれる構成要素をまとめてデータの更新（例えば、強化、育成）ができる反面、個々の構成要素をそれぞれ更新できないため、集合体に含まれるすべての構成要素を高いレベルにして強力な集合体を作り上げることの困難性が上がり、第１パートをプレイする動機付けを高めることができる。また、第１パートで一旦データの更新が完了した集合体は、それ以降はデータの更新ができないため、より強力な集合体を作るためには、繰り返し第１パートをプレイする必要があるため、第１パートをプレイする動機付けを高めることができる。

（付記Ｃ２）また、本発明の一態様は、付記Ｃ１に記載のゲームプログラムであって、前記管理するステップ（Ｓ１５０）において、前記集合体（例えば、チーム（育成済チーム））を複数管理し、前記コンピュータに、ユーザの操作に基づいて、前記管理されている複数の集合体のうちから、前記第２パートで使用する一の集合体を選択するステップ（Ｓ２１０、Ｓ２１３）を実行させる。

付記Ｃ２の構成によれば、第１パートでデータを更新（例えば、強化、育成）した複数の集合体を管理し、その中から対戦に使用する集合体を選択できるため、育成した集合体を使用したプレイを多様化することができる。

（付記Ｃ３）また、本発明の一態様は、付記Ｃ１または付記Ｃ２に記載のゲームプログラムであって、前記更新するステップ（Ｓ１１０、Ｓ１３４１）において、所定の期間（例えば、育成期間）、前記集合体（例えば、チーム（育成対象チーム））に関連付けられるデータを更新する。

付記Ｃ３の構成によれば、集合体に関連付けられるデータを更新する期間（例えば、育成期間）が限られているため、他ユーザに対して勝利するために、限られた期間内で最大限集合体を強化しようとする意欲をユーザに持たせることができる。よって、第１パートをプレイする動機付けを高めることができる。

（付記Ｃ４）また、本発明の一態様は、付記Ｃ３に記載のゲームプログラムであって、前記コンピュータに、前記第１パートにおいて、前記所定の期間の途中に、前記更新の対象として前記集合体（例えば、チーム（育成対象チーム））に含まれる構成要素（例えば、キャラクタ（育成対象キャラクタ））を追加するステップ（Ｓ１４８１）と、前記第１パートにおいて、前記所定の期間の途中に、前記更新の対象として前記集合体に含まれる構成要素を前記更新の対象から除外するステップ（Ｓ１４７３）とを実行させる。

付記Ｃ４の構成によれば、集合体に関連付けられるデータを更新する期間（例えば、育成期間）の途中でも、上記更新対象の構成要素に変化があるため、育成パートにおけるプレイを多様化することができる。

（付記Ｃ５）また、本発明の一態様は、付記Ｃ３から付記Ｃ４のいずれか一に記載のゲームプログラムであって、前記更新するステップ（Ｓ１１０、Ｓ１３４１）において、前記所定の期間内の前記第１パートの進行に従って、前記集合体（例えば、チーム（育成対象チーム））に含まれる構成要素（例えば、キャラクタ（育成対象キャラクタ））に関連付けられるデータを更新する。

付記Ｃ５の構成によれば、第１パートの進行に従って、集合体に含まれる構成要素を強化（育成）することができる。

（付記Ｃ６）また、本発明の一態様は、付記Ｃ１から付記Ｃ５のいずれか一に記載のゲームプログラムであって、前記集合体（例えば、チーム（育成対象チーム））に含まれる構成要素（例えば、キャラクタ（育成対象キャラクタ））には、前記第１パートの開始時点で、前記第１パートにより更新される期間（例えば、育成期間）が異なることにより初期状態のデータが異なる複数の構成要素が含まれる。

付記Ｃ６の構成によれば、第１パートの開始時点で、第１パートにより更新される期間及びデータが異なる構成要素が含まれるため、集合体に含まれる構成要素を多様化することができる。

（付記Ｃ７）また、本発明の一態様は、付記Ｃ１から付記Ｃ６のいずれか一に記載のゲームプログラムであって、前記処理を行なうステップ（Ｓ２７０）において、前記第２パートでは、前記集合体（例えば、チーム（育成済チーム））に含まれる複数の構成要素（例えば、キャラクタ（育成済キャラクタ））のうちの少なくとも一部を使用した処理を行ない、前記コンピュータに、ユーザの操作に基づいて、前記集合体に含まれる複数の構成要素のうち前記第２パートで使用する構成要素を設定するステップ（Ｓ４３０５）を実行させる。

付記Ｃ７の構成によれば、集合体に含まれる構成要素の中から試合に出場する構成要素のオーダーをユーザが設定することができる。よって、第２パートにおいて、ユーザが集合体の編成を考えてプレイすることができる。

（付記Ｃ８）また、本発明の一態様は、付記Ｃ７に記載のゲームプログラムであって、前記コンピュータに、遊技価値（例えば、課金、またはゲームの進行に応じて入手されるゲーム内のコインやメダル、ポイント、チケット、またはアイテム等）の消費と引換えに特定の構成要素（例えば、イベキャラ）を示すデータをユーザに関連付けるステップ、を実行させ、前記更新するステップ（Ｓ１１０、Ｓ１３４１）において、前記ユーザに関連付けられたデータに基づいて前記集合体（例えば、チーム（育成対象チーム））に含まれる構成要素（例えば、キャラクタ（育成対象キャラクタ））として選択された前記特定の構成要素に関連付けられるデータを更新し、前記設定するステップ（Ｓ４３０５）において、前記更新するステップでデータが更新された前記特定の構成要素を、ユーザの操作に基づいて前記第２パートで使用する構成要素（例えば、キャラクタ（育成済キャラクタ））として設定する。

付記Ｃ８の構成によれば、遊技価値の消費と引換えに取得するイベキャラを育成パートで強化（育成）し対戦パートで使用できるため、イベキャラを取得することへの動機付けをユーザに持たせることもできる。

（付記Ｃ９）また、本発明の一態様は、付記Ｃ８に記載のゲームプログラムであって、前記設定するステップ（Ｓ４３０５）において、前記第２パートで使用する構成要素（例えば、キャラクタ（育成済キャラクタ））として設定する前記特定の構成要素（例えば、イベキャラ）を、前記集合体（例えば、チーム（育成済チーム））に含まれる構成要素の一部に制限する。

付記Ｃ９の構成によれば、第２パートで使用する特定の構成要素の数に制限を設けるため、遊技価値の消費による集合体の能力に与える影響が大きくなりすぎないようにすることができる。

（付記Ｃ１０）また、本発明の一態様は、付記Ｃ１から付記Ｃ９のいずれか一に記載のゲームプログラムであって、前記コンピュータに、前記第２パートにおいて使用する前記集合体（例えば、チーム（育成済チーム））に関連付けられたデータを、一時的に変更するステップ（Ｓ２７１５）を実行させる。

付記Ｃ１０の構成によれば、第２パートにおけるプレイを多様化することができる。また、強化アイテムの取得の動機付けを与えることができる。

（付記Ｃ１１）本発明の一態様に係るゲーム処理方法は、複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））を含んで構成される一の集合体（例えば、チーム（育成対象チーム））に関連付けられるデータを更新する第１パート（例えば、育成パート）と、前記第１パートにより更新された前記集合体（例えば、チーム（育成済チーム））を使用する第２パート（例えば、対戦パート）を含むゲームのゲームプログラムに基づいてコンピュータにより実行されるゲーム処理方法であって、前記第１パートにおいて、前記集合体に関連付けられるデータを更新するステップ（Ｓ１１０、Ｓ１３４１）と、前記第１パートの終了に応じて更新が完了した前記集合体のデータを管理するステップ（Ｓ１５０）と、前記第２パートにおいて、前記管理されている前記集合体を使用した処理を前記更新が完了したデータに基づいて行なうステップ（Ｓ２７０）と、を含み、前記管理するステップにより管理されている前記更新が完了した前記集合体のデータについては、再び更新されない。

付記Ｃ１１の構成によれば、第１パートにおいて、集合体に含まれる構成要素をまとめてデータの更新（例えば、強化、育成）ができる反面、個々の構成要素をそれぞれ更新できないため、集合体に含まれるすべての構成要素を高いレベルにして強力な集合体を作り上げることの困難性が上がり、第１パートをプレイする動機付けを高めることができる。また、第１パートで一旦データの更新が完了した集合体は、それ以降はデータの更新ができないため、より強力な集合体を作るためには、繰り返し第１パートをプレイする必要があるため、第１パートをプレイする動機付けを高めることができる。

（付記Ｃ１２）本発明の一態様に係るゲーム装置（１０）は、複数の構成要素（例えば、キャラクタ（育成対象キャラクタ））を含んで構成される一の集合体（例えば、チーム（育成対象チーム））に関連付けられるデータを更新する第１パート（例えば、育成パート）と、前記第１パートにより更新された前記集合体（例えば、チーム（育成済チーム））を使用する第２パート（例えば、対戦パート）を含むゲームのゲームプログラムを実行するゲーム装置であって、前記第１パートにおいて、前記集合体（例えば、チーム（育成済チーム））に関連付けられるデータを更新する更新部（１６３３）と、前記第１パートの終了に応じて更新が完了した前記集合体のデータを管理する管理部（１６３５）と、前記第２パートにおいて、前記管理されている前記集合体を使用した処理を前記更新が完了したデータに基づいて行なう処理部（１６６３）と、を備え、前記管理するステップにより管理されている前記更新が完了した前記集合体のデータについては、再び更新されない。

付記Ｃ１２の構成によれば、第１パートにおいて、集合体に含まれる構成要素をまとめてデータの更新（例えば、強化、育成）ができる反面、個々の構成要素をそれぞれ更新できないため、集合体に含まれるすべての構成要素を高いレベルにして強力な集合体を作り上げることの困難性が上がり、第１パートをプレイする動機付けを高めることができる。また、第１パートで一旦データの更新が完了した集合体は、それ以降はデータの更新ができないため、より強力な集合体を作るためには、繰り返し第１パートをプレイする必要があるため、第１パートをプレイする動機付けを高めることができる。

１ ゲームシステム、１０ 端末装置、３０ サーバ装置、１１ 通信部、１２ 入力部、１３ 表示部、１４ 音声出力部、１５ 記憶部、１６ ＣＰＵ、１５０ データ記憶部、１５１ キャラクタデータ記憶部、１５２ ユーザデータ記憶部、１５３ 所有キャラクタデータ記憶部、１５４ 高校データ記憶部、１５５ 育成データ記憶部、１５６ チームデータ記憶部、１５７ チームメンバデータ記憶部、１６０ 制御部、１６１ 操作受付部、１６２ 表示制御部、１６３ 育成パート処理部、１６３１ 選択部、１６３２ 更新指示部、１６３３ 更新部、１６３４ 育成提供部、１６３５ データ管理部、１６３６ 育成キャラクタ設定部、１６３７ 追加部、１６３８ 解除部、１６４ 利用チーム設定部、１６５ オーダー設定部、１６６ 対戦パート処理部、１６６１ チーム選択部、１６６２ 対戦相手決定部、１６６３ 対戦処理部、１６６４ アイテム処理部

Claims (12)

1. コンピュータに、
   集合体に含まれる複数の構成要素に関連付けられるデータの更新を指示するステップと、
   前記指示するステップによる１回の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新するステップと、
   前記指示するステップによる１回の指示機会を、ユーザに所定回数を上限とした複数回提供するステップと、
   を実行させるためのゲームプログラム。
2. 前記指示するステップにおいて、前記集合体に含まれる複数の構成要素のいずれかが関連付けられた選択肢を含む複数の選択肢のうち、ユーザにより選択された選択肢に関連付けられた構成要素に対して前記更新を指示する、
   請求項１に記載のゲームプログラム。
3. 前記指示するステップにおいて、前記複数の選択肢のそれぞれに対して設定された更新条件に基づいて、ユーザにより選択された選択肢に関連付けられた構成要素のそれぞれに対して、当該選択肢に設定された更新条件に基づく前記更新を指示する、
   請求項２に記載のゲームプログラム。
4. 前記更新条件は、対応する選択肢に関連付けられた構成要素に基づいて設定される、
   請求項３に記載のゲームプログラム。
5. 前記コンピュータに、
   前記複数の選択肢のそれぞれに対して設定された更新条件を、ユーザに認識可能に提示するステップ、
   を実行させる請求項３または請求項４に記載のゲームプログラム。
6. 前記指示するステップにおいて、
   ユーザにより選択された選択肢に設定された更新条件とユーザにより選択されなかった選択肢に設定された更新条件とのうちの少なくとも一方を変更した更新条件のそれぞれに基づいて、ユーザにより選択された選択肢に関連付けられた構成要素のそれぞれに対して前記更新を指示するとともに、ユーザにより選択されなかった選択肢に関連付けられた構成要素のそれぞれに対して前記更新を指示し、
   前記少なくとも一方の更新条件の変更は、ユーザにより選択された選択肢の方がユーザにより選択されなかった選択肢より有利な変更である、
   請求項３から請求項５のいずれか一項に記載のゲームプログラム。
7. 前記コンピュータに、
   ユーザの操作に基づいて、前記複数の選択肢のいずれかを仮選択する操作と仮選択された選択肢を選択決定する操作とを受け付けるステップと、
   前記複数の選択肢のそれぞれに設定された更新条件をユーザに認識可能に提示するとともに、いずれかの選択肢がユーザの操作に基づいて仮選択された場合、前記少なくとも一方の選択肢に設定された更新条件が変更されたそれぞれの更新条件をユーザに認識可能に提示するステップと、
   を実行させる請求項６に記載のゲームプログラム。
8. 前記コンピュータに、
   ユーザに前記集合体の属性を選択させるステップと、
   ユーザにより選択された前記集合体の属性に応じて定まる構成要素と、ユーザに関連付けられているデータのうちからユーザにより選択されたデータに応じて定まる構成要素とを、前記集合体に含まれる複数の構成要素として設定するステップと、
   を実行させる請求項１から請求項７のいずれか一項に記載のゲームプログラム。
9. 前記コンピュータに、
   前記更新するステップにより構成要素に関連付けられるデータが更新された前記集合体を、複数管理するステップと、
   ユーザの操作に基づいて、前記管理された複数の前記集合体のうちから対戦で使用する一の集合体を選択するステップと、
   前記選択された前記集合体に含まれる複数の構成要素のうちの少なくとも一部を使用して対戦処理を行なうステップと、
   を実行させる請求項１から請求項８のいずれか一項に記載のゲームプログラム。
10. 前記管理するステップにおいて、前記更新が完了した前記集合体のデータを管理し、
    前記対戦処理を行なうステップにおいて、前記管理されている前記集合体を使用した対戦処理を前記更新が完了したデータに基づいて行ない、
    前記管理するステップにより管理されている前記更新が完了した前記集合体のデータについては、再び更新されない、
    請求項９に記載のゲームプログラム。
11. コンピュータにより実行されるゲーム処理方法であって、
    集合体に含まれる複数の構成要素に関連付けられるデータの更新を指示するステップと、
    前記指示するステップによる１回の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新するステップと、
    前記指示するステップによる１回の指示機会を、ユーザに所定回数を上限とした複数回提供するステップと、
    を含むゲーム処理方法。
12. ゲームプログラムを実行するゲーム装置であって、
    集合体に含まれる複数の構成要素に関連付けられるデータの更新を指示する指示部と、
    前記指示部による１回の指示に応じて、前記集合体に含まれる２以上の構成要素のそれぞれに関連付けられるデータを更新する更新部と、
    前記指示部による１回の指示機会を、ユーザに所定回数を上限とした複数回提供する提供部と、
    を備えるゲーム装置。

Images