JP2019136552A

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

Info

Publication number: JP2019136552A
Application number: JP2019093247A
Authority: JP
Inventors: 潤哉福重; Junya Fukushige
Original assignee: Colopl Inc
Current assignee: Colopl Inc
Priority date: 2019-05-16
Filing date: 2019-05-16
Publication date: 2019-08-22

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

ゲームプログラムであって、
前記ゲームプログラムは、プロセッサおよびメモリを備える、１または複数のコンピュータにより実行されるものであり、
前記ゲームプログラムに基づくゲームは、複数の選手から成るチーム同士が対戦する対戦ゲームであって、所定の動作を行う機会が、１または複数の選手に順番に与えられて進行する対戦ゲームであり、
前記ゲームプログラムは、前記プロセッサの少なくともいずれか１つに、
デジタルコンテンツとしての選手であって、複数のユーザのそれぞれが所有する選手の中からそれぞれ１人以上選出された選手からなる協力チームを生成するステップと、
前記協力チームと、該協力チームと対戦する相手チームとの対戦を進行させるステップと、を実行させ、
前記対戦を進行させるステップでは、前記順番が回ってきた選手の動作を、該選手を所有するユーザが、該ユーザが操作するコンピュータに対して実施した入力操作にしたがって決定する、ゲームプログラム。
前記生成するステップでは、前記協力チームに含める選手を、各ユーザが所有する複数の選手の中からランダムに選出する、請求項１に記載のゲームプログラム。
ユーザが所有する選手からなるユーザの固有チーム、および、前記協力チームは、デッキによって定義され、該デッキは、チームを構成する役割ごとに所定数の枠を有し、該デッキにおいて前記枠に前記選手を紐付けることによって該選手の役割が設定されるものであり、
前記生成するステップでは、前記協力チームのデッキにおいて、前記ユーザのデッキにおいて設定されている役割と同じ役割が選手に設定されるように、かつ、前記協力チームを構成する役割のすべての枠に選手が紐付けられるように、各ユーザのデッキから選手を選出する、請求項２に記載のゲームプログラム。
前記対戦ゲームにおいて進行される対戦は、野球の試合であり、前記固有チームを定義するデッキは、野手のスターティングメンバーを構成するために必要な枠を有する野手デッキを含み、
前記生成するステップでは、前記協力チームにおける野手のスターティングメンバーを、各ユーザの各野手デッキにおいて各選手に設定されている野手のポジションが、前記協力チームのデッキにおいて重複しないように、各野手デッキから選出する、請求項３に記載のゲームプログラム。
前記固有チームを定義するデッキは、先発投手の枠を所定数有する先発投手デッキと、リリーフ投手の枠を所定数有するリリーフ投手デッキとを含み、
前記生成するステップでは、前記協力チームにおける先発投手を、各ユーザの前記先発投手デッキのいずれか１つから１人選出し、前記協力チームにおけるリリーフ投手を、各ユーザの前記リリーフ投手デッキから１または複数選出する、請求項４に記載のゲームプログラム。
前記対戦ゲームは、前記協力チームが前記相手チームと対戦する第１のゲーム要素に加えて、ユーザが操作するチームと他のユーザが操作するチームとが対戦する第２のゲーム要素をさらに含み、各ユーザには、前記第２のゲーム要素における対戦の結果に基づいて増減させる評価値が設定されており、
前記生成するステップでは、前記所定の動作を行う出番が、各ユーザが所有する選手の間で巡回するように、かつ、設定されている前記評価値に基づいて、前記所定の動作を行
う順番を決定する、請求項１から５のいずれか１項に記載のゲームプログラム。
前記対戦ゲームにおいて進行される対戦は野球の試合であり、
前記生成するステップでは、前記評価値が高いユーザの選手の出番が先になるように打順を決定する、請求項６に記載のゲームプログラム。
前記生成するステップでは、さらに、各選手に紐付けられている属性を考慮して前記順番を決定し、
前記属性は、前記選手の能力を表すパラメータ、および、前記選手に設定された前記チームにおける役割の少なくともいずれか一方を含む、請求項６または７に記載のゲームプログラム。
前記生成するステップでは、前記協力チームにおける先発投手に１番の登板順を割り当て、前記評価値に基づいて、前記協力チームにおける複数のリリーフ投手に２番以降の登板順を割り当てる、請求項８に記載のゲームプログラム。
前記対戦を進行させるステップでは、
前記対戦が進行する仮想空間に、前記協力チームの各選手と、前記相手チームの各選手と、仮想カメラとを配置し、
配置された仮想カメラの位置と向きとに基づいて、前記ユーザに視認させる視界領域を設定し、
前記視界領域に基づいて生成された視界画像を、前記ユーザが操作するコンピュータの表示部に表示し、
前記仮想カメラは、前記仮想空間に配置された、少なくとも前記ユーザが所有するいずれかの選手の位置と向きとに基づいて、該仮想空間に配置される、請求項１から９のいずれか１項に記載のゲームプログラム。
ゲームプログラムであって、
前記ゲームプログラムは、プロセッサおよびメモリを備えるサーバにより実行されるものであり、
前記ゲームプログラムに基づくゲームは、複数の選手から成るチーム同士が対戦する対戦ゲームであり、該対戦ゲームは、複数のユーザが協力して操作する協力チームが相手チームと対戦する第１のゲーム要素を少なくとも含み、
前記メモリは、前記ゲームプログラムに基づくゲームをプレイするユーザのそれぞれが所有するデジタルコンテンツとしての選手をユーザごとに記憶するように構成されており、
前記ゲームプログラムは、前記プロセッサに、
前記対戦で協力し合う複数のユーザを、各ユーザの前記対戦ゲームにおけるプレイ履歴、および、各ユーザが所有する選手の少なくともいずれか一方に基づいてグルーピングするステップと、
グルーピングされた前記複数のユーザのそれぞれが所有する選手の中からそれぞれ１人以上選出された選手からなる協力チームを生成するステップと、
前記協力チームと前記相手チームとの対戦を進行させるステップと、を実行させ、
前記対戦を進行させるステップでは、前記対戦における選手の動作を、該選手を所有するユーザが、該ユーザが操作するコンピュータに対して実施した入力操作にしたがって決定する、ゲームプログラム。
前記対戦ゲームは、ユーザが操作するチームと他のユーザが操作するチームとが対戦する第２のゲーム要素をさらに含み、
前記プレイ履歴は、前記第１のゲーム要素および前記第２のゲーム要素の少なくともい
ずれか一方における対戦の対戦履歴である、請求項１１に記載のゲームプログラム。
前記対戦履歴は、前記第２のゲーム要素において、各ユーザに設定され、対戦の結果に基づいて増減される評価値であり、
前記グルーピングするステップでは、前記評価値が近いユーザ同士をグルーピングする、請求項１２に記載のゲームプログラム。
ユーザが所有する選手からなるユーザの固有チーム、および、前記協力チームは、デッキによって定義され、
前記グルーピングするステップでは、前記デッキに組み入れられている１以上の選手の強さに基づいて算出される、前記デッキの強さを意味するデッキ総合パラメータの値が近いユーザ同士をグルーピングする、請求項１１から１３のいずれか１項に記載のゲームプログラム。
コンピュータがゲームプログラムを実行する方法であって、
前記コンピュータは、プロセッサおよびメモリを備え、
前記プロセッサが請求項１に記載の各ステップを実行する方法。
情報処理装置であって、
前記情報処理装置は、
請求項１に記載のゲームプログラムを記憶する記憶部と、
該ゲームプログラムを実行することにより、前記情報処理装置の動作を制御する制御部とを備えている、情報処理装置。
サーバがゲームプログラムを実行する方法であって、
前記コンピュータは、プロセッサおよびメモリを備え、
前記プロセッサが請求項１１に記載の各ステップを実行する方法。
情報処理装置であって、
前記情報処理装置は、
請求項１１に記載のゲームプログラムを記憶する記憶部と、
該ゲームプログラムを実行することにより、前記情報処理装置の動作を制御する制御部とを備えている、情報処理装置。