〔実施形態1〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<ゲームシステム1のハードウェア構成>
図1は、ゲームシステム1のハードウェア構成を示す図である。ゲームシステム1は図示の通り、複数のユーザ端末100と、サーバ200とを含む。各ユーザ端末100は、サーバ200とネットワーク2を介して接続する。ネットワーク2は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂3G、4G移動通信システム、LTE(Long Term Evolution)、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク(例えばWi-Fi(登録商標))等が挙げられる。
サーバ200(コンピュータ、情報処理装置)は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ200は、プロセッサ20と、メモリ21と、ストレージ22と、通信IF23と、入出力IF24とを備える。サーバ200が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
ユーザ端末100(コンピュータ、情報処理装置)は、スマートフォン、フィーチャーフォン、PDA(Personal Digital Assistant)、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末100は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末100は図示の通り、プロセッサ10と、メモリ11と、ストレージ12と、通信インターフェース(IF)13と、入出力IF14と、タッチスクリーン15(表示部)と、カメラ17と、測距センサ18とを備える。ユーザ端末100が備えるこれらの構成は、通信バスによって互いに電気的に接続される。また、図1に示すように、ユーザ端末100は、1つ以上のコントローラ1020と通信可能に構成されることとしてもよい。コントローラ1020は、例えば、Bluetooth(登録商標)等の通信規格に従って、ユーザ端末100と通信を確立する。コントローラ1020は、1つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末100へ送信する。また、コントローラ1020は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末100へ送信する。
なお、ユーザ端末100がカメラ17および測距センサ18を備えることに代えて、または、加えて、コントローラ1020がカメラ17および測距センサ18を有していてもよい。
ユーザ端末100は、例えばゲーム開始時に、コントローラ1020を使用するユーザに、該ユーザの名前またはログインID等のユーザ識別情報を、該コントローラ1020を介して入力させることが望ましい。これにより、ユーザ端末100は、コントローラ1020とユーザとを紐付けることが可能となり、受信した出力値の送信元(コントローラ1020)に基づいて、該出力値がどのユーザのものであるかを特定することができる。
ユーザ端末100が複数のコントローラ1020と通信する場合、各コントローラ1020を各ユーザが把持することで、ネットワーク2を介してサーバ200などの他の装置と通信せずに、該1台のユーザ端末100でマルチプレイを実現することができる。また、各ユーザ端末100が無線LAN(Local Area Network)規格等の無線規格により互いに通信接続する(サーバ200を介さずに通信接続する)ことで、複数台のユーザ端末100によりローカルでマルチプレイを実現することもできる。1台のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、ユーザ端末100は、さらに、サーバ200が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末100は、サーバ200が備える後述する種々の機能を分散して備えていてもよい。
なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末100はサーバ200と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ200に送信してもよい。
また、コントローラ1020は、ユーザ端末100に着脱可能な構成であるとしてもよい。この場合、ユーザ端末100の筐体における少なくともいずれかの面に、コントローラ1020との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末100とコントローラ1020とが結合している場合は、ユーザ端末100とコントローラ1020とは、有線を介して信号を送受信する。
図1に示すように、ユーザ端末100は、外部のメモリカード等の記憶媒体1030の装着を、入出力IF14を介して受け付けてもよい。これにより、ユーザ端末100は、記憶媒体1030に記録されるプログラム及びデータを読み込むことができる。記憶媒体1030に記録されるプログラムは、例えばゲームプログラムである。
ユーザ端末100は、サーバ200等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末100のメモリ11に記憶してもよいし、記憶媒体1030から読み込むことにより取得したゲームプログラムをメモリ11に記憶してもよい。
以上で説明したとおり、ユーザ端末100は、該ユーザ端末100に対して情報を入力する機構の一例として、通信IF13、入出力IF14、タッチスクリーン15、カメラ17、および、測距センサ18を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
例えば、操作部が、カメラ17および測距センサ18の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末100の近傍の物体1010を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体1010としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体1010の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末100は、カメラ17の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ(ユーザの手の一連の動き)を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。
あるいは、操作部がタッチスクリーン15で構成される場合、ユーザ端末100は、タッチスクリーン15の入力部151に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF13で構成される場合、ユーザ端末100は、コントローラ1020から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF14で構成される場合、該入出力IF14と接続されるコントローラ1020とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<ゲーム概要>
ゲームシステム1は、一方のコンピュータを操作するユーザと、他方のコンピュータを操作する対戦相手としての相手ユーザとを、前記各コンピュータ間の通信を介して対戦させる通信対戦ゲームを実行するためのシステムである。
該通信対戦ゲームの題材またはジャンルは特に限定されない。該通信対戦ゲームは、例えば、テニス、卓球、ドッジボール、野球、サッカー、ホッケー等のスポーツを題材としたゲームであってもよい。該通信対戦ゲームは、スポーツを題材としたゲーム以外にも、例えば、パズルゲーム、クイズゲーム、RPG、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、アクションゲームなどにおいて、通信対戦の要素を含むゲームであってもよい。
本実施形態では、一例として、ゲームシステム1は、ユーザが操作する1以上のキャラクタが属する自チームと、相手ユーザが操作する1以上のキャラクタが属する相手チームとを対戦させる通信対戦野球ゲームを実行するためのシステムである。ゲームシステム1では、ユーザは、コンピュータを用いて、自チームに属するキャラクタを操作する。上述の相手ユーザは、上述の相手チームに属するキャラクタを、上述のコンピュータと通信可能な、別のコンピュータを用いて操作する。ゲームシステム1において実行される通信対戦野球ゲームのゲームプログラムは、ユーザが操作する一方のコンピュータ、および、相手ユーザが操作する他方のコンピュータのうち、少なくともいずれか1つにより実行される。
一例として、通信対戦野球ゲームが実行されるゲームシステム1において、サーバ200を介して通信する第1のユーザ端末100と第2のユーザ端末100とによって、それぞれのチームが操作される。そして、通信対戦野球ゲームは、1イニングにつき、表と裏でチームの攻守が入れ替わりつつ進行する。以下では、あるイニングの表または裏において、守備側のチームを操作するユーザ端末100と、攻撃側のユーザ端末100とを互いに区別する必要がある場合、前者を投球側ユーザ端末100A、後者を打撃側ユーザ端末100Bと称する。両者を区別する必要がない場合には、単に、ユーザ端末100と称する。投球側ユーザ端末100Aのユーザを、投球側ユーザ、打撃側ユーザ端末100Bのユーザを、打撃側ユーザと称する。ただし、両ユーザを特に区別する必要がない場合、および、その区別が明らかな場合には、単にユーザと称する。投球側ユーザは、投球側ユーザ端末100Aを用いて、投手キャラクタによる投球を操作し、打撃側ユーザは、打撃側ユーザ端末100Bを用いて、打者キャラクタによる打撃を操作する。
投球側ユーザ端末100Aは、投球側ユーザから受け付けた投球操作に応じて投球結果を決定し、該投球結果を含むデータ(図1に示す投球結果D1)を生成し、サーバ200に送信する。投球結果D1は、サーバ200を介して、対戦相手の打撃側ユーザ端末100Bに送信される。投球操作とは、投球側ユーザが、投手キャラクタに投球させるために、投球側ユーザ端末100Aの入力部151に対して実施する操作のことである。
打撃側ユーザ端末100Bは、打撃側ユーザから受け付けた打撃操作に応じて打撃結果を決定し、該打撃結果を含むデータ(図1に示す打撃結果D2)を生成し、サーバ200に送信する。打撃結果D2は、サーバ200を介して、対戦相手の投球側ユーザ端末100Aに送信される。打撃操作とは、打撃側ユーザが、打者キャラクタにボールを打撃させるために、打撃側ユーザ端末100Bの入力部151に対して実施する操作のことである。
本実施形態に係る通信対戦野球ゲームにおいて、対戦に参加しているユーザ端末100のそれぞれは、投球結果D1と、打撃結果D2とに基づいて、対戦会場としての球場を模して定義された仮想空間についての計算を実行し、対戦を進行させる。投球結果D1および打撃結果D2は、一方が、自端末において生成されたものであり、他方が、相手ユーザが操作するユーザ端末100において生成されたものである。仮想空間についての計算には、例えば、投球されたボールの移動経路、振られたバットの位置、および、打撃後のボールの飛翔経路などを計算する処理、および、バットがボールに当たったか否か判定する処理などが含まれる。さらに、フィールドに配置されている選手キャラクタの動きとボールの位置とを計算して、フィールドプレイを再現する処理なども、仮想空間についての計算に含まれる。
上述のとおり、ユーザ端末100(コンピュータ)は、投球結果D1と打撃結果D2とに基づいて、対戦を進行させる機能を備えている。また、ユーザ端末100は、該対戦の進行状況を示す状況情報D3を、サーバ200を介して、対戦相手のユーザ端末100に提供する機能を備えている。さらに、ユーザ端末100は、対戦相手のユーザ端末100から提供された状況情報D4を取得し、自端末で生成した状況情報D3と比較することにより同期ずれを検出する機能を備えている。さらに、ユーザ端末100は、同期ずれが解消されるまでの期間、ユーザに情報を提示して、ユーザのストレスを解消または低減するユーザインターフェース(以下、UI)を備えている。サーバ200は、対戦に参加している各ユーザのストレスを解消または低減する方法にて、同期ずれを解消する機能を備えている。本実施形態に係る各装置の上述の各構成については、以下で詳細に説明する。
<各装置のハードウェア構成要素>
プロセッサ10は、ユーザ端末100全体の動作を制御する。プロセッサ20は、サーバ200全体の動作を制御する。プロセッサ10および20は、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、およびGPU(Graphics Processing Unit)を含む。
プロセッサ10は後述するストレージ12からプログラムを読み出し、後述するメモリ11に展開する。プロセッサ20は後述するストレージ22からプログラムを読み出し、後述するメモリ21に展開する。プロセッサ10およびプロセッサ20は展開したプログラムを実行する。
メモリ11および21は主記憶装置である。メモリ11および21は、ROM(Read Only Memory)およびRAM(Random Access Memory)等の記憶装置で構成される。メモリ11は、プロセッサ10が後述するストレージ12から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ10に作業領域を提供する。メモリ11は、プロセッサ10がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ21は、プロセッサ20が後述するストレージ22から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ20に作業領域を提供する。メモリ21は、プロセッサ20がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
本実施形態においてプログラムとは、ゲームをユーザ端末100により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末100とサーバ200との協働により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末100の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末100とサーバ200との間または複数のユーザ端末100間で送受信する指示または通知を含んでいる。
ストレージ12および22は補助記憶装置である。ストレージ12および22は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12およびストレージ22には、ゲームに関する各種データが格納される。
通信IF13は、ユーザ端末100における各種データの送受信を制御する。通信IF23は、サーバ200における各種データの送受信を制御する。通信IF13および23は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
入出力IF14は、ユーザ端末100がデータの入力を受け付けるためのインターフェースであり、またユーザ端末100がデータを出力するためのインターフェースである。入出力IF14は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14は、例えば、ユーザ端末100の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ200の入出力IF24は、サーバ200がデータの入力を受け付けるためのインターフェースであり、またサーバ200がデータを出力するためのインターフェースである。入出力IF24は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
ユーザ端末100のタッチスクリーン15は、入力部151と表示部152とを組み合わせた電子部品である。入力部151は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
入力部151は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。
図示していないが、ユーザ端末100は、該ユーザ端末100の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末100がセンサを備えている場合、プロセッサ10は、センサの出力からユーザ端末100の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10は、ユーザ端末100が縦向きに保持されているときには、縦長の画像を表示部152に表示させる縦画面表示としてもよい。一方、ユーザ端末100が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10は、ユーザ端末100の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
カメラ17は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。
測距センサ18は、測定対象物までの距離を測定するセンサである。測距センサ18は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ18は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ18は、指向性を有する光を発する光源を有することとしてもよい。
ここで、ユーザ端末100が、カメラ17と測距センサ18とを用いて、ユーザ端末100の近傍の物体1010を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ17および測距センサ18は、例えば、ユーザ端末100の筐体の側面に設けられてもよい。カメラ17の近傍に測距センサ18が設けられてもよい。カメラ17としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ17に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ17の撮影画像に基づく物体の検出精度をいっそう向上させることができる。
プロセッサ10は、カメラ17の撮影画像に対して、例えば以下の(1)〜(5)に示す処理のうち1つ以上の処理を行ってもよい。(1)プロセッサ10は、カメラ17の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ10は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。(2)また、プロセッサ10は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ10は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数(伸びている指の本数)を特定する。プロセッサ10はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ10は、指の本数が5本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が0本である(指が検出されなかった)場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が2本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。(3)プロセッサ10は、カメラ17の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。(4)プロセッサ10は、カメラ17の撮影画像の画像認識結果、および、測距センサ18の出力値等の少なくともいずれか1つに基づいて、ユーザ端末100の近傍の物体1010(ユーザの手など)とユーザ端末100との距離を検出する。例えば、プロセッサ10は、カメラ17の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末100の近傍(例えば所定値未満の距離)にあるのか、遠く(例えば所定値以上の距離)にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ10は、ユーザの手がユーザ端末100に接近しているのか遠ざかっているのかを検出してもよい。(5)カメラ17の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末100とユーザの手との距離が変化していることが判明した場合、プロセッサ10は、ユーザが手をカメラ17の撮影方向において振っていると認識する。カメラ17の撮影範囲よりも指向性が強い測距センサ18において、物体が検出されたりされなかったりする場合に、プロセッサ10は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。
このように、プロセッサ10は、カメラ17の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か(「グー」のジェスチャであるか、それ以外のジェスチャ(例えば「パー」)であるか)を検出する。また、プロセッサ10は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ10は、ユーザがこの手をユーザ端末100に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末100は、例えば、ユーザの手の移動に応じて、タッチスクリーン15においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末100は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末100は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作(またはドラッグ操作)に対応する操作として認識することもできる。また、ユーザ端末100は、カメラ17の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。
<ゲームシステム1の機能的構成>
図2は、ゲームシステム1に含まれるサーバ200およびユーザ端末100の機能的構成を示すブロック図である。サーバ200およびユーザ端末100のそれぞれが備えている、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成については、適宜省略している。
ユーザ端末100(コンピュータ、情報処理装置、クライアント)は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像または音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、および入出力IF14等の協働によって、制御部110および記憶部120として機能する。
サーバ200は、各ユーザ端末100と通信して、ユーザ端末100が通信対戦ゲームを進行させるのを支援する機能を有する。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部220として機能する。
記憶部120および記憶部220は、ゲームプログラム131、ゲーム情報132およびユーザ情報133を格納する。ゲームプログラム131は、ユーザ端末100およびサーバ200で実行するゲームプログラムである。ゲーム情報132は、制御部110および制御部210がゲームプログラム131を実行する際に参照するデータである。ユーザ情報133は、ユーザのアカウントに関するデータである。記憶部220において、ゲーム情報132およびユーザ情報133は、ユーザ端末100ごとに格納されている。
(サーバ200の機能的構成)
制御部210は、記憶部220に格納されたゲームプログラム131を実行することにより、サーバ200を統括的に制御する。例えば、制御部210は、ユーザ端末100に各種データおよびプログラム等を送信する。制御部210は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末100から受信する。ゲームがマルチプレイゲームである場合には、制御部210は、ユーザ端末100からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末100に送信してもよい。
制御部210は、ゲームプログラム131の記述に応じて、対戦支援部211として機能する。制御部210は、実行するゲームの性質に応じて、ユーザ端末100におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。
対戦支援部211は、各ユーザ端末100が通信対戦ゲームを進行させるのを支援する。具体的には、対戦支援部211は、対戦する各ユーザ端末100と通信して、ユーザ端末100同士のやりとりを仲介する。さらに、対戦支援部211は、対戦相手のマッチング、対戦の進行状況の同期をとるための同期制御などを実行する。
(ユーザ端末100の機能的構成)
制御部110は、記憶部120に格納されたゲームプログラム131を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム131およびユーザの操作にしたがって、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。
制御部110は、ゲームプログラム131の記述に応じて、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、および、対戦進行部115として機能する。制御部110は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。
操作受付部111は、入力部151に対するユーザの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
例えば、操作受付部111は、入力部151に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部111は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部111は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
UI制御部113は、UIを構築するために表示部152に表示させるUIオブジェクトを制御する。UIオブジェクトは、ユーザが、ゲームの進行上必要な入力をユーザ端末100に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末100から得るためのツールである。UIオブジェクトは、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面、および、ユーザへ提供されるメッセージを含むテキストまたは画像などである。
さらに、UI制御部113は、対戦進行中、対戦進行部115と連携して、投球側ユーザによる投球操作を支援するためのUIオブジェクト、または、打撃側ユーザによる打撃操作を支援するためのUIオブジェクトの表示態様を制御する。これらのUIオブジェクトについては、図5〜図9に基づいて、後に詳述する。
アニメーション生成部114は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。例えば、投手キャラクタの投球動作のアニメーション、打者キャラクタの打撃動作のアニメーション、該打者キャラクタが振るバットのアニメーション、投手キャラクタによって投げられたボールのアニメーション、打者キャラクタによって打たれたボールのアニメーション、走者キャラクタが盗塁するアニメーション等を生成してもよい。
表示制御部112は、タッチスクリーン15の表示部152に対して、上述の各要素によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部112は、アニメーション生成部114によって生成されたアニメーションを含むゲーム画面を表示部152に表示してもよい。また、表示制御部112は、UI制御部113によって制御されている上述のUIオブジェクトを、該ゲーム画面に重畳して描画してもよい。
対戦進行部115は、サーバ200との間でデータの送受信を行って、相手ユーザとの対戦を進行させる。具体的には、ユーザ端末100を操作するユーザの操作にしたがって、対戦を進行させるとともに、該対戦の進行状況を、相手ユーザが操作する他のユーザ端末100との間で同期させるために必要な各処理を実行する。
一例として、対戦進行部115は、自身が進行させた対戦の進行状況を示す状況情報(以下、第1状況情報)を、該対戦の進行上の所定のタイミングで生成する。一方、相手ユーザが操作する他のユーザ端末100では、上述と同じタイミングにて、該他のユーザ端末100が、該対戦の進行状況を示す状況情報(以下、第2状況情報)を生成する。そこで、対戦進行部115は、第2状況情報を、サーバ200を介して、取得する。対戦進行部115は、表示制御部112を制御して、第1状況情報および第2状況情報のうち、一致しない状況情報がある場合に、同期ずれが発生したことを示す通知を表示部152に表示させる。また、対戦進行部115は、同期ずれが発生したことをサーバ200に通知する。
また、対戦進行部115は、UI制御部113およびアニメーション生成部114と連携して、ユーザが通信対戦野球ゲームをプレイするために必要な上述の各種UIを提供する。各種UIは、例えば、対戦進行部115が、UI制御部113に、UIオブジェクトを含むゲーム画面を生成させること、および、表示制御部112が、該ゲーム画面を表示部152に表示させることにより実現される。
なお、図2に示すサーバ200およびユーザ端末100の機能は一例にすぎない。サーバ200は、ユーザ端末100が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末100は、サーバ200が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該他の装置にゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
<対戦の進行>
図3は、本実施形態に係るゲームシステム1において、通信対戦野球ゲームのゲームプログラム131に基づいて進行される対戦(試合)を模式的に示す図である。本実施形態に係る通信対戦野球ゲームの対戦は、一例として、以下の要素で構成される。
この対戦が開始される前に、まず、複数のキャラクタから成るチームが編成される。ユーザは、ユーザ端末100を操作して、9名のキャラクタをポジションごとに選出することができる。こうして、自チームを編成する。相手ユーザも、同様に、自分のユーザ端末100を操作して、9名のキャラクタによるチーム(相手チーム)を編成する。
サーバ200は、ユーザ端末100からマッチング要求を受け付けると、同じくマッチング要求を受け付けた別のユーザ端末100の中から対戦相手を決定して、対戦の準備を整える。サーバ200により、マッチングが成立すると、以下のように、対戦が進行される。
図3に示すとおり、各ユーザ端末100の対戦進行部115によって進行される対戦は、複数の回(イニング)で構成される。本ゲームでは、1イニングにつき、表と裏でチームの攻守を入れ替え、各チームが1回ずつ守備と攻撃とを実施することにより、対戦が進行する。1イニングの表および裏のそれぞれは、複数の打席で構成され、攻撃側のキャラクタ1名につき1つの打席が対応付けられる。1つの打席は、守備側(投球側)のキャラクタと、攻撃側(打撃側)のキャラクタとが1対1で対決するキャラクタ対決シーンと、対決の結果を決定し、それをアニメーションによって描出して、該打席を完了させるフィールドプレイシーンとで構成される。
キャラクタ対決シーンは、さらに複数のフェーズに区切られる。フェーズは、対決する各キャラクタが、守備動作および攻撃動作のいずれか一方を、それぞれ所定回数行う期間である。1つのフェーズにおいて、守備側のキャラクタ(投手キャラクタ)、および、攻撃側のキャラクタ(打者キャラクタ)のそれぞれが動作を行う回数は、予め定められている。しかし、その回数は、ゲームの題材となる競技に基づいて任意に定められればよい。また、守備側と攻撃側とで、動作回数は同じに定められてもよいし、異なっていても構わない。本実施形態では、一例として、1つのフェーズにおいて、投手キャラクタが投球動作を1回、打者キャラクタが打撃動作を1回行うと定められているものとする。なお、本実施形態では、打撃動作には、バットを振らずに投球を見送る動作、バットにボールを当てられずに空振りする動作も含まれる。
フェーズは、いわば、対戦を構成する要素の最小単位であり、野球ゲームにおいては、投手キャラクタが投げる1球に相当する。1つのフェーズにおいて、投手キャラクタによって、1つの投球動作が実行され、打者キャラクタによって1つの打撃動作が実行されると、対戦進行部115は、1つのフェーズを完了させて、フィールドプレイシーンまたは次のフェーズに移行する。例えば、打者キャラクタがバットにボールを当てることができ、ボールに対して打撃が与えられた場合、対戦進行部115は、打撃された該ボールの飛翔経路を計算し、該ボールをフィールド上にて移動させるとともに、フィールドプレイシーンを進行させる。一方、打者キャラクタが空振りしたり見逃したりしてボールに対して打撃が与えられなかった場合、対戦進行部115は、当該フェーズを完了させて、状況情報を更新し、次のフェーズを進行させる。具体的には、対戦進行部115は、ホームベースの上あたりに仮想的に設定された、ストライクゾーンとボールゾーンとを含む交差面における投球の到達位置に基づいて、状況情報の1つであるボールカウントを更新する。例えば、投球がストライクゾーンに着弾すれば、ストライクのカウントを1つ増やし、ストライクゾーン以外に着弾すれば、ボールのカウントを1つ増やす。
1以上のフェーズの進行を経て、最新のフェーズまたはフィールドプレイシーンにおいて、対戦進行部115は、進行中の打席の結果を決定する。例えば、三振またはゴロなどにより1アウト、ヒットによる進塁、ホームランによる得点追加などが決定される。対戦進行部115は、これに伴い、上述の1つの打席を完了させて、次の打席を進行させる。つまり、1つの打席は、フィールドプレイシーンを経ずに終了することもあり得る。例えば、三振またはフォアボールのときは、複数のフェーズのみが進行されて1つの打席が完了する。
いくつかの打席の進行を経て、1つのイニングの表(または裏)において、3つのアウトが累積されると、対戦進行部115は、該1つのイニングの表(または裏)を完了させ、各チームの攻守を入れ替えて、同イニングの裏(または次のイニングの表)を進行させる。
一例として、本実施形態では、対戦を構成する上述の各要素のうち、フィールドプレイシーンは、ユーザの操作を受け付けることなく、対戦中の各ユーザ端末100が、ゲームプログラム131にしたがって、それぞれ、オートで進行させてもよい(オート進行)。一方、キャラクタ対決シーンの全フェーズは、ユーザが入力部151を介して実施する操作に基づいて、すなわち、マニュアル制御によって進行させることができる(マニュアル進行)。投球動作および打撃動作が1度ずつ行われる各フェーズは、対戦の勝敗を左右する重要な要素であり、対戦の大部分を占める要素である。したがって、ユーザの操作の巧拙が対戦の勝敗に大きな影響を与え、うまく操作したユーザが対戦を有利に進めることができる。
本実施形態では、ユーザは、フェーズごとに(一球ごとに)、希望する制御方法を切り替えることができてもよい。本実施形態では、ユーザ端末100は、制御方法の切り替え指示を随時ユーザから受け付け、受け付け直後に訪れるフェーズの開始時点で、指示された制御方法に設定する。例えば、ユーザは、ある一球については、ユーザが自身で投球操作を行って、投手キャラクタに投球動作を行わせ、次の一球については、サーバ200の制御下で、自動で投手キャラクタに投球動作を行わせるというように、プレイすることが可能である。
本実施形態では、対戦進行部115は、対戦の進行上の所定のタイミングで、周期的に状況情報を生成する。所定のタイミングは、一例として、対戦の各要素の区切りである。図3に示すとおり、所定のタイミングは、フェーズの区切り(t1〜t3など)であってもよいし、打席の区切り(tmなど)であってもよいし、攻守切り替え時(tnなど)であってもよいし、イニングの区切り(tp、tqなど)であってもよい。
状況情報は、対戦の進行状況を示す情報であり、特に対戦の勝敗を左右する重要な情報である。状況情報は、一例として、進行中のイニングを示す「イニング」、各チームの得点を示す「スコア」、走者が何塁にいるかを示す「ランナー」、「アウトカウント」、および、「ボールカウント」を含む。状況情報のデータ構造は、図4を参照しながら詳述する。
本実施形態では、対戦進行部115は、生成した第1状況情報を、サーバ200に送信するとともに、同じタイミングで生成された対戦相手のユーザ端末100で生成された第2状況情報を受信する。すなわち、対戦しているユーザ端末100同士が、互いに生成した状況情報を交換し合う。これにより、互いの状況情報が一致しているか否かを確認することができる。両者の状況情報の一致は、対戦の進行状況について同期がとれており、このまま対戦を進行させることができるということを意味する。
状況情報の交換を行うタイミング(以下、通信タイミング)は、状況情報を生成するタイミング(以下、生成タイミング)と同じであってもよい。あるいは、対戦進行部115は、状況情報の交換を、少なくともフィールドプレイシーンが完了した直後のタイミング(tmなど)において行うことが好ましい。
同期ずれは、フィールドプレイシーンで起こり得る。フィールドプレイシーンを進行させる処理は、多数のパラメータを参照し、複雑な計算を行う高負荷処理だからである。例えば、対戦進行部115は、フィールドプレイシーンを進行させるために以下の高負荷処理を実行する。バットで打撃されたボールの飛翔経路と飛翔速度とを計算して、仮想空間においてボールを移動させる。対戦進行部115は、ボールと野手キャラクタとの位置関係、および、野手キャラクタの守備に係る能力値に基づいて、ボールの捕球シーンおよび送球シーンを再現する。例えば、対戦進行部115は、野手キャラクタを移動させるためのアルゴリズムと、対戦進行部115により決定されるボールの移動経路とに応じて、野手キャラクタをフィールドにおいて移動させ、野手キャラクタにボールを捕球させる。対戦進行部115は、野手キャラクタがボールを捕球した際に、ランナーの出塁状況、アウトカウントの状況などに基づいて、ボールの送球先を決定する。対戦進行部115は、走者キャラクタの走力に係る能力値に基づいて、走塁シーンを再現する。対戦進行部115は、ボールの位置と、走者キャラクタとの位置関係に基づいてアウトかセーフかを判定する。
例えば、それぞれのユーザ端末100が把握している仮想空間において、塁を守る野手によってボールが捕球されたタイミングと、走者キャラクタの体の一部が塁に届いたタイミングとが、ほんの数フレームずれているだけでも、一方のユーザ端末100では、アウトと処理され、他方のユーザ端末100ではセーフと処理されるということが起こり得る。このように進行状況にずれが生じたままでは、これ以降対戦を進行させることができない。
上述の構成によれば、少なくとも、同期ずれが起こり得るフィールドプレイシーンの直後に、両者の状況情報を交換し、比較するので、同期ずれが起こったとしても、ただちにそれを検出し、対処することができる。このような同期制御を可能にするための、ゲームシステム1における情報処理および該情報処理で用いられるデータ構造の具体例を、以下で詳細に説明する。
フィールドプレイシーンの前後における、上述の情報処理およびデータ構造の具体例を説明する前に、まず、フィールドプレイシーンに移るまでの、ユーザ端末100の動作およびユーザインターフェースについて、図4〜図9に基づいて説明する。
<マッチング画面の例>
図4は、ユーザ端末の表示部に表示されるゲーム画面の一具体例を示す図である。具体的には、該ゲーム画面は、サーバ200においてマッチングが成立したとき、対戦が開始される直前に、ユーザ端末100の表示部152に表示されるマッチング画面500である。マッチング画面500は、UI制御部113が、対戦進行部115の指示にしたがって、必要な各種情報を組み合わせることにより生成される。
マッチング画面500は、サーバ200から提供された対戦に係る各種情報を、対戦開始前にユーザに提供するための画面である。一例として、マッチング画面500は、対戦開始のタイミングをユーザに知らせるためのカウントダウン520を含んでいてもよい。マッチング画面500は、ユーザ自身のユーザ名522、相手ユーザのユーザ名523、ユーザのレーティング524、および、相手ユーザのレーティング525を含んでいてもよい。その他、図示されていないが、該ゲーム画面は、例えば、自チームおよび相手チームにおける先発の投手キャラクタの情報を含んでいてもよい。
レーティングは、各ユーザに設定されている評価値を示す。評価値は、ユーザの実力を量るための指標である。一例として、評価値は、数値が多いほど実力が高い、すなわち、本ゲームが巧いことを意味する。本実施形態では、評価値の算定方法は、従来実施されている方法が採用されてもよい。例えば、ユーザが対戦に勝利すると、評価値は、所定値分加算され、敗北すると、所定値分減算される。加算または減算される所定値は、対戦開始時におけるユーザの評価値と、相手ユーザの評価値との差分に基づいて決定されてもよい。評価値の算定は、ユーザ端末100の対戦進行部115が実行してもよいし、サーバ200の対戦支援部211が実行してもよい。このレーティングを用いることにより、サーバ200は、実力に大きな開きがあるユーザ同士をマッチングすることを避け、できるだけ実力が拮抗するユーザ同士をマッチングさせることができる。
<投球画面の例>
図5〜図8は、ユーザ端末の表示部に表示されるゲーム画面の他の具体例を示す図である。具体的には、該ゲーム画面は、投手キャラクタの投球シーンを表す投球画面600である。投球画面600は、進行中のフェーズがマニュアル進行モードである場合に、投球側ユーザによる投球操作を受け付けるための、以下に説明する投球操作UIを含む。
本実施形態において、投球結果D1を決定するための投球操作には、一例として、球種を指定するためのスライド操作と、コースを指定するためのドラッグ操作と、制球の良否を決定するためのタイミングを投球側ユーザに指定させるタップ操作とが含まれる。第2タップ操作の入力タイミングの良否に応じて、投球の良否が決定される。つまり、投球側ユーザにとって、対戦、特に、守備の回を有利に進めることができるか否かは、マニュアル進行モードの場合、タップ操作の巧拙にかかっている。
1つのフェーズが開始されると、投球側ユーザ端末100Aの対戦進行部115は、まず、図5に示す第1の投球画面600を、UI制御部113に生成させて、表示部152に表示させる。
第1の投球画面600は、仮想空間に配置されている各種オブジェクトを含む。具体的には、相手ユーザが操作する打者キャラクタ601、バット602、ユーザ自身が操作する投手キャラクタ603、ホームベース607、および、捕手キャラクタ605を含む。
第1の投球画面600は、次のフェーズをオート進行またはマニュアル進行に切り替えるための切替ボタン613を含んでいてもよい。図5に示す例では、該フェーズは、マニュアルモードにて進行している。そのため、切替ボタン613は、次のフェーズをオート進行に切り替えるためのボタンとして投球画面600に重畳表示されている。
第1の投球画面600は、該フェーズにおいて対決中の各キャラクタのステータス情報を含んでいてもよい。一例として、自チームの投手キャラクタのステータス情報611と、相手チームの打者キャラクタのステータス情報612とを含んでいてもよい。
第1の投球画面600は、投球操作を支援するUIオブジェクトとして、投手キャラクタ603に投げさせる球種を投球側ユーザが指定するための球種指定オブジェクト610を含んでいてもよい。
対戦進行部115は、球種指定オブジェクト610に対するユーザのスライド操作に基づいて、球種を決定する。図5に示すとおり、球種指定オブジェクト610において、ボールアイコンの周囲を囲うように、球種が1対1で対応付けられた球種アイコンが配置されている。球種アイコンは、対応付けられている球種を示すテキストまたはイラストなどを含んでいる。UI制御部113は、球種指定オブジェクト610において一覧される球種の種類を、投手キャラクタ603の能力に基づいて異ならせてもよい。
操作受付部111は、ボールアイコンに対する所定方向のスライド操作を、球種を指定するための操作として受け付ける。対戦進行部115は、スライド操作の方向に配置されている球種アイコンに対応する球種を、投手キャラクタ603に投げさせる球種として決定する。例えば、図5に示す例では、ユーザがボールアイコンを上方向にスライドさせた場合、対戦進行部115は、投手キャラクタ603にストレートを投げさせると決定する。球種にはボール604の移動経路、球速等を特定するためのパラメータが対応付けられている。球種のパラメータは、球速、変化量、および変化の方向を示す情報を含む。また、球種のパラメータは、投手キャラクタ603の識別情報に対応付けられて、記憶部120に記憶されている(不図示)。対戦進行部115は、投手キャラクタ603の識別情報に対応付けられた球種のパラメータのうち、決定した球種のパラメータを記憶部120から読み出し、投球結果D1に含める。
球種が決定されると、次に、対戦進行部115は、図6に示す第2の投球画面600を表示部152に表示させる。第2の投球画面600は、球種指定オブジェクト610に代えて、コース指定オブジェクト614を含む。コース指定オブジェクト614は、カーソル615と組み合わせて、投球側ユーザに、投手キャラクタ603に投げさせるコース(内角高め、低めなど)を指定させるためのUIオブジェクトとして機能する。
コース指定オブジェクト614は、一例として、ストライクゾーンに対応する矩形を9つのマスに分割したものである。各マスは、投手キャラクタ603の能力、具体的には、得意なコースおよび不得意なコースに基づいて、色分けして表示されてもよい。
コース指定オブジェクト614は、投げられたボールの到達予定位置を示す標識であるカーソル615を含む。第2の投球画面600が表示されている間、操作受付部111は、カーソル615の位置を指定するためのドラッグ操作を受け付ける。操作受付部111がカーソル615を移動させるためのドラッグ操作を受け付けると、UI制御部113は、該ドラッグ操作に関して検出されたタッチ位置に基づいて、カーソル615を移動させる。
操作受付部111は、タッチスクリーン15に対するユーザの最初の接触位置(初期タッチ座標)と、カーソル移動操作後の接触位置(タッチナウ座標)とを取得する。UI制御部113は、取得された各座標を比較した結果得られた変化方向、および、変化量に基づいて、カーソル615の位置の変化方向、および、変化量をそれぞれ決定する。これにより、UI制御部113は、カーソル615が直接タッチされなくても、また、コース指定オブジェクト614の表示領域外でドラッグ操作が受け付けられても、該ドラッグ操作に連動して、カーソル615を移動させることができる。このようにすれば、ユーザの指によってカーソル615の視認が妨げられることを回避できる。表示制御部112は、UI制御部113によって実行されているカーソル615の移動に連動して、移動するカーソル615を第2の投球画面600上に表示させる。
対戦進行部115は、コースの確定を、任意の方法で行う。例えば、ユーザが上述のドラッグ操作に基づく接触が維持された状態で、所定閾値以上の圧力で強く押し込む操作を続けて行ったとする。対戦進行部115は、押し込む操作が受け付けられた時点におけるカーソル615の位置を、最終的なコースとして確定させる。あるいは、「コース確定」などのボタン(不図示)が別途、第2の投球画面600に設けられてもよい。対戦進行部115は、該ボタンがタップ操作されたときのカーソル615の位置に基づいてコースを確定させてもよい。
コースが確定すると、次に、対戦進行部115は、図7に示す第3の投球画面600を表示部152に表示させる。第3の投球画面600は、良否判定オブジェクト620を含む。良否判定オブジェクト620は、投手キャラクタ603の制球の良否を決定するためのタイミングを投球側ユーザに指定させるためのUIオブジェクトとして機能する。
一例として、良否判定オブジェクト620は、弓形の帯状のゲージで構成される。良否判定オブジェクト620は、該ゲージ内に、帯の長手方向にスライドするスライドバー621と、スライドバー621が停止する帯上の位置を定義する第1領域622および第2領域623とを含む。
該帯状のゲージは、投手キャラクタ603の位置(以下、第1位置)から、捕手キャラクタ605の位置(以下、第2位置)に向かって伸びている。
UI制御部113は、スライドバー621を、初期位置である第1位置(例えば、図7の破線枠)から、最終位置である第2位置(例えば、図7のカーソル615の位置)に向かって、帯の長手方向(矢印の方向)に移動させる。アニメーション生成部114は、スライドバー621が、移動の開始から所定時間後に第2領域623を通過し、第1領域622を通過して、最終的にカーソル615の位置に到達するように、アニメーションを生成する。
ユーザは、スライドバー621が帯上の所望の位置に到達した時、その位置でスライドバー621を停止させるよう、タッチスクリーン15に対してタップ操作を行う。UI制御部113は、操作受付部111によってタップ操作が受け付けられた時の位置にて、スライドバー621を停止させる。対戦進行部115は、スライドバー621の停止位置に応じて、制球の良否を判定する。一例として、本実施形態では、対戦進行部115は、スライドバー621が第1領域622で停止した場合に、投手キャラクタ603が制球に完全に成功したと判定し、スライドバー621が第2領域623で停止した場合、成功に近い投球がなされたと判定し、それ以外の領域で停止した場合に、制球に失敗したと判定する。ここで、「制球に完全に成功した」とは、投手キャラクタ603が好投し、投球側ユーザによって指定された球種およびコースどおりに該ボールが仮想空間上を移動することを意味する。「成功に近い投球がなされた」とは、投球側ユーザによって指定された球種およびコースどおりにとはいかないが、それに近い球種およびコースに基づいて該ボールが仮想空間上を移動することを意味する。「制球に失敗した」とは、投手キャラクタ603が失投し、投球側ユーザによって指定された球種およびコースとはかけ離れた球種およびコースにて、該ボールが仮想空間上を移動することを意味する。
別の実施形態では、好投であると判定された場合には、打撃側ユーザ端末100Bは、打撃画面700(図9にて後述)に表示される、打撃操作を支援するUIオブジェクトを非表示にしたり、見えにくくしたり、表示するタイミングを遅くしたりしてもよい。これにより、投球側ユーザが、上述の一連の投球操作をうまく実施して制球に成功した場合には、打撃側ユーザが打撃を成功させにくくなる。このように、ユーザのゲームの操作に対する習熟度が対戦の進行に直接影響をおよぼすため、対戦ゲームの興趣性がより一層高まる。
制球の良否が判定されると、次に、対戦進行部115は、図8に示す第4の投球画面600を表示部152に表示させる。第4の投球画面600は、良否判定結果624を含む。また、第4の投球画面600においては、投手キャラクタ603が投球を開始するアニメーションが付与され、これまで投手キャラクタ603のグローブに収まっていたボール604が描出されてもよい。これにより、投球側ユーザは、第3の投球画面600に対して行った自身の操作に関して、フィードバックを即時に受け取ることができる。
なお、良否判定オブジェクト620の帯状のゲージは、弓、アーチなど形状を有し、投げられたボールが描く放物線を模していることが好ましい。また、良否判定オブジェクト620の帯の幅は、第1位置から第2位置へ移動するにつれて、細くなるように定められていることが好ましい。また、該ゲージにおいて、第2位置に最も近く、最も帯の幅が細くなっている部分、すなわち、ゲージの先端が、ボールの到達予定位置として確定したカーソル615に重なるように、良否判定オブジェクト620が配置されることが好ましい。これにより、ユーザは、直観的に、帯状のゲージを、投手キャラクタ603から投げられたボールが、画面奥に配置されている捕手キャラクタ605に向かって移動する経路であるかのように理解する。以上のことから、本実施形態に係る良否判定オブジェクト620は、現実の野球を再現するという目的に反して、ゲームの興趣性を高める目的で追加されたUIでありながら、投球画面600を現実の投球シーンから乖離させることなく、見た目に違和感のない投球シーンを演出することに貢献している。
<打撃画面の例>
図9は、ユーザ端末の表示部に表示されるゲーム画面のさらに他の具体例を示す図である。具体的には、該ゲーム画面は、打者キャラクタの打撃シーンを表す打撃画面700である。打撃画面700は、進行中のフェーズがマニュアル進行モードである場合に、打撃側ユーザによる打撃操作を受け付けるための、以下に説明する打撃操作UIを含む。
1つのフェーズが開始され、対戦相手である投球側ユーザが投球操作を実施すると、それに応じて投球側ユーザ端末100Aにて生成された投球結果D1が、打撃側ユーザ端末100Bに供給される。打撃側ユーザ端末100Bが、投球結果D1を受信すると、打撃側ユーザ端末100Bの対戦進行部115は、例えば、図9に示す打撃画面700を、UI制御部113に生成させて、表示部152に表示させる。
対戦進行部115は、仮想空間としての球場における第1位置と第2位置との間に、ホームベース607を配置する。対戦進行部115は、ホームベース607上に、第1位置から第2位置に向かう方向に交差する方向に延在する交差面を設定する。対戦進行部115は、交差面に基づいて、打者キャラクタ601がボール604を打撃したか否かを判定する。上述したとおり、交差面は、例えば、ストライクゾーン701と、該ストライクゾーンの外側に配置されるボールゾーン702とを含んでいてもよい。
操作受付部111が、投手キャラクタ603が投球したボール604が交差面に到達したタイミングで、ユーザからスイングのタイミングを指定する操作を受け付けると、打者キャラクタ601は、バット602をスイングすることによって、ボール604を打ち返す作用をボール604に与えることができる。図9に示すボール604は、投手キャラクタ603によって投球された後、交差面に向かって移動している途中のボール604の一例を示す。
図9に示すとおり、打撃画面700は、上述の他にも、各種オブジェクトを含んでいてもよい。特に、ユーザの打撃操作を支援するためのUIオブジェクトを含んでいることが好ましい。打撃操作を支援するUIオブジェクトとしては、例えば、タイミングヒントオブジェクト703、ミートカーソル704、位置ヒントオブジェクト705、方向ヒントオブジェクト706等がある。
タイミングヒントオブジェクト703は、打者キャラクタ601にバット602をスイングさせる良好なタイミングをユーザに示す。ミートカーソル704は、バット602がスイングされた際に交差面においてボール604に作用を与え得る領域として、スイングされたバット602の到達予定位置をユーザに示す。また、ミートカーソル704は、バット602とボール604との当たりを判定するために、対戦進行部115によって参照される領域でもある。位置ヒントオブジェクト705は、投手キャラクタ603によって投げられたボール604の、交差面における到達予定位置をユーザに示す。方向ヒントオブジェクト706は、投げられたボール604の進行方向の変化をユーザに示す。
本実施形態において、打撃結果D2を決定するための打撃操作には、一例として、ミートカーソル704の位置を指定するためのスライド操作と、決定したミートカーソル704の位置に向けてバット602を振るタイミングを指定するためのフリック操作とが含まれる。つまり、スライド操作が、投球に対して打撃を行う位置を指定する操作であり、フリック操作が、打撃を行うタイミング、つまりバット602を振るタイミングを指定する操作である。つまり、打撃側ユーザにとって、対戦、特に、攻撃の回を有利に進めることができるか否かは、マニュアル進行モードの場合、スライド操作とフリック操作との両方の巧拙にかかっている。
投手キャラクタ603からボール604が投げられると、打撃画面700において、操作受付部111は、上述の打撃操作を待機する状態に遷移する。操作受付部111が、タッチスクリーン15に対するユーザのスライド操作を受け付けると、該スライド操作にしたがって、UI制御部113は、ミートカーソル704を移動させる。なお、ユーザは、ミートカーソル704のベストの位置を、位置ヒントオブジェクト705を参考にして決定してもよい。
続いて、対戦進行部115は、投手キャラクタ603より投げられたボール604が交差面を基準とする所定の範囲内に到達したか否かを判定する。つまり、投げられたボール604が、ホームベース607上に設定された交差面に所定距離未満まで近づいてきたか否かを判定する。ボール604が交差面から所定距離未満まで到達したと判定された場合、UI制御部113は、ミートカーソル704の移動の少なくとも一部を制限してもよい。移動が制限されたことを示すように、UI制御部113はミートカーソル704の色または模様などの表示態様を変化させてもよい。
打撃画面700において、投げられたボール604には、ストライクゾーン701に向かって移動してくるアニメーションが、アニメーション生成部114によって付与される。ユーザは、移動してくるボール604を目で追い、ボール604がホームベース607上に到達したと思うベストのタイミングで、打者キャラクタ601が行うスイングの開始タイミングを指定するためにフリック操作を行うことができる。
ユーザは、フリック操作のベストのタイミングを計るために、さらに、タイミングヒントオブジェクト703を参考にすることができる。タイミングヒントオブジェクト703は、ボール604の投球が開始されたときから表示が開始され、ボール604がホームベース607上の交差面に近づくにつれてボール604の中心に向かって収縮するようなアニメーションが、アニメーション生成部114によって付与されている。さらに、該アニメーションは、ボール604が交差面に到達したタイミングで、ちょうどボール604の輪郭と同じ大きさにまで縮小するアニメーションである。ユーザは、タイミングヒントオブジェクト703の大きさを確認することにより、良好な打撃結果が得られるベストタイミングを計ることができる。
操作受付部111がフリック操作を受け付けると、対戦進行部115は、その時の交差面におけるボール604とミートカーソル704との位置関係に少なくとも基づいて、打者キャラクタ601がボール604に打撃を与えたか否かを判定する。つまり、ユーザのスライド操作とフリック操作とに基づいて、打者キャラクタ601によってスイングされたバット602が、ボール604に当たったか否かを判定する。例えば、交差面においてボール604がミートカーソル704と少なくとも部分的に重畳している場合には、打者キャラクタ601がボール604を打撃したと判定してもよい。
さらに、対戦進行部115は、操作受付部111が特定したフリック操作のタイミングに基づいて、打撃を与えたか否かの判定を実行してもよい。例えば、交差面におけるボール604およびミートカーソル704が打撃に適合した位置関係にある場合であっても、フリック操作のタイミングがボール604への打撃に適合したタイミングに対して、早過ぎたり遅すぎたりする場合には、対戦進行部115は、打者キャラクタ601がボール604を打撃しなかったと判定してもよい。
また、対戦進行部115は、上述の位置関係に少なくとも基づいて、打撃が与えられたボール604が仮想空間において移動する際の移動経路を算出する。具体的には、対戦進行部115は、上述の位置関係に基づいて、バット602とボール604との衝突を力学的にモデル化する。この場合、バット602に衝突した直後のボール604の速度ベクトル、回転軸、回転量等を、ボール604を移動させるための初期条件として取得すればよい。例えば、ボール604の下部をミートカーソル704の上部で打撃した場合には、打球の角度が上がりフライとなる。また、ボール604の上部をミートカーソル704の下部で打撃した場合には、打球の角度が下がりゴロとなる。また、例えば、対戦進行部115は、ミートカーソル704の中央の位置(図9の芯707)でボール604の中央を打撃する等の所謂ジャストミートの場合には、ライナーでボール604が飛ぶような移動経路を算出する。一方、ジャストミート以外の場合には凡打と判定して、凡打に対応する移動経路を算出してもよい。
対戦進行部115が算出した移動経路にしたがって、アニメーション生成部114は、算出された移動経路を飛んでいくボール604のアニメーションを生成する。表示制御部112は、生成された、飛翔するボール604のアニメーションを、表示部152に表示する。
こうしてボール604がフィールド上に移動した後は、対戦進行部115は、ゲームプログラム131にしたがって、仮想空間における、ボール604の移動、守備をする野手キャラクタの動き、および、進塁する走者キャラクタの動きなどをそれぞれ計算する。そして、計算結果に基づいて、各オブジェクトを移動させ、フィールドプレイシーンを進行させる。UI制御部113およびアニメーション生成部114は、計算されたフィールドプレイシーンに対応する画像またはアニメーションを生成して、表示部152に表示させてもよい。
なお、対戦進行部115は、打者キャラクタ601がボール604に打撃を与えなかったと判定した場合には、ボール604の移動経路の算出を省略してもよい。この場合、打者キャラクタ601がボール604を空振りするアニメーションがアニメーション生成部114によって生成され、該アニメーションが表示制御部112によって表示部152に表示される。
打撃画面700は、進行しているフェーズにおいて対決中の各キャラクタのステータス情報を含んでいてもよい。一例として、自チームの打者キャラクタ601のステータス情報708と、相手チームの投手キャラクタ603のステータス情報709とを含んでいてもよい。
<状況情報>
図10は、対戦進行部115が生成する状況情報のデータ構造の一例を示す図である。一例として、状況情報400は、図3に示すタイミングt3において、投球側ユーザ端末100Aおよび打撃側ユーザ端末100Bの両方で共有されている状況情報を示す。状況情報401は、タイミングtmにおいて、投球側ユーザ端末100Aの対戦進行部115によって生成された第1状況情報を示す。状況情報402は、同じタイミングtmにおいて、打撃側ユーザ端末100Bの対戦進行部115によって生成された第2状況情報を示す。
図10に示すとおり、状況情報は、一例として、進行中のイニングを示すイニング410、各チームの得点を示すスコア411、攻撃側のチームの走者キャラクタが何塁にいるかを示すランナー412、進行中の打席におけるボールカウント413、および、進行中のイニングにおけるアウトカウント414の各種情報を含む。
図10に示す例では、タイミングt3において、「1アウト、ランナー1塁」という状況で、各ユーザ端末100の同期がとれている。ここで、タイミングt3以降の所定のフェーズにおいて、投手キャラクタから投げられたボールを打者キャラクタがフェアに打ち返したとする。
そして、一方の投球側ユーザ端末100Aでは、対戦進行部115が、フィールドプレイを計算し、1塁にいた走者キャラクタは2塁に進塁し、打者キャラクタは1塁でアウトをとられたという結果を出力したとする。この場合、対戦進行部115は、タイミングtmにおいて、状況情報401を生成する。
他方、打撃側ユーザ端末100Bでは、対戦進行部115が、フィールドプレイを計算し、1塁にいた走者キャラクタは2塁に進塁し、打者キャラクタはセーフとなり1塁に出塁したという結果を出力したとする。この場合、対戦進行部115は、タイミングtmにおいて、状況情報402を生成する。
状況情報401および状況情報402が、サーバ200を介して交換されると、対戦進行部115は、タイミングt3からtmまでのどこかで、同期ずれが発生したことを検出する。対戦進行部115は、同じタイミングで生成された状況情報401と状況情報402とを比較し、状況情報に含まれている少なくとも1つの情報に不一致があれば、同期ずれが発生したと判断できる。図10に示す例では、対戦進行部115は、ランナー412と、アウトカウント414とが一致しないことに基づいて、同期ずれの発生を検出する。
<処理フロー>
図11および図12は、ゲームシステム1に含まれる各装置が、ゲームプログラム131に基づいて実行する処理の流れを示すフローチャートである。図11に示すフローチャートにおいては、ユーザ端末100が実行する処理を、投球側ユーザ端末100Aが実行する処理と、打撃側ユーザ端末100Bが実行する処理とに分けて記載する。図12に示すステップS139以降の処理については、ユーザ端末100が実行する処理は、投球側ユーザ端末100Aと打撃側ユーザ端末100Bとで共通である。そのため、図12に示すフローチャートにおいては、投球側ユーザ端末100Aが実行する処理と打撃側ユーザ端末100Bが実行する処理とを区別せずに、ユーザ端末100が実行する処理としてまとめて記載する。
図11に示す一連の処理は、サーバ200が、投球側ユーザ端末100Aと、打撃側ユーザ端末100Bとのマッチングを成立させたことにより開始される。
ステップS101にて、サーバ200の対戦支援部211は、状況情報を初期化する。初期化された対戦情報は、対戦開始時の対戦の進行状況を示す。ステップS102にて、対戦支援部211は、マッチングが成立した旨の通知と、初期化された状況情報とを各ユーザ端末100に送信して、対戦を開始する。
ステップS103およびステップS104にて、各ユーザ端末100の対戦進行部115は、初期化された状況情報を受信して、対戦の進行を開始する。このとき、各ユーザ端末100の表示制御部112は、例えば、図4に示すマッチング画面を表示部152に表示してもよい。
ステップS105にて、対戦支援部211は、フェーズ開始の同期をとる。これに伴い、投球側ユーザ端末100Aの対戦進行部115は、ステップS106にて、該フェーズの進行を開始し、投球画面600(図5〜図8)を表示部152に表示させる。
ステップS107にて、操作受付部111は、投球側ユーザから投球操作を受け付ける。ステップS108にて、対戦進行部115は、該投球操作に基づいて、球種、コース、および、好投か否か等の投球内容を決定する。ステップS109にて、決定した投球内容を示す情報を含む投球結果D1を生成し、投球結果D1をサーバ200に送信する。
一方、ステップS105にてフェーズ開始の同期がとられたとき、打撃側ユーザ端末100Bの対戦進行部115は、ステップS110にて、打撃画面700を表示部152に表示させる。このとき、投手キャラクタ603の投球動作は確定していないので、打撃画面700には、ボールを投げる前の投手キャラクタ603と、ミートカーソル704とが表示される。ステップS111にて、操作受付部111は、ミートカーソル704を移動させるためのスライド操作を受け付けてもよい。
ステップS112にて、対戦支援部211は、投球結果D1を受信する。そして、ステップS113にて、受信した投球結果D1を、打撃側ユーザ端末100Bに送信する。
ステップS114にて、打撃側ユーザ端末100Bは、サーバ200から投球結果D1を受信する。ステップS115にて、打撃側ユーザ端末100Bのアニメーション生成部114は、受信された投球結果D1に基づいて、投手キャラクタ603が投球するアニメーションとボール604が移動するアニメーションとを生成する。ステップS116にて、表示制御部112は、生成された該アニメーションを表示部152に表示する。ここで、UI制御部113は、ミートカーソル704の他に、打撃側ユーザの打撃操作を支援するためのUIオブジェクト(例えば、図9)を打撃画面700に重畳させてもよい。
投球側ユーザ端末100Aにおいても同様に、ステップS117にて、アニメーション生成部114によって、投手キャラクタ603が投球するアニメーションとボール604が移動するアニメーションとが生成される。そして、ステップS118にて、表示制御部112によって、これらのアニメーションが表示部152に表示される。
ステップS119にて、打撃側ユーザ端末100Bの操作受付部111は、打撃側ユーザによる打撃操作を受け付ける。ステップS120にて、対戦進行部115は、受け付けられた打撃操作に基づいて、バット602のスイング位置、および、スイングタイミング等を決定する。ステップS121にて、対戦進行部115は、決定したスイング位置およびスイングタイミングの情報を含む打撃結果D2を生成し、サーバ200に送信する。
ステップS122にて、対戦支援部211は、打撃結果D2を受信する。そして、ステップS123にて、受信した打撃結果D2を、投球側ユーザ端末100Aに送信する。
投球側ユーザ端末100Aがサーバ200から打撃結果D2を受信すると、ステップS124にて、アニメーション生成部114は、受信された打撃結果D2に基づいて、打者キャラクタ601が打撃するアニメーションを生成する。ステップS125にて、表示制御部112は、生成された該アニメーションを表示部152に表示する。
対戦進行部115は、打撃結果D2に基づいて「打者キャラクタ601がバット602にボール604を当てて打撃した」と判断した場合には、ステップS126にて、フィールドプレイの計算を行う。具体的には、対戦進行部115は、打撃されたボール604をフィールド上で移動させるための計算、野手キャラクタに守備(捕球、送球など)をさせるための計算、および、走者キャラクタを進塁または出塁させるための計算を行う。
ステップS127にて、アニメーション生成部114は、対戦進行部115の計算結果にしたがって、フィールドプレイのアニメーションを生成してもよい。ステップS128にて、表示制御部112は、該生成されたアニメーションを表示部152に表示してもよい。
なお、対戦進行部115は、打撃結果D2に基づいて「打者キャラクタ601がバット602にボール604を当てなかった(空振りした、または、見逃した)」と判断した場合には、ステップS126〜ステップS128の各処理の実行を省略する。
ステップS129にて、対戦進行部115は、フィールドプレイに関する計算結果に基づいて、状況情報を更新する。例えば、計算結果が、「打者キャラクタ601がフェアに打ち返したボールは、打者キャラクタ601が1塁に到達するよりも前に、1塁に送球された」ことを指しているとする。この場合、対戦進行部115は、状況情報400を状況情報401に更新する。対戦進行部115は、更新した状況情報401をサーバ200に送信する。
あるいは、対戦進行部115は、ステップS126〜ステップS128が省略された場合には、投げられたボール604の交差面における到達位置が、ストライクゾーン701内か、それ以外かに基づいて、状況情報の中のボールカウント413を更新する。
一方、打撃側ユーザ端末100Bの対戦進行部115は、ステップS121の後、ステップS130〜ステップS134の各ステップを実行する。ステップS130〜ステップS134は、上述の、ステップS124〜ステップS128と同様に実行される。異なる点は、打撃結果D2が、サーバ200から送信されたものではなく、ステップS120にて自端末にて生成された情報であるという点である。
また、ステップS132では、ステップS126とは異なり、対戦進行部115は、例えば、「打者キャラクタ601がフェアに打ち返したボールが1塁に送球されるよりも前に、打者キャラクタ601が1塁に到達した」ことを指す計算結果を出力したとする。この場合、対戦進行部115は、ステップS135にて、状況情報400を状況情報402に更新する。対戦進行部115は、更新した状況情報402をサーバ200に送信する。
対戦支援部211は、それぞれのユーザ端末100から、同じタイミングで生成された状況情報を受信すると、ステップS136にて、受信した状況情報を、それぞれ対戦体の各ユーザ端末100に転送する。すなわち、投球側ユーザ端末100Aが生成した状況情報401は、打撃側ユーザ端末100Bに供給され、打撃側ユーザ端末100Bが生成した状況情報402は、投球側ユーザ端末100Aに供給されて、状況情報が交換される。ステップS137およびステップS138にて、各ユーザ端末100は、対戦相手のユーザ端末100で生成された状況情報をそれぞれ受信する。
ユーザ端末100が対戦相手の状況情報を受信すると、ステップS139にて、対戦進行部115は、自端末で生成された第1状況情報(例えば、状況情報401)と、対戦相手のユーザ端末100で生成された第2状況情報(例えば、状況情報402)とを比較する。
状況情報のすべてが一致している場合、対戦進行部115は、ステップS139のYESから、ステップS106またはステップS110に戻り、それ以降の処理を実行して、次のフェーズを進行させる。
一方、状況情報に含まれる情報のうち1つでも一致しない情報がある場合、対戦進行部115は、ステップS139のNOから、ステップS140に進む。そして、対戦進行部115は、対戦の進行状況が一致していないこと、すなわち、同期ずれが発生していることを検知する。対戦進行部115は、同期ずれの発生を検知すると、現在進行中のフェーズを中断する。
ステップS141にて、対戦進行部115は、同期ずれが発生していることをサーバ200に通知する。通知は、投球側ユーザ端末100Aおよび打撃側ユーザ端末100Bの両方からサーバ200宛てに送信されてもよいし、いずれか一方からサーバ200宛てに送信されてもよい。また、各ユーザ端末100は、対戦相手のユーザ端末100にも、該通知を送信してもよい。
ステップS142にて、対戦進行部115は、同期ずれが発生した旨をユーザに通知するためのメッセージ画面を表示部152に表示する。具体的には、対戦進行部115は、UI制御部113に作成させた該メッセージ画面を表示部152に表示するように、表示制御部112に指示する。該メッセージ画面を表示するステップS142は、ステップS140が実行された後、ステップS141よりも前に実行されてもよい。また、メッセージ画面は、後述のステップS146が実行されるまで、継続して表示されてもよい。
ステップS143にて、サーバ200の対戦支援部211は、対戦中の各ユーザ端末100のうちの少なくとも1台から同期ずれが発生した旨の通知を受信すると、ステップS143のYESからステップS144に進む。ここで、対戦支援部211は、各ユーザ端末100から状況情報を取得する。一例として、投球側ユーザ端末100Aから第1状況情報を、打撃側ユーザ端末100Bから第2状況情報を取得する。
ステップS144にて、対戦支援部211は、どちらの状況情報を進行中の対戦における最新の状況情報として採用するのかを決定する。対戦支援部211は、後述するように、各種パラメータに基づいて採用する状況情報を決定してもよいし、ランダムに決定してもよい。
ステップS145にて、対戦支援部211は、いずれの状況情報を採用したのかを示す通知を、対戦に参加する各ユーザ端末100に送信する。
ステップS146にて、各ユーザ端末100の対戦進行部115は、上述の通知を受信する。そして、進行中の対戦の最新の状況情報を、通知された、採用された方の状況情報に更新する。採用された状況情報が、ステップS129またはステップS135にて、自端末で作成されたものである場合には、更新する処理は省略されてもよい。
ステップS147にて、対戦進行部115は、採用された状況情報に基づく対戦の進行状況をユーザに通知するためのメッセージ画面を表示部152に表示する。具体的には、対戦進行部115は、該状況情報に基づいてUI制御部113に作成させたメッセージ画面を表示部152に表示するように、表示制御部112に指示する。
1つの状況情報が採用され統一されたことにより、同期ずれが解消されると、各装置は、中断していたフェーズを終了させ、採用された状況情報に基づいて、次のフェーズに移行し、対戦を再開する。具体的には、ステップS148にて、サーバ200の対戦支援部211は、同期ずれが解消されたフェーズを終了し、ステップS105に戻り、次のフェーズを開始するための同期制御を行う。ステップS149にて、各ユーザ端末100の対戦支援部211は、同期ずれが解消されたフェーズを終了し、次のフェーズに移行して、中断していた対戦を再開する。投球側ユーザ端末100Aは、ステップS106に戻り、上述の次のフェーズの投球画面600を自端末の表示部152に表示する。打撃側ユーザ端末100Bは、ステップS110に戻り、上述の次のフェーズの打撃画面700を自端末の表示部152に表示する。
<メッセージ画面の例>
(審議中画面)
図13は、ユーザ端末の表示部に表示されるメッセージ画面の一具体例を示す図である。具体的には、該メッセージ画面は、同期ずれが発生している間、ステップS142にて、ユーザ端末100の表示部152に表示される。該メッセージ画面は、一例として、図13に示すとおり、審議中画面800であることが好ましい。
審議中画面800は、例えば、同期ずれが発生した旨をユーザに通知するためのテキストメッセージ801を含む。審議中画面800は、さらに、同期ずれという、ゲームシステム1上で現実に発生している不具合によって、対戦の進行が中断している状況を、野球の試合が中断している状況に置き換えた演出を含んでいることが好ましい。
現実の野球の試合では、審判の判定に納得できない場合に監督が再考を求めることにより、審判団が審議を行う間、試合が中断するということが起こり得る。そこで、審議中画面800は、上述の演出として、審判団による審議中であることを示すテキストデータ802を含んでいてもよい。これに代えて、または、これに加えて、審議中画面800は、上述の演出として、審判団による審議のシーンを示す画像データ803を含んでいてもよい。
上述のメッセージ画面により、ユーザは、対戦の進行が中断している理由を知ることができる。そのため、ユーザに、待機の時間を短く感じさせることができる。また、上述のメッセージ画面により、同期ずれという現実の不具合を通知するときに、野球の雰囲気を壊さないようにすることができる。結果として、対戦を通じてユーザが培った野球ゲームへの没入感、および、該ゲームの興趣性は損なわれないという効果を奏する。
なお、対戦進行部115は、審議中画面800において、対戦の進行が中断していてもユーザが可能な操作に関して、切替ボタン613などのUIオブジェクトを表示させ、ユーザの操作を受け付けてもよい。
(審議結果画面)
図14は、ユーザ端末の表示部に表示されるメッセージ画面の他の具体例を示す図である。具体的には、該メッセージ画面は、発生していた同期ずれが解消されたときに、ステップS147にて、ユーザ端末100の表示部152に表示される。該メッセージ画面は、一例として、図14に示すとおり、審議結果画面810であることが好ましい。
審議結果画面810は、例えば、同期ずれが解消され、どのような進行状況から対戦を再開するのかをユーザに通知するためのテキストメッセージ811を含む。図示のテキストメッセージ811は、一例として、不一致が起こっていた状況情報401および状況情報402(図10)のうち、状況情報401が採用された場合に通知されるテキストメッセージを示している。
審議結果画面810は、さらに、ゲームシステム1上で現実に発生した同期ずれの不具合に対する対処結果の報告を、野球の試合で行われる結果の報告に置き換えた演出を含んでいることが好ましい。
現実の野球の試合では、審判団の審議の結果を、代表の審判員が観客席に向かって発表するということが起こり得る。そこで、審議結果画面810は、上述の演出として、審議の結果についての発表であることを示すテキストデータ812を含んでいてもよい。これに代えて、または、これに加えて、審議結果画面810は、上述の演出として、審議の結果が代表の審判員によって発表されるシーンを示す画像データ813を含んでいてもよい。図14に示すとおり、テキストメッセージ811の表現は、画像データ813で表現されている雰囲気にマッチさせることがより好ましい。具体的には、テキストメッセージ811は、画像データ813に含まれる審判員が発現した内容を表現していることが好ましい。
上述のメッセージ画面により、同期ずれに対する対処結果という現実の不具合に係る内容を通知するときに、野球の雰囲気を壊さないようにすることができる。特に、自端末の進行状況がリセットされ、それとは違う状況から対戦を再開しなければならなくなったユーザは、違和感または不満を抱く可能性がある。上述のメッセージ画面に係る演出により、こうした違和感または不満をできるだけ緩和することができる。結果として、対戦を通じてユーザが培った野球ゲームへの没入感、および、該ゲームの興趣性は損なわれないという効果を奏する。
<採用する状況情報の決定方法>
ステップS144では、サーバ200の対戦支援部211は、同期ずれが発生する直前の時点において、負けている(劣勢の)ユーザのユーザ端末100で生成された状況情報を採用してもよい。例えば、図3に示すt3のタイミングにおいて、図10に示す状況情報400のとおり、攻撃側ユーザが操作する第1チームと、投球側ユーザが操作する第2チームとのスコアが、1対0であるとする。この場合、対戦支援部211は、打撃側ユーザ端末100Bで生成された状況情報401を不採用とし、投球側ユーザ端末100Aで生成された状況情報402を採用する。
上述の構成によれば、同期ずれが原因で余儀なく発生する違和感のある進行を、対戦で勝っている(優勢の)ユーザに負担してもらうことにより、負けているユーザのストレスを減らし、心理的負担の公平性を保つことができる。違和感のある進行とは、自端末における対戦の進行状況がなかったことになり、それとは異なる進行状況から対戦が再開されるというゲーム上の進行を指す。
ステップS144では、対戦支援部211は、同期ずれが発生する直前の時点において、負けているユーザに有利な状況情報を採用してもよい。例えば、図3に示すt3のタイミングにおいて、状況情報400のとおり、攻撃側ユーザが操作する第1チームと、投球側ユーザが操作する第2チームとのスコアが、1対0であるとする。ここで、状況情報401および状況情報402のうち、負けている第2チームに有利な状況情報は、状況情報401である。よって、対戦支援部211は、状況情報402を破棄し、状況情報401を採用する。
上述の構成によれば、試合の均衡をできる限り保ち、同期ずれの発生が、一方的な試合展開を助長することを防止することができる。
ステップS144では、対戦支援部211は、レーティングが低いユーザのユーザ端末100で生成された状況情報を採用してもよい。例えば、図10に示す第1チームを操作する打撃側ユーザのレーティングが「1932」で、第2チームを操作する投球側ユーザのレーティングが「2069」であるとする。この場合、対戦支援部211は、レーティングが低い打撃側ユーザの打撃側ユーザ端末100Bで生成された状況情報401を採用する。
上述の構成によれば、同期ずれが原因で余儀なく発生する違和感のある進行を、ゲームに強い方のユーザに負担してもらうことにより、弱い方のユーザのストレスを減らし、心理的負担の公平性を保つことができる。
ステップS144では、対戦支援部211は、レーティングが低いユーザが操作しているチームに有利な状況情報を採用してもよい。例えば、レーティングが低い打撃側ユーザが操作している第1チームに有利な状況情報は、状況情報402である。よって、対戦支援部211は、状況情報401を破棄し、状況情報402を採用する。
上述の構成によれば、試合の均衡をできる限り保ち、同期ずれの発生が、一方的な試合展開を助長することを防止することができる。
ステップS144では、対戦支援部211は、ユーザが操作するチーム、または、該チームに属する各選手キャラクタに付与されている強さのパラメータが低い方のユーザのユーザ端末100で生成された状況情報を採用してもよい。例えば、図10に示す第1チームの総合的な強さを示す総合能力値のパラメータが「12885ポイント」であって、第2チームの総合能力値のパラメータが「14068ポイント」であるとする。この場合、対戦支援部211は、総合能力値が低い第1チームを操作している打撃側ユーザの打撃側ユーザ端末100Bで生成された状況情報401を採用する。
上述の構成によれば、同期ずれが原因で余儀なく発生する違和感のある進行を、強いチームを操作しているユーザに負担してもらうことにより、弱いチームを操作しているユーザのストレスを減らし、心理的負担の公平性を保つことができる。
ステップS144では、対戦支援部211は、上述の強さのパラメータが低いチームに有利な状況情報を採用してもよい。上述の例では、総合能力値が低いチームは、第1チームであり、第1チームに有利な状況情報は、状況情報402である。よって、対戦支援部211は、状況情報401を破棄し、状況情報402を採用する。
上述の構成によれば、試合の均衡をできる限り保ち、同期ずれの発生が、一方的な試合展開を助長することを防止することができる。
ステップS144では、対戦支援部211は、1つの試合の中で同期ずれが複数回発生している場合に、採用された回数が少ないユーザ端末100で生成された状況情報を採用してもよい。例えば、1試合中で、これまで同期ずれが3回発生し、投球側ユーザ端末100Aで生成された状況情報が2回、打撃側ユーザ端末100Bで生成された状況情報が1回採用されているとする。この場合、対戦支援部211は、4回目の同期ずれにおいては、打撃側ユーザ端末100Bで生成された状況情報を採用する。
上述の構成によれば、同期ずれが原因で、違和感のある進行を強制されるユーザが特定のユーザに偏らないようにすることができる。これにより、ユーザの心理的負担を公平に保つことができる。
ステップS144では、対戦支援部211は、状況情報を採用するユーザ端末100を順番に、2人対戦の場合は交互に、切り替えてもよい。例えば、1回目の同期ずれでは、投球側ユーザ端末100Aで生成された状況情報を採用し、2回目の同期ずれでは、打撃側ユーザ端末100Bで生成された状況情報を採用し、以降も同期ずれが発生すれば、各ユーザ端末100で生成された状況情報を交互に採用する。
上述の構成によれば、同期ずれが原因で、違和感のある進行を強制されるユーザが特定のユーザに偏らないようにすることができる。これにより、ユーザの心理的負担を公平に保つことができる。
ステップS144では、対戦支援部211は、どのユーザが操作するチームにとって有利な状況情報を採用するのかを、順番にまたは交互に切り替えてもよい。例えば、1回目の同期ずれでは、第1チームに有利な状況情報を採用し、1回目の同期ずれでは、第2チームに有利な状況情報を採用し、以降も同期ずれが発生すれば、各チームに有利な状況情報を交互に採用する。
上述の構成によれば、同期ずれが原因で、進行上の不利益を被るユーザが特定のユーザに偏らないようにすることができる。
〔変形例〕
ユーザ端末100の対戦進行部115は、1つ試合で同期ずれが発生する回数が所定回数を超えると、強制的に、進行モードをオート進行に切り替えて、対戦の進行に係るユーザの操作を受け付けないようにしてもよい。具体的には、対戦進行部115は、図5〜図9に示す投球操作UIまたは打撃操作UIを表示させない。したがって、対戦進行部115は、ユーザの投球操作または打撃操作を受け付けることなく、ゲームプログラム131にしたがって、サーバ200との通信によって対戦を進行させる。
本実施形態の構成は、2人で対戦するゲームの他に、3人以上で対戦するゲームにも適用可能である。この場合、ユーザ端末100の対戦進行部115は、3人以上のユーザのそれぞれが操作している各ユーザ端末100で生成された、3つ以上状況情報をそれぞれ比較する。そして、1つでも矛盾する状況情報があれば、同期ずれを検知する。この場合、サーバ200の対戦支援部211は、多数決で1つの状況情報を採用してもよい。
対戦支援部211は、矛盾のある2つ以上の状況情報を組み合わせて、妥協点となる1つの状況情報を新規に生成してもよい。例えば、図10に示す状況情報401と、状況情報402との不一致により、同期ずれが発生したとする。不一致は、状況情報の中でも、特に、各ランナー412および各アウトカウント414において生じている。そこで、対戦支援部211は、ランナー412については、一方の状況情報401から採用し、アウトカウント414については、他方の状況情報402から採用して、新たな状況情報を生成してもよい。
あるいは、2以上の状況情報の間で、数値に矛盾がある場合、対戦支援部211は、矛盾する数値の平均値を新たな状況情報として生成してもよい。例えば、スコア411が、一方の状況情報において、「5対3」を示し、他方の状況情報において、スコア411が「7対3」を示す場合、対戦支援部211は、矛盾する数値の間をとり、「6対3」のスコア411を含む状況情報を生成し、これを採用してもよい。
上述の構成によれば、同期ずれが原因で、進行上の不利益を被るユーザが特定のユーザに偏らないようにすることができるとともに、ユーザの心理的負担を公平に保つことができる。
各ユーザ端末100で生成された状況情報の比較と、同期ずれの検知とを、ユーザ端末100に代えて、サーバ200が行ってもよい。この場合、図11に示すステップS136にて、サーバ200の対戦支援部211は、各ユーザ端末100によって、対戦の進行上の同じタイミングで生成された状況情報を、ユーザ端末100のそれぞれから取得する。対戦支援部211は、ここでは、取得した状況情報を別のユーザ端末100に転送すること、すなわち、状況情報を交換する処理を省略してもよい。この場合、ステップS137〜S143も省略される。
対戦支援部211は、ステップS136の次に、各ユーザ端末100の状況情報を比較するステップを実行する。例えば、投球側ユーザ端末100Aで生成された状況情報401と、打撃側ユーザ端末100Bで生成された状況情報402とを比較する。
状況情報のすべてが一致している場合、対戦支援部211は、ステップS148に進み、進行中のフェーズを終了させて、次のフェーズに移行する。一方、状況情報に含まれる情報のうち1つでも一致しない情報がある場合、対戦支援部211は、対戦の進行状況が一致していないこと、すなわち、同期ずれが発生していることを検知するステップを実行する。対戦支援部211は、同期ずれの発生を検知すると、同期ずれが発生した旨を各ユーザ端末100に通知するステップを実行してもよい。それから、ステップS144に進む。
なお、ステップS144にて、対戦支援部211が、いずれの状況情報を採用するのかを調停している間、通信トラブルなどによって、一方または両方のユーザ端末100がオフラインになることが想定される。この場合、対戦支援部211は、オフラインになったユーザ端末100の進行モードをオート進行モードに切り替える。そして、オート進行モードにおいて、対戦支援部211は、投球結果または打撃結果を、ユーザ端末100から受信できない代わりに、抽選を実行して決定し、自ら生成してもよい。これにより、ユーザ端末100がオフラインになっても対戦を進行させることができる。対戦支援部211は、オフラインのユーザ端末100が、再度オンラインになった場合に、対戦の最終結果(スコア、勝敗など)を送信してもよい。
〔ソフトウェアによる実現例〕
制御部210の制御ブロック(特に、対戦支援部211)、ならびに、制御部110の制御ブロック(特に、操作受付部111、表示制御部112、UI制御部113、アニメーション生成部114、および、対戦進行部115)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。
(項目1) ゲームプログラム(131)について説明した。本開示のある局面によると、ゲームプログラムに基づくゲームは、コンピュータ(ユーザ端末100)を操作するユーザと、1以上の、他のコンピュータ(他のユーザ端末100)を操作する相手ユーザとを、各コンピュータ間の通信を介して対戦させる対戦ゲームである。ゲームプログラムは、プロセッサ(10)、メモリ(11)、操作部(入力部151など)および表示部(152)を備える、上述の各コンピュータの少なくともいずれか1つにより実行される。ゲームプログラムは、プロセッサに、ユーザと相手ユーザとの対戦を、相手ユーザが操作する他のコンピュータとの間で進行状況を同期させて、ユーザの操作にしたがって進行させるステップ(S106〜S128、S130〜S134)と、進行させた対戦の進行状況を示す第1の状況情報(状況情報401、状況情報402)を、対戦の進行上の所定のタイミング(例えば、tmなど)で生成するステップ(S129、S135)と、他のコンピュータにおいて同じ所定のタイミングで生成された第2の状況情報(状況情報402、状況情報401)を取得するステップ(S137、S138)と、第1の状況情報と一致しない第2の状況情報がある場合に(S139でNO)、同期ずれが発生したことを示す第1の通知(テキストメッセージ801)を表示部に表示するステップ(S142)と、を実行させる。これにより、同期制御を実現し、通信対戦ゲームを滞りなく進行させることができる。また、同期ずれが発生した場合には、待たされることによりユーザが感じるストレスを軽減できるという効果を奏する。結果として、同期制御に係る不具合が発生した場合でも、ゲームの興趣性を損なうことなく、不具合に伴うユーザのストレスを抑制することができるという効果を奏する。
(項目2) (項目1)において、進行させるステップでは、同期ずれが発生した場合、所定のタイミングにおける進行状況が各コンピュータの間で共有されることにより対戦が再開可能となるまで、対戦を中断する。これにより、ゲームの興趣性を損なうことなく、不具合に伴うユーザのストレスを抑制することができる。
(項目3) (項目2)において、第1の通知を表示するステップでは、対戦が中断されている間、第1の通知の表示を継続する。これにより、ゲームの興趣性を損なうことなく、不具合に伴うユーザのストレスを抑制することができる。
(項目4) (項目3)において、対戦ゲームにおける対戦は、スポーツ(野球)の試合であり、第1の通知を表示するステップでは、試合の審判団による審議のシーンを示す第1の画像(画像データ803)および第1のテキスト(テキストデータ802)の少なくともいずれか一方を、第1の通知とともに表示部に表示することが好ましい。これにより、ユーザに、待機の時間を短く感じさせることができる。また、通信に係る現実の不具合を通知するときに、野球の雰囲気を壊さないようにすることができる。結果として、対戦を通じてユーザが培ったゲームへの没入感は損なわれないという効果を奏する。
(項目5) (項目4)において、ゲームプログラムは、プロセッサに、審議の結果を示す第2の通知(テキストメッセージ811)を表示部に表示するステップ(S147)を実行させてもよい。これにより、ユーザは、不具合に対する対処結果を知ることができる。
(項目6) (項目5)において、第2の通知を表示するステップでは、審議の結果を審判員が発表するシーンを示す第2の画像(画像データ813)および第2のテキスト(テキストデータ812)の少なくともいずれか一方を、第2の通知とともに表示部に表示することが好ましい。これにより、通信に係る不具合に対する対処結果という現実の問題を通知するときに、野球の雰囲気を壊さないようにすることができる。特に、自端末の進行状況がリセットされ、それとは違う状況から再開しなければならなくなったユーザが抱くであろう違和感をできるだけ緩和することができる。結果として、対戦を通じてユーザが培ったゲームへの没入感は損なわれないという効果を奏する。
(項目7) (項目1)から(項目6)までのいずれか1項目において、対戦ゲームにおける対戦は、野球の試合であり、生成するステップでは、試合の所定のタイミングにおけるイニング、スコア、ランナー、アウトカウントおよびボールカウントを含む状況情報を生成してもよい。これにより、同期させるのは、野球ゲームの進行上影響がある必要最低限の情報(上述のイニング、スコア・・・など)に絞られ、クライアントとしての各コンピュータの対戦を支援するサーバは、それ以外の情報を保持したり処理したりしないで済む。その他の情報は、各クライアントで、保持および処理される。これにより、サーバの負荷を低減させることができる。
(項目8) (項目7)において、第1の通知を表示するステップでは、イニング、スコア、ランナー、アウトカウントおよびボールカウントのうち1つでも一致しない場合には、第1の通知を表示する。これにより、同期制御を実現しすることができる。また、同期ずれが発生した場合には、待たされることによりユーザが感じるストレスを軽減できるという効果を奏する。
(項目9) (項目1)から(項目7)までのいずれか1項目において、ゲームプログラムは、プロセッサに、同期ずれが発生したことを、クライアントとしての各コンピュータにおける対戦の進行を支援するサーバ(200)、および、1以上の相手ユーザの1以上の他のコンピュータの少なくともいずれか一方に通知するステップ(S141)を実行させてもよい。これにより、同期制御を実現し、通信対戦ゲームを滞りなく進行させることができる。
(項目10) (項目9)において、進行させるステップでは、各コンピュータの間で共有された、所定のタイミングにおける進行状況に基づいて対戦を再開する。これにより、同期制御を実現し、通信対戦ゲームを滞りなく進行させることができる。
(項目11) (項目1)から(項目10)までのいずれか1項目において、進行させるステップでは、1度の対戦中に、同期ずれが所定回数を超えて発生した場合に、該対戦の進行に係るユーザの操作を受け付けることなく、該対戦を進行させてもよい。これにより、頻繁に同期ずれが発生する場合でも、通信対戦ゲームを滞りなく進行させることができる。また、頻繁に対戦が中断することに基づくストレスからユーザを解放することができるという効果を奏する。
(項目12) ゲームプログラム(131)について説明した。本開示のある局面によると、ゲームプログラムは、(項目1)から(項目11)までのいずれか1項目に記載のゲームプログラムを実行する、クライアントとしての各コンピュータと通信して、各コンピュータにおける対戦の進行を支援するサーバ(200)により実行されるものである。該サーバは、プロセッサ(20)およびメモリ(21)を備える。サーバにより実行されるゲームプログラムは、サーバのプロセッサに、対戦に参加する各コンピュータにより対戦の進行上の同じタイミングで生成された状況情報を周期的に取得するステップ(S136)と、所定のタイミングにおいて同期ずれが発生した旨の通知を、対戦に参加する各コンピュータの少なくとも1台から受信するステップ(S143)と、取得された複数の状況情報に基づいて、同期ずれが発生した所定のタイミングにおける、各コンピュータに共有させる進行状況を決定するステップ(S144)と、決定された進行状況を各コンピュータに通知するステップ(S145)とを実行させる。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。同期ずれが発生することに基づくストレスからユーザを解放することができる。結果として、ゲームの興趣性を損なうことなく不具合に対処することができるという効果を奏する。
(項目13) (項目12)において、進行状況を決定するステップでは、取得された複数の状況情報のうち、いずれか1つを、所定のタイミングにおける状況情報として採用し、通知するステップでは、いずれのコンピュータが生成した状況情報を採用したのかを示す通知を各コンピュータに送信してもよい。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。同期ずれが発生することに基づくストレスからユーザを解放することができるという効果を奏する。
(項目14) (項目13)において、状況情報は、対戦に参加する各ユーザの、上述のタイミングにおける優劣を示す情報(スコア411)を含み、進行状況を決定するステップでは、同期ずれが発生する直前のタイミング(例えば、tmの前のt3)において各コンピュータによって生成された状況情報を参照し、劣勢の(負けている)ユーザが操作しているコンピュータから取得された状況情報、または、該ユーザに有利な状況情報を採用してもよい。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。
(項目15) (項目13)において、対戦ゲームにおいて、各ユーザには、対戦に勝利すると値が上がるように更新される評価値が付与されており、進行状況を決定するステップでは、評価値が低いユーザが操作するコンピュータから取得された状況情報、または、該ユーザに有利な状況情報を採用してもよい。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。
(項目16) (項目13)において、対戦ゲームにおいてユーザによって操作されるチームまたはキャラクタには、強さを示すパラメータが付与されており、進行状況を決定するステップでは、パラメータが低いチームまたはキャラクタを操作しているユーザのコンピュータから取得された状況情報、または、該ユーザに有利な状況情報を採用してもよい。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。
(項目17) (項目13)において、進行状況を決定するステップでは、1度の対戦の中で同期ずれが複数回発生している場合に、生成した状況情報が採用された回数が最も少ないコンピュータから取得された状況情報を採用してもよい。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。
(項目18) (項目13)において、進行状況を決定するステップでは、状況情報を採用するコンピュータを順番に切り替えてもよい。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。
(項目19) (項目13)において、進行状況を決定するステップでは、どのユーザに有利な状況情報を採用するのかを順番に切り替えてもよい。これにより、同期ずれを解消し、通信対戦ゲームを滞りなく進行させることができる。
(項目20) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムに基づくゲームは、コンピュータを操作するユーザと、1以上の、他のコンピュータを操作する相手ユーザとを、各コンピュータ間の通信を介して対戦させる対戦ゲームであり、ゲームプログラムは、プロセッサ、メモリ、操作部および表示部を備える、各コンピュータの少なくともいずれか1つにより実行される。該方法は、プロセッサが、ユーザと相手ユーザとの対戦を、相手ユーザが操作する他のコンピュータとの間で進行状況を同期させて、ユーザの操作にしたがって進行させるステップと、プロセッサが、進行させた対戦の進行状況を示す第1の状況情報を、対戦の進行上の所定のタイミングで生成するステップと、プロセッサが、他のコンピュータにおいて同じ所定のタイミングで生成された第2の状況情報を取得するステップと、プロセッサが、第1の状況情報と一致しない第2の状況情報がある場合に、同期ずれが発生したことを示す第1の通知を表示部に表示するステップと、を含む。(項目20)に係る方法は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目21) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、(項目1)から(項目11)までのいずれか1項目に記載のゲームプログラムを実行する、クライアントとしての各コンピュータと通信して、各コンピュータにおける対戦の進行を支援するサーバにより実行される。該サーバは、プロセッサおよびメモリを備える。該方法は、サーバのプロセッサが、対戦に参加する各コンピュータにより対戦の進行上の同じタイミングで生成された状況情報を周期的に取得するステップと、サーバのプロセッサが、所定のタイミングにおいて同期ずれが発生した旨の通知を、対戦に参加する各コンピュータの少なくとも1台から受信するステップと、サーバのプロセッサが、取得された複数の状況情報に基づいて、同期ずれが発生した所定のタイミングにおける、各コンピュータに共有させる進行状況を決定するステップと、サーバのプロセッサが、決定された進行状況を各コンピュータに通知するステップと、を含む。(項目21)に係る方法は、(項目12)に係るゲームプログラムと同様の作用効果を奏する。
(項目22) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、該ゲームプログラムに基づくゲームは、コンピュータを操作するユーザと、1以上の、他のコンピュータを操作する相手ユーザとを、各コンピュータ間の通信を介して対戦させる対戦ゲームである。該ゲームプログラムは、クライアントとしての各コンピュータと通信して、各コンピュータにおける対戦の進行を支援するサーバにより実行されるものであり、該サーバは、プロセッサおよびメモリを備える。該方法は、サーバのプロセッサが、対戦に参加する各コンピュータにより対戦の進行上の同じタイミングで生成された状況情報を周期的に取得するステップと、サーバのプロセッサが、同じタイミングで生成された各状況情報が一致しない場合に、同期ずれが発生したことを検知するステップと、サーバのプロセッサが、取得された複数の状況情報に基づいて、同期ずれが発生したタイミングにおける、各コンピュータに共有させる進行状況を決定するステップと、サーバのプロセッサが、決定された進行状況を各コンピュータに通知するステップと、を含む。(項目22)に係る方法は、(項目12)に係るゲームプログラムと同様の作用効果を奏する。
(項目23) 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、ゲームプログラムを記憶する記憶部(120)と、ゲームプログラムを実行することにより、情報処理装置(ユーザ端末100)の動作を制御する制御部(110)と、操作部と、表示部とを備える。ゲームプログラムに基づくゲームは、コンピュータを操作するユーザと、1以上の、他のコンピュータを操作する相手ユーザとを、各コンピュータ間の通信を介して対戦させる対戦ゲームである。上述の各コンピュータの少なくともいずれか1つが情報処理装置として機能する。制御部は、ユーザと相手ユーザとの対戦を、相手ユーザが操作する他のコンピュータとの間で進行状況を同期させて、ユーザの操作にしたがって進行させ、進行させた対戦の進行状況を示す第1の状況情報を、対戦の進行上の所定のタイミングで生成し、他のコンピュータにおいて同じ所定のタイミングで生成された第2の状況情報を取得し、第1の状況情報と一致しない第2の状況情報がある場合に、同期ずれが発生したことを示す第1の通知を表示部に表示する。(項目23)に係る情報処理装置は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目24) サーバを説明した。本開示のある局面によると、該サーバは、ゲームプログラムを記憶する記憶部(220)と、ゲームプログラムを実行することにより、サーバ(200)の動作を制御する制御部(210)とを備える。サーバは、(項目1)から(項目11)までのいずれか1項目に記載のゲームプログラムを実行する、クライアントとしての各コンピュータと通信して、各コンピュータにおける対戦の進行を支援するものである。サーバの制御部は、対戦に参加する各コンピュータにより対戦の進行上の同じタイミングで生成された状況情報を周期的に取得し、所定のタイミングにおいて同期ずれが発生した旨の通知を、対戦に参加する各コンピュータの少なくとも1台から受信し、取得された複数の状況情報に基づいて、同期ずれが発生した所定のタイミングにおける、各コンピュータに共有させる進行状況を決定し、決定された進行状況を各コンピュータに通知する。(項目23)に係る情報処理装置は、(項目24)に係るゲームプログラムと同様の作用効果を奏する。