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

Abstract

【課題】抽選の興趣性を損なうことなく、所望のゲーム媒体を入手したいというユーザの欲求に応える。【解決手段】ゲームプログラム（１３１）は、プロセッサ（１０）に、ゲームプログラムに基づくゲームで利用できる１以上のゲーム媒体を獲得するために使用されるデジタルデータのうち、第１の権利を、該ゲームにおいて第１の条件が満たされたことによりユーザに獲得させるステップ（Ｓ４）と、デジタルデータのうち、第２の権利を、該ゲームにおいて第２の条件が満たされたことによりユーザに獲得させるステップ（Ｓ１０）と、第１の権利または第２の権利が１つ使用されたことに応じて、抽選を複数回実行し、各回につき当選させるゲーム媒体を特定するステップ（Ｓ７）と、を実行させ、特定するステップは、第２の権利に基づいて実行する複数回の抽選のうち少なくとも１回について、ユーザが指定した属性と同じ属性が関連付けられたゲーム媒体を当選させる。【選択図】図４

Description

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

従来、キャラクタカードなどのゲーム媒体を用いてユーザがプレイするゲームが知られている。ゲーム媒体とは、該ゲームのゲームプログラムが実行されている間、該ゲームプログラム実行するコンピュータによって処理されるデジタルデータのことである。具体的には、上述したキャラクタカード（以下、キャラクタと称する）、または、ゲームを有利に進めるためのアイテムなどである。ゲーム媒体は、以下のように有償または無償でユーザに提供される。

例えば、ゲーム上で金銭的な価値を有するゲーム内価値（例えば、仮想通貨、コイン、宝石、クリスタル、ポイントなどの有価媒体）をユーザに販売することが広く行われている。そして、該有価媒体をユーザに保有させ、該価値が消費されることにより、ゲーム上で利用される各種サービス（ゲーム媒体の付与など）を該ユーザに提供することが行われている。非特許文献１には、ユーザによって保有されている仮想通貨と引き換えに、キャラクタをユーザに獲得させるための抽選ゲームのサービスを行うことができる技術が開示されている。

また、例えば、ユーザがゲームをプレイした場合（一例として、クエストまたは対戦などを所定回数プレイした場合、または、所定の課題をクリアした場合など）に、その報酬として、ゲーム媒体をユーザに無償で獲得させることが広く行われている。

プロ野球スピリッツＡ攻略まとめ名鑑、"〔プロスピＡ〕自チーム確定スカウトは回すべき？１０回目はＳランク確率２倍"、[online］、２０１７年６月３０日、プロ野球スピリッツＡ攻略まとめ名鑑，［２０１８年３月１２日検索］、インターネット（ＵＲＬ：http://xn--a-39tzcn0z5bh0kza6q4a7209hpx1boi3b6letm2ly6i.com/post-15148/）

一般に、ユーザに長くプレイさせることを意図して開発されたゲームにおいては、ユーザがゲームに飽きるという問題に如何に対処するかは重要である。特に、上述のようなキャラクタをデッキに編成して楽しむゲームでは、様々な種類のキャラクタを用意して、キャラクタを獲得する喜び、および、獲得したキャラクタでチームを編成する楽しみを、ユーザに与えることが求められる。

しかしながら、上述の従来技術には、以下の問題が生じる。具体的には、非特許文献１に記載のゲームでは、所望の属性を有したゲーム媒体（特定のチームに所属する選手カード）が確実に手に入るので、所望の属性のゲーム媒体を入手したいというユーザの欲求には十二分に応えることができる反面、抽選の興趣性、遊戯性が損なわれるという問題がある。具体的には、抽選結果を待つまでの間にユーザが抱くであろう期待、緊張、または、興奮などは、その程度が著しく減じられる。また、例えば、当選後において、ユーザが目当ての選手カードを引き当てたとしても、そのときの喜び、または、高揚感などの程度が著しく減じられる。

本開示の一態様は、抽選の興趣性を損なうことなく、所望のゲーム媒体を入手したいというユーザの欲求に応えることを目的とする。

本開示に係るゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームで利用できる１以上のゲーム媒体を獲得するために使用されるデジタルデータのうち、第１の権利を、該ゲームにおいて第１の条件が満たされたことによりユーザに獲得させるステップと、デジタルデータのうち、第２の権利を、該ゲームにおいて第２の条件が満たされたことによりユーザに獲得させるステップと、第１の権利または第２の権利が１つ使用されたことに応じて、抽選を複数回実行し、各回につき当選させるゲーム媒体を特定するステップと、を実行させ、特定するステップは、第２の権利に基づいて実行する複数回の抽選のうち少なくとも１回について、ユーザが指定した属性と同じ属性が関連付けられたゲーム媒体を当選させる。

本開示の一態様によれば、抽選の興趣性を損なうことなく、所望のゲーム媒体を入手したいというユーザの欲求に応えることができるという効果を奏する。

ゲームシステムのハードウェア構成を示す図である。 ユーザ端末およびサーバの機能的構成を示すブロック図である。 パックの外観の具体例を示す図である。 本実施形態に係るゲームプログラムに基づいて、ゲームシステムにおいて実行される処理の流れを示すフローチャートである。 デッキ詳細情報のデータ構造の一例を示す図である。 デッキ概要情報のデータ構造の一例を示す図である。 デッキ選択画面の一例を示す図である。 野手デッキ編成画面の一例を示す図である。 投手デッキ編成画面の一例を示す図である。 パック通知画面の具体例を示す図である。 パック運用画面の具体例を示す図である。 パック運用画面の他の具体例を示す図である。 キャラクタ通知画面の具体例を示す図である。 本実施形態に係るゲームプログラムに基づいて、ゲームシステムにおいて実行される処理の流れを示すフローチャートである。 ボックスを購入してカードを獲得する仕組みを説明する図である。 管理データのデータ構造の一例を示す図である。 チケット獲得画面の具体例を示す図である。 メニュー画面の具体例を示す図である。 ボックス購入画面の具体例を示す図である。 開梱結果画面の具体例を示す図である。 最終結果画面の具体例を示す図である。 本実施形態に係るゲームプログラムに基づいて、ゲームシステムにおいて実行される処理の流れを示すフローチャートである。 抽選データベースのデータ構造の一例を示す図である。 確率表のデータ構造の一例を示す図である。 ユーザ端末またはサーバが実行するパック開封処理の流れを示すフローチャートである。

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

＜ゲームシステム１のハードウェア構成＞
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（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 (14)

1. ゲームプログラムであって、
   前記ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行されるものであり、
   前記ゲームプログラムは、前記プロセッサに、
   前記ゲームプログラムに基づくゲームで利用できる１以上のゲーム媒体を獲得するために使用されるデジタルデータのうち、第１の権利を、該ゲームにおいて第１の条件が満たされたことによりユーザに獲得させるステップと、
   前記デジタルデータのうち、第２の権利を、該ゲームにおいて第２の条件が満たされたことにより前記ユーザに獲得させるステップと、
   前記第１の権利または前記第２の権利が１つ使用されたことに応じて、抽選を複数回実行し、各回につき当選させるゲーム媒体を特定するステップと、を実行させ、
   前記特定するステップは、前記第２の権利に基づいて実行する複数回の抽選のうち少なくとも１回について、前記ユーザが指定した属性と同じ属性が関連付けられたゲーム媒体を当選させる、ゲームプログラム。
2. 前記メモリには、前記ゲーム媒体の当選確率を示す確率情報が記憶されており、前記確率情報は、前記権利の種類ごと、かつ、該権利に基づく抽選の回ごとに設定され、
   前記特定するステップは、使用された前記権利に設定されている回ごとの確率情報に基づいて、各回の抽選を実行する、請求項１に記載のゲームプログラム。
3. 前記特定するステップは、前記ユーザが指定した属性と同じ属性が関連付けられた同属性ゲーム媒体の当選を保証する第１付加価値が付加された第２の権利に基づく前記複数回の抽選のうち少なくとも１回の抽選を、前記同属性ゲーム媒体が確実に当選するように設定された確率情報に基づいて実行する、請求項２に記載のゲームプログラム。
4. 前記特定するステップは、ゲーム上での価値の高さを示す希少度が所定以上である高希少度ゲーム媒体の当選を保証する第２付加価値が付加された第２の権利に基づく前記少なくとも１回の抽選を、前記高希少度ゲーム媒体が確実に当選するように設定された確率情報に基づいて実行する、請求項２または３に記載のゲームプログラム。
5. 前記特定するステップは、当選可能期間が限定されている限定ゲーム媒体が当選する可能性がある第３付加価値が付加された第１の権利および第２の権利に基づく複数回の抽選を、前記限定ゲーム媒体の当選確率が、０％よりも高くなるように設定された確率情報に基づいて実行する、請求項２から４のいずれか１項に記載のゲームプログラム。
6. 前記第２の権利をユーザに獲得させるステップは、前記第２の条件が満たされたことにより、複数の権利が紐付けられている権利集合媒体をユーザに獲得させ、
   該権利集合媒体には、前記第２の権利が少なくとも１つ紐付けられている、請求項１から５のいずれか１項に記載のゲームプログラム。
7. 前記第２の権利を獲得させるステップは、前記ユーザが前記権利集合媒体を獲得した場合に限り、前記第２の権利を該ユーザに獲得させる、請求項６に記載のゲームプログラム。
8. 前記第１の権利を獲得させるステップは、前記ユーザが前記ゲームをプレイしたことに基づいて、前記第１の条件が満たされたと判断し、
   前記第２の権利を獲得させるステップは、前記ユーザが前記権利集合媒体を購入するための操作を実施したことに基づいて、前記第２の条件が満たされたと判断する、請求項７に記載のゲームプログラム。
9. 前記ゲームプログラムは、前記プロセッサに、
   前記ゲームにおいて前記第１の条件が満たされたことにより、前記権利集合媒体を購入する権利である第３の権利を前記ユーザに獲得させるステップを実行させ、
   前記第２の権利を獲得させるステップは、前記ユーザが前記第３の権利を使用した上で、前記権利集合媒体を購入するための操作を実施したことに基づいて、前記第２の条件が満たされたと判断する、請求項７に記載のゲームプログラム。
10. 前記ゲームプログラムは、前記プロセッサに、
    前記権利集合媒体に紐付けられている複数の権利のそれぞれについて、権利の種類を決定するステップをさらに実行させ、
    前記権利の種類を決定するステップは、
    （１）第１の権利および第２の権利の区別、
    （２）特定のゲーム媒体の当選確率を上げる付加価値の有無、および、該付加価値の種類、ならびに、
    （３）前記ゲーム上の価値の高さが所定値以上であるゲーム媒体の当選のし易さを示すグレード、の少なくともいずれか１項目を抽選で決定することにより、前記権利の種類を決定する、請求項６から９のいずれか１項に記載のゲームプログラム。
11. 前記権利集合媒体には、提供する付加価値の種類に応じた複数の種類があり、前記ユーザに獲得される該権利集合媒体の種類は、抽選により決定され、
    前記権利の種類を決定するステップは、
    前記ユーザが指定した属性と同じ属性が関連付けられた同属性ゲーム媒体の当選を保証する第１付加価値を提供する第１種の権利集合媒体には、該第１付加価値が付加された第２の権利を少なくとも１つ紐付け、
    前記ゲーム上での価値の高さを示す希少度が所定以上である高希少度ゲーム媒体の当選を保証する第２付加価値を提供する第２種の権利集合媒体には、該第２付加価値が付加された第２の権利を少なくとも１つ紐付け、
    当選可能期間が限定されている限定ゲーム媒体の当選確率が他の種類の権利よりも高くなる第３付加価値を提供する第３種の権利集合媒体には、該第３付加価値が付加された第１の権利または第２の権利を少なくとも１つ紐付ける、請求項１０に記載のゲームプログラム。
12. 前記ゲーム媒体はキャラクタであり、前記ゲームは、前記ユーザが所有する１以上のキャラクタで構成された自チームを相手チームと対戦させる対戦ゲームであり、
    前記メモリには、前記自チームの編成がそれぞれ異なる第１デッキと第２デッキとが記憶されており、
    前記第２デッキは、前記ユーザが指定した属性と同じ属性を有する１以上のキャラクタを含む場合に、対戦において有利な効果を発動させる性質を有する、請求項１から１１のいずれか１項に記載のゲームプログラム。
13. コンピュータがゲームプログラムを実行する方法であって、
    前記コンピュータは、プロセッサおよびメモリを備え、
    前記プロセッサが請求項１に記載の各ステップを実行する方法。
14. 情報処理装置であって、
    前記情報処理装置は、
    請求項１に記載のゲームプログラムを記憶する記憶部と、
    該ゲームプログラムを実行することにより、情報処理装置の動作を制御する制御部とを備えている、情報処理装置。

Images