JP2019024630A - ゲームプログラム、方法、および情報処理装置 - 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）ディスプレイ等によって構成される。

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

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

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

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

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

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

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

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

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

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

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

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

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

対戦支援部２１１は、各ユーザ端末１００による対戦の進行を支援する。具体的には、各ユーザ端末１００のリクエストに基づいて、対戦相手のマッチングを行ったり、必要なタイミングで、各ユーザ端末１００における対戦の進行状況の同期をとったりする。

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

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

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

例えば、操作受付部１１１は、入力部１５１に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部１１１は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部１１１は、連続して検知されていた入力が途切れると、タッチスクリーン１５から接触入力が解除されたことを検知する。

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

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

さらに本実施形態では、自チームによる攻撃の回が進行中、ＵＩ制御部１１３は、盗塁指示ボタンの表示態様を制御する。盗塁指示ボタンは、ユーザが盗塁の実施をユーザ端末１００に指示するためのＵＩオブジェクトである。また、ＵＩ制御部１１３は、盗塁の実施結果を示すＵＩオブジェクトの表示態様を制御してもよい。

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

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

対戦進行部１１５は、操作受付部１１１によって受け付けられたユーザの操作にしたがって、対戦を進行させる。一例として、対戦進行部１１５は、ユーザが操作する自チームが守備を行う回においては、ユーザの操作にしたがって、投手キャラクタを制御する。該自チームが攻撃を行う回においては、ユーザの操作にしたがって、打者キャラクタを制御する。

本実施形態では、対戦進行部１１５は、操作受付部１１１を介して、打者キャラクタに対するユーザの操作を受け付けている間に、ユーザから盗塁を指示する操作を受け付けることができる。この盗塁指示が受け付けられると、対戦進行部１１５は、相手チームの投手キャラクタが投球を２以上の所定の回数（期限投球回数）行うまでの所定のタイミングで、走者キャラクタを進塁させるための盗塁を実行する。一例として、対戦進行部１１５は、盗塁の指示を受け付けてから、投手キャラクタが３球投げ終わるまでの間に、盗塁を実施する。より詳細には、対戦進行部１１５は、上述の３球のうちのどの投球の直後に盗塁を実施するのかを決定する。そして、盗塁を実施するタイミングにおいて取得される各種パラメータに基づいて盗塁の成否を決定する。

そして、決定した盗塁の成否に基づいて対戦の状況情報を更新し対戦を進行させる。状況情報とは、対戦の進行状況を示す情報である。状況情報は、一例として、各チームの得点を示す「スコア」、走者が何塁にいるかを示す「ランナー」、「アウトカウント」、および、「ボールカウント」を含む。対戦進行部１１５は、このうち、盗塁の成否に基づいて、スコア、ランナーおよびアウトカウントを更新する。対戦進行部１１５は、ボールカウントについては、上述の盗塁が実施されたときに投球されたボールの、上述の交差面における到達位置（ストライクゾーンか、ボールゾーンか）に基づき更新する。

例えば、ユーザが操作する自チームが攻撃側であって、アウトカウントが１アウトであり、走者キャラクタが一人３塁にいる状況で、投球直後に盗塁が実施されたとする。そして、上述の走者キャラクタによる盗塁の成功が決定され、上述の投球による打者キャラクタ６０１の空振り三振が決定されたとする。この場合、対戦進行部１１５は、上述の自チームのスコアを１点加算し、ランナーを「なし」に更新し、アウトカウントを「２アウト」に更新し、ボールカウントを「ノーストライクノーボール」に更新する。

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

＜画面例＞
図３は、ユーザ端末１００の表示部１５２に表示されるゲーム画面の一具体例を示す図である。該ゲーム画面は、対戦進行部１１５によって、ＵＩ制御部１１３が生成したＵＩオブジェクトと、アニメーション生成部１１４が生成したアニメーションとを含んで生成される。生成された該ゲーム画面は、表示制御部１１２によって表示部１５２に表示される。

図３に示すゲーム画面は、具体的には、打撃側ユーザ端末１００Ｂの表示部１５２に表示される打席画面である。該打席画面には、球場を模した仮想空間をある視点（例えば、捕手キャラクタまたは主審の視点）から捉えた場面が描出され、該仮想空間に配置されている各種オブジェクトも併せて描出される。

具体的には、仮想空間には、ユーザ自身が操作する打者キャラクタ６０１、打者キャラクタ６０１が操作するバット６０２、対戦相手である守備側ユーザが操作する投手キャラクタ６０３、および、ホームベース６０７等が配置されている。なお、ボールは、仮想空間内に配置されているが、図３に示す打席画面が表示されているタイミングでは、投手キャラクタ６０３のグローブの中に配置されており、図示されていない。これらのオブジェクトのアニメーションは、アニメーション生成部１１４によって制御される。

さらに、打席画面には、ユーザが自チームを操作したり、自チームに関する情報を得たりするための各種ＵＩオブジェクトが重畳表示されてもよい。例えば、ミートカーソル６０６、選手情報６１１、モード切替ボタン６１２、および、盗塁指示ボタン６１３（盗塁指示ユーザインターフェース、盗塁指示ＵＩ）が重畳表示されてもよい。モード切替ボタン６１２は、対戦を進行させるモードをオートモードとマニュアルモードとで切り替えるためのボタンである。

本実施形態において、打者キャラクタ６０１に打撃動作を行わせる方法は、特に限定されてないが、一例として、以下のような方法が採用される。仮想空間である球場において、投手キャラクタ６０３が立っている位置（以下、第１位置）と、図示しない捕手キャラクタが立っている位置（以下、第２位置）との間に、ホームベース６０７が配置されている。対戦進行部１１５は、ホームベース６０７上に、第１位置から第２位置に向かう方向に交差する方向に延在する交差面を設定する。交差面は、例えば、ストライクゾーンと、該ストライクゾーンの外側に配置されるボールゾーンとを含んでいてもよい。これらのゾーンは、可視化され、打席画面に描出されてもよい。

さらに、ミートカーソル６０６が交差面に配置され、打席画面に描出される。ミートカーソル６０６は、バット６０２がスイングされた際に、交差面においてボールに作用を与え得る領域を示す標識である。ミートカーソル６０６は、バット６０２がスイングされたときの到達予定位置に設定される領域であり、特に良好な打撃力によってボールに作用を与えることができる領域である。

本実施形態において、打者キャラクタ６０１に打撃動作を行わせるためのコア操作は、少なくとも、ミートカーソル６０６の位置を指定するためのスワイプ操作と、ミートカーソル６０６の該位置に向けてバット６０２を振るタイミングを指定するためのフリック操作とを含む。つまり、スワイプ操作が、投球に対して打撃を行う位置を指定する操作であり、フリック操作が、該打撃を行うタイミングを指定する操作である。

本実施形態では、図３に示す打席画面が表示され、投手キャラクタ６０３が投球を開始するまでの期間、対戦進行部１１５は、盗塁指示ボタン６１３を打席画面に表示させる。盗塁指示ボタン６１３は、ユーザがユーザ端末１００に対して盗塁を指示するための盗塁指示ＵＩである。本実施形態では、ユーザは、盗塁指示ボタン６１３に対して、例えばタップ等のタッチ操作を行うことにより、ユーザ端末１００に対して盗塁を指示することができる。このように、ユーザは、上述の期間において、走者に盗塁を行わせたい場合に、ユーザ端末１００に対して、盗塁の実行を指示することができる。

なお、表示制御部１１２は、投手キャラクタ６０３が投球を開始した後の所定期間は、盗塁指示ボタン６１３を非表示にしてもよい。非表示の期間は、例えば、投げられたボールが、ホームベース６０７上に設定された交差面を通過するまで継続されてもよいし、投げられたボールが仮想空間における第１位置から第２位置へ移動している間継続されてもよい。いずれにしても、ボールが、仮想空間において、打者キャラクタ６０１が該ボールに対して何らかの打撃動作を行える位置を移動している間は、表示制御部１１２は、盗塁指示ボタン６１３を非表示にする。「ボールに対して何らかの打撃動作を行える位置」とは、「投手キャラクタ６０３に打撃動作をさせるための打撃操作をユーザが入力可能な期間に対応する、第１位置から第２位置までの間の位置」を意味する。つまり、投手キャラクタ６０３によって投げられたボールが、図示しない捕手キャラクタがいる第２位置に到達するまでの間は、打者キャラクタ６０１が、打撃動作によってボールに作用を与えられる期間である。そこで、該期間において、盗塁指示ボタン６１３を非表示にする。これにより、投手キャラクタ６０３が投球を開始した後は、ユーザは、投球を打ち返すための打撃操作に集中することができる。

本実施形態では、１度の対戦（１試合）の中で、盗塁を実行できる回数（以下、盗塁可能回数）の上限が定められていてもよい。この場合、ＵＩ制御部１１３は、その対戦中に、残りの盗塁可能回数を示す盗塁指示ボタン６１３を生成してもよい。これにより、ユーザは、あと何回盗塁が実施できるかを把握して、攻撃の戦略を練ることができる。

なお、ユーザ端末１００が、ユーザから盗塁の指示を受け付ける方法は、盗塁指示ボタン６１３だけに限られない。例えば、ユーザ端末１００は、マイク等を備えた入出力ＩＦ１４を介して入力されたユーザの音声に基づいて、盗塁の指示を受け付けてもよい。

＜盗塁処理フロー＞
図４は、ユーザ端末１００（とりわけ、打撃側ユーザ端末１００Ｂ）が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。対戦進行部１１５は、まず、ステップＳ１０１が実行される前に、対戦の現在の進行状況が、盗塁が実施できる状況か否かを判断するステップを実行する。具体的には、対戦進行部１１５は、塁に走者キャラクタいる状況では、盗塁可能と判断する。また、後述するように、現在の盗塁可能回数が１以上であれば、盗塁可能と判断する。対戦進行部１１５は、盗塁可能と判断した場合に、表示制御部１１２に対して盗塁指示ボタン６１３の表示を指示する。

ステップＳ１０１にて、表示制御部１１２は、対戦進行部１１５の制御にしたがって、盗塁の指示を受け付けるための盗塁指示ボタン６１３を表示部１５２に表示させる。例えば、表示制御部１１２は、図３に示すゲーム画面を表示する。

ユーザが、例えば、盗塁指示ボタン６１３に対してタップ操作を行うと、ステップＳ１０２にて、対戦進行部１１５は、操作受付部１１１を介して、盗塁指示を受け付ける。

ステップＳ１０３にて、対戦進行部１１５は、盗塁の実施を決定する。具体的には、盗塁指示ボタン６１３がタップ操作された時点から、相手チームの投手キャラクタ６０３が３球の投球を終えるまでの所定タイミングにて盗塁を実施することを決定する。より具体的には、３球のうちのどの投球の直後に盗塁を実施するのかを決定する。

対戦が進行し、盗塁を実施するタイミングになると、対戦進行部１１５は、ステップＳ１０４のＹＥＳから、ステップＳ１０５に進む。ステップＳ１０５にて、対戦進行部１１５は、該タイミングにおいて取得される各種パラメータに基づいて、実施される盗塁の成功確率（以下、盗塁成功確率）を決定するための処理を実行する。該処理の詳細は、別図を参照して後述する。

ステップＳ１０６にて、対戦進行部１１５は、決定した盗塁成功確率に基づいて、Ｓ１０３で実施することが決定された盗塁の成否を決定する。成否は、例えば、決定した盗塁成功確率に基づいて、抽選により決定される。ステップＳ１０７にて、対戦進行部１１５は、決定した盗塁の成否に基づいて、状況情報を更新し、対戦の進行を継続する。

対戦進行部１１５は、盗塁実施結果を表示部１５２に表示する（ステップＳ１０８）。盗塁実施結果は、一例として、盗塁が実施されたことを示す情報、または、盗塁の成否を示す情報であってもよい。該情報は、テキストデータであってもよいし、盗塁の場面を表した画像またはアニメーションであってもよい。あるいは、盗塁実施結果は、盗塁の実施に伴ってステップＳ１０７にて更新された状況情報であってもよい。これにより、ユーザは、自身が行った盗塁の指示に関して、その結果を明確に確認することができる。具体的には、盗塁が実施されたことと、その成否と、その後の対戦の進行状況とを確認することができる。つまり、ユーザは、自分自身で練り、実行した戦略に関して、明確なフィードバックを受けることができる。結果として、ゲームの興趣性をより向上させることができる。

＜盗塁可能回数について＞
本実施形態では、上述のとおり、対戦進行部１１５は、１試合中の盗塁可能回数を制限してもよい。例えば、３回に制限してもよい。この場合、対戦の開始時に、図示しない一時記憶部において、盗塁可能回数「３回」が格納される。対戦進行部１１５は、盗塁を実施する度に、ステップＳ１０４のＹＥＳ以降の任意の時点で、格納されている上述の該盗塁可能回数を１つ減じる。

対戦進行部１１５は、ステップＳ１０１の前に実行される、上述の判断するステップにおいて、その時点における盗塁可能回数を図示しない一時記憶部から読み出す。そして、盗塁が実施できるか否かを判断する。

具体的には、対戦進行部１１５は、読み出した盗塁可能回数が１以上である場合に、ＵＩ制御部１１３および表示制御部１１２を制御して、ステップＳ１０１を実行させる。このとき、対戦進行部１１５は、読み出した盗塁可能回数を示す盗塁指示ボタン６１３を、ＵＩ制御部１１３に生成させることが好ましい。一方、読み出した盗塁可能回数が１未満である場合には、対戦進行部１１５は、ＵＩ制御部１１３を制御して、盗塁指示ボタン６１３を含まないゲーム画面を生成させる。つまり、残りの盗塁可能回数が０回になった場合には、盗塁指示ボタン６１３が表示されていない打席画面が表示部１５２に表示される。この場合、ユーザは、走者が塁に出ている状況でも盗塁を指示することができない。

これにより、ユーザは、盗塁可能回数に制約がある中で、対戦中のどの状況で盗塁を指示すべきかを、より慎重に判断することが必要となり、対戦における相手ユーザとの駆け引きが一層面白くなる。結果として、ゲームの興趣性をより向上させる効果を奏する。

なお、盗塁の指示が受け付けられた後、実際には、盗塁を実施するタイミングに到達することなく、盗塁可能な状況が、盗塁不可能な状況に移行するケースも想定される。例えば、盗塁の指示が受け付けられた後、対戦が進行し、盗塁が実施されるまでに、３アウトで攻撃回が終了したり、打者キャラクタがホームランを打って、塁上に走者キャラクタが一人もいなくなったりする状況が考えられる。このような場合には、対戦進行部１１５は、上述の一時記憶部に格納されている残りの盗塁可能回数を減じることなく、一連の処理を終了する。まだ攻撃回が続いている場合には、ステップＳ１０１の前の判断するステップに戻ってもよい。受け付けられた盗塁の指示に対して、上述の事情により実際に盗塁が実施されなかった場合には、対戦進行部１１５は、その旨を通知するメッセージを表示部１５２に出力するように、ＵＩ制御部１１３および表示制御部１１２に通知してもよい。

別の実施形態では、実際に盗塁が実施されなくても、盗塁の指示が受け付けられたことに基づいて盗塁可能回数が減じられてもよい。この場合、ユーザは、盗塁が実施される可能性がより高いタイミングを計って盗塁を指示しなければならず、より高度な判断が要求される。難易度が高くなる分、戦略の立てることの面白みが増し、ゲームの興趣性をより一層向上させることが可能となる。

さらに別の実施形態では、対戦進行部１１５は、盗塁可能回数の上限を、対戦開始時に取得される、各種パラメータに基づいて、動的に決定してもよい。この場合、対戦進行部１１５は、上述の判断するステップよりも前に、各種パラメータに基づいて盗塁可能回数の上限を決定するステップを実行する。各種パラメータは、例えば、ユーザに予め付与されているレーティング等であってもよい。レーティングとは、ユーザのプレイに係る実力の指標となる評価値である。あるいは、各種パラメータは、チームに属する各選手キャラクタの能力値の合計または平均等であってもよい。あるいは、チーム自体に予め付与されている能力値またはランク等であってもよい。例えば、対戦進行部１１５は、ユーザ同士のパラメータを比較し、ユーザのパラメータが、相手ユーザのパラメータよりも値が優れている場合に、該ユーザの盗塁可能回数の上限を増やしてもよい（例えば、４回）。また、相手ユーザのパラメータの方が優れている場合には、該ユーザの盗塁可能回数の上限を減らしてもよい（例えば、２回）。つまり、ユーザは、チームまたは選手キャラクタの能力値を強化したことの恩恵を、盗塁可能回数を増加させるという形で受け取ることができる。結果として、強いチームまたは選手キャラクタを育てることに対するユーザの動機付けを強化することができる。

＜盗塁実施タイミングについて＞
ステップＳ１０４において、対戦進行部１１５は、相手チームの投手キャラクタが今後投げる３球のうち、どの投球の直後に盗塁を実施するのかを決定する。対戦進行部１１５は、盗塁を実施するタイミングを決定する方法としては、例えば、以下の２つの方法がある。

第１の方法は、ステップＳ１０３にて盗塁を実施することが決まった後、投手キャラクタが次の投球を開始するまでに、いつ盗塁するのかを１回の抽選で決定する方法である。具体的には、対戦進行部１１５は、これから投げられる３球のうちのいずれの投球の直後に盗塁を実施するのかを１回の抽選で決定する。より詳細には、対戦進行部１１５は、「１球目（で盗塁する）」、「２球目」および「３球目」の３つの出目で構成された抽選を、所定の確率に基づいて、実行する。例えば、３つの出目の当選確率は、１／３ずつ均等であってもよい。この場合、純粋にランダムに、３球の投球の中から盗塁を実施するタイミングが決定される。あるいは、対戦進行部１１５は、３つの出目のそれぞれの当選確率を変動させた上で抽選を実行してもよい。ステップＳ１０４では、対戦進行部１１５は、上述の抽選によって当選した出目の投球が行われた直後に、ＹＥＳと判断する。

第２の方法は、ステップＳ１０３にて盗塁を実施することが決まった後、投手キャラクタが投球を行う直前のタイミングにおいて抽選を実行し、その投球で盗塁するのかしないのかを都度決定していく方法である。この方法では、Ｎ球以内に盗塁すると定められている場合、ステップＳ１０４において、少なくとも１回、最大でＮ−１回の抽選が繰り返し実行される。例えば、３球以内に盗塁するという実施形態においては、対戦進行部１１５は、１球目で１回目の抽選を実行して、盗塁するか否かを決定し、１球目で盗塁しなかった場合には、２球目で２回目の抽選を実行して、盗塁するか否かを決定する。２球目で盗塁しなかった場合には、必ず３球目で盗塁が実行されるので、抽選は行われない。

より詳細には、対戦進行部１１５は、１球目の投球直前に、該１球目で盗塁するか否かを抽選に基づき決定する。すなわち、出目が、「（１球目で）盗塁する」および「盗塁しない」の２種類の抽選を実施する。２つの出目の当選確率は、例えば、それぞれ、１／３、および、２／３であってもよい。対戦進行部１１５は、当選した出目に応じて、ステップＳ１０４におけるＹＥＳまたはＮＯを判断する。

１球目で「盗塁しない」の出目が当選した場合、ステップＳ１０４のＮＯから、再び、ステップＳ１０４に戻り、対戦進行部１１５は、２球目の投球直前に、該２球目で盗塁するか否かを抽選に基づき決定する。すなわち、出目が、「（２球目で）盗塁する」および「盗塁しない（＝３球目で盗塁する）」の２種類の抽選を実施する。２つの出目の当選確率は、例えば、１／２ずつであってもよい。対戦進行部１１５は、当選した出目に応じて、ステップＳ１０４におけるＹＥＳまたはＮＯを判断する。

２球目で「盗塁しない」が当選した場合、ステップＳ１０４のＮＯから、再び、ステップＳ１０４に戻り、対戦進行部１１５は、３球目の投球直前に、抽選を実行することなく、３球目が盗塁の実施タイミングであると決定する。対戦進行部１１５は、「３球以内に盗塁する」という所定の規則と、１〜２球目で「盗塁しない」が当選したこととに基づいて、ステップＳ１０４におけるＹＥＳを判断する。結果的に、上述の当選確率によれば、１球目から３球目までのそれぞれのタイミングで盗塁が実施される確率は、１／３ずつ均等となる。

第２の方法において、対戦進行部１１５は、上述の当選確率を、対戦に出場させている選手キャラクタの属性情報、および、対戦の進行状況を示す状況情報の少なくともいずれかに基づいて、変動させてもよい。属性情報とは、例えば、打席およびマウンドにいる選手キャラクタに付与されている能力値または特性等を含む。特性とは、具体的には、投手キャラクタが投げるときに得意とする球種またはコース、および、打者キャラクタが打つときに得意とする球種またはコース等である。状況情報は、例えば、抽選を実行する直前の時点のボールカウント、アウトカウント、ランナー、もしくは、投手キャラクタがこれまで投げてきた球種またはコース等の投球履歴を含む。

現実の試合では、監督から盗塁の指示を受けた走者は、何も判断することなくただちに盗塁を実施するとはかぎらない。走者は、対戦の進行状況（とりわけ、ボールカウント）、投手の投球履歴、次の投球予測、および、投手と打者との力関係または相性等に基づいて、いつ盗塁を実施するのかを判断している。

上述の方法によれば、１回の投球ごとに、そのときの進行状況に応じて、「盗塁する」および「盗塁しない」の２つの出目の当選確率が変動する。したがって、本ゲームにおいて、上述したような、現実の野球の試合で行われる盗塁をより忠実に再現することができる。これによりゲームの興趣性をより一層向上させることが可能となる。

例えば、対戦進行部１１５は、ボールカウントが投手側に有利な状況である場合（２ストライクノーボール等）、１球目で盗塁する確率を下げてもよい。あるいは、投手キャラクタの得意な決め球が変化球であって、該変化球で勝負してくる可能性が高い状況である場合（２ストライク３ボール等）、対戦進行部１１５は、その投球で盗塁する確率を上げてもよい。

上述の例では、盗塁指示を受け付けてから実際に盗塁が実施されるべき期限を定めている期限投球回数は、「投手キャラクタが『３球』投げるまで」と定められているが、期限投球回数は、「２球」以上であれば特に限定されない。期限投球回数が、複数の投球数であることは、以下の作用効果をもたらす。

つまり、本ゲームにおいて、盗塁がユーザの指示後にただちに実行されるとは限らないという仕様を実現することができる。該仕様によれば、ユーザは、盗塁を指示してから、実際に盗塁が実施されるまでの間の投球に対して、打者キャラクタにどのような打撃動作を行わせるのかを、戦略的に決定することができる。そして、ユーザは、戦略を駆使して、相手ユーザが制御する投手キャラクタの配球を読み、駆け引きを楽しみながら、プレイすることができる。

また、上述の仕様は、現実の野球の試合をより忠実に再現している。現実の野球においては、監督は走者に対して盗塁を指示するものの、その実施のタイミングについては、走者に判断を委ねることが多く、指示後ただちに盗塁が実施されずに、走者の思うタイミングで実施されることが通常である。上述の仕様により、あたかも現実の野球で盗塁を指示する監督になったような体験をユーザに提供することができ、ゲームの興趣性がより一層向上する。

別の実施形態では、期限投球回数は、固定的に「『２以上の所定球数』以内」と定められておらず、対戦進行部１１５が、対戦開始時に取得される上述の各種パラメータに基づいて、あるいは、ランダムに変更するものであってもよい。この場合、対戦進行部１１５は、図４に示すステップＳ１０１が実行されるよりも前に、期限投球回数を決定するステップ（回数を決定するステップ）を実行する。

例えば、固定的に、「『３球』以内」と期限投球回数が定められている場合、ユーザは、プレイ回数を重ねるうちに、「指示後３球以内に必ず盗塁が実施される」という知見を得る可能性がある。この場合、いつ盗塁が実施されるのか明確には分からない中で駆け引きを楽しめるという利点、および、監督の立場を追体験できるという利点が、若干損なわれる虞がある。期限投球回数の決定機構を、完全にブラックボックス化することにより、ユーザは、上述の利点を、少しも損なうことなく最大限に享受することが可能となる。

＜盗塁成功確率に係る補正テーブル＞
図５は、盗塁成功確率を補正するための補正テーブルのデータ構造の一具体例を示す図である。該補正テーブルは、ユーザ端末１００の記憶部１２０において、ゲーム情報１３２として格納されている。該補正テーブルは、対戦進行部１１５がステップＳ１０５にて、盗塁成功確率を決定するために、対戦進行部１１５によって参照される。

本実施形態では、一例として、基準の盗塁成功確率が予め定められている。対戦進行部１１５は、この基準の盗塁成功確率に対して、各種パラメータに基づいて得られた確率補正値を適用し、盗塁成功確率を変動させて、最終的な盗塁成功確率を出力する。なお、各種パラメータとしては、とりわけ、盗塁が実施されるタイミングの基準となった投球場面に関わるあらゆる情報が取得される。

補正テーブルは、一例として、因子、条件、補正値の各カラムを含む。カラム「因子」には、盗塁の成功または失敗という結果を生じさせる要素の１つ１つが格納されている。カラム「条件」には、該因子に関して、上述の投球場面において想定され得る結果が体系化されて格納されている。カラム「補正値」には、想定される得る結果ごとに、該結果が得られたときに適用する補正値が格納されている。一例として、該補正値は、成功の確率に対して適用する補正値が示している。

（因子：パラメータ比較）
盗塁の成否を決める因子の一つに、盗塁の場面における当事者の能力がある。具体的には、盗塁を実施する走者の走力、および、盗塁を阻止する捕手の肩の力が、盗塁の成否を決める因子となり得る。野球の試合において、走者の走力が高ければ、盗塁は成功しやすくなり、捕手の肩の力が強ければ、盗塁は失敗しやすくなると考えられる。

そこで、本実施形態では、走者キャラクタの属性情報および捕手キャラクタの属性情報に応じて、成功確率を変動させるための補正値を設定する。具体的には、走者キャラクタの走る力を示す走力パラメータが、捕手キャラクタのボールを投げる力（肩の力）を示す肩力パラメータを上回るという条件に対して、成功確率に対する補正値「＋１０％」を対応付けておく。走力パラメータと肩力パラメータとが同じという条件に対して、補正値「±０％」を対応付けておく。走力パラメータが肩力パラメータを下回るという条件に対して、補正値「−１０％」を対応付けておく。なお、走力パラメータと、肩力パラメータとは、例えば、同じ尺度で数値化され、数値同士を単純比較できるようになっていてもよい。

上述のデータ構造によれば、対戦進行部１１５は、上述の投球場面における当事者間のパラメータの比較結果に応じて、成功確率を補正するための補正値を１つ取得することができる。これにより、本ゲームの対戦における進行状況と、盗塁の成否との因果関係を、現実の野球の試合においてみられる因果関係に、より近づけることができる。結果として、本ゲームにて、現実の野球の試合をしているかのような体験をユーザに提供することができる。

（因子：球種）
盗塁の成否を決める因子の一つに、盗塁の直前で投げられた球の球種がある。具体的には、一般的に、球種によって球速が異なり、ボールが投手の手を離れてから、捕手のミットに届くまでの時間が盗塁の成否を決める因子となり得る。野球の試合において、球速が遅く、ボールが捕手の手に渡るまでに時間がかかれば盗塁は成功しやすくなり、球速が早く、ボールが早く捕手の手に渡れば盗塁は失敗しやすくなると考えられる。

そこで、本実施形態では、例えば、投手キャラクタが投げる球種のうち、カーブ等の球速が遅い球種に対して、補正値「＋１０％」を対応付けておく。例えば、ストレート等の球速が早い球種に対して、補正値「−１０％」を対応付けておく。なお、例えば、スライダー等、球速がカーブとストレートとの中間くらいの球種に対しては、補正値「±０％」を対応付けておいてもよい。図示は一例にすぎず、他のあらゆる球種に対して、その一般的な球速に応じて、あらゆる補正値が対応付けられていてもよい。具体的には、球速が遅い球種ほど盗塁成功確率が高くなるように補正値が設定される。

上述のデータ構造によれば、対戦進行部１１５は、上述の投球場面において投げられた球の球種に応じて、成功確率を補正するための補正値を１つ取得することができる。これにより、本ゲームの対戦における進行状況と、盗塁の成否との因果関係を、現実の野球の試合においてみられる因果関係に、より近づけることができる。結果として、本ゲームにて、現実の野球の試合をしているかのような体験をユーザに提供することができる。

（因子：コース）
盗塁の成否を決める因子の一つに、盗塁の直前で投げられた球のコースがある。具体的には、一般的に、コースによって捕手の捕球時における体勢はさまざまである。そして、捕球時の体勢から、盗塁を阻止するための送球の体勢、すなわち立位の姿勢に移るのにどのくらい時間を要するのかが、盗塁の成否を決める因子となり得る。野球の試合において、低めのコースの投球を捕球する場合、捕手は、しゃがんだり、膝をついたり、体勢を崩して手を伸ばして捕球する。そのため、捕球後ただちに送球の体勢をとることができないため、その分塁を守る野手にボールが届くのが遅れ、盗塁は成功しやすくなると考えられる。反対に、高めのコースの投球を捕球する場合、捕手は、例えば、腰を浮かす等して立位の姿勢に近い体勢となるため、捕球後ただちに送球の体勢をとることができる。そのため、盗塁は失敗しやすくなると考えられる。

そこで、本実施形態では、投手キャラクタが投げるコースのうち、例えば、低めのコースに対して、補正値「＋１０％」を対応付けておき、高めのコースに対して、補正値「−１０％」を対応付けておく。

上述のデータ構造によれば、対戦進行部１１５は、上述の投球場面において投げられた球のコースに応じて、成功確率を補正するための補正値を１つ取得することができる。これにより、本ゲームの対戦における進行状況と、盗塁の成否との因果関係を、現実の野球の試合においてみられる因果関係に、より近づけることができる。結果として、本ゲームにて、現実の野球の試合をしているかのような体験をユーザに提供することができる。

（因子：打席結果）
盗塁の成否を決める因子の一つに、盗塁の直前で投げられた球に対する打者の打撃動作がある。具体的には、一般的に、打者が空振りするか見逃すかによって、捕手の送球のタイミングが変わるので、これが盗塁の成否を決める因子となり得る。野球の試合において、打者が空振りして、捕手の目前で体勢を崩している場合には、送球のタイミングが遅れ、盗塁は成功しやすくなる。一方、打者が投球を見送れば、捕手の視界は遮られることがないので、投球のタイミングが遅らされることはなくなり、盗塁は失敗しやすくなる。

そこで、本実施形態では、盗塁が実施されたときに打者キャラクタがとり得る打撃動作のうち、「空振り」に対して、補正値「＋１０％」を対応付けておき、「見逃し」に対して、補正値「−１０％」を対応付けておく。

上述のデータ構造によれば、対戦進行部１１５は、上述の投球場面においてとられた打者キャラクタの打撃動作に応じて、成功確率を補正するための補正値を１つ取得することができる。これにより、本ゲームの対戦における進行状況と、盗塁の成否との因果関係を、現実の野球の試合においてみられる因果関係に、より近づけることができる。結果として、本ゲームにて、現実の野球の試合をしているかのような体験をユーザに提供することができる。

（因子：捕手適性）
盗塁の成否を決める因子として、捕手の能力が与える影響は大きい。盗塁の阻止に着目しても、捕手のポジションを守る選手には、捕手としての専門的な能力が要求される。

そこで、本実施形態では、チーム編成において、相手チームの捕手のポジションに配置された選手キャラクタ、すなわち、捕手キャラクタの属性情報に基づいて、盗塁成功確率が補正されてもよい。ここでは、属性情報は、具体的には、各選手キャラクタに予め付与されている適性ポジションの情報を指す。属性情報の１つとして付与される適性ポジションには、現実の野球と同様に、例えば、投手、捕手、一塁手、遊撃手・・・等が含まれる。選手キャラクタには、複数種類の適性ポジションが付与されてもよい。以下では、適正ポジションとして、「捕手」が付与されていることを「捕手適性がある」、「捕手適性あり」等と表現する。

本実施形態では、相手チームの捕手キャラクタに、「捕手」の適性ポジションが付与されていないという条件に対して、補正値「＋１０％」を対応付けておく。一方、「捕手」の適性ポジションが付与されているという条件に対して、補正値「−１０％」を対応付けておく。

上述のデータ構造によれば、対戦進行部１１５は、盗塁の場面における当事者としての捕手キャラクタの適性に基づいて、成功確率を補正するための補正値を１つ取得することができる。これにより、本ゲームの対戦における進行状況と盗塁の成否との因果関係に関わる因子を多様にし、ゲームの興趣性をより一層向上させることができる。

なお、現実の野球においては、ゲームとは異なり、捕手以外の選手が捕手のポジションに就くということがレアケースであると考えられる。しかし、上述のデータ構造は、本ゲームの対戦における進行状況と盗塁の成否との因果関係を、現実の野球の試合における因果関係から遠ざけることにはならない。現実の野球においても、専門性の高い特殊な能力が要求される捕手のポジションに、捕手の適性がない選手が就けば、当然ながら、盗塁の成功確率は高くなると考えられるからである。結果として、上述のデータ構造によれば、本ゲームにて、現実の野球の再現性を損なうことなく、ゲームの興趣性をより一層向上させることが可能となる。

＜盗塁成功確率決定処理フロー＞
図６は、ユーザ端末１００（とりわけ、打撃側ユーザ端末１００Ｂ）が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。図６に示す各処理は、図４に示すステップＳ１０５の盗塁成功確率決定処理に対応する。

ステップＳ２０１にて、対戦進行部１１５は、走力パラメータと肩力パラメータとを比較する。ここで、上述の走力パラメータは、対戦進行部１１５が、自チームに属する選手キャラクタのうち、出塁中の走者キャラクタの走力パラメータを記憶部１２０から読み出したものである。また、上述の肩力パラメータは、対戦進行部１１５が、相手チームに属する捕手キャラクタの肩力パラメータをサーバ２００から取得したものである。詳細には、対戦進行部１１５は、図４に示すステップＳ１０４においてＹＥＳと判断されたタイミングに対応する投球が行われた場面において、捕手のポジションに就いていた捕手キャラクタの肩力パラメータを取得する。

ステップＳ２０２にて、対戦進行部１１５は、例えば、図５に示す補正テーブルを参照し、比較結果に応じた補正値を取得する。

ステップＳ２０３にて、対戦進行部１１５は、上述の補正テーブルを参照し、球種に応じた補正値を取得する。具体的には、対戦進行部１１５は、図４に示すステップＳ１０４においてＹＥＳと判断されたタイミングに対応する投球に関し、サーバ２００から投球結果Ｄ１を受信する。そして、投球結果Ｄ１に含まれている球種を読み出して、該球種に応じた補正値を取得する。

ステップＳ２０４にて、対戦進行部１１５は、上述の補正テーブルを参照し、コースに応じた補正値を取得する。具体的には、対戦進行部１１５は、上述の投球結果Ｄ１に含まれているコースを読み出して、該コースに応じた補正値を取得する。

ステップＳ２０５にて、対戦進行部１１５は、上述の補正テーブルを参照し、打席結果に応じた補正値を取得する。具体的には、対戦進行部１１５は、図４に示すステップＳ１０４においてＹＥＳと判断されたタイミングに対応する投球に対して、打者キャラクタが起こした打撃動作が空振りか見逃しかに応じて補正値を取得する。

ステップＳ２０６にて、対戦進行部１１５は、上述の補正テーブルを参照し、捕手適性に応じた補正値を取得する。具体的には、対戦進行部１１５は、図４に示すステップＳ１０４においてＹＥＳと判断されたタイミングに対応する投球が行われた場面において、捕手のポジションに就いていた捕手キャラクタの適性ポジションを取得する。そして、該捕手キャラクタに付与されている適性ポジションの中に「捕手」が含まれているか否かに応じて補正値を取得する。

ステップＳ２０７にて、対戦進行部１１５は、上述のステップＳ２０２〜Ｓ２０６において取得した各補正値に基づいて、盗塁成功確率を決定する。一例として、対戦進行部１１５は、予め定められた基準の盗塁成功確率に対して、取得した各補正値を適用し、最終的な盗塁成功確率を算出してもよい。具体的には、基準の盗塁成功確率が「盗塁成功５０％」、すなわち、「盗塁失敗５０％」と、予め定められているとする。ここで、５つの因子につき取得された補正値が、それぞれ、「＋１０％」、「±０％」、「＋１０％」、「＋１０％」および「−１０％」であるとする。この場合、対戦進行部１１５は、これらの補正値を基準の盗塁成功確率に適用して（具体的には、５０％＋１０％＋１０％＋１０％−１０％を計算して）、最終的な盗塁成功確率を、「盗塁成功７０％」、すなわち、「盗塁失敗３０％」と決定する。

ステップＳ２０７にて出力された最終的な盗塁成功確率は、図４に示すステップＳ１０６にて、対戦進行部１１５によって利用される。

＜効果＞
上述の本実施形態によれば、戦略が多様化し、対戦相手との駆け引きが一層面白くなる。結果として、対戦型野球ゲームの興趣性が向上する。

具体的には、本実施形態に係る上述のゲームシステムによれば、攻撃側ユーザが、打撃側ユーザ端末１００Ｂにおいて盗塁を指示しても、その後ただちに盗塁が実施されるとは限らない。このため、攻撃側ユーザは、盗塁を指示してから、実際に盗塁が実施されるまでの間の投球に対して、打者キャラクタにどのような打撃動作を行わせるのかを、戦略的に決定することができる。

例えば、攻撃側ユーザは、安打が出やすい球種（ストレート）だけを狙って、打者キャラクタのスイングを操作することができる。ストレート待ちをしていると、変化球が来た場合に、空振りするリスクが大きくなる。しかし、盗塁指示後の状況では、このことが盗塁成功確率を上げることにつながるため、空振りをリスクと捉えずに、積極的にストレートを狙える。また、盗塁成功確率を上げるために、高めのコースのボールを見逃さずに打ちに行くという戦略も立てられる。

以上のように、多様化する戦略を駆使して、攻撃側ユーザは、対戦相手の守備側ユーザが操作する投手キャラクタの配球を読み、駆け引きを楽しみながら、プレイすることができる。

また、盗塁がユーザの指示後にただちに実行されるとは限らないという仕様は、現実の野球の試合での現象に似通っている。現実の野球においても、監督は走者に対して盗塁するタイミングの判断を委ねることが多く、指示後ただちに盗塁が実施されずに、走者の思うタイミングで実施されることが通常である。このような仕様により、あたかも現実の野球で盗塁を指示する監督になったような体験をユーザに提供することができ、ゲームの興趣性がより一層向上する。

＜変形例＞
図５に示す例では、対戦進行部１１５が盗塁成功確率を補正するために参照する因子として、上述の５種類を示した。しかし、対戦進行部１１５は、このすべてを参照せずともよく、これらのうちのいずれか１つに基づいて、または、任意のいくつかを参照して組み合わせることにより、盗塁成功確率を補正してもよい。また、補正値の具体的な数値「＋１０％」、「±０％」、および、「−１０％」は、一例にすぎず、任意の値が採用され得る。

図６に示すステップＳ２０１およびＳ２０２に代わり、あるいは、加えて、対戦進行部１１５は、走者キャラクタの走力パラメータおよび捕手キャラクタの肩力パラメータのいずれか一方に基づいて補正値を取得してもよい。例えば、対戦進行部１１５は、捕手キャラクタの肩力パラメータを参照せず、走者キャラクタの走力パラメータに基づく補正値を取得してもよい。一例として、対戦進行部１１５は、走者キャラクタの走力パラメータが所定値以上である場合に、補正値「＋１０％」を取得し、該所定値未満である場合に補正値「−１０％」を取得してもよい。あるいは、対戦進行部１１５は、走者キャラクタの走力パラメータを参照せず、捕手キャラクタの肩力パラメータに基づく補正値を取得してもよい。一例として、対戦進行部１１５は、相手チームの捕手キャラクタの肩力パラメータが所定値以上である場合に、補正値「−１０％」を取得し、該所定値未満である場合に補正値「＋１０％」を取得してもよい。

上述の構成によれば、相手チームの選手キャラクタとの相対的な能力の高さに基づかず、自チームの選手キャラクタの能力値に基づいて、盗塁の成否が決定される。これにより、ユーザが、自チーム（とりわけ、走者キャラクタまたは捕手キャラクタ）の強化のためのプレイを行ったことが、そのまま、盗塁の成功のしやすさ、または、盗塁の阻止のしやすさという形で、報われる。結果として、ユーザのプレイに対する動機付けを強化することができる。

基準の盗塁成功確率は、上述したとおり、５０％で固定であってもよいし、盗塁を実施させる選手キャラクタに応じて変動させてもよい。具体的には、選手キャラクタごとに、基準の盗塁成功確率が予め定められていてもよい。

図６に示す盗塁の成功確率を決定するための処理において、ステップＳ２０２〜Ｓ２０６の各ステップは、図示されたステップ番号順に実行されずとも、任意の順に実行されればよいし、適宜省略されてもよい。なお、ステップＳ２０１は、ステップＳ２０２が省略されない場合に、ステップＳ２０２よりも前の任意のタイミングで実行されればよい。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック（特に、対戦支援部２１１）、ならびに、制御部１１０の制御ブロック（特に、操作受付部１１１、表示制御部１１２、ＵＩ制御部１１３、アニメーション生成部１１４および対戦進行部１１５）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（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