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

Abstract

【課題】ユーザのゲームをプレイする意欲が減退することを回避する。【解決手段】ゲームプログラムは、プロセッサに、コンピュータに対するユーザの入力と、コンピュータとサーバとの間の通信とに基づいて、ユーザと対戦相手との対戦を進行させるステップと、対戦の進行中に通信が不可能となる第１エラーがサーバに発生したことを検出するステップ（Ｓ９０１）と、第１エラーがサーバに発生したことに応じて、対戦を無効とするステップ（Ｓ９０６）と、対戦が無効とされなかった場合、対戦の進行に応じて対戦の結果を決定するステップと、対戦が無効とされた場合、ユーザが対戦に勝利できなかったことに応じてユーザの不利益になるように更新される第１パラメータを更新しない一方、対戦の結果が決定された場合、対戦の結果に基づいて、第１パラメータを更新するステップと、を実行させる。【選択図】図９

Description

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

特許文献１には、ゲームにおける対戦の状況が不利になった場合に、敗北がランキングに反映されないようにするために故意に回線を切断するユーザを視覚化する技術が開示されている。

特開２００９−２４７４７９号公報

従来の対戦ゲームには、ユーザのゲームをプレイする意欲が減退することを回避することができる余地がある。

本開示の一態様は、ユーザのゲームをプレイする意欲が減退することを回避することができる余地がある。

本開示に係るゲームプログラムは、プロセッサを備えたコンピュータにより実行される。ゲームプログラムは、プロセッサに、コンピュータに対するユーザの入力と、コンピュータとサーバとの間の通信とに基づいて、ユーザと対戦相手との対戦を進行させるステップと、対戦の進行中に通信が不可能となる第１エラーがサーバに発生したことを検出するステップと、第１エラーがサーバに発生したことに応じて、対戦を無効とするステップと、対戦が無効とされなかった場合、対戦の進行に応じて対戦の結果を決定するステップと、対戦が無効とされた場合、ユーザが対戦に勝利できなかったことに応じてユーザの不利益になるように更新される第１パラメータを更新しない一方、対戦の結果が決定された場合、対戦の結果に基づいて、第１パラメータを更新するステップと、を実行させる。

本開示の一態様によれば、ユーザのゲームをプレイする意欲が減退することを回避するという効果を奏する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜ゲーム概要＞
ゲームシステム１によって実行されるゲーム（以下、本ゲーム）は、ユーザの操作内容（例えば、操作スピード、タイミング、およびテクニックなど）に応じて異なる結果が得られるゲームである。

本ゲームは、例えば、対戦ゲームであり、該対戦ゲームは、ユーザの操作内容に応じて、試合運び、スコア、および、対戦の勝敗などが変化する。本ゲームは、一例として、複数のユーザの間で、タイム、スコア、戦績などの観点で、優位性を競わせるゲームであってもよい。ユーザは通常、競争に勝ちたいと考えてゲームをプレイする。そのため、ゲームに競争の要素を含ませ、操作内容に応じて優位性が決するようにゲームシステム１を構築することにより、ユーザに操作の習熟を促すことができる。

さらには、本対戦ゲームは、例えば、ユーザと他のユーザとの対戦により進行する対人対戦を行うゲームパートを含んでいてもよい。なお、本ゲームにおける「対戦」はマルチ対戦（所謂、ＰｖＰ（Player vs Player）戦）に限られない。例えば、ユーザが操作するプレイヤキャラクタ（以下、ＰＣ（player character））と、ノンプレイヤキャラクタ（以下、ＮＰＣ(non player character））との対戦（所謂、ＣＯＭ戦またはＣＰＵ戦）も、本対戦ゲームにおける「対戦」に含まれる。本ゲームの対戦は、一例として、スポーツゲームにおける試合であってもよい。

本実施形態に係るゲームシステム１は、一例として、ＰｖＰ戦を行う対戦型野球ゲーム（以下、本ゲーム、本野球ゲームと称する場合がある）を実行するためのシステムである。つまり、ゲームシステム１は、一方のコンピュータを操作するユーザが制御可能な１以上のキャラクタからなるチームが、他方のコンピュータを操作する対戦相手のユーザが制御可能な１以上のキャラクタからなるチームと、野球の試合を行うためのシステムである。

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

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

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

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

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

以降、ユーザがユーザ端末１００を操作して、自身でキャラクタを制御して対戦を進行させるモードをマニュアル進行モードと称し、ユーザ端末１００が、ゲームプログラムに従ってキャラクタを制御して対戦を進行させるモードをオート進行モードと称する場合がある。

また、オート進行モードは、さらに、複数のモードを含んでいてもよい。一例として、オート進行モードには、キャラクタはゲームプログラムに従って動作するが、ユーザが指示を出したり、キャラクタの交代（選手交代）を行なったりすることができる、部分オートモードと、対戦の進行に係るすべての制御をゲームプログラムに従って行う完全オートモード（第１モード）とがあってもよい。

本野球ゲームでは、チームは、１または複数のオブジェクトを、ユーザがデッキに組み入れることにより生成される。オブジェクトは、本野球ゲームにおいて、対戦の進行に何らかの作用を及ぼすデジタルコンテンツであり、１以上のオブジェクトによって編成された各ユーザのデッキの強さが、少なくとも、対戦の進行に作用する。オブジェクトは、例えば、選手などのキャラクタであり、本野球ゲームでは、選手は、一例として、カードという表示態様で表される。

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

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

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

本野球ゲームでは、パックにランクが設定されており、パックのランク別に当選確率テーブルが予め生成されていてもよい。ランク別の当選確率テーブルにおいては、パックのランクが高いほど、希少度の高いキャラクタのカードが当選する確率が高くなるように当選確率が設定されていることが好ましい。

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

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

サーバ２００は、各ユーザ端末１００と通信して、ユーザ端末１００がゲームを進行させるのを支援する機能を有する。ゲームがマルチプレイゲームである場合には、サーバ２００は、ゲームに参加する各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する機能を有していてもよい。サーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、および入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２２０として機能する。

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

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

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

対戦支援部２１１は、各ユーザ端末１００における、本ゲームの対戦の進行を支援する。具体的には、対戦支援部２１１は、各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する。さらに、対戦支援部２１１は、対戦相手のマッチング、対戦の進行状況の同期をとるための同期制御などを実行する。

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

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

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

例えば、操作受付部１１１は、（１）「接近操作」、（２）「リリース操作」、（３）「タップ操作」、（４）「ダブルタップ操作」、（５）「長押し操作（ロングタッチ操作）」、（６）「ドラッグ操作（スワイプ操作）」、（７）「ムーブ操作」、（８）「フリック操作」、その他のユーザの入力操作を判別する。操作受付部１１１が判別するユーザの入力操作は、上記に限られない。例えば、操作受付部１１１が、ユーザがタッチスクリーン１５に対して押下する圧力の大きさを検出可能な機構を有する場合、操作受付部１１１は、ユーザにより押下された圧力の大きさを判別する。

（１）「接近操作」とは、ユーザが指などをタッチスクリーン１５に接近させる操作である。タッチスクリーン１５は、ユーザの指などが接近したこと（ユーザの指などがタッチスクリーン１５に接触したことを含む）を検出し、検出したタッチスクリーン１５の座標に応じた信号を操作受付部１１１へ出力する。操作受付部１１１は、タッチスクリーン１５へのユーザの指などの接近を検出しない状態から、接近を検出したときに、状態が「タッチオン状態」になったと判別する。

（２）「リリース操作」とは、ユーザがタッチオン状態を止める操作である。操作受付部１１１は、例えば、ユーザが指などをタッチスクリーン１５に接触させている状態から、指を離す操作をしたときに、ユーザの操作を「リリース操作」と判別する。操作受付部１１１は、タッチスクリーン１５へのユーザの指などの接近を検出している状態から、接近を検出しない状態になったときに、状態が「タッチオン状態」から「タッチオフ状態」になったと判別する。

（３）「タップ操作」とは、ユーザがタッチスクリーン１５に対して指などを接近させる接近操作をした後に、接近操作をした位置でリリース操作を行うことである。操作受付部１１１は、接近操作が検出されない状態（ユーザの指などがタッチスクリーン１５から離れており、タッチスクリーン１５がユーザの指などの接近を検出していない状態）から、タッチスクリーン１５の出力に基づいて、ユーザの指などが接近したことを検出した場合に、その検出した座標を「初期タッチ位置」として保持する。操作受付部１１１は、初期タッチ位置の座標と、リリース操作をした座標とがほぼ同一である場合（接近操作が検出された座標から一定範囲内の座標においてリリース操作の座標が検出された場合）に、ユーザの操作を「タップ操作」と判別する。

（４）「ダブルタップ操作」とは、ユーザがタップ操作を一定時間内に２回行う操作である。操作受付部１１１は、例えば、ユーザの操作をタップ操作と判別してから一定時間内に、タップ操作にかかる座標で再びタップ操作を判別した場合に、ユーザの操作を「ダブルタップ操作」と判別する。

（５）「長押し操作」とは、ユーザがタッチスクリーン１５を押し続ける操作である。操作受付部１１１は、ユーザの操作を検出して接近操作を判別してから、接近操作が検出された座標において接近操作が継続している時間が一定時間を超えた場合に、ユーザの操作を「長押し操作」と判別する。「長押し操作」を、「ロングタッチ操作」と称する場合もある。

（６）「ドラッグ操作」とは、ユーザがタッチスクリーン１５に指などを接近させた接近状態を維持したまま、指をスライドさせる操作である。「ドラッグ操作」を「スライド操作」と称する場合もある。

（７）「ムーブ操作」とは、ユーザがタッチスクリーン１５において、接近操作を維持しつつ、タッチスクリーン１５に指などを接近させている位置を移動させてリリース操作を行う一連の操作をいう。「ムーブ操作」を「スワイプ操作」と称する場合もある。

（８）「フリック操作」は、ユーザがムーブ操作を予め定められた時間よりも短い時間で行う操作をいう。フリック操作は、ユーザがタッチスクリーン１５で指を弾くような操作である。

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

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

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

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

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

時間計測部１１６は、図示しないカウンタを制御して、ゲームのプレイ中に或る事象が発生してからの経過時間を計測する。一例として、時間計測部１１６は、対戦の進行中に、ユーザ端末１００とサーバ２００との間の通信が不可能となるエラー（第１エラー）が発生した場合、該エラーが発生してからの経過時間を計測する。該エラーの発生は、一例として、対戦進行部１１５が検出する。対戦進行部１１５は、例えば、ＨＴＴＰレスポンスステータスコードの「５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ」を受信したことにより、該エラーを検出してもよい。また、該エラーとは、例えば、サーバ２００における、いわゆるサーバダウンの発生である。以降、該エラーは、サーバダウンの発生であるものとして説明する。

また、時間計測部１１６は、サーバダウンが発生してから所定の時間（第１時間）が経過したか否かを判定する。

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

＜対戦前の処理＞
ユーザによる所定の操作、例えば、表示部１５２に表示されている、本ゲームのアイコンへのタップ操作が入力されると、ユーザ端末１００において本ゲームが開始される。一例として、制御部１１０は、表示部１５２にホーム画面（不図示）を表示する。ホーム画面とは、本ゲームの開始後、最初に表示される画面であり、例えば、本ゲームに含まれる各モードを開始するためのタップ操作を受け付けるＵＩを含む画面である。

図３は、ユーザ端末１００の表示部１５２に表示されるゲーム画面の一具体例を示す図である。一例として、ホーム画面に表示されている、ＰｖＰ戦を開始するためのＵＩに対しタップ操作が入力されたと操作受付部１１１が判別した場合、制御部１１０は、図３に示す対戦開始画面３１０を表示部１５２に表示させる。以降、単に「対戦」と記載する場合には、該「対戦」はＰｖＰ戦を指すものとする。

本ゲームは、対戦の開始前に、自チームの拠点となる地区（以下、拠点地区）を、複数の地区から選択するものであってもよい。複数の地区は、例えば、日本全国の４７都道府県のうち、東京を除く４６道府県のそれぞれを１地区とする４６地区と、東京を第１地区および第２地区に分けた２地区とによる、４８地区であってもよい。ユーザは、自チームが拠点とする地区を、４８地区の中から任意に選択することができる。制御部１１０は、対戦を開始するためのＵＩに対しタップ操作が入力された後、対戦開始画面３１０を表示させる前に、ユーザに拠点地区を選択させる画面を表示してもよい。

対戦開始画面３１０は、ユーザが茨城県を自チームの拠点地区としている例である。一例として、４８地区のそれぞれには、対戦会場となる球場が設定されている。球場は、野球の対戦が進行される仮想空間を定義する。対戦は、ユーザまたは相手ユーザが選択している拠点地区に設定されている球場のいずれかにおいて進行する。少なくとも一部の地区の球場の仕様は、地区ごとに特有のものであってもよい。球場の仕様は、対戦の進行に影響を与える各種パラメータで決定される。具体的には、球場の広さ、屋根の有無、屋根の高さなどである。広さのパラメータは、ホームランの出やすさなどに影響する。屋根のパラメータは、打球の飛翔経路または打撃結果などに影響する。

本実施形態では、４８地区のうち、１２地区について、実在のプロリーグ球団のフランチャイズ球場を模した球場（以下、フランチャイズ球場）が設定されていてもよい。残りの３６地区のうちのいくつかの地区について、実在の名のある球場を模した球場が設定されていてもよい。残りの地区については、仕様が共通の架空の球場が設定されていてもよい。

（マッチング）
一例として、自チームの拠点地区が選択されると、他のユーザとの対戦が可能となる。対戦開始画面３１０は、対戦開始ＵＩ３１１を含み、対戦開始ＵＩ３１１へのタップ操作が入力されたと操作受付部１１１が判別した場合、対戦進行部１１５は、対戦相手のマッチングを実行する。具体的には、対戦進行部１１５は、該タップ操作に応答して、マッチング要求をサーバ２００に送信する。マッチング要求とは、他のユーザ端末１００のユーザと対戦をプレイできるように、対戦相手となる他のユーザ端末１００を探索することをサーバ２００に対して要求するメッセージである。

サーバ２００の対戦支援部２１１は、マッチング要求に応答して、対戦相手を探索する。対戦相手のマッチング（探索）は、ユーザに付与されているレーティング（評価値）に少なくとも基づいて実行される。具体的には、対戦支援部２１１は、レーティングが近いユーザ同士をマッチングする。レーティングは、対戦結果に応じて更新される値である。したがって、レーティングを参照することにより、対戦支援部２１１は、基本的には、実力が拮抗するユーザ同士をマッチングすることができる。なお、対戦支援部２１１は、レーティングに加えて、さらに別のユーザ情報１３３に基づいて、マッチングを実行する構成であってもよい。該構成については、後に詳述する。

（レーティング）
対戦支援部２１１は、一例として、対戦の勝敗に応じて、以下のようにレーティングを増減させる。

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

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

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

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

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

再びマッチングの説明に戻る。対戦支援部２１１は、マッチングの結果をユーザ端末１００に返信する。対戦相手が見つかってマッチングが成立した場合には、対戦支援部２１１は、要求元のユーザが操作するユーザ端末１００と、対戦相手のユーザが操作するユーザ端末１００とのそれぞれにマッチング結果を配信する。マッチング結果には、対戦相手の情報が含まれている。対戦相手が見つからずにタイムアウトした場合には、対戦支援部２１１は、要求元のユーザのユーザ端末１００に、対戦相手が見つからなかった旨の通知を含むマッチング結果を送信する。

対戦支援部２１１は、レーティングに加えて、チーム（デッキ）の強さにも基づいて、マッチングを実行する構成であってもよい。

（デッキ）
デッキは、一例として、ＰｖＰ戦に参加させるチーム（以下、自チーム）を編成するためのＵＩである。ユーザは、手持ちのカード中から所望のカードをデッキに組み入れることにより、自チームを編成することができる。本野球ゲームにおけるデッキは、一例として、守備のポジション区分に基づいて、野手デッキおよび投手デッキの２種類のデッキで構成されている。また、本実施形態では、それぞれの区分のデッキを、メインとサブという概念を採用してさらに区分してもよい。本野球ゲームでは、一例として、野手デッキのメインデッキを野手スタメンデッキ、野手デッキのサブデッキを野手ベンチデッキ、投手デッキのメインデッキを投手先発デッキ、および、投手デッキのサブデッキを投手リリーフデッキと称する。

野手スタメンデッキは、投手を除く８つの守備ポジションのそれぞれに対応する枠と、指名打者に対応する枠とを有する。野手ベンチデッキは、一例として、控えの選手５人分に相当する５つの枠を有してもよい。投手先発デッキは、一例として、先発投手５人分に相当する５つの枠を有してもよい。投手リリーフデッキは、一例として、リリーフ投手６人分に相当する６つの枠を有してもよい。

一例として、ホーム画面に表示されている、デッキの編成を開始するためのＵＩに対しタップ操作が入力されたと操作受付部１１１が判別した場合、制御部１１０は、デッキ編成画面（不図示）を表示部１５２に表示させる。野手デッキを編成するデッキ編成画面と、投手デッキを編成するデッキ編成画面とは異なる画面であってもよい。この場合、ユーザは、一例として、一方のデッキ編成画面が表示された状態で、所定の操作を入力部１５１に入力することで、他方のデッキ編成画面を表示する（すなわち、２つのデッキ編成画面を切り換える）ことができる。ユーザは、デッキ編成画面が表示された状態で、手持ちの所望のカードを、それぞれの枠に紐付けるための入力操作を、入力部１５１を用いて行う。対戦進行部１１５は、上述の入力操作を、操作受付部１１１を介して受け付け、枠とカードとを対応付けて、その対応関係をデッキ情報として生成する。

（デッキ情報）
デッキ情報は、カードを配置することが可能な各枠と、カードとの対応関係を示す情報である。一例として、デッキ情報は、デッキを構成する各枠を識別するための枠識別番号と、カードを識別するためのカードＩＤとが関連付けられたデータ構造を有する。さらに、デッキ情報は、カードＩＤに関連付けて、総合パラメータ、および、希少度の各項目を含んでいてもよい。総合パラメータについては詳細を後述する。

希少度は、カードが表している選手の希少価値を等級で表したものである。一般に、ゲーム上、特に、プレイパートにおいて良好な結果をもたらす選手、すなわち、野球の試合に係る能力の高い選手には、上級の希少度が設定されている。本実施形態では、希少価値の高い等級から順に、「Ｓ」、「Ａ」、「Ｂ」、および、「Ｃ」のアルファベットにより希少度が設定される。

なお、希少度は、例えば、カードの入手困難性、または、有償入手の場合の価格などと相関があってもよい。カードの希少度が高いほど、該カードの入手困難性は高くなる。

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

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

ユーザの入力操作にしたがって、対戦進行部１１５が生成したデッキ情報が記憶部に保存されると、次に、対戦進行部１１５は、デッキ情報に基づいて、デッキメタ情報を生成する。デッキメタ情報には、少なくとも、後述のデッキ総合パラメータが含まれている。

デッキメタ情報は、一例として、デッキ総合パラメータ、平均値、および、Ｓレア枚数の各項目を含んでいる。これらの各項目は、先に生成されたデッキ情報に基づいて、対戦進行部１１５によって決定される。

デッキ総合パラメータは、デッキ内の各選手の総合パラメータに基づいて算出される値である。デッキ内の各選手の総合パラメータが高いほど、デッキ総合パラメータも高く算出される。各選手は総合パラメータが高いほど対戦に強いということができるので、デッキ総合パラメータが高いほどデッキ（チーム）が対戦において強いということができる。平均値は、デッキ内の各選手の総合パラメータの平均値である。平均値が高いほど、強い選手のカードが多くデッキに配置されていることになる。Ｓレア枚数は、カードの希少度が最高ランクである「Ｓ」のカードがデッキ内に何枚あるのかを示す値である。希少度がＳランクのカードの選手には高い能力値が設定されており、対戦を有利に進めることができる。そのようなＳランクの選手を多くデッキに配置すれば、それだけデッキを強化することができる。

以上のとおり、デッキ総合パラメータ、平均値、および、Ｓレア枚数は、デッキの強さを表す指標（以下、デッキ強度指標）として採用できる。

対戦進行部１１５は、デッキに組み入れられた各選手の総合パラメータに基づいて、デッキ総合パラメータを算出する。

例えば、対戦進行部１１５は、デッキ内の各選手の総合パラメータの合計値を算出し、得られた総合パラメータの合計値をデッキ総合パラメータとしてもよい。対戦進行部１１５は、４種類すべてのデッキ内の選手の総合パラメータを合計してデッキ総合パラメータを算出してもよいし、メインデッキ内の選手の総合パラメータだけを合計してデッキ総合パラメータを算出てもよい。メインデッキとは、例えば、野手スタメンデッキおよび、投手先発デッキである。

さらに、対戦進行部１１５は、デッキに組み入れられている選手に設定されている他のパラメータに基づいて、選手同士の相関関係を特定してもよい。そして、対戦進行部１１５は、特定した相関関係に基づいて、上述の合計値にプラスまたはマイナスの補正を行ってデッキ総合パラメータを算出してもよい。例えば、相性が良いという相関関係にある２人の選手がデッキに編成されることにより、対戦進行部１１５は、上述の合計値にさらに所定の値を加算してデッキ総合パラメータを算出してもよい（いわゆる、コンボ）。デッキ総合パラメータは、加算条件をうまくそろえることによって高騰させやすい値であり、このような加算条件をそろえることも、ゲーム、とりわけ、デッキ編成の興趣性を向上させることに貢献している。

レーティングとデッキの強さとの両方に基づいて行うマッチングは、ユーザが非熟練者である場合に実行されてもよい。非熟練者とは、対戦のプレイ回数が少ない初心者、および、プレイ回数は多くとも、対戦に係る操作に習熟できず、腕前が上達していない未熟者などが含まれる。非熟練者には、比較的低いレーティングが付与されている。一方、ユーザが熟練者である場合、マッチングは、レーティングのみに基づいて行われてもよい。熟練者は、本ゲームにおける対戦のプレイを数多くこなし、かつ、対戦に係る操作に慣れていて、腕前が上達しているユーザを指す。

非熟練者が多く集まっているユーザ層（レーティング初期値周辺のユーザの集団）には、始めたばかりの初心者と、プレイ経験は豊富だが上達しないためにレーティングの上位集団に抜け出せない未熟者とが混在している。経験豊富な未熟者は、ゲームの腕前が拙劣であるとはいえ、多くの回数のプレイをこなすことにより、多くの報酬を獲得し、強い選手を豊富に所有している可能性が高い。したがって、強いデッキを編成することが可能である。一方、ゲームを始めたての初心者は、開始当初の手持ちの選手が限られており、強いデッキを編成することが難しい。上述の事情から、デッキの強さの格差は、初心者が多く集まるレーティング初期値周辺のユーザ層において顕著である。

このような非熟練者の集団においては、レーティングにのみ基づいてマッチングが行われると、初心者と、経験豊富な未熟者とがマッチングされる可能性がある。そして、このようなマッチングにより、デッキの強さに関して、非常に大きな格差が生じる可能性が高い。

本野球ゲームのような、編成されたデッキの強さが対戦の進行に何らかの作用を及ぼすような対戦ゲームにおいては、ユーザのゲームの腕前だけでなくデッキの強さが、対戦結果を左右する重要な要素となり得る。したがって、デッキの強さの格差を引き起こす理不尽なマッチングは、対戦を行う前から、デッキの強さが劣勢のユーザのプレイ意欲を萎えさせてしまう。また、実際に対戦が進行しても、ワンサイドゲームになる可能性があり、ゲームの興趣性を著しく低下させる。

ユーザが非熟練者である場合にレーティングとデッキの強さとの両方に基づくマッチングを行うことは、このような課題を解決することができる。すなわち、デッキの格差が顕著な非熟練者においては、レーティングだけでなく、デッキの強さが近いユーザ同士がマッチングされる。結果として、理不尽なマッチングを回避して、ゲームの興趣性が損なわれることを防止することが可能となる。

具体的には、理不尽なマッチングを回避し、デッキの強さにおいて劣勢のユーザがプレイする前から意欲を損なうことが回避されるという効果を奏する。特に、本野球ゲームのように、対戦の開始前に、デッキの強さの比較結果が提示されるゲームでは、この効果は特にメリットがある。対戦が開始される直前にデッキの強さの比較結果が提示される場合、デッキの強さがほぼ互角のユーザ同士の対決では、各ユーザは、互いのデッキの強さがほぼ互角であると理解できる。そして、各ユーザは、腕前によって勝敗が決まると理解して対戦を開始することになるから、ユーザのプレイへの意欲を向上させることができる。

（対戦成績）
再び図３を参照して、対戦開始画面３１０の説明に戻る。対戦開始画面３１０は、ユーザの対戦成績を示すＵＩを含んでもよい。このユーザの対戦成績は、地区ごとに蓄積されてもよい。対戦成績は、一例として、現在連勝数（第１パラメータ）、最高連勝数、および、勝敗数などを含む。

現在連勝数は、現時点において、その地区を拠点として連続して勝利している数を示す。よって、該地区を拠点とした状態で敗戦すると０勝にリセットされる。また、該地区を拠点とした状態で引き分けた場合にも０勝にリセットされてもよい。ＵＩ３１２は、この現在連勝数を示すＵＩである。すなわち、現在連勝数は、ユーザが対戦に勝利できなかった場合にユーザの不利益になるように更新されるパラメータであると表現することもできる。

最高連勝数は、その地区においてこれまで記録された現在連勝数のうち、最多数のものを示す。よって、最高連勝数は、敗戦してもリセットされない。最新の現在連勝数が最高連勝数を超えた場合に、該最高連勝数が、最新の現在連勝数に更新される。

＜対戦中の処理＞
図４は、ゲームシステム１に含まれる各装置が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。図４に示すフローチャートにおいては、ユーザ端末１００が実行する処理を、投球側ユーザ端末１００Ａが実行する処理と、打撃側ユーザ端末１００Ｂが実行する処理とに分けて記載する。図４に示す一連の処理は、サーバ２００が、投球側ユーザ端末１００Ａと、打撃側ユーザ端末１００Ｂとのマッチングを成立させたことにより開始される。

ステップＳ１０１にて、サーバ２００の対戦支援部２１１は、状況情報を初期化する。状況情報は、対戦の進行状況を示す情報であり、特に対戦の勝敗を左右する重要な情報である。状況情報は、一例として、進行中のイニングを示す「イニング」、各チームの得点を示す「スコア」、走者が何塁にいるかを示す「ランナー」、「アウトカウント」、および、「ボールカウント」を含む。初期化された状況情報は、対戦開始時の対戦の進行状況を示す。ステップＳ１０２にて、対戦支援部２１１は、マッチングが成立した旨の通知と、初期化された状況情報とを各ユーザ端末１００に送信して、対戦を開始する。

ステップＳ１０３およびステップＳ１０４にて、各ユーザ端末１００の対戦進行部１１５は、初期化された状況情報を受信して、対戦の進行を開始する。

ステップＳ１０５にて、対戦支援部２１１は、フェーズ開始の同期をとる。これに伴い、投球側ユーザ端末１００Ａの対戦進行部１１５は、ステップＳ１０６にて、該フェーズの進行を開始し、投球画面を表示部１５２に表示させる。

ステップＳ１０７にて、操作受付部１１１は、投球側ユーザから投球操作を受け付ける。ステップＳ１０８にて、対戦進行部１１５は、該投球操作に基づいて、球種、コース、および、好投か否か等の投球内容を決定する。ステップＳ１０９にて、決定した投球内容を示す情報を含む投球結果Ｄ１を生成し、投球結果Ｄ１をサーバ２００に送信する。

（投球画面）
図５は、ユーザ端末の表示部に表示されるゲーム画面の具体例を示す図である。具体的には、該ゲーム画面は、投手キャラクタの投球シーンを表す投球画面６００である。投球画面６００は、進行中のフェーズがマニュアル進行モードである場合に、投球側ユーザによる投球操作を受け付けるための、以下に説明する投球操作ＵＩを含む。

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

１つのフェーズが開始されると、投球側ユーザ端末１００Ａの対戦進行部１１５は、まず、図５に示す投球画面６００を、ＵＩ制御部１１３に生成させて、表示部１５２に表示させる。

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

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

投球画面６００は、対決中の各キャラクタのステータス情報を含んでいてもよい。一例として、投球画面６００は、自チームの投手キャラクタのステータス情報６１１と、相手チームの打者キャラクタのステータス情報６１２とを含んでいてもよい。

投球画面６００は、対戦における現在の状況を示す状況情報を含んでいてもよい。一例として、状況情報は、現在のイニングを示すイニング情報６３１、各塁における走者の有無を示す走者情報６３２、現在の各チームの得点を示す得点情報６３３、現在のボールカウントおよびアウトカウントを示すカウント情報６３４を含んでもよい。

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

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

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

球種が決定されると、次に、対戦進行部１１５は、次の投球画面（不図示）を表示部１５２に表示させる。なお、以降、該投球画面を第２の投球画面と称する場合がある。第２の投球画面は、球種指定オブジェクト６１０に代えて、コース指定オブジェクトを含む。コース指定オブジェクトは、後述するカーソルと組み合わせることにより、投球側ユーザに、投手キャラクタ６０３に投球させるコースを指定させるためのＵＩオブジェクトとして機能する。

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

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

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

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

コースが確定すると、次に、対戦進行部１１５は、次の投球画面（不図示）を表示部１５２に表示させる。なお、以降、該投球画面を第３の投球画面と称する場合がある。第３の投球画面は、良否判定オブジェクトを含む。良否判定オブジェクトは、投手キャラクタ６０３の制球の良否を決定するためのタイミングを投球側ユーザに指定させるためのＵＩオブジェクトとして機能する。

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

該帯状のゲージは、投手キャラクタ６０３の位置から、捕手キャラクタ６０５の位置に向かって伸びている。ＵＩ制御部１１３は、スライドバーを、初期位置である第１位置から、最終位置である第２位置に向かって、帯の長手方向に移動させる。アニメーション生成部１１４は、スライドバー６２１が、移動の開始から所定時間後に第２領域を通過し、第１領域を通過して、最終的にカーソルの位置に到達するように、アニメーションを生成する。

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

なお、スライドバーを停止させるための操作は、タップ操作に限定されない。例えば、コース確定のための操作が押し込む操作である場合、スライドバーを停止させるための操作は、リリース操作であってもよい。

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

制球の良否が判定されると、対戦進行部１１５は、請求の良否の判定結果に基づいて、ボールが投球されるコース、球速、球種が変化球である場合は、さらに変化量を決定し、これらを投球結果Ｄ１に含め、投球結果Ｄ１をサーバ２００に送信する。次に、対戦進行部１１５は、次の投球画面（不図示）を表示部１５２に表示させる。なお、以降、該投球画面を第４の投球画面と称する場合がある。第４の投球画面は、良否判定結果を含む。

再び図４を参照して、各装置の処理の流れの説明に戻る。ステップＳ１１７にて、アニメーション生成部１１４によって、投手キャラクタ６０３が投球するアニメーションとボール６０４が移動するアニメーションとが生成される。そして、ステップＳ１１８にて、表示制御部１１２によって、これらのアニメーションが表示部１５２に表示される。具体的には、第４の投球画面において、該アニメーションが表示される。これにより、これまで投手キャラクタ６０３のグローブに収まっていたボール６０４が描出されてもよい。

一方、ステップＳ１０５にてフェーズ開始の同期がとられたとき、打撃側ユーザ端末１００Ｂの対戦進行部１１５は、ステップＳ１１０にて、打撃画面を表示部１５２に表示させる。このとき、投手キャラクタ６０３の投球動作は確定していないので、該打撃画面には、ボールを投げる前の投手キャラクタ６０３と、後述するミートカーソル７０４とが表示される。ステップＳ１１１にて、操作受付部１１１は、ミートカーソル７０４を移動させるためのスライド操作を受け付けてもよい。

ステップＳ１１２にて、対戦支援部２１１は、投球結果Ｄ１を受信する。そして、ステップＳ１１３にて、受信した投球結果Ｄ１を、打撃側ユーザ端末１００Ｂに送信する。

ステップＳ１１４にて、打撃側ユーザ端末１００Ｂは、サーバ２００から投球結果Ｄ１を受信する。ステップＳ１１５にて、打撃側ユーザ端末１００Ｂのアニメーション生成部１１４は、受信された投球結果Ｄ１に基づいて、投手キャラクタ６０３が投球するアニメーションとボール６０４が移動するアニメーションとを生成する。ステップＳ１１６にて、表示制御部１１２は、生成された該アニメーションを表示部１５２に表示する。ここで、ＵＩ制御部１１３は、ミートカーソル７０４の他に、打撃側ユーザの打撃操作を支援するためのＵＩオブジェクトを打撃画面に重畳させてもよい。

ステップＳ１１９にて、打撃側ユーザ端末１００Ｂの操作受付部１１１は、打撃側ユーザによる打撃操作を受け付ける。ステップＳ１２０にて、対戦進行部１１５は、受け付けられた打撃操作に基づいて、バット６０２のスイング位置、および、スイングタイミング等を決定する。ステップＳ１２１にて、対戦進行部１１５は、決定したスイング位置およびスイングタイミングの情報を含む打撃結果Ｄ２を生成し、サーバ２００に送信する。

（打撃画面）
図６は、ユーザ端末の表示部に表示されるゲーム画面の具体例を示す図である。具体的には、該ゲーム画面は、打者キャラクタの打撃シーンを表す打撃画面７００である。打撃画面７００は、打撃側ユーザ端末１００Ｂが投球結果Ｄ１を受信した後に表示される画面（ステップＳ１１６にて表示部１５２に表示される画面）である。

打撃画面７００は、仮想空間に配置されている各種オブジェクトを含む。具体的には、打者キャラクタ６０１、バット６０２、相手ユーザが操作する投手キャラクタ６０３、ボール６０４、ホームベース６０７を含む。図６に示すように、打撃画面７００は、相手チームに所属する野手キャラクタ（守備についているキャラクタ）を含んでもよい。

打撃画面７００は、上述した切替ボタン６１３、対決中の各キャラクタのステータス情報（ステータス情報７０８、７０９）、現在の状況を示す状況情報を含んでもよい。

打撃画面７００は、進行中のフェーズがマニュアル進行モードである場合に、打撃画面７００は、マニュアル進行モードにおいて、打撃側ユーザによる打撃操作を受け付けるための、以下に説明する打撃操作ＵＩを含む。すなわち、打撃画面７００は、打撃操作ＵＩとして、タイミングヒントオブジェクト７０３、ミートカーソル７０４、位置ヒントオブジェクト７０５、方向ヒントオブジェクト７０６等を含んでもよい。

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

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

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

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

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

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

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

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

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

再び図４を参照して、各装置の処理の流れの説明に戻る。ステップＳ１２２にて、対戦支援部２１１は、打撃結果Ｄ２を受信する。そして、ステップＳ１２３にて、受信した打撃結果Ｄ２を、投球側ユーザ端末１００Ａに送信する。

投球側ユーザ端末１００Ａがサーバ２００から打撃結果Ｄ２を受信すると、ステップＳ１２４にて、アニメーション生成部１１４は、受信された打撃結果Ｄ２に基づいて、打者キャラクタ６０１が打撃するアニメーションを生成する。ステップＳ１２５にて、表示制御部１１２は、生成された該アニメーションを表示部１５２に表示する。

対戦進行部１１５は、打撃結果Ｄ２に基づいて「打者キャラクタ６０１がバット６０２にボール６０４を当てて打撃した」と判断した場合には、ステップＳ１２６にて、フィールドプレイの計算を行う。具体的には、対戦進行部１１５は、打撃されたボール６０４をフィールド上で移動させるための計算、野手キャラクタに守備（捕球、送球など）をさせるための計算、および、走者キャラクタを進塁または出塁させるための計算を行う。

ステップＳ１２７にて、アニメーション生成部１１４は、対戦進行部１１５の計算結果にしたがって、フィールドプレイのアニメーションを生成してもよい。ステップＳ１２８にて、表示制御部１１２は、該生成されたアニメーションを表示部１５２に表示してもよい。

なお、対戦進行部１１５は、打撃結果Ｄ２に基づいて「打者キャラクタ６０１がバット６０２にボール６０４を当てなかった（空振りした、または、見逃した）」と判断した場合には、ステップＳ１２６〜ステップＳ１２８の各処理の実行を省略する。

ステップＳ１２９にて、対戦進行部１１５は、フィールドプレイに関する計算結果に基づいて、状況情報を更新する。

あるいは、対戦進行部１１５は、ステップＳ１２６〜ステップＳ１２８が省略された場合には、投げられたボール６０４の交差面における到達位置が、ストライクゾーン７０１内か、それ以外かに基づいて、状況情報の中のボールカウントを更新する。

一方、打撃側ユーザ端末１００Ｂの対戦進行部１１５は、ステップＳ１２１の後、ステップＳ１３０〜ステップＳ１３４の各ステップを実行する。ステップＳ１３０〜ステップＳ１３４は、上述の、ステップＳ１２４〜ステップＳ１２８と同様に実行される。異なる点は、打撃結果Ｄ２が、サーバ２００から送信されたものではなく、ステップＳ１２０にて自端末にて生成された情報であるという点である。

対戦進行部１１５は、ステップＳ１３５にて、状況情報４００を更新する。対戦進行部１１５は、更新した状況情報をサーバ２００に送信する。

対戦支援部２１１は、それぞれのユーザ端末１００から、同じタイミングで生成された状況情報を受信すると、ステップＳ１３６にて、受信した状況情報を、それぞれ対戦体の各ユーザ端末１００に転送する。すなわち、投球側ユーザ端末１００Ａが生成した状況情報は、打撃側ユーザ端末１００Ｂに供給され、打撃側ユーザ端末１００Ｂが生成した状況情報は、投球側ユーザ端末１００Ａに供給されて、状況情報が交換される。ステップＳ１３７およびステップＳ１３８にて、各ユーザ端末１００は、対戦相手のユーザ端末１００で生成された状況情報をそれぞれ受信する。

以上で１つのフェーズが終了し、新たなフェーズが開始される。具体的には、ゲームシステム１に含まれる各装置が、ステップＳ１０５からＳ１３８までの処理を再度実行する。フェーズの開始と終了が繰り返されることにより、対戦（ＰｖＰ戦）が進行する。

＜対戦後の処理＞
図７は、ユーザ端末１００が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。図７に示す処理については、投球側ユーザ端末１００Ａと打撃側ユーザ端末１００Ｂとで共通である。そのため、図７に示すフローチャートにおいては、投球側ユーザ端末１００Ａが実行する処理と打撃側ユーザ端末１００Ｂが実行する処理とを区別せずに、ユーザ端末１００が実行する処理としてまとめて記載する。これは、図７以降のフローチャートでも同様である。

ステップＳ７０１において、フェーズの終了時に所定の条件が満たされると、対戦進行部１１５は、対戦の進行に応じて対戦の結果を決定し、対戦を終了（正常終了）させる。一例として、対戦進行部１１５は、最新の状況情報において、「イニング」が最終回（例えば９回）の裏であり、かつ、「アウトカウント」が３アウトである場合、対戦を終了させる。また、例えば、対戦進行部１１５は、最新の状況情報において、「イニング」が最終回（例えば９回）の表であり、守備側のチームの得点が攻撃側のチームの得点より多く、かつ、「アウトカウント」が３アウトである場合、対戦を終了させる。

ステップＳ７０２において、対戦進行部１１５は、自端末のユーザのチーム（自チーム）が対戦に勝利したか否かを判定する。具体的には、対戦進行部１１５は、自チームの得点が相手チームの得点より多いか否かを判定し、自チームの得点が相手チームの得点より多い場合、対戦に勝利したと判定する。一方、対戦進行部１１５は、自チームの得点が相手チームの得点より少ない場合、対戦に敗北したと判定する。

自チームが勝利したと判定した場合（ステップＳ７０２でＹＥＳ）、ステップＳ７０３において、対戦進行部１１５は、現在の拠点地区におけるユーザの連勝数（現在連勝数）を１増やす。続いて、対戦進行部１１５は、現在連勝数が、予め設定された複数の閾値（第１閾値）のいずれかに到達したか否かを判定する。該閾値の何れかに到達したと判定した場合、対戦進行部１１５は、到達した閾値に応じた報酬をユーザに付与する。対戦進行部１１５は、一例として、ゲーム情報１３２として記憶部１２０に格納されている、現在連勝数と報酬とを対応付けたテーブルを参照し、ユーザに付与する報酬を特定する。

図８は、該テーブルの一具体例を示す図である。図８に示すテーブルは、「連勝数」のカラムと「報酬」のカラムとから構成されている。「連勝数」のカラムには、上述した複数の閾値が格納される。図８の例では、５、１０、１５、２０が格納されている。「報酬」のカラムにはユーザに付与される報酬を示す情報が格納されている。図８の例では、第１報酬〜第４報酬を示す情報が格納されている。つまり、図８に示すテーブルは、ユーザが編成したチームが拠点地区において５連勝、１０連勝、１５連勝、２０連勝した場合、それぞれ、第１報酬、第２報酬、第３報酬、第４報酬をユーザに付与することを示している。なお、テーブルに格納される閾値、および、報酬を示す情報は、図８の例に限定されない。

また、第１報酬〜第４報酬は、その序数が大きいほど、ゲーム内における価値が高い報酬であるとする。すなわち、第１報酬、第２報酬、第３報酬、第４報酬の順に、ゲーム内における価値が高くなる。「ゲーム内における価値が高い」とは、例えば、個数が多い、希少度が高い、ゲーム内における有用度が高いという意味であり、これらの複数を満たすものであってもよい。

一例として、第１報酬〜第４報酬がパックである場合、その序数が大きいほど、ランクが高いパックであってもよい。あるいは、その序数が大きいほど、付与されるパックの数が多くなってもよい。また、より序数の大きい報酬は、「パックのランクが高い」、および、「付与されるパックの数が多い」、の両方を満たすものであってもよい。例えば、第１報酬が、最もランクの低いパック１つである場合、第２報酬〜第４報酬の少なくともいずれかが、その一部が最もランクの低いパックであり、残りがよりランクの高いパックである、複数のパックであってもよい。また、第２報酬〜第４報酬の少なくともいずれかが、よりランクの高いパックのみで構成された複数のパックであってもよい。

図７では、現在連勝数が、予め設定された複数の閾値のいずれかに到達したか否かを判定するステップの例として、現在連勝数が５であるか否か（ステップＳ７０４）、および、現在連勝数が１０であるか否か（ステップＳ７０６）を記載している。換言すれば、図７では、フローの簡略化を目的として、現在連勝数が１５および２０であるか否かの判定については、記載を省略している。

ステップＳ７０４でＹＥＳの場合、対戦進行部１１５は、ステップＳ７０５において、ユーザに第１報酬を付与する。ステップＳ７０４でＮＯ、かつ、ステップＳ７０６でＹＥＳの場合、対戦進行部１１５は、ステップＳ７０７において、ユーザに、第１報酬よりゲーム内における価値が高い第２報酬を付与する。

ステップＳ７０６でＮＯの場合、対戦進行部１１５は、ユーザに報酬を付与しない。なお、ステップＳ７０６でＮＯの場合とは、現在連勝数が、予め設定された複数の閾値のいずれでもない場合である。そして、図７に示すフローは終了する。対戦進行部１１５は、ゲーム画面を、自動的にホーム画面に遷移させてもよい。

一方、ステップＳ７０２において、自チームが敗北したと判定した場合（Ｓ７０２でＮＯ）、ステップＳ７０８において、対戦進行部１１５は、現在の拠点地区におけるユーザの現在連勝数を０にリセットする。つまり、敗北したユーザは連勝数の増加を、０からやり直さなければならない。例えば、現在連勝数が１９であった場合、敗北したユーザは、第４報酬を獲得するために、対戦に２０連勝する必要がある。

（サーバダウン）
図９は、ユーザ端末１００が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。具体的には、サーバ２００においてサーバダウンが発生した場合に、ユーザ端末１００が実行する処理の流れを示すフローチャートである。

ステップＳ９０１において、対戦進行部１１５はサーバダウンを検出する。サーバダウンの検出方法としては、既知の方法を用いればよい。対戦進行部１１５は、ステップＳ９０２において、サーバダウンを検出した時点のイニング数に応じて、最大待機時間を決定し、ステップＳ９０３において、対戦を中断する。最大待機時間とは、サーバ２００の復帰を待機する時間の最大値である。対戦進行部１１５は、一例として、試合の終盤においてサーバダウンが発生したことを検出した場合、試合の序盤においてサーバダウンが発生したことを検出した場合に比べて、最大待機時間を長くしてもよい。例えば、対戦進行部１１５は、イニングが１〜４回であるときにサーバダウンが発生したことを検出した場合、最大待機時間を５分として、対戦を中断する。一方、対戦進行部１１５は、イニングが５〜９回であるときにサーバダウンが発生したことを検出した場合、最大待機時間を１０分として、対戦を中断する。

なお、最大待機時間の長さは、対戦の状況に依らず固定（例えば、５分）であってもよい。この例の場合、ステップＳ９０２の処理は実行されない。

図１０は、ユーザ端末の表示部に表示されるゲーム画面の具体例を示す図である。該ゲーム画面は、図３を参照して説明した対戦開始画面３１０であるが、図１０に示す対戦開始画面３１０は、対戦開始ＵＩ３１１の代わりに、テキスト３１３を含んでいる点が、図３に示す対戦開始画面３１０と異なる。

対戦進行部１１５は、対戦を中断した場合、一例として、対戦中のゲーム画面に代えて図１０に示す対戦開始画面３１０を表示部１５２に表示させる。テキスト３１３は、サーバダウンが発生したことにより対戦が中断していることをユーザに報知するテキストである。サーバダウンが発生したことにより対戦が中断していることをユーザに報知することができれば、テキスト３１３の内容は、図１０に示すものに限定されない。

ステップＳ９０４およびＳ９０５において、対戦進行部１１５は、最大待機時間が経過するまで、サーバ２００の復帰を待機する。具体的には、対戦進行部１１５は、最大待機時間が経過するまで、図１０に示す対戦開始画面３１０を表示部１５２に表示する。

（対戦の再開）
最大待機時間が経過する前に、サーバ２００の復帰を検出した場合（ステップＳ９０４でＹＥＳ）、ステップＳ９０７において、対戦進行部１１５は、サーバ２００の復帰をユーザに通知する。

図１１は、ユーザ端末の表示部に表示されるゲーム画面の具体例を示す図である。該ゲーム画面は、図３を参照して説明した対戦開始画面３１０であるが、図１１に示す対戦開始画面３１０は、対戦開始ＵＩ３１１の代わりに、対戦再開ＵＩ３１４およびテキスト３１５を含んでいる点が、図３に示す対戦開始画面３１０と異なる。

対戦進行部１１５は、サーバ２００の復帰を検出した場合、一例として、図１０に示す対戦開始画面３１０を、図１１に示す対戦開始画面３１０に更新し、サーバ２００の復帰をユーザに通知する。テキスト３１５は、サーバ２００がサーバダウンから復帰したことをユーザに通知するテキストである。サーバ２００がサーバダウンから復帰したことをユーザに通知することができれば、テキスト３１５の内容は、図１１に示すものに限定されない。

ステップＳ９０８およびＳ９０９において、対戦進行部１１５は、ユーザおよび相手ユーザによる対戦再開操作の入力（第１の入力）を待機する状態となる。対戦再開操作とは、中断した対戦を再開（復帰）させるための操作であり、一例として、図１１に示す対戦開始画面３１０に含まれる、対戦再開ＵＩ３１４に対するタップ操作である。

対戦再開操作が入力されたと操作受付部１１１が判別した場合（ステップＳ９０８でＹＥＳ）、対戦進行部１１５は、対戦再開通知を、サーバ２００を介して相手ユーザのユーザ端末１００へ送信する。対戦再開通知とは、対戦再開ＵＩ３１１へのタップ操作を受け付けたこと、すなわち、ユーザが対戦を再開しようとしていることを相手ユーザのユーザ端末１００へ通知するものである。

対戦進行部１１５は、相手ユーザによる対戦再開操作の入力を、対戦再開通知を受信することにより特定する。対戦再開通知を受信した場合（ステップＳ９０９でＹＥＳ）、すなわち、ユーザおよび相手ユーザの両方が対戦再開操作を入力した場合、ステップＳ９１０およびＳ９１１において、対戦進行部１１５は、待機時間に応じて対戦を自動的に進行させた後、対戦を再開させる。待機時間とは、対戦が中断してから再開するまでに要した時間、換言すれば、サーバ２００においてサーバダウンが発生してから（あるいは、ユーザ端末１００が、サーバダウンが発生したことを検出してから）、ユーザおよび相手ユーザの両方が対戦再開操作を入力するまでに要した時間である。

一例として、対戦進行部１１５は、サーバ２００から受信した状況情報に基づいて、対戦を進行させる。具体的には、サーバ２００の対戦支援部２１１は、ゲーム情報２３２として予め記憶部２２０に記憶されている、１イニングが開始してから終了するまでの平均時間と、上述した待機時間とに基づいて、対戦を自動的に進行させる量を決定する。より具体的には、待機時間を平均時間で除算することにより、自動的に進行させた後のイニング（何回であるか、および、表と裏のいずれであるか）を決定する。平均時間は、例えば、本野球ゲームにおいて過去に実施された複数の試合における、１イニングが開始してから終了するまでの時間に基づいて算出されたものであってもよい。あるいは、平均時間は、実際の試合（例えば、本年度のプロ野球における複数の試合）における、１イニングが開始してから終了するまでの時間に基づいて算出されたものであってもよい。

対戦支援部２１１は、さらに、試合に出場しているキャラクタ（カード）、打者であるキャラクタ、スコア、ランナー、アウトカウント、および、ボールカウントを決定する。対戦支援部２１１は、例えば、自動的に進行された期間の打撃結果Ｄ２をすべて決定し、該打撃結果Ｄ２に基づいてスコアを決定してもよい。また、対戦支援部２１１は、自動的に進行された期間に選手の交代があったとして、スターティングメンバーであるキャラクタに代えて、ベンチ入りのキャラクタを試合に出場させてもよい。なお、スターティングメンバーであるキャラクタとは、すなわち、メインデッキに含まれるカードである。ベンチ入りのキャラクタとは、すなわち、サブデッキに含まれるカードである。つまり、「試合に出場しているキャラクタに代えて、ベンチ入りの選手を試合に出場させる」とは、ユーザ端末１００から受信したデッキ情報において、サブデッキを構成する枠の枠識別番号に関連付けられているカードＩＤを、メインデッキを構成する枠の枠識別番号に関連付けられるように変更することである。

対戦支援部２１１は、ランナー、アウトカウント、および、ボールカウントを、本野球ゲームにおける野球のルールから逸脱しない範囲内でランダムに決定してもよい。例えば、対戦支援部２１１は、「ランナー２塁、２アウト、２ボール１ストライク」という状況情報を生成してもよい。これにより、対戦は、あるイニングの最初からではなく、途中から、すなわち、ランナー２塁、２アウト、２ボール１ストライクという状況で再開される。

対戦支援部２１１は、生成した状況情報を、両方のユーザ端末１００に送信する。これにより、両方のユーザ端末１００において、同一の状況で対戦が再開される。

図１２は、ユーザ端末の表示部に表示されるゲーム画面の具体例を示す図である。具体的には、該ゲーム画面は、対戦が再開された場合に表示されるゲーム画面である。図１２では、このゲーム画面の一例として、投球画面６００を示している。なお、対戦が再開された場合に表示されるゲーム画面は、対戦を自動的に進行させた後のイニングに応じて決まるため、対戦が再開された場合に表示されるゲーム画面として、打撃画面７００が表示される場合もある。

ここでは、図５に示す投球画面６００が表示されているときに、サーバ２００においてサーバダウンが発生し、対戦が中断したものとする。換言すれば、対戦は４回裏（図５参照）で中断したものとする。

図１２に示すように、対戦の再開後に表示された投球画面６００では、イニング情報６３１は「６裏」となっており、６回の裏であることを示している。つまり、対戦は、４回裏から６回裏まで自動的に進行したうえで再開されている。また、図１２に示す投球画面６００では、得点情報６３３が「Ｓ１−３Ｄ」となっている。つまり、対戦が自動的に進行する過程で、両チームに１点ずつ追加されている。このように、対戦の再開前に、対戦を自動的に進行させることで、対戦にかかる時間の長大化を防ぐことができる。結果として、中断した時点から対戦が再開することに起因する、ユーザの対戦を継続することへの意欲の減退を防ぐことができる。

対戦の再開後、図９に示すフローチャートは、図７に示すフローチャートのステップＳ７０１へ進む。すなわち、対戦は、再開後に図４に示すフローチャートに基づいて進行した後、終了する。

（無効試合）
サーバ２００の復帰を検出することなく、最大待機時間が経過した場合（ステップＳ９０４でＮＯ、かつ、ステップＳ９０５でＹＥＳ）、サーバ２００が復帰した後、対戦再開操作を受け付けることなく、最大待機時間が経過した場合（ステップＳ９０８でＮＯ、かつ、ステップＳ９０５でＹＥＳ）、および、サーバ２００が復帰した後、対戦再開通知を受信することなく、最大待機時間が経過した場合（ステップＳ９０９でＮＯ、かつ、ステップＳ９０５でＹＥＳ）、対戦進行部１１５は、ステップＳ９０６において、該対戦を無効試合として終了させる。対戦進行部１１５は、対戦を無効試合として終了させた場合、対戦前の連勝数を維持する。

図１３は、ユーザ端末の表示部に表示されるゲーム画面の具体例を示す図である。該ゲーム画面は、図３を参照して説明した対戦開始画面３１０であるが、図１３に示す対戦開始画面３１０は、対戦開始ＵＩ３１１の代わりに、ＵＩ３１６およびテキスト３１７を含んでいる点が、図３に示す対戦開始画面３１０と異なる。

対戦進行部１１５は、対戦を無効試合として終了させると、一例として、図１１に示す対戦開始画面３１０を、図１３に示す対戦開始画面３１０に更新し、対戦が無効試合となり終了したことをユーザに通知する。テキスト３１７は、対戦が無効試合となったことをユーザに通知するテキストである。また、テキスト３１７は、対戦前の連勝数が維持されることをユーザに通知する内容を含んでいる。これにより、ユーザは、無効試合になったことで連勝数が更新されないことを容易に理解することができる。換言すれば、ユーザ端末１００は、無効試合になったことで連勝数がリセットされる（０になる）のではないか、との不安を、ユーザが抱くことを回避することができる。なお、テキスト３１７の内容は、対戦が無効試合になったことをユーザに通知することができればよく、図１３に示すものに限定されない。例えば、テキスト３１７は、対戦前の連勝数が維持されることをユーザに通知する内容を含んでいなくてもよい。

以上で、図９に示すフローは終了する。対戦進行部１１５は、ステップＳ９０６における処理の実行後、ゲーム画面を、自動的にホーム画面に遷移させてもよい。

（効果）
以上のように、本実施形態では、ユーザ端末１００は、ゲームプログラム１３１に基づいて、以下のステップを実行するように構成されている。具体的には、ユーザ端末１００は、ユーザ端末１００に対するユーザの入力と、ユーザ端末１００とサーバ２００との間の通信とに基づいて、ユーザと相手ユーザとの対人対戦を進行させるステップと、対人対戦の進行中にサーバ２００においてサーバダウンが発生したことを検出するステップと、サーバダウンがサーバ２００に発生したことに応じて、対人対戦を無効試合として終了するステップと、対人対戦が無効とされなかった場合、対人対戦の進行に応じて対戦の結果を決定するステップと、対人対戦が無効とされた場合、現在連勝数を更新しない一方、対人対戦の結果が決定された場合、対人対戦の結果に基づいて、現在連勝数を更新するステップと、を実行するように構成されている。

このように、ユーザ端末１００は、サーバ２００のサーバダウンが発生したことに応じて、対人対戦を無効として対人対戦を終了させる。一方、対人対戦が無効とされなかった場合、例えば、対人対戦が正常に終了した場合は、対人対戦の進行に応じて対戦の結果を決定する。そして、対戦の結果が決定された場合、現在連勝数を更新する一方、対人対戦が無効とされた場合、現在連勝数を更新しない。これにより、ユーザに非が無く対戦が途中で終了したにもかかわらず、ユーザの連勝がストップすることによる、ユーザのゲームをプレイする意欲が減退することを回避することができる。

また、一例として、ユーザ端末１００は、ゲームプログラム１３１に基づいて、ユーザが対戦に勝利したことに応じて更新された現在連勝数が複数の閾値のいずれかに到達した場合、ゲーム内で利用できる報酬をユーザに付与するステップをさらに実行してもよい。

また、該付与するステップでは、現在連勝数がより高い閾値に到達した場合、ゲーム内における価値がより高い報酬を付与してもよい。

このように、連勝を重ねていくことで、ユーザには報酬が付与される。さらに、連勝が続けば、報酬はより価値の高いものになっていく。換言すれば、本野球ゲームにおいて、連勝を継続することはユーザにとって重要な事項であり、連勝がストップすることはユーザにとって大きな不利益となる。つまり、サーバ２００のサーバダウンといった、ユーザに非が無い原因で対戦が途中で終了し、ユーザの連勝がストップすることは、ユーザのゲームをプレイする意欲を大きく減退させるものである。

特に、本野球ゲームにおいては、対戦に勝利することによりレーティングの値が増加する。これはすなわち、連勝数の増加に伴い、対戦する相手ユーザの強さが強くなることを意味する。つまり、本野球ゲームにおいて、連勝を継続することは困難である。このため、本野球ゲームにおいて、サーバ２００のサーバダウンといった、ユーザに非が無い原因で対戦が途中で終了し、ユーザの連勝がストップすることは、対戦相手がレーティングに基づかずに決定されるゲームと比べて、ユーザのゲームをプレイする意欲をより大きく減退させるものとなる。

このような課題に対し、本実施形態に係るユーザ端末１００は、サーバダウンに基づいて対戦が終了した場合は、ユーザの現在連勝数を更新せず、対戦前の現在連勝数を維持するので、ユーザのゲームをプレイする意欲が大きく減退することを回避することができる。この効果は、対戦相手がレーティングに基づいて決定される本野球ゲームのようなゲームにおいて、特に顕著な効果であるといえる。

また、一例として、ユーザ端末１００は、サーバダウンがサーバ２００に発生したことに応じて対人対戦を中断するステップをさらに実行するように構成されていてもよい。この例において、ユーザ端末１００は、サーバダウンがサーバ２００に発生してから最大待機時間が経過するまでに対人対戦が再開されなかったことに応じて、対人対戦を無効としてもよい。これにより、サーバダウンにより対人対戦が即無効試合となることを回避することができる。

また、一例として、ユーザ端末１００は、サーバ２００がサーバダウンから復帰したことを検出するステップと、サーバダウンがサーバ２００に発生してから最大待機時間が経過する前にサーバ２００がサーバダウンから復帰し、かつ、最大待機時間が経過する前にユーザおよび相手ユーザの両方が対戦再開操作の入力を入力部１５１に対して行ったことに応じて、対人対戦を再開するステップと、を実行するように構成されていてもよい。これにより、対戦の中断後に、ユーザおよび相手ユーザに、対戦再開の意欲がある場合、対戦を再開することができる。よって、対戦の再開を願うユーザおよび相手ユーザが満足する可能性を上げることができる。

また、一例として、ユーザ端末１００は、上述の再開するステップにおいて、対戦の中断分を自動的に進行させてから、対人対戦を再開してもよい。

これにより、対戦の中断に伴う、対戦にかかる時間の長大化を防ぐことができる。結果として、中断した時点から対戦が再開することに起因する、ユーザが対戦を継続する意欲の減退を回避することができる。

なお、ユーザ端末１００は、対戦を中断させてから再開させるまでに要した時間に基づいて決定した進行量で、中断させた対人対戦を自動的に進行させてもよい。あるいは、予め定められた進行量で、中断させた対人対戦を自動的に進行させてもよい。換言すれば、進行量は固定であってもよい。

また、一例として、ユーザ端末１００は、上述の無効とするステップでは、最大待機時間が経過する前にサーバ２００がサーバダウンから復帰した場合であっても、最大待機時間が経過するまでの間にユーザおよび相手ユーの少なくとも一方が対戦再開操作を入力部１５１に入力しない場合、対人対戦を終了させてもよい。

このように、対戦の中断により、ユーザおよび相手ユーザの両方が対戦を継続する意欲を失った場合、ユーザ端末１００は対戦を終了させる。これにより、対戦が不要に継続することを防ぐことができる。

また、一例として、ユーザ端末１００は、ゲームプログラム１３１に基づいて、サーバダウンが発生した場合、対戦の状況に基づいて、最大待機時間の長さを決定するステップをさらに実行してもよい。これにより、ユーザが対戦の再開を待機する時間を適切なものとすることができる。

上述の決定するステップでは、一例として、サーバダウンが発生した時点のイニングが、１回から最終回までの何れであるかに応じて最大待機時間の長さを決定してもよい。例えば、上述の決定するステップでは、対戦の終盤（例えば５〜９回）においてサーバダウンが発生したことを検出した場合、対戦の序盤（例えば１〜４回）においてサーバダウンが発生したことを検出した場合に比べて、最大待機時間を長くしてもよい。

終盤で対戦が中断した場合、特に中断時点で有利であったユーザ（例えば、中断時点で自チームが勝っているユーザ）は、対戦の再開を強く願うものである。このため、対戦の終盤においてサーバダウンが発生したことを検出した場合は、対戦の序盤においてサーバダウンが発生したことを検出した場合に比べて、最大待機時間を長くすることにより、対戦が再開する可能性を上げることができ、対戦の再開を願うユーザが満足する可能性を上げることができる。

〔実施形態２〕
本発明の他の実施形態について、以下に説明する。なお、説明の便宜上、上述の実施形態にて説明した部材と同じ機能を有する部材については、同じ符号を付記する。また、このような部材については、実施形態１で既に説明しているため、本実施形態ではその説明を繰り返さない。

図１４は、ユーザ端末１００が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。具体的には、サーバ２００においてサーバダウンが発生した場合に、ユーザ端末１００が実行する処理の流れを示すフローチャートである。なお、なお、図１４に記載のフローは、図９に記載のステップＳ９０１〜Ｓ９０４が実行された後のフローである。

最大待機時間が経過する前に、サーバ２００の復帰を検出した場合、ステップＳ１４０１において、対戦進行部１１５は、サーバ２００の復帰をユーザに通知する。対戦進行部１１５は、例えば、図１０に示す対戦開始画面３１０を、図１１に示す対戦開始画面３１０に更新し、サーバ２００の復帰をユーザに通知する。

ステップＳ１４０２において、対戦進行部１１５は、対戦開始通知の受信を待機する状態となる。

対戦開始通知を受信した場合（ステップＳ９０９でＹＥＳ）、ステップＳ１４０３において、対戦進行部１１５は、待機時間に応じて対戦を自動的に進行させる。ここでの待機時間は、サーバ２００においてサーバダウンが発生してから、対戦開始通知を受信するまでに要した時間である。

ステップＳ１４０４において、対戦進行部１１５は、ユーザによる対戦再開操作の入力を待機する状態となる。

対戦再開操作が入力されたと操作受付部１１１が判別した場合（ステップＳ１４０４でＹＥＳ）、ステップＳ１４０５において、対戦進行部１１５は、マニュアル進行モード、または、部分オートモード対人対戦を再開させる。対戦進行部１１５は、例えば、対人対戦の中断時にマニュアル進行モードであった場合、マニュアル進行モードで再開させ、該中断時に部分オートモードであった場合、部分オートモードで対人対戦を再開させてもよい。あるいは、対戦進行部１１５は、中断時にいずれのモードであったかに関わらず、マニュアル進行モードで対人対戦を再開させてもよい。

一方、対戦再開操作が入力されたと操作受付部１１１が判別していない場合（ステップＳ１４０４でＮＯ）、ステップＳ１４０６において、対戦進行部１１５は、自動的に進行させた対人対戦を、完全オートモードで再開させる。すなわち、対戦進行部１１５は、ユーザのチームのキャラクタを、ユーザの操作入力無しでゲームプログラム１３１に従って動作させ、対戦を進行させる。

対戦進行部１１５は、対戦を進行させながら、対戦終了までにユーザによる対戦再開操作の入力を待機している（ステップＳ１４０７）。対戦終了までにユーザによる対戦再開操作の入力があった場合（ステップＳ１４０７でＹＥＳ）、すなわち、対戦終了までに対戦再開操作が入力されたと操作受付部１１１が判別した場合、対戦進行部１１５は、ステップＳ１４０８において、完全オートモードで進行した部分を維持して、マニュアル進行モード、または部分オートモードで対人対戦を再開させる。

一方、対戦終了までにユーザによる対戦再開操作の入力が無かった場合（ステップＳ１４０７でＮＯ）、図１４に示すフローチャートは、図７に示すフローチャートのステップＳ７０１へ進む。すなわち、対戦進行部１１５は、完全オートモードで進行した対人対戦の結果に応じて、現在連勝数を更新する。

なお、ステップＳ１４０２の処理と、ステップＳ１４０４の処理とは、同時に実行されてもよい。この場合、対戦進行部１１５は、対戦再開通知を受信した場合、または、対戦再開操作が入力されたと操作受付部１１１が判別した場合に、ステップＳ１４０３の処理を実行する。そして、対戦再開通知の受信および対戦再開操作の入力のうち、実行されていない方の実行を待機しながら、対人対戦を再開する。

なお、ユーザによる対戦再開操作が入力されたと操作受付部１１１が判別し、かつ、対戦進行部１１５が対戦再開通知を受信していない場合、すなわち、相手ユーザが対戦再開操作を入力していない場合、ユーザのユーザ端末１００では、マニュアル進行モード、または部分オートモードで対人対戦が再開し、相手ユーザのユーザ端末１００では、完全オートモードで対人対戦が再開する。すなわち、本実施形態に係るゲームシステム１では、最大待機時間が経過する前に、ユーザおよび相手ユーザの一方が対戦再開操作の入力を入力部１５１に対して行うとともに、他方が対戦再開操作の入力を入力部１５１に対して行わなかったことに応じて、対人対戦を、該他方の操作入力無しで進行するモード（第１モード）で再開する、と表現することもできる。「他方の操作入力無しで進行するモード」とは、すなわち、対戦再開操作の入力を行った側のユーザ端末１００では、対戦が、マニュアル進行モード、または部分オートモードで再開し、対戦再開操作の入力を行わなかった側のユーザ端末１００では、対戦が、完全オートモードで対人対戦が再開することを指す。

（効果）
以上のように、本実施形態では、ユーザ端末１００は、ゲームプログラム１３１に基づいて、最大待機時間が経過する前にサーバ２００がサーバダウンから復帰し、かつ、最大待機時間が経過する前に一方のみが対戦再開操作を入力部１５１に入力した場合、対戦再開操作の入力を行った側のユーザ端末１００では、対戦が、マニュアル進行モード、または部分オートモードで再開し、対戦再開操作の入力を行わなかった側のユーザ端末１００では、対戦が、完全オートモードで対人対戦が再開する。そして、再開された対人対戦が無効となることなく終了すれば、該対人対戦の結果に応じて現在連勝数が更新される。

これにより、ユーザが対戦再開操作を入力すれば、その対戦が無効試合となることが無くなるので、対戦の再開を希望するユーザ、例えば、中断時点で有利であったユーザを満足させることができる。また、ユーザはこの対戦に勝利すれば、現在連勝数を伸ばすことができる。一方、対戦再開操作を入力しない場合、相手ユーザが対戦再開操作を入力していれば、完全オートモードで対人対戦が再開し、該対戦の結果に基づいて現在連勝数が更新される。このためユーザは、対戦に敗北し、現在連勝数が０になることを嫌い、対戦再開操作を積極的に入力しようとする。結果として、サーバ２００がサーバダウンから復帰した後の対戦を、対人対戦として再開できる可能性が向上する。

〔サーバ２００を原因としない通信エラーの場合〕
ここでは、サーバ２００を原因としない通信エラー（第２エラー）が発生した場合の処理の流れについて説明する。図１５は、ユーザ端末１００が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。具体的には、サーバ２００を原因としない通信エラーが発生した場合に、ユーザ端末１００が実行する処理の流れを示すフローチャートである。なお、サーバ２００を原因としない通信エラーとは、例えば、ユーザまたは相手ユーザが、ユーザ端末１００とサーバ２００との通信を不可能な状態とする操作を、ユーザ端末１００に入力したり、ユーザまたは相手ユーザが、ユーザ端末１００を持ったまま通信圏外に移動したり、無線通信事業者の通信設備に障害が発生したりした場合に発生するが、該通信エラーの発生原因はこの例に限定されない。なお以降、サーバ２００を原因としない通信エラーを単に「通信エラー」と記載する。

ステップＳ１５０１において、対戦進行部１１５は通信エラーを検出する。通信エラーの検出方法としては、既知の方法を用いればよい。対戦進行部１１５は、ステップＳ１５０２において、対戦を中断する。

ステップＳ１５０３およびＳ１５０５において、対戦進行部１１５は、所定の最大待機時間（第２時間）が経過するまで、通信エラーの解消を待機する。対戦進行部１１５は、最大待機時間が経過するまで、対戦開始画面３１０を表示部１５２に表示してもよい。この対戦開始画面３１０は、例えば、通信エラーのため対戦が中断していることを示すテキストを含んでいてもよい。また、最大待機時間は可変であってもよい。例えば、対戦進行部１１５は、通信エラーを検出した時点のイニング数に応じて、最大待機時間を決定してもよい。

最大待機時間が経過する前に、通信エラーの解消を検出した場合（ステップＳ１５０３でＹＥＳ）、ステップＳ１５０６において、対戦進行部１１５は、サーバ２００の復帰をユーザに通知する。以降のステップＳ１５０７〜Ｓ１５１０の処理は、それぞれ、図９に示すステップＳ９０８〜Ｓ９１１の処理と同様であるため、ここでは説明を繰り返さない。

一方、通信エラーの解消を検出することなく、最大待機時間が経過した場合（ステップＳ１５０３でＮＯ、かつ、ステップＳ１５０４でＹＥＳ）、通信エラーが解消した後、対戦再開操作を受け付けることなく、最大待機時間が経過した場合（ステップＳ１５０７でＮＯ、かつ、ステップＳ１５０４でＹＥＳ）、および、通信エラーが解消した後、対戦再開通知を受信することなく、最大待機時間が経過した場合（ステップＳ１５０８でＮＯ、かつ、ステップＳ１５０４でＹＥＳ）、対戦進行部１１５は、ステップＳ１５０５において、中断時の状況に基づいて対戦結果を決定する。対戦進行部１１５は、一例として、中断時点でより多くの得点を獲得しているチームの勝利とする。なお、対戦進行部１１５は、中断時点の得点が同じである場合、該対戦を引き分けとしてもよい。

対戦結果の決定後、図１５に示すフローチャートは、図７に示すフローチャートのステップＳ７０１へ進み、対戦が終了する。そして、対戦進行部１１５は、対戦結果に応じて現在連勝数を更新する。

（効果）
以上のように、実施形態１および２に係るユーザ端末１００は、一例として、対人対戦の進行中に、サーバ２００を原因としない通信エラー（以下、単に「通信エラー」）が発生したことを検出するステップをさらに実行するように構成されていてもよい。そして、ユーザ端末１００は、この例において、通信エラーが発生したことに応じて対人対戦を無効としない。

また、実施形態１および２に係るユーザ端末１００は、この例において、通信エラーが発生したことに応じて対人対戦を中断するステップをさらに実行するように構成されていてもよい。そして、ユーザ端末１００は、通信エラーが発生してから最大待機時間が経過するまでに通信エラーが解消されなかった場合、対人対戦の中断時点における状況に基づいて、対人対戦の結果を決定してもよい。

つまり、サーバダウンなどのサーバ２００を原因とするエラーにより対人対戦が終了した場合は、ユーザに非が無く対戦が途中で終了しているため、その対戦を無効とし、現在連勝数に影響が出ないようにする一方、サーバ２００を原因としない通信エラーにより対人対戦が終了した場合は、対戦を無効とせず、中断時の状況に応じて対戦結果を決定し、現在連勝数を更新する。換言すれば、ゲームの運営側に非が無い場合の異常終了では、対戦を無効とせず、現在連勝数を更新する。

これにより、対戦の状況が悪くなったユーザが意図的に通信を遮断し、対戦を強制的に終わらせることを防止することができる。

〔変形例〕
上述の各実施形態では、ゲームシステム１によって実行されるゲームは、対戦型野球ゲームであるものとして説明したが、ゲームシステム１によって実行されるゲームは、ユーザ端末１００に対するユーザの入力と、ユーザ端末１００とサーバ２００との間の通信とに基づいて、ユーザと対戦相手との対戦が進行するゲームであれば、この例に限定されない。例えば、野球以外のスポーツ（テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなど）を題材としたゲームであってもよい。また、例えば、パズルゲーム、クイズゲーム、ＲＰＧ、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームであってもよい。

さらに、ユーザと対戦相手との対戦は、対人対戦に限定されない。例えば、該対戦はＣＰＵ戦であってもよい。また、対人対戦に参加するユーザおよび相手ユーザの人数は、３人以上であってもよい。すなわち、対人対戦は、１人対複数人、または、複数人対複数人の対戦であってもよい。

また、本野球ゲームにおいて、対戦の結果に応じて更新されるパラメータは、現在連勝数に限定されない。該パラメータは、例えば、ユーザのレーティングであってもよい。また、本野球ゲームにおいては、ユーザが対戦に敗北した場合に、該ユーザの不利益になるように更新されるパラメータとは異なるパラメータを、対戦の結果に応じて更新してもよい。

また、ユーザ端末１００が検出する、サーバ２００との通信が不可能な状態の原因は、サーバダウンと異なる、サーバ２００の不具合が原因であってもよい。

本野球ゲームにおいて、サーバ２００の不具合に起因して対戦を途中で終了する場合、該対戦を無効試合とは異なる結果でユーザに通知してもよい。例えば、該対戦を引き分けとしてユーザに通知してもよい。ただし、この例においては、どのような結果で通知するにしても、該対戦の結果に基づく連勝数などのパラメータの更新は行われない。

ユーザ端末１００は、サーバ２００の不具合に起因して対戦を途中で終了する場合において、対戦が中断した時点のイニングが所定の条件を満たしている場合、対戦が成立したとみなしてもよい。対戦が成立したとみなす、とは、すなわち、この対戦の結果に応じて、連勝数などのパラメータの更新を行うということである。例えば、ユーザ端末１００は、対戦が中断した時点のイニングが６回以降である場合、対戦が成立したとみなしてもよい。

連勝数などの、ユーザが対戦に敗北した場合に、該ユーザの不利益になるように更新されるパラメータが所定の閾値に到達した場合に、ユーザに付与される報酬は、パックに限定されない。

対戦の状況に基づく、最大待機時間の長さの決定は、サーバ２００に不具合が発生した（すなわち、対戦が中断した）時点のイニングに基づく決定に限定されない。例えば、該時点での点差が所定の閾値を超えるか否か、などに基づいて決定してもよい。具体的には、該時点の点差が所定の閾値を超える場合、該点差が所定の閾値を超えない場合に比べて、最大待機時間の長さを長くしてもよい。

また、上述した実施形態では、野球ゲームを例示して説明したため、サーバ２００の不具合（サーバダウン）が発生した時点のイニングが、１回から最終回までの何れであるかに応じて最大待機時間の長さを決定していた。これに対し、ゲームシステム１によって実行されるゲームが、野球ゲーム以外のゲームであって、複数のフェーズから構成される対戦を行うゲームパートを含むゲームである場合、ユーザ端末１００のプロセッサ１０は、サーバ２００に不具合が発生した時点が含まれる第１フェーズが、複数のフェーズの何れであるかに応じて最大待機時間の長さを決定すればよい。複数のフェーズの一例としては、例えば、サッカーを題材としたゲームにおけるサッカーの試合の前後半、テニスを題材としたゲームにおけるテニスの各セット、格闘ゲームや、ボクシングを題材としたゲームにおける各ラウンド、などが挙げられるが、これらに限定されるものではない。

対戦進行部１１５は、試合の終盤においてサーバダウンが発生したことを検出した場合、試合の序盤においてサーバダウンが発生したことを検出した場合に比べて、最大待機時間を短くしてもよい。

各ユーザ端末１００の対戦進行部１１５は、サーバ２００の不具合に起因してサーバ２００との通信が不可能となった場合、対戦を中断せず、ＣＰＵ戦として対戦を継続してもよい。該ＣＰＵ戦は、マニュアル進行モードで進行してもよいし、部分オートモード、または、完全オートモードで進行してもよい。また、この例において、最大待機時間が経過する前にサーバ２００がサーバダウンから復帰し、かつ、最大待機時間が経過する前にユーザおよび相手ユーザが対戦再開操作を入力部１５１に入力した場合、対戦進行部１１５は、対人対戦を再開させてもよい。ただし、ＣＰＵ戦で進行した部分については、両ユーザ端末１００で同期がとれていない、換言すれば、該部分の状況は、ユーザ端末１００ごとに異なるため、対戦進行部１１５は、ＣＰＵ戦で進行した部分をリセットし、サーバ２００との通信が不可能となった時点から対人対戦を再開することが望ましい。

あるいは、ＣＰＵ戦で進行した部分については、先に対戦再開操作を入力部１５１に入力したユーザ側の部分を採用してもよい。具体的には、サーバ２００の対戦支援部２１１は、両方のユーザ端末１００から対戦再開通知を受信した場合、先に対戦再開通知を送信したユーザ端末１００に対し、状況情報の送信指示を送信する。該送信指示を受信したユーザ端末１００は、状況情報をサーバ２００へ送信し、対戦支援部２１１は、該状況情報を他方のユーザ端末１００へ送信する。該他方のユーザ端末１００は、受信した状況情報に基づいて、ＣＰＵ戦で進行した部分を更新する。

また、この例において、最大待機時間が経過する前に、サーバ２００がサーバダウンから復帰した場合であっても、最大待機時間が経過するまでの間にユーザおよび相手ユーザがいずれも対戦再開操作を入力部１５１に入力しない場合、対戦進行部１１５は、無効試合として対戦を終了させてもよい。

また、この例において、最大待機時間が経過する前にサーバ２００がサーバダウンから復帰し、かつ、最大待機時間が経過するまでの間にユーザのみが対戦再開操作を入力部１５１に入力した場合、対戦進行部１１５は、ＣＰＵ戦を継続し、該ＣＰＵ戦の終了後、該ＣＰＵ戦の結果に応じて連勝数を更新してもよい。対戦進行部１１５は、該ＣＰＵ戦の結果を示す情報を、サーバ２００を介して相手ユーザのユーザ端末１００へ送信する。相手ユーザのユーザ端末１００は、受信した情報に基づいて連勝数を更新する。

また、最大待機時間が経過する前にサーバ２００がサーバダウンから復帰した場合であっても、最大待機時間が経過するまでの間にユーザおよび相手ユーザの少なくとも一方が対戦再開操作を入力部１５１に入力しない場合、対戦進行部１１５は、対人対戦を終了させてもよい。換言すれば、対戦進行部１１５は、ユーザおよび相手ユーザの両方が、最大待機時間が経過するまでに対戦再開操作を入力部１５１に入力しない限り、対人対戦を終了させてもよい。

ユーザ端末１００は、サーバ２００がサーバダウンから復帰したことを検出した場合、プッシュ通知によりサーバ２００の復帰をユーザに通知してもよい。このような構成とすることで、ユーザは、本野球ゲームのアプリケーションを起動し続けておく必要が無くなる。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック、ならびに、制御部１１０の制御ブロックは、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

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

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

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

（項目１） ゲームプログラムについて説明した。本開示のある局面によると、ゲームプログラム（１３１）は、プロセッサ（１０）を備えるコンピュータ（ユーザ端末１００）により実行される。ゲームプログラムは、プロセッサに、コンピュータに対するユーザの入力と、コンピュータとサーバ（２００）との間の通信とに基づいて、ユーザと対戦相手との対戦を進行させるステップと、対戦の進行中に通信が不可能となる第１エラーがサーバに発生したことを検出するステップと（ステップＳ９０１）、第１エラーがサーバに発生したことに応じて、対戦を無効とするステップと（ステップＳ９０６）、対戦が無効とされなかった場合、対戦の進行に応じて対戦の結果を決定するステップと、対戦が無効とされた場合、ユーザが前記対戦に勝利できなかったことに応じて前記ユーザの不利益になるように更新される第１パラメータを更新しない一方、対戦の結果が決定された場合、対戦の結果に基づいて、第１パラメータを更新するステップ（ステップＳ７０３、Ｓ７０８、Ｓ９０６）と、を実行させる。

（項目２） （項目１）において、ゲームプログラムは、プロセッサに、第１エラーがサーバに発生したことに応じて対戦を中断するステップ（ステップＳ９０３）をさらに実行させる。無効とするステップでは、第１エラーがサーバに発生してから第１時間が経過するまでに対戦が再開されなかったことに応じて、前記対戦を無効とする。

（項目３） （項目２）において、対戦は、ユーザと、１以上の他のコンピュータ（ユーザ端末１００）を操作する１以上の相手ユーザとの、サーバを介した、各コンピュータ間の通信に基づく対戦である。ゲームプログラムは、プロセッサに、サーバにおいて第１エラーが解消されたことを検出するステップ（ステップＳ９０４）と、第１エラーがサーバに発生してから第１時間が経過する前に第１エラーが解消され、かつ、第１時間が経過する前にユーザおよび相手ユーザの少なくとも一方が対戦を再開させる第１の入力を行ったことに応じて、対戦を再開するステップ（ステップＳ９１１）と、をさらに実行させる。

（項目４） （項目３）において、再開するステップでは、第１時間が経過する前に、ユーザおよび相手ユーザの一方が第１の入力を行うとともに他方が第１の入力を行わなかったことに応じて、対戦を、他方の操作入力無しで進行する第１モードで再開する。

（項目５） （項目３）または（項目４）において、再開するステップでは、対戦の中断分を自動的に進行させてから、対戦を再開する。

（項目６） （項目３）から（項目５）のいずれか１項目において、再開するステップでは、対戦を中断させてから再開させるまでに要した時間に基づいて決定した進行量で、対戦の中断分を自動的に進行させる。

（項目７） （項目２）から（項目６）のいずれか１項目において、ゲームプログラムは、プロセッサに、サーバにおいて第１エラーが解消されたことを検出するステップ（Ｓ９０４）をさらに実行させる。無効とするステップでは、第１エラーがサーバに発生してから第１時間が経過するまでの間に第１エラーが解消されなかったこと、または、第１エラーがサーバに発生してから第１時間が経過する前に第１エラーが解消された場合であっても、第１時間が経過するまでの間に対戦を再開させる第１の入力が行われなかったことに応じて、対戦を無効とする。

（項目８） （項目２）から（項目７）までのいずれか１項目において、ゲームプログラムは、プロセッサに、サーバに第１エラーが発生した場合、対戦の状況に基づいて、第１時間の長さを決定するステップ（ステップＳ９０２）をさらに実行させる。

（項目９） （項目８）において、進行させるステップでは、複数のフェーズから構成される対戦を進行させる。決定するステップでは、サーバに第１エラーが発生した時点が含まれる第１フェーズが、複数のフェーズの何れであるかに応じて第１時間の長さを決定する。

（項目１０） （項目９）において、決定するステップでは、第１フェーズが対戦の終盤のフェーズである場合、第１フェーズが対戦の序盤のフェーズである場合と比べて、第１時間の長さを長くする。

（項目１１） （項目９）または（項目１０）において、進行させるステップでは、対戦として、野球の試合を進行させる。決定するステップでは、第１フェーズとしての、サーバに第１エラーが発生した時点のイニングが、１回から最終回までの何れであるかに応じて第１時間の長さを決定する。

（項目１２） （項目１）から（項目１１）のいずれか１項目において、ゲームプログラムは、プロセッサに、対戦の進行中に、サーバを原因としない、対戦の進行に必要な通信が不可能となる第２エラーが発生したことを検出するステップ（ステップＳ１５０１）をさらに実行させる。無効とするステップでは、第２エラーがサーバに発生したことに応じて、対戦を無効としない。

（項目１３） （項目１２）において、ゲームプログラムは、プロセッサに、第２エラーが発生したことに応じて対戦を中断するステップ（ステップＳ１５０２）をさらに実行させる。決定するステップでは、第２エラーが発生してから第２時間が経過するまでに第２エラーが解消されなかった場合、対戦の中断時点における状況に基づいて、対戦の結果を決定する。

（項目１４） （項目１）から（項目１３）までのいずれか１項目において、ゲームプログラムは、プロセッサに、ユーザが対戦に勝利したことに応じて更新された第１パラメータが第１条件を満たした場合、ゲーム内で利用できる報酬をユーザに付与するステップ（ステップＳ７０５，Ｓ７０７）をさらに実行させる。

（項目１５） （項目１４）において、第１パラメータは、ユーザが目下連続して勝利している対戦の数を示す連勝数である。付与するステップでは、第１条件として、連勝数が複数の第１閾値のいずれかに到達した場合、報酬をユーザに付与し、連勝数がより高い第１閾値に到達した場合、ゲーム内における価値がより高い報酬を付与する。

（項目１６） 情報処理装置について説明した。本開示のある局面によると、情報処理装置（ユーザ端末１００）は、ゲームプログラム（１３１）を記憶する記憶部（１２０）と、ゲームプログラムを実行することにより、情報処理装置の動作を制御する制御部（１１０）と、を備える。制御部は、情報処理装置に対するユーザの入力と、情報処理装置とサーバ（２００）との間の通信とに基づいて、ユーザと対戦相手との対戦を進行させ、対戦の進行中に通信が不可能となる第１エラーがサーバに発生したことを検出し、第１エラーがサーバに発生したことに応じて、対戦を無効とし、対戦が無効とされなかった場合、対戦の進行に応じて対戦の結果を決定し、対戦が無効とされた場合、ユーザが対戦に勝利できなかったことに応じてユーザの不利益になるように更新される第１パラメータを更新しない一方、対戦の結果が決定された場合、対戦の結果に基づいて、第１パラメータを更新する。

（項目１３） ゲームプログラムを実行する方法について説明した。本開示のある局面によると、ゲームプログラム（１３１）は、プロセッサ（１０）を備えるコンピュータ（ユーザ端末１００）により実行される。方法は、プロセッサが、コンピュータに対するユーザの入力と、コンピュータとサーバ（２００）との間の通信とに基づいて、ユーザと対戦相手との対戦を進行させるステップと、対戦の進行中に通信が不可能となる第１エラーがサーバに発生したことを検出するステップと（ステップＳ９０１）、第１エラーがサーバに発生したことに応じて、対戦を無効とするステップと（ステップＳ９０６）、対戦が無効とされなかった場合、対戦の進行に応じて対戦の結果を決定するステップと、対戦が無効とされた場合、ユーザが前記対戦に勝利できなかったことに応じて前記ユーザの不利益になるように更新される第１パラメータを更新しない一方、対戦の結果が決定された場合、対戦の結果に基づいて、第１パラメータを更新するステップ（ステップＳ７０３、Ｓ７０８、Ｓ９０６）と、を含む。

１ ゲームシステム、２ ネットワーク、１０，２０ プロセッサ、１１，２１ メモリ、１２，２２ ストレージ、１３，２３ 通信ＩＦ（操作部）、１４，２４ 入出力ＩＦ（操作部）、１５ タッチスクリーン（表示部、操作部）、１７ カメラ（操作部）、１８ 測距センサ（操作部）、１００ ユーザ端末（情報処理装置）、１１０，２１０ 制御部、１１１ 操作受付部、１１２ 表示制御部、１１３ ＵＩ制御部、１１４ アニメーション生成部、１１５ 対戦進行部、１１６ 時間計測部、１２０，２２０ 記憶部、１３１，２３１ ゲームプログラム、１３２ ゲーム情報、１３３ ユーザ情報、１５１ 入力部（操作部）、１５２ 表示部、２００ サーバ、２１１ 対戦支援部、３１０ 対戦開始画面、３１１ 対戦開始ＵＩ、３１２，３１６ ＵＩ、３１３，３１５，３１７ テキスト、３１４ 対戦再開ＵＩ、６００ 投球画面、６０１ 打者キャラクタ、６０２ バット、６０３ 投手キャラクタ、６０４ ボール、６０５ 捕手キャラクタ、６０７ ホームベース、６１０ 球種指定オブジェクト、６１１，６１２，７０８，７０９ ステータス情報、６１３ 切換ボタン、６３１ イニング情報、６３２走者情報、６３３ 得点情報、６３４ カウント情報、７００ 打撃画面、７０１ ストライクゾーン、７０２ ボールゾーン、７０３ タイミングヒントオブジェクト、７０４ ミートカーソル、７０５ 位置ヒントオブジェクト、７０６ 方向ヒントオブジェクト、１０１０ 物体、１０２０ コントローラ（操作部）、１０３０ 記憶媒体

Claims (17)

1. プロセッサを備えたコンピュータにより実行されるゲームプログラムであって、
   前記ゲームプログラムは、前記プロセッサに、
   前記コンピュータに対するユーザの入力と、前記コンピュータとサーバとの間の通信とに基づいて、前記ユーザと対戦相手との対戦を進行させるステップと、
   前記対戦の進行中に前記通信が不可能となる第１エラーが前記サーバに発生したことを検出するステップと、
   前記第１エラーが前記サーバに発生したことに応じて、前記対戦を無効とするステップと、
   前記対戦が無効とされなかった場合、前記対戦の進行に応じて前記対戦の結果を決定するステップと、
   前記対戦が無効とされた場合、前記ユーザが前記対戦に勝利できなかったことに応じて前記ユーザの不利益になるように更新される第１パラメータを更新しない一方、前記対戦の結果が決定された場合、前記対戦の結果に基づいて、前記第１パラメータを更新するステップと、を実行させるためのプログラム。
2. 前記ゲームプログラムは、前記プロセッサに、前記第１エラーが前記サーバに発生したことに応じて前記対戦を中断するステップをさらに実行させ、
   前記無効とするステップでは、前記第１エラーが前記サーバに発生してから第１時間が経過するまでに前記対戦が再開されなかったことに応じて、前記対戦を無効とする、請求項１に記載のゲームプログラム。
3. 前記対戦は、前記ユーザと、１以上の他のコンピュータを操作する１以上の相手ユーザとの、前記サーバを介した、各コンピュータ間の通信に基づく対戦であり、
   前記ゲームプログラムは、前記プロセッサに、
   前記サーバにおいて前記第１エラーが解消されたことを検出するステップと、
   前記第１エラーが前記サーバに発生してから前記第１時間が経過する前に前記第１エラーが解消され、かつ、前記第１時間が経過する前に前記ユーザおよび前記相手ユーザの少なくとも一方が前記対戦を再開させる第１の入力を行ったことに応じて、前記対戦を再開するステップと、をさらに実行させる、請求項２に記載のゲームプログラム。
4. 前記再開するステップでは、前記第１時間が経過する前に、前記ユーザおよび前記相手ユーザの一方が前記第１の入力を行うとともに他方が前記第１の入力を行わなかったことに応じて、前記対戦を、前記他方の操作入力無しで進行する第１モードで再開する、請求項３に記載のゲームプログラム。
5. 前記再開するステップでは、前記対戦の中断分を自動的に進行させてから、前記対戦を再開する、請求項３または４に記載のゲームプログラム。
6. 前記再開するステップでは、前記対戦を中断させてから再開させるまでに要した時間に基づいて決定した進行量で、前記対戦の中断分を自動的に進行させる、請求項３から５のいずれか１項に記載のゲームプログラム。
7. 前記ゲームプログラムは、前記プロセッサに、前記サーバにおいて前記第１エラーが解消されたことを検出するステップをさらに実行させ、
   前記無効とするステップでは、前記第１エラーが前記サーバに発生してから前記第１時間が経過するまでの間に前記第１エラーが解消されなかったこと、または、前記第１エラーが前記サーバに発生してから前記第１時間が経過する前に前記第１エラーが解消された場合であっても、前記第１時間が経過するまでの間に前記対戦を再開させる第１の入力が行われなかったことに応じて、前記対戦を無効とする、請求項２から６のいずれか１項に記載のゲームプログラム。
8. 前記ゲームプログラムは、前記プロセッサに、前記サーバに前記第１エラーが発生した場合、前記対戦の状況に基づいて、前記第１時間の長さを決定するステップをさらに実行させる、請求項２から７のいずれか１項に記載のゲームプログラム。
9. 前記進行させるステップでは、複数のフェーズから構成される前記対戦を進行させ、
   前記決定するステップでは、前記サーバに前記第１エラーが発生した時点が含まれる第１フェーズが、前記複数のフェーズの何れであるかに応じて前記第１時間の長さを決定する、請求項８に記載のゲームプログラム。
10. 前記決定するステップでは、前記第１フェーズが前記対戦の終盤のフェーズである場合、前記第１フェーズが前記対戦の序盤のフェーズである場合と比べて、前記第１時間の長さを長くする、請求項９に記載のゲームプログラム。
11. 前記進行させるステップでは、前記対戦として、野球の試合を進行させ、
    前記決定するステップでは、前記第１フェーズとしての、前記サーバに前記第１エラーが発生した時点のイニングが、１回から最終回までの何れであるかに応じて前記第１時間の長さを決定する、請求項９または１０に記載のゲームプログラム。
12. 前記ゲームプログラムは、前記プロセッサに、前記対戦の進行中に、前記サーバを原因としない、前記対戦の進行に必要な通信が不可能となる第２エラーが発生したことを検出するステップをさらに実行させ、
    前記無効とするステップでは、前記第２エラーが前記サーバに発生したことに応じて、前記対戦を無効としない、請求項１から１１のいずれか１項に記載のゲームプログラム。
13. 前記ゲームプログラムは、前記プロセッサに、前記第２エラーが発生したことに応じて前記対戦を中断するステップをさらに実行させ、
    前記決定するステップでは、前記第２エラーが発生してから第２時間が経過するまでに前記第２エラーが解消されなかった場合、前記対戦の中断時点における状況に基づいて、前記対戦の結果を決定する、請求項１２に記載のゲームプログラム。
14. 前記ゲームプログラムは、前記プロセッサに、前記ユーザが前記対戦に勝利したことに応じて更新された前記第１パラメータが第１条件を満たした場合、ゲーム内で利用できる報酬を前記ユーザに付与するステップをさらに実行させる、請求項１から１３のいずれか１項に記載のゲームプログラム。
15. 前記第１パラメータは、前記ユーザが目下連続して勝利している前記対戦の数を示す連勝数であり、
    前記付与するステップでは、
    前記第１条件として、前記連勝数が複数の第１閾値のいずれかに到達した場合、前記報酬を前記ユーザに付与し、
    前記連勝数がより高い前記第１閾値に到達した場合、前記ゲーム内における価値がより高い報酬を付与する、請求項１４に記載のゲームプログラム。
16. 情報処理装置であって、
    前記情報処理装置は、
    ゲームプログラムを記憶する記憶部と、
    前記ゲームプログラムを実行することにより、前記情報処理装置の動作を制御する制御部と、を備え、
    前記制御部は、
    前記情報処理装置に対するユーザの入力と、前記情報処理装置とサーバとの間の通信とに基づいて、前記ユーザと対戦相手との対戦を進行させ、
    前記対戦の進行中に前記通信が不可能となる第１エラーが前記サーバに発生したことを検出し、
    前記第１エラーが前記サーバに発生したことに応じて、前記対戦を無効とし、
    前記対戦が無効とされなかった場合、前記対戦の進行に応じて前記対戦の結果を決定し、
    前記対戦が無効とされた場合、前記ユーザが前記対戦に勝利できなかったことに応じて前記ユーザの不利益になるように更新される第１パラメータを更新しない一方、前記対戦の結果が決定された場合、前記対戦の結果に基づいて、前記第１パラメータを更新する、情報処理装置。
17. プロセッサを備えたコンピュータがゲームプログラムを実行する方法であって、
    前記方法は、前記プロセッサが、
    前記コンピュータに対するユーザの入力と、前記コンピュータとサーバとの間の通信とに基づいて、前記ユーザと対戦相手との対戦を進行させるステップと、
    前記対戦の進行中に前記通信が不可能となる第１エラーが前記サーバに発生したことを検出するステップと、
    前記第１エラーが前記サーバに発生したことに応じて、前記対戦を無効とするステップと、
    前記対戦が無効とされなかった場合、前記対戦の進行に応じて前記対戦の結果を決定するステップと、
    前記対戦が無効とされた場合、前記ユーザが前記対戦に勝利できなかったことに応じて前記ユーザの不利益になるように更新される第１パラメータを更新しない一方、前記対戦の結果が決定された場合、前記対戦の結果に基づいて、前記第１パラメータを更新するステップと、を含む、方法。

Images