〔実施形態1〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<ゲームシステム1のハードウェア構成>
図1は、ゲームシステム1のハードウェア構成を示す図である。ゲームシステム1は図示の通り、複数のユーザ端末100と、サーバ200とを含む。各ユーザ端末100は、サーバ200とネットワーク2を介して接続する。ネットワーク2は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂3G、4G移動通信システム、LTE(Long Term Evolution)、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク(例えばWi-Fi(登録商標))等が挙げられる。
サーバ200(コンピュータ、情報処理装置)は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ200は、プロセッサ20と、メモリ21と、ストレージ22と、通信IF23と、入出力IF24とを備える。サーバ200が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
ユーザ端末100(コンピュータ、情報処理装置)は、スマートフォン、フィーチャーフォン、PDA(Personal Digital Assistant)、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末100は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末100は図示の通り、プロセッサ10と、メモリ11と、ストレージ12と、通信インターフェース(IF)13と、入出力IF14と、タッチスクリーン15(表示部)と、カメラ17と、測距センサ18とを備える。ユーザ端末100が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末100は、タッチスクリーン15に代えて、または、加えて、ユーザ端末100本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF14を備えていてもよい。
また、図1に示すように、ユーザ端末100は、1つ以上のコントローラ1020と通信可能に構成されることとしてもよい。コントローラ1020は、例えば、Bluetooth(登録商標)等の通信規格に従って、ユーザ端末100と通信を確立する。コントローラ1020は、1つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末100へ送信する。また、コントローラ1020は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末100へ送信する。
なお、ユーザ端末100がカメラ17および測距センサ18を備えることに代えて、または、加えて、コントローラ1020がカメラ17および測距センサ18を有していてもよい。
ユーザ端末100は、例えばゲーム開始時に、コントローラ1020を使用するユーザに、該ユーザの名前またはログインID等のユーザ識別情報を、該コントローラ1020を介して入力させることが望ましい。これにより、ユーザ端末100は、コントローラ1020とユーザとを紐付けることが可能となり、受信した出力値の送信元(コントローラ1020)に基づいて、該出力値がどのユーザのものであるかを特定することができる。
ユーザ端末100が複数のコントローラ1020と通信する場合、各コントローラ1020を各ユーザが把持することで、ネットワーク2を介してサーバ200などの他の装置と通信せずに、該1台のユーザ端末100でマルチプレイを実現することができる。また、各ユーザ端末100が無線LAN(Local Area Network)規格等の無線規格により互いに通信接続する(サーバ200を介さずに通信接続する)ことで、複数台のユーザ端末100によりローカルでマルチプレイを実現することもできる。1台のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、ユーザ端末100は、さらに、サーバ200が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末100は、サーバ200が備える後述する種々の機能を分散して備えていてもよい。
なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末100はサーバ200と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ200に送信してもよい。
また、コントローラ1020は、ユーザ端末100に着脱可能な構成であるとしてもよい。この場合、ユーザ端末100の筐体における少なくともいずれかの面に、コントローラ1020との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末100とコントローラ1020とが結合している場合は、ユーザ端末100とコントローラ1020とは、有線を介して信号を送受信する。
図1に示すように、ユーザ端末100は、外部のメモリカード等の記憶媒体1030の装着を、入出力IF14を介して受け付けてもよい。これにより、ユーザ端末100は、記憶媒体1030に記録されるプログラム及びデータを読み込むことができる。記憶媒体1030に記録されるプログラムは、例えばゲームプログラムである。
ユーザ端末100は、サーバ200等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末100のメモリ11に記憶してもよいし、記憶媒体1030から読み込むことにより取得したゲームプログラムをメモリ11に記憶してもよい。
以上で説明したとおり、ユーザ端末100は、該ユーザ端末100に対して情報を入力する機構の一例として、通信IF13、入出力IF14、タッチスクリーン15、カメラ17、および、測距センサ18を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
例えば、操作部が、カメラ17および測距センサ18の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末100の近傍の物体1010を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体1010としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体1010の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末100は、カメラ17の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ(ユーザの手の一連の動き)を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。
あるいは、操作部がタッチスクリーン15で構成される場合、ユーザ端末100は、タッチスクリーン15の入力部151に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF13で構成される場合、ユーザ端末100は、コントローラ1020から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF14で構成される場合、該入出力IF14と接続されるコントローラ1020とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<ゲーム概要>
ゲームシステム1は、一例として、ゲームプログラムに基づいて、各ユーザが操作する各ユーザ端末100(クライアント)が通信して対戦を進行させる、通信対人対戦ゲームを実行するためのシステムである。
ゲームシステム1は、特定のジャンルに限らず、あらゆるジャンルのゲームを実行するためのシステムであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、RPG、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。
ゲームシステム1は、一例として、通信対人対戦ゲームとして、野球の試合を進行させる、通信対人対戦型の野球ゲーム(以下、本ゲーム、本野球ゲームと称することがある)を実行する。
ゲームシステム1が実行する野球ゲームでは、サーバ200(情報処理装置)を介して通信する第1のユーザ端末100と第2のユーザ端末100とによって、それぞれのチームが操作される。チームは、1または複数のオブジェクトを、ユーザがデッキに組み入れることにより生成される。オブジェクトは、本ゲームにおいて、対戦の進行に何らかの作用を及ぼすデジタルデータである。1以上のオブジェクトによって構成された各ユーザのデッキの強さが、少なくとも、対戦の進行に作用する。オブジェクトは、例えば、キャラクタであり、キャラクタは、例えば、野球の試合に参加して相手チームの選手と対決する野球の選手、または、該選手が試合を有利に進められるように選手を支援する球団のマスコットである。本ゲームでは、選手およびマスコットは、一例として、カードという形態で表現される。本ゲームでは、属性として、選手およびマスコットには、そのキャラクタが所属する球団を示す「所属球団」が設定されている。
本野球ゲームにおいて、ユーザによって対人の対戦がプレイされることにより、プレイ内容に対する評価結果(勝敗、記録、スコアなどの対戦の成績)が出力される。また、該ゲームにおいては、ユーザが対戦をプレイしたことに対して報酬が付与される。該報酬は、例えば、上述のオブジェクトを1以上取得できる権利をユーザに与えるための権利データである。具体的には、選手のカードが所定枚数封入されたパックである。パックを開封することにより、ユーザは、該パックに封入されたカードを入手することができる。そして、入手したカードをデッキに組み入れて、該カードが表している選手を対戦で利用できるようになる。また、パックには、マスコットのカードが封入されていてもよい。ユーザは、パックから入手したマスコットのカードをデッキに組み入れて、同じくデッキに組み入れられている選手を支援させ、対戦を有利に進行させることができる。
本野球ゲームでは、一例として、報酬として与えられたパックは、ユーザに獲得されただけでは開封されない。パックは、ユーザが所有するスロットにセットされた上で、該パックに関連付けてカウントされているパックポイントが所定値に到達した場合に開封可能となる。パックポイントは、ユーザが対戦をプレイする度に、これも対戦をプレイしたことの報酬として、該ユーザに付与され、該ユーザが所有する各パックに割り振られる。
ユーザは、対戦をプレイするほどに多くのパックを入手し、また、多くのパックポイントを獲得する。すなわち、ユーザは、対戦を数多くプレイするほど、より多くのパックを開封し、より多くのカード(選手またはマスコットなどのキャラクタ)を所有することができる。そして、より強い選手または性能の高いマスコットをデッキに組み入れることによりデッキ全体を強化して、対戦を有利に進めることが可能となる。
本野球ゲームは、1イニングにつき、表と裏でチームの攻守が入れ替わりつつ進行する。以下では、あるイニングの表または裏において、守備側のチームを操作するユーザ端末100と、攻撃側のユーザ端末100とを互いに区別する必要がある場合、前者を投球側ユーザ端末100A、後者を打撃側ユーザ端末100Bと称する。両者を区別する必要がない場合には、単に、ユーザ端末100と称する。投球側ユーザ端末100Aのユーザを、投球側ユーザ、打撃側ユーザ端末100Bのユーザを、打撃側ユーザと称する。ただし、両ユーザを特に区別する必要がない場合、および、その区別が明らかな場合には、単にユーザと称する。投球側ユーザは、投球側ユーザ端末100Aを用いて、投手キャラクタによる投球を操作し、攻撃側ユーザは、打撃側ユーザ端末100Bを用いて、打者キャラクタによる打撃を操作する。
投球側ユーザ端末100Aは、投球側ユーザから受け付けた投球操作に応じて投球結果を決定し、該投球結果を含むデータ(図1に示す投球結果D1)を生成し、サーバ200に送信する。投球結果D1は、サーバ200を介して、対戦相手の打撃側ユーザ端末100Bに送信される。投球操作とは、投球側ユーザが、投手キャラクタに投球させるために、投球側ユーザ端末100Aの入力部151に対して実施する操作のことである。
打撃側ユーザ端末100Bは、打撃側ユーザから受け付けた打撃操作に応じて打撃結果を決定し、該打撃結果を含むデータ(図1に示す打撃結果D2)を生成し、サーバ200に送信する。打撃結果D2は、サーバ200を介して、対戦相手の投球側ユーザ端末100Aに送信される。打撃操作とは、打撃側ユーザが、打者キャラクタにボールを打撃させるために、打撃側ユーザ端末100Bの入力部151に対して実施する操作のことである。
本野球ゲームにおいて、ユーザは、自身でキャラクタを制御することを希望しない場合に、ユーザ端末100を操作して、サーバ200に対してその旨を通知することができる。サーバ200は、このような通知をユーザ端末100から受信すると、ゲームプログラムにしたがって、進行している対戦に関わる各種情報に基づいて、該キャラクタの動作結果(投球結果または打撃結果)を決定する。そして、決定した動作結果を対戦相手のユーザ端末100に送信する。すなわち、サーバ200は、ユーザ端末100に代わり、該キャラクタを制御する。
<各装置のハードウェア構成要素>
プロセッサ10は、ユーザ端末100全体の動作を制御する。プロセッサ20は、サーバ200全体の動作を制御する。プロセッサ10および20は、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、およびGPU(Graphics Processing Unit)を含む。
プロセッサ10は後述するストレージ12からプログラムを読み出し、後述するメモリ11に展開する。プロセッサ20は後述するストレージ22からプログラムを読み出し、後述するメモリ21に展開する。プロセッサ10およびプロセッサ20は展開したプログラムを実行する。
メモリ11および21は主記憶装置である。メモリ11および21は、ROM(Read Only Memory)およびRAM(Random Access Memory)等の記憶装置で構成される。メモリ11は、プロセッサ10が後述するストレージ12から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ10に作業領域を提供する。メモリ11は、プロセッサ10がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ21は、プロセッサ20が後述するストレージ22から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ20に作業領域を提供する。メモリ21は、プロセッサ20がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
本実施形態においてプログラムとは、ゲームをユーザ端末100により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末100とサーバ200との協働により実現するためのゲームプログラムであってもよい。なお、ユーザ端末100とサーバ200との協働により実現されるゲームは、一例として、ユーザ端末100において起動されたブラウザ上で実行されるゲームであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末100の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末100とサーバ200との間または複数のユーザ端末100間で送受信する指示または通知を含んでいる。
ストレージ12および22は補助記憶装置である。ストレージ12および22は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12およびストレージ22には、ゲームに関する各種データが格納される。
通信IF13は、ユーザ端末100における各種データの送受信を制御する。通信IF23は、サーバ200における各種データの送受信を制御する。通信IF13および23は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
入出力IF14は、ユーザ端末100がデータの入力を受け付けるためのインターフェースであり、またユーザ端末100がデータを出力するためのインターフェースである。入出力IF14は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14は、例えば、ユーザ端末100の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ200の入出力IF24は、サーバ200がデータの入力を受け付けるためのインターフェースであり、またサーバ200がデータを出力するためのインターフェースである。入出力IF24は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
ユーザ端末100のタッチスクリーン15は、入力部151と表示部152とを組み合わせた電子部品である。入力部151は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
入力部151は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。
図示していないが、ユーザ端末100は、該ユーザ端末100の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末100がセンサを備えている場合、プロセッサ10は、センサの出力からユーザ端末100の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10は、ユーザ端末100が縦向きに保持されているときには、縦長の画像を表示部152に表示させる縦画面表示としてもよい。一方、ユーザ端末100が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10は、ユーザ端末100の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
カメラ17は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。
測距センサ18は、測定対象物までの距離を測定するセンサである。測距センサ18は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ18は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ18は、指向性を有する光を発する光源を有することとしてもよい。
ここで、ユーザ端末100が、カメラ17と測距センサ18とを用いて、ユーザ端末100の近傍の物体1010を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ17および測距センサ18は、例えば、ユーザ端末100の筐体の側面に設けられてもよい。カメラ17の近傍に測距センサ18が設けられてもよい。カメラ17としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ17に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ17の撮影画像に基づく物体の検出精度をいっそう向上させることができる。
プロセッサ10は、カメラ17の撮影画像に対して、例えば以下の(1)〜(5)に示す処理のうち1つ以上の処理を行ってもよい。(1)プロセッサ10は、カメラ17の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ10は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。(2)また、プロセッサ10は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ10は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数(伸びている指の本数)を特定する。プロセッサ10はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ10は、指の本数が5本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が0本である(指が検出されなかった)場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が2本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。(3)プロセッサ10は、カメラ17の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。(4)プロセッサ10は、カメラ17の撮影画像の画像認識結果、および、測距センサ18の出力値等の少なくともいずれか1つに基づいて、ユーザ端末100の近傍の物体1010(ユーザの手など)とユーザ端末100との距離を検出する。例えば、プロセッサ10は、カメラ17の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末100の近傍(例えば所定値未満の距離)にあるのか、遠く(例えば所定値以上の距離)にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ10は、ユーザの手がユーザ端末100に接近しているのか遠ざかっているのかを検出してもよい。(5)カメラ17の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末100とユーザの手との距離が変化していることが判明した場合、プロセッサ10は、ユーザが手をカメラ17の撮影方向において振っていると認識する。カメラ17の撮影範囲よりも指向性が強い測距センサ18において、物体が検出されたりされなかったりする場合に、プロセッサ10は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。
このように、プロセッサ10は、カメラ17の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か(「グー」のジェスチャであるか、それ以外のジェスチャ(例えば「パー」)であるか)を検出する。また、プロセッサ10は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ10は、ユーザがこの手をユーザ端末100に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末100は、例えば、ユーザの手の移動に応じて、タッチスクリーン15においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末100は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末100は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作(またはドラッグ操作)に対応する操作として認識することもできる。また、ユーザ端末100は、カメラ17の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。
<ゲームシステム1の機能的構成>
図2は、ゲームシステム1に含まれるサーバ200およびユーザ端末100の機能的構成を示すブロック図である。サーバ200およびユーザ端末100のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。
ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、および入出力IF14等の協働によって、制御部110および記憶部120として機能する。
サーバ200は、各ユーザ端末100と通信して、各ユーザ端末100が通信対戦ゲームを進行させるのを支援する機能を有する。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部220として機能する。
記憶部120および記憶部220は、ゲームプログラム131、ゲーム情報132およびユーザ情報133を格納する。ゲームプログラム131は、ユーザ端末100およびサーバ200で実行するゲームプログラムである。ゲーム情報132は、制御部110および制御部210がゲームプログラム131を実行する際に参照するデータである。ユーザ情報133は、ユーザのアカウントに関するデータである。記憶部220において、ゲーム情報132およびユーザ情報133は、ユーザ端末100ごとに格納されている。
(サーバ200の機能的構成)
制御部210は、記憶部220に格納されたゲームプログラム131を実行することにより、サーバ200を統括的に制御する。例えば、制御部210は、ユーザ端末100に各種データおよびプログラム等を送信する。制御部210は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末100から受信する。ゲームがマルチプレイゲームである場合には、制御部210は、ユーザ端末100からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末100に送信してもよい。
制御部210は、ゲームプログラム131の記述に応じて、対戦支援部211、および、カード提供部212として機能する。制御部210は、実行するゲームの性質に応じて、ユーザ端末100におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。
対戦支援部211は、各ユーザ端末100が通信対戦ゲームを進行させるのを支援する。具体的には、対戦支援部211は、対戦する各ユーザ端末100と通信して、ユーザ端末100同士のやりとりを仲介する。さらに、対戦支援部211は、対戦相手のマッチング、対戦の進行状況の同期をとるための同期制御などを実行する。また、対戦支援部211は、対戦の成績に基づいて報酬を算定したり、報酬の内容をユーザ端末100に通知して、ユーザに報酬を付与したりする。
カード提供部212は、ユーザ端末100からの要求に応じて、ユーザに、対戦で利用可能なオブジェクトを提供する。本実施形態では、カード提供部212は、デッキに組み入れて対戦で利用することが可能なキャラクタのカードを提供する。本実施形態では、ユーザにカードを獲得させる方法が2つある。第1の方法は、上述のパック(第1報酬)が運用されたことに基づいて、カード提供部212が該パックに対応するカードを提供する方法である。カード提供部212は、提供されるカードを、パックに設定されているランクに基づいて抽選などによって特定してもよい。パックは、本野球ゲームのメイン要素である、上述の対人対戦(以下、メイン対戦ゲーム)がプレイされたことの報酬として、ユーザに付与される。第2の方法は、ユーザが所有するゲーム内の価値(仮想通貨、ポイント、ジュエルなど)と引き換えに、カード提供部212が該価値に見合うカードを提供する方法である。カード提供部212は、ユーザが選択したカードを上述の価値と交換で直接的に提供してもよいし、該カードをユーザに獲得させることを可能にするアイテム(例えば、抽選チケットなど)を上述の価値と交換することにより、間接的にカードを提供してもよい。ゲーム内の価値は、本野球ゲームのサブ要素である、後述のコンピュータ対戦(以下、サブ対戦ゲーム)がプレイされたことの報酬として、ユーザに付与される。本実施形態では、一例として、ゲーム内の価値は、交換ポイントと称される。ユーザは、サブ対戦ゲームをプレイすることにより交換ポイント(第2報酬)を貯め、貯めた交換ポイントを予め定められた量消費することにより、該量に見合った価値を持つカードを獲得することができる。
第1の方法を実現する第1のカード獲得処理において、本実施形態では、カード提供部212は、ユーザ端末100のカード取得部116から指定されたカードパックに基づいて、該カードパックに対応する選手カードを特定する。そして、カード提供部212は、特定したカードをカード取得部116に通知することにより、ユーザにカードを提供する。本実施形態では、カード提供部212は、指定されたカードパックと引き換えに抽選を実施して、提供すべき選手カードを特定してもよい。
本実施形態では、権利データには、ゲームを有利に進める上で価値が高いオブジェクトが取得できる可能性を表す期待値が設定されていてもよい。具体的には、期待値とは、上述の抽選において、良いカードを引き当てる確率である。良いカードとは、対戦を有利に進める上で価値が高いとされるカードであり、対戦における能力が高い選手の選手カードを指す。本実施形態では、カードパックのそれぞれには、能力が高い選手の選手カードが当選する期待値が設定されている。
本実施形態では、選手カードには、上述の価値の高さを表す希少度が設定されており、例えば、希少度が高い(能力が高い)順に、S、A、B、Cの4種類がある。抽選において、希少度が高いほど当選する確率は低くなる。以下では、特に、期待値という用語を用いる場合には、対戦を有利に進める上で価値が高い選手カードとして、Sの希少度が設定されている選手カードを引き当てる確率を意味する。
より具体的には、カードパックには、4種類のランクが設定されていてもよい。本実施形態では、ブラック、ゴールド、シルバー、ノーマルの4種類のランクのいずれかが、カードパックに付与される。本実施形態では、カードパックのランクに応じて、当該カードパックにおいて、期待値、すなわち、希少度Sの選手カードを引き当てる確率がそれぞれ異なる。各ランクのカードパックに設定されている期待値は、一例として、ランクが高いカードパックから順に、ブラックは20%、ゴールドは10%、シルバーは5%、ノーマルは0.5%であってもよい。なお、各ランクにおける、希少度A以降の抽選確率は、希少度が下がるにつれて抽選確率が上がるように適宜設定されてもよいし、一律に設定されてもよい。例えば、ゴールドランクのカードパックにおいて、希少度A以降の抽選確率は、それぞれ一律30%であってもよい。
別の実施形態では、カードパックのランクに基づいて、すべての希少度ごとに期待値が設定されていてもよい。一例として、カード提供部212が、ノーマルランクのカードパックに基づいて、各希少度の選手カードを引き当てる確率は、S:0.5%、A:5.5%、B:44%、C:50%であってもよい。カード提供部212が、ブラックランクのカードパックに基づいて、各希少度の選手カードを引き当てる確率は、例えば、S:20%、A:25%、B:35%、C:20%であってもよい。
いずれの実施形態においても、希少度Sの期待値は、ランクが上がるにつれて高くなるように、それぞれのランクのカードパックに設定されていることが好ましい。カードパックは、開封前から期待値が分かるように、ランクごとに異なる態様でユーザに提示されてもよい。カードパックは、表示部152に提示される際、大きさ、色、形、装飾、または、文字などの表示の態様が、ランクごとに異なっていることが好ましい。これにより、ユーザは、開封前から、自身が入手したカードパックに基づいて、希少度Sの選手カードを取得できる確率を推測することができる。これにより、戦略的にカードパックを開封することが可能となり、ゲームの興趣性を向上させることができる。
本実施形態では、対戦支援部211は、報酬を算定する際、対戦のプレイ結果に応じた期待値が設定された権利データを、対戦をプレイしたユーザに付与する。具体的には、対戦の成績が良いほど、ランクの高いカードパックが付与されるように、報酬を算定する。
第2の方法を実現する第2のカード獲得処理において、本実施形態では、カード提供部212は、交換ポイントと交換することが可能なキャラクタのカードの一覧を、交換に必要なポイント数とともにユーザ端末100に提供する。ユーザ端末100のカード取得部116は、交換ポイントと交換したキャラクタの指定をユーザから受け付ける。カード提供部212は、ユーザ端末100のカード取得部116からキャラクタのカードを交換する要求を受け付けると、所定の交換ポイントと引き換えに、要求されたキャラクタのカードをユーザ端末100に提供する。
(ユーザ端末100の機能的構成)
制御部110は、記憶部120に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131およびユーザの操作にしたがって、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。
制御部110は、ゲームプログラム131の記述に応じて、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、対戦進行部115、および、カード取得部116として機能する。制御部110は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。
操作受付部111は、入力部151に対するユーザの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
例えば、操作受付部111は、入力部151に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部111は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部111は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
UI制御部113は、ユーザインターフェース(以下、UI)を構築するために表示部152に表示させるUI部品を制御する。UI部品は、ユーザが、ゲームの進行上必要な入力をユーザ端末100に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末100から得るためのツールである。UI部品は、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。
また、対戦進行中、とりわけ、投球操作、または、打撃操作を支援するためのUI部品の表示態様を制御する。打撃操作を支援するUI部品としては、例えば、打撃の良好なタイミングを示すタイミングヒントオブジェクト、投手キャラクタから投げられたボール、投球の進行方向の変化を示す方向ヒントオブジェクト、投球の到達予定位置を示す位置ヒントオブジェクト、および、バットとボールとの当たりを判定するためのミートカーソル等がある。投球操作を支援するUIオブジェクトとしては、例えば、球種選択オブジェクト、コース提示オブジェクト、コース選択オブジェクト、および、投球タイミングオブジェクト等がある。
アニメーション生成部114は、上述のUI部品を含む各種のオブジェクトの制御態様に基づいて、各オブジェクトのモーションを示すアニメーションを生成する。例えば、投手の投球動作のアニメーション、打者の打撃動作のアニメーション、該打者が振るバットのアニメーション、投手によって投げられたボールのアニメーション、打者によって打たれたボールのアニメーション、走者が盗塁するアニメーション等を生成してもよい。上述の投手、打者、および、走者は、デッキに編成されたカード(選手)に基づいて規定される。
表示制御部112は、タッチスクリーン15の表示部152に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部112は、アニメーション生成部114によって生成されたアニメーションを含むゲーム画面を表示部152に表示してもよい。また、表示制御部112は、上述のUIオブジェクトを、該ゲーム画面に重畳して描画してもよい。
対戦進行部115は、サーバ200との間でデータの送受信を行って、相手ユーザとの対戦を進行させる。また、対戦進行部115は、UI制御部113、アニメーション生成部114および表示制御部112を制御して、ユーザが本野球ゲームをプレイするために必要な上述のUIをユーザに提供する。対戦進行部115は、UI制御部113またはアニメーション生成部114に、UI部品を含むゲーム画面を生成させる。対戦進行部115は、表示制御部112に、生成された該ゲーム画面を表示部152に表示させる。これにより、ユーザが本野球ゲームをプレイするためのUIが実現される。
したがって、後に図に基づいて詳述するゲーム画面は、UI制御部113が生成するUI部品、アニメーション生成部114が生成するアニメーション、または、これらを組み合わせによって構成される。UI制御部113またはアニメーション生成部114によって生成されたゲーム画面は、表示制御部112によって、ユーザ端末100の表示部152に表示される。表示制御部112、UI制御部113およびアニメーション生成部114は、対戦進行部115の制御下で、ゲーム画面を表示部152に表示するための処理を実行する。よって、「対戦進行部115が、ゲーム画面を表示部152に表示する」という記載は、「対戦進行部115が、UI制御部113またはアニメーション生成部114を制御して、UI部品またはアニメーションを生成させ、表示制御部112を制御して、生成されたUI部品またはアニメーションを含むゲーム画面を表示部152に表示させる」ことを意味する。
カード取得部116は、サーバ200から第1の方法または第2の方法にて提供されるカードを取得してユーザに獲得させる。第1のカード獲得処理において、まず、カード取得部116は、ユーザに付与された権利データ(パック)を、該権利データに基づいてオブジェクト(キャラクタ)を取得できる状態に遷移させる。すなわち、カードパックを開封可能な状態に遷移させる。本実施形態では、カード取得部116は、一例として、パックポイントの加算を可能にするスロットに、カードパックを配置する。本実施形態では、スロットは、ユーザに対して所定数提供される。例えば、デフォルトで、3つのスロットがユーザに関連付けてゲーム情報132において定義されている。カード取得部116は、スロットにカードパックを配置することにより、カードパックに対応付けてパックポイントを加算することができる。カード取得部116によって、パックポイントが加算されていくことによって、カードパックに割り当てられている条件が満足されると、すなわち、パックポイントの合計が、上述の条件に示された所定値に到達すると、カードパックは、開封可能な状態となる。すなわち、カード取得部116が、カードパックに基づいて選手カードを取得できる状態となる。パックポイントは、例えば、カードパックと同様に、メイン対戦ゲームの報酬としてユーザに付与されてもよい。
本実施形態では、カードパックはスロットに配置されることにより、パックポイントを貯めていくことができる。すなわち、スロットは、カード取得部116がパックポイントを加算することを可能にし、カードパックが開封可能な状態へと遷移していくことを可能にする要件となる。さらに、パックポイントの加算には、別の要件が追加されてもよい。
次に、カード取得部116は、オブジェクトを取得可能な状態に遷移した権利データに基づいて、オブジェクトを取得する。カード取得部116は、権利データを消費し、該権利データと引き換えに、該権利データに対応するオブジェクトを取得してもよい。本実施形態では、カード取得部116は、カードパックを開封して、そこに封入されている選手カードを取得する。より具体的には、カード取得部116は、選手カードを取得するために、消費する権利データを指定したカード取得要求を、サーバ200に通知する。サーバ200において、指定された権利データに基づいて、選手カードが特定され、これがカード取得部116に通知されることにより、カード取得部116は、選手カードを取得することができる。
第2のカード獲得処理において、まず、操作受付部111が、交換ポイントで交換したいキャラクタの指定を受け付ける。カード取得部116は、指定されたキャラクタのカードを、交換ポイントと交換する旨の要求をサーバ200に送信する。カード取得部116は、交換の成立に係る通知をサーバ200から受信し、指定されたキャラクタのカードをユーザに獲得させる。キャラクタのカードをユーザに獲得させるとは、一例として、ユーザに対応付けて管理されているデジタルデータであるキャラクタのステータスを、使用不可から使用可能に遷移させることであってもよい。あるいは、キャラクタのカードに相当するデジタルデータを、ユーザ識別情報またはユーザIDに対応付けて、ゲームシステム1に含まれる少なくともいずれかのメモリ(メモリ11、メモリ21)に記憶させることであってもよい。
なお、図2に示すサーバ200およびユーザ端末100の機能は一例にすぎない。サーバ200は、ユーザ端末100が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末100は、サーバ200が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該他の装置にゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
<処理概要>
図3は、本野球ゲームのおおまかな流れを説明するフローチャートである。概して、ゲームシステム1に含まれるユーザ端末100およびサーバ200の少なくともいずれか一方のコンピュータは、ゲームプログラムを実行することにより、以下の各ステップを実行する構成である。
すなわち、ゲームシステム1は、ステップS1において、ユーザの操作にしたがって、該ユーザが所有する1以上のキャラクタで構成された自チームをデッキとして編成するステップを実行する。ステップS2において、ゲームシステム1は、編成されたチームを、マッチングされた相手チームと対戦させるメイン対戦ゲーム(第1対戦ゲーム)を進行させるステップを実行する。ステップS3において、ゲームシステム1は、カードをユーザに獲得させるための第1のカード獲得処理を実行する。例えば、ゲームシステム1は、ユーザによりメイン対戦ゲームがプレイされた場合に、キャラクタのカードを獲得できるパック(権利データ、第1報酬)を該ユーザに付与するステップを実行する。具体的には、ステップS3において、ゲームシステム1は、第1条件が満たされた場合に、パックに基づいて特定された1以上のキャラクタをユーザに獲得させるステップを実行する。
次に、ステップS4において、ゲームシステム1は、後述のサブ対戦ゲームをプレイする機会をユーザに与えるか否かを決定するための事前処理としてサブ対戦ゲームの実行を制御するステップを実行してもよい。例えば、ゲームシステム1は、第2条件が満たされた場合に、サブ対戦ゲームをプレイする機会をユーザに与えることを決定する。サブ対戦ゲーム(第2対戦ゲーム)は、ユーザによって編成された自チームを、ゲームプログラムにしたがって動作するキャラクタで構成された相手チームと対戦させるゲームである。
サブ対戦ゲームを実行することが決定された場合、ゲームシステム1は、ステップS5のYESからステップS6に進む。そして、ゲームシステム1は、ステップS6において、サブ対戦ゲーム(第2対戦ゲーム)を進行させるステップを実行する。サブ対戦ゲームを実行しないことが決定された場合、ステップS6およびS7は省略される。
ステップS7において、ゲームシステム1は、カードをユーザに獲得させるための第2のカード獲得処理を実行する。例えば、ゲームシステム1は、ユーザによりサブ対戦ゲームがプレイされた場合に、キャラクタ、または、該キャラクタと交換可能な交換ポイント(ゲーム内の価値)を、該ユーザに第2報酬として付与するステップを実行する。
なお、ゲームシステム1は、以下のように構成することもできる。すなわち、ゲームシステム1は、ステップS2において、ユーザが所有する1以上のキャラクタで構成された自チームを、マッチングされた相手チームと対戦させるメイン対戦ゲーム(第1対戦ゲーム)を進行させるステップを実行する。ゲームシステム1は、第1対戦ゲームが終了した後、所定の確率にて、ステップS6において、自チームを、ゲームプログラムにしたがって動作するキャラクタで構成された相手チームと対戦させるサブ対戦ゲーム(第2対戦ゲーム)を進行させるステップを実行する。ゲームシステム1は、ユーザにより第2対戦ゲームがプレイされた場合に、ステップS7において、サブ対戦ゲームの成績に応じた報酬を該ユーザに付与するステップを実行する。サブ対戦ゲームの報酬としては、キャラクタ(例えば、キャラクタのカード)、または、該キャラクタと交換可能なゲーム内の価値(例えば、上述の交換ポイント)が想定される。
上述の各ステップのすべてが1台のコンピュータで実行されなくてもよく、一部のステップをユーザ端末100が実行し、残りのステップをサーバ200が実行する構成であってもよい。
本実施形態では、メイン対戦ゲームにおいてマッチングされる相手チームは、基本的に、他のユーザが所有する1以上のキャラクタで構成されたチームであり、メイン対戦ゲームは、他のユーザが操作する相手チームと対戦する通信対人対戦である。しかし、マッチングの結果、他のユーザが見つからなかった場合には、サーバ200は、ゲームプログラムに基づいて動作するキャラクタで構成されたチームを、ユーザの対戦相手としてマッチングする場合もある。すなわち、メイン対戦ゲームは、コンピュータ対戦を含み得る。
ゲームシステム1において、メイン対戦ゲームが、通信対人対戦として実行される場合、ユーザ端末100(ユーザのコンピュータ)は、対戦相手である他のユーザが操作するユーザ端末100(他のコンピュータ)と通信しながら、進行状況を同期させて対戦を進行させる。
本実施形態では、サブ対戦ゲームにおける相手チームは、ゲームプログラムにしたがって動作するキャラクタで予め構成されたチームである。すなわち、サブ対戦ゲームは、コンピュータ対戦である。したがって、ユーザのコンピュータは、他のコンピュータとの同期を考慮することなく、ゲームプログラムとユーザが実施する操作とに基づいて、コンピュータ対戦を進行させることができる。ユーザは、対戦相手である他のユーザの挙動の影響を受けずに、自分のペースで対戦を進行させることができる。メイン対戦ゲームにおいては、ユーザは、他のユーザの挙動を予測したりしてかけひきを楽しみ、緊張感の中で対戦に興じることができる。その一方で、サブ対戦ゲームでは、ユーザは、そうした緊張感から解放されて、気楽にコンピュータ相手の対戦を楽しむことができる。メイン対戦ゲームのような興奮度の高い対戦ばかりでなく、ときおり、サブ対戦ゲームのように気楽に取り組めるコンピュータ対戦が差し挟まれることにより、ゲームの内容に緩急をつけることができる。こうして、ゲームの内容に緩急をつけることにより、ユーザを過度に疲れさせたり、飽きさせたりすることを回避でき、結果として、ユーザのプレイの動機付けを維持または強化することができる。
なお、第2条件が満たされるかどうかは、ランダムで決定されてもよい。具体的には、サブ対戦ゲームの実行可否は、抽選の実施により決定されてもよい。その際、第1対戦ゲームの勝敗が確率に影響を与えてもよい。例えば、上述の制御するステップでは、ゲームシステム1は、自チームがメイン対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、第2条件が満たされたと判断してもよい。
さらに、サブ対戦ゲームにおける相手チームは、ゲームシステム1によって作成された、複数のチームの中からランダムで決定されてもよい。相手チームの候補となる複数のチームは、それぞれ、強さが異なっていることが好ましい。そして、ステップS7において、ゲームシステム1は、サブ対戦ゲームの報酬(第2報酬)として、自チームが対戦する相手チームが強いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する報酬を付与することが好ましい。
さらに、サブ対戦ゲームにおいて、どの強さの相手チームと対戦するのかは、抽選の実施により決定されてもよい。第1対戦ゲームの勝敗が確率に影響を与えてもよい。例えば、上述の制御するステップでは、ゲームシステム1は、自チームがメイン対戦ゲームに勝利にした場合に、敗北した場合よりも高い確率で、より強いチームを相手チームとして決定してもよい。
<ユーザ情報のデータ構造>
図4は、ユーザ情報133のデータ構造の一例を示す図である。ユーザ情報133は、対戦で参照されるユーザに係る情報を管理するためのデータであり、ユーザごとに作成される。ユーザ情報133は、記憶部120に格納されている。ユーザ情報133は、サーバ200の記憶部220にも格納されていてもよい。
ユーザ情報は、複数の項目を含む。一例として、少なくとも、ユーザ名、レーティング、指定球団、および、交換ポイントの各項目を含む。
「ユーザ名」は、ユーザの名称を示す。ユーザ名は、他のユーザがユーザを識別するために利用する。さらに、ユーザ情報は、ゲームシステム1の各装置がユーザを識別するための「ユーザID」を含んでいてもよい。「レーティング」は、ユーザに設定されているレーティングを示す。レーティングは、対戦におけるユーザの強さを表す指標である。レーティングは、所定の演算式に基づき、ユーザ同士の対戦の結果(例えば、勝敗)と、各ユーザの対戦前のレーティングの差分とに基づいて更新される。具体的には、対戦に勝利したユーザのレーティングは増加され、敗北したユーザのレーティングは、減じられる。したがって、レーティングが高いほどそのユーザが対戦に強いという推測が成り立つ。
ユーザ情報は、さらに、「指定球団」の項目を含む。本ゲームでは、一例として、本ゲームの開始時に実在するプロ野球チーム(12球団)の中から、ユーザがお気に入りの球団を指定球団として1つ指定する。指定球団の項目は、対戦進行部115によって、参照される。例えば、対戦進行部115は、ユーザがお気に入りの指定球団に基づいて、ユーザのチームを表すチームロゴのデザインを決定してもよいし、該指定球団とデッキに組み入れられているキャラクタに設定されている属性(例えば、所属球団)に基づいて、デッキの強さを決定してもよい。
指定球団は、ゲームが開始された後、ユーザによって任意に変更されてもよいし、ユーザが本ゲームをプレイした結果、一定の条件が満たされたことにより、該ユーザが変更できるものであってもよい。
「交換ポイント」の項目には、ユーザがこれまで獲得した交換ポイントの累計が格納されている。ユーザが、サブ対戦ゲームをプレイしたことにより、新たに交換ポイントが付与された場合には、対戦進行部115は、付与された交換ポイントを該累計に加算する。ユーザが、交換ポイントと引き換えに、新たなキャラクタを獲得した場合には、カード取得部116は、該累計から交換対象のポイントを減算する。
<デッキ編成処理>
図5〜図10を参照して、ユーザ端末100およびサーバ200の少なくともいずれか一方が実施するデッキ編成処理の詳細について説明する。
(デッキについて)
ユーザが保有するデッキは、デッキ情報として、ゲームシステム1において取り扱われる。デッキ情報のデータ構造については、後に詳述する。デッキ情報は、ユーザが所有するデッキに係る情報を管理するためのデータである。デッキ情報は、記憶部120に、ゲーム情報132として格納されている。デッキ情報は、サーバ200の記憶部220にも格納されていてもよい。デッキ情報は、対戦進行部115によって、対戦の進行時に参照され、利用される。
本実施形態では、一例として、デッキ情報は、デッキ詳細情報とデッキ概要情報とを含む。デッキ詳細情報は、デッキを構成する各キャラクタの個別情報を集約したものである。デッキ概要情報は、各キャラクタがデッキに配置されたことにより編成されたチーム全体に関する情報である。
ユーザは、本ゲームにおいて、一例として、第1デッキと第2デッキとの、性質の異なる2種類のデッキを保有可能であってもよい。第1デッキは、例えば、キャラクタ優先デッキである。第1デッキは、ユーザの指定球団およびキャラクタの所属球団に依らず、能力の高いキャラクタを多く組み入れるほど、デッキの強さが上がる性質を持つ。このような性質の第1デッキがユーザに提供されることにより、強いキャラクタを獲得する喜び、お気に入りのキャラクタを収集する楽しみ、および、獲得した強いキャラクタで、自分なりのドリームチームを編成する楽しみを、ユーザに与えることができる。
第2デッキは、例えば、自球団優先デッキである。第2デッキは、ユーザの指定球団に属するキャラクタを多く組み入れるほど、デッキの強さが上がる性質を持つ。このような性質の第2デッキがユーザに提供されることにより、自分のお気に入りである指定球団に所属するキャラクタを獲得する喜び、指定球団所属のキャラクタを収集する楽しみ、および、獲得したキャラクタで指定球団のようなチームを編成する楽しみを、ユーザに与えることができる。
(キャラクタについて)
本実施形態では、ユーザは、保有するデッキに、選手およびマスコットの2種類のキャラクタを組み入れることができる。選手は、対戦が進行する仮想空間上に配置されるオブジェクトである。選手は、該選手に設定されている属性および能力値に基づいて、場合によっては、ユーザの入力操作に基づいて決定された動作を仮想空間上で実施する。すなわち、選手は、対戦の進行に直接的に作用する直接オブジェクトである。マスコットは、該マスコットに設定されている属性および能力値に基づいて決定された効果を、直接オブジェクトとしての選手に個別に、または、デッキ全体にもたらす。こうしてマスコットは、選手が対戦を有利に進められるように選手を支援する。すなわち、マスコットは、対戦中に動作を実施する選手に対して有利な作用を及ぼすことにより、対戦の進行に間接的に作用する間接オブジェクトである。
本実施形態では、第1デッキおよび第2デッキのいずれにも、選手だけでなくマスコットを組み入れることができる。マスコットがデッキに組み入れられたときに発揮される効果、および、効果が発揮されるための条件などは、各デッキの性質に合わせて、異ならせることが好ましい。これにより、ユーザは、手持ちのマスコットの効果がより効果的に発揮されるためにいずれのデッキを用いるか、また、どのように選手を配置するかを思慮深く検討することになる。結果として、デッキ編成の戦略性が高まり、ゲームの興趣性を向上させることができる。
さらに、本実施形態では、各キャラクタは、キャラクタ種別に基づいて分類されてもよい。キャラクタ種別も、属性の1項目として、各キャラクタに設定されている。例えば、選手は、守備のポジションに基づいて「野手」か「投手」かに分類される。ポジションに基づく上述の分類をポジション種別(第1種別)と称する。マスコットは、性別(第2種別)に基づいて、「雄」か「雌」かに分類される。
本実施形態では、マスコットの効果は、マスコットの性別に対応するポジション種別を有する選手に対して発揮されてもよい。一例として、デッキに組み入れられた選手の能力値は、該選手のポジション種別に対応する性別のマスコットがデッキに組み入れられている場合に上方に補正される。より具体的には、「野手」の分類と「雄」の分類とが対応しており、「投手」の分類と「雌」の分類とが対応している場合、マスコットの雄は、対戦において野手の能力値を上昇させる効果を発揮してもよい。
本実施形態では、「ポジション」との用語は、デッキにおいて1体のキャラクタが担う1つの役割を示し、デッキを構成する最小単位の要素である。「ポジション」とキャラクタとは1対1で紐付けられる。デッキは、同じ役割のポジションを複数有していてもよい。「ポジション」の一例として、野球における守備位置が想定されているが、「ポジション」は野球の守備位置としてのみ狭義に解釈されるべきでなく、1体のマスコットが担う、「選手を応援する」という役割も「ポジション」の1つに含まれる。
(能力値について)
本野球ゲームでは、キャラクタのそれぞれには、能力値が設定されている。能力値には、身体能力パラメータと、総合パラメータとがある。身体能力パラメータは、対戦において発揮される選手の身体能力を表す値である。具体的には、身体能力パラメータは、野球で必要とされる技能ごとに、選手の技量を数値化したものである。本実施形態では、例えば、身体能力パラメータとして、打撃力、命中力、最速球速、制球力、変化球力、走力、守備力、送球速度、および、送球精度などがある。
これに対して、総合パラメータは、技能および技量に関係なく、キャラクタの総合的な強さを数値化したものであり、キャラクタのカードごとに設定される。総合パラメータは、対戦時、対戦進行部115および対戦支援部211によって参照され、対戦の進行に影響を与える。具体的には、本野球ゲームは、第1デッキおよび第2デッキのいずれも、組み入れられているキャラクタの総合パラメータが高いほど、対戦が有利に進行する仕様である。
選手個々に設定されている総合パラメータは、投手と打者とが対決する場面において参照されてもよい。例えば、対戦進行部115は、1つの打席開始時に、打者の総合パラメータと、投手の総合パラメータとを比較する。そして、該打席が進行する期間、総合パラメータが低い方の選手の身体能力パラメータをマイナス補正する。例えば、総合パラメータの比較で投手が負けた場合、対戦進行部115は、該打席の間、投手の投球に関わる身体能力パラメータ(最高球速および制球力)を、それぞれ、例えば10%減算する。このように、総合パラメータがより高い選手を起用することが、各打席を有利に進行させることにつながる。別の例では、総合パラメータの比較で投手が負けた場合、打者の身体能力パラメータ(打撃力および命中力)を、それぞれ、例えば10%加算してもよい。
(デッキ詳細情報)
図5は、デッキ情報のうち、デッキ詳細情報のデータ構造の一例を示す図である。図5に示すデッキ詳細情報は、第1デッキおよび第2デッキのそれぞれについて別に生成される。
本実施形態では、1つのデッキを、配置される選手の役割に応じて、複数種類の下位デッキに区分してもよい。デッキは、一例として、選手のポジションに基づいて、野手デッキおよび投手デッキの2種類に区分されてもよい。さらに、デッキは、例えば、選手の試合への出場タイミングに基づいて、スターティングメンバーのデッキおよび控えメンバーのデッキの2種類に区分されてもよい。したがって、本野球ゲームでは、第1デッキおよび第2デッキのそれぞれは、以下のように4つに区分された下位デッキで構成される。
本野球ゲームでは、一例として、スターティングメンバーの野手を含む下位デッキを野手スタメンデッキと称し、控えメンバーの野手を含む下位デッキを野手ベンチデッキと称する。また、スターティングメンバーの投手、すなわち、先発投手を含む下位デッキを投手先発デッキと称し、控えメンバーの投手、すなわち、リリーフ投手を含む下位デッキを投手リリーフデッキと称する。
デッキは、上述のとおり複数の役割で構成されている。例えば、役割としては、チームにおける守備または攻撃のポジションがあってもよいし、これらの直接的なポジションにいるチーム員を支援または補助する応援のポジションがあってもよい。1つのデッキは、異種のポジションを1つずつ有していてもよいし、同種のポジションを複数有していてもよい。例えば、野手スタメンデッキは、1種のポジションを1つずつ有する。投手リリーフデッキは、同種のポジションを複数有する。
デッキ詳細情報は、デッキを構成する各ポジションと、該ポジションを担うキャラクタとの紐付けを管理するための情報である。図5に示すとおり、一例として、本ゲームのデッキは、27個のポジションで構成されている。デッキ詳細情報において、1個のポジションにつき1つのレコードが生成され、合計27体のキャラクタがそれぞれのポジションに紐付けられる。
図5に示すとおり、デッキ詳細情報は、一例として、デッキ区分、ポジションID、ポジション名、キャラクタID、属性、総合パラメータ、および、マスコット効果補正の各項目を有する。デッキ詳細情報が、第1デッキのものであるとき、自球団効果補正の項目は設けられないか、あるいは、当該項目の値はNULL値をとる。
「デッキ区分」は、該当レコードのポジションが上述の4つの下位デッキのいずれに属するのかを示す。
「ポジションID」は、デッキにおける各ポジションを一意に識別するための識別情報である。同種のポジションについても、互いに異なるポジションIDが付与されているので、各レコードが一意に識別可能である。「ポジション名」は、ポジションの名称を示す。名称によって、ユーザは、デッキ内の各ポジションを識別することができる。
「キャラクタID」は、選手またはマスコットに見立てたカードを一意に識別するための識別情報である。キャラクタIDは、ポジションIDと1対1で紐付けられる。これにより、デッキのポジションと、該ポジションを担うキャラクタとの対応関係が管理される。
「属性」は、該当レコードのポジションに就いたキャラクタの属性を示す。一例として、属性には、キャラクタ種別と所属球団とがある。「キャラクタ種別」は、キャラクタが選手の場合、ポジションに基づいて野手か投手かを分類するポジション種別を示し、キャラクタがマスコットの場合、雄か雌かの性別を示す。「所属球団」は、あらかじめ定められた球団(例えば、実在するプロ野球チーム、12球団)のうち、キャラクタが所属している球団を示す。
「総合パラメータ」は、各キャラクタに設定されている総合パラメータを示す。該カラムに格納される総合パラメータの値は、該キャラクタに設定されている基本の値であり、該値が補正される時の補正値は、カラムを別にして管理される。
「マスコット効果補正」は、デッキにおけるマスコットの配置が所定の条件を満たすことに伴って補正される、各キャラクタの総合パラメータの補正値を示す。図5に示す例では、補正値「50」は、1つ左のカラムに格納されている総合パラメータの基本の値に、50が加算されることを示す。
なお、図5に示す例では、便宜上、マスコット雄を配置するための野手応援のポジションは、野手スタメンデッキに属し、マスコット雌を配置するための投手応援のポジションは、投手先発デッキに属するものとして管理されている。しかし、これに限らず、デッキ詳細情報において、第5の下位デッキ「マスコットデッキ」を生成し、そこにマスコット専用のポジションのレコードを設けてもよい。
図5に示すとおり、本実施形態における第2デッキのデッキ詳細情報は、さらに、「自球団効果補正」の項目を有する。「自球団効果補正」は、デッキにおけるキャラクタの配置が所定の条件を満たすまたは満たさないことに伴って補正される、各キャラクタの総合パラメータの補正値を示す。
本実施形態では、第2デッキは、ユーザの指定球団と同じ球団を所属球団とするキャラクタを多く配置するほど対戦が有利になるという性質を持つ。そこで、対戦進行部115は、第2デッキに、指定球団と同球団のキャラクタが配置されている場合には、該キャラクタの総合パラメータを上方に補正し、指定球団と異なる球団のキャラクタが配置されている場合には、該キャラクタの総合パラメータを下方に補正する。具体的には、図5の自球団効果補正の項目について、指定球団と同球団のキャラクタについては、総合パラメータ「+150」の値を、異球団のキャラクタについては、総合パラメータ「−150」の値を各レコードに格納する。
ユーザの入力操作にしたがって、対戦進行部115が生成したデッキ詳細情報が記憶部120に保存されると、次に、対戦進行部115は、デッキ詳細情報に基づいて、デッキ概要情報を生成する。
(デッキ概要情報)
図6は、デッキ情報のうち、デッキ概要情報のデータ構造の一例を示す図である。図6に示すデッキ概要情報は、ユーザごとに生成され、ユーザが保有するデッキの種類ごとにレコードが登録される。
図6に示すとおり、デッキ概要情報は、一例として、デッキID、デッキ種別、総合パラメータ合計値、自球団度、加算値、および、デッキ総合パラメータの各項目を有する。デッキ概要情報のうち、第1デッキのレコードについては、自球団度の項目、および、加算値の項目の中のマスコットボーナスのサブ項目において、値はNULL値をとる。
「デッキID」は、ユーザが保有するデッキを一意に識別するための識別情報である。本実施形態では、性質の異なる2種類のデッキがユーザによって保有され、それぞれのデッキには、「D1」、「D2」のデッキIDが付与されている。
「デッキ種別」は、デッキの種別を示す。本実施形態では、D1は、第1デッキ、具体的には、キャラクタ優先デッキであり、D2は、第2デッキ、具体的には、自球団優先デッキである。
「総合パラメータ合計値」は、デッキに組み入れられている各キャラクタの補正後の総合パラメータを合計して得られた値を示す。補正後の総合パラメータとは、デッキに組み入れられているキャラクタに本来設定されている、基本の総合パラメータが、同じデッキに組み入れられているマスコットの効果に基づいて補正されたものである。
「自球団度」は、第2デッキにおいて、ユーザの指定球団と同じ球団に所属するキャラクタが配置されている割合を示す。本実施形態では、1つのデッキには、27個のポジションが含まれている。したがって、自球団度は、n/27(nは、デッキに配置されている、指定球団と同じ所属球団のキャラクタの数)で表される。
「加算値」は、総合パラメータ合計値に対して、デッキの配置が所定の条件を満たした場合に臨時に加算される値を示す。一例として、加算値には、マスコットボーナスと選手ボーナスとがある。「マスコットボーナス」は、1または複数のマスコットの配置が所定の条件を満たした場合に加算される値を示す。本実施形態では、マスコットボーナスは、デッキ種別が、第2デッキである場合に発生する。したがって、第1デッキのマスコットボーナスはNULL値または「0」の値をとる。「選手ボーナス」は、1または複数の選手の配置が所定の条件を満たした場合に加算される値を示す。例えば、上述の自球団度が所定値以上を満足した場合に、加算される選手ボーナスがあってもよい。
「デッキ総合パラメータ」は、ユーザが保有するデッキの、対戦における総合的な強さを示す指標であり、デッキごとに付与されるものである。デッキ総合パラメータは、デッキに配置されている各キャラクタの補正後の総合パラメータに基づいて算出される。より具体的には、デッキ総合パラメータは、デッキに配置される各キャラクタの補正後の総合パラメータを合計した上述の総合パラメータ合計値と、マスコットが該デッキに組み入れられていることに基づいて加算される加算値(上述のマスコットボーナス)とを合計して算出される。したがって、デッキ内の各キャラクタの総合パラメータが高いほど、デッキ総合パラメータも高く算出される。本実施形態では、対戦進行部115は、ユーザのデッキのデッキ総合パラメータと、対戦相手のデッキのデッキ総合パラメータとを比較し、デッキ総合パラメータの値が上回った方に有利に対戦を進行させる。したがって、デッキ総合パラメータが高いほど、対戦に強いデッキであり、対戦に有利であると考えることができる。これにより、ユーザは、デッキ総合パラメータを高めることを目的として、総合パラメータが高いキャラクタを収集したり、加算値が多く得られるようにデッキの配置を工夫したりして、本ゲームをより一層楽しむことが可能となる。
図6に示すとおり、本実施形態における第2デッキのデッキ概要情報は、自球団度、および、マスコットボーナスの加算値の項目をさらに含む。
自球団度は、デッキのすべてのポジションのうち、指定球団と同じ球団に所属する選手が何人配置されているのかを示す。対戦進行部115は、自球団度が「所定閾値以上」との条件を満たした場合に、選手ボーナスを加算してもよい。
さらに、マスコットには、第2デッキに配置された場合に、選手に有利な効果をもたらすスキルが設定されている。そこで、対戦進行部115は、第2デッキに、ユーザの指定球団と同じ球団を所属球団とするマスコットが配置されている場合には、該マスコットのスキルを発動させて、第2デッキにおけるデッキ総合パラメータを大幅に上方に補正する。具体的には、対戦進行部115は、指定球団と同じマスコットが1体配置されるごとに、所定値のマスコットボーナスを加算してもよい。
これにより、ユーザは、自分のお気に入りの球団に所属するキャラクタを集めるように促され、また、とりわけ、自分のお気に入りの球団に所属するマスコットを獲得することを望むようになる。結果として、ユーザに対して、お気に入り球団のマスコットと、お気に入り球団所属の選手とを獲得する喜び、集める喜び、および、獲得したキャラクタを編成する楽しみをユーザに与えることができる。
(画面例)
図7は、ユーザ端末100の表示部152に表示されるデッキ選択画面の一例を示す図である。デッキ選択画面400は、ユーザが複数種類のデッキを保有できるゲームにおいて、編成したいデッキの種別をユーザが選択するための画面である。デッキ選択画面400は、各種デッキの情報と、デッキを選択するためのUIとを含む。例えば、デッキ選択画面400は、自球団優先デッキとしての第2デッキのステータス情報401、および、キャラクタ優先デッキとしての第1デッキのステータス情報402を含む。さらに、デッキ選択画面400は、いずれのデッキを選択するのかをユーザが指定するためのUIとして、択一選択式のチェックボックス403および404を含む。
ステータス情報401は、図6に示すデッキ概要情報のうち、D2のレコードに基づいて生成される。ステータス情報401は、「自球団度」と、総合パラメータ合計値を示す「合計値」と、マスコットボーナスおよび選手ボーナスを合計した「加算値」と、該「合計値」と該「加算値」との和である「デッキ総合パラメータ」とを含む。
ステータス情報402は、図6に示すデッキ概要情報のうち、D1のレコードに基づいて生成される。ステータス情報402は、総合パラメータ合計値を示す「合計値」と、選手ボーナスを合計した「加算値」と、該「合計値」と該「加算値」との和である「デッキ総合パラメータ」とを含む。
ユーザは、上述の各デッキのステータス情報を確認しながら、チェックボックス403および404を操作して、編成したいデッキを選択する。なお、対戦進行部115は、図7に示すデッキ選択画面400を、マッチング要求をサーバ200に対して行う直前に表示し、対戦で使用するデッキをユーザに選択させてもよい。
図8は、デッキ編成画面のうち、野手を配置するための野手デッキ編成画面の一例を示す図である。野手デッキ編成画面500は、一例として、野手スタメンデッキ501および野手ベンチデッキ502を含む。野手スタメンデッキ501は、投手を除く8つの守備ポジションのそれぞれに対応する枠F2〜F9と、指名打者のポジションに対応する枠F10とを有する。さらに、本実施形態では、野手スタメンデッキ501は、野手応援のポジションに対応する枠F1を有する。野手ベンチデッキ502は、一例として、控えの野手のポジション5人分に相当する5つの枠を有してもよい。
図9は、デッキ編成画面のうち、投手を配置するための投手デッキ編成画面の一例を示す図である。投手デッキ編成画面550は、一例として、投手先発デッキ551および投手リリーフデッキ552を含む。投手先発デッキ551は、一例として、先発投手のポジション5人分に相当する5つの枠を有してもよい。投手リリーフデッキ552は、一例として、リリーフ投手のポジション6人分に相当する6つの枠を有してもよい。
本実施形態では、投手デッキ編成画面550は、さらに、投手応援のポジションに対応するマスコット表示枠F16を含む。投手応援のポジションは、データ構造上、投手先発デッキ551に含まれているが、枠F16は、図9に示すとおり、投手先発デッキ551の領域外に表示してもよい。
本実施形態では、対戦進行部115は、ポジションに対応するデッキ上の枠に、配置したキャラクタの情報を表示することが好ましい。例えば、枠の右上の数字は、配置されたキャラクタの総合パラメータを示す。該数字のさらに右には、上方向または下方向を示す矢印が必要に応じて表示される。上方向の矢印は、キャラクタに設定されている基本の総合パラメータが上方に補正されたことを示す。上方補正は、例えば、各キャラクタのデッキの配置が所定条件を満たしたことによりなされる。下方向の矢印はキャラクタに設定されている基本の総合パラメータが下方に補正されたことを示す。下方補正は、例えば、各キャラクタのデッキの配置が所定条件を満たさなかったことに対するペナルティとして課される。枠の左下のロゴは、配置されたキャラクタの所属球団を示す。その他、キャラクタの希少度、キャラクタ名などが枠周辺に表示されてもよい。
さらに、各デッキ編成画面は、デッキ総合パラメータ503を含んでいてもよい。デッキ総合パラメータについても上方または下方に補正されたことを示す矢印を付加してもよい。さらに、各デッキ編成画面は、現行のデッキの配置に基づいて発生しているマスコットボーナスおよび選手ボーナスの一覧表を呼び出すためのUI504を含んでいてもよい。なお、本実施形態では、第1デッキには、自球団度のパラメータは設定されないので、図8および図9に示されたデッキ編成画面が、第1デッキの場合には、自球団度505は表示されない。
ユーザは、それぞれのデッキ編成画面を表示部152に表示させて、手持ちの所望のカードを、それぞれの枠に紐付けるための入力操作を入力部151を用いて行う。対戦進行部115は、上述の入力操作を操作受付部111を介して受け付け、枠とカードとの対応関係に基づいて、ポジションとキャラクタとの紐付けを行い、デッキ詳細情報を生成する。
(処理の流れ)
図10は、ゲームシステム1がゲームプログラム131に基づいて実行するデッキ編成処理の流れを示すフローチャートである。以下では、図10に示す各処理をユーザ端末100が実行するものとして説明するが、その一部の処理をサーバ200が実行してもよい。図10に示す一連の処理は、図3に示すステップS1の処理に対応している。
ステップS101において、対戦進行部115は、例えば、図7に示すデッキ選択画面400を表示部152に表示する。ユーザは、デッキ選択画面400を操作して、上述の第1デッキおよび第2デッキのいずれを編成するのかを選択する。
ステップS102において、対戦進行部115は、いずれのデッキが選択されたのかを判断する。例えば、チェックボックス404にチェックを入れる操作を操作受付部111が受け付けた場合、対戦進行部115は、第1デッキが選択されたと判断し、ステップS102のYESからステップS103に進む。
ステップS103において、対戦進行部115は、ユーザによって選択された第1デッキを編成するためのデッキ編成画面を表示部152に表示する。対戦進行部115は、図8に示す野手デッキ編成画面500と図9に示す投手デッキ編成画面550とを同時に表示部152の一画面に表示してもよいし、同図に示したとおり、「野手デッキ」と「投手デッキ」との切り替えボタンを設けて、各デッキ編成画面を切り替えて表示してもよい。
ステップS104において、対戦進行部115は、操作受付部111が受け付けたユーザの入力操作にしたがって、デッキを生成する。具体的には、ユーザが指定した枠とカードとの対応関係にしたがって、該枠が示すポジションと、該カードが示すキャラクタとを対応付ける。
ここで、対戦進行部115は、デッキ上のキャラクタの配置が特定の条件を満たすか否かに基づいて、デッキまたは該デッキに配置されている各キャラクタに関わるパラメータを上方または下方に補正してもよい。
第1デッキに関しては、対戦進行部115は、ユーザの指定球団を考慮しない。対戦進行部115は、デッキに配置されたマスコットに設定されている、マスコット効果にしたがって、各キャラクタの総合パラメータに所定の加算値を加算してもよい。
一方、ステップS102において、操作受付部111がチェックボックス403にチェックを入れる操作を受け付けた場合、対戦進行部115は、第2デッキが選択されたと判断して、ステップS102のNOからステップS105に進む。
ステップS105において、対戦進行部115は、ユーザによって選択された第2デッキを編成するためのデッキ編成画面を表示部152に表示する。
ステップS106において、対戦進行部115は、ステップS104のときと同様に、デッキを生成する。また、対戦進行部115は、デッキにマスコットが配置された場合には、該マスコットに設定されている、マスコット効果にしたがって、各キャラクタの総合パラメータに所定の加算値を加算してもよい。
さらに、第2デッキに関して、対戦進行部115は、ユーザの指定球団を考慮したパラメータの補正を、例えば、以下のようにして行う。
ステップS107において、対戦進行部115は、ユーザの指定球団と同じ球団のキャラクタの総合パラメータを上方に補正する。
ステップS108において、対戦進行部115は、ユーザの指定球団と異なる球団のキャラクタの総合パラメータを下方に補正する。
ステップS109において、対戦進行部115は、第2デッキにおける、ユーザの指定球団と同じ球団のキャラクタの数に基づいて、自球団度を決定する。対戦進行部115は、ステップS107〜S109を任意の順序で実行することができる。
ステップS110において、対戦進行部115は、総合パラメータ合計値を算出する。本実施形態では、対戦進行部115は、上述のとおり、キャラクタ個別の補正後の総合パラメータを単純に合計することにより、総合パラメータ合計値を算出する。
ステップS111において、対戦進行部115は、デッキにおけるキャラクタの配置に基づいて、ボーナスを適用して、上述の総合パラメータ合計値に加算することができる加算値を算出する。本実施形態の第1デッキでは、マスコットボーナスは発生しない。したがって、対戦進行部115は、ユーザが編成した配置が、選手ボーナスの条件を満たしている場合には、該選手ボーナスに対応する加算値を算出する。デッキの配置が複数の選手ボーナスの条件を満たした場合には、対戦進行部115は、各選手ボーナスの加算値を合計して最終的な加算値を算出する。本実施形態の第2デッキでは、さらに、対戦進行部115は、ユーザの指定球団と同じ球団のマスコットが配置されている場合には、該マスコットのマスコットスキルを発動し、総合パラメータ合計値に対して加算すべき加算値(マスコットボーナス)を算出してもよい。例えば、雌雄計2体のマスコットが配置されており、それぞれのマスコットが、「デッキ総合パラメータを1000アップする」というマスコットスキルを有している場合を想定する。この場合、対戦進行部115は、1000×2=2000を、マスコットボーナスとして算出する。対戦進行部115は、上述のように算出したマスコットボーナスと、選手ボーナスとを合わせて、第2デッキにおける加算値を算出する。
ステップS112において、対戦進行部115は、デッキ総合パラメータを算出する。本実施形態では、対戦進行部115は、ステップS110で求めた総合パラメータ合計値に、ステップS111で求めた加算値を足すことにより、デッキ総合パラメータを求める。
ステップS113において、対戦進行部115は、ステップS104またはS106にて対応関係が変更された後のデッキを示すデッキ編成画面を表示部152に表示する。このとき、対戦進行部115は、対戦で比較に用いられる値(例えば、デッキ総合パラメータまたは各キャラクタの個別の総合パラメータ)が、デッキにマスコットが組み入れられたことに応じて上方に補正されたことをユーザに通知する情報を表示することが好ましい。例えば、対戦進行部115は、値の右横に、上方に補正されたことを示す上向きの矢印を付与してもよい。これにより、ユーザは、マスコットをデッキに配置することによって得られる効果を直感的に理解することが可能となる。
ステップS114において、操作受付部111が、変更後のデッキの内容を確定させるための操作入力をユーザから受け付ける。例えば、野手デッキ編成画面500および投手デッキ編成画面550の右下に配置された保存ボタンに対するタッチ操作を操作受付部111が受け付ける。この場合、対戦進行部115は、ステップS114のYESからステップS115に進む。
ステップS115において、対戦進行部115は、ゲーム情報132として記憶部120に記憶されているデッキ情報を更新する。具体的には、対戦進行部115は、図5に示すデッキ詳細情報と図6に示すデッキ概要情報とを更新する。
<メイン対戦ゲームから第1のカード獲得処理まで>
図11〜図23を参照して、ユーザ端末100およびサーバ200の少なくともいずれか一方が実施するメイン対戦ゲームおよび第1のカード獲得処理の詳細について説明する。
(マッチングについて)
本実施形態では、メイン対戦ゲームは、基本的に、通信対人対戦を前提としている。したがって、ユーザのチームが対戦する相手、すなわち、相手チームは、サーバ200によってマッチングにより決定される。本実施形態では、相手チームのマッチングは、サーバ200の対戦支援部211によって実行される。本実施形態では、相手チームは、他のユーザによって編成されたチームの中から探索される。対人対戦のための適当な相手チームが探索されなかった場合には、対戦支援部211は、ゲームプログラム131にしたがって動作するキャラクタから構成されたチームを生成し、あるいは、事前に用意しておき、当該チームを相手チームとして、ユーザのチームにマッチングさせる。したがって、メイン対戦ゲームは、他のユーザによる相手チームが探索されなかった場合に、コンピュータ対戦になることもあり得る。本実施形態では、対戦支援部211は、ユーザに付与されているレーティング(評価値)に基づいて、適当な相手チームを探索する。
レーティングとは、対戦におけるユーザの強さを表す指標である。レーティングは、所定の演算式に基づき、対戦の結果(具体的には、勝敗)、および、対戦前の自分のレーティングと相手のレーティングとの差分に基づいて更新される。相手のレーティングとは、他のユーザであれば該他のユーザに付与されているレーティング、相手がコンピュータである場合には、該コンピュータに仮想的に設定されているレーティングを指す。
レーティングの算出および更新の処理は、サーバ200の対戦支援部211が実行してもよいし、ユーザ端末100(クライアント、コンピュータ)の対戦進行部115が実行してもよい。いずれにしても、ユーザに付与されている最新のレーティングは、サーバ200とユーザ端末100との間で共有されている。
以下では、一例として、ユーザに付与されているレーティングの更新は、サーバ200によって行われるものとして説明する。
対戦支援部211は、対戦相手をマッチングするために参照するレーティングをユーザごとに管理する。対戦支援部211は、例えば、マッチングにより対戦をプレイしたユーザについて、対戦前のユーザと相手とのレーティングの差分値と、対戦の勝敗とに基づいて、対戦後のユーザのレーティングを更新する。
対戦支援部211は、例えば、初期値として値「1500」を各ユーザに設定する。ユーザXとユーザYとが対戦し、ユーザXが勝利し、ユーザYが敗北した場合に、以下の式1および式2に従って、対戦後のレーティングが更新される。
〔式1〕 対戦後の勝利側のユーザ(ユーザX)のレーティング = 勝利側のユーザ(ユーザX)の対戦前のレーティング + 32 + (敗北した側(ユーザY)のレーティング − 勝利した側(ユーザX)のレーティング)×0.04
〔式2〕 対戦後の敗北側のユーザ(ユーザY)のレーティング = 敗北側のユーザ(ユーザY)の対戦前のレーティング − 32 + (敗北した側(ユーザY)のレーティング − 勝利した側(ユーザX)のレーティング)×0.04
対戦前後において変動するレーティングに幅(上限値および下限値)を設けてもよい。例えば、変動するレーティングの幅として、最大値「64」、最小値「4」などと設定してもよい。対戦するユーザ間のレーティングの差が過度に大きい場合、式1または式2に従ってレーティングを計算すると、レーティングが高い方のユーザが、勝利したにもかかわらずレーティングが減少し、勝利したユーザが納得できないという事態が生じ得る。そこで、対戦前のレーティングから変動する幅に最大値および最小値を設定することで、そのような事態を回避し、ユーザの納得感を向上させることができる。
上述のとおり、本実施形態では、対戦相手を探索するために、ユーザのレーティングが参照される。そのため、ユーザは、自身のレーティングを上げれば上げるほど、レーティングの高い、すなわち、強い相手と戦いやすくなる。本実施形態によれば、この仕組みを利用することにより、対戦をプレイすることのユーザの動機付けを維持できる。さらには、強い相手と対戦することの動機付けを強化できる。
本実施形態では、ユーザ端末100は、ユーザから、メイン対戦ゲームを開始する指示を受け付けると、サーバ200に対して、マッチングを実施するように要求する。サーバ200の対戦支援部211は、マッチングを実施して、マッチングの結果をユーザ端末100に返信する。
図11は、マッチングが成立したときにユーザ端末100の表示部152に表示されるマッチング成立画面の一例を示す図である。マッチング成立画面600は、マッチングが成立した旨の結果をユーザに通知するとともに、その対戦相手の情報を対戦開始前にユーザに提供するためのゲーム画面である。
マッチング成立画面600は、一例として、ユーザ本人のユーザ名601、対戦相手のユーザ名602、ユーザ本人のレーティング603、および、対戦相手のレーティング604を含んでいる。
マッチング成立画面600は、さらに、ユーザ本人および対戦相手のデッキの種別を示す情報を含んでいてもよい。本実施形態では、一例として、ユーザまたは対戦相手のデッキが、第2デッキにより編成されている場合、対戦進行部115は、そのことを示す球団ロゴ605を、マッチング成立画面600に表示させる。本ゲームでは、指定できる球団ごとに球団ロゴが対応付けられており、ロゴにより、球団が識別できるようになっている。図10に示す例では、球団ロゴ605がユーザの情報を表示する領域に付与されていることにより、ユーザのデッキとして、「鳥取サーモンズ」を指定球団とする第2デッキ(自球団優先デッキ)が採用されていることがユーザと対戦相手とによって認識される。一方、対戦相手が第1デッキを採用している場合には、対戦相手の情報を表示する領域にロゴが付与されない。これにより、対戦相手が第1デッキを採用していることをユーザは認識することができる。
なお、他のユーザとのマッチングが成立せず、相手チームがコンピュータの制御下で動作するチームである場合には、対戦相手のユーザ名602において、対戦相手がコンピュータであることが分かる表示を行うことが好ましい。
(メイン対戦ゲームの構成)
マッチングが成立すると、ユーザ端末100は、メイン対戦ゲームの進行を開始する。本実施形態で実行されるメイン対戦ゲームの構成について、図12に基づいて説明する。図12は、本実施形態に係るゲームシステム1において、ゲームプログラム131に基づいて進行される対戦を模式的に示す図である。本実施形態に係るメイン対戦ゲームの対戦は、以下の要素で構成される。そして、各要素は、サーバ200の制御部210、および、ユーザ端末100の制御部110の少なくともいずれか一方によって進行される。
以下では、ユーザのユーザ端末100によって編成されたチームを自チーム、対戦相手のユーザのユーザ端末100によって編成されたチームまたはゲームプログラム131に基づいて自動で編成されたチームを相手チームと称する。
図12に示すとおり、対戦進行部115によって進行される対戦は、複数のイニングで構成され、1イニングにつき、表と裏でチームの攻守を入れ替え、各チームが1回ずつ守備と攻撃とを実行して、対戦が進行する。1イニングの表および裏のそれぞれは、複数の打席で構成され、攻撃側のキャラクタ1名につき1つの打席が対応付けられる。1つの打席は、守備側(投球側)のキャラクタと、攻撃側(打撃側)のキャラクタとが1対1で対決する対決要素と、対決の結果を決定し、出力させて、該打席を完了させる結果出力要素とで構成される。
対決要素は、さらに複数のフェーズに区切られる。フェーズは、対決する各キャラクタが、守備動作および攻撃動作のいずれか一方を、それぞれ所定回数行う期間である。1のフェーズにおいて、守備側のキャラクタ、および、攻撃側のキャラクタのそれぞれが動作を行う回数は、予め定められている。しかし、その回数は、ゲームの題材となる競技に基づいて任意に定められればよい。また、守備側と攻撃側とで、動作回数は同じに定められてもよいし、異なっていても構わない。本実施形態では、一例として、1のフェーズにおいて、守備側のキャラクタが守備動作を1回、攻撃側のキャラクタが攻撃動作を1回行うと定められているものとする。
フェーズは、いわば、対戦を構成する要素の最小単位であり、野球ゲームにおいては、投手が投げる1球に相当する。各フェーズにおいて、守備側のキャラクタによって、1つの守備動作(投球動作)が実行され、攻撃側のキャラクタによって1つの攻撃動作(打撃動作)が実行されると、1つのフェーズが完了し、次のフェーズへ移行する。
いくつかのフェーズの進行を経て、結果出力要素において、当該打席の結果(アウトまたは進塁等)が決定する。これにより、1つの打席が完了し、次の打席へ移行する。いくつかの打席を経て、1イニングの表(または裏)において、3つのアウトが累積されると、1つのイニングの表(または裏)が完了し、攻守が入れ替わって、同イニングの裏(または次のイニング)へ移行する。
本実施形態において、対戦を構成する各要素のうち、結果出力要素は、主に、各コンピュータ(サーバ200、および、ユーザ端末100)が読み出すゲームプログラムにしたがって、すなわちオート制御によって進行してもよい。
一方、対決要素の全フェーズは、ユーザが入力部151を介して実施する操作に基づいて、すなわち、マニュアル制御によって進行させることができる。守備動作および攻撃動作が1度ずつ行われる各フェーズは、対戦の勝敗を左右する重要な要素であり、対戦の大部分を占める要素である。したがって、ユーザの操作の巧拙が対戦の勝敗に大きな影響を与え、うまく操作したユーザが対戦を有利に進めることができる。
とりわけ、本実施形態では、ユーザは、フェーズごとに(一球ごとに)、希望する制御方法を切り替えることができる。本実施形態では、ユーザ端末100は、制御方法の切り替え指示を随時ユーザから受け付け、受け付け直後に訪れるフェーズの開始時点で、指示された制御方法に設定する。例えば、ユーザは、ある一球については、ユーザが自身で投球操作を行って、投手キャラクタに投球動作(守備動作)を行わせ、次の一球については、サーバ200の制御下で、自動で投手キャラクタに投球動作を行わせるというように、プレイすることが可能である。
上述のプレイ形態によれば、ユーザに対して、全フェーズに介入できる(マニュアル制御に設定する)権利が与えられる。したがって、全フェーズまたは一部のフェーズがオート制御であったがゆえに対戦に負けたのだとしても、ユーザ自身が介入する権利を放棄したことに起因する敗北であるとユーザは認識し、対戦結果に納得することができる。
以上のことから、対戦の各要素を自動で進行させる機能を備えつつも、全フェーズに介入できる権利をユーザに提供することで、対戦結果に対するユーザの納得感が損なわれないゲームを実現することができる。
以下では、上述のオート制御によって対戦を進行させることをオート進行モードと称し、上述のマニュアル制御によって対戦を進行させることをマニュアル進行モードと称する。
(メイン対戦ゲームにおける画面例)
図13〜図16は、ユーザ端末100が、メイン対戦ゲームを進行しているときに、表示部152に表示させるゲーム画面の一例を示す図である。図13〜図16に示すゲーム画面は、メイン対戦ゲームがマニュアル進行モードで進行するときに対戦進行部115が表示部152に表示させる対戦画面の一例である。
図13〜図15は、対戦画面のうち、自チームの守備回において表示される投球画面700を示す。投球画面700は、ユーザが投手のポジションに紐付けた投手703の投球動作を決定するための投球操作UIを含む。投球操作UIは、投球側ユーザによる投球操作を受け付けるためUIである。
本実施形態において、投球結果D1を決定するための投球操作には、一例として、球種を指定するためのスライド操作と、コースを指定するためのドラッグ操作と、制球の良否を決定するためのタイミングを投球側ユーザに指定させるタップ操作とが含まれる。タップ操作の入力タイミングの良否に応じて、投球の良否が決定される。つまり、投球側ユーザにとって、対戦、特に、守備の回を有利に進めることができるか否かは、マニュアル進行モードの場合、タップ操作の巧拙にかかっている。
1つのフェーズ(1回の投球動作と、1回の見逃しも含む打撃動作とが実施される期間)が開始されると、投球側ユーザ端末の対戦進行部115は、まず、図13に示す第1の投球画面700を、UI制御部113に生成させて、表示部152に表示させる。
第1の投球画面700は、仮想空間に配置されている各種オブジェクトを含む。具体的には、相手チームの打者701、バット702、ユーザ自身が操作する投手703、ホームベース707、および、捕手705を含む。
第1の投球画面700は、次のフェーズをオート進行モードまたはマニュアル進行モードに切り替えるための切替ボタン713を含んでいてもよい。図13に示す例では、該フェーズは、マニュアル進行モードにて進行している。そのため、切替ボタン713は、次のフェーズをオート進行モードに切り替えるためのボタンとして投球画面700に重畳表示されている。
第1の投球画面700は、該フェーズにおいて対決中の各選手のステータス情報を含んでいてもよい。一例として、自チームの投手のステータス情報711と、相手チームの打者のステータス情報712とを含んでいてもよい。
第1の投球画面700は、投球操作を支援するUIオブジェクトとして、投手703に投げさせる球種を投球側ユーザが指定するための球種指定オブジェクト710を含んでいてもよい。
対戦進行部115は、球種指定オブジェクト710に対するユーザのスライド操作に基づいて、球種を決定する。図13に示すとおり、球種指定オブジェクト710において、ボールアイコンの周囲を囲うように、球種が1対1で対応付けられた球種アイコンが配置されている。球種アイコンは、対応付けられている球種を示すテキストまたはイラストなどを含んでいる。UI制御部113は、球種指定オブジェクト710において一覧される球種の種類を、投手703の能力に基づいて異ならせてもよい。
操作受付部111は、ボールアイコンに対する所定方向のスライド操作を、球種を指定するための操作として受け付ける。対戦進行部115は、スライド操作の方向に配置されている球種アイコンに対応する球種を、投手703に投げさせる球種として決定する。例えば、図13に示す例では、ユーザがボールアイコンを上方向にスライドさせた場合、対戦進行部115は、投手703にストレートを投げさせると決定する。球種にはボール704の移動経路、球速等を特定するためのパラメータが対応付けられている。球種のパラメータは、球速、変化量、および変化の方向を示す情報を含む。また、球種のパラメータは、投手703の識別情報に対応付けられて、記憶部120に記憶されている(不図示)。対戦進行部115は、投手703の識別情報に対応付けられた球種のパラメータのうち、決定した球種のパラメータを記憶部120から読み出し、投球結果D1に含める。
球種が決定されると、次に、対戦進行部115は、図14に示す第2の投球画面700を表示部152に表示させる。第2の投球画面700は、球種指定オブジェクト710に代えて、コース指定オブジェクト714を含む。コース指定オブジェクト714は、カーソル715と組み合わせて、投球側ユーザに、投手703に投げさせるコース(内角高め、低めなど)を指定させるためのUIオブジェクトとして機能する。
コース指定オブジェクト714は、一例として、ストライクゾーンに対応する矩形を9つのマスに分割したものである。各マスは、投手703の能力、具体的には、得意なコースおよび不得意なコースに基づいて、色分けして表示されてもよい。
コース指定オブジェクト714は、投げられたボールの到達予定位置を示す標識であるカーソル715を含む。第2の投球画面700が表示されている間、操作受付部111は、カーソル715の位置を指定するためのドラッグ操作を受け付ける。操作受付部111がカーソル715を移動させるためのドラッグ操作を受け付けると、UI制御部113は、該ドラッグ操作に関して検出されたタッチ位置に基づいて、カーソル715を移動させる。
操作受付部111は、タッチスクリーン15に対するユーザの最初の接触位置(初期タッチ座標)と、カーソル移動操作後の接触位置(タッチナウ座標)とを取得する。UI制御部113は、取得された各座標を比較した結果得られた変化方向、および、変化量に基づいて、カーソル715の位置の変化方向、および、変化量をそれぞれ決定する。これにより、UI制御部113は、カーソル715が直接タッチされなくても、また、コース指定オブジェクト714の表示領域外でドラッグ操作が受け付けられても、該ドラッグ操作に連動して、カーソル715を移動させることができる。このようにすれば、ユーザの指によってカーソル715の視認が妨げられることを回避できる。表示制御部112は、UI制御部113によって実行されているカーソル715の移動に連動して、移動するカーソル715を第2の投球画面700上に表示させる。
対戦進行部115は、コースの確定を、任意の方法で行う。例えば、ユーザが上述のドラッグ操作に基づく接触が維持された状態で、所定閾値以上の圧力で強く押し込む操作を続けて行ったとする。対戦進行部115は、押し込む操作が受け付けられた時点におけるカーソル715の位置を、最終的なコースとして確定させる。あるいは、「コース確定」などのボタン(不図示)が別途、第2の投球画面700に設けられてもよい。対戦進行部115は、該ボタンがタップ操作されたときのカーソル715の位置に基づいてコースを確定させてもよい。
コースが確定すると、次に、対戦進行部115は、図15に示す第3の投球画面700を表示部152に表示させる。第3の投球画面700は、良否判定オブジェクト720を含む。良否判定オブジェクト720は、投手703の制球の良否を決定するためのタイミングを投球側ユーザに指定させるためのUIオブジェクトとして機能する。
一例として、良否判定オブジェクト720は、弓形の帯状のゲージで構成される。良否判定オブジェクト720は、該ゲージ内に、帯の長手方向にスライドするスライドバー721と、スライドバー721が停止する帯上の位置を定義する第1領域722および第2領域723とを含む。
該帯状のゲージは、投手703の位置(以下、第1位置)から、捕手705の位置(以下、第2位置)に向かって伸びている。
UI制御部113は、スライドバー721を、初期位置である第1位置(例えば、図15の破線枠)から、最終位置である第2位置(例えば、図15のカーソル715の位置)に向かって、帯の長手方向(矢印の方向)に移動させる。アニメーション生成部114は、スライドバー721が、移動の開始から所定時間後に第2領域723を通過し、第1領域722を通過して、最終的にカーソル715の位置に到達するように、アニメーションを生成する。
ユーザは、スライドバー721が帯上の所望の位置に到達した時、その位置でスライドバー721を停止させるよう、タッチスクリーン15に対してタップ操作を行う。UI制御部113は、操作受付部111によってタップ操作が受け付けられた時の位置にて、スライドバー721を停止させる。対戦進行部115は、スライドバー721の停止位置に応じて、制球の良否を判定する。一例として、本実施形態では、対戦進行部115は、スライドバー721が第1領域722で停止した場合に、投手703が制球に完全に成功したと判定し、スライドバー721が第2領域723で停止した場合、成功に近い投球がなされたと判定し、それ以外の領域で停止した場合に、制球に失敗したと判定する。ここで、「制球に完全に成功した」とは、投手703が好投し、投球側ユーザによって指定された球種およびコースどおりに該ボールが仮想空間上を移動することを意味する。「成功に近い投球がなされた」とは、投球側ユーザによって指定された球種およびコースどおりにとはいかないが、それに近い球種およびコースに基づいて該ボールが仮想空間上を移動することを意味する。「制球に失敗した」とは、投手703が失投し、投球側ユーザによって指定された球種およびコースとはかけ離れた球種およびコースにて、該ボールが仮想空間上を移動することを意味する。
制球の良否が判定されると、次に、対戦進行部115は、図示しない第4の投球画面700を表示部152に表示させる。第4の投球画面700は、良否判定結果を含む。また、第4の投球画面700においては、投手703が投球を開始するアニメーションが付与され、これまで投手703のグローブに収まっていたボール704が描出されてもよい。これにより、投球側ユーザは、第3の投球画面700に対して行った自身の操作に関して、フィードバックを即時に受け取ることができる。
なお、良否判定オブジェクト720の帯状のゲージは、弓、アーチなど形状を有し、投げられたボールが描く放物線を模していることが好ましい。また、良否判定オブジェクト720の帯の幅は、第1位置から第2位置へ移動するにつれて、細くなるように定められていることが好ましい。また、該ゲージにおいて、第2位置に最も近く、最も帯の幅が細くなっている部分、すなわち、ゲージの先端が、ボールの到達予定位置として確定したカーソル715に重なるように、良否判定オブジェクト720が配置されることが好ましい。これにより、ユーザは、直観的に、帯状のゲージを、投手703から投げられたボールが、画面奥に配置されている捕手705に向かって移動する経路であるかのように理解する。以上のことから、本実施形態に係る良否判定オブジェクト720は、現実の野球を再現するという目的に反して、ゲームの興趣性を高める目的で追加されたUIでありながら、投球画面700を現実の投球シーンから乖離させることなく、見た目に違和感のない投球シーンを演出することに貢献している。
以上のように、投球側ユーザの投球側ユーザ端末において、対戦進行部115は、投球側ユーザの投球操作に基づいて、投手703の投球動作を決定する。決定した投球動作を示す投球結果D1は、サーバ200を介して対戦相手の他のユーザのユーザ端末100に供給される。
図16は、対戦画面のうち、自チームの攻撃回において表示される打撃画面750を示す。打撃画面750は、ユーザが野手のポジションに紐付けた打者701の打撃動作を決定するための打撃操作UIを含む。打撃操作UIは、打撃側ユーザによる打撃操作を受け付けるためのUIである。
1つのフェーズが開始され、相手チームの投手703の投球動作が進行すると、それに応じて投球側ユーザ端末またはサーバ200にて生成された投球結果D1が、打撃側ユーザ端末に供給される。打撃側ユーザ端末が、投球結果D1を受信すると、打撃側ユーザ端末の対戦進行部115は、例えば、図16に示す打撃画面750を、UI制御部113に生成させて、表示部152に表示させる。
対戦進行部115は、仮想空間としての球場における第1位置と第2位置との間に、ホームベース707を配置する。対戦進行部115は、ホームベース707上に、第1位置から第2位置に向かう方向に交差する方向に延在する交差面を設定する。対戦進行部115は、交差面に基づいて、打者701がボール704を打撃したか否かを判定する。上述したとおり、交差面は、例えば、ストライクゾーン751と、該ストライクゾーン751の外側に配置されるボールゾーン752とを含んでいてもよい。
操作受付部111が、投手703が投球したボール704が交差面に到達したタイミングで、ユーザからスイングのタイミングを指定する操作を受け付けると、打者701は、バット702をスイングすることによって、ボール704を打ち返す作用をボール704に与えることができる。図16に示すボール704は、投手703によって投球された後、交差面に向かって移動している途中のボール704の一例を示す。
図16に示すとおり、打撃画面750は、上述の他にも、各種オブジェクトを含んでいてもよい。特に、ユーザの打撃操作を支援するためのUIオブジェクトを含んでいることが好ましい。打撃操作を支援するUIオブジェクトとしては、例えば、タイミングヒントオブジェクト753、ミートカーソル754、位置ヒントオブジェクト755、方向ヒントオブジェクト756等がある。
タイミングヒントオブジェクト753は、打者701にバット702をスイングさせる良好なタイミングをユーザに示す。ミートカーソル754は、バット702がスイングされた際に交差面においてボール704に作用を与え得る領域として、スイングされたバット702の到達予定位置をユーザに示す。また、ミートカーソル754は、バット702とボール704との当たりを判定するために、対戦進行部115によって参照される領域でもある。位置ヒントオブジェクト755は、投手703によって投げられたボール704の、交差面における到達予定位置をユーザに示す。方向ヒントオブジェクト756は、投げられたボール704の進行方向の変化をユーザに示す。
本実施形態において、打撃結果D2を決定するための打撃操作には、一例として、ミートカーソル754の位置を指定するためのスライド操作と、決定したミートカーソル754の位置に向けてバット702を振るタイミングを指定するためのフリック操作とが含まれる。つまり、スライド操作が、投球に対して打撃を行う位置を指定する操作であり、フリック操作が、打撃を行うタイミング、つまりバット702を振るタイミングを指定する操作である。つまり、打撃側ユーザにとって、対戦、特に、攻撃の回を有利に進めることができるか否かは、マニュアル進行モードの場合、スライド操作とフリック操作との両方の巧拙にかかっている。
投手703からボール704が投げられると、打撃画面750において、操作受付部111は、上述の打撃操作を待機する状態に遷移する。操作受付部111が、タッチスクリーン15に対するユーザのスライド操作を受け付けると、該スライド操作にしたがって、UI制御部113は、ミートカーソル754を移動させる。なお、ユーザは、ミートカーソル754のベストの位置を、位置ヒントオブジェクト755を参考にして決定してもよい。
続いて、対戦進行部115は、投手703より投げられたボール704が交差面を基準とする所定の範囲内に到達したか否かを判定する。つまり、投げられたボール704が、ホームベース707上に設定された交差面に所定距離未満まで近づいてきたか否かを判定する。ボール704が交差面から所定距離未満まで到達したと判定された場合、UI制御部113は、ミートカーソル754の移動の少なくとも一部を制限してもよい。移動が制限されたことを示すように、UI制御部113はミートカーソル754の色または模様などの表示態様を変化させてもよい。
打撃画面750において、投げられたボール704には、ストライクゾーン751に向かって移動してくるアニメーションが、アニメーション生成部114によって付与される。ユーザは、移動してくるボール704を目で追い、ボール704がホームベース707上に到達したと思うベストのタイミングで、打者701が行うスイングの開始タイミングを指定するためにフリック操作を行うことができる。
ユーザは、フリック操作のベストのタイミングを計るために、さらに、タイミングヒントオブジェクト753を参考にすることができる。タイミングヒントオブジェクト753は、ボール704の投球が開始されたときから表示が開始され、ボール704がホームベース707上の交差面に近づくにつれてボール704の中心に向かって収縮するようなアニメーションが、アニメーション生成部114によって付与されている。さらに、該アニメーションは、ボール704が交差面に到達したタイミングで、ちょうどボール704の輪郭と同じ大きさにまで縮小するアニメーションである。ユーザは、タイミングヒントオブジェクト753の大きさを確認することにより、良好な打撃結果が得られるベストタイミングを計ることができる。
操作受付部111がフリック操作を受け付けると、対戦進行部115は、その時の交差面におけるボール704とミートカーソル754との位置関係に少なくとも基づいて、打者701がボール704に打撃を与えたか否かを判定する。つまり、ユーザのスライド操作とフリック操作とに基づいて、打者701によってスイングされたバット702が、ボール704に当たったか否かを判定する。例えば、交差面においてボール704がミートカーソル754と少なくとも部分的に重畳している場合には、打者701がボール704を打撃したと判定してもよい。
さらに、対戦進行部115は、操作受付部111が特定したフリック操作のタイミングに基づいて、打撃を与えたか否かの判定を実行してもよい。例えば、交差面におけるボール704およびミートカーソル754が打撃に適合した位置関係にある場合であっても、フリック操作のタイミングがボール704への打撃に適合したタイミングに対して、早過ぎたり遅すぎたりする場合には、対戦進行部115は、打者701がボール704を打撃しなかったと判定してもよい。
また、対戦進行部115は、上述の位置関係に少なくとも基づいて、打撃が与えられたボール704が仮想空間において移動する際の移動経路を算出する。具体的には、対戦進行部115は、上述の位置関係に基づいて、バット702とボール704との衝突を力学的にモデル化する。この場合、バット702に衝突した直後のボール704の速度ベクトル、回転軸、回転量等を、ボール704を移動させるための初期条件として取得すればよい。例えば、ボール704の下部をミートカーソル754の上部で打撃した場合には、打球の角度が上がりフライとなる。また、ボール704の上部をミートカーソル754の下部で打撃した場合には、打球の角度が下がりゴロとなる。また、例えば、対戦進行部115は、ミートカーソル754の中央の位置(図16の芯757)でボール704の中央を打撃する等の所謂ジャストミートの場合には、ライナーでボール704が飛ぶような移動経路を算出する。一方、ジャストミート以外の場合には凡打と判定して、凡打に対応する移動経路を算出してもよい。なお、対戦進行部115は、ボール704の速度ベクトル(初速など)、回転軸、回転量等を決定する際、打者701に設定されているスキル別身体パラメータ、特に、命中力および打撃力等を参照してもよい。
対戦進行部115が算出した移動経路にしたがって、アニメーション生成部114は、算出された移動経路を飛んでいくボール704のアニメーションを生成する。表示制御部112は、生成された、飛翔するボール704のアニメーションを、表示部152に表示する。
以上のように、打撃側ユーザの打撃側ユーザ端末において、対戦進行部115は、打撃側ユーザの打撃操作に基づいて、打者701の打撃動作を決定する。決定した打撃動作を示す打撃結果D2は、サーバ200を介して、対戦相手の他のユーザのユーザ端末100に供給される。
打撃結果D2に基づいて算出された移動経路にしたがって、ボール704が仮想空間内のフィールド上に移動した後は、各ユーザのユーザ端末100の対戦進行部115は、ゲームプログラム131にしたがって、仮想空間における、ボール704の移動、守備をする野手の動き、および、進塁する走者の動きなどをそれぞれ計算する。そして、計算結果に基づいて、仮想空間において各オブジェクトを移動させ、フィールドプレイシーンを進行させる。UI制御部113およびアニメーション生成部114は、計算されたフィールドプレイシーンに対応する画像またはアニメーションを生成して、表示部152に表示させてもよい。
なお、対戦進行部115は、打者701がボール704に打撃を与えなかったと判定した場合には、ボール704の移動経路の算出を省略してもよい。この場合、打者701がボール704を空振りするアニメーションがアニメーション生成部114によって生成され、該アニメーションが表示制御部112によって表示部152に表示される。
打撃画面750は、進行しているフェーズにおいて対決中の各キャラクタのステータス情報を含んでいてもよい。一例として、自チームの打者701のステータス情報758と、相手チームの投手703のステータス情報759とを含んでいてもよい。
(第1のカード獲得処理における画面例)
図3に示すとおり、メイン対戦ゲームが終了すると、次に、ゲームシステム1は、第1のカード獲得処理を実行する。具体的には、まずは、ゲームシステム1は、ユーザがメイン対戦ゲームをプレイしたことに対する報酬を該ユーザに付与する。本実施形態では、メイン対戦ゲームの報酬は、権利データとしてのパックと、パックポイントとを少なくとも含む。
本実施形態では、パック(権利データ)は、ユーザがキャラクタを獲得するために使用するデジタルデータであり、ユーザは、権利データを使用する、すなわち、パックを開封することによって、該パックに設定された期待値に基づいて特定されたキャラクタのカードを獲得することができる。
本実施形態では、パックは付与されただけでは、使用可能とならず、パックに関連付けられているパックポイントの合計が所定値に到達することにより使用可能となる。カード取得部116は、パックを運用する。具体的には、カード取得部116は、ユーザに付与されたパックポイントを、パックのパックポイント合計に加算し、該合計が所定値に到達した場合に、パックを使用不可能状態から使用可能状態へと遷移させる。
カード取得部116は、パックが使用可能状態へと遷移した場合に、該パックに基づいてキャラクタのカードを提供するように、サーバ200のカード提供部212に要求する。カード提供部212は、要求に応じて、使用されたパックの期待値に基づいてキャラクタを特定し、特定したキャラクタのカードを、ユーザが所有するデジタルデータとして該ユーザに紐付ける。
以上のとおり、第1のカード獲得処理とは、パックの付与、パックの運用(パックポイントの蓄積)、パック開封に伴うキャラクタの特定、特定されたキャラクタのカードのユーザとの紐付け、などの一連の処理を指す。
図17〜図22は、図3のステップS3に示される第1のカード獲得処理が実行されるときに、ユーザ端末100の表示部152において表示されるゲーム画面の一例を示す図である。
ステップS3では、ユーザ端末100の対戦進行部115は、付与された報酬をユーザに通知するために、例えば、図17および図18に示すゲーム画面を生成してもよい。表示制御部112は、ステップS3において、生成されたこれらのゲーム画面を表示部152に表示する。
図17は、ユーザに獲得させた報酬をユーザに通知するための報酬通知画面800の一例を示す図である。報酬通知画面800は、一例として、対戦をプレイしたことの報酬として付与された、経験値801、ゴールド802、および、パックポイントパックポイント803を含む。経験値は、対戦をプレイするユーザに関連付けて付与される。経験値が一定以上貯まると、ユーザランクが上昇する。ユーザランクは、例えば、チームまたは各選手のパラメータなどに対して影響を与えてもよく、その影響は、ユーザランクが高いほど、対戦が有利に進められるようにプラスに作用する。ゴールドは、プレイされるゲーム内で消費することが可能なゲーム内価値であり、例えば仮想通貨である。具体的には、ゴールドと引き換えに対戦を有利に進めるための各種アイテムが入手できてもよい。
パックポイントは、パックを開封(使用)不可能状態から可能状態に遷移させるために必要なゲーム内価値である。パックポイントは、スロットに配置されたカードパックに対応付けられている開封の条件を、貯めることで満足させるものである。これにより、ユーザは、カードパックから選手カードを取り出したいために、パックポイントを得ようとして、強い動機を持って、対戦プレイを繰り返し行うことができる。
サーバ200の対戦支援部211は、ユーザが対戦をプレイすると、たとえ対戦に負けたとしても、上述の報酬を必ずもらえるように算定してもよい。また、対戦支援部211は、対戦の成績が良いほど、より多くの経験値、ゴールド、および、パックポイントが付与されるように、報酬を算定することが好ましい。これにより、成績が伴わない熟練度の低いユーザに対しては、やる気を削がないようにすることができる一方、熟練度の高いユーザに対しては、負けたくないとか、いい成績で勝ちたいとかいった競争心、または、より操作に習熟したいという向上心を、芽生えさせることができる。このように、ユーザの熟練度を問わず、あらゆるユーザの、ゲームをプレイすることに対する動機付けをより一層強化することができる。
さらに、本実施形態では、対戦支援部211は、オート進行モードにて対戦が進行された割合、すなわち、オート進行モードの使用率を記憶しておいてもよい。そして、どのランクのカードパックをユーザに付与するのかを、該オート進行モードの使用率に基づいて決定してもよい。具体的には、対戦支援部211は、オート進行モードの使用率が低いほど、高いランクのカードパックが付与されるように報酬を決定してもよい。これにより、マニュアル進行モードに基づくプレイをユーザに促すことができ、対人対戦におけるゲームの興趣性を一層向上させることができる。
ユーザ端末100の対戦進行部115は、オート進行モードの使用率を、オート使用率804として、図17に示すゲーム画面に含めてもよい。さらに、対戦進行部115は、対戦成績805を該ゲーム画面に含めてもよい。
図18は、ユーザに獲得させた報酬としてのパックをユーザに通知するためのパック通知画面810の一例を示す図である。パック通知画面810は、いずれのランクのパックが付与されたのかをユーザに通知するために表示部152に表示される。パック通知画面810は、一例として、対戦をプレイしたことの報酬として付与された、パック811を含む。表示制御部112は、図17に示す報酬通知画面800および図18に示すパック通知画面810を、一画面に同時に表示させてもよいし、任意の順序で順次表示させてもよい。
図18に示すOKボタン812が、ユーザの操作により押下されると、カード取得部116は、パックを運用するためのゲーム画面、すなわち、パックを配置するスロットを含むゲーム画面(図19〜図20)を生成する。カード取得部116によって生成されたゲーム画面は、表示制御部112によって表示部152に表示される。一例として、カード取得部116は、図19に示すゲーム画面を生成し、表示部152に表示させる。
図19は、パックの運用進捗をユーザに通知するためのパック運用画面820の一例を示す図である。パック運用画面820は、ユーザが所有する1以上のスロットの状態を一覧するためのスロット一覧821を含む。図19に示す例では、ユーザには、デフォルトで3つのスロット822〜824が提供されている。本実施形態では、スロットには順序が設けられており、一番左のスロット822を先頭として、右に行くにつれて順序が後ろになるようにスロット823、および、スロット824が表示されている。
図19に示すスロット822は、付与されたばかりのパック811(図18)が、該スロット822に配置されたことを表している。カード取得部116は、新たなパック811が付与されると、該パック811を、空いているスロットの中で順番が一番前のスロット(図19に示す例では、スロット822)に、自動的に配置する。そして、パック811が開封可能な状態に遷移するまで、パック811をスロット822で待機させる。上述したとおり、本実施形態では、カードパックは、カード取得部116が、スロットに配置しなければ、パックポイントを貯められる状態にならない。それゆえ、スロットは、カードパックが開封可能な状態へと遷移していくことを可能にする第1の要件である。
さらに、本実施形態では、カードパックがパックポイントを貯められる状態になるために、第2の要件が設定される。第2の要件は、パックポイントの加算を可能にするツールを利用することをユーザに課す。該ツールは、一例として、本野球ゲームの文脈に沿ってスカウトマンという形態でユーザに提供される。本実施形態では、一例として、カード取得部116は、1つのスロットにつき、一人のスカウトマンを割り当てる。本実施形態では、スカウトマンが割り当てられたスロットにカードパックが配置されることにより、該カードパックにパックポイントを貯めることが可能となる。換言すれば、カードパックは、第1の要件としてスロットに配置されること、および、第2の要件として該スロットにスカウトマンが割り当てられていること、の2つが満たされて、パックポイントを加算していくことが不可能な状態(以下、加算不可状態)から、パックポイントを加算していくことが可能な状態(以下、加算可能状態)へと移行する。
加算可能状態とは、開封のための所定の条件を満足するべく、カードパックの状態を変化させていくことができる状態を意味する。具体的には、条件として設定されたパックポイントの合計に到達すべく、パックポイントを貯めることが可能な状態を意味する。反対に、加算不可状態とは、上述の所定の条件を満足するべく、カードパックの状態を変化させていくことができない状態を意味する。具体的には、パックポイントを貯めることが不可能な状態、つまり、パックポイントが獲得されてもカードパックに対応付けてポイントは貯まらない状態を意味する。
カード取得部116は、報酬としてパックポイントがユーザに付与された場合、付与されたパックポイントを、スカウトマンが割り当てられたスロットに配置されているカードパックに対して加算する。例えば、図17に示す例では、218ポイントのパックポイントが付与された。図19に示す例では、スカウトマン825が割り当てられている状態でかつカードパックが配置されているのはスロット822である。そこで、カード取得部116は、付与された218ポイントを、スロット822に配置されているパック811に対して加算する。
カード取得部116がパック811にパックポイントを加算した結果、パックポイントの合計が所定値に到達した場合、カード取得部116は、パック811を、開封不可能状態から開封可能状態へと遷移させる。そして、カード取得部116は、パック811のパックポイントの合計が条件を満たしたことをユーザに通知するために、図20に示すゲーム画面を生成し、表示部152に表示させてもよい。
図20は、パックの運用進捗をユーザに通知するためのパック運用画面820の別の例を示す図である。図20に示す例では、ゲージ826は、パック811に対してパックポイントが加算された結果、貯められたパックポイントが、条件である「800pt」に到達したことを示している。この画面が表示された後、カード取得部116は、パック811を開封する処理を実行する、すなわち、パック811に基づいて、ユーザに所有させるキャラクタのカードを特定するように、サーバ200に要求する。ここで、パック811は消費され、スロットに空きができる。
本実施形態では、スカウトマンが割り当てられているスロットに空きができた場合に、その空きのスロットよりも後ろに、スカウトマンが割り当てられていないスロットがあって、該スロットにカードパックが配置されている場合が想定される。該カードパックは、スカウトマンがいないために、パックポイントが貯められず単にスロットに待機している状態である。このような場合、カード取得部116は、該カードパックを、上述の空きのスロットに繰り上げて配置する。これにより、該カードパックは、パックポイントが貯められる状態になる。
図20に示すように、カードパックのゲージがいっぱいになったとき、カード取得部116は、該パックを開封可能な状態に遷移させた上で、パックを開封してカードをユーザに獲得させる。このとき、カード取得部116は、パックが開封されて、キャラクタのカードが取得されようとしているシーンを演出するゲーム画面を生成し、表示部152に表示させてもよい。不図示の該ゲーム画面は、例えば、パック811の封が切られて、中から1以上の所定枚数のカードが、絵柄が伏せられた状態で取り出されるシーンを表現したアニメーションを含んでいてもよい。
カード取得部116は、サーバ200のカード提供部212から、開封されたカードパックに基づいて特定された、ユーザに所有させるキャラクタのカードについての通知を受け取る。このとき、カード取得部116は、獲得されたキャラクタをユーザに通知するために、図21に示すゲーム画面を生成し、表示部152に表示させてもよい。
図21は、ユーザに獲得させたキャラクタをユーザに通知するためのキャラクタ通知画面830の一例を示す図である。例えば、キャラクタ通知画面830は、開封されたカードパックと引き換えに獲得されたキャラクタの絵柄が示されたカード831〜833を含んでいる。各カードは、例えば、選手の画像、選手名、選手の所属チーム名、および、カードの希少度を示す情報を含んでいる。いずれかのカードを選択すると、選択されたカードについて、さらに詳細情報が表示されてもよい。例えば、選手の能力に係る各種パラメータが表示されてもよい。
(処理の流れ)
図22は、ゲームシステム1がゲームプログラム131に基づいて実行するメイン対戦ゲームおよび第1のカード獲得処理の流れを示すフローチャートである。以下で、ユーザ端末100が実行するものとして説明した処理は、サーバ200が実行してもよいし、反対に、サーバ200が実行するものとして説明した処理は、ユーザ端末100が実行してもよい。図22に示す一連の処理は、図3に示すステップS2およびS3の処理に対応している。
ステップS201では、ユーザ端末100の操作受付部111が、対戦の開始を指示するユーザの操作を、入力部151を介して受け付ける。これに応じて、対戦進行部115は、メインゲーム対戦を開始するためのマッチングをサーバ200に対して要求する。
ステップS202では、サーバ200の対戦支援部211は、通信IF23を介して、ユーザ端末100から上述の要求を受け付ける。これに応じて、対戦支援部211は、マッチング処理を実行し、ユーザの対戦相手を探索する。対戦相手が見つかり、マッチングが成立した場合、対戦支援部211は、ステップS203に進む。
ステップS203では、対戦支援部211は、マッチングされた各ユーザ端末100が対戦を進行させることができるように、対戦を実施するユーザ端末100同士に情報を共有させ、同期制御を行って、対戦を支援する。例えば、対戦支援部211は、マッチングが成立した旨を対戦進行部115に通知するとともに、対戦相手および相手チームの情報をユーザのユーザ端末100に提供する。
ステップS204では、対戦進行部115は、対戦支援部211と通信して、メインゲーム対戦を進行させる。対戦進行部115は、対戦の開始時に、図11に示すマッチング成立画面600を表示部152に表示させてもよい。そして、対戦進行部115は、自チームの守備回において、投球結果D1をサーバ200に送信して、マウンドにおける投球のイベント、および、フィールドにおける守備のイベントなどを進行させる。対戦進行部115は、守備回において、例えば、図13〜図15に示す投球画面700を表示部152に表示させてもよい。また、対戦進行部115は、自チームの攻撃回において、打撃結果D2をサーバ200に送信して、バッターボックスにおける打撃のイベント、飛球のイベントなどを進行させる。対戦進行部115は、攻撃回において、例えば、図16に示す打撃画面750を表示部152に表示させてもよい。
ステップS205でYESの場合、例えば、全イニングの進行が完了した場合、ステップS206では、対戦支援部211は、成績を決定する。一例として、対戦支援部211は、メイン対戦ゲームが実行されている間に記憶部220に記録されていたゲーム情報132から勝敗、得点、奪三振数、安打数、本塁打数、および、オート制御使用率などを読み出す。
ステップS207では、対戦支援部211は、決定した対戦成績に基づいて、メイン対戦ゲームをプレイしたユーザに付与する報酬を算定する。本実施形態では、一例として、対戦をプレイしたことの報酬として、カードパック、経験値、ゴールド、および、パックポイントなどがユーザに付与される。例えば、対戦支援部211は、対戦成績が良いほど高いランクのカードパック、または、より多くのパックポイントが付与されるように、報酬を算定する。
ステップS208では、対戦支援部211は、算定した報酬を、ユーザに付与する。本実施形態では、一例として、該報酬(例えば、カードパック)を、上述のユーザのユーザ識別情報に関連付けて、ゲーム情報132として保存する。あるいは、対戦支援部211は、対戦前の経験値、ゴールド、および、パックポイントに対して、今回の報酬としての経験値、ゴールド、および、パックポイントをそれぞれ加算して、ユーザのゲーム情報132を更新する。これにより、ユーザに、上述の報酬を獲得させることができる。対戦支援部211は、ユーザに付与した報酬の内容を、ユーザ端末100に通知してもよい。
ステップS209では、ユーザ端末100の対戦進行部115は、上述の通知を受信すると、例えば、図17に示す報酬通知画面800および図18に示すパック通知画面810を生成し、表示部152に表示させてもよい。対戦進行部115は、対戦支援部211からの報酬に係る通知に基づいて、記憶部120のゲーム情報132を更新し、ユーザに報酬を獲得させる。カード取得部116は、パックが獲得されると、該パックを運用し、キャラクタのカードをユーザに獲得させるための一連の処理を実行する。
ステップS210でYESの場合、すなわち、カードパックが配置されていない空きのスロットがあれば、ステップS211において、カード取得部116は、付与されたカードパックを、該空きのスロットに配置する。本実施形態では、ユーザが所有するスロットに1つでも空きがあれば、カード取得部116は、付与されたカードパックを、空きのスロットに自動的に配置してもよい。例えば、カード取得部116は、図19に示すパック運用画面820を表示部152に表示させてもよい。
一方、ステップS210でNOの場合、すなわち、ユーザが所有するすべてのスロットがすでにカードパックで埋まっている場合、カード取得部116は、ステップS209で新たに付与されたカードパックをどこのスロットにも配置することができない。
この場合、ステップS212では、カード取得部116は、新たに付与されたパックを破棄する。すなわち、パックに係るデジタルデータは、記憶部120または記憶部220に格納されることなく消滅する。
なお、別の実施形態では、カード取得部116は、空きスロットが無いために配置できないパックについて、スロットに配置するまでもなくカードパックを即時に開封する機会を、所定の条件付きでユーザに提供してもよい。具体的には、カード取得部116は、所定の消費アイテム等のゲーム内価値と引き換えることを条件に、カードパックを即時に開封するか否かを問うメッセージを表示部152に表示させてもよい。ここで、カードパックを「即時に」開封することを提案するとは、カードパックをスロットに配置することを待たずに、あるいは、パックポイントが条件に到達することを待たずに、カードパックを開封する機会をユーザに与えることを意味する。したがって、「即時に開封する」との用語は、カードパックが付与された瞬間ただちに開封すること、および、消費アイテムが消費された瞬間ただちに開封することのみに限定して解釈されるべきではない。
ステップS213において、カード取得部116は、ステップS209で付与されたパックポイントを、スロットに配置され、かつ、スカウトマンが割り当てられているカードパックに対応付けられているパックポイントの合計に加算する。該ユーザによって、カードパックが配置されているスロットが複数所有されている場合には、カード取得部116は、付与されたパックポイントを、第1および第2の要件をともに満たすカードパックのそれぞれに加算してもよいし、付与されたパックポイントを所定の割合で各カードパックに分配してもよい。例えば、カード取得部116は、図20に示すパック運用画面820を表示部152に表示させてもよい。
ステップS214において、カード取得部116は、各パックのパックポイントの合計が所定の条件を満たすか否かを判定する。カードパックに対応付けられているパックポイントが、該カードパックに割り当てられている条件を満足しない場合、カード取得部116は、一連の第1のカード獲得処理を終了させる。この後、対戦進行部115が、ステップS214のNOから、図3に示すステップS4に進み、以降の処理を実行する。
一方、ステップS213において、パックポイントが加算された結果、スロットに配置されているいずれかのパックのパックポイントの合計が所定値に到達した場合、カード取得部116は、ステップS214のYESからステップS215に進む。
ステップS215において、カード取得部116は、パックポイントの条件を満たしたパックを開封可能な状態へと遷移させる。そして、カード取得部116は、該パックに基づいて、キャラクタのカードの取得要求を、サーバ200に送信する。具体的には、カード取得部116は、消費するカードパックを指定して、該カードパックに基づいてユーザに所持させる選手カードを特定するように、サーバ200に要求する。
ステップS216では、サーバ200のカード提供部212は、ユーザ端末100から指定されたカードパックに設定されているランクに基づいて、ユーザに提供するキャラクタを特定する。本実施形態では、カード提供部212は、カードパックのランクに対応する期待値に基づいて、抽選を実施し、所定のキャラクタの集合の中から、ユーザに獲得させるキャラクタのカードを所定枚数特定する。本実施形態では、一例として、カード提供部212は、1つのカードパックにつき、3枚のカードを特定してもよい。
ステップS217では、カード提供部212は、選択した3枚のカードを、ユーザに提供し、所有させる。具体的には、カード提供部212は、該3枚のカードを、ユーザ識別情報に関連付けて、ゲーム情報132として記憶部220に保存する。これにより、ユーザは、これらのカードを所持することができ、これらのカードのキャラクタを起用して、対戦ゲームにおいて、該キャラクタを動作させることができる。カード提供部212は、ユーザに所持させた3枚のカードの内容を、ユーザ端末100に通知してもよい。
ステップS218では、ユーザ端末100のカード取得部116は、上述の通知を受信すると、ユーザにキャラクタのカードを獲得させる。具体的には、カード取得部116は、提供されたキャラクタのカードを、ユーザが所有するカードとして記憶部120に格納する。カード取得部116は、ユーザに獲得させたカードを通知するために、図21に示すキャラクタ通知画面830を表示部152に表示させてもよい。この後、対戦進行部115は、図3に示すステップS4に進み、以降の処理を実行する。
<サブ対戦ゲームの意義について>
本実施形態において、本野球ゲームは、上述したとおり、メイン対戦ゲームに加えてサブ対戦ゲームを含む。例えば、サブ対戦ゲームは、メイン対戦ゲームより簡易に構成されていることが好ましい。ここで、「簡易に構成されている」とは、対戦の開始から終了までの所要時間が短いことを意味していてもよい。あるいは、メイン対戦ゲームでは、全イニングにおいて、オート進行モードとマニュアル進行モードとをユーザが任意に切り替えることができるのに対して、サブ対戦ゲームは、所定の局面を除いてオート進行モードにて進行することを意味していてもよい。あるいは、メイン対戦ゲームでは、例外を除いて概して他のユーザを相手とする対人対戦が実施されるが、サブ対戦ゲームでは、コンピュータを相手とするコンピュータ対戦が実施されることを意味していてもよい。つまり、サブ対戦ゲームは、本野球ゲームにおいて、高い集中力が要求されるメイン対戦ゲームとは別に、ユーザの気分転換になるように設けられたものである。
このようにサブ対戦ゲームをメイン対戦ゲームと比較して簡易に構成することにより、ユーザは、メイン対戦ゲームよりも気軽にサブ対戦ゲームに取り組むことができる。これにより、ゲームプレイに伴うユーザの緊張感、および、操作に係る負担が緩和される。
その上、本実施形態では、サブ対戦ゲームがプレイされたことに対して報酬がユーザに付与される。サブ対戦ゲームの報酬は、上述したとおり、一例として交換ポイントである。本実施形態では、交換ポイントは、一例として、キャラクタのカードを交換可能なゲーム内価値である。このように、メイン対戦ゲームをプレイする他にも、気軽に取り組めるサブ対戦ゲームをプレイすることによって、キャラクタのカードを獲得する方法をユーザに提供する。これにより、ゲームをプレイする意欲をユーザが損なうことを回避することができる。
本野球ゲームの興趣性は、基本的には、強いキャラクタのカードをデッキに組み入れることにより、強いチームを作り、そのような強いチームによって対戦で勝つことに見出される。つまり、強いキャラクタのカードを獲得できることがユーザの楽しみであり、プレイを継続する強い動機付けにつながる。
ここで、キャラクタのカードを獲得する方法がメイン対戦ゲームしかない場合には、ユーザのメイン対戦ゲームをプレイするモチベーションが一度下がってしまうと、キャラクタのカードが獲得できず、デッキの強化に進展がなくなり、一層モチベーションが低下する、というような悪循環からユーザを救済することが難しい。精神的負担が大きいメイン対戦ゲームに疲れる、敗北が続いて面白さを感じられない、十分な時間を取ってメイン対戦ゲームに取り組めない、など、モチベーションが下がる原因はいろいろ考えられる。したがって、メイン対戦ゲームのみですべてのユーザのモチベーションを維持し続けることは非常に難しい。
このような課題に対して、本実施形態によれば、より気軽に取り組めるサブ対戦ゲームを設ける。さらに、該サブ対戦ゲームをプレイすることでもキャラクタのカードが入手できる仕組みを構築する。これにより、ユーザのモチベーションが低下することがあったとしても、上述のような悪循環に陥ることを回避することが可能となる。
<事前処理>
本実施形態では、一例として、対戦進行部115は、メイン対戦ゲームの合間に一定の確率でサブ対戦ゲームをプレイする機会をユーザに与える。具体的には、対戦進行部115は、以下に説明する事前処理を実行して、サブ対戦ゲームを実行するか否かを決定する。事前処理を説明する前に、まず、サブ対戦ゲームの概要を説明する。
本実施形態では、一例として、対戦進行部115は、ユーザのチームを、COMチームと対戦させるサブ対戦ゲームを提供する。COMチームとは、ゲームプログラム131に基づいて、サーバ200またはユーザ端末100によって動作が制御される1以上のキャラクタで構成されたチームである。本実施形態では、一例として、COMチームは、日本代表に選ばれた選手で構成された日本代表チームである。
日本代表チームのデッキ情報は、予め、記憶部220または記憶部120にゲーム情報132として格納されていてもよい。この場合、対戦進行部115が、必要に応じて日本代表チームのデッキ情報を適宜読み出す。日本代表チームのデッキ情報は、サブ対戦ゲームを実行することが決定されたことに応じて、都度、対戦進行部115によって作成されてもよいし、都度、対戦支援部211から提供されてもよい。
本実施形態では、一例として、日本代表チームは、強さに応じて、複数チーム提供される。強さとは、対戦における有利性または勝利のし易さを指す。具体的には、デッキ総合パラメータ、または、日本代表チームを構成する各選手の能力値が高いほど、強いチームである。
本実施形態では、一例として、強さが異なる4種類の日本代表チームのデッキ情報が、予め記憶部220または記憶部120に格納されている。各日本代表チームには、強い順に、「超級」、「上級」、「中級」および「初級」の等級が設定されている。
本実施形態では、一例として、対戦進行部115は、事前処理を実行する。具体的には、対戦進行部115は、まず、所定の確率に基づいて、サブ対戦ゲームをプレイする機会をユーザに与えるか否かを決定する。すなわち、対戦進行部115は、後述する出現確率に基づいて、メイン対戦ゲームの後、サブ対戦ゲームでユーザのチームと対戦させる日本代表チームを出現させるか否かを決定する。また、対戦進行部115は、該出現確率に基づいて、ユーザのチームと対戦させる日本代表チームの等級を決定する。例えば、対戦進行部115は、日本代表チームを出現させるか否かと、出現させる場合の日本代表チームの等級とを、上述の出現確率に基づいて1回の抽選により決定してもよい。
(出現確率について)
図23は、出現確率表のデータ構造の一例を示す図である。出現確率表は、対戦進行部115が事前処理を実行するときに参照するデータである。出現確率表は、対戦進行部115が、日本代表チームとのサブ対戦ゲームをプレイする機会をユーザに対して与えるか否かを決定するために参照される。また、出現確率表は、対戦進行部115が、サブ対戦ゲームのプレイ機会を与える場合に、相手チームである日本代表チームの等級を決定するために参照される。
出現確率表において、事前処理で実行される抽選の出目ごとに出現確率が設定される。出目は、例えば、日本代表チームを出現させる場合の該日本代表チームの各「等級」、および、日本代表チームを出現させない場合を意味する「出現なし」である。図23に示す例では、5つの出目ごとに出現確率が設定される。
本実施形態では、一例として、メイン対戦ゲームにおけるユーザの勝敗に応じて、異なる出現確率が設定されていてもよい。例えば、出現確率表は、メイン対戦ゲームにおいてユーザが勝利した場合に参照される第1確率表620と、ユーザが敗北した場合に参照される第2確率表621とを含んでいてもよい。
本実施形態では、勝利時の日本代表チームの出現確率は、敗北時の出現確率より高く設定されていてもよい。つまり、第1確率表620の各等級の出目に設定された確率は、第2確率表621の各等級の出目に設定された確率よりも高く設定される。さらに、勝利時は、いずれかの等級の日本代表チームが必ず出現するように、第1確率表620が設定されていてもよい。つまり、第1確率表620において、出目「出現なし」には、確率「0(%)」が設定されていてもよい。
対戦進行部115は、あるいは、ユーザがメイン対戦ゲームにおいて所定回数連敗した場合には、日本代表チームが必ず出現するように、第2確率表621に代えて、別の確率表を参照してもよい。すなわち、該別の確率表においては、出目「出現なし」には、確率「0(%)」が設定されている。そして、対戦進行部115は、ユーザが所定数の連敗を喫した場合には、第2確率表621の代わりに、上述の別の確率表を参照して、日本代表チームを出現させることを必ず決定してもよい。あるいは、対戦進行部115は、ユーザの連敗数に応じて、第2確率表621の確率値をそれぞれ補正してもよい。具体的には、対戦進行部115は、各等級の出目の確率を上げ、「出現なし」の出目の確率を下げるまたはゼロにする。
本野球ゲームでは、キャラクタのカードはメイン対戦ゲームの対戦をプレイすることにより付与されるパックから入手される。したがって、連敗しているユーザは、強いキャラクタのカードを入手しにくく、ゲームを続ける意欲が損なわれる虞がある。そこで、このようなユーザに対して、キャラクタのカードと交換できる交換ポイントが報酬として得られるサブ対戦ゲームのプレイ機会を必ず与えるようにする。ユーザは、これにより、メイン対戦ゲームとは別の気軽に取り組めるサブ対戦ゲームにおいて交換ポイントを貯めることにより、キャラクタのカードを入手する機会を得ることができる。結果として、メイン対戦ゲームで負けが続いてプレイ意欲が低迷しているユーザに対して、動機付けを与え、プレイ意欲を回復させることが可能となる。
本実施形態では、さらに、各等級の日本代表チームの出現確率は、ユーザのレーティングに応じて設定されてもよい。レーティングは、ユーザの強さを表す指標である。対戦進行部115は、上述の制御するステップにおいて、ユーザに付与されたレーティング(評価値)が示す該ユーザの対戦における強さが強いほど、強い日本代表チーム(チーム)を、より高い確率でサブ対戦ゲームの相手チームとして決定してもよい。例えば、日本代表チームの強さがユーザの強さにだいたい見合うように、出現確率が設定される。図示の例では、例えば、ユーザの強さを、レーティングに基づいて4つに区分する。そして、区分ごとに異なる、第1確率表620および第2確率表621をそれぞれ設定する。
なお、本実施形態では、ユーザのチームが、高い等級、すなわち、強い日本代表チームと対戦するほど、対戦進行部115は、該ユーザに対して付与する交換ポイントを多くすることが好ましい。図23に示すとおり、日本代表チームの等級ごとに、報酬として付与される交換ポイントが予め設定されていてもよい。
上述の構成によれば、ユーザのレーティングが高いほど、強い日本代表チームと当たり易くなり、結果として、交換ポイントが貯まり易くなる。したがって、交換ポイントを効率よく貯めるために、ユーザは、レーティングを上げたいと望み、メイン対戦ゲームをプレイすることを促される。
また、本実施形態では、対戦進行部115は、ユーザが日本代表チームに勝利した場合、敗北した場合よりも多くの交換ポイントを該ユーザに付与することが好ましい。また、敗北した場合にも、交換ポイントがユーザに付与されることが好ましい。これにより、ユーザは、気軽ではあるが、勝利を目指してサブ対戦ゲームに取り組むように促される。また、敗北した場合でも交換ポイントが付与されるので、ユーザは、サブ対戦ゲームに取り組むこと自体に価値を見出し、より気軽にサブ対戦ゲームを楽しむことができる。
(画面例)
図24は、サブ対戦ゲームをプレイする機会が与えられたこと、具体的には、日本代表チームが出現したことをユーザに通知するためのメッセージ画面840の一例を示す図である。例えば、メッセージ画面840は、日本代表チームと対戦する機会がユーザに与えられたことを通知するためのメッセージ841と、出現した日本代表チームの等級842とを含む。
本実施形態では、対戦進行部115は、さらに、サブ対戦ゲームをプレイするか否かをユーザに選択させるためのUI部品をメッセージ画面840に配置してもよい。具体的には、メッセージ画面840は、日本代表チームとの対戦に挑戦しないことを選択するためのボタン843と、該対戦に挑戦することを選択するためのボタン844とを含んでいてもよい。
ボタン843がタップ操作された場合には、対戦進行部115は、メイン対戦ゲームが終了した後に通常遷移する画面(例えば、不図示のメニュー画面など)を表示部152に表示させる。一方、ボタン844がタップ操作された場合には、対戦進行部115は、サブ対戦ゲームの画面を表示部152に表示させて、日本代表チームとの対戦を進行する。
なお、別の実施形態では、対戦進行部115は、日本代表チームを出現させると決定した場合には、メッセージ画面840において、ユーザに、サブ対戦ゲームをプレイするか否かを選択させることなく、強制的にサブ対戦ゲームを実行してもよい。
(処理の流れ)
図25は、ゲームシステム1がゲームプログラム131に基づいて実行する事前処理の流れを示すフローチャートである。以下で、ユーザ端末100が実行するものとして説明した処理は、サーバ200が実行してもよい。図25に示す一連の処理は、図3に示すステップS4の処理に対応している。
ステップS301では、対戦進行部115は、上述の出現確率表のうち、ユーザのレーティングに応じた区分の確率表を読み出す。
ステップS302では、対戦進行部115は、先のステップ(図3のステップS2)にて実行されたメイン対戦ゲームにおいて、ユーザが勝利したか否かを判定する。対戦進行部115は、ユーザが勝利した場合、ステップS302のYESからステップS303に進む。一方、対戦進行部115は、ユーザが敗北した場合、ステップS302のNOからステップS304に進む。
ステップS303では、対戦進行部115は、第1確率表620を選択する。
ステップS304では、対戦進行部115は、第2確率表621を選択する。
ステップS305では、対戦進行部115は、ユーザの連敗数に応じて選択した第2確率表621の各出目の確率を補正してもよい。ステップS305は省略されてもよい。
ステップS306では、対戦進行部115は、選択した確率表に基づいて、抽選を実施する。
ステップS307では、対戦進行部115は、当選した出目が、「出現なし」か、それ以外の等級の出目かを判定する。当選した出目が、日本代表チームのいずれかの等級の出目である場合、対戦進行部115は、サブ対戦ゲームをプレイする機会をユーザに与えることを決定し、ステップS307のYESからステップS308に進む。一方、ステップS307において、対戦進行部115は、当選した出目が「出現なし」である場合、ステップS307のNOからステップS311に進む。
ステップS308では、対戦進行部115は、日本代表チームが出現した旨を通知し、日本代表チームに挑戦するか否かをユーザに選択させるためのメッセージ画面840を表示部152に表示させる。
ステップ309では、対戦進行部115は、日本代表チームに挑戦しないことを選択するボタン843、および、日本代表チームに挑戦することを選択するボタン844のいずれがタップされたのかを判定する。操作受付部111が、ボタン844に対するタップ操作を受け付けた場合、対戦進行部115は、ステップS309のYESからステップS310に進む。一方、操作受付部111が、ボタン843に対するタップ操作を受け付けた場合、対戦進行部115は、ステップS309のNOからステップS311に進む。
ステップS310では、対戦進行部115は、ボタン844がタップされたことに伴い、当選した等級の日本代表チームとのサブ対戦ゲームを実行することを決定する。
ステップS311では、対戦進行部115は、「出現なし」の出目が当選したこと、または、ボタン843がタップ操作されたことに伴い、サブ対戦ゲームを実行しないことを決定する。
<サブ対戦ゲームから第2のカード獲得処理まで>
対戦進行部115は、サブ対戦ゲームを実行することを決定した場合には、当選させた日本代表チームとの対戦の進行を開始する。メイン対戦ゲームと同様に、サブ対戦ゲームは、複数のフェーズで区切られており、各フェーズは、キャラクタの動作を決定するためにユーザが実施する操作の影響を受けて、ゲームプログラム131にしたがってキャラクタを動作させるマニュアル進行モード、または、ユーザが実施する操作の影響を受けずに、ゲームプログラム131にしたがってキャラクタを動作させるオート進行モードで進行する。本実施形態では、対戦進行部115は、メイン対戦ゲームでは、上述のとおり、ユーザが、フェーズごとに、マニュアル進行モードとオード進行モードとを任意に切り替えることが可能である。対戦進行部115は、ユーザによって、マニュアル進行モードで進行させることが指定された各フェーズを、該マニュアル進行モードにて進行させる。一方、本実施形態では、対戦進行部115は、サブ対戦ゲームでは、所定の条件を満たすフェーズを除き、各フェーズをオート進行モードにて進行させる。
具体的には、対戦進行部115は、サブ対戦ゲームを基本的にオート進行モードにて進行させ、対戦の局面が所定の条件に合致した場合に、当該局面のフェーズを、例外的に、マニュアル進行モードに切り替えて進行させる。例えば、対戦進行部115は、ユーザのチームが守備回のときに、得点圏に相手チームの走者が進塁した場合に、その直後の打席における投球のフェーズをマニュアル進行モードに切り替える。あるいは、対戦進行部115は、ユーザのチームが攻撃回のときに、自チームの走者が得点圏に進塁した場合に、その直後の打席のフェーズをマニュアル進行モードに切り替える。
つまり、勝敗を左右する重要な局面を除いては、すべてのイニングはオート進行モードにて進行するため、ユーザの操作が対戦の進行に影響を与える期間は短縮され、操作に係る負担も大幅に削減される。また、サブ対戦ゲームの成績は、メイン対戦ゲームの成績に影響を与えない。以上のことから、ユーザは、サブ対戦ゲームを、メイン対戦ゲームの合間の気分転換として、気軽に楽しむことができる。
サブ対戦ゲームが終了すると、対戦進行部115または対戦支援部211は、第2のカード獲得処理を実行する。具体的には、サブ対戦ゲームにおけるユーザの成績に応じて交換ポイントを算出し、ユーザに付与する。成績とは、例えば、対戦の勝敗、および、マニュアル進行モードで進行していた期間においてユーザがキャラクタに達成させた記録などを含む。このようにして、交換ポイントがサブ対戦ゲームの報酬としてユーザに付与されることにより、ユーザは、交換ポイントを用いてキャラクタのカードを獲得することができる。
(サブ対戦ゲームにおける画面例)
図26および図27は、図3に示すステップS6にて対戦進行部115が表示部152に表示するオート進行画面の一具体例を示す図である。図26に示すオート進行画面850は、対戦の局面が所定の条件を満たしていない期間のある時点で表示されるオート進行画面の一例である。オート進行画面850は、少なくとも、オート進行モードにて進行している対戦の局面を示す情報を含む。一例として、オート進行画面850は、スコアボード851を含む。スコアボード851は、各チームの各イニングの得点、並びに、各チームの現在の得点、ヒットの数、およびエラーの数を示す。なお、本野球ゲームにおいて、サブ対戦ゲームは、図示のスコアボード851が示すように、9イニングで構成されていてもよい。
また、オート進行画面850は、各チームの現在の得点を示す得点表示852、ユーザ本人のユーザ名853、対戦相手のユーザ名854、ユーザ本人が操作する自チームのチーム名855、対戦相手が操作する相手チームのチーム名856を含んでいてもよい。本実施形態では、対戦相手のユーザ名854は、日本代表チームの等級を示している。
また、オート進行画面850は、その他のUIを含んでいてもよい。例えば、現在打席に立っている打者キャラクタのキャラクタ名、画像、および打撃結果、現在投球している投手キャラクタのキャラクタ名および画像、ボールカウントおよびアウトカウントを示す画像、現在のイニングを示す画像、各塁の走者の有無を示す画像などを含んでいてもよい。
対戦進行部115は、オート進行モードで対戦を進行させるのに伴い、図示のスコアボード851および得点表示852を更新する。
具体的には、対戦進行部115は、ユーザの操作するチームが守備側である場合、現在投球している投手キャラクタの能力値に基づき、投球結果D1を生成する。一例として、対戦進行部115は、現在投球している自チームの投手キャラクタの能力値を入力として、ゲームプログラム131に基づき、投手キャラクタに投球させる球種、球速、およびコース(内角高め、低めなど)を決定し、これらを含む投球結果D1を出力する。そして、対戦進行部115は、該投球結果D1を、サーバ200へ送信する。なお、日本代表チームの動作を、サーバ200ではなくユーザ端末100が決定する場合、すなわち、ユーザ端末100が単独でサブ対戦ゲームを進行させる場合には、対戦進行部115は、投球結果D1をサーバ200に送信することを省略する。
対戦進行部115は、サーバ200から、投球結果D1の送信に対する応答として、打撃結果D2を受信する。対戦支援部211は、投球結果D1および日本代表チームの現在打席に立っている打者キャラクタの能力値を入力として、ゲームプログラム131に基づき、打者キャラクタが振ったバットがボールに当たったか否かと、当たった場合には、バットがボールに対して打撃を与えたときのバットとボールとの位置関係とを決定し、これらを含む打撃結果D2を出力する。ユーザ端末100が単独でサブ対戦ゲームを進行させる場合には、対戦支援部211に代えて対戦進行部115が打撃結果D2を生成する。
対戦進行部115は、打撃結果D2に応じて対戦を進行させる。具体的には、対戦進行部115は、投球結果D1と、打撃結果D2とに基づいて、対戦会場としての球場を模して定義された仮想空間についての計算を実行し、対戦を進行させる。仮想空間についての計算には、例えば、投球されたボールの移動経路、振られたバットの位置、および、打撃後のボールの飛翔経路などを計算する処理、および、バットがボールに当たったか否かを判定する処理などが含まれる。さらに、フィールドに配置されている野手キャラクタの能力値と、走塁する走者キャラクタの能力値(例えば、足の速さを示す走力)とに基づいて、野手キャラクタの動き、走者キャラクタの動き、および、ボールの位置を計算して、フィールドプレイを再現する処理なども、仮想空間についての計算に含まれる。対戦を進行させた結果、得点が入った場合、対戦進行部115は、スコアボード851および得点表示852を更新する。また、対戦進行部115は、打撃結果D2がヒットあるいはエラーである場合、または、スリーアウトとなった場合、スコアボード851を更新する。
一方、ユーザの操作するチームが攻撃側である場合、対戦進行部115は、サーバ200から送信される投球結果D1を待機する。投球結果D1を受信すると、対戦進行部115は、投球結果D1と、現在打席に立っている打者キャラクタとを入力して、ゲームプログラム131に基づき、打撃結果D2を出力する。一例として、対戦進行部115は、投球結果D1が示す球種、球速、およびコースに対する、打者キャラクタの得意不得意を示す能力値、並びに、打者キャラクタの打撃に関する能力値に基づき、打撃結果D2を生成する。対戦進行部115は、該打撃結果D2を、サーバ200へ送信する。また、対戦進行部115は、打撃結果D2に応じて対戦を進行させる。なお、打撃に関する能力値とは、例えば、ボールをバットに当てる巧さ(命中力)や、ボールを遠くに飛ばす力(打撃力)などである。なお、ユーザ端末100が単独でサブ対戦ゲームを進行させる場合には、対戦進行部115は、日本代表チームの投球結果D1を、サーバ200から受信することなく自ら生成する。
対戦進行部115は、以上の処理を、オート進行モードが終了するまで、フェーズごとに繰り返すことで、対戦を進行させる。
図27に示すオート進行画面850は、対戦の局面が所定の条件を満たしたときに表示されるオート進行画面の一例である。図示のオート進行画面850は、さらに、対戦の局面の概要を示す概要表示857、対戦の局面の詳細を示す詳細表示858、および、オート進行モードからマニュアル進行モードへと切り替わることを示す変更表示859を含む。詳細表示858は、一例として、アウトカウント、走者の有無および走者がいる塁、並びに、現在の打者キャラクタの名前を含む。
図示の例において、所定の条件は、概要表示857が示すように、ユーザが操作するチームが得点するチャンスとなったことである。得点するチャンスとは、例えば、ユーザが操作するチームが攻撃側である場合に、詳細表示858が示すように、得点圏(二塁または三塁の少なくとも一方)に走者がいることである。対戦進行部115は、図27に示すオート進行画面850を表示部152に表示させた後、表示部152に表示させるゲーム画面をオート進行画面850から、マニュアル進行画面に切り替える。マニュアル進行画面は、既に示したとおり、自チームの攻撃回であれば、図16に示す打撃画面750であり、自チームの守備回であれば、図13〜図15に示す投球画面700である。
図28および図29は、対戦の局面が所定の条件を満たしたときに表示されるオート進行画面の他の例を示す図である。図28の例において、所定の条件は、概要表示860が示すように、ユーザが操作するチームがピンチ、すなわち失点する可能性がある状況となったことである。失点する可能性がある状況とは、例えば、ユーザが操作するチームが守備側である場合に、詳細表示858が示すように、得点圏に走者がいることである。
また、図29の例において、所定の条件は、概要表示861が示すように、対戦における、自チームの最後の打席が開始されることである。換言すれば、所定の条件は、最後の攻撃回において、詳細表示862が示すように、ツーアウトとなってから次の打席が開始されることである。なお、所定の条件は、図27〜図29に示す局面に限定されない。例えば、図示しないが、所定の条件は、対戦における、相手チーム最後の打席が開始されることであってもよい。換言すれば、所定の条件は、最後の守備回において、ツーアウトをとった後、相手チームの次の打席が開始されることである。
また、別の実施形態では、対戦進行部115は、マニュアル進行モードに切り替えるフェーズの上限を予め定めていてもよい。この場合、1度の対戦において、上述の所定の条件を満たす局面が何度訪れても、マニュアル進行モードにてユーザがプレイするフェーズ数は、予め定められた上限数で固定される。これにより、サブ対戦ゲームの操作に係る負荷が、進行状況に応じて増加することがなくなる。結果として、気分転換のために気軽に取り組めるという、サブ対戦ゲームの存在意義が損なわれることを回避できる。
(第2のカード獲得処理における画面例)
図3に示すとおり、サブ対戦ゲームが終了すると、次に、ゲームシステム1は、第2のカード獲得処理を実行する。具体的には、まずは、ゲームシステム1は、ユーザがサブ対戦ゲームをプレイしたことに対する報酬を該ユーザに付与する。本実施形態では、サブ対戦ゲームの報酬は、キャラクタのカードと交換することが可能な交換ポイントを少なくとも含む。
図30は、図3のステップS7に示される第2のカード獲得処理が実行されるときに、ユーザ端末100の表示部152において表示されるゲーム画面の一例を示す図である。具体的には、図30に示すゲーム画面は、ユーザに獲得させた報酬、具体的には、交換ポイントをユーザに通知するための報酬通知画面870の一例である。
報酬通知画面870は、少なくとも、獲得ポイント合計871を含む。獲得ポイント合計871は、サブ対戦ゲームにおける1度の対戦で、ユーザが獲得した交換ポイントの合計を示す。
さらに、報酬通知画面870は、獲得ポイント合計871の内訳を含んでいてもよい。本実施形態では、一例として、ユーザに付与される変換ポイントは、日本代表チームとの対戦の勝敗に伴って決定される勝敗加点、マニュアル進行モードにおけるユーザの良好なプレイ結果に伴うプレイ加点、および、第2デッキ(例えば、自球団優先デッキ)に基づく自チームにて勝利したことに伴うデッキ加点の合計で決まる。したがって、図30に示す例では、報酬通知画面870は、勝敗加点872、プレイ加点873、および、デッキ加点874を含んでいてもよい。
さらに、報酬通知画面870は、あと何ポイント獲得すれば、キャラクタのカードを交換することが可能であるのかを示す目標ポイントを示したメッセージ875を含んでいてもよい。
さらに、報酬通知画面870は、誘導ボタン876を含んでいてもよい。誘導ボタン876は、ユーザをポイント交換所に誘導するためのUIである。ポイント交換所とは、交換ポイントと交換可能なアイテムの一覧と、ユーザからの交換の指示を受け付けるためのUIとを含むポイント交換画面(図示せず)のことである。具体的には、誘導ボタン876がタップ操作されると、カード取得部116は、表示部152に表示させる画面を、報酬通知画面870からポイント交換画面へ切り替える。ユーザは、ポイント交換画面を操作することにより、付与された交換ポイントと引き換えに、キャラクタのカードを含む各種のアイテムを獲得することができる。
(交換ポイントについて)
ユーザ端末100の対戦進行部115またはサーバ200の対戦支援部211は、ユーザによってプレイされたサブ対戦ゲームの進行状況に応じて、該ユーザに獲得させる交換ポイントを、以下のとおり決定する。以下では、対戦支援部211が報酬の算定を行うものとして説明するが、同様の処理を対戦進行部115に実行させてもよい。
まず、対戦支援部211は、サブ対戦ゲームにおいて実施された対戦に係る成績を決定する。具体的には、対戦支援部211は、成績として、対戦全体におけるユーザのチームの活躍度を評価した対戦成績と、ユーザのプレイ内容を評価したプレイ成績とを決定する。対戦成績は、1つの試合(対戦)において自チームが達成した記録である。対戦成績は、例えば、対戦の勝敗、得点、自チームの投手キャラクタの奪三振数および防御率、並びに、自チームの打者キャラクタの安打数および本塁打数などの項目のすべてまたは一部を含んでいてもよい。
プレイ成績は、試合の中で、ユーザがマニュアル進行モードでプレイした期間(フェーズ)において、ユーザが操作したキャラクタに達成させた記録、または、該記録に基づく評価である。つまりユーザがマニュアル進行モードで投球操作または打撃操作した結果、キャラクタがそのフェーズにおいてどのような結果を残したのかに応じて決定される。具体的には、攻撃回のある1つの局面において、ユーザがプレイした結果、得点が入ったか否かに応じて、対戦支援部211は、ユーザの上述のプレイに対して、「良」または「不良」評価を下す。あるいは、対戦支援部211は、守備回のある1つの局面において、ユーザのプレイにより、相手チームの得点を阻むことができれば「良」、得点を許してしまったら「不良」の評価を下す。さらに、対戦支援部211は、ユーザの投手キャラクタが被安打および四球なしであることを「良」の評価を下す条件に加えてもよい。
対戦支援部211は、ステップS7では、サブ対戦ゲームの成績が良いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する第2報酬をユーザに付与することが好ましい。
例えば、対戦支援部211は、少なくとも、上述のようにして決定した成績に基づいて、ユーザに付与する交換ポイントを算定する。より具体的には、対戦支援部211は、サブ対戦ゲームにおいてユーザが収めた対戦成績およびプレイ成績が良いほど、多くの交換ポイントをユーザに付与する。なお、対戦支援部211は、成績以外にも、相手チームである日本代表チームの等級、および、ユーザのチームのデッキ種別を加味して交換ポイントを算定してもよい。
本実施形態では、一例として、対戦支援部211は、対戦成績と相手チームの等級とに基づいて、勝敗加点872を決定する。具体的には、対戦支援部211は、図23に示す、日本代表チームの等級ごと、かつ、勝敗別に定めされている交換ポイントのテーブルを参照して、勝敗加点872を決定する。例えば、対戦支援部211は、ユーザのチームが、日本代表チーム「超級」に勝利した場合には、図23に示すテーブルにしたがい、勝敗加点872を「2500ポイント」と決定する。
本実施形態では、一例として、対戦支援部211は、プレイ成績に基づいて、プレイ加点873を決定する。例えば、対戦支援部211は、「良」の評価の数×70ポイントをプレイ加点873としてもよい。例えば、ユーザが、1度の対戦において、4回のマニュアル進行モードでのプレイ機会のうち、3回について「良」の評価を得た場合には、対戦支援部211は、「3×70=210ポイント」をプレイ加点873と決定する。
本実施形態では、一例として、対戦支援部211は、ユーザが用いたデッキの種類に基づいて、デッキ加点874を決定する。
上述したとおり、記憶部120には、ゲーム情報132として、ユーザの自チームの編成がそれぞれ異なる第1デッキと第2デッキとが記憶されている。本野球ゲームでは、一例として、ユーザは、キャラクタ優先デッキである第1デッキと、自球団優先デッキである第2デッキとの2種類のデッキを使い分けることができる。上述したとおり、自球団優先デッキ(第2デッキ)は、ユーザが指定した球団(属性)と同じ球団に属する(同じ属性を有する)1以上のキャラクタを含む場合に、対戦において有利な効果を発動させる性質を有する。
対戦支援部211は、自球団優先デッキに基づく自チームで、日本代表チーム(相手チーム)と対戦した場合に、キャラクタ優先デッキに基づく自チームで対戦した場合よりも、ゲーム上の価値が高いこと、および、量が多いことの少なくともいずれか一方に該当する前記報酬を付与してもよい。
例えば、対戦支援部211は、ユーザが、キャラクタ優先デッキ(第1デッキ)で日本代表チームに勝利しても加点されないところ、自球団優先デッキで勝利した場合には、一律、所定ポイント(例えば、500ポイント)のデッキ加点874をユーザに付与する交換ポイントの合計に加えてもよい。
最後に、対戦支援部211は、上述のように決定した勝敗加点872、プレイ加点873およびデッキ加点874を合計して、ユーザに獲得させる交換ポイントの合計(図30に示す獲得ポイント合計871)を算定する。対戦支援部211は、算定した獲得ポイント合計871を、ユーザ端末100の対戦進行部115に対して送信する。対戦支援部211は、獲得ポイント合計871を、ユーザに紐付けて管理することにより、サブ対戦ゲームがプレイされたことの報酬である獲得ポイント合計871をユーザに獲得させる。
(処理の流れ)
図31は、ゲームシステム1がゲームプログラム131に基づいて実行するサブ対戦ゲームおよび第2のカード獲得処理の流れを示すフローチャートである。以下で、ユーザ端末100が実行するものとして説明した処理は、サーバ200が実行してもよいし、反対に、サーバ200が実行するものとして説明した処理は、ユーザ端末100が実行してもよい。例えば、ユーザ端末100が単独でサブ対戦ゲームを実行する場合には、ステップS401、S402、および、S407は省略され、ステップS408〜S410は、ユーザ端末100によって実行される。図31に示す一連の処理は、図3に示すステップS6およびS7の処理に対応している。図3に示すステップS4およびS5において、サブ対戦ゲームを実行することが決定された場合、ゲームシステム1は、図31に示す処理を開始する。
ステップS401にて、対戦進行部115は、サブ対戦ゲームの進行を支援するようサーバ200に要求する。具体的には、対戦進行部115は、対戦を進行させるために必要な各種情報の提供をサーバ200に要求する。
ステップS402にて、対戦支援部211は、上述の要求に対する応答として、ユーザ端末100にて対戦が進行されるように、対戦進行部115が実行する対戦の進行を支援する。具体的には、対戦支援部211は、日本代表チームのデッキ情報、日本代表チームの投手キャラクタの投球動作を決定するための投球結果D1、および、日本代表チームの打者キャラクタの打撃動作を決定するための打撃結果D2を対戦進行部115に供給する。
ステップS403において、対戦が終了しないうちは、すなわち、対戦の進行状況が9回裏でスリーアウトの局面に到達しないうちは、対戦支援部211は、ステップS403のNOからステップS402に戻り、対戦の支援を継続する。
ステップS404において、対戦進行部115は、対戦支援部211と通信し、対戦の進行を開始する。このとき、対戦進行部115は、オート進行モードで対戦を進行させる。ここで、対戦進行部115は、例えば、図26に示すオート進行画面850を表示部152に表示させる。オート進行画面が表示されることにより、各ユーザは、対戦の進行状況を認識することができる。また、マニュアル進行モードに切り替わったときに、どのようにプレイすべきかを容易に決定することができる。対戦が進行するにしたがって、対戦進行部115は、オート進行画面850を更新する。
ステップS405において、対戦の局面が所定の条件を満たす場合、対戦進行部115は、ステップS405のYESからステップS406へ進む。一方、対戦の局面が所定の条件を満たさないうちは、対戦進行部115は、ステップS405のNOからステップS404に戻り、オート進行モードでの対戦の進行を継続する。
ステップS406において、対戦進行部115は、オート進行モードからマニュアル進行モードに切り替えて、対戦を進行させる。ここで、対戦進行部115は、例えば、図13〜図15に示す投球画面700、または、図16に示す打撃画面750を表示部152に表示させる。投球画面700および打撃画面750は、ともに、マニュアル進行モードにおいて、キャラクタの動作を決定するためのユーザの操作を受け付けるための画面として機能する。ユーザの操作とは、例えば、投球操作および打撃操作である。
ステップS407において、対戦進行部115は、上述のマニュアル進行モードにおけるユーザのプレイを評価し、その評価結果「良」または「不良」を、表示部152に表示させてもよい。
ステップS408において、対戦が終了しないうちは、対戦進行部115は、ステップS408のNOからステップS404に戻り、再び、オード進行モードに切り替えて、次の打席から対戦を進行させる。
ステップS403およびステップS408のそれぞれにおいて、例えば、9回裏でスリーアウトの局面に到達するなどして全イニングの進行が完了した場合、対戦が終了する。この場合、対戦支援部211は、ステップS403のYESからステップS409へ進む。一方、対戦進行部115は、ステップS408のYESから後述するステップS412へ進む。なお、別の実施形態では、対戦進行部115は、ステップS408のYESから、後述するステップS409〜S411に進み、その後、ステップS412へ進んでもよい。
ステップS409では、対戦支援部211は、成績を決定する。一例として、対戦支援部211は、サブ対戦ゲームが実行されている間に記憶部220に記録されていたゲーム情報132から勝敗、得点、奪三振数、安打数、および、本塁打数などを読み出して対戦成績を決定する。また、対戦支援部211は、マニュアル進行モードの期間におけるユーザのプレイに対する評価を読み出してプレイ成績を決定する。
ステップS410では、対戦支援部211は、決定した対戦成績およびプレイ成績に基づいて、サブ対戦ゲームをプレイしたユーザに付与する報酬を算定する。本実施形態では、一例として、対戦をプレイしたことの報酬として、交換ポイントがユーザに付与される。例えば、対戦支援部211は、勝敗加点872、プレイ加点873、および、デッキ加点874を決定し、それぞれを合計することにより、ユーザに付与する交換ポイントを算定する。
ステップS411では、対戦支援部211は、算定した報酬を、ユーザに付与する。本実施形態では、一例として、算定した交換ポイントを、上述のユーザのユーザ識別情報に関連付けて、ゲーム情報132として保存する。具体的には、対戦支援部211は、対戦前に累積された交換ポイントに対して、今回の対戦の報酬としての交換ポイントを加算して、ユーザのゲーム情報132を更新する。これにより、ユーザに、上述の報酬を獲得させることができる。対戦支援部211は、ユーザに付与した報酬の内容を、ユーザ端末100に通知してもよい。
ステップS412では、ユーザ端末100の対戦進行部115は、上述の通知を受信すると、例えば、図30に示す報酬通知画面870を生成し、表示部152に表示させてもよい。
ステップS413では、対戦進行部115は、対戦支援部211からの報酬に係る通知に基づいて、記憶部120のゲーム情報132として記憶されている、ユーザが保有する交換ポイントの累積を更新し、ユーザに報酬を獲得させる。
これにより、カード取得部116は、累積された交換ポイントと引き換えに、キャラクタのカードをユーザに獲得させるための処理を実行することが可能となる。具体的には、カード取得部116は、図示しないポイント交換画面を表示させ、交換ポイントとアイテム、とりわけ、キャラクタのカードとの交換指示をユーザから受け付ける。例えば、操作受付部111は、ポイント交換画面を介して、交換ポイントをキャラクタのカードと交換する旨の指示をユーザから受け付ける。この場合、カード取得部116は、ユーザに指定されたキャラクタのカードに設定されている交換ポイントを、上述の交換ポイントの累積から減算し、該カードをユーザに獲得させるように、サーバ200のカード提供部212に要求する。カード提供部212は、交換ポイントと引き換えに、該カードをユーザに獲得させる。
以上の構成および方法によれば、ユーザのレーティングおよび直前のメイン対戦ゲームにおける勝敗に基づいて決定された所定の確率にて、メイン対戦ゲームの合間に気軽に取り組めるサブ対戦ゲームが実行される。そして、サブ対戦ゲームがプレイされたことの報酬として、キャラクタのカードと交換可能な交換ポイントがユーザに付与される。これにより、メイン対戦ゲームをプレイするのとは別に、キャラクタのカードを獲得する方法をユーザに提供できる。結果として、ゲームをプレイする意欲をユーザが損なうことを回避することができる。
〔ソフトウェアによる実現例〕
制御部210の制御ブロック(特に、対戦支援部211およびカード提供部212)、ならびに、制御部110の制御ブロック(特に、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、対戦進行部115およびカード取得部116)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。
(項目1) ゲームプログラム(131)について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ(10、20)、メモリ(11、21)および操作部(入力部151など)を備えるコンピュータ(ユーザ端末100およびサーバ200の少なくとも一方)により実行される。ゲームプログラムは、プロセッサに、ユーザが所有する1以上のキャラクタで構成された自チームを、マッチングされた相手チームと対戦させる第1対戦ゲーム(メイン対戦ゲーム)を進行させるステップ(S2)と、第1対戦ゲームが終了した後、所定の確率にて、自チームを、ゲームプログラムにしたがって動作するキャラクタで構成された相手チームと対戦させる第2対戦ゲーム(サブ対戦ゲーム)を進行させるステップ(S6)と、ユーザにより第2対戦ゲームがプレイされた場合に、該第2対戦ゲームの成績に応じた報酬(第2報酬、交換ポイント)を該ユーザに付与するステップ(S7)とを実行させる。これにより、緊張および興奮が高まる対人対戦とは別に、気軽に取り組めるモードを提供することが可能となる。結果として、ゲームの興趣性を向上させるという効果を奏する。
(項目2) (項目1)において、ゲームプログラムは、プロセッサに、第2対戦ゲームの実行を制御するステップ(S4、S5)を実行させ、制御するステップは、抽選の実施により、第2対戦ゲームの実行可否を決定するとともに、該第2対戦ゲームにおいて、自チームと対戦させる相手チームを、強さが異なる複数のチームの中から決定し、報酬を付与するステップは、自チームが対戦する相手チームが強いほど、ゲーム上の価値がより高いこと、および、量がより多いことの少なくともいずれか一方に該当する報酬を付与してもよい。これにより、第2対戦ゲームにおいて強い相手チームと対戦する動機付けをユーザに与えることができる。
(項目3) (項目2)において、制御するステップは、抽選において、自チームが第1対戦ゲームにおける対戦に勝利にした場合に、敗北した場合よりも高い確率で、より強いチームを相手チームとして当選させてもよい。これにより、第1対戦ゲームの成績が良いほど、第2対戦ゲームにおいて良い報酬を得ることが期待できるため、第1対戦ゲームをプレイする動機付けをユーザに与え、その習熟を促すことができる。
(項目4) (項目2)または(項目3)において、第1対戦ゲームを進行させるステップは、ユーザの対戦における強さを示す評価値(レーティング)を、第1対戦ゲームの勝敗に応じて増減させ、制御するステップは、抽選において、評価値が示すユーザの対戦における強さが強いほど、強いチームを、より高い確率で相手チームとして当選させてもよい。これにより、評価値が高いほど、第2対戦ゲームにおいて良い報酬を得ることが期待できるため、第1対戦ゲームをプレイする動機付けをユーザに与え、その習熟を促すことができる。
(項目5) (項目1)から(項目4)までのいずれか1項目において、第1対戦ゲームを進行させるステップは、自チームと、他のユーザが所有する1以上のキャラクタで構成された相手チームとの対戦を、他のユーザが操作する他のコンピュータとの間で進行状況を同期させて進行させる一方、第2対戦ゲームを進行させるステップは、ゲームプログラムにしたがって動作するキャラクタで構成された相手チームとの対戦を、他のコンピュータとの同期を考慮することなく進行させてもよい。
(項目6) (項目5)において、第1対戦ゲームおよび第2対戦ゲームは、複数のフェーズで区切られており、各フェーズは、キャラクタの動作を決定するためにユーザが実施する操作の影響を受けて、ゲームプログラムにしたがってキャラクタを動作させるマニュアル進行モード、または、ユーザが実施する操作の影響を受けずに、ゲームプログラムにしたがってキャラクタを動作させるオート進行モードで進行するものであり、第1対戦ゲームを進行させるステップは、ユーザによって、マニュアル進行モードで進行させることが指定された各フェーズを、マニュアル進行モードにて進行させる一方、第2対戦ゲームを進行させるステップは、所定の条件を満たすフェーズを除き、各フェーズを、オート進行モードにて進行させてもよい。
(項目7) (項目1)から(項目6)までのいずれか1項目において、報酬を付与するステップは、キャラクタ、または、該キャラクタと交換可能な価値を、報酬としてユーザに付与してもよい。これにより、第2対戦ゲームによって、ユーザに対して、キャラクタを獲得する喜びを与えることができる。結果として、ゲームの興趣性を向上させるという効果を奏する。
(項目8) (項目1)から(項目7)までのいずれか1項目において、メモリには、自チームの編成がそれぞれ異なる第1デッキ(キャラクタ優先デッキ)と第2デッキ(自球団優先デッキ)とが記憶されており、第2デッキは、ユーザが指定した属性(球団)と同じ属性を有する(同じ球団に属する)1以上のキャラクタを含む場合に、対戦において有利な効果を発動させる性質を有し、報酬を付与するステップは、第2デッキに基づく自チームで相手チームと対戦した場合に、第1デッキに基づく自チームで対戦した場合よりも、ゲーム上の価値が高いこと、および、量が多いことの少なくともいずれか一方に該当する報酬を付与してもよい。これにより、ユーザを、第1デッキだけでなく、第2デッキを使って対戦するように促すことができる。また、ユーザは、第2デッキを強化するために、自身が指定した属性と同じ属性を有するキャラクタを収集することに楽しみを見出すことができる。
(項目9) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ、メモリおよび操作部を備えるコンピュータにより実行される。該方法は、プロセッサが(項目1)に記載の各ステップを実行する方法である。(項目9)に係る方法は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目10) 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、(項目1)に係るゲームプログラムを記憶する記憶部(120、220)と、該ゲームプログラムを実行することにより、情報処理装置(ユーザ端末100、サーバ200)の動作を制御する制御部(110、210)とを備える。(項目10)に係る情報処理装置は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。