JP6480055B1 - ゲームプログラム、方法、および情報処理装置 - Google Patents

Abstract

【課題】興趣性を向上させるゲームプログラム、ゲームプログラムを実行する方法および情報処理装置を提供する。
【解決手段】ゲームプログラムは、プロセッサに、ユーザが所有するキャラクタで構成された自チームを編成するステップＳ１と、自チームをマッチングされた相手チームと対戦させる第１対戦ゲームを進行させるステップＳ２と、第１対戦ゲームがプレイされた場合に、キャラクタを獲得できる権利データを、第１報酬としてユーザに付与するステップＳ３と、第１条件が満たされた場合、権利データに基づいて特定されたキャラクタをユーザに獲得させるステップＳ３と、第２条件が満たされた場合、自チームを相手チームと対戦させる第２対戦ゲームを進行させるステップＳ６と、ユーザにより第２対戦ゲームがプレイされた場合、キャラクタまたはキャラクタと交換可能な価値を、第２報酬としてユーザに付与するステップＳ７とを実行させる。
【選択図】図３

Description

本開示はゲームプログラム、ゲームプログラムを実行する方法および情報処理装置に関する。

ゲーム上の仮想空間内に選手などのキャラクタを表示させて、ユーザに該選手を操作させることによりゲームを進行させるゲームプログラムが、様々な事業者により提供されている。例えば、テニス、卓球、ドッジボール、野球、サッカー、ホッケー等の競技を題材としたゲームが提供されている。

とりわけ、野球またはサッカー等、複数の選手からなるチーム同士が対戦するチーム競技は、対戦ゲームの題材として多く取り上げられている。対戦ゲームでは、ユーザがチーム内の各選手を操作して対戦が進行する。なかでも、複数のユーザのそれぞれが、端末を用いて情報をやりとりし、これにより対戦を進行させる通信対戦ゲームが提供されている（例えば、特許文献１）。このようなゲームでは、上述のキャラクタとしてのデジタルコンテンツが、例えば、ゲームをプレイしたことの報酬としてユーザに提供されたりする。そして、ユーザは、獲得した複数のキャラクタをデッキに編成し、対戦をプレイすることができる。ここで、キャラクタに設定されている様々なパラメータが対戦の進行に影響を与える。

特許第６０５０８８４号公報（２０１６年１２月２１日発行）

一般に、ユーザがゲームに飽きるという問題に如何に対処するかは重要である。特に、上述のように、キャラクタをデッキに編成して楽しむゲームでは、様々な種類のキャラクタを用意して、キャラクタを獲得する喜び、および、獲得したキャラクタでチームを編成する楽しみを、ユーザに与えることが求められる。あるいは、特に、上述のような対人対戦をメインとするゲームでは、緊張および興奮が高まる対人対戦とは別に、ユーザが、息抜きまたは気分転換などを図ることを目的に、気軽に取り組めるモードを提供することが求められる。

本開示の一態様は、ゲームの興趣性を向上させることを目的とする。

本開示に係るゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、ユーザの操作にしたがって、該ユーザが所有する１以上のキャラクタで構成された自チームを編成するステップと、編成された自チームを、マッチングされた相手チームと対戦させる第１対戦ゲームを進行させるステップと、ユーザにより第１対戦ゲームがプレイされた場合に、キャラクタを獲得できる権利データを、第１報酬として、該ユーザに付与するステップと、第１条件が満たされた場合に、権利データに基づいて特定された１以上のキャラクタをユーザに獲得させるステップと、第２条件 が満たされた場合に、自チームを、ゲームプログラムにしたがって動作するキャラクタで構成された相手チームと対戦させる第２対戦ゲームを進行させるステップと、ユーザにより第２対戦ゲームがプレイされた場合に、キャラクタ、または、該キャラクタと交換可能な価値を、第２報酬として、該ユーザに付与するステップとを実行させる。

本開示の一態様によれば、ゲームの興趣性を向上させる効果を奏する。

ゲームシステムのハードウェア構成を示す図である。 ユーザ端末およびサーバの機能的構成を示すブロック図である。 本実施形態に係るゲームプログラムに基づいて、ゲームシステムにおいて実行される処理の流れを示すフローチャートである。 ユーザ情報のデータ構造の一例を示す図である。 デッキ詳細情報のデータ構造の一例を示す図である。 デッキ概要情報のデータ構造の一例を示す図である。 デッキ選択画面の一例を示す図である。 野手デッキ編成画面の一例を示す図である。 投手デッキ編成画面の一例を示す図である。 ゲームシステムがゲームプログラムに基づいて実行するデッキ編成処理の流れを示すフローチャートである。 マッチング成立画面の一例を示す図である。 本実施形態に係る野球ゲームにおいて進行される対戦を模式的に示す図である。 表示部に表示される投球画面の具体例を示す図である。 表示部に表示される投球画面の具体例を示す図である。 表示部に表示される投球画面の具体例を示す図である。 表示部に表示される打撃画面の具体例を示す図である。 メイン対戦ゲームが終了した後で表示部に表示される、報酬通知画面の具体例を示す図である。 メイン対戦ゲームが終了した後で表示部に表示される、パック通知画面の具体例を示す図である。 表示部に表示されるパック運用画面の具体例を示す図である。 表示部に表示されるパック運用画面の他の具体例を示す図である。 表示部に表示されるキャラクタ通知画面の具体例を示す図である。 ゲームシステムがゲームプログラムに基づいて実行するメイン対戦ゲームおよび第１のカード獲得処理の流れを示すフローチャートである。 出現確率表のデータ構造の一例を示す図である。 表示部に表示されるメッセージ画面の具体例を示す図である。 ゲームシステムがゲームプログラムに基づいて実行する事前処理の流れを示すフローチャートである。 表示部に表示されるオート進行画面の具体例を示す図である。 表示部に表示されるオート進行画面の他の具体例を示す図である。 表示部に表示されるオート進行画面のさらに他の具体例を示す図である。 表示部に表示されるオート進行画面のさらに他の具体例を示す図である。 サブ対戦ゲームが終了した後で表示部に表示される、報酬通知画面の具体例を示す図である。 ゲームシステムがゲームプログラムに基づいて実行するサブ対戦ゲームおよび第２のカード獲得処理の流れを示すフローチャートである。

〔実施形態１〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。

＜ゲームシステム１のハードウェア構成＞
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えばWi-Fi（登録商標））等が挙げられる。

サーバ２００（コンピュータ、情報処理装置）は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ２００は、プロセッサ２０と、メモリ２１と、ストレージ２２と、通信ＩＦ２３と、入出力ＩＦ２４とを備える。サーバ２００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。

ユーザ端末１００（コンピュータ、情報処理装置）は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末１００は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末１００は図示の通り、プロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５（表示部）と、カメラ１７と、測距センサ１８とを備える。ユーザ端末１００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末１００は、タッチスクリーン１５に代えて、または、加えて、ユーザ端末１００本体とは別に構成されたディスプレイ（表示部）を接続可能な入出力ＩＦ１４を備えていてもよい。

また、図１に示すように、ユーザ端末１００は、１つ以上のコントローラ１０２０と通信可能に構成されることとしてもよい。コントローラ１０２０は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信規格に従って、ユーザ端末１００と通信を確立する。コントローラ１０２０は、１つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末１００へ送信する。また、コントローラ１０２０は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末１００へ送信する。

なお、ユーザ端末１００がカメラ１７および測距センサ１８を備えることに代えて、または、加えて、コントローラ１０２０がカメラ１７および測距センサ１８を有していてもよい。

ユーザ端末１００は、例えばゲーム開始時に、コントローラ１０２０を使用するユーザに、該ユーザの名前またはログインＩＤ等のユーザ識別情報を、該コントローラ１０２０を介して入力させることが望ましい。これにより、ユーザ端末１００は、コントローラ１０２０とユーザとを紐付けることが可能となり、受信した出力値の送信元（コントローラ１０２０）に基づいて、該出力値がどのユーザのものであるかを特定することができる。

ユーザ端末１００が複数のコントローラ１０２０と通信する場合、各コントローラ１０２０を各ユーザが把持することで、ネットワーク２を介してサーバ２００などの他の装置と通信せずに、該１台のユーザ端末１００でマルチプレイを実現することができる。また、各ユーザ端末１００が無線ＬＡＮ（Local Area Network）規格等の無線規格により互いに通信接続する（サーバ２００を介さずに通信接続する）ことで、複数台のユーザ端末１００によりローカルでマルチプレイを実現することもできる。１台のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、ユーザ端末１００は、さらに、サーバ２００が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末１００は、サーバ２００が備える後述する種々の機能を分散して備えていてもよい。

なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末１００はサーバ２００と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ２００に送信してもよい。

また、コントローラ１０２０は、ユーザ端末１００に着脱可能な構成であるとしてもよい。この場合、ユーザ端末１００の筐体における少なくともいずれかの面に、コントローラ１０２０との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末１００とコントローラ１０２０とが結合している場合は、ユーザ端末１００とコントローラ１０２０とは、有線を介して信号を送受信する。

図１に示すように、ユーザ端末１００は、外部のメモリカード等の記憶媒体１０３０の装着を、入出力ＩＦ１４を介して受け付けてもよい。これにより、ユーザ端末１００は、記憶媒体１０３０に記録されるプログラム及びデータを読み込むことができる。記憶媒体１０３０に記録されるプログラムは、例えばゲームプログラムである。

ユーザ端末１００は、サーバ２００等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末１００のメモリ１１に記憶してもよいし、記憶媒体１０３０から読み込むことにより取得したゲームプログラムをメモリ１１に記憶してもよい。

以上で説明したとおり、ユーザ端末１００は、該ユーザ端末１００に対して情報を入力する機構の一例として、通信ＩＦ１３、入出力ＩＦ１４、タッチスクリーン１５、カメラ１７、および、測距センサ１８を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。

例えば、操作部が、カメラ１７および測距センサ１８の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末１００の近傍の物体１０１０を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体１０１０としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体１０１０の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末１００は、カメラ１７の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ（ユーザの手の一連の動き）を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。

あるいは、操作部がタッチスクリーン１５で構成される場合、ユーザ端末１００は、タッチスクリーン１５の入力部１５１に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信ＩＦ１３で構成される場合、ユーザ端末１００は、コントローラ１０２０から送信される信号（例えば、出力値）をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力ＩＦ１４で構成される場合、該入出力ＩＦ１４と接続されるコントローラ１０２０とは異なる入力装置（図示せず）から出力される信号をユーザの入力操作として特定し、受け付ける。

＜ゲーム概要＞
ゲームシステム１は、一例として、ゲームプログラムに基づいて、各ユーザが操作する各ユーザ端末１００（クライアント）が通信して対戦を進行させる、通信対人対戦ゲームを実行するためのシステムである。

ゲームシステム１は、特定のジャンルに限らず、あらゆるジャンルのゲームを実行するためのシステムであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、ＲＰＧ、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。

ゲームシステム１は、一例として、通信対人対戦ゲームとして、野球の試合を進行させる、通信対人対戦型の野球ゲーム（以下、本ゲーム、本野球ゲームと称することがある）を実行する。

ゲームシステム１が実行する野球ゲームでは、サーバ２００（情報処理装置）を介して通信する第１のユーザ端末１００と第２のユーザ端末１００とによって、それぞれのチームが操作される。チームは、１または複数のオブジェクトを、ユーザがデッキに組み入れることにより生成される。オブジェクトは、本ゲームにおいて、対戦の進行に何らかの作用を及ぼすデジタルデータである。１以上のオブジェクトによって構成された各ユーザのデッキの強さが、少なくとも、対戦の進行に作用する。オブジェクトは、例えば、キャラクタであり、キャラクタは、例えば、野球の試合に参加して相手チームの選手と対決する野球の選手、または、該選手が試合を有利に進められるように選手を支援する球団のマスコットである。本ゲームでは、選手およびマスコットは、一例として、カードという形態で表現される。本ゲームでは、属性として、選手およびマスコットには、そのキャラクタが所属する球団を示す「所属球団」が設定されている。

本野球ゲームにおいて、ユーザによって対人の対戦がプレイされることにより、プレイ内容に対する評価結果（勝敗、記録、スコアなどの対戦の成績）が出力される。また、該ゲームにおいては、ユーザが対戦をプレイしたことに対して報酬が付与される。該報酬は、例えば、上述のオブジェクトを１以上取得できる権利をユーザに与えるための権利データである。具体的には、選手のカードが所定枚数封入されたパックである。パックを開封することにより、ユーザは、該パックに封入されたカードを入手することができる。そして、入手したカードをデッキに組み入れて、該カードが表している選手を対戦で利用できるようになる。また、パックには、マスコットのカードが封入されていてもよい。ユーザは、パックから入手したマスコットのカードをデッキに組み入れて、同じくデッキに組み入れられている選手を支援させ、対戦を有利に進行させることができる。

本野球ゲームでは、一例として、報酬として与えられたパックは、ユーザに獲得されただけでは開封されない。パックは、ユーザが所有するスロットにセットされた上で、該パックに関連付けてカウントされているパックポイントが所定値に到達した場合に開封可能となる。パックポイントは、ユーザが対戦をプレイする度に、これも対戦をプレイしたことの報酬として、該ユーザに付与され、該ユーザが所有する各パックに割り振られる。

ユーザは、対戦をプレイするほどに多くのパックを入手し、また、多くのパックポイントを獲得する。すなわち、ユーザは、対戦を数多くプレイするほど、より多くのパックを開封し、より多くのカード（選手またはマスコットなどのキャラクタ）を所有することができる。そして、より強い選手または性能の高いマスコットをデッキに組み入れることによりデッキ全体を強化して、対戦を有利に進めることが可能となる。

本野球ゲームは、１イニングにつき、表と裏でチームの攻守が入れ替わりつつ進行する。以下では、あるイニングの表または裏において、守備側のチームを操作するユーザ端末１００と、攻撃側のユーザ端末１００とを互いに区別する必要がある場合、前者を投球側ユーザ端末１００Ａ、後者を打撃側ユーザ端末１００Ｂと称する。両者を区別する必要がない場合には、単に、ユーザ端末１００と称する。投球側ユーザ端末１００Ａのユーザを、投球側ユーザ、打撃側ユーザ端末１００Ｂのユーザを、打撃側ユーザと称する。ただし、両ユーザを特に区別する必要がない場合、および、その区別が明らかな場合には、単にユーザと称する。投球側ユーザは、投球側ユーザ端末１００Ａを用いて、投手キャラクタによる投球を操作し、攻撃側ユーザは、打撃側ユーザ端末１００Ｂを用いて、打者キャラクタによる打撃を操作する。

投球側ユーザ端末１００Ａは、投球側ユーザから受け付けた投球操作に応じて投球結果を決定し、該投球結果を含むデータ（図１に示す投球結果Ｄ１）を生成し、サーバ２００に送信する。投球結果Ｄ１は、サーバ２００を介して、対戦相手の打撃側ユーザ端末１００Ｂに送信される。投球操作とは、投球側ユーザが、投手キャラクタに投球させるために、投球側ユーザ端末１００Ａの入力部１５１に対して実施する操作のことである。

打撃側ユーザ端末１００Ｂは、打撃側ユーザから受け付けた打撃操作に応じて打撃結果を決定し、該打撃結果を含むデータ（図１に示す打撃結果Ｄ２）を生成し、サーバ２００に送信する。打撃結果Ｄ２は、サーバ２００を介して、対戦相手の投球側ユーザ端末１００Ａに送信される。打撃操作とは、打撃側ユーザが、打者キャラクタにボールを打撃させるために、打撃側ユーザ端末１００Ｂの入力部１５１に対して実施する操作のことである。

本野球ゲームにおいて、ユーザは、自身でキャラクタを制御することを希望しない場合に、ユーザ端末１００を操作して、サーバ２００に対してその旨を通知することができる。サーバ２００は、このような通知をユーザ端末１００から受信すると、ゲームプログラムにしたがって、進行している対戦に関わる各種情報に基づいて、該キャラクタの動作結果（投球結果または打撃結果）を決定する。そして、決定した動作結果を対戦相手のユーザ端末１００に送信する。すなわち、サーバ２００は、ユーザ端末１００に代わり、該キャラクタを制御する。

＜各装置のハードウェア構成要素＞
プロセッサ１０は、ユーザ端末１００全体の動作を制御する。プロセッサ２０は、サーバ２００全体の動作を制御する。プロセッサ１０および２０は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、およびＧＰＵ（Graphics Processing Unit）を含む。

プロセッサ１０は後述するストレージ１２からプログラムを読み出し、後述するメモリ１１に展開する。プロセッサ２０は後述するストレージ２２からプログラムを読み出し、後述するメモリ２１に展開する。プロセッサ１０およびプロセッサ２０は展開したプログラムを実行する。

メモリ１１および２１は主記憶装置である。メモリ１１および２１は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の記憶装置で構成される。メモリ１１は、プロセッサ１０が後述するストレージ１２から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ１０に作業領域を提供する。メモリ１１は、プロセッサ１０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ２１は、プロセッサ２０が後述するストレージ２２から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ２０に作業領域を提供する。メモリ２１は、プロセッサ２０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

本実施形態においてプログラムとは、ゲームをユーザ端末１００により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末１００とサーバ２００との協働により実現するためのゲームプログラムであってもよい。なお、ユーザ端末１００とサーバ２００との協働により実現されるゲームは、一例として、ユーザ端末１００において起動されたブラウザ上で実行されるゲームであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末１００の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末１００とサーバ２００との間または複数のユーザ端末１００間で送受信する指示または通知を含んでいる。

ストレージ１２および２２は補助記憶装置である。ストレージ１２および２２は、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）等の記憶装置で構成される。ストレージ１２およびストレージ２２には、ゲームに関する各種データが格納される。

通信ＩＦ１３は、ユーザ端末１００における各種データの送受信を制御する。通信ＩＦ２３は、サーバ２００における各種データの送受信を制御する。通信ＩＦ１３および２３は例えば、無線ＬＡＮ（Local Area Network）を介する通信、有線ＬＡＮ、無線ＬＡＮ、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。

入出力ＩＦ１４は、ユーザ端末１００がデータの入力を受け付けるためのインターフェースであり、またユーザ端末１００がデータを出力するためのインターフェースである。入出力ＩＦ１４は、ＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行ってもよい。入出力ＩＦ１４は、例えば、ユーザ端末１００の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ２００の入出力ＩＦ２４は、サーバ２００がデータの入力を受け付けるためのインターフェースであり、またサーバ２００がデータを出力するためのインターフェースである。入出力ＩＦ２４は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。

ユーザ端末１００のタッチスクリーン１５は、入力部１５１と表示部１５２とを組み合わせた電子部品である。入力部１５１は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部１５２は、例えば液晶ディスプレイ、または有機ＥＬ（Electro-Luminescence）ディスプレイ等によって構成される。

入力部１５１は、入力面に対しユーザの操作（主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作）が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部１５１は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。

図示していないが、ユーザ端末１００は、該ユーザ端末１００の保持姿勢を特定するための１以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末１００がセンサを備えている場合、プロセッサ１０は、センサの出力からユーザ端末１００の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ１０は、ユーザ端末１００が縦向きに保持されているときには、縦長の画像を表示部１５２に表示させる縦画面表示としてもよい。一方、ユーザ端末１００が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ１０は、ユーザ端末１００の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。

カメラ１７は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。

測距センサ１８は、測定対象物までの距離を測定するセンサである。測距センサ１８は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ１８は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ１８は、指向性を有する光を発する光源を有することとしてもよい。

ここで、ユーザ端末１００が、カメラ１７と測距センサ１８とを用いて、ユーザ端末１００の近傍の物体１０１０を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ１７および測距センサ１８は、例えば、ユーザ端末１００の筐体の側面に設けられてもよい。カメラ１７の近傍に測距センサ１８が設けられてもよい。カメラ１７としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ１７に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ１７の撮影画像に基づく物体の検出精度をいっそう向上させることができる。

プロセッサ１０は、カメラ１７の撮影画像に対して、例えば以下の（１）〜（５）に示す処理のうち１つ以上の処理を行ってもよい。（１）プロセッサ１０は、カメラ１７の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ１０は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。（２）また、プロセッサ１０は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ１０は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数（伸びている指の本数）を特定する。プロセッサ１０はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ１０は、指の本数が５本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が０本である（指が検出されなかった）場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が２本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。（３）プロセッサ１０は、カメラ１７の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。（４）プロセッサ１０は、カメラ１７の撮影画像の画像認識結果、および、測距センサ１８の出力値等の少なくともいずれか１つに基づいて、ユーザ端末１００の近傍の物体１０１０（ユーザの手など）とユーザ端末１００との距離を検出する。例えば、プロセッサ１０は、カメラ１７の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末１００の近傍（例えば所定値未満の距離）にあるのか、遠く（例えば所定値以上の距離）にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ１０は、ユーザの手がユーザ端末１００に接近しているのか遠ざかっているのかを検出してもよい。（５）カメラ１７の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末１００とユーザの手との距離が変化していることが判明した場合、プロセッサ１０は、ユーザが手をカメラ１７の撮影方向において振っていると認識する。カメラ１７の撮影範囲よりも指向性が強い測距センサ１８において、物体が検出されたりされなかったりする場合に、プロセッサ１０は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。

このように、プロセッサ１０は、カメラ１７の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か（「グー」のジェスチャであるか、それ以外のジェスチャ（例えば「パー」）であるか）を検出する。また、プロセッサ１０は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ１０は、ユーザがこの手をユーザ端末１００に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末１００は、例えば、ユーザの手の移動に応じて、タッチスクリーン１５においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末１００は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末１００は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作（またはドラッグ操作）に対応する操作として認識することもできる。また、ユーザ端末１００は、カメラ１７の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。

＜ゲームシステム１の機能的構成＞
図２は、ゲームシステム１に含まれるサーバ２００およびユーザ端末１００の機能的構成を示すブロック図である。サーバ２００およびユーザ端末１００のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。

ユーザ端末１００は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信ＩＦ１３、および入出力ＩＦ１４等の協働によって、制御部１１０および記憶部１２０として機能する。

サーバ２００は、各ユーザ端末１００と通信して、各ユーザ端末１００が通信対戦ゲームを進行させるのを支援する機能を有する。サーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、および入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２２０として機能する。

記憶部１２０および記憶部２２０は、ゲームプログラム１３１、ゲーム情報１３２およびユーザ情報１３３を格納する。ゲームプログラム１３１は、ユーザ端末１００およびサーバ２００で実行するゲームプログラムである。ゲーム情報１３２は、制御部１１０および制御部２１０がゲームプログラム１３１を実行する際に参照するデータである。ユーザ情報１３３は、ユーザのアカウントに関するデータである。記憶部２２０において、ゲーム情報１３２およびユーザ情報１３３は、ユーザ端末１００ごとに格納されている。

（サーバ２００の機能的構成）
制御部２１０は、記憶部２２０に格納されたゲームプログラム１３１を実行することにより、サーバ２００を統括的に制御する。例えば、制御部２１０は、ユーザ端末１００に各種データおよびプログラム等を送信する。制御部２１０は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末１００から受信する。ゲームがマルチプレイゲームである場合には、制御部２１０は、ユーザ端末１００からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末１００に送信してもよい。

制御部２１０は、ゲームプログラム１３１の記述に応じて、対戦支援部２１１、および、カード提供部２１２として機能する。制御部２１０は、実行するゲームの性質に応じて、ユーザ端末１００におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。

対戦支援部２１１は、各ユーザ端末１００が通信対戦ゲームを進行させるのを支援する。具体的には、対戦支援部２１１は、対戦する各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する。さらに、対戦支援部２１１は、対戦相手のマッチング、対戦の進行状況の同期をとるための同期制御などを実行する。また、対戦支援部２１１は、対戦の成績に基づいて報酬を算定したり、報酬の内容をユーザ端末１００に通知して、ユーザに報酬を付与したりする。

カード提供部２１２は、ユーザ端末１００からの要求に応じて、ユーザに、対戦で利用可能なオブジェクトを提供する。本実施形態では、カード提供部２１２は、デッキに組み入れて対戦で利用することが可能なキャラクタのカードを提供する。本実施形態では、ユーザにカードを獲得させる方法が２つある。第１の方法は、上述のパック（第１報酬）が運用されたことに基づいて、カード提供部２１２が該パックに対応するカードを提供する方法である。カード提供部２１２は、提供されるカードを、パックに設定されているランクに基づいて抽選などによって特定してもよい。パックは、本野球ゲームのメイン要素である、上述の対人対戦（以下、メイン対戦ゲーム）がプレイされたことの報酬として、ユーザに付与される。第２の方法は、ユーザが所有するゲーム内の価値（仮想通貨、ポイント、ジュエルなど）と引き換えに、カード提供部２１２が該価値に見合うカードを提供する方法である。カード提供部２１２は、ユーザが選択したカードを上述の価値と交換で直接的に提供してもよいし、該カードをユーザに獲得させることを可能にするアイテム（例えば、抽選チケットなど）を上述の価値と交換することにより、間接的にカードを提供してもよい。ゲーム内の価値は、本野球ゲームのサブ要素である、後述のコンピュータ対戦（以下、サブ対戦ゲーム）がプレイされたことの報酬として、ユーザに付与される。本実施形態では、一例として、ゲーム内の価値は、交換ポイントと称される。ユーザは、サブ対戦ゲームをプレイすることにより交換ポイント（第２報酬）を貯め、貯めた交換ポイントを予め定められた量消費することにより、該量に見合った価値を持つカードを獲得することができる。

第１の方法を実現する第１のカード獲得処理において、本実施形態では、カード提供部２１２は、ユーザ端末１００のカード取得部１１６から指定されたカードパックに基づいて、該カードパックに対応する選手カードを特定する。そして、カード提供部２１２は、特定したカードをカード取得部１１６に通知することにより、ユーザにカードを提供する。本実施形態では、カード提供部２１２は、指定されたカードパックと引き換えに抽選を実施して、提供すべき選手カードを特定してもよい。

本実施形態では、権利データには、ゲームを有利に進める上で価値が高いオブジェクトが取得できる可能性を表す期待値が設定されていてもよい。具体的には、期待値とは、上述の抽選において、良いカードを引き当てる確率である。良いカードとは、対戦を有利に進める上で価値が高いとされるカードであり、対戦における能力が高い選手の選手カードを指す。本実施形態では、カードパックのそれぞれには、能力が高い選手の選手カードが当選する期待値が設定されている。

本実施形態では、選手カードには、上述の価値の高さを表す希少度が設定されており、例えば、希少度が高い（能力が高い）順に、Ｓ、Ａ、Ｂ、Ｃの４種類がある。抽選において、希少度が高いほど当選する確率は低くなる。以下では、特に、期待値という用語を用いる場合には、対戦を有利に進める上で価値が高い選手カードとして、Ｓの希少度が設定されている選手カードを引き当てる確率を意味する。

より具体的には、カードパックには、４種類のランクが設定されていてもよい。本実施形態では、ブラック、ゴールド、シルバー、ノーマルの４種類のランクのいずれかが、カードパックに付与される。本実施形態では、カードパックのランクに応じて、当該カードパックにおいて、期待値、すなわち、希少度Ｓの選手カードを引き当てる確率がそれぞれ異なる。各ランクのカードパックに設定されている期待値は、一例として、ランクが高いカードパックから順に、ブラックは２０％、ゴールドは１０％、シルバーは５％、ノーマルは０．５％であってもよい。なお、各ランクにおける、希少度Ａ以降の抽選確率は、希少度が下がるにつれて抽選確率が上がるように適宜設定されてもよいし、一律に設定されてもよい。例えば、ゴールドランクのカードパックにおいて、希少度Ａ以降の抽選確率は、それぞれ一律３０％であってもよい。

別の実施形態では、カードパックのランクに基づいて、すべての希少度ごとに期待値が設定されていてもよい。一例として、カード提供部２１２が、ノーマルランクのカードパックに基づいて、各希少度の選手カードを引き当てる確率は、Ｓ：０．５％、Ａ：５．５％、Ｂ：４４％、Ｃ：５０％であってもよい。カード提供部２１２が、ブラックランクのカードパックに基づいて、各希少度の選手カードを引き当てる確率は、例えば、Ｓ：２０％、Ａ：２５％、Ｂ：３５％、Ｃ：２０％であってもよい。

いずれの実施形態においても、希少度Ｓの期待値は、ランクが上がるにつれて高くなるように、それぞれのランクのカードパックに設定されていることが好ましい。カードパックは、開封前から期待値が分かるように、ランクごとに異なる態様でユーザに提示されてもよい。カードパックは、表示部１５２に提示される際、大きさ、色、形、装飾、または、文字などの表示の態様が、ランクごとに異なっていることが好ましい。これにより、ユーザは、開封前から、自身が入手したカードパックに基づいて、希少度Ｓの選手カードを取得できる確率を推測することができる。これにより、戦略的にカードパックを開封することが可能となり、ゲームの興趣性を向上させることができる。

本実施形態では、対戦支援部２１１は、報酬を算定する際、対戦のプレイ結果に応じた期待値が設定された権利データを、対戦をプレイしたユーザに付与する。具体的には、対戦の成績が良いほど、ランクの高いカードパックが付与されるように、報酬を算定する。

第２の方法を実現する第２のカード獲得処理において、本実施形態では、カード提供部２１２は、交換ポイントと交換することが可能なキャラクタのカードの一覧を、交換に必要なポイント数とともにユーザ端末１００に提供する。ユーザ端末１００のカード取得部１１６は、交換ポイントと交換したキャラクタの指定をユーザから受け付ける。カード提供部２１２は、ユーザ端末１００のカード取得部１１６からキャラクタのカードを交換する要求を受け付けると、所定の交換ポイントと引き換えに、要求されたキャラクタのカードをユーザ端末１００に提供する。

（ユーザ端末１００の機能的構成）
制御部１１０は、記憶部１２０に格納されたゲームプログラム１３１を実行することにより、ユーザ端末１００を統括的に制御する。例えば、制御部１１０は、ゲームプログラム１３１およびユーザの操作にしたがって、ゲームを進行させる。また、制御部１１０は、ゲームを進行させている間、必要に応じて、サーバ２００と通信して、情報の送受信を行う。

制御部１１０は、ゲームプログラム１３１の記述に応じて、操作受付部１１１、表示制御部１１２、ＵＩ制御部１１３、アニメーション生成部１１４、対戦進行部１１５、および、カード取得部１１６として機能する。制御部１１０は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。

操作受付部１１１は、入力部１５１に対するユーザの入力操作を検知し受け付ける。操作受付部１１１は、タッチスクリーン１５およびその他の入出力ＩＦ１４を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部１１０の各要素に出力する。

例えば、操作受付部１１１は、入力部１５１に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部１１１は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部１１１は、連続して検知されていた入力が途切れると、タッチスクリーン１５から接触入力が解除されたことを検知する。

ＵＩ制御部１１３は、ユーザインターフェース（以下、ＵＩ）を構築するために表示部１５２に表示させるＵＩ部品を制御する。ＵＩ部品は、ユーザが、ゲームの進行上必要な入力をユーザ端末１００に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末１００から得るためのツールである。ＵＩ部品は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。

また、対戦進行中、とりわけ、投球操作、または、打撃操作を支援するためのＵＩ部品の表示態様を制御する。打撃操作を支援するＵＩ部品としては、例えば、打撃の良好なタイミングを示すタイミングヒントオブジェクト、投手キャラクタから投げられたボール、投球の進行方向の変化を示す方向ヒントオブジェクト、投球の到達予定位置を示す位置ヒントオブジェクト、および、バットとボールとの当たりを判定するためのミートカーソル等がある。投球操作を支援するＵＩオブジェクトとしては、例えば、球種選択オブジェクト、コース提示オブジェクト、コース選択オブジェクト、および、投球タイミングオブジェクト等がある。

アニメーション生成部１１４は、上述のＵＩ部品を含む各種のオブジェクトの制御態様に基づいて、各オブジェクトのモーションを示すアニメーションを生成する。例えば、投手の投球動作のアニメーション、打者の打撃動作のアニメーション、該打者が振るバットのアニメーション、投手によって投げられたボールのアニメーション、打者によって打たれたボールのアニメーション、走者が盗塁するアニメーション等を生成してもよい。上述の投手、打者、および、走者は、デッキに編成されたカード（選手）に基づいて規定される。

表示制御部１１２は、タッチスクリーン１５の表示部１５２に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部１１２は、アニメーション生成部１１４によって生成されたアニメーションを含むゲーム画面を表示部１５２に表示してもよい。また、表示制御部１１２は、上述のＵＩオブジェクトを、該ゲーム画面に重畳して描画してもよい。

対戦進行部１１５は、サーバ２００との間でデータの送受信を行って、相手ユーザとの対戦を進行させる。また、対戦進行部１１５は、ＵＩ制御部１１３、アニメーション生成部１１４および表示制御部１１２を制御して、ユーザが本野球ゲームをプレイするために必要な上述のＵＩをユーザに提供する。対戦進行部１１５は、ＵＩ制御部１１３またはアニメーション生成部１１４に、ＵＩ部品を含むゲーム画面を生成させる。対戦進行部１１５は、表示制御部１１２に、生成された該ゲーム画面を表示部１５２に表示させる。これにより、ユーザが本野球ゲームをプレイするためのＵＩが実現される。

したがって、後に図に基づいて詳述するゲーム画面は、ＵＩ制御部１１３が生成するＵＩ部品、アニメーション生成部１１４が生成するアニメーション、または、これらを組み合わせによって構成される。ＵＩ制御部１１３またはアニメーション生成部１１４によって生成されたゲーム画面は、表示制御部１１２によって、ユーザ端末１００の表示部１５２に表示される。表示制御部１１２、ＵＩ制御部１１３およびアニメーション生成部１１４は、対戦進行部１１５の制御下で、ゲーム画面を表示部１５２に表示するための処理を実行する。よって、「対戦進行部１１５が、ゲーム画面を表示部１５２に表示する」という記載は、「対戦進行部１１５が、ＵＩ制御部１１３またはアニメーション生成部１１４を制御して、ＵＩ部品またはアニメーションを生成させ、表示制御部１１２を制御して、生成されたＵＩ部品またはアニメーションを含むゲーム画面を表示部１５２に表示させる」ことを意味する。

カード取得部１１６は、サーバ２００から第１の方法または第２の方法にて提供されるカードを取得してユーザに獲得させる。第１のカード獲得処理において、まず、カード取得部１１６は、ユーザに付与された権利データ（パック）を、該権利データに基づいてオブジェクト（キャラクタ）を取得できる状態に遷移させる。すなわち、カードパックを開封可能な状態に遷移させる。本実施形態では、カード取得部１１６は、一例として、パックポイントの加算を可能にするスロットに、カードパックを配置する。本実施形態では、スロットは、ユーザに対して所定数提供される。例えば、デフォルトで、３つのスロットがユーザに関連付けてゲーム情報１３２において定義されている。カード取得部１１６は、スロットにカードパックを配置することにより、カードパックに対応付けてパックポイントを加算することができる。カード取得部１１６によって、パックポイントが加算されていくことによって、カードパックに割り当てられている条件が満足されると、すなわち、パックポイントの合計が、上述の条件に示された所定値に到達すると、カードパックは、開封可能な状態となる。すなわち、カード取得部１１６が、カードパックに基づいて選手カードを取得できる状態となる。パックポイントは、例えば、カードパックと同様に、メイン対戦ゲームの報酬としてユーザに付与されてもよい。

本実施形態では、カードパックはスロットに配置されることにより、パックポイントを貯めていくことができる。すなわち、スロットは、カード取得部１１６がパックポイントを加算することを可能にし、カードパックが開封可能な状態へと遷移していくことを可能にする要件となる。さらに、パックポイントの加算には、別の要件が追加されてもよい。

次に、カード取得部１１６は、オブジェクトを取得可能な状態に遷移した権利データに基づいて、オブジェクトを取得する。カード取得部１１６は、権利データを消費し、該権利データと引き換えに、該権利データに対応するオブジェクトを取得してもよい。本実施形態では、カード取得部１１６は、カードパックを開封して、そこに封入されている選手カードを取得する。より具体的には、カード取得部１１６は、選手カードを取得するために、消費する権利データを指定したカード取得要求を、サーバ２００に通知する。サーバ２００において、指定された権利データに基づいて、選手カードが特定され、これがカード取得部１１６に通知されることにより、カード取得部１１６は、選手カードを取得することができる。

第２のカード獲得処理において、まず、操作受付部１１１が、交換ポイントで交換したいキャラクタの指定を受け付ける。カード取得部１１６は、指定されたキャラクタのカードを、交換ポイントと交換する旨の要求をサーバ２００に送信する。カード取得部１１６は、交換の成立に係る通知をサーバ２００から受信し、指定されたキャラクタのカードをユーザに獲得させる。キャラクタのカードをユーザに獲得させるとは、一例として、ユーザに対応付けて管理されているデジタルデータであるキャラクタのステータスを、使用不可から使用可能に遷移させることであってもよい。あるいは、キャラクタのカードに相当するデジタルデータを、ユーザ識別情報またはユーザＩＤに対応付けて、ゲームシステム１に含まれる少なくともいずれかのメモリ（メモリ１１、メモリ２１）に記憶させることであってもよい。

なお、図２に示すサーバ２００およびユーザ端末１００の機能は一例にすぎない。サーバ２００は、ユーザ端末１００が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末１００は、サーバ２００が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末１００およびサーバ２００以外の他の装置をゲームシステム１の構成要素とし、該他の装置にゲームシステム１における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末１００、サーバ２００、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。

＜処理概要＞
図３は、本野球ゲームのおおまかな流れを説明するフローチャートである。概して、ゲームシステム１に含まれるユーザ端末１００およびサーバ２００の少なくともいずれか一方のコンピュータは、ゲームプログラムを実行することにより、以下の各ステップを実行する構成である。

すなわち、ゲームシステム１は、ステップＳ１において、ユーザの操作にしたがって、該ユーザが所有する１以上のキャラクタで構成された自チームをデッキとして編成するステップを実行する。ステップＳ２において、ゲームシステム１は、編成されたチームを、マッチングされた相手チームと対戦させるメイン対戦ゲーム（第１対戦ゲーム）を進行させるステップを実行する。ステップＳ３において、ゲームシステム１は、カードをユーザに獲得させるための第１のカード獲得処理を実行する。例えば、ゲームシステム１は、ユーザによりメイン対戦ゲームがプレイされた場合に、キャラクタのカードを獲得できるパック（権利データ、第１報酬）を該ユーザに付与するステップを実行する。具体的には、ステップＳ３において、ゲームシステム１は、第１条件が満たされた場合に、パックに基づいて特定された１以上のキャラクタをユーザに獲得させるステップを実行する。

次に、ステップＳ４において、ゲームシステム１は、後述のサブ対戦ゲームをプレイする機会をユーザに与えるか否かを決定するための事前処理としてサブ対戦ゲームの実行を制御するステップを実行してもよい。例えば、ゲームシステム１は、第２条件が満たされた場合に、サブ対戦ゲームをプレイする機会をユーザに与えることを決定する。サブ対戦ゲーム（第２対戦ゲーム）は、ユーザによって編成された自チームを、ゲームプログラムにしたがって動作するキャラクタで構成された相手チームと対戦させるゲームである。

サブ対戦ゲームを実行することが決定された場合、ゲームシステム１は、ステップＳ５のＹＥＳからステップＳ６に進む。そして、ゲームシステム１は、ステップＳ６において、サブ対戦ゲーム（第２対戦ゲーム）を進行させるステップを実行する。サブ対戦ゲームを実行しないことが決定された場合、ステップＳ６およびＳ７は省略される。

ステップＳ７において、ゲームシステム１は、カードをユーザに獲得させるための第２のカード獲得処理を実行する。例えば、ゲームシステム１は、ユーザによりサブ対戦ゲームがプレイされた場合に、キャラクタ、または、該キャラクタと交換可能な交換ポイント（ゲーム内の価値）を、該ユーザに第２報酬として付与するステップを実行する。

なお、ゲームシステム１は、以下のように構成することもできる。すなわち、ゲームシステム１は、ステップＳ２において、ユーザが所有する１以上のキャラクタで構成された自チームを、マッチングされた相手チームと対戦させるメイン対戦ゲーム（第１対戦ゲーム）を進行させるステップを実行する。ゲームシステム１は、第１対戦ゲームが終了した後、所定の確率にて、ステップＳ６において、自チームを、ゲームプログラムにしたがって動作するキャラクタで構成された相手チームと対戦させるサブ対戦ゲーム（第２対戦ゲーム）を進行させるステップを実行する。ゲームシステム１は、ユーザにより第２対戦ゲームがプレイされた場合に、ステップＳ７において、サブ対戦ゲームの成績に応じた報酬を該ユーザに付与するステップを実行する。サブ対戦ゲームの報酬としては、キャラクタ（例えば、キャラクタのカード）、または、該キャラクタと交換可能なゲーム内の価値（例えば、上述の交換ポイント）が想定される。

上述の各ステップのすべてが１台のコンピュータで実行されなくてもよく、一部のステップをユーザ端末１００が実行し、残りのステップをサーバ２００が実行する構成であってもよい。

本実施形態では、メイン対戦ゲームにおいてマッチングされる相手チームは、基本的に、他のユーザが所有する１以上のキャラクタで構成されたチームであり、メイン対戦ゲームは、他のユーザが操作する相手チームと対戦する通信対人対戦である。しかし、マッチングの結果、他のユーザが見つからなかった場合には、サーバ２００は、ゲームプログラムに基づいて動作するキャラクタで構成されたチームを、ユーザの対戦相手としてマッチングする場合もある。すなわち、メイン対戦ゲームは、コンピュータ対戦を含み得る。

ゲームシステム１において、メイン対戦ゲームが、通信対人対戦として実行される場合、ユーザ端末１００（ユーザのコンピュータ）は、対戦相手である他のユーザが操作するユーザ端末１００（他のコンピュータ）と通信しながら、進行状況を同期させて対戦を進行させる。

本実施形態では、サブ対戦ゲームにおける相手チームは、ゲームプログラムにしたがって動作するキャラクタで予め構成されたチームである。すなわち、サブ対戦ゲームは、コンピュータ対戦である。したがって、ユーザのコンピュータは、他のコンピュータとの同期を考慮することなく、ゲームプログラムとユーザが実施する操作とに基づいて、コンピュータ対戦を進行させることができる。ユーザは、対戦相手である他のユーザの挙動の影響を受けずに、自分のペースで対戦を進行させることができる。メイン対戦ゲームにおいては、ユーザは、他のユーザの挙動を予測したりしてかけひきを楽しみ、緊張感の中で対戦に興じることができる。その一方で、サブ対戦ゲームでは、ユーザは、そうした緊張感から解放されて、気楽にコンピュータ相手の対戦を楽しむことができる。メイン対戦ゲームのような興奮度の高い対戦ばかりでなく、ときおり、サブ対戦ゲームのように気楽に取り組めるコンピュータ対戦が差し挟まれることにより、ゲームの内容に緩急をつけることができる。こうして、ゲームの内容に緩急をつけることにより、ユーザを過度に疲れさせたり、飽きさせたりすることを回避でき、結果として、ユーザのプレイの動機付けを維持または強化することができる。

なお、第２条件が満たされるかどうかは、ランダムで決定されてもよい。具体的には、サブ対戦ゲームの実行可否は、抽選の実施により決定されてもよい。その際、第１対戦ゲームの勝敗が確率に影響を与えてもよい。例えば、上述の制御するステップでは、ゲームシステム１は、自チームがメイン対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、第２条件が満たされたと判断してもよい。

さらに、サブ対戦ゲームにおける相手チームは、ゲームシステム１によって作成された、複数のチームの中からランダムで決定されてもよい。相手チームの候補となる複数のチームは、それぞれ、強さが異なっていることが好ましい。そして、ステップＳ７において、ゲームシステム１は、サブ対戦ゲームの報酬（第２報酬）として、自チームが対戦する相手チームが強いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する報酬を付与することが好ましい。

さらに、サブ対戦ゲームにおいて、どの強さの相手チームと対戦するのかは、抽選の実施により決定されてもよい。第１対戦ゲームの勝敗が確率に影響を与えてもよい。例えば、上述の制御するステップでは、ゲームシステム１は、自チームがメイン対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、より強いチームを相手チームとして決定してもよい。

＜ユーザ情報のデータ構造＞
図４は、ユーザ情報１３３のデータ構造の一例を示す図である。ユーザ情報１３３は、対戦で参照されるユーザに係る情報を管理するためのデータであり、ユーザごとに作成される。ユーザ情報１３３は、記憶部１２０に格納されている。ユーザ情報１３３は、サーバ２００の記憶部２２０にも格納されていてもよい。

ユーザ情報は、複数の項目を含む。一例として、少なくとも、ユーザ名、レーティング、指定球団、および、交換ポイントの各項目を含む。

「ユーザ名」は、ユーザの名称を示す。ユーザ名は、他のユーザがユーザを識別するために利用する。さらに、ユーザ情報は、ゲームシステム１の各装置がユーザを識別するための「ユーザＩＤ」を含んでいてもよい。「レーティング」は、ユーザに設定されているレーティングを示す。レーティングは、対戦におけるユーザの強さを表す指標である。レーティングは、所定の演算式に基づき、ユーザ同士の対戦の結果（例えば、勝敗）と、各ユーザの対戦前のレーティングの差分とに基づいて更新される。具体的には、対戦に勝利したユーザのレーティングは増加され、敗北したユーザのレーティングは、減じられる。したがって、レーティングが高いほどそのユーザが対戦に強いという推測が成り立つ。

ユーザ情報は、さらに、「指定球団」の項目を含む。本ゲームでは、一例として、本ゲームの開始時に実在するプロ野球チーム（１２球団）の中から、ユーザがお気に入りの球団を指定球団として１つ指定する。指定球団の項目は、対戦進行部１１５によって、参照される。例えば、対戦進行部１１５は、ユーザがお気に入りの指定球団に基づいて、ユーザのチームを表すチームロゴのデザインを決定してもよいし、該指定球団とデッキに組み入れられているキャラクタに設定されている属性（例えば、所属球団）に基づいて、デッキの強さを決定してもよい。

指定球団は、ゲームが開始された後、ユーザによって任意に変更されてもよいし、ユーザが本ゲームをプレイした結果、一定の条件が満たされたことにより、該ユーザが変更できるものであってもよい。

「交換ポイント」の項目には、ユーザがこれまで獲得した交換ポイントの累計が格納されている。ユーザが、サブ対戦ゲームをプレイしたことにより、新たに交換ポイントが付与された場合には、対戦進行部１１５は、付与された交換ポイントを該累計に加算する。ユーザが、交換ポイントと引き換えに、新たなキャラクタを獲得した場合には、カード取得部１１６は、該累計から交換対象のポイントを減算する。

＜デッキ編成処理＞
図５〜図１０を参照して、ユーザ端末１００およびサーバ２００の少なくともいずれか一方が実施するデッキ編成処理の詳細について説明する。

（デッキについて）
ユーザが保有するデッキは、デッキ情報として、ゲームシステム１において取り扱われる。デッキ情報のデータ構造については、後に詳述する。デッキ情報は、ユーザが所有するデッキに係る情報を管理するためのデータである。デッキ情報は、記憶部１２０に、ゲーム情報１３２として格納されている。デッキ情報は、サーバ２００の記憶部２２０にも格納されていてもよい。デッキ情報は、対戦進行部１１５によって、対戦の進行時に参照され、利用される。

本実施形態では、一例として、デッキ情報は、デッキ詳細情報とデッキ概要情報とを含む。デッキ詳細情報は、デッキを構成する各キャラクタの個別情報を集約したものである。デッキ概要情報は、各キャラクタがデッキに配置されたことにより編成されたチーム全体に関する情報である。

ユーザは、本ゲームにおいて、一例として、第１デッキと第２デッキとの、性質の異なる２種類のデッキを保有可能であってもよい。第１デッキは、例えば、キャラクタ優先デッキである。第１デッキは、ユーザの指定球団およびキャラクタの所属球団に依らず、能力の高いキャラクタを多く組み入れるほど、デッキの強さが上がる性質を持つ。このような性質の第１デッキがユーザに提供されることにより、強いキャラクタを獲得する喜び、お気に入りのキャラクタを収集する楽しみ、および、獲得した強いキャラクタで、自分なりのドリームチームを編成する楽しみを、ユーザに与えることができる。

第２デッキは、例えば、自球団優先デッキである。第２デッキは、ユーザの指定球団に属するキャラクタを多く組み入れるほど、デッキの強さが上がる性質を持つ。このような性質の第２デッキがユーザに提供されることにより、自分のお気に入りである指定球団に所属するキャラクタを獲得する喜び、指定球団所属のキャラクタを収集する楽しみ、および、獲得したキャラクタで指定球団のようなチームを編成する楽しみを、ユーザに与えることができる。

（キャラクタについて）
本実施形態では、ユーザは、保有するデッキに、選手およびマスコットの２種類のキャラクタを組み入れることができる。選手は、対戦が進行する仮想空間上に配置されるオブジェクトである。選手は、該選手に設定されている属性および能力値に基づいて、場合によっては、ユーザの入力操作に基づいて決定された動作を仮想空間上で実施する。すなわち、選手は、対戦の進行に直接的に作用する直接オブジェクトである。マスコットは、該マスコットに設定されている属性および能力値に基づいて決定された効果を、直接オブジェクトとしての選手に個別に、または、デッキ全体にもたらす。こうしてマスコットは、選手が対戦を有利に進められるように選手を支援する。すなわち、マスコットは、対戦中に動作を実施する選手に対して有利な作用を及ぼすことにより、対戦の進行に間接的に作用する間接オブジェクトである。

本実施形態では、第１デッキおよび第２デッキのいずれにも、選手だけでなくマスコットを組み入れることができる。マスコットがデッキに組み入れられたときに発揮される効果、および、効果が発揮されるための条件などは、各デッキの性質に合わせて、異ならせることが好ましい。これにより、ユーザは、手持ちのマスコットの効果がより効果的に発揮されるためにいずれのデッキを用いるか、また、どのように選手を配置するかを思慮深く検討することになる。結果として、デッキ編成の戦略性が高まり、ゲームの興趣性を向上させることができる。

さらに、本実施形態では、各キャラクタは、キャラクタ種別に基づいて分類されてもよい。キャラクタ種別も、属性の１項目として、各キャラクタに設定されている。例えば、選手は、守備のポジションに基づいて「野手」か「投手」かに分類される。ポジションに基づく上述の分類をポジション種別（第１種別）と称する。マスコットは、性別（第２種別）に基づいて、「雄」か「雌」かに分類される。

本実施形態では、マスコットの効果は、マスコットの性別に対応するポジション種別を有する選手に対して発揮されてもよい。一例として、デッキに組み入れられた選手の能力値は、該選手のポジション種別に対応する性別のマスコットがデッキに組み入れられている場合に上方に補正される。より具体的には、「野手」の分類と「雄」の分類とが対応しており、「投手」の分類と「雌」の分類とが対応している場合、マスコットの雄は、対戦において野手の能力値を上昇させる効果を発揮してもよい。

本実施形態では、「ポジション」との用語は、デッキにおいて１体のキャラクタが担う１つの役割を示し、デッキを構成する最小単位の要素である。「ポジション」とキャラクタとは１対１で紐付けられる。デッキは、同じ役割のポジションを複数有していてもよい。「ポジション」の一例として、野球における守備位置が想定されているが、「ポジション」は野球の守備位置としてのみ狭義に解釈されるべきでなく、１体のマスコットが担う、「選手を応援する」という役割も「ポジション」の１つに含まれる。

（能力値について）
本野球ゲームでは、キャラクタのそれぞれには、能力値が設定されている。能力値には、身体能力パラメータと、総合パラメータとがある。身体能力パラメータは、対戦において発揮される選手の身体能力を表す値である。具体的には、身体能力パラメータは、野球で必要とされる技能ごとに、選手の技量を数値化したものである。本実施形態では、例えば、身体能力パラメータとして、打撃力、命中力、最速球速、制球力、変化球力、走力、守備力、送球速度、および、送球精度などがある。

これに対して、総合パラメータは、技能および技量に関係なく、キャラクタの総合的な強さを数値化したものであり、キャラクタのカードごとに設定される。総合パラメータは、対戦時、対戦進行部１１５および対戦支援部２１１によって参照され、対戦の進行に影響を与える。具体的には、本野球ゲームは、第１デッキおよび第２デッキのいずれも、組み入れられているキャラクタの総合パラメータが高いほど、対戦が有利に進行する仕様である。

選手個々に設定されている総合パラメータは、投手と打者とが対決する場面において参照されてもよい。例えば、対戦進行部１１５は、１つの打席開始時に、打者の総合パラメータと、投手の総合パラメータとを比較する。そして、該打席が進行する期間、総合パラメータが低い方の選手の身体能力パラメータをマイナス補正する。例えば、総合パラメータの比較で投手が負けた場合、対戦進行部１１５は、該打席の間、投手の投球に関わる身体能力パラメータ（最高球速および制球力）を、それぞれ、例えば１０％減算する。このように、総合パラメータがより高い選手を起用することが、各打席を有利に進行させることにつながる。別の例では、総合パラメータの比較で投手が負けた場合、打者の身体能力パラメータ（打撃力および命中力）を、それぞれ、例えば１０％加算してもよい。

（デッキ詳細情報）
図５は、デッキ情報のうち、デッキ詳細情報のデータ構造の一例を示す図である。図５に示すデッキ詳細情報は、第１デッキおよび第２デッキのそれぞれについて別に生成される。

本実施形態では、１つのデッキを、配置される選手の役割に応じて、複数種類の下位デッキに区分してもよい。デッキは、一例として、選手のポジションに基づいて、野手デッキおよび投手デッキの２種類に区分されてもよい。さらに、デッキは、例えば、選手の試合への出場タイミングに基づいて、スターティングメンバーのデッキおよび控えメンバーのデッキの２種類に区分されてもよい。したがって、本野球ゲームでは、第１デッキおよび第２デッキのそれぞれは、以下のように４つに区分された下位デッキで構成される。

本野球ゲームでは、一例として、スターティングメンバーの野手を含む下位デッキを野手スタメンデッキと称し、控えメンバーの野手を含む下位デッキを野手ベンチデッキと称する。また、スターティングメンバーの投手、すなわち、先発投手を含む下位デッキを投手先発デッキと称し、控えメンバーの投手、すなわち、リリーフ投手を含む下位デッキを投手リリーフデッキと称する。

デッキは、上述のとおり複数の役割で構成されている。例えば、役割としては、チームにおける守備または攻撃のポジションがあってもよいし、これらの直接的なポジションにいるチーム員を支援または補助する応援のポジションがあってもよい。１つのデッキは、異種のポジションを１つずつ有していてもよいし、同種のポジションを複数有していてもよい。例えば、野手スタメンデッキは、１種のポジションを１つずつ有する。投手リリーフデッキは、同種のポジションを複数有する。

デッキ詳細情報は、デッキを構成する各ポジションと、該ポジションを担うキャラクタとの紐付けを管理するための情報である。図５に示すとおり、一例として、本ゲームのデッキは、２７個のポジションで構成されている。デッキ詳細情報において、１個のポジションにつき１つのレコードが生成され、合計２７体のキャラクタがそれぞれのポジションに紐付けられる。

図５に示すとおり、デッキ詳細情報は、一例として、デッキ区分、ポジションＩＤ、ポジション名、キャラクタＩＤ、属性、総合パラメータ、および、マスコット効果補正の各項目を有する。デッキ詳細情報が、第１デッキのものであるとき、自球団効果補正の項目は設けられないか、あるいは、当該項目の値はＮＵＬＬ値をとる。

「デッキ区分」は、該当レコードのポジションが上述の４つの下位デッキのいずれに属するのかを示す。

「ポジションＩＤ」は、デッキにおける各ポジションを一意に識別するための識別情報である。同種のポジションについても、互いに異なるポジションＩＤが付与されているので、各レコードが一意に識別可能である。「ポジション名」は、ポジションの名称を示す。名称によって、ユーザは、デッキ内の各ポジションを識別することができる。

「キャラクタＩＤ」は、選手またはマスコットに見立てたカードを一意に識別するための識別情報である。キャラクタＩＤは、ポジションＩＤと１対１で紐付けられる。これにより、デッキのポジションと、該ポジションを担うキャラクタとの対応関係が管理される。

「属性」は、該当レコードのポジションに就いたキャラクタの属性を示す。一例として、属性には、キャラクタ種別と所属球団とがある。「キャラクタ種別」は、キャラクタが選手の場合、ポジションに基づいて野手か投手かを分類するポジション種別を示し、キャラクタがマスコットの場合、雄か雌かの性別を示す。「所属球団」は、あらかじめ定められた球団（例えば、実在するプロ野球チーム、１２球団）のうち、キャラクタが所属している球団を示す。

「総合パラメータ」は、各キャラクタに設定されている総合パラメータを示す。該カラムに格納される総合パラメータの値は、該キャラクタに設定されている基本の値であり、該値が補正される時の補正値は、カラムを別にして管理される。

「マスコット効果補正」は、デッキにおけるマスコットの配置が所定の条件を満たすことに伴って補正される、各キャラクタの総合パラメータの補正値を示す。図５に示す例では、補正値「５０」は、１つ左のカラムに格納されている総合パラメータの基本の値に、５０が加算されることを示す。

なお、図５に示す例では、便宜上、マスコット雄を配置するための野手応援のポジションは、野手スタメンデッキに属し、マスコット雌を配置するための投手応援のポジションは、投手先発デッキに属するものとして管理されている。しかし、これに限らず、デッキ詳細情報において、第５の下位デッキ「マスコットデッキ」を生成し、そこにマスコット専用のポジションのレコードを設けてもよい。

図５に示すとおり、本実施形態における第２デッキのデッキ詳細情報は、さらに、「自球団効果補正」の項目を有する。「自球団効果補正」は、デッキにおけるキャラクタの配置が所定の条件を満たすまたは満たさないことに伴って補正される、各キャラクタの総合パラメータの補正値を示す。

本実施形態では、第２デッキは、ユーザの指定球団と同じ球団を所属球団とするキャラクタを多く配置するほど対戦が有利になるという性質を持つ。そこで、対戦進行部１１５は、第２デッキに、指定球団と同球団のキャラクタが配置されている場合には、該キャラクタの総合パラメータを上方に補正し、指定球団と異なる球団のキャラクタが配置されている場合には、該キャラクタの総合パラメータを下方に補正する。具体的には、図５の自球団効果補正の項目について、指定球団と同球団のキャラクタについては、総合パラメータ「＋１５０」の値を、異球団のキャラクタについては、総合パラメータ「−１５０」の値を各レコードに格納する。

ユーザの入力操作にしたがって、対戦進行部１１５が生成したデッキ詳細情報が記憶部１２０に保存されると、次に、対戦進行部１１５は、デッキ詳細情報に基づいて、デッキ概要情報を生成する。

（デッキ概要情報）
図６は、デッキ情報のうち、デッキ概要情報のデータ構造の一例を示す図である。図６に示すデッキ概要情報は、ユーザごとに生成され、ユーザが保有するデッキの種類ごとにレコードが登録される。

図６に示すとおり、デッキ概要情報は、一例として、デッキＩＤ、デッキ種別、総合パラメータ合計値、自球団度、加算値、および、デッキ総合パラメータの各項目を有する。デッキ概要情報のうち、第１デッキのレコードについては、自球団度の項目、および、加算値の項目の中のマスコットボーナスのサブ項目において、値はＮＵＬＬ値をとる。

「デッキＩＤ」は、ユーザが保有するデッキを一意に識別するための識別情報である。本実施形態では、性質の異なる２種類のデッキがユーザによって保有され、それぞれのデッキには、「Ｄ１」、「Ｄ２」のデッキＩＤが付与されている。

「デッキ種別」は、デッキの種別を示す。本実施形態では、Ｄ１は、第１デッキ、具体的には、キャラクタ優先デッキであり、Ｄ２は、第２デッキ、具体的には、自球団優先デッキである。

「総合パラメータ合計値」は、デッキに組み入れられている各キャラクタの補正後の総合パラメータを合計して得られた値を示す。補正後の総合パラメータとは、デッキに組み入れられているキャラクタに本来設定されている、基本の総合パラメータが、同じデッキに組み入れられているマスコットの効果に基づいて補正されたものである。

「自球団度」は、第２デッキにおいて、ユーザの指定球団と同じ球団に所属するキャラクタが配置されている割合を示す。本実施形態では、１つのデッキには、２７個のポジションが含まれている。したがって、自球団度は、ｎ／２７（ｎは、デッキに配置されている、指定球団と同じ所属球団のキャラクタの数）で表される。

「加算値」は、総合パラメータ合計値に対して、デッキの配置が所定の条件を満たした場合に臨時に加算される値を示す。一例として、加算値には、マスコットボーナスと選手ボーナスとがある。「マスコットボーナス」は、１または複数のマスコットの配置が所定の条件を満たした場合に加算される値を示す。本実施形態では、マスコットボーナスは、デッキ種別が、第２デッキである場合に発生する。したがって、第１デッキのマスコットボーナスはＮＵＬＬ値または「０」の値をとる。「選手ボーナス」は、１または複数の選手の配置が所定の条件を満たした場合に加算される値を示す。例えば、上述の自球団度が所定値以上を満足した場合に、加算される選手ボーナスがあってもよい。

「デッキ総合パラメータ」は、ユーザが保有するデッキの、対戦における総合的な強さを示す指標であり、デッキごとに付与されるものである。デッキ総合パラメータは、デッキに配置されている各キャラクタの補正後の総合パラメータに基づいて算出される。より具体的には、デッキ総合パラメータは、デッキに配置される各キャラクタの補正後の総合パラメータを合計した上述の総合パラメータ合計値と、マスコットが該デッキに組み入れられていることに基づいて加算される加算値（上述のマスコットボーナス）とを合計して算出される。したがって、デッキ内の各キャラクタの総合パラメータが高いほど、デッキ総合パラメータも高く算出される。本実施形態では、対戦進行部１１５は、ユーザのデッキのデッキ総合パラメータと、対戦相手のデッキのデッキ総合パラメータとを比較し、デッキ総合パラメータの値が上回った方に有利に対戦を進行させる。したがって、デッキ総合パラメータが高いほど、対戦に強いデッキであり、対戦に有利であると考えることができる。これにより、ユーザは、デッキ総合パラメータを高めることを目的として、総合パラメータが高いキャラクタを収集したり、加算値が多く得られるようにデッキの配置を工夫したりして、本ゲームをより一層楽しむことが可能となる。

図６に示すとおり、本実施形態における第２デッキのデッキ概要情報は、自球団度、および、マスコットボーナスの加算値の項目をさらに含む。

自球団度は、デッキのすべてのポジションのうち、指定球団と同じ球団に所属する選手が何人配置されているのかを示す。対戦進行部１１５は、自球団度が「所定閾値以上」との条件を満たした場合に、選手ボーナスを加算してもよい。

さらに、マスコットには、第２デッキに配置された場合に、選手に有利な効果をもたらすスキルが設定されている。そこで、対戦進行部１１５は、第２デッキに、ユーザの指定球団と同じ球団を所属球団とするマスコットが配置されている場合には、該マスコットのスキルを発動させて、第２デッキにおけるデッキ総合パラメータを大幅に上方に補正する。具体的には、対戦進行部１１５は、指定球団と同じマスコットが１体配置されるごとに、所定値のマスコットボーナスを加算してもよい。

これにより、ユーザは、自分のお気に入りの球団に所属するキャラクタを集めるように促され、また、とりわけ、自分のお気に入りの球団に所属するマスコットを獲得することを望むようになる。結果として、ユーザに対して、お気に入り球団のマスコットと、お気に入り球団所属の選手とを獲得する喜び、集める喜び、および、獲得したキャラクタを編成する楽しみをユーザに与えることができる。

（画面例）
図７は、ユーザ端末１００の表示部１５２に表示されるデッキ選択画面の一例を示す図である。デッキ選択画面４００は、ユーザが複数種類のデッキを保有できるゲームにおいて、編成したいデッキの種別をユーザが選択するための画面である。デッキ選択画面４００は、各種デッキの情報と、デッキを選択するためのＵＩとを含む。例えば、デッキ選択画面４００は、自球団優先デッキとしての第２デッキのステータス情報４０１、および、キャラクタ優先デッキとしての第１デッキのステータス情報４０２を含む。さらに、デッキ選択画面４００は、いずれのデッキを選択するのかをユーザが指定するためのＵＩとして、択一選択式のチェックボックス４０３および４０４を含む。

ステータス情報４０１は、図６に示すデッキ概要情報のうち、Ｄ２のレコードに基づいて生成される。ステータス情報４０１は、「自球団度」と、総合パラメータ合計値を示す「合計値」と、マスコットボーナスおよび選手ボーナスを合計した「加算値」と、該「合計値」と該「加算値」との和である「デッキ総合パラメータ」とを含む。

ステータス情報４０２は、図６に示すデッキ概要情報のうち、Ｄ１のレコードに基づいて生成される。ステータス情報４０２は、総合パラメータ合計値を示す「合計値」と、選手ボーナスを合計した「加算値」と、該「合計値」と該「加算値」との和である「デッキ総合パラメータ」とを含む。

ユーザは、上述の各デッキのステータス情報を確認しながら、チェックボックス４０３および４０４を操作して、編成したいデッキを選択する。なお、対戦進行部１１５は、図７に示すデッキ選択画面４００を、マッチング要求をサーバ２００に対して行う直前に表示し、対戦で使用するデッキをユーザに選択させてもよい。

図８は、デッキ編成画面のうち、野手を配置するための野手デッキ編成画面の一例を示す図である。野手デッキ編成画面５００は、一例として、野手スタメンデッキ５０１および野手ベンチデッキ５０２を含む。野手スタメンデッキ５０１は、投手を除く８つの守備ポジションのそれぞれに対応する枠Ｆ２〜Ｆ９と、指名打者のポジションに対応する枠Ｆ１０とを有する。さらに、本実施形態では、野手スタメンデッキ５０１は、野手応援のポジションに対応する枠Ｆ１を有する。野手ベンチデッキ５０２は、一例として、控えの野手のポジション５人分に相当する５つの枠を有してもよい。

図９は、デッキ編成画面のうち、投手を配置するための投手デッキ編成画面の一例を示す図である。投手デッキ編成画面５５０は、一例として、投手先発デッキ５５１および投手リリーフデッキ５５２を含む。投手先発デッキ５５１は、一例として、先発投手のポジション５人分に相当する５つの枠を有してもよい。投手リリーフデッキ５５２は、一例として、リリーフ投手のポジション６人分に相当する６つの枠を有してもよい。

本実施形態では、投手デッキ編成画面５５０は、さらに、投手応援のポジションに対応するマスコット表示枠Ｆ１６を含む。投手応援のポジションは、データ構造上、投手先発デッキ５５１に含まれているが、枠Ｆ１６は、図９に示すとおり、投手先発デッキ５５１の領域外に表示してもよい。

本実施形態では、対戦進行部１１５は、ポジションに対応するデッキ上の枠に、配置したキャラクタの情報を表示することが好ましい。例えば、枠の右上の数字は、配置されたキャラクタの総合パラメータを示す。該数字のさらに右には、上方向または下方向を示す矢印が必要に応じて表示される。上方向の矢印は、キャラクタに設定されている基本の総合パラメータが上方に補正されたことを示す。上方補正は、例えば、各キャラクタのデッキの配置が所定条件を満たしたことによりなされる。下方向の矢印はキャラクタに設定されている基本の総合パラメータが下方に補正されたことを示す。下方補正は、例えば、各キャラクタのデッキの配置が所定条件を満たさなかったことに対するペナルティとして課される。枠の左下のロゴは、配置されたキャラクタの所属球団を示す。その他、キャラクタの希少度、キャラクタ名などが枠周辺に表示されてもよい。

さらに、各デッキ編成画面は、デッキ総合パラメータ５０３を含んでいてもよい。デッキ総合パラメータについても上方または下方に補正されたことを示す矢印を付加してもよい。さらに、各デッキ編成画面は、現行のデッキの配置に基づいて発生しているマスコットボーナスおよび選手ボーナスの一覧表を呼び出すためのＵＩ５０４を含んでいてもよい。なお、本実施形態では、第１デッキには、自球団度のパラメータは設定されないので、図８および図９に示されたデッキ編成画面が、第１デッキの場合には、自球団度５０５は表示されない。

ユーザは、それぞれのデッキ編成画面を表示部１５２に表示させて、手持ちの所望のカードを、それぞれの枠に紐付けるための入力操作を入力部１５１を用いて行う。対戦進行部１１５は、上述の入力操作を操作受付部１１１を介して受け付け、枠とカードとの対応関係に基づいて、ポジションとキャラクタとの紐付けを行い、デッキ詳細情報を生成する。

（処理の流れ）
図１０は、ゲームシステム１がゲームプログラム１３１に基づいて実行するデッキ編成処理の流れを示すフローチャートである。以下では、図１０に示す各処理をユーザ端末１００が実行するものとして説明するが、その一部の処理をサーバ２００が実行してもよい。図１０に示す一連の処理は、図３に示すステップＳ１の処理に対応している。

ステップＳ１０１において、対戦進行部１１５は、例えば、図７に示すデッキ選択画面４００を表示部１５２に表示する。ユーザは、デッキ選択画面４００を操作して、上述の第１デッキおよび第２デッキのいずれを編成するのかを選択する。

ステップＳ１０２において、対戦進行部１１５は、いずれのデッキが選択されたのかを判断する。例えば、チェックボックス４０４にチェックを入れる操作を操作受付部１１１が受け付けた場合、対戦進行部１１５は、第１デッキが選択されたと判断し、ステップＳ１０２のＹＥＳからステップＳ１０３に進む。

ステップＳ１０３において、対戦進行部１１５は、ユーザによって選択された第１デッキを編成するためのデッキ編成画面を表示部１５２に表示する。対戦進行部１１５は、図８に示す野手デッキ編成画面５００と図９に示す投手デッキ編成画面５５０とを同時に表示部１５２の一画面に表示してもよいし、同図に示したとおり、「野手デッキ」と「投手デッキ」との切り替えボタンを設けて、各デッキ編成画面を切り替えて表示してもよい。

ステップＳ１０４において、対戦進行部１１５は、操作受付部１１１が受け付けたユーザの入力操作にしたがって、デッキを生成する。具体的には、ユーザが指定した枠とカードとの対応関係にしたがって、該枠が示すポジションと、該カードが示すキャラクタとを対応付ける。

ここで、対戦進行部１１５は、デッキ上のキャラクタの配置が特定の条件を満たすか否かに基づいて、デッキまたは該デッキに配置されている各キャラクタに関わるパラメータを上方または下方に補正してもよい。

第１デッキに関しては、対戦進行部１１５は、ユーザの指定球団を考慮しない。対戦進行部１１５は、デッキに配置されたマスコットに設定されている、マスコット効果にしたがって、各キャラクタの総合パラメータに所定の加算値を加算してもよい。

一方、ステップＳ１０２において、操作受付部１１１がチェックボックス４０３にチェックを入れる操作を受け付けた場合、対戦進行部１１５は、第２デッキが選択されたと判断して、ステップＳ１０２のＮＯからステップＳ１０５に進む。

ステップＳ１０５において、対戦進行部１１５は、ユーザによって選択された第２デッキを編成するためのデッキ編成画面を表示部１５２に表示する。

ステップＳ１０６において、対戦進行部１１５は、ステップＳ１０４のときと同様に、デッキを生成する。また、対戦進行部１１５は、デッキにマスコットが配置された場合には、該マスコットに設定されている、マスコット効果にしたがって、各キャラクタの総合パラメータに所定の加算値を加算してもよい。

さらに、第２デッキに関して、対戦進行部１１５は、ユーザの指定球団を考慮したパラメータの補正を、例えば、以下のようにして行う。

ステップＳ１０７において、対戦進行部１１５は、ユーザの指定球団と同じ球団のキャラクタの総合パラメータを上方に補正する。

ステップＳ１０８において、対戦進行部１１５は、ユーザの指定球団と異なる球団のキャラクタの総合パラメータを下方に補正する。

ステップＳ１０９において、対戦進行部１１５は、第２デッキにおける、ユーザの指定球団と同じ球団のキャラクタの数に基づいて、自球団度を決定する。対戦進行部１１５は、ステップＳ１０７〜Ｓ１０９を任意の順序で実行することができる。

ステップＳ１１０において、対戦進行部１１５は、総合パラメータ合計値を算出する。本実施形態では、対戦進行部１１５は、上述のとおり、キャラクタ個別の補正後の総合パラメータを単純に合計することにより、総合パラメータ合計値を算出する。

ステップＳ１１１において、対戦進行部１１５は、デッキにおけるキャラクタの配置に基づいて、ボーナスを適用して、上述の総合パラメータ合計値に加算することができる加算値を算出する。本実施形態の第１デッキでは、マスコットボーナスは発生しない。したがって、対戦進行部１１５は、ユーザが編成した配置が、選手ボーナスの条件を満たしている場合には、該選手ボーナスに対応する加算値を算出する。デッキの配置が複数の選手ボーナスの条件を満たした場合には、対戦進行部１１５は、各選手ボーナスの加算値を合計して最終的な加算値を算出する。本実施形態の第２デッキでは、さらに、対戦進行部１１５は、ユーザの指定球団と同じ球団のマスコットが配置されている場合には、該マスコットのマスコットスキルを発動し、総合パラメータ合計値に対して加算すべき加算値（マスコットボーナス）を算出してもよい。例えば、雌雄計２体のマスコットが配置されており、それぞれのマスコットが、「デッキ総合パラメータを１０００アップする」というマスコットスキルを有している場合を想定する。この場合、対戦進行部１１５は、１０００×２＝２０００を、マスコットボーナスとして算出する。対戦進行部１１５は、上述のように算出したマスコットボーナスと、選手ボーナスとを合わせて、第２デッキにおける加算値を算出する。

ステップＳ１１２において、対戦進行部１１５は、デッキ総合パラメータを算出する。本実施形態では、対戦進行部１１５は、ステップＳ１１０で求めた総合パラメータ合計値に、ステップＳ１１１で求めた加算値を足すことにより、デッキ総合パラメータを求める。

ステップＳ１１３において、対戦進行部１１５は、ステップＳ１０４またはＳ１０６にて対応関係が変更された後のデッキを示すデッキ編成画面を表示部１５２に表示する。このとき、対戦進行部１１５は、対戦で比較に用いられる値（例えば、デッキ総合パラメータまたは各キャラクタの個別の総合パラメータ）が、デッキにマスコットが組み入れられたことに応じて上方に補正されたことをユーザに通知する情報を表示することが好ましい。例えば、対戦進行部１１５は、値の右横に、上方に補正されたことを示す上向きの矢印を付与してもよい。これにより、ユーザは、マスコットをデッキに配置することによって得られる効果を直感的に理解することが可能となる。

ステップＳ１１４において、操作受付部１１１が、変更後のデッキの内容を確定させるための操作入力をユーザから受け付ける。例えば、野手デッキ編成画面５００および投手デッキ編成画面５５０の右下に配置された保存ボタンに対するタッチ操作を操作受付部１１１が受け付ける。この場合、対戦進行部１１５は、ステップＳ１１４のＹＥＳからステップＳ１１５に進む。

ステップＳ１１５において、対戦進行部１１５は、ゲーム情報１３２として記憶部１２０に記憶されているデッキ情報を更新する。具体的には、対戦進行部１１５は、図５に示すデッキ詳細情報と図６に示すデッキ概要情報とを更新する。

＜メイン対戦ゲームから第１のカード獲得処理まで＞
図１１〜図２３を参照して、ユーザ端末１００およびサーバ２００の少なくともいずれか一方が実施するメイン対戦ゲームおよび第１のカード獲得処理の詳細について説明する。

（マッチングについて）
本実施形態では、メイン対戦ゲームは、基本的に、通信対人対戦を前提としている。したがって、ユーザのチームが対戦する相手、すなわち、相手チームは、サーバ２００によってマッチングにより決定される。本実施形態では、相手チームのマッチングは、サーバ２００の対戦支援部２１１によって実行される。本実施形態では、相手チームは、他のユーザによって編成されたチームの中から探索される。対人対戦のための適当な相手チームが探索されなかった場合には、対戦支援部２１１は、ゲームプログラム１３１にしたがって動作するキャラクタから構成されたチームを生成し、あるいは、事前に用意しておき、当該チームを相手チームとして、ユーザのチームにマッチングさせる。したがって、メイン対戦ゲームは、他のユーザによる相手チームが探索されなかった場合に、コンピュータ対戦になることもあり得る。本実施形態では、対戦支援部２１１は、ユーザに付与されているレーティング（評価値）に基づいて、適当な相手チームを探索する。

レーティングとは、対戦におけるユーザの強さを表す指標である。レーティングは、所定の演算式に基づき、対戦の結果（具体的には、勝敗）、および、対戦前の自分のレーティングと相手のレーティングとの差分に基づいて更新される。相手のレーティングとは、他のユーザであれば該他のユーザに付与されているレーティング、相手がコンピュータである場合には、該コンピュータに仮想的に設定されているレーティングを指す。

レーティングの算出および更新の処理は、サーバ２００の対戦支援部２１１が実行してもよいし、ユーザ端末１００（クライアント、コンピュータ）の対戦進行部１１５が実行してもよい。いずれにしても、ユーザに付与されている最新のレーティングは、サーバ２００とユーザ端末１００との間で共有されている。

以下では、一例として、ユーザに付与されているレーティングの更新は、サーバ２００によって行われるものとして説明する。

対戦支援部２１１は、対戦相手をマッチングするために参照するレーティングをユーザごとに管理する。対戦支援部２１１は、例えば、マッチングにより対戦をプレイしたユーザについて、対戦前のユーザと相手とのレーティングの差分値と、対戦の勝敗とに基づいて、対戦後のユーザのレーティングを更新する。

対戦支援部２１１は、例えば、初期値として値「１５００」を各ユーザに設定する。ユーザＸとユーザＹとが対戦し、ユーザＸが勝利し、ユーザＹが敗北した場合に、以下の式１および式２に従って、対戦後のレーティングが更新される。

〔式１〕 対戦後の勝利側のユーザ（ユーザＸ）のレーティング ＝ 勝利側のユーザ（ユーザＸ）の対戦前のレーティング ＋ ３２ ＋ （敗北した側（ユーザＹ）のレーティング − 勝利した側（ユーザＸ）のレーティング）×０．０４
〔式２〕 対戦後の敗北側のユーザ（ユーザＹ）のレーティング ＝ 敗北側のユーザ（ユーザＹ）の対戦前のレーティング − ３２ ＋ （敗北した側（ユーザＹ）のレーティング − 勝利した側（ユーザＸ）のレーティング）×０．０４
対戦前後において変動するレーティングに幅（上限値および下限値）を設けてもよい。例えば、変動するレーティングの幅として、最大値「６４」、最小値「４」などと設定してもよい。対戦するユーザ間のレーティングの差が過度に大きい場合、式１または式２に従ってレーティングを計算すると、レーティングが高い方のユーザが、勝利したにもかかわらずレーティングが減少し、勝利したユーザが納得できないという事態が生じ得る。そこで、対戦前のレーティングから変動する幅に最大値および最小値を設定することで、そのような事態を回避し、ユーザの納得感を向上させることができる。

上述のとおり、本実施形態では、対戦相手を探索するために、ユーザのレーティングが参照される。そのため、ユーザは、自身のレーティングを上げれば上げるほど、レーティングの高い、すなわち、強い相手と戦いやすくなる。本実施形態によれば、この仕組みを利用することにより、対戦をプレイすることのユーザの動機付けを維持できる。さらには、強い相手と対戦することの動機付けを強化できる。

本実施形態では、ユーザ端末１００は、ユーザから、メイン対戦ゲームを開始する指示を受け付けると、サーバ２００に対して、マッチングを実施するように要求する。サーバ２００の対戦支援部２１１は、マッチングを実施して、マッチングの結果をユーザ端末１００に返信する。

図１１は、マッチングが成立したときにユーザ端末１００の表示部１５２に表示されるマッチング成立画面の一例を示す図である。マッチング成立画面６００は、マッチングが成立した旨の結果をユーザに通知するとともに、その対戦相手の情報を対戦開始前にユーザに提供するためのゲーム画面である。

マッチング成立画面６００は、一例として、ユーザ本人のユーザ名６０１、対戦相手のユーザ名６０２、ユーザ本人のレーティング６０３、および、対戦相手のレーティング６０４を含んでいる。

マッチング成立画面６００は、さらに、ユーザ本人および対戦相手のデッキの種別を示す情報を含んでいてもよい。本実施形態では、一例として、ユーザまたは対戦相手のデッキが、第２デッキにより編成されている場合、対戦進行部１１５は、そのことを示す球団ロゴ６０５を、マッチング成立画面６００に表示させる。本ゲームでは、指定できる球団ごとに球団ロゴが対応付けられており、ロゴにより、球団が識別できるようになっている。図１０に示す例では、球団ロゴ６０５がユーザの情報を表示する領域に付与されていることにより、ユーザのデッキとして、「鳥取サーモンズ」を指定球団とする第２デッキ（自球団優先デッキ）が採用されていることがユーザと対戦相手とによって認識される。一方、対戦相手が第１デッキを採用している場合には、対戦相手の情報を表示する領域にロゴが付与されない。これにより、対戦相手が第１デッキを採用していることをユーザは認識することができる。

なお、他のユーザとのマッチングが成立せず、相手チームがコンピュータの制御下で動作するチームである場合には、対戦相手のユーザ名６０２において、対戦相手がコンピュータであることが分かる表示を行うことが好ましい。

（メイン対戦ゲームの構成）
マッチングが成立すると、ユーザ端末１００は、メイン対戦ゲームの進行を開始する。本実施形態で実行されるメイン対戦ゲームの構成について、図１２に基づいて説明する。図１２は、本実施形態に係るゲームシステム１において、ゲームプログラム１３１に基づいて進行される対戦を模式的に示す図である。本実施形態に係るメイン対戦ゲームの対戦は、以下の要素で構成される。そして、各要素は、サーバ２００の制御部２１０、および、ユーザ端末１００の制御部１１０の少なくともいずれか一方によって進行される。

以下では、ユーザのユーザ端末１００によって編成されたチームを自チーム、対戦相手のユーザのユーザ端末１００によって編成されたチームまたはゲームプログラム１３１に基づいて自動で編成されたチームを相手チームと称する。

図１２に示すとおり、対戦進行部１１５によって進行される対戦は、複数のイニングで構成され、１イニングにつき、表と裏でチームの攻守を入れ替え、各チームが１回ずつ守備と攻撃とを実行して、対戦が進行する。１イニングの表および裏のそれぞれは、複数の打席で構成され、攻撃側のキャラクタ１名につき１つの打席が対応付けられる。１つの打席は、守備側（投球側）のキャラクタと、攻撃側（打撃側）のキャラクタとが１対１で対決する対決要素と、対決の結果を決定し、出力させて、該打席を完了させる結果出力要素とで構成される。

対決要素は、さらに複数のフェーズに区切られる。フェーズは、対決する各キャラクタが、守備動作および攻撃動作のいずれか一方を、それぞれ所定回数行う期間である。１のフェーズにおいて、守備側のキャラクタ、および、攻撃側のキャラクタのそれぞれが動作を行う回数は、予め定められている。しかし、その回数は、ゲームの題材となる競技に基づいて任意に定められればよい。また、守備側と攻撃側とで、動作回数は同じに定められてもよいし、異なっていても構わない。本実施形態では、一例として、１のフェーズにおいて、守備側のキャラクタが守備動作を１回、攻撃側のキャラクタが攻撃動作を１回行うと定められているものとする。

フェーズは、いわば、対戦を構成する要素の最小単位であり、野球ゲームにおいては、投手が投げる１球に相当する。各フェーズにおいて、守備側のキャラクタによって、１つの守備動作（投球動作）が実行され、攻撃側のキャラクタによって１つの攻撃動作（打撃動作）が実行されると、１つのフェーズが完了し、次のフェーズへ移行する。

いくつかのフェーズの進行を経て、結果出力要素において、当該打席の結果（アウトまたは進塁等）が決定する。これにより、１つの打席が完了し、次の打席へ移行する。いくつかの打席を経て、１イニングの表（または裏）において、３つのアウトが累積されると、１つのイニングの表（または裏）が完了し、攻守が入れ替わって、同イニングの裏（または次のイニング）へ移行する。

本実施形態において、対戦を構成する各要素のうち、結果出力要素は、主に、各コンピュータ（サーバ２００、および、ユーザ端末１００）が読み出すゲームプログラムにしたがって、すなわちオート制御によって進行してもよい。

一方、対決要素の全フェーズは、ユーザが入力部１５１を介して実施する操作に基づいて、すなわち、マニュアル制御によって進行させることができる。守備動作および攻撃動作が１度ずつ行われる各フェーズは、対戦の勝敗を左右する重要な要素であり、対戦の大部分を占める要素である。したがって、ユーザの操作の巧拙が対戦の勝敗に大きな影響を与え、うまく操作したユーザが対戦を有利に進めることができる。

とりわけ、本実施形態では、ユーザは、フェーズごとに（一球ごとに）、希望する制御方法を切り替えることができる。本実施形態では、ユーザ端末１００は、制御方法の切り替え指示を随時ユーザから受け付け、受け付け直後に訪れるフェーズの開始時点で、指示された制御方法に設定する。例えば、ユーザは、ある一球については、ユーザが自身で投球操作を行って、投手キャラクタに投球動作（守備動作）を行わせ、次の一球については、サーバ２００の制御下で、自動で投手キャラクタに投球動作を行わせるというように、プレイすることが可能である。

上述のプレイ形態によれば、ユーザに対して、全フェーズに介入できる（マニュアル制御に設定する）権利が与えられる。したがって、全フェーズまたは一部のフェーズがオート制御であったがゆえに対戦に負けたのだとしても、ユーザ自身が介入する権利を放棄したことに起因する敗北であるとユーザは認識し、対戦結果に納得することができる。

以上のことから、対戦の各要素を自動で進行させる機能を備えつつも、全フェーズに介入できる権利をユーザに提供することで、対戦結果に対するユーザの納得感が損なわれないゲームを実現することができる。

以下では、上述のオート制御によって対戦を進行させることをオート進行モードと称し、上述のマニュアル制御によって対戦を進行させることをマニュアル進行モードと称する。

（メイン対戦ゲームにおける画面例）
図１３〜図１６は、ユーザ端末１００が、メイン対戦ゲームを進行しているときに、表示部１５２に表示させるゲーム画面の一例を示す図である。図１３〜図１６に示すゲーム画面は、メイン対戦ゲームがマニュアル進行モードで進行するときに対戦進行部１１５が表示部１５２に表示させる対戦画面の一例である。

図１３〜図１５は、対戦画面のうち、自チームの守備回において表示される投球画面７００を示す。投球画面７００は、ユーザが投手のポジションに紐付けた投手７０３の投球動作を決定するための投球操作ＵＩを含む。投球操作ＵＩは、投球側ユーザによる投球操作を受け付けるためＵＩである。

本実施形態において、投球結果Ｄ１を決定するための投球操作には、一例として、球種を指定するためのスライド操作と、コースを指定するためのドラッグ操作と、制球の良否を決定するためのタイミングを投球側ユーザに指定させるタップ操作とが含まれる。タップ操作の入力タイミングの良否に応じて、投球の良否が決定される。つまり、投球側ユーザにとって、対戦、特に、守備の回を有利に進めることができるか否かは、マニュアル進行モードの場合、タップ操作の巧拙にかかっている。

１つのフェーズ（１回の投球動作と、１回の見逃しも含む打撃動作とが実施される期間）が開始されると、投球側ユーザ端末の対戦進行部１１５は、まず、図１３に示す第１の投球画面７００を、ＵＩ制御部１１３に生成させて、表示部１５２に表示させる。

第１の投球画面７００は、仮想空間に配置されている各種オブジェクトを含む。具体的には、相手チームの打者７０１、バット７０２、ユーザ自身が操作する投手７０３、ホームベース７０７、および、捕手７０５を含む。

第１の投球画面７００は、次のフェーズをオート進行モードまたはマニュアル進行モードに切り替えるための切替ボタン７１３を含んでいてもよい。図１３に示す例では、該フェーズは、マニュアル進行モードにて進行している。そのため、切替ボタン７１３は、次のフェーズをオート進行モードに切り替えるためのボタンとして投球画面７００に重畳表示されている。

第１の投球画面７００は、該フェーズにおいて対決中の各選手のステータス情報を含んでいてもよい。一例として、自チームの投手のステータス情報７１１と、相手チームの打者のステータス情報７１２とを含んでいてもよい。

第１の投球画面７００は、投球操作を支援するＵＩオブジェクトとして、投手７０３に投げさせる球種を投球側ユーザが指定するための球種指定オブジェクト７１０を含んでいてもよい。

対戦進行部１１５は、球種指定オブジェクト７１０に対するユーザのスライド操作に基づいて、球種を決定する。図１３に示すとおり、球種指定オブジェクト７１０において、ボールアイコンの周囲を囲うように、球種が１対１で対応付けられた球種アイコンが配置されている。球種アイコンは、対応付けられている球種を示すテキストまたはイラストなどを含んでいる。ＵＩ制御部１１３は、球種指定オブジェクト７１０において一覧される球種の種類を、投手７０３の能力に基づいて異ならせてもよい。

操作受付部１１１は、ボールアイコンに対する所定方向のスライド操作を、球種を指定するための操作として受け付ける。対戦進行部１１５は、スライド操作の方向に配置されている球種アイコンに対応する球種を、投手７０３に投げさせる球種として決定する。例えば、図１３に示す例では、ユーザがボールアイコンを上方向にスライドさせた場合、対戦進行部１１５は、投手７０３にストレートを投げさせると決定する。球種にはボール７０４の移動経路、球速等を特定するためのパラメータが対応付けられている。球種のパラメータは、球速、変化量、および変化の方向を示す情報を含む。また、球種のパラメータは、投手７０３の識別情報に対応付けられて、記憶部１２０に記憶されている（不図示）。対戦進行部１１５は、投手７０３の識別情報に対応付けられた球種のパラメータのうち、決定した球種のパラメータを記憶部１２０から読み出し、投球結果Ｄ１に含める。

球種が決定されると、次に、対戦進行部１１５は、図１４に示す第２の投球画面７００を表示部１５２に表示させる。第２の投球画面７００は、球種指定オブジェクト７１０に代えて、コース指定オブジェクト７１４を含む。コース指定オブジェクト７１４は、カーソル７１５と組み合わせて、投球側ユーザに、投手７０３に投げさせるコース（内角高め、低めなど）を指定させるためのＵＩオブジェクトとして機能する。

コース指定オブジェクト７１４は、一例として、ストライクゾーンに対応する矩形を９つのマスに分割したものである。各マスは、投手７０３の能力、具体的には、得意なコースおよび不得意なコースに基づいて、色分けして表示されてもよい。

コース指定オブジェクト７１４は、投げられたボールの到達予定位置を示す標識であるカーソル７１５を含む。第２の投球画面７００が表示されている間、操作受付部１１１は、カーソル７１５の位置を指定するためのドラッグ操作を受け付ける。操作受付部１１１がカーソル７１５を移動させるためのドラッグ操作を受け付けると、ＵＩ制御部１１３は、該ドラッグ操作に関して検出されたタッチ位置に基づいて、カーソル７１５を移動させる。

操作受付部１１１は、タッチスクリーン１５に対するユーザの最初の接触位置（初期タッチ座標）と、カーソル移動操作後の接触位置（タッチナウ座標）とを取得する。ＵＩ制御部１１３は、取得された各座標を比較した結果得られた変化方向、および、変化量に基づいて、カーソル７１５の位置の変化方向、および、変化量をそれぞれ決定する。これにより、ＵＩ制御部１１３は、カーソル７１５が直接タッチされなくても、また、コース指定オブジェクト７１４の表示領域外でドラッグ操作が受け付けられても、該ドラッグ操作に連動して、カーソル７１５を移動させることができる。このようにすれば、ユーザの指によってカーソル７１５の視認が妨げられることを回避できる。表示制御部１１２は、ＵＩ制御部１１３によって実行されているカーソル７１５の移動に連動して、移動するカーソル７１５を第２の投球画面７００上に表示させる。

対戦進行部１１５は、コースの確定を、任意の方法で行う。例えば、ユーザが上述のドラッグ操作に基づく接触が維持された状態で、所定閾値以上の圧力で強く押し込む操作を続けて行ったとする。対戦進行部１１５は、押し込む操作が受け付けられた時点におけるカーソル７１５の位置を、最終的なコースとして確定させる。あるいは、「コース確定」などのボタン（不図示）が別途、第２の投球画面７００に設けられてもよい。対戦進行部１１５は、該ボタンがタップ操作されたときのカーソル７１５の位置に基づいてコースを確定させてもよい。

コースが確定すると、次に、対戦進行部１１５は、図１５に示す第３の投球画面７００を表示部１５２に表示させる。第３の投球画面７００は、良否判定オブジェクト７２０を含む。良否判定オブジェクト７２０は、投手７０３の制球の良否を決定するためのタイミングを投球側ユーザに指定させるためのＵＩオブジェクトとして機能する。

一例として、良否判定オブジェクト７２０は、弓形の帯状のゲージで構成される。良否判定オブジェクト７２０は、該ゲージ内に、帯の長手方向にスライドするスライドバー７２１と、スライドバー７２１が停止する帯上の位置を定義する第１領域７２２および第２領域７２３とを含む。

該帯状のゲージは、投手７０３の位置（以下、第１位置）から、捕手７０５の位置（以下、第２位置）に向かって伸びている。

ＵＩ制御部１１３は、スライドバー７２１を、初期位置である第１位置（例えば、図１５の破線枠）から、最終位置である第２位置（例えば、図１５のカーソル７１５の位置）に向かって、帯の長手方向（矢印の方向）に移動させる。アニメーション生成部１１４は、スライドバー７２１が、移動の開始から所定時間後に第２領域７２３を通過し、第１領域７２２を通過して、最終的にカーソル７１５の位置に到達するように、アニメーションを生成する。

ユーザは、スライドバー７２１が帯上の所望の位置に到達した時、その位置でスライドバー７２１を停止させるよう、タッチスクリーン１５に対してタップ操作を行う。ＵＩ制御部１１３は、操作受付部１１１によってタップ操作が受け付けられた時の位置にて、スライドバー７２１を停止させる。対戦進行部１１５は、スライドバー７２１の停止位置に応じて、制球の良否を判定する。一例として、本実施形態では、対戦進行部１１５は、スライドバー７２１が第１領域７２２で停止した場合に、投手７０３が制球に完全に成功したと判定し、スライドバー７２１が第２領域７２３で停止した場合、成功に近い投球がなされたと判定し、それ以外の領域で停止した場合に、制球に失敗したと判定する。ここで、「制球に完全に成功した」とは、投手７０３が好投し、投球側ユーザによって指定された球種およびコースどおりに該ボールが仮想空間上を移動することを意味する。「成功に近い投球がなされた」とは、投球側ユーザによって指定された球種およびコースどおりにとはいかないが、それに近い球種およびコースに基づいて該ボールが仮想空間上を移動することを意味する。「制球に失敗した」とは、投手７０３が失投し、投球側ユーザによって指定された球種およびコースとはかけ離れた球種およびコースにて、該ボールが仮想空間上を移動することを意味する。

制球の良否が判定されると、次に、対戦進行部１１５は、図示しない第４の投球画面７００を表示部１５２に表示させる。第４の投球画面７００は、良否判定結果を含む。また、第４の投球画面７００においては、投手７０３が投球を開始するアニメーションが付与され、これまで投手７０３のグローブに収まっていたボール７０４が描出されてもよい。これにより、投球側ユーザは、第３の投球画面７００に対して行った自身の操作に関して、フィードバックを即時に受け取ることができる。

なお、良否判定オブジェクト７２０の帯状のゲージは、弓、アーチなど形状を有し、投げられたボールが描く放物線を模していることが好ましい。また、良否判定オブジェクト７２０の帯の幅は、第１位置から第２位置へ移動するにつれて、細くなるように定められていることが好ましい。また、該ゲージにおいて、第２位置に最も近く、最も帯の幅が細くなっている部分、すなわち、ゲージの先端が、ボールの到達予定位置として確定したカーソル７１５に重なるように、良否判定オブジェクト７２０が配置されることが好ましい。これにより、ユーザは、直観的に、帯状のゲージを、投手７０３から投げられたボールが、画面奥に配置されている捕手７０５に向かって移動する経路であるかのように理解する。以上のことから、本実施形態に係る良否判定オブジェクト７２０は、現実の野球を再現するという目的に反して、ゲームの興趣性を高める目的で追加されたＵＩでありながら、投球画面７００を現実の投球シーンから乖離させることなく、見た目に違和感のない投球シーンを演出することに貢献している。

以上のように、投球側ユーザの投球側ユーザ端末において、対戦進行部１１５は、投球側ユーザの投球操作に基づいて、投手７０３の投球動作を決定する。決定した投球動作を示す投球結果Ｄ１は、サーバ２００を介して対戦相手の他のユーザのユーザ端末１００に供給される。

図１６は、対戦画面のうち、自チームの攻撃回において表示される打撃画面７５０を示す。打撃画面７５０は、ユーザが野手のポジションに紐付けた打者７０１の打撃動作を決定するための打撃操作ＵＩを含む。打撃操作ＵＩは、打撃側ユーザによる打撃操作を受け付けるためのＵＩである。

１つのフェーズが開始され、相手チームの投手７０３の投球動作が進行すると、それに応じて投球側ユーザ端末またはサーバ２００にて生成された投球結果Ｄ１が、打撃側ユーザ端末に供給される。打撃側ユーザ端末が、投球結果Ｄ１を受信すると、打撃側ユーザ端末の対戦進行部１１５は、例えば、図１６に示す打撃画面７５０を、ＵＩ制御部１１３に生成させて、表示部１５２に表示させる。

対戦進行部１１５は、仮想空間としての球場における第１位置と第２位置との間に、ホームベース７０７を配置する。対戦進行部１１５は、ホームベース７０７上に、第１位置から第２位置に向かう方向に交差する方向に延在する交差面を設定する。対戦進行部１１５は、交差面に基づいて、打者７０１がボール７０４を打撃したか否かを判定する。上述したとおり、交差面は、例えば、ストライクゾーン７５１と、該ストライクゾーン７５１の外側に配置されるボールゾーン７５２とを含んでいてもよい。

操作受付部１１１が、投手７０３が投球したボール７０４が交差面に到達したタイミングで、ユーザからスイングのタイミングを指定する操作を受け付けると、打者７０１は、バット７０２をスイングすることによって、ボール７０４を打ち返す作用をボール７０４に与えることができる。図１６に示すボール７０４は、投手７０３によって投球された後、交差面に向かって移動している途中のボール７０４の一例を示す。

図１６に示すとおり、打撃画面７５０は、上述の他にも、各種オブジェクトを含んでいてもよい。特に、ユーザの打撃操作を支援するためのＵＩオブジェクトを含んでいることが好ましい。打撃操作を支援するＵＩオブジェクトとしては、例えば、タイミングヒントオブジェクト７５３、ミートカーソル７５４、位置ヒントオブジェクト７５５、方向ヒントオブジェクト７５６等がある。

タイミングヒントオブジェクト７５３は、打者７０１にバット７０２をスイングさせる良好なタイミングをユーザに示す。ミートカーソル７５４は、バット７０２がスイングされた際に交差面においてボール７０４に作用を与え得る領域として、スイングされたバット７０２の到達予定位置をユーザに示す。また、ミートカーソル７５４は、バット７０２とボール７０４との当たりを判定するために、対戦進行部１１５によって参照される領域でもある。位置ヒントオブジェクト７５５は、投手７０３によって投げられたボール７０４の、交差面における到達予定位置をユーザに示す。方向ヒントオブジェクト７５６は、投げられたボール７０４の進行方向の変化をユーザに示す。

本実施形態において、打撃結果Ｄ２を決定するための打撃操作には、一例として、ミートカーソル７５４の位置を指定するためのスライド操作と、決定したミートカーソル７５４の位置に向けてバット７０２を振るタイミングを指定するためのフリック操作とが含まれる。つまり、スライド操作が、投球に対して打撃を行う位置を指定する操作であり、フリック操作が、打撃を行うタイミング、つまりバット７０２を振るタイミングを指定する操作である。つまり、打撃側ユーザにとって、対戦、特に、攻撃の回を有利に進めることができるか否かは、マニュアル進行モードの場合、スライド操作とフリック操作との両方の巧拙にかかっている。

投手７０３からボール７０４が投げられると、打撃画面７５０において、操作受付部１１１は、上述の打撃操作を待機する状態に遷移する。操作受付部１１１が、タッチスクリーン１５に対するユーザのスライド操作を受け付けると、該スライド操作にしたがって、ＵＩ制御部１１３は、ミートカーソル７５４を移動させる。なお、ユーザは、ミートカーソル７５４のベストの位置を、位置ヒントオブジェクト７５５を参考にして決定してもよい。

続いて、対戦進行部１１５は、投手７０３より投げられたボール７０４が交差面を基準とする所定の範囲内に到達したか否かを判定する。つまり、投げられたボール７０４が、ホームベース７０７上に設定された交差面に所定距離未満まで近づいてきたか否かを判定する。ボール７０４が交差面から所定距離未満まで到達したと判定された場合、ＵＩ制御部１１３は、ミートカーソル７５４の移動の少なくとも一部を制限してもよい。移動が制限されたことを示すように、ＵＩ制御部１１３はミートカーソル７５４の色または模様などの表示態様を変化させてもよい。

打撃画面７５０において、投げられたボール７０４には、ストライクゾーン７５１に向かって移動してくるアニメーションが、アニメーション生成部１１４によって付与される。ユーザは、移動してくるボール７０４を目で追い、ボール７０４がホームベース７０７上に到達したと思うベストのタイミングで、打者７０１が行うスイングの開始タイミングを指定するためにフリック操作を行うことができる。

ユーザは、フリック操作のベストのタイミングを計るために、さらに、タイミングヒントオブジェクト７５３を参考にすることができる。タイミングヒントオブジェクト７５３は、ボール７０４の投球が開始されたときから表示が開始され、ボール７０４がホームベース７０７上の交差面に近づくにつれてボール７０４の中心に向かって収縮するようなアニメーションが、アニメーション生成部１１４によって付与されている。さらに、該アニメーションは、ボール７０４が交差面に到達したタイミングで、ちょうどボール７０４の輪郭と同じ大きさにまで縮小するアニメーションである。ユーザは、タイミングヒントオブジェクト７５３の大きさを確認することにより、良好な打撃結果が得られるベストタイミングを計ることができる。

操作受付部１１１がフリック操作を受け付けると、対戦進行部１１５は、その時の交差面におけるボール７０４とミートカーソル７５４との位置関係に少なくとも基づいて、打者７０１がボール７０４に打撃を与えたか否かを判定する。つまり、ユーザのスライド操作とフリック操作とに基づいて、打者７０１によってスイングされたバット７０２が、ボール７０４に当たったか否かを判定する。例えば、交差面においてボール７０４がミートカーソル７５４と少なくとも部分的に重畳している場合には、打者７０１がボール７０４を打撃したと判定してもよい。

さらに、対戦進行部１１５は、操作受付部１１１が特定したフリック操作のタイミングに基づいて、打撃を与えたか否かの判定を実行してもよい。例えば、交差面におけるボール７０４およびミートカーソル７５４が打撃に適合した位置関係にある場合であっても、フリック操作のタイミングがボール７０４への打撃に適合したタイミングに対して、早過ぎたり遅すぎたりする場合には、対戦進行部１１５は、打者７０１がボール７０４を打撃しなかったと判定してもよい。

また、対戦進行部１１５は、上述の位置関係に少なくとも基づいて、打撃が与えられたボール７０４が仮想空間において移動する際の移動経路を算出する。具体的には、対戦進行部１１５は、上述の位置関係に基づいて、バット７０２とボール７０４との衝突を力学的にモデル化する。この場合、バット７０２に衝突した直後のボール７０４の速度ベクトル、回転軸、回転量等を、ボール７０４を移動させるための初期条件として取得すればよい。例えば、ボール７０４の下部をミートカーソル７５４の上部で打撃した場合には、打球の角度が上がりフライとなる。また、ボール７０４の上部をミートカーソル７５４の下部で打撃した場合には、打球の角度が下がりゴロとなる。また、例えば、対戦進行部１１５は、ミートカーソル７５４の中央の位置（図１６の芯７５７）でボール７０４の中央を打撃する等の所謂ジャストミートの場合には、ライナーでボール７０４が飛ぶような移動経路を算出する。一方、ジャストミート以外の場合には凡打と判定して、凡打に対応する移動経路を算出してもよい。なお、対戦進行部１１５は、ボール７０４の速度ベクトル（初速など）、回転軸、回転量等を決定する際、打者７０１に設定されているスキル別身体パラメータ、特に、命中力および打撃力等を参照してもよい。

対戦進行部１１５が算出した移動経路にしたがって、アニメーション生成部１１４は、算出された移動経路を飛んでいくボール７０４のアニメーションを生成する。表示制御部１１２は、生成された、飛翔するボール７０４のアニメーションを、表示部１５２に表示する。

以上のように、打撃側ユーザの打撃側ユーザ端末において、対戦進行部１１５は、打撃側ユーザの打撃操作に基づいて、打者７０１の打撃動作を決定する。決定した打撃動作を示す打撃結果Ｄ２は、サーバ２００を介して、対戦相手の他のユーザのユーザ端末１００に供給される。

打撃結果Ｄ２に基づいて算出された移動経路にしたがって、ボール７０４が仮想空間内のフィールド上に移動した後は、各ユーザのユーザ端末１００の対戦進行部１１５は、ゲームプログラム１３１にしたがって、仮想空間における、ボール７０４の移動、守備をする野手の動き、および、進塁する走者の動きなどをそれぞれ計算する。そして、計算結果に基づいて、仮想空間において各オブジェクトを移動させ、フィールドプレイシーンを進行させる。ＵＩ制御部１１３およびアニメーション生成部１１４は、計算されたフィールドプレイシーンに対応する画像またはアニメーションを生成して、表示部１５２に表示させてもよい。

なお、対戦進行部１１５は、打者７０１がボール７０４に打撃を与えなかったと判定した場合には、ボール７０４の移動経路の算出を省略してもよい。この場合、打者７０１がボール７０４を空振りするアニメーションがアニメーション生成部１１４によって生成され、該アニメーションが表示制御部１１２によって表示部１５２に表示される。

打撃画面７５０は、進行しているフェーズにおいて対決中の各キャラクタのステータス情報を含んでいてもよい。一例として、自チームの打者７０１のステータス情報７５８と、相手チームの投手７０３のステータス情報７５９とを含んでいてもよい。

（第１のカード獲得処理における画面例）
図３に示すとおり、メイン対戦ゲームが終了すると、次に、ゲームシステム１は、第１のカード獲得処理を実行する。具体的には、まずは、ゲームシステム１は、ユーザがメイン対戦ゲームをプレイしたことに対する報酬を該ユーザに付与する。本実施形態では、メイン対戦ゲームの報酬は、権利データとしてのパックと、パックポイントとを少なくとも含む。

本実施形態では、パック（権利データ）は、ユーザがキャラクタを獲得するために使用するデジタルデータであり、ユーザは、権利データを使用する、すなわち、パックを開封することによって、該パックに設定された期待値に基づいて特定されたキャラクタのカードを獲得することができる。

本実施形態では、パックは付与されただけでは、使用可能とならず、パックに関連付けられているパックポイントの合計が所定値に到達することにより使用可能となる。カード取得部１１６は、パックを運用する。具体的には、カード取得部１１６は、ユーザに付与されたパックポイントを、パックのパックポイント合計に加算し、該合計が所定値に到達した場合に、パックを使用不可能状態から使用可能状態へと遷移させる。

カード取得部１１６は、パックが使用可能状態へと遷移した場合に、該パックに基づいてキャラクタのカードを提供するように、サーバ２００のカード提供部２１２に要求する。カード提供部２１２は、要求に応じて、使用されたパックの期待値に基づいてキャラクタを特定し、特定したキャラクタのカードを、ユーザが所有するデジタルデータとして該ユーザに紐付ける。

以上のとおり、第１のカード獲得処理とは、パックの付与、パックの運用（パックポイントの蓄積）、パック開封に伴うキャラクタの特定、特定されたキャラクタのカードのユーザとの紐付け、などの一連の処理を指す。

図１７〜図２２は、図３のステップＳ３に示される第１のカード獲得処理が実行されるときに、ユーザ端末１００の表示部１５２において表示されるゲーム画面の一例を示す図である。

ステップＳ３では、ユーザ端末１００の対戦進行部１１５は、付与された報酬をユーザに通知するために、例えば、図１７および図１８に示すゲーム画面を生成してもよい。表示制御部１１２は、ステップＳ３において、生成されたこれらのゲーム画面を表示部１５２に表示する。

図１７は、ユーザに獲得させた報酬をユーザに通知するための報酬通知画面８００の一例を示す図である。報酬通知画面８００は、一例として、対戦をプレイしたことの報酬として付与された、経験値８０１、ゴールド８０２、および、パックポイントパックポイント８０３を含む。経験値は、対戦をプレイするユーザに関連付けて付与される。経験値が一定以上貯まると、ユーザランクが上昇する。ユーザランクは、例えば、チームまたは各選手のパラメータなどに対して影響を与えてもよく、その影響は、ユーザランクが高いほど、対戦が有利に進められるようにプラスに作用する。ゴールドは、プレイされるゲーム内で消費することが可能なゲーム内価値であり、例えば仮想通貨である。具体的には、ゴールドと引き換えに対戦を有利に進めるための各種アイテムが入手できてもよい。

パックポイントは、パックを開封（使用）不可能状態から可能状態に遷移させるために必要なゲーム内価値である。パックポイントは、スロットに配置されたカードパックに対応付けられている開封の条件を、貯めることで満足させるものである。これにより、ユーザは、カードパックから選手カードを取り出したいために、パックポイントを得ようとして、強い動機を持って、対戦プレイを繰り返し行うことができる。

サーバ２００の対戦支援部２１１は、ユーザが対戦をプレイすると、たとえ対戦に負けたとしても、上述の報酬を必ずもらえるように算定してもよい。また、対戦支援部２１１は、対戦の成績が良いほど、より多くの経験値、ゴールド、および、パックポイントが付与されるように、報酬を算定することが好ましい。これにより、成績が伴わない熟練度の低いユーザに対しては、やる気を削がないようにすることができる一方、熟練度の高いユーザに対しては、負けたくないとか、いい成績で勝ちたいとかいった競争心、または、より操作に習熟したいという向上心を、芽生えさせることができる。このように、ユーザの熟練度を問わず、あらゆるユーザの、ゲームをプレイすることに対する動機付けをより一層強化することができる。

さらに、本実施形態では、対戦支援部２１１は、オート進行モードにて対戦が進行された割合、すなわち、オート進行モードの使用率を記憶しておいてもよい。そして、どのランクのカードパックをユーザに付与するのかを、該オート進行モードの使用率に基づいて決定してもよい。具体的には、対戦支援部２１１は、オート進行モードの使用率が低いほど、高いランクのカードパックが付与されるように報酬を決定してもよい。これにより、マニュアル進行モードに基づくプレイをユーザに促すことができ、対人対戦におけるゲームの興趣性を一層向上させることができる。

ユーザ端末１００の対戦進行部１１５は、オート進行モードの使用率を、オート使用率８０４として、図１７に示すゲーム画面に含めてもよい。さらに、対戦進行部１１５は、対戦成績８０５を該ゲーム画面に含めてもよい。

図１８は、ユーザに獲得させた報酬としてのパックをユーザに通知するためのパック通知画面８１０の一例を示す図である。パック通知画面８１０は、いずれのランクのパックが付与されたのかをユーザに通知するために表示部１５２に表示される。パック通知画面８１０は、一例として、対戦をプレイしたことの報酬として付与された、パック８１１を含む。表示制御部１１２は、図１７に示す報酬通知画面８００および図１８に示すパック通知画面８１０を、一画面に同時に表示させてもよいし、任意の順序で順次表示させてもよい。

図１８に示すＯＫボタン８１２が、ユーザの操作により押下されると、カード取得部１１６は、パックを運用するためのゲーム画面、すなわち、パックを配置するスロットを含むゲーム画面（図１９〜図２０）を生成する。カード取得部１１６によって生成されたゲーム画面は、表示制御部１１２によって表示部１５２に表示される。一例として、カード取得部１１６は、図１９に示すゲーム画面を生成し、表示部１５２に表示させる。

図１９は、パックの運用進捗をユーザに通知するためのパック運用画面８２０の一例を示す図である。パック運用画面８２０は、ユーザが所有する１以上のスロットの状態を一覧するためのスロット一覧８２１を含む。図１９に示す例では、ユーザには、デフォルトで３つのスロット８２２〜８２４が提供されている。本実施形態では、スロットには順序が設けられており、一番左のスロット８２２を先頭として、右に行くにつれて順序が後ろになるようにスロット８２３、および、スロット８２４が表示されている。

図１９に示すスロット８２２は、付与されたばかりのパック８１１（図１８）が、該スロット８２２に配置されたことを表している。カード取得部１１６は、新たなパック８１１が付与されると、該パック８１１を、空いているスロットの中で順番が一番前のスロット（図１９に示す例では、スロット８２２）に、自動的に配置する。そして、パック８１１が開封可能な状態に遷移するまで、パック８１１をスロット８２２で待機させる。上述したとおり、本実施形態では、カードパックは、カード取得部１１６が、スロットに配置しなければ、パックポイントを貯められる状態にならない。それゆえ、スロットは、カードパックが開封可能な状態へと遷移していくことを可能にする第１の要件である。

さらに、本実施形態では、カードパックがパックポイントを貯められる状態になるために、第２の要件が設定される。第２の要件は、パックポイントの加算を可能にするツールを利用することをユーザに課す。該ツールは、一例として、本野球ゲームの文脈に沿ってスカウトマンという形態でユーザに提供される。本実施形態では、一例として、カード取得部１１６は、１つのスロットにつき、一人のスカウトマンを割り当てる。本実施形態では、スカウトマンが割り当てられたスロットにカードパックが配置されることにより、該カードパックにパックポイントを貯めることが可能となる。換言すれば、カードパックは、第１の要件としてスロットに配置されること、および、第２の要件として該スロットにスカウトマンが割り当てられていること、の２つが満たされて、パックポイントを加算していくことが不可能な状態（以下、加算不可状態）から、パックポイントを加算していくことが可能な状態（以下、加算可能状態）へと移行する。

加算可能状態とは、開封のための所定の条件を満足するべく、カードパックの状態を変化させていくことができる状態を意味する。具体的には、条件として設定されたパックポイントの合計に到達すべく、パックポイントを貯めることが可能な状態を意味する。反対に、加算不可状態とは、上述の所定の条件を満足するべく、カードパックの状態を変化させていくことができない状態を意味する。具体的には、パックポイントを貯めることが不可能な状態、つまり、パックポイントが獲得されてもカードパックに対応付けてポイントは貯まらない状態を意味する。

カード取得部１１６は、報酬としてパックポイントがユーザに付与された場合、付与されたパックポイントを、スカウトマンが割り当てられたスロットに配置されているカードパックに対して加算する。例えば、図１７に示す例では、２１８ポイントのパックポイントが付与された。図１９に示す例では、スカウトマン８２５が割り当てられている状態でかつカードパックが配置されているのはスロット８２２である。そこで、カード取得部１１６は、付与された２１８ポイントを、スロット８２２に配置されているパック８１１に対して加算する。

カード取得部１１６がパック８１１にパックポイントを加算した結果、パックポイントの合計が所定値に到達した場合、カード取得部１１６は、パック８１１を、開封不可能状態から開封可能状態へと遷移させる。そして、カード取得部１１６は、パック８１１のパックポイントの合計が条件を満たしたことをユーザに通知するために、図２０に示すゲーム画面を生成し、表示部１５２に表示させてもよい。

図２０は、パックの運用進捗をユーザに通知するためのパック運用画面８２０の別の例を示す図である。図２０に示す例では、ゲージ８２６は、パック８１１に対してパックポイントが加算された結果、貯められたパックポイントが、条件である「８００ｐｔ」に到達したことを示している。この画面が表示された後、カード取得部１１６は、パック８１１を開封する処理を実行する、すなわち、パック８１１に基づいて、ユーザに所有させるキャラクタのカードを特定するように、サーバ２００に要求する。ここで、パック８１１は消費され、スロットに空きができる。

本実施形態では、スカウトマンが割り当てられているスロットに空きができた場合に、その空きのスロットよりも後ろに、スカウトマンが割り当てられていないスロットがあって、該スロットにカードパックが配置されている場合が想定される。該カードパックは、スカウトマンがいないために、パックポイントが貯められず単にスロットに待機している状態である。このような場合、カード取得部１１６は、該カードパックを、上述の空きのスロットに繰り上げて配置する。これにより、該カードパックは、パックポイントが貯められる状態になる。

図２０に示すように、カードパックのゲージがいっぱいになったとき、カード取得部１１６は、該パックを開封可能な状態に遷移させた上で、パックを開封してカードをユーザに獲得させる。このとき、カード取得部１１６は、パックが開封されて、キャラクタのカードが取得されようとしているシーンを演出するゲーム画面を生成し、表示部１５２に表示させてもよい。不図示の該ゲーム画面は、例えば、パック８１１の封が切られて、中から１以上の所定枚数のカードが、絵柄が伏せられた状態で取り出されるシーンを表現したアニメーションを含んでいてもよい。

カード取得部１１６は、サーバ２００のカード提供部２１２から、開封されたカードパックに基づいて特定された、ユーザに所有させるキャラクタのカードについての通知を受け取る。このとき、カード取得部１１６は、獲得されたキャラクタをユーザに通知するために、図２１に示すゲーム画面を生成し、表示部１５２に表示させてもよい。

図２１は、ユーザに獲得させたキャラクタをユーザに通知するためのキャラクタ通知画面８３０の一例を示す図である。例えば、キャラクタ通知画面８３０は、開封されたカードパックと引き換えに獲得されたキャラクタの絵柄が示されたカード８３１〜８３３を含んでいる。各カードは、例えば、選手の画像、選手名、選手の所属チーム名、および、カードの希少度を示す情報を含んでいる。いずれかのカードを選択すると、選択されたカードについて、さらに詳細情報が表示されてもよい。例えば、選手の能力に係る各種パラメータが表示されてもよい。

（処理の流れ）
図２２は、ゲームシステム１がゲームプログラム１３１に基づいて実行するメイン対戦ゲームおよび第１のカード獲得処理の流れを示すフローチャートである。以下で、ユーザ端末１００が実行するものとして説明した処理は、サーバ２００が実行してもよいし、反対に、サーバ２００が実行するものとして説明した処理は、ユーザ端末１００が実行してもよい。図２２に示す一連の処理は、図３に示すステップＳ２およびＳ３の処理に対応している。

ステップＳ２０１では、ユーザ端末１００の操作受付部１１１が、対戦の開始を指示するユーザの操作を、入力部１５１を介して受け付ける。これに応じて、対戦進行部１１５は、メインゲーム対戦を開始するためのマッチングをサーバ２００に対して要求する。

ステップＳ２０２では、サーバ２００の対戦支援部２１１は、通信ＩＦ２３を介して、ユーザ端末１００から上述の要求を受け付ける。これに応じて、対戦支援部２１１は、マッチング処理を実行し、ユーザの対戦相手を探索する。対戦相手が見つかり、マッチングが成立した場合、対戦支援部２１１は、ステップＳ２０３に進む。

ステップＳ２０３では、対戦支援部２１１は、マッチングされた各ユーザ端末１００が対戦を進行させることができるように、対戦を実施するユーザ端末１００同士に情報を共有させ、同期制御を行って、対戦を支援する。例えば、対戦支援部２１１は、マッチングが成立した旨を対戦進行部１１５に通知するとともに、対戦相手および相手チームの情報をユーザのユーザ端末１００に提供する。

ステップＳ２０４では、対戦進行部１１５は、対戦支援部２１１と通信して、メインゲーム対戦を進行させる。対戦進行部１１５は、対戦の開始時に、図１１に示すマッチング成立画面６００を表示部１５２に表示させてもよい。そして、対戦進行部１１５は、自チームの守備回において、投球結果Ｄ１をサーバ２００に送信して、マウンドにおける投球のイベント、および、フィールドにおける守備のイベントなどを進行させる。対戦進行部１１５は、守備回において、例えば、図１３〜図１５に示す投球画面７００を表示部１５２に表示させてもよい。また、対戦進行部１１５は、自チームの攻撃回において、打撃結果Ｄ２をサーバ２００に送信して、バッターボックスにおける打撃のイベント、飛球のイベントなどを進行させる。対戦進行部１１５は、攻撃回において、例えば、図１６に示す打撃画面７５０を表示部１５２に表示させてもよい。

ステップＳ２０５でＹＥＳの場合、例えば、全イニングの進行が完了した場合、ステップＳ２０６では、対戦支援部２１１は、成績を決定する。一例として、対戦支援部２１１は、メイン対戦ゲームが実行されている間に記憶部２２０に記録されていたゲーム情報１３２から勝敗、得点、奪三振数、安打数、本塁打数、および、オート制御使用率などを読み出す。

ステップＳ２０７では、対戦支援部２１１は、決定した対戦成績に基づいて、メイン対戦ゲームをプレイしたユーザに付与する報酬を算定する。本実施形態では、一例として、対戦をプレイしたことの報酬として、カードパック、経験値、ゴールド、および、パックポイントなどがユーザに付与される。例えば、対戦支援部２１１は、対戦成績が良いほど高いランクのカードパック、または、より多くのパックポイントが付与されるように、報酬を算定する。

ステップＳ２０８では、対戦支援部２１１は、算定した報酬を、ユーザに付与する。本実施形態では、一例として、該報酬（例えば、カードパック）を、上述のユーザのユーザ識別情報に関連付けて、ゲーム情報１３２として保存する。あるいは、対戦支援部２１１は、対戦前の経験値、ゴールド、および、パックポイントに対して、今回の報酬としての経験値、ゴールド、および、パックポイントをそれぞれ加算して、ユーザのゲーム情報１３２を更新する。これにより、ユーザに、上述の報酬を獲得させることができる。対戦支援部２１１は、ユーザに付与した報酬の内容を、ユーザ端末１００に通知してもよい。

ステップＳ２０９では、ユーザ端末１００の対戦進行部１１５は、上述の通知を受信すると、例えば、図１７に示す報酬通知画面８００および図１８に示すパック通知画面８１０を生成し、表示部１５２に表示させてもよい。対戦進行部１１５は、対戦支援部２１１からの報酬に係る通知に基づいて、記憶部１２０のゲーム情報１３２を更新し、ユーザに報酬を獲得させる。カード取得部１１６は、パックが獲得されると、該パックを運用し、キャラクタのカードをユーザに獲得させるための一連の処理を実行する。

ステップＳ２１０でＹＥＳの場合、すなわち、カードパックが配置されていない空きのスロットがあれば、ステップＳ２１１において、カード取得部１１６は、付与されたカードパックを、該空きのスロットに配置する。本実施形態では、ユーザが所有するスロットに１つでも空きがあれば、カード取得部１１６は、付与されたカードパックを、空きのスロットに自動的に配置してもよい。例えば、カード取得部１１６は、図１９に示すパック運用画面８２０を表示部１５２に表示させてもよい。

一方、ステップＳ２１０でＮＯの場合、すなわち、ユーザが所有するすべてのスロットがすでにカードパックで埋まっている場合、カード取得部１１６は、ステップＳ２０９で新たに付与されたカードパックをどこのスロットにも配置することができない。

この場合、ステップＳ２１２では、カード取得部１１６は、新たに付与されたパックを破棄する。すなわち、パックに係るデジタルデータは、記憶部１２０または記憶部２２０に格納されることなく消滅する。

なお、別の実施形態では、カード取得部１１６は、空きスロットが無いために配置できないパックについて、スロットに配置するまでもなくカードパックを即時に開封する機会を、所定の条件付きでユーザに提供してもよい。具体的には、カード取得部１１６は、所定の消費アイテム等のゲーム内価値と引き換えることを条件に、カードパックを即時に開封するか否かを問うメッセージを表示部１５２に表示させてもよい。ここで、カードパックを「即時に」開封することを提案するとは、カードパックをスロットに配置することを待たずに、あるいは、パックポイントが条件に到達することを待たずに、カードパックを開封する機会をユーザに与えることを意味する。したがって、「即時に開封する」との用語は、カードパックが付与された瞬間ただちに開封すること、および、消費アイテムが消費された瞬間ただちに開封することのみに限定して解釈されるべきではない。

ステップＳ２１３において、カード取得部１１６は、ステップＳ２０９で付与されたパックポイントを、スロットに配置され、かつ、スカウトマンが割り当てられているカードパックに対応付けられているパックポイントの合計に加算する。該ユーザによって、カードパックが配置されているスロットが複数所有されている場合には、カード取得部１１６は、付与されたパックポイントを、第１および第２の要件をともに満たすカードパックのそれぞれに加算してもよいし、付与されたパックポイントを所定の割合で各カードパックに分配してもよい。例えば、カード取得部１１６は、図２０に示すパック運用画面８２０を表示部１５２に表示させてもよい。

ステップＳ２１４において、カード取得部１１６は、各パックのパックポイントの合計が所定の条件を満たすか否かを判定する。カードパックに対応付けられているパックポイントが、該カードパックに割り当てられている条件を満足しない場合、カード取得部１１６は、一連の第１のカード獲得処理を終了させる。この後、対戦進行部１１５が、ステップＳ２１４のＮＯから、図３に示すステップＳ４に進み、以降の処理を実行する。

一方、ステップＳ２１３において、パックポイントが加算された結果、スロットに配置されているいずれかのパックのパックポイントの合計が所定値に到達した場合、カード取得部１１６は、ステップＳ２１４のＹＥＳからステップＳ２１５に進む。

ステップＳ２１５において、カード取得部１１６は、パックポイントの条件を満たしたパックを開封可能な状態へと遷移させる。そして、カード取得部１１６は、該パックに基づいて、キャラクタのカードの取得要求を、サーバ２００に送信する。具体的には、カード取得部１１６は、消費するカードパックを指定して、該カードパックに基づいてユーザに所持させる選手カードを特定するように、サーバ２００に要求する。

ステップＳ２１６では、サーバ２００のカード提供部２１２は、ユーザ端末１００から指定されたカードパックに設定されているランクに基づいて、ユーザに提供するキャラクタを特定する。本実施形態では、カード提供部２１２は、カードパックのランクに対応する期待値に基づいて、抽選を実施し、所定のキャラクタの集合の中から、ユーザに獲得させるキャラクタのカードを所定枚数特定する。本実施形態では、一例として、カード提供部２１２は、１つのカードパックにつき、３枚のカードを特定してもよい。

ステップＳ２１７では、カード提供部２１２は、選択した３枚のカードを、ユーザに提供し、所有させる。具体的には、カード提供部２１２は、該３枚のカードを、ユーザ識別情報に関連付けて、ゲーム情報１３２として記憶部２２０に保存する。これにより、ユーザは、これらのカードを所持することができ、これらのカードのキャラクタを起用して、対戦ゲームにおいて、該キャラクタを動作させることができる。カード提供部２１２は、ユーザに所持させた３枚のカードの内容を、ユーザ端末１００に通知してもよい。

ステップＳ２１８では、ユーザ端末１００のカード取得部１１６は、上述の通知を受信すると、ユーザにキャラクタのカードを獲得させる。具体的には、カード取得部１１６は、提供されたキャラクタのカードを、ユーザが所有するカードとして記憶部１２０に格納する。カード取得部１１６は、ユーザに獲得させたカードを通知するために、図２１に示すキャラクタ通知画面８３０を表示部１５２に表示させてもよい。この後、対戦進行部１１５は、図３に示すステップＳ４に進み、以降の処理を実行する。

＜サブ対戦ゲームの意義について＞
本実施形態において、本野球ゲームは、上述したとおり、メイン対戦ゲームに加えてサブ対戦ゲームを含む。例えば、サブ対戦ゲームは、メイン対戦ゲームより簡易に構成されていることが好ましい。ここで、「簡易に構成されている」とは、対戦の開始から終了までの所要時間が短いことを意味していてもよい。あるいは、メイン対戦ゲームでは、全イニングにおいて、オート進行モードとマニュアル進行モードとをユーザが任意に切り替えることができるのに対して、サブ対戦ゲームは、所定の局面を除いてオート進行モードにて進行することを意味していてもよい。あるいは、メイン対戦ゲームでは、例外を除いて概して他のユーザを相手とする対人対戦が実施されるが、サブ対戦ゲームでは、コンピュータを相手とするコンピュータ対戦が実施されることを意味していてもよい。つまり、サブ対戦ゲームは、本野球ゲームにおいて、高い集中力が要求されるメイン対戦ゲームとは別に、ユーザの気分転換になるように設けられたものである。

このようにサブ対戦ゲームをメイン対戦ゲームと比較して簡易に構成することにより、ユーザは、メイン対戦ゲームよりも気軽にサブ対戦ゲームに取り組むことができる。これにより、ゲームプレイに伴うユーザの緊張感、および、操作に係る負担が緩和される。

その上、本実施形態では、サブ対戦ゲームがプレイされたことに対して報酬がユーザに付与される。サブ対戦ゲームの報酬は、上述したとおり、一例として交換ポイントである。本実施形態では、交換ポイントは、一例として、キャラクタのカードを交換可能なゲーム内価値である。このように、メイン対戦ゲームをプレイする他にも、気軽に取り組めるサブ対戦ゲームをプレイすることによって、キャラクタのカードを獲得する方法をユーザに提供する。これにより、ゲームをプレイする意欲をユーザが損なうことを回避することができる。

本野球ゲームの興趣性は、基本的には、強いキャラクタのカードをデッキに組み入れることにより、強いチームを作り、そのような強いチームによって対戦で勝つことに見出される。つまり、強いキャラクタのカードを獲得できることがユーザの楽しみであり、プレイを継続する強い動機付けにつながる。

ここで、キャラクタのカードを獲得する方法がメイン対戦ゲームしかない場合には、ユーザのメイン対戦ゲームをプレイするモチベーションが一度下がってしまうと、キャラクタのカードが獲得できず、デッキの強化に進展がなくなり、一層モチベーションが低下する、というような悪循環からユーザを救済することが難しい。精神的負担が大きいメイン対戦ゲームに疲れる、敗北が続いて面白さを感じられない、十分な時間を取ってメイン対戦ゲームに取り組めない、など、モチベーションが下がる原因はいろいろ考えられる。したがって、メイン対戦ゲームのみですべてのユーザのモチベーションを維持し続けることは非常に難しい。

このような課題に対して、本実施形態によれば、より気軽に取り組めるサブ対戦ゲームを設ける。さらに、該サブ対戦ゲームをプレイすることでもキャラクタのカードが入手できる仕組みを構築する。これにより、ユーザのモチベーションが低下することがあったとしても、上述のような悪循環に陥ることを回避することが可能となる。

＜事前処理＞
本実施形態では、一例として、対戦進行部１１５は、メイン対戦ゲームの合間に一定の確率でサブ対戦ゲームをプレイする機会をユーザに与える。具体的には、対戦進行部１１５は、以下に説明する事前処理を実行して、サブ対戦ゲームを実行するか否かを決定する。事前処理を説明する前に、まず、サブ対戦ゲームの概要を説明する。

本実施形態では、一例として、対戦進行部１１５は、ユーザのチームを、ＣＯＭチームと対戦させるサブ対戦ゲームを提供する。ＣＯＭチームとは、ゲームプログラム１３１に基づいて、サーバ２００またはユーザ端末１００によって動作が制御される１以上のキャラクタで構成されたチームである。本実施形態では、一例として、ＣＯＭチームは、日本代表に選ばれた選手で構成された日本代表チームである。

日本代表チームのデッキ情報は、予め、記憶部２２０または記憶部１２０にゲーム情報１３２として格納されていてもよい。この場合、対戦進行部１１５が、必要に応じて日本代表チームのデッキ情報を適宜読み出す。日本代表チームのデッキ情報は、サブ対戦ゲームを実行することが決定されたことに応じて、都度、対戦進行部１１５によって作成されてもよいし、都度、対戦支援部２１１から提供されてもよい。

本実施形態では、一例として、日本代表チームは、強さに応じて、複数チーム提供される。強さとは、対戦における有利性または勝利のし易さを指す。具体的には、デッキ総合パラメータ、または、日本代表チームを構成する各選手の能力値が高いほど、強いチームである。

本実施形態では、一例として、強さが異なる４種類の日本代表チームのデッキ情報が、予め記憶部２２０または記憶部１２０に格納されている。各日本代表チームには、強い順に、「超級」、「上級」、「中級」および「初級」の等級が設定されている。

本実施形態では、一例として、対戦進行部１１５は、事前処理を実行する。具体的には、対戦進行部１１５は、まず、所定の確率に基づいて、サブ対戦ゲームをプレイする機会をユーザに与えるか否かを決定する。すなわち、対戦進行部１１５は、後述する出現確率に基づいて、メイン対戦ゲームの後、サブ対戦ゲームでユーザのチームと対戦させる日本代表チームを出現させるか否かを決定する。また、対戦進行部１１５は、該出現確率に基づいて、ユーザのチームと対戦させる日本代表チームの等級を決定する。例えば、対戦進行部１１５は、日本代表チームを出現させるか否かと、出現させる場合の日本代表チームの等級とを、上述の出現確率に基づいて１回の抽選により決定してもよい。

（出現確率について）
図２３は、出現確率表のデータ構造の一例を示す図である。出現確率表は、対戦進行部１１５が事前処理を実行するときに参照するデータである。出現確率表は、対戦進行部１１５が、日本代表チームとのサブ対戦ゲームをプレイする機会をユーザに対して与えるか否かを決定するために参照される。また、出現確率表は、対戦進行部１１５が、サブ対戦ゲームのプレイ機会を与える場合に、相手チームである日本代表チームの等級を決定するために参照される。

出現確率表において、事前処理で実行される抽選の出目ごとに出現確率が設定される。出目は、例えば、日本代表チームを出現させる場合の該日本代表チームの各「等級」、および、日本代表チームを出現させない場合を意味する「出現なし」である。図２３に示す例では、５つの出目ごとに出現確率が設定される。

本実施形態では、一例として、メイン対戦ゲームにおけるユーザの勝敗に応じて、異なる出現確率が設定されていてもよい。例えば、出現確率表は、メイン対戦ゲームにおいてユーザが勝利した場合に参照される第１確率表６２０と、ユーザが敗北した場合に参照される第２確率表６２１とを含んでいてもよい。

本実施形態では、勝利時の日本代表チームの出現確率は、敗北時の出現確率より高く設定されていてもよい。つまり、第１確率表６２０の各等級の出目に設定された確率は、第２確率表６２１の各等級の出目に設定された確率よりも高く設定される。さらに、勝利時は、いずれかの等級の日本代表チームが必ず出現するように、第１確率表６２０が設定されていてもよい。つまり、第１確率表６２０において、出目「出現なし」には、確率「０（％）」が設定されていてもよい。

対戦進行部１１５は、あるいは、ユーザがメイン対戦ゲームにおいて所定回数連敗した場合には、日本代表チームが必ず出現するように、第２確率表６２１に代えて、別の確率表を参照してもよい。すなわち、該別の確率表においては、出目「出現なし」には、確率「０（％）」が設定されている。そして、対戦進行部１１５は、ユーザが所定数の連敗を喫した場合には、第２確率表６２１の代わりに、上述の別の確率表を参照して、日本代表チームを出現させることを必ず決定してもよい。あるいは、対戦進行部１１５は、ユーザの連敗数に応じて、第２確率表６２１の確率値をそれぞれ補正してもよい。具体的には、対戦進行部１１５は、各等級の出目の確率を上げ、「出現なし」の出目の確率を下げるまたはゼロにする。

本野球ゲームでは、キャラクタのカードはメイン対戦ゲームの対戦をプレイすることにより付与されるパックから入手される。したがって、連敗しているユーザは、強いキャラクタのカードを入手しにくく、ゲームを続ける意欲が損なわれる虞がある。そこで、このようなユーザに対して、キャラクタのカードと交換できる交換ポイントが報酬として得られるサブ対戦ゲームのプレイ機会を必ず与えるようにする。ユーザは、これにより、メイン対戦ゲームとは別の気軽に取り組めるサブ対戦ゲームにおいて交換ポイントを貯めることにより、キャラクタのカードを入手する機会を得ることができる。結果として、メイン対戦ゲームで負けが続いてプレイ意欲が低迷しているユーザに対して、動機付けを与え、プレイ意欲を回復させることが可能となる。

本実施形態では、さらに、各等級の日本代表チームの出現確率は、ユーザのレーティングに応じて設定されてもよい。レーティングは、ユーザの強さを表す指標である。対戦進行部１１５は、上述の制御するステップにおいて、ユーザに付与されたレーティング（評価値）が示す該ユーザの対戦における強さが強いほど、強い日本代表チーム（チーム）を、より高い確率でサブ対戦ゲームの相手チームとして決定してもよい。例えば、日本代表チームの強さがユーザの強さにだいたい見合うように、出現確率が設定される。図示の例では、例えば、ユーザの強さを、レーティングに基づいて４つに区分する。そして、区分ごとに異なる、第１確率表６２０および第２確率表６２１をそれぞれ設定する。

なお、本実施形態では、ユーザのチームが、高い等級、すなわち、強い日本代表チームと対戦するほど、対戦進行部１１５は、該ユーザに対して付与する交換ポイントを多くすることが好ましい。図２３に示すとおり、日本代表チームの等級ごとに、報酬として付与される交換ポイントが予め設定されていてもよい。

上述の構成によれば、ユーザのレーティングが高いほど、強い日本代表チームと当たり易くなり、結果として、交換ポイントが貯まり易くなる。したがって、交換ポイントを効率よく貯めるために、ユーザは、レーティングを上げたいと望み、メイン対戦ゲームをプレイすることを促される。

また、本実施形態では、対戦進行部１１５は、ユーザが日本代表チームに勝利した場合、敗北した場合よりも多くの交換ポイントを該ユーザに付与することが好ましい。また、敗北した場合にも、交換ポイントがユーザに付与されることが好ましい。これにより、ユーザは、気軽ではあるが、勝利を目指してサブ対戦ゲームに取り組むように促される。また、敗北した場合でも交換ポイントが付与されるので、ユーザは、サブ対戦ゲームに取り組むこと自体に価値を見出し、より気軽にサブ対戦ゲームを楽しむことができる。

（画面例）
図２４は、サブ対戦ゲームをプレイする機会が与えられたこと、具体的には、日本代表チームが出現したことをユーザに通知するためのメッセージ画面８４０の一例を示す図である。例えば、メッセージ画面８４０は、日本代表チームと対戦する機会がユーザに与えられたことを通知するためのメッセージ８４１と、出現した日本代表チームの等級８４２とを含む。

本実施形態では、対戦進行部１１５は、さらに、サブ対戦ゲームをプレイするか否かをユーザに選択させるためのＵＩ部品をメッセージ画面８４０に配置してもよい。具体的には、メッセージ画面８４０は、日本代表チームとの対戦に挑戦しないことを選択するためのボタン８４３と、該対戦に挑戦することを選択するためのボタン８４４とを含んでいてもよい。

ボタン８４３がタップ操作された場合には、対戦進行部１１５は、メイン対戦ゲームが終了した後に通常遷移する画面（例えば、不図示のメニュー画面など）を表示部１５２に表示させる。一方、ボタン８４４がタップ操作された場合には、対戦進行部１１５は、サブ対戦ゲームの画面を表示部１５２に表示させて、日本代表チームとの対戦を進行する。

なお、別の実施形態では、対戦進行部１１５は、日本代表チームを出現させると決定した場合には、メッセージ画面８４０において、ユーザに、サブ対戦ゲームをプレイするか否かを選択させることなく、強制的にサブ対戦ゲームを実行してもよい。

（処理の流れ）
図２５は、ゲームシステム１がゲームプログラム１３１に基づいて実行する事前処理の流れを示すフローチャートである。以下で、ユーザ端末１００が実行するものとして説明した処理は、サーバ２００が実行してもよい。図２５に示す一連の処理は、図３に示すステップＳ４の処理に対応している。

ステップＳ３０１では、対戦進行部１１５は、上述の出現確率表のうち、ユーザのレーティングに応じた区分の確率表を読み出す。

ステップＳ３０２では、対戦進行部１１５は、先のステップ（図３のステップＳ２）にて実行されたメイン対戦ゲームにおいて、ユーザが勝利したか否かを判定する。対戦進行部１１５は、ユーザが勝利した場合、ステップＳ３０２のＹＥＳからステップＳ３０３に進む。一方、対戦進行部１１５は、ユーザが敗北した場合、ステップＳ３０２のＮＯからステップＳ３０４に進む。

ステップＳ３０３では、対戦進行部１１５は、第１確率表６２０を選択する。

ステップＳ３０４では、対戦進行部１１５は、第２確率表６２１を選択する。

ステップＳ３０５では、対戦進行部１１５は、ユーザの連敗数に応じて選択した第２確率表６２１の各出目の確率を補正してもよい。ステップＳ３０５は省略されてもよい。

ステップＳ３０６では、対戦進行部１１５は、選択した確率表に基づいて、抽選を実施する。

ステップＳ３０７では、対戦進行部１１５は、当選した出目が、「出現なし」か、それ以外の等級の出目かを判定する。当選した出目が、日本代表チームのいずれかの等級の出目である場合、対戦進行部１１５は、サブ対戦ゲームをプレイする機会をユーザに与えることを決定し、ステップＳ３０７のＹＥＳからステップＳ３０８に進む。一方、ステップＳ３０７において、対戦進行部１１５は、当選した出目が「出現なし」である場合、ステップＳ３０７のＮＯからステップＳ３１１に進む。

ステップＳ３０８では、対戦進行部１１５は、日本代表チームが出現した旨を通知し、日本代表チームに挑戦するか否かをユーザに選択させるためのメッセージ画面８４０を表示部１５２に表示させる。

ステップ３０９では、対戦進行部１１５は、日本代表チームに挑戦しないことを選択するボタン８４３、および、日本代表チームに挑戦することを選択するボタン８４４のいずれがタップされたのかを判定する。操作受付部１１１が、ボタン８４４に対するタップ操作を受け付けた場合、対戦進行部１１５は、ステップＳ３０９のＹＥＳからステップＳ３１０に進む。一方、操作受付部１１１が、ボタン８４３に対するタップ操作を受け付けた場合、対戦進行部１１５は、ステップＳ３０９のＮＯからステップＳ３１１に進む。

ステップＳ３１０では、対戦進行部１１５は、ボタン８４４がタップされたことに伴い、当選した等級の日本代表チームとのサブ対戦ゲームを実行することを決定する。

ステップＳ３１１では、対戦進行部１１５は、「出現なし」の出目が当選したこと、または、ボタン８４３がタップ操作されたことに伴い、サブ対戦ゲームを実行しないことを決定する。

＜サブ対戦ゲームから第２のカード獲得処理まで＞
対戦進行部１１５は、サブ対戦ゲームを実行することを決定した場合には、当選させた日本代表チームとの対戦の進行を開始する。メイン対戦ゲームと同様に、サブ対戦ゲームは、複数のフェーズで区切られており、各フェーズは、キャラクタの動作を決定するためにユーザが実施する操作の影響を受けて、ゲームプログラム１３１にしたがってキャラクタを動作させるマニュアル進行モード、または、ユーザが実施する操作の影響を受けずに、ゲームプログラム１３１にしたがってキャラクタを動作させるオート進行モードで進行する。本実施形態では、対戦進行部１１５は、メイン対戦ゲームでは、上述のとおり、ユーザが、フェーズごとに、マニュアル進行モードとオード進行モードとを任意に切り替えることが可能である。対戦進行部１１５は、ユーザによって、マニュアル進行モードで進行させることが指定された各フェーズを、該マニュアル進行モードにて進行させる。一方、本実施形態では、対戦進行部１１５は、サブ対戦ゲームでは、所定の条件を満たすフェーズを除き、各フェーズをオート進行モードにて進行させる。

具体的には、対戦進行部１１５は、サブ対戦ゲームを基本的にオート進行モードにて進行させ、対戦の局面が所定の条件に合致した場合に、当該局面のフェーズを、例外的に、マニュアル進行モードに切り替えて進行させる。例えば、対戦進行部１１５は、ユーザのチームが守備回のときに、得点圏に相手チームの走者が進塁した場合に、その直後の打席における投球のフェーズをマニュアル進行モードに切り替える。あるいは、対戦進行部１１５は、ユーザのチームが攻撃回のときに、自チームの走者が得点圏に進塁した場合に、その直後の打席のフェーズをマニュアル進行モードに切り替える。

つまり、勝敗を左右する重要な局面を除いては、すべてのイニングはオート進行モードにて進行するため、ユーザの操作が対戦の進行に影響を与える期間は短縮され、操作に係る負担も大幅に削減される。また、サブ対戦ゲームの成績は、メイン対戦ゲームの成績に影響を与えない。以上のことから、ユーザは、サブ対戦ゲームを、メイン対戦ゲームの合間の気分転換として、気軽に楽しむことができる。

サブ対戦ゲームが終了すると、対戦進行部１１５または対戦支援部２１１は、第２のカード獲得処理を実行する。具体的には、サブ対戦ゲームにおけるユーザの成績に応じて交換ポイントを算出し、ユーザに付与する。成績とは、例えば、対戦の勝敗、および、マニュアル進行モードで進行していた期間においてユーザがキャラクタに達成させた記録などを含む。このようにして、交換ポイントがサブ対戦ゲームの報酬としてユーザに付与されることにより、ユーザは、交換ポイントを用いてキャラクタのカードを獲得することができる。

（サブ対戦ゲームにおける画面例）
図２６および図２７は、図３に示すステップＳ６にて対戦進行部１１５が表示部１５２に表示するオート進行画面の一具体例を示す図である。図２６に示すオート進行画面８５０は、対戦の局面が所定の条件を満たしていない期間のある時点で表示されるオート進行画面の一例である。オート進行画面８５０は、少なくとも、オート進行モードにて進行している対戦の局面を示す情報を含む。一例として、オート進行画面８５０は、スコアボード８５１を含む。スコアボード８５１は、各チームの各イニングの得点、並びに、各チームの現在の得点、ヒットの数、およびエラーの数を示す。なお、本野球ゲームにおいて、サブ対戦ゲームは、図示のスコアボード８５１が示すように、９イニングで構成されていてもよい。

また、オート進行画面８５０は、各チームの現在の得点を示す得点表示８５２、ユーザ本人のユーザ名８５３、対戦相手のユーザ名８５４、ユーザ本人が操作する自チームのチーム名８５５、対戦相手が操作する相手チームのチーム名８５６を含んでいてもよい。本実施形態では、対戦相手のユーザ名８５４は、日本代表チームの等級を示している。

また、オート進行画面８５０は、その他のＵＩを含んでいてもよい。例えば、現在打席に立っている打者キャラクタのキャラクタ名、画像、および打撃結果、現在投球している投手キャラクタのキャラクタ名および画像、ボールカウントおよびアウトカウントを示す画像、現在のイニングを示す画像、各塁の走者の有無を示す画像などを含んでいてもよい。

対戦進行部１１５は、オート進行モードで対戦を進行させるのに伴い、図示のスコアボード８５１および得点表示８５２を更新する。

具体的には、対戦進行部１１５は、ユーザの操作するチームが守備側である場合、現在投球している投手キャラクタの能力値に基づき、投球結果Ｄ１を生成する。一例として、対戦進行部１１５は、現在投球している自チームの投手キャラクタの能力値を入力として、ゲームプログラム１３１に基づき、投手キャラクタに投球させる球種、球速、およびコース（内角高め、低めなど）を決定し、これらを含む投球結果Ｄ１を出力する。そして、対戦進行部１１５は、該投球結果Ｄ１を、サーバ２００へ送信する。なお、日本代表チームの動作を、サーバ２００ではなくユーザ端末１００が決定する場合、すなわち、ユーザ端末１００が単独でサブ対戦ゲームを進行させる場合には、対戦進行部１１５は、投球結果Ｄ１をサーバ２００に送信することを省略する。

対戦進行部１１５は、サーバ２００から、投球結果Ｄ１の送信に対する応答として、打撃結果Ｄ２を受信する。対戦支援部２１１は、投球結果Ｄ１および日本代表チームの現在打席に立っている打者キャラクタの能力値を入力として、ゲームプログラム１３１に基づき、打者キャラクタが振ったバットがボールに当たったか否かと、当たった場合には、バットがボールに対して打撃を与えたときのバットとボールとの位置関係とを決定し、これらを含む打撃結果Ｄ２を出力する。ユーザ端末１００が単独でサブ対戦ゲームを進行させる場合には、対戦支援部２１１に代えて対戦進行部１１５が打撃結果Ｄ２を生成する。

対戦進行部１１５は、打撃結果Ｄ２に応じて対戦を進行させる。具体的には、対戦進行部１１５は、投球結果Ｄ１と、打撃結果Ｄ２とに基づいて、対戦会場としての球場を模して定義された仮想空間についての計算を実行し、対戦を進行させる。仮想空間についての計算には、例えば、投球されたボールの移動経路、振られたバットの位置、および、打撃後のボールの飛翔経路などを計算する処理、および、バットがボールに当たったか否かを判定する処理などが含まれる。さらに、フィールドに配置されている野手キャラクタの能力値と、走塁する走者キャラクタの能力値（例えば、足の速さを示す走力）とに基づいて、野手キャラクタの動き、走者キャラクタの動き、および、ボールの位置を計算して、フィールドプレイを再現する処理なども、仮想空間についての計算に含まれる。対戦を進行させた結果、得点が入った場合、対戦進行部１１５は、スコアボード８５１および得点表示８５２を更新する。また、対戦進行部１１５は、打撃結果Ｄ２がヒットあるいはエラーである場合、または、スリーアウトとなった場合、スコアボード８５１を更新する。

一方、ユーザの操作するチームが攻撃側である場合、対戦進行部１１５は、サーバ２００から送信される投球結果Ｄ１を待機する。投球結果Ｄ１を受信すると、対戦進行部１１５は、投球結果Ｄ１と、現在打席に立っている打者キャラクタとを入力して、ゲームプログラム１３１に基づき、打撃結果Ｄ２を出力する。一例として、対戦進行部１１５は、投球結果Ｄ１が示す球種、球速、およびコースに対する、打者キャラクタの得意不得意を示す能力値、並びに、打者キャラクタの打撃に関する能力値に基づき、打撃結果Ｄ２を生成する。対戦進行部１１５は、該打撃結果Ｄ２を、サーバ２００へ送信する。また、対戦進行部１１５は、打撃結果Ｄ２に応じて対戦を進行させる。なお、打撃に関する能力値とは、例えば、ボールをバットに当てる巧さ（命中力）や、ボールを遠くに飛ばす力（打撃力）などである。なお、ユーザ端末１００が単独でサブ対戦ゲームを進行させる場合には、対戦進行部１１５は、日本代表チームの投球結果Ｄ１を、サーバ２００から受信することなく自ら生成する。

対戦進行部１１５は、以上の処理を、オート進行モードが終了するまで、フェーズごとに繰り返すことで、対戦を進行させる。

図２７に示すオート進行画面８５０は、対戦の局面が所定の条件を満たしたときに表示されるオート進行画面の一例である。図示のオート進行画面８５０は、さらに、対戦の局面の概要を示す概要表示８５７、対戦の局面の詳細を示す詳細表示８５８、および、オート進行モードからマニュアル進行モードへと切り替わることを示す変更表示８５９を含む。詳細表示８５８は、一例として、アウトカウント、走者の有無および走者がいる塁、並びに、現在の打者キャラクタの名前を含む。

図示の例において、所定の条件は、概要表示８５７が示すように、ユーザが操作するチームが得点するチャンスとなったことである。得点するチャンスとは、例えば、ユーザが操作するチームが攻撃側である場合に、詳細表示８５８が示すように、得点圏（二塁または三塁の少なくとも一方）に走者がいることである。対戦進行部１１５は、図２７に示すオート進行画面８５０を表示部１５２に表示させた後、表示部１５２に表示させるゲーム画面をオート進行画面８５０から、マニュアル進行画面に切り替える。マニュアル進行画面は、既に示したとおり、自チームの攻撃回であれば、図１６に示す打撃画面７５０であり、自チームの守備回であれば、図１３〜図１５に示す投球画面７００である。

図２８および図２９は、対戦の局面が所定の条件を満たしたときに表示されるオート進行画面の他の例を示す図である。図２８の例において、所定の条件は、概要表示８６０が示すように、ユーザが操作するチームがピンチ、すなわち失点する可能性がある状況となったことである。失点する可能性がある状況とは、例えば、ユーザが操作するチームが守備側である場合に、詳細表示８５８が示すように、得点圏に走者がいることである。

また、図２９の例において、所定の条件は、概要表示８６１が示すように、対戦における、自チームの最後の打席が開始されることである。換言すれば、所定の条件は、最後の攻撃回において、詳細表示８６２が示すように、ツーアウトとなってから次の打席が開始されることである。なお、所定の条件は、図２７〜図２９に示す局面に限定されない。例えば、図示しないが、所定の条件は、対戦における、相手チーム最後の打席が開始されることであってもよい。換言すれば、所定の条件は、最後の守備回において、ツーアウトをとった後、相手チームの次の打席が開始されることである。

また、別の実施形態では、対戦進行部１１５は、マニュアル進行モードに切り替えるフェーズの上限を予め定めていてもよい。この場合、１度の対戦において、上述の所定の条件を満たす局面が何度訪れても、マニュアル進行モードにてユーザがプレイするフェーズ数は、予め定められた上限数で固定される。これにより、サブ対戦ゲームの操作に係る負荷が、進行状況に応じて増加することがなくなる。結果として、気分転換のために気軽に取り組めるという、サブ対戦ゲームの存在意義が損なわれることを回避できる。

（第２のカード獲得処理における画面例）
図３に示すとおり、サブ対戦ゲームが終了すると、次に、ゲームシステム１は、第２のカード獲得処理を実行する。具体的には、まずは、ゲームシステム１は、ユーザがサブ対戦ゲームをプレイしたことに対する報酬を該ユーザに付与する。本実施形態では、サブ対戦ゲームの報酬は、キャラクタのカードと交換することが可能な交換ポイントを少なくとも含む。

図３０は、図３のステップＳ７に示される第２のカード獲得処理が実行されるときに、ユーザ端末１００の表示部１５２において表示されるゲーム画面の一例を示す図である。具体的には、図３０に示すゲーム画面は、ユーザに獲得させた報酬、具体的には、交換ポイントをユーザに通知するための報酬通知画面８７０の一例である。

報酬通知画面８７０は、少なくとも、獲得ポイント合計８７１を含む。獲得ポイント合計８７１は、サブ対戦ゲームにおける１度の対戦で、ユーザが獲得した交換ポイントの合計を示す。

さらに、報酬通知画面８７０は、獲得ポイント合計８７１の内訳を含んでいてもよい。本実施形態では、一例として、ユーザに付与される変換ポイントは、日本代表チームとの対戦の勝敗に伴って決定される勝敗加点、マニュアル進行モードにおけるユーザの良好なプレイ結果に伴うプレイ加点、および、第２デッキ（例えば、自球団優先デッキ）に基づく自チームにて勝利したことに伴うデッキ加点の合計で決まる。したがって、図３０に示す例では、報酬通知画面８７０は、勝敗加点８７２、プレイ加点８７３、および、デッキ加点８７４を含んでいてもよい。

さらに、報酬通知画面８７０は、あと何ポイント獲得すれば、キャラクタのカードを交換することが可能であるのかを示す目標ポイントを示したメッセージ８７５を含んでいてもよい。

さらに、報酬通知画面８７０は、誘導ボタン８７６を含んでいてもよい。誘導ボタン８７６は、ユーザをポイント交換所に誘導するためのＵＩである。ポイント交換所とは、交換ポイントと交換可能なアイテムの一覧と、ユーザからの交換の指示を受け付けるためのＵＩとを含むポイント交換画面（図示せず）のことである。具体的には、誘導ボタン８７６がタップ操作されると、カード取得部１１６は、表示部１５２に表示させる画面を、報酬通知画面８７０からポイント交換画面へ切り替える。ユーザは、ポイント交換画面を操作することにより、付与された交換ポイントと引き換えに、キャラクタのカードを含む各種のアイテムを獲得することができる。

（交換ポイントについて）
ユーザ端末１００の対戦進行部１１５またはサーバ２００の対戦支援部２１１は、ユーザによってプレイされたサブ対戦ゲームの進行状況に応じて、該ユーザに獲得させる交換ポイントを、以下のとおり決定する。以下では、対戦支援部２１１が報酬の算定を行うものとして説明するが、同様の処理を対戦進行部１１５に実行させてもよい。

まず、対戦支援部２１１は、サブ対戦ゲームにおいて実施された対戦に係る成績を決定する。具体的には、対戦支援部２１１は、成績として、対戦全体におけるユーザのチームの活躍度を評価した対戦成績と、ユーザのプレイ内容を評価したプレイ成績とを決定する。対戦成績は、１つの試合（対戦）において自チームが達成した記録である。対戦成績は、例えば、対戦の勝敗、得点、自チームの投手キャラクタの奪三振数および防御率、並びに、自チームの打者キャラクタの安打数および本塁打数などの項目のすべてまたは一部を含んでいてもよい。

プレイ成績は、試合の中で、ユーザがマニュアル進行モードでプレイした期間（フェーズ）において、ユーザが操作したキャラクタに達成させた記録、または、該記録に基づく評価である。つまりユーザがマニュアル進行モードで投球操作または打撃操作した結果、キャラクタがそのフェーズにおいてどのような結果を残したのかに応じて決定される。具体的には、攻撃回のある１つの局面において、ユーザがプレイした結果、得点が入ったか否かに応じて、対戦支援部２１１は、ユーザの上述のプレイに対して、「良」または「不良」評価を下す。あるいは、対戦支援部２１１は、守備回のある１つの局面において、ユーザのプレイにより、相手チームの得点を阻むことができれば「良」、得点を許してしまったら「不良」の評価を下す。さらに、対戦支援部２１１は、ユーザの投手キャラクタが被安打および四球なしであることを「良」の評価を下す条件に加えてもよい。

対戦支援部２１１は、ステップＳ７では、サブ対戦ゲームの成績が良いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する第２報酬をユーザに付与することが好ましい。

例えば、対戦支援部２１１は、少なくとも、上述のようにして決定した成績に基づいて、ユーザに付与する交換ポイントを算定する。より具体的には、対戦支援部２１１は、サブ対戦ゲームにおいてユーザが収めた対戦成績およびプレイ成績が良いほど、多くの交換ポイントをユーザに付与する。なお、対戦支援部２１１は、成績以外にも、相手チームである日本代表チームの等級、および、ユーザのチームのデッキ種別を加味して交換ポイントを算定してもよい。

本実施形態では、一例として、対戦支援部２１１は、対戦成績と相手チームの等級とに基づいて、勝敗加点８７２を決定する。具体的には、対戦支援部２１１は、図２３に示す、日本代表チームの等級ごと、かつ、勝敗別に定めされている交換ポイントのテーブルを参照して、勝敗加点８７２を決定する。例えば、対戦支援部２１１は、ユーザのチームが、日本代表チーム「超級」に勝利した場合には、図２３に示すテーブルにしたがい、勝敗加点８７２を「２５００ポイント」と決定する。

本実施形態では、一例として、対戦支援部２１１は、プレイ成績に基づいて、プレイ加点８７３を決定する。例えば、対戦支援部２１１は、「良」の評価の数×７０ポイントをプレイ加点８７３としてもよい。例えば、ユーザが、１度の対戦において、４回のマニュアル進行モードでのプレイ機会のうち、３回について「良」の評価を得た場合には、対戦支援部２１１は、「３×７０＝２１０ポイント」をプレイ加点８７３と決定する。

本実施形態では、一例として、対戦支援部２１１は、ユーザが用いたデッキの種類に基づいて、デッキ加点８７４を決定する。

上述したとおり、記憶部１２０には、ゲーム情報１３２として、ユーザの自チームの編成がそれぞれ異なる第１デッキと第２デッキとが記憶されている。本野球ゲームでは、一例として、ユーザは、キャラクタ優先デッキである第１デッキと、自球団優先デッキである第２デッキとの２種類のデッキを使い分けることができる。上述したとおり、自球団優先デッキ（第２デッキ）は、ユーザが指定した球団（属性）と同じ球団に属する（同じ属性を有する）１以上のキャラクタを含む場合に、対戦において有利な効果を発動させる性質を有する。

対戦支援部２１１は、自球団優先デッキに基づく自チームで、日本代表チーム（相手チーム）と対戦した場合に、キャラクタ優先デッキに基づく自チームで対戦した場合よりも、ゲーム上の価値が高いこと、および、量が多いことの少なくともいずれか一方に該当する前記報酬を付与してもよい。

例えば、対戦支援部２１１は、ユーザが、キャラクタ優先デッキ（第１デッキ）で日本代表チームに勝利しても加点されないところ、自球団優先デッキで勝利した場合には、一律、所定ポイント（例えば、５００ポイント）のデッキ加点８７４をユーザに付与する交換ポイントの合計に加えてもよい。

最後に、対戦支援部２１１は、上述のように決定した勝敗加点８７２、プレイ加点８７３およびデッキ加点８７４を合計して、ユーザに獲得させる交換ポイントの合計（図３０に示す獲得ポイント合計８７１）を算定する。対戦支援部２１１は、算定した獲得ポイント合計８７１を、ユーザ端末１００の対戦進行部１１５に対して送信する。対戦支援部２１１は、獲得ポイント合計８７１を、ユーザに紐付けて管理することにより、サブ対戦ゲームがプレイされたことの報酬である獲得ポイント合計８７１をユーザに獲得させる。

（処理の流れ）
図３１は、ゲームシステム１がゲームプログラム１３１に基づいて実行するサブ対戦ゲームおよび第２のカード獲得処理の流れを示すフローチャートである。以下で、ユーザ端末１００が実行するものとして説明した処理は、サーバ２００が実行してもよいし、反対に、サーバ２００が実行するものとして説明した処理は、ユーザ端末１００が実行してもよい。例えば、ユーザ端末１００が単独でサブ対戦ゲームを実行する場合には、ステップＳ４０１、Ｓ４０２、および、Ｓ４０７は省略され、ステップＳ４０８〜Ｓ４１０は、ユーザ端末１００によって実行される。図３１に示す一連の処理は、図３に示すステップＳ６およびＳ７の処理に対応している。図３に示すステップＳ４およびＳ５において、サブ対戦ゲームを実行することが決定された場合、ゲームシステム１は、図３１に示す処理を開始する。

ステップＳ４０１にて、対戦進行部１１５は、サブ対戦ゲームの進行を支援するようサーバ２００に要求する。具体的には、対戦進行部１１５は、対戦を進行させるために必要な各種情報の提供をサーバ２００に要求する。

ステップＳ４０２にて、対戦支援部２１１は、上述の要求に対する応答として、ユーザ端末１００にて対戦が進行されるように、対戦進行部１１５が実行する対戦の進行を支援する。具体的には、対戦支援部２１１は、日本代表チームのデッキ情報、日本代表チームの投手キャラクタの投球動作を決定するための投球結果Ｄ１、および、日本代表チームの打者キャラクタの打撃動作を決定するための打撃結果Ｄ２を対戦進行部１１５に供給する。

ステップＳ４０３において、対戦が終了しないうちは、すなわち、対戦の進行状況が９回裏でスリーアウトの局面に到達しないうちは、対戦支援部２１１は、ステップＳ４０３のＮＯからステップＳ４０２に戻り、対戦の支援を継続する。

ステップＳ４０４において、対戦進行部１１５は、対戦支援部２１１と通信し、対戦の進行を開始する。このとき、対戦進行部１１５は、オート進行モードで対戦を進行させる。ここで、対戦進行部１１５は、例えば、図２６に示すオート進行画面８５０を表示部１５２に表示させる。オート進行画面が表示されることにより、各ユーザは、対戦の進行状況を認識することができる。また、マニュアル進行モードに切り替わったときに、どのようにプレイすべきかを容易に決定することができる。対戦が進行するにしたがって、対戦進行部１１５は、オート進行画面８５０を更新する。

ステップＳ４０５において、対戦の局面が所定の条件を満たす場合、対戦進行部１１５は、ステップＳ４０５のＹＥＳからステップＳ４０６へ進む。一方、対戦の局面が所定の条件を満たさないうちは、対戦進行部１１５は、ステップＳ４０５のＮＯからステップＳ４０４に戻り、オート進行モードでの対戦の進行を継続する。

ステップＳ４０６において、対戦進行部１１５は、オート進行モードからマニュアル進行モードに切り替えて、対戦を進行させる。ここで、対戦進行部１１５は、例えば、図１３〜図１５に示す投球画面７００、または、図１６に示す打撃画面７５０を表示部１５２に表示させる。投球画面７００および打撃画面７５０は、ともに、マニュアル進行モードにおいて、キャラクタの動作を決定するためのユーザの操作を受け付けるための画面として機能する。ユーザの操作とは、例えば、投球操作および打撃操作である。

ステップＳ４０７において、対戦進行部１１５は、上述のマニュアル進行モードにおけるユーザのプレイを評価し、その評価結果「良」または「不良」を、表示部１５２に表示させてもよい。

ステップＳ４０８において、対戦が終了しないうちは、対戦進行部１１５は、ステップＳ４０８のＮＯからステップＳ４０４に戻り、再び、オード進行モードに切り替えて、次の打席から対戦を進行させる。

ステップＳ４０３およびステップＳ４０８のそれぞれにおいて、例えば、９回裏でスリーアウトの局面に到達するなどして全イニングの進行が完了した場合、対戦が終了する。この場合、対戦支援部２１１は、ステップＳ４０３のＹＥＳからステップＳ４０９へ進む。一方、対戦進行部１１５は、ステップＳ４０８のＹＥＳから後述するステップＳ４１２へ進む。なお、別の実施形態では、対戦進行部１１５は、ステップＳ４０８のＹＥＳから、後述するステップＳ４０９〜Ｓ４１１に進み、その後、ステップＳ４１２へ進んでもよい。

ステップＳ４０９では、対戦支援部２１１は、成績を決定する。一例として、対戦支援部２１１は、サブ対戦ゲームが実行されている間に記憶部２２０に記録されていたゲーム情報１３２から勝敗、得点、奪三振数、安打数、および、本塁打数などを読み出して対戦成績を決定する。また、対戦支援部２１１は、マニュアル進行モードの期間におけるユーザのプレイに対する評価を読み出してプレイ成績を決定する。

ステップＳ４１０では、対戦支援部２１１は、決定した対戦成績およびプレイ成績に基づいて、サブ対戦ゲームをプレイしたユーザに付与する報酬を算定する。本実施形態では、一例として、対戦をプレイしたことの報酬として、交換ポイントがユーザに付与される。例えば、対戦支援部２１１は、勝敗加点８７２、プレイ加点８７３、および、デッキ加点８７４を決定し、それぞれを合計することにより、ユーザに付与する交換ポイントを算定する。

ステップＳ４１１では、対戦支援部２１１は、算定した報酬を、ユーザに付与する。本実施形態では、一例として、算定した交換ポイントを、上述のユーザのユーザ識別情報に関連付けて、ゲーム情報１３２として保存する。具体的には、対戦支援部２１１は、対戦前に累積された交換ポイントに対して、今回の対戦の報酬としての交換ポイントを加算して、ユーザのゲーム情報１３２を更新する。これにより、ユーザに、上述の報酬を獲得させることができる。対戦支援部２１１は、ユーザに付与した報酬の内容を、ユーザ端末１００に通知してもよい。

ステップＳ４１２では、ユーザ端末１００の対戦進行部１１５は、上述の通知を受信すると、例えば、図３０に示す報酬通知画面８７０を生成し、表示部１５２に表示させてもよい。

ステップＳ４１３では、対戦進行部１１５は、対戦支援部２１１からの報酬に係る通知に基づいて、記憶部１２０のゲーム情報１３２として記憶されている、ユーザが保有する交換ポイントの累積を更新し、ユーザに報酬を獲得させる。

これにより、カード取得部１１６は、累積された交換ポイントと引き換えに、キャラクタのカードをユーザに獲得させるための処理を実行することが可能となる。具体的には、カード取得部１１６は、図示しないポイント交換画面を表示させ、交換ポイントとアイテム、とりわけ、キャラクタのカードとの交換指示をユーザから受け付ける。例えば、操作受付部１１１は、ポイント交換画面を介して、交換ポイントをキャラクタのカードと交換する旨の指示をユーザから受け付ける。この場合、カード取得部１１６は、ユーザに指定されたキャラクタのカードに設定されている交換ポイントを、上述の交換ポイントの累積から減算し、該カードをユーザに獲得させるように、サーバ２００のカード提供部２１２に要求する。カード提供部２１２は、交換ポイントと引き換えに、該カードをユーザに獲得させる。

以上の構成および方法によれば、ユーザのレーティングおよび直前のメイン対戦ゲームにおける勝敗に基づいて決定された所定の確率にて、メイン対戦ゲームの合間に気軽に取り組めるサブ対戦ゲームが実行される。そして、サブ対戦ゲームがプレイされたことの報酬として、キャラクタのカードと交換可能な交換ポイントがユーザに付与される。これにより、メイン対戦ゲームをプレイするのとは別に、キャラクタのカードを獲得する方法をユーザに提供できる。結果として、ゲームをプレイする意欲をユーザが損なうことを回避することができる。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック（特に、対戦支援部２１１およびカード提供部２１２）、ならびに、制御部１１０の制御ブロック（特に、操作受付部１１１、表示制御部１１２、ＵＩ制御部１１３、アニメーション生成部１１４、対戦進行部１１５およびカード取得部１１６）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

後者の場合、制御部２１０または制御部１１０、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。

（項目１） ゲームプログラム（１３１）について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ（１０、２０）およびメモリ（１１、２１）を備えるコンピュータ（ユーザ端末１００およびサーバ２００の少なくとも一方）により実行される。ゲームプログラムは、プロセッサに、ユーザの操作にしたがって、該ユーザが所有する１以上のキャラクタで構成された自チームを編成するステップ（Ｓ１）と、編成された自チームを、マッチングされた相手チームと対戦させる第１対戦ゲーム（メイン対戦ゲーム）を進行させるステップ（Ｓ２）と、ユーザにより第１対戦ゲームがプレイされた場合に、キャラクタを獲得できる権利データ（パック）を、第１報酬として、該ユーザに付与するステップ（Ｓ３、Ｓ２０８）と、第１条件が満たされた場合に、権利データに基づいて特定された１以上のキャラクタをユーザに獲得させるステップ（Ｓ３、Ｓ２１８）と、第２条件が満たされた場合に、自チームを、ゲームプログラムにしたがって動作するキャラクタで構成された相手チーム（日本代表チーム）と対戦させる第２対戦ゲーム（サブ対戦ゲーム）を進行させるステップ（Ｓ６）と、ユーザにより第２対戦ゲームがプレイされた場合に、キャラクタ、または、該キャラクタと交換可能な価値（交換ポイント）を、第２報酬として、該ユーザに付与するステップ（Ｓ７）とを実行させる。これにより、第１対戦ゲームに加えて、第２対戦ゲームによっても、ユーザに対して、キャラクタを獲得する喜びを与えることができる。結果として、ゲームの興趣性を向上させるという効果を奏する。

（項目２） （項目１）において、ゲームプログラムは、プロセッサに、第２対戦ゲームの実行を制御するステップ（Ｓ４、Ｓ５）を実行させ、制御するステップは、自チームが第１対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、第２条件が満たされたと判断してもよい。これにより、第１対戦ゲームで勝利するために全力でプレイするようにユーザを促すことができ、第１対戦ゲームにおいて無気力なプレイを防止することができる。

（項目３） （項目２）において、制御するステップは、自チームと対戦させる相手チームを、強さが異なる複数のチームの中から決定し（Ｓ３０６）、第２報酬を付与するステップは、自チームが対戦する相手チームが強いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する第２報酬を付与してもよい。これにより、第２対戦ゲームをプレイする動機付けをユーザに与えることができる。

（項目４） （項目３）において、制御するステップは、自チームが第１対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、より強いチームを相手チームとして決定してもよい。これにより、第１対戦ゲームの成績が良いほど、第２対戦ゲームにおいて良い報酬を得ることが期待できるため、第１対戦ゲームをプレイする動機付けをユーザに与え、その習熟を促すことができる。

（項目５） （項目３）または（項目４）において、第１対戦ゲームを進行させるステップは、ユーザの対戦における強さを示す評価値（レーティング）を、第１対戦ゲームの勝敗に応じて増減させ、制御するステップは、評価値が示すユーザの対戦における強さが強いほど、強いチームを、より高い確率で相手チームとして決定してもよい。これにより、評価値が高いほど、第２対戦ゲームにおいて良い報酬を得ることが期待できるため、第１対戦ゲームをプレイする動機付けをユーザに与え、その習熟を促すことができる。

（項目６） （項目１）から（項目５）までのいずれか１項目において、第２報酬を付与するステップは、第２対戦ゲームの成績が良いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する第２報酬をユーザに付与してもよい。これにより、第２対戦ゲームをプレイする動機付けをユーザに与えることができる。

（項目７） （項目６）において、第２対戦ゲームを進行させるステップは、該第２対戦ゲームの一部を、ユーザが実施する操作にしたがってキャラクタを動作させるマニュアル進行モードにて進行させ、第２報酬を付与するステップは、マニュアル進行モードにて進行した一部の成績が良いほど、第２報酬を多く付与してもよい。これにより、第２対戦ゲームをプレイする動機付けをユーザに与えることができる。

（項目８） ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ、メモリおよび操作部を備えるコンピュータにより実行される。該方法は、プロセッサが（項目１）に記載の各ステップを実行する方法である。（項目８）に係る方法は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

（項目９） 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、（項目１）に係るゲームプログラムを記憶する記憶部（１２０、２２０）と、該ゲームプログラムを実行することにより、情報処理装置（ユーザ端末１００、サーバ２００）の動作を制御する制御部（１１０、２１０）とを備える。（項目９）に係る情報処理装置は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

１ ゲームシステム、２ ネットワーク、１０，２０ プロセッサ、１１，２１ メモリ、１２，２２ ストレージ、１３，２３ 通信ＩＦ、１４，２４ 入出力ＩＦ、１５ タッチスクリーン、１７ カメラ、１８ 測距センサ、１００ ユーザ端末（コンピュータ、情報処理装置）、１１０，２１０ 制御部、１１１ 操作受付部、１１２ 表示制御部、１１３ ＵＩ制御部、１１４ アニメーション生成部、１１５ 対戦進行部、１１６ カード取得部、１２０，２２０ 記憶部、１３１ ゲームプログラム、１３２ ゲーム情報、１３３ ユーザ情報、１５１ 入力部、１５２ 表示部、２００ サーバ（コンピュータ、情報処理装置）、２１１ 対戦支援部、２１２ カード提供部、１０１０ 物体、１０２０ コントローラ、１０３０ 記憶媒体

Claims (9)

1. ゲームプログラムであって、
   前記ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行されるものであり、
   前記ゲームプログラムは、前記プロセッサに、
   ユーザの操作にしたがって、該ユーザが所有する１以上のキャラクタで構成された自チームを編成するステップと、
   編成された前記自チームを、マッチングされた相手チームと対戦させる第１対戦ゲームを進行させるステップと、
   前記ユーザにより前記第１対戦ゲームがプレイされた場合に、キャラクタを獲得できる権利データを、第１報酬として、該ユーザに付与するステップと、
   第１条件が満たされた場合に、前記権利データに基づいて特定された１以上のキャラクタを前記ユーザに獲得させるステップと、
   前記ユーザにより前記第１対戦ゲームがプレイされた後、所定の確率にて、前記自チームの対戦を、コンピュータ対戦である第２対戦ゲームとして進行させるステップと、
   前記ユーザにより前記第２対戦ゲームがプレイされた場合に、キャラクタ、または、該キャラクタと交換可能な価値を、第２報酬として、該ユーザに付与するステップとを実行させる、ゲームプログラム。
2. 前記ゲームプログラムは、前記プロセッサに、
   前記第２対戦ゲームの実行を制御するステップを実行させ、
   前記制御するステップは、前記自チームが前記第１対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、前記第２対戦ゲームを、前記第２対戦ゲームとして進行させるステップにて実行することを決定する、請求項１に記載のゲームプログラム。
3. 前記制御するステップは、前記自チームと対戦させる前記相手チームを、強さが異なる複数のチームの中から決定し、
   前記第２報酬を付与するステップは、前記自チームが対戦する相手チームが強いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する前記第２報酬を付与する、請求項２に記載のゲームプログラム。
4. 前記制御するステップは、前記自チームが前記第１対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、より強いチームを前記相手チームとして決定する、請求項３に記載のゲームプログラム。
5. 前記第１対戦ゲームを進行させるステップは、ユーザの対戦における強さを示す評価値を、前記第１対戦ゲームの勝敗に応じて増減させ、
   前記制御するステップは、前記評価値が示す前記ユーザの対戦における強さが強いほど、強いチームを、より高い確率で前記相手チームとして決定する、請求項３または４に記載のゲームプログラム。
6. 前記第２報酬を付与するステップは、前記第２対戦ゲームの成績が良いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する前記第２報酬を前記ユーザに付与する、請求項１から５のいずれか１項に記載のゲームプログラム。
7. 前記第２対戦ゲームを進行させるステップは、該第２対戦ゲームの一部を、前記ユーザが実施する操作にしたがって前記キャラクタを動作させるマニュアル進行モードにて進行させ、
   前記第２報酬を付与するステップは、前記マニュアル進行モードにて進行した前記一部の成績が良いほど、前記第２報酬を多く付与する、請求項６に記載のゲームプログラム。
8. コンピュータがゲームプログラムを実行する方法であって、
   前記コンピュータは、プロセッサおよびメモリを備え、
   前記プロセッサが請求項１に記載の各ステップを実行する方法。
9. 情報処理装置であって、
   前記情報処理装置は、
   請求項１に記載のゲームプログラムを記憶する記憶部と、
   該ゲームプログラムを実行することにより、情報処理装置の動作を制御する制御部とを備えている、情報処理装置。

Images