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

Abstract

【課題】１回の対戦にかかる時間を短くするとともに、短時間でもユーザが満足する対戦を提供する。
【解決手段】ゲームプログラム（１３１）は、プロセッサ（２０）に、マッチングされた対戦相手との対戦を、ユーザおよび対戦相手のユーザの操作によらずに進行する第１モードで進行させるステップ（Ｓ１０３）と、第１モードで進行している対戦の状況が所定の条件を満たす状況となった場合、対戦を、ユーザおよび対戦相手のユーザの操作に基づいて進行する第２モードに変更するステップ（Ｓ１０６）と、第１モードが第２モードに変更された場合、ユーザの操作を受け付けるための操作画面を表示部に表示させるステップ（Ｓ１０７）と、を実行させる。
【選択図】図４

Description

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

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

このようなゲームは、複数のユーザがキャラクタ同士を対戦させるいわゆる対戦ゲームとして提供され得る。より具体的には、対戦ゲームには、それぞれのユーザの端末間で情報をやり取りして対戦を進行させる通信対戦ゲームがある。

このような通信対戦ゲームは、少なくとも二人のユーザを対戦終了までゲームに向かわせるものであるため、１回の対戦にかかる時間を短くすることが多く行われている。非特許文献１には、試合に出場するメンバーをユーザが決定し、試合自体は完全にオートで進行する野球ゲームが開示されている。また、試合はユーザがキャラクタを操作することにより進行するが、イニング数を実際の野球のイニング数より少なくすることで、１回の対戦にかかる時間を短くした野球ゲームもある。

ファミ通Ａｐｐ、"〔ファミ通×コロプラ〕第11回『プロ野球PRIDE』2013年度版でさらに進化"、［online］、平成２５年５月３１日、［平成２９年１１月２１日検索］、インターネット＜https://app.famitsu.com/20130531_150988/＞

しかしながら、通信対戦ゲームにおいて、１回の対戦にかかる時間を短くしすぎると、すぐに対戦が終わってしまい、ユーザの満足感が低下するおそれがある。

本開示の一態様は、１回の対戦にかかる時間を短くしつつ、ユーザが満足する対戦を提供することを目的とする。

本開示に係るゲームプログラムは、プロセッサ、メモリ、操作部および表示部を備えるコンピュータにおいて実行される。ゲームプログラムに基づくゲームは、一方のコンピュータを操作するユーザと、他方のコンピュータを操作する対戦相手のユーザとを、各コンピュータ間の通信を介して対戦させる対戦ゲームである。対戦ゲームにおいて、各ユーザには、対戦の結果に基づいて増減される評価値が付与され、評価値に基づいて対戦相手とのマッチングが実行される。ゲームプログラムは、プロセッサに、マッチングされた対戦相手との対戦を、ユーザおよび対戦相手のユーザの操作によらずに進行する第１モードで進行させるステップと、第１モードで進行している対戦の状況が所定の条件を満たす状況となった場合、対戦を、ユーザおよび対戦相手のユーザの操作に基づいて進行する第２モードに変更するステップと、第１モードが第２モードに変更された場合、ユーザの操作を受け付けるための操作画面を表示部に表示させるステップと、を実行させる。

１回の対戦にかかる時間を短くするとともに、短時間でもユーザが満足する対戦を提供することができるという効果を奏する。

ゲームシステムのハードウェア構成を示す図である。 ユーザ端末およびサーバの機能的構成を示すブロック図である。 ユーザ情報のデータ構造の一例を示す図である。 本実施形態に係るゲームプログラムに基づいて、ゲームシステムにおいて実行される処理の流れを示すフローチャートである。 ユーザ端末の制御部によって生成される、野球ゲームのゲーム画面の一例である。 ユーザ端末の制御部によって生成される、野球ゲームのゲーム画面の一例である。 ユーザ端末の制御部によって生成される、野球ゲームのゲーム画面の一例である。 ユーザ端末の制御部によって生成される、野球ゲームのゲーム画面の一例である。 ユーザ端末の制御部によって生成される、野球ゲームのゲーム画面の一例である。 ユーザ端末の制御部によって生成される、野球ゲームのゲーム画面の一例である。 ユーザ端末の制御部によって生成される、野球ゲームのゲーム画面の一例である。 デッキ情報のデータ構造の一例を示す図である。

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

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

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

ユーザ端末１００（コンピュータ、情報処理装置）は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末１００は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末１００は図示の通り、プロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５（表示部）と、カメラ１７と、測距センサ１８とを備える。ユーザ端末１００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。また、図１に示すように、ユーザ端末１００は、１つ以上のコントローラ１０２０と通信可能に構成されることとしてもよい。コントローラ１０２０は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信規格に従って、ユーザ端末１００と通信を確立する。コントローラ１０２０は、１つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末１００へ送信する。また、コントローラ１０２０は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末１００へ送信する。

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

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

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

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

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

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

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

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

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

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

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

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

ゲームシステム１は、一例として、通信対人対戦ゲームとして、野球の試合を進行させる、通信対人対戦型の野球ゲーム（以下、本ゲーム、本野球ゲームと称することがある）を実行する。具体的には、ゲームシステム１が実行する野球ゲームでは、サーバ２００（情報処理装置）を介して通信する第１のユーザ端末１００と第２のユーザ端末１００とによって、それぞれのチームが操作される。一例として、ゲームシステム１は、第１のユーザ端末１００のユーザが操作する１以上のキャラクタが属する自チームと、第２のユーザ端末１００のユーザ（相手ユーザ）が操作する１以上のキャラクタが属する相手チームとを対戦させる。

本野球ゲームにおいて、ユーザによって対人の対戦がプレイされることにより、プレイ内容に対する評価結果（勝敗、成績、スコアなどの対戦成績）が出力される。また、該ゲームにおいては、ユーザが対戦をプレイしたことに対して報酬が付与される。報酬の詳細については後述する。

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

本野球ゲームにおける対戦は、各ユーザの操作によらずに進行するオート進行モード（第１モード）、または、各ユーザの操作に基づいて進行するマニュアル進行モード（第2モード）のいずれかで進行する。具体的には、本野球ゲームにおける対戦は、該対戦の状況が所定の条件を満たす状況となった場合、自動的に、オート進行モードからマニュアル進行モードに変更される。一方、本野球ゲームにおける対戦は、ユーザの操作によって、オート進行モードをマニュアル進行モードに変更することはできない。また、一例として、本野球ゲームにおける対戦は、オート進行モードで開始されてもよい。

また、本野球ゲームにおいて、ユーザは、自身でキャラクタを制御することを希望しない場合に、ユーザ端末１００を操作して、対戦におけるモードを、マニュアル進行モードから、上記オート進行モードとは異なる第２のオート進行モードに変更することが可能であってもよい。この例の場合、ユーザは、ユーザ端末１００を操作して、第２のオート進行モードからマニュアルモードに変更することが可能であることが望ましい。

マニュアル進行モードの場合、投球側ユーザは、投球側ユーザ端末１００Ａを用いて、投手キャラクタによる投球を操作し、攻撃側ユーザは、打撃側ユーザ端末１００Ｂを用いて、打者キャラクタによる打撃を操作する。

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

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

一方、オート進行モード、または、第２のオート進行モードの場合、ユーザ端末１００は、ゲームプログラムにしたがって、進行している対戦に関わる各種情報に基づいてキャラクタの動作結果（投球結果または打撃結果）を決定する。そして、決定した動作結果をサーバ２００へ送信する。

＜各装置のハードウェア構成要素＞
プロセッサ１０は、ユーザ端末１００全体の動作を制御する。プロセッサ２０は、サーバ２００全体の動作を制御する。プロセッサ１０および２０は、ＣＰＵ（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 (10)

1. ゲームプログラムであって、
   前記ゲームプログラムは、プロセッサ、メモリ、操作部および表示部を備えるコンピュータにより実行されるものであり、
   前記ゲームプログラムに基づくゲームは、一方のコンピュータを操作するユーザと、他方のコンピュータを操作する対戦相手のユーザとを、前記各コンピュータ間の通信を介して対戦させる対戦ゲームであり、該対戦ゲームにおいて、各ユーザには、対戦の結果に基づいて増減される評価値が付与され、該評価値に基づいて対戦相手とのマッチングが実行され、
   前記ゲームプログラムは、前記プロセッサに、
   マッチングされた前記対戦相手との前記対戦を、前記ユーザおよび前記対戦相手のユーザの操作によらずに進行する第１モードで進行させるステップと、
   前記第１モードで進行している前記対戦の状況が所定の条件を満たす状況となった場合、前記対戦を、前記ユーザおよび前記対戦相手のユーザの操作に基づいて進行する第２モードに変更するステップと、
   前記第１モードが前記第２モードに変更された場合、前記ユーザの操作を受け付けるための操作画面を前記表示部に表示させるステップと、を実行させ、
   前記対戦は、１以上のオブジェクトによって編成された各ユーザのデッキに基づいて進行するものであり、
   前記マッチングは、前記評価値に加え、ユーザの前記デッキの強さの指標に基づいて実行され、
   各オブジェクトには、前記ゲームの進行上の総合的な強さを示す総合パラメータがそれぞれ設定されており、前記デッキの強さの指標は、前記デッキに組み込まれている各オブジェクトの前記総合パラメータに基づいて算出されたデッキ総合パラメータであり、
   前記ゲームプログラムは、前記プロセッサに、
   前記対戦の前に、前記ユーザの前記デッキ総合パラメータと、前記対戦相手のユーザの前記デッキ総合パラメータとを比較するステップと、
   前記ユーザおよび前記対戦相手のユーザのうち、前記デッキ総合パラメータが低い側の前記デッキに組み込まれている前記オブジェクトに設定されている、前記対戦において発揮される能力に係るパラメータを、前記対戦が進行する期間において減少させるステップと、をさらに実行させる、ゲームプログラム。
2. 前記ゲームは、前記ユーザが操作する１以上のキャラクタが属する自チームと、前記対戦相手のユーザが操作する１以上のキャラクタが属する相手チームとを対戦させる対戦ゲームであり、
   前記対戦が終了した後、前記第２モードにおける前記ユーザの操作に応じた前記キャラクタの動作に基づいて、前記ユーザに付与する報酬が決定される、請求項１に記載のゲームプログラム。
3. 前記ゲームは、前記ユーザが操作する１以上のキャラクタが属する自チームと、前記対戦相手のユーザが操作する１以上のキャラクタが属する相手チームとを対戦させる対戦ゲームであり、
   前記対戦が終了した後、前記第２モードにおける前記ユーザの操作に応じた前記キャラクタの動作に基づいて、前記ユーザの前記評価値が更新される、請求項１または２に記載のゲームプログラム。
4. 前記対戦は前記第１モードで開始される、請求項１から３のいずれか１項に記載のゲームプログラム。
5. 前記第１モードで進行させるステップでは、前記対戦の状況をユーザに認識させるための画面を前記表示部に表示させる、請求項１から４のいずれか１項に記載のゲームプログラム。
6. 前記対戦ゲームは、野球の試合を進行させる対戦型野球ゲームであり、
   前記所定の条件を満たす前記状況は、二塁または三塁の少なくとも一方に走者がいることである、請求項１から５のいずれか１項に記載のゲームプログラム。
7. 前記対戦ゲームは、野球の試合を進行させる対戦型野球ゲームであり、
   前記所定の条件を満たす前記状況は、最終回においてツーアウトとなることである、請求項１から６のいずれか１項に記載のゲームプログラム。
8. 前記対戦ゲームは、野球の試合を進行させる対戦型野球ゲームであり、
   前記対戦は９イニングで行われる、請求項１から７のいずれか１項に記載のゲームプログラム。
9. コンピュータがゲームプログラムを実行する方法であって、
   前記コンピュータは、プロセッサ、メモリ、操作部および表示部を備え、
   前記プロセッサが請求項１に記載の各ステップを実行する方法。
10. 情報処理装置であって、
    前記情報処理装置は、
    ゲームプログラムを記憶する記憶部と、
    該ゲームプログラムを実行することにより、前記情報処理装置の動作を制御する制御部と、
    操作部と、
    表示部と、を備え、
    前記ゲームプログラムに基づくゲームは、一方の情報処理装置を操作するユーザと、他方の情報処理装置を操作する対戦相手のユーザとを、前記各情報処理装置間の通信を介して対戦させる対戦ゲームであり、該対戦ゲームにおいて、各ユーザには、対戦の結果に基づいて増減される評価値が付与され、該評価値に基づいて対戦相手とのマッチングが実行され、
    前記制御部は、
    マッチングされた前記対戦相手との前記対戦を、前記ユーザおよび前記対戦相手のユーザの操作によらずに進行する第１モードで進行させ、
    前記第１モードで進行している前記対戦の状況が所定の条件を満たす状況となった場合、前記対戦を、前記ユーザおよび前記対戦相手のユーザの操作に基づいて進行する第２モードに変更し、
    前記第１モードが前記第２モードに変更された場合、前記ユーザの操作を受け付けるための操作画面を前記表示部に表示させ、
    前記対戦は、１以上のオブジェクトによって編成された各ユーザのデッキに基づいて進行するものであり、
    前記マッチングは、前記評価値に加え、ユーザの前記デッキの強さの指標に基づいて実行され、
    各オブジェクトには、前記ゲームの進行上の総合的な強さを示す総合パラメータがそれぞれ設定されており、前記デッキの強さの指標は、前記デッキに組み込まれている各オブジェクトの前記総合パラメータに基づいて算出されたデッキ総合パラメータであり、
    前記制御部は、さらに、
    前記対戦の前に、前記ユーザの前記デッキ総合パラメータと、前記対戦相手のユーザの前記デッキ総合パラメータとを比較し、
    前記ユーザおよび前記対戦相手のユーザのうち、前記デッキ総合パラメータが低い側の前記デッキに組み込まれている前記オブジェクトに設定されている、前記対戦において発揮される能力に係るパラメータを、前記対戦が進行する期間において減少させる、情報処理装置。

Images