JP2023124466A - ゲームシステム、ゲーム制御装置及びプログラム - Google Patents

Abstract

【課題】ゲーム条件による使用対象の使い分けを可能としながら、マッチングされ難かった条件においてもマッチングの機会を増やすことができるようにする。【解決手段】登録部は、ユーザの操作に基づいて、少なくとも１つのオブジェクトを含む使用対象を複数登録する。条件設定部は、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を可能とする。マッチング部は、前記条件設定を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングする。ゲーム実行部は、前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行する。【選択図】図１０

Description

本発明はゲームシステム、ゲーム制御装置及びプログラムに関する。

従来より、マッチングされたユーザ同士がネットワークを介して対戦することができるオンラインゲームが知られている。ユーザは、マッチングの条件を設定して対戦相手を探すことができる。

特開２０１１－１５６２８４号公報

例えば、各ユーザが任意に参加可能な複数のリーグを設けた場合、ユーザはマッチングの条件として何れかのリーグを指定することができる。この場合、参加人数が多いリーグにユーザが集まる傾向がある。このため、特定の１つのリーグに人が集中してしまい、参加人数が少ないリーグでプレイしたいユーザにとっては、簡単にはマッチングが成立せずに待ち時間が長くなり、満足にゲームを楽しめない場合があり得る。

そこで、本発明の目的の一つは、マッチングされ難かった条件においてもマッチングの機会を増やすことができるようにすることである。

本発明の一態様によるゲームシステムまたはゲーム制御装置は、ユーザの操作に基づいて、少なくとも１つのオブジェクトを含む使用対象を複数登録する登録手段と、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段と、前記条件設定を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングするマッチング手段と、前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段と、を含む。

本発明の他の一態様によるゲーム制御装置は、ユーザの操作に基づいて、少なくとも１つのオブジェクトを含む使用対象を複数登録する登録手段と、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段と、前記条件設定を伴うマッチング要求に基づいてマッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段と、を含む。

本発明の一実施の形態に係るゲームシステムの構成例を示す概略のブロック図である。 イベントデッキの表示画面の一例を示す図である。 主人公キャラクタの能力一覧画面の一例を示す図である。 リアルタイム対戦モードのトップ画面の一例を示す図である。 育成選手オーダー設定画面の一例を示す図である。 検索設定画面の一例を示す図である。 対戦前確認画面の一例を示す図である。 キャラクタ情報テーブルの一例を示す図である。 マッチング処理の一例を説明するための図である ゲームシステムの機能的な構成の一例を示す概略の機能ブロック図である。 ユーザ情報テーブルの一例を示す図である。 ゲーム条件テーブルの一例を示す図である。 チームオーダーテーブルの一例を示す図である。 所持キャラクタデータの一例を示す図である。 チームオーダーデータの一例を示す図である。 検索設定画面の他の一例を示す図である。 チームオーダーテーブルの他の一例を示す図である。 ゲームシステムの処理の一例を示すフローチャートである。 ゲームシステムの処理の一例を示すシーケンスチャートである。

以下、本発明の実施形態の一例を、図面を参照しながら説明する。

［１．ゲームシステムの構成］
図１は、本発明の実施の形態に係るゲームシステム１の構成例を示す概略のブロック図である。このゲームシステム１は、複数のゲーム端末１０－ｎ（ｎは正の整数。１０－１、１０－２、・・・）と、サーバ３０とを含んでいる。ゲームシステム１内のゲーム端末１０－ｎ及びサーバ３０は、インターネットなどのネットワークＮを介して、相互にデータ通信可能に接続されている。ここで、複数のゲーム端末１０－ｎは同様の構成であるため、特に区別しない場合には、単に「ゲーム端末１０」と記載して説明する。

本実施の形態のネットワークＮは、インターネットに限定されるものではなく、ゲームシステム１内のゲーム端末１０－ｎ及びサーバ３０を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。

ユーザが操作するゲーム端末１０は、ユーザがゲームをプレイするために使用するコンピュータである。ゲーム端末１０は、例えば、家庭用のゲーム機（据置型又は携帯型）、パーソナルコンピュータ、スマートフォン、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、タブレット型コンピュータ、多機能型テレビジョン受像機（いわゆるスマートテレビ）、遊戯施設等に設置される業務用（商業用）ゲーム機等である。

サーバ３０は、例えば、サーバコンピュータである。サーバ３０は、各ユーザを一意に識別するためのユーザＩＤと関連付けて、ユーザのゲームに関する情報を、例えばデータベースＤＢに記憶して管理する。データベースＤＢはサーバ３０内に構築されていてもよいし、サーバ３０とは別のサーバコンピュータ内に構築されていてもよい。

ゲームシステム１では、コンピュータ対戦（またはＣＰＵ対戦とも称される）や通信対戦が可能である。通信対戦では、例えば、ゲーム端末１０－１を操作するユーザＡと、ゲーム端末１０－２を操作するユーザＢとが、ネットワークＮを介して対戦ゲームを行うことができる。この通信対戦の場合、例えば、サーバ３０によってマッチングされたゲーム端末１０－１とゲーム端末１０－２との間で、Ｐ２Ｐ（Peer to Peer）接続等により直接通信して対戦する方法がある。あるいは、ゲーム端末１０－１とゲーム端末１０－２との間のデータのやり取りを、サーバ３０を経由して通信対戦する方法もある。何れの方法で通信対戦が行われてもよい。

ゲーム端末１０－ｎとサーバ３０との間の通信は、例えば、ベースのプロトコルとしてＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）上で動作するＨＴＴＰ（Hyper Text Transfer Protocol）を使用し、本システムで規定するアプリケーションプロトコルを上位に実装することによって実現できる。

一方、Ｐ２Ｐ等で接続されるゲーム端末１０－１とゲーム端末１０－２との間の通信は、例えば、ＯＳＩ参照モデルのトランスポート層上の通信規約であって主にＩＰプロトコル上に実装されるＵＤＰ（User Datagram Protocol）によって実現できる。上記のＵＤＰは、データの送達確認やエラー訂正を行わず、データを相手側のゲーム端末に送りっぱなしにする通信方式であるため、データの信頼度は低いがデータの転送速度が高いという利点がある。なお、ゲーム端末１０－１とゲーム端末１０－２との間の通信にＵＤＰ以外の他の既存プロトコルを用いたり、今後、新たに規定される新規プロトコルを用いたりすることも勿論可能である。

また、例えば、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能を有するゲーム端末１０－ｎでは、複数台のゲーム端末１０－ｎ間で、直接通信を行って対戦ゲーム等を実行することもできる。

（ゲーム端末のハード構成）
ゲーム端末１０は、主に、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、補助記憶装置１４、通信部１５、操作部１６、表示部１７、および音声出力部１８を備え、これらはアドレスバス、データバス及びコントロールバス等を含むバスラインを介して相互に接続されている。なお、バスラインと各構成要素との間には必要に応じてインタフェース回路、画像処理部、またはサウンド処理部等が介在しているが、ここでは図示を省略している。

ＣＰＵ１１は、ゲームプログラムの命令を解釈して実行し、ゲーム端末１０全体の制御を行う。ＲＯＭ１２は、ゲーム端末１０の基本的な動作制御に必要なプログラムやデータ等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

補助記憶装置１４は、ゲームプログラムや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えば、不揮発性の半導体メモリ、ハードディスクドライブ、ソリッドステートドライブ等を用いることができる。

通信部１５は、図示しない通信インタフェースを備え、ゲーム実行時にデータ通信するための通信制御機能を有している。ここで、データ通信用の通信制御機能には、例えば、インターネット接続機能、無線ＬＡＮ（Local Area Network）接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信部１５は、ＣＰＵ１１からの命令に基づいてゲーム端末１０をネットワークＮに接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ１１へ供給する。

操作部１６は、ユーザが種々の操作命令をゲーム端末１０に入力するためのものである。操作部１６の一例としては、タッチインターフェースを備えた位置入力部（タッチパネルの構成要素）、物理的なボタン、コントローラ、アナログスティック、キーボード、ポインティングデバイス等を挙げることができる。また、マイクロフォン等の音声入力部から入力された音声を識別することにより、音声入力可能な操作部１６として構成してもよい。

表示部１７は、ＣＰＵ１１からの画像表示命令に基づいて駆動され、ゲーム画面等を表示する。表示部１７には、液晶ディスプレイや有機ＥＬ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。また、表示部１７を、液晶ディスプレイ等の表示装置にタッチインターフェースを備えた位置入力部を組み合わせたタッチパネルとすることもできる。表示部１７をタッチパネルとして構成した場合、ゲーム端末１０は図示しないタッチ入力検出部を備える。このタッチ入力検出部は、指やペン等の指示体が画面に接触したとき、当該画面上の接触位置座標を検出して座標信号をＣＰＵ１１へと供給する。これによって、表示部１７の画面上の接触位置がＣＰＵ１１に認識されるようになっている。表示部１７は、ゲーム端末１０と一体である必要はなく、例えば、ゲーム端末１０に対して外部接続されるテレビジョンモニタ等であってもよい。このように、表示部１７が外部接続されるテレビジョンモニタ等の場合、当該表示部１７はゲーム端末１０の構成には含まれない。
音声出力部１８は、ＣＰＵ１１からの発音指示に基づいてアナログ音声信号を生成してスピーカーより音声等を出力する。

また、ゲーム端末１０は、記録媒体ドライブを具備していてもよい。記録媒体ドライブとしては、例えば、ＤＶＤ－ＲＯＭドライブ、ＣＤ－ＲＯＭドライブ、ハードディスクドライブ、光ディスクドライブ、フレキシブルディスクドライブ、シリコンディスクドライブ、カセット媒体読み取り機等が用いられる。この場合、記録媒体としては、ＤＶＤ－ＲＯＭ、ＣＤ－ＲＯＭ、ハードディスク、光ディスク、フレキシブルディスク、半導体メモリ等が用いられる。記録媒体ドライブは、記録媒体から画像データ、音声データ及びプログラムデータを読み出し、読み出したデータをデコーダを介してＲＡＭ１３等に供給する。

（サーバのハード構成）
サーバ３０は、主に、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、補助記憶装置３４、および通信部３５を備え、これらはアドレスバス、データバス及びコントロールバス等を含むバスラインを介して相互に接続されている。なお、バスラインと各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ３１は、システムソフトウェアやアプリケーションソフトウェアの命令を解釈して実行し、サーバ３０全体の制御を行う。ＲＯＭ３２は、サーバ３０の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ３３は、各種プログラム及びデータを記憶し、ＣＰＵ３１に対する作業領域を確保する。補助記憶装置３４は、プログラムや各種データ等を格納する記憶装置である。補助記憶装置３４としては、例えばハードディスクドライブ又はソリッドステートドライブ等を用いることができる。

通信部３５は、図示しない通信インタフェースを備え、ネットワークＮを介した各ゲーム端末１０－ｎとの間の通信を制御する。また、通信部３５は、ネットワークＮに接続されている図示しない他のサーバとの通信も制御するようになっている。例えば、サーバ３０をソーシャルネットワーキングサービス（ＳＮＳ）に組み込んだシステム構成とした場合、サーバ３０の通信部３５は、ＳＮＳサーバとの間の通信を制御する。また、例えば、サーバ３０は、ユーザがプレイしたゲーム動画を、観戦者に配信する動画配信サーバとの間の通信を制御する。なお、サーバ３０に動画配信機能を持たせることもできる。

サーバ３０は、単独のコンピュータで構成することもできるが、サーバ３０の有する各機能を複数のサーバに分散して持たせる機能分散型の構成とすることもできる。あるいは、ネットワークＮ上に複数のサーバ３０を設けて冗長化（多重化）を図ることにより、負荷分散型の構成としてもよい。また、サーバ３０は、クラウドコンピューティング技術を利用したクラウドサーバとして構成されてもよい。

プログラムやデータは、ネットワークＮを介して遠隔地からゲーム端末１０又はサーバ３０に供給されて、ＲＡＭ１３、補助記憶装置１４、ＲＡＭ３３又は補助記憶装置３４に記憶される。なお、情報記憶媒体（例えば光ディスク又はメモリカード等）に記憶されたプログラムやデータを読み取るための構成要素（例えば光ディスクドライブ又はメモリーカードスロット等）がゲーム端末１０又はサーバ３０に備えられてもよい。そして、プログラムやデータが、前記情報記憶媒体を介してゲーム端末１０又はサーバ３０に供給されてもよい。

なお、以下では、ゲーム端末１０がタッチパネルを備えたスマートフォン又はタブレット型コンピュータである場合を想定する。

［２．ゲームの一例の概要］
ゲームの一例の概要を、以下に説明する。
ゲームシステム１では、各種ゲームを実行できる。例えば、スポーツゲーム（野球、サッカー、テニス、アメリカンフットボール等を題材としたゲーム）、レースゲーム、格闘ゲーム、戦闘ゲーム、デジタルカードゲーム等、ゲーム形式・ジャンルを問わず様々なゲームを実行できる。

例えば、野球ゲームでは、一又は複数のオブジェクト（例えば、ゲームキャラクタ、ゲームカード、又はゲームアイテム等）に基づいて、育成や対戦をはじめとする種々のゲームモードが実行される。以下では、ゲームシステム１で実行されるゲームの一例として、主に野球を題材とした野球ゲームについて説明し、必要に応じてその他のゲームについても言及する。

本実施形態の野球ゲームには、育成モード、チーム育成モード、抽選入手モード、強化モード、ＣＰＵ対戦モード、リアルタイム対戦モード等の様々なゲームモードが搭載されている。

育成モードは、ユーザが育成対象キャラクタを育成して、自分だけのオリジナルのゲームキャラクタを作成するキャラクタ育成モードである。本実施形態では、育成モードにおいて、投手または野手（捕手も含む）のキャラクタを育成することができる。以下、ユーザが育成モードで作成したゲームキャラクタを「育成選手」と称する。育成選手は、チーム育成モード、ＣＰＵ対戦モード、リアルタイム対戦モード等の他のゲームモードで使用できる。チーム育成モードは、複数の選手キャラクタから構成されるチームの育成等を行うゲームモードである。

抽選入手モードは、育成モードで育成対象キャラクタを育成するときに補助のオブジェクトとして利用できる、後述の「イベントキャラクタ」を抽選により入手可能なゲームモードである。この抽選入手モードでは、例えば、ゲーム内の全てのイベントキャラクタの中からユーザに付与するイベントキャラクタの抽選（いわゆるガチャ）が行われる。ユーザが抽選入手モードを実行するためには、例えば、所定量のゲーム内ポイント、課金アイテム等を必要としてもよい。
強化モードは、抽選入手モード等で入手したイベントキャラクタ同士を合成などすることでイベントキャラクタのレベルを向上させて強化できるモードである。

ＣＰＵ対戦モードは、コンピュータ対戦モードとも称される。例えば、ＣＰＵ対戦モードに「スタジアム」等の名称を付けてもよい。このＣＰＵ対戦モードでは、ユーザが育成モードで育成した育成選手で編成した自チームの選手キャラクタの打撃操作、投球操作または守備操作等を行い、ＣＰＵが自動制御する対戦相手のチームと対戦する。例えば、ＣＰＵが自動制御する対戦相手チームは、他のユーザが育成モードで育成した育成選手で編成したチームである。

リアルタイム対戦モードは、ネットワークＮを介して、ユーザが遠隔地の他のユーザとオンラインで通信対戦できるモードである。このリアルタイム対戦では、例えば、ユーザのチームと、対戦相手のチーム（ネットワークＮ上の他のユーザの野球チーム）との試合が、それぞれのゲーム端末１０における操作に基づいて、通信対戦で進行する。例えば、ユーザが守備側で、対戦相手のユーザが攻撃側であれば、対戦相手のユーザの操作（投球操作又は守備操作）に応じて選手キャラクタが投球又は守備を行い、ユーザの操作（打撃操作又は走塁操作）に応じて選手キャラクタが打撃又は走塁を行う。このようなアクションゲームでは、選手キャラクタに対する各ユーザの操作に基づいて、ゲーム内の試合の状況が更新されていく。このリアルタイム対戦は、ｅスポーツ（electronic sports）でも利用される対戦方式である。

本実施形態におけるリアルタイム対戦モードでは、少なくとも、ユーザが育成モードで育成した育成選手と、育成モードでも使用されるイベントキャラクタとの２種類のオブジェクトを使用可能である。
以下には、先ず育成モードについて説明し、その後、育成選手とイベントキャラクタとを使用したリアルタイム対戦モードについてより詳しく説明する。

（２－１．育成モード）
育成モードでは、育成対象となる主人公キャラクタが高校で野球の練習をし、様々なイベントを経て主人公キャラクタが投手または野手として育成される。なお、本実施形態の育成モードでは複数のシナリオが用意されており、シナリオによって進学する高校が異なっている。本実施形態のゲームでは、ユーザがその中の１つのシナリオを選択することにより、主人公キャラクタが進学する高校が決定される。

シナリオが選択されると、まず、ユーザは主人公キャラクタの基本情報を決定する。基本情報としては、名前、ポジション、利き腕、打撃フォーム、投手の場合は投球フォームを決定する。ポジションについては、投手、捕手、一塁手、二塁手、三塁手、遊撃手、外野手から選択する。以下、投手以外のポジションについては野手として説明する。

主人公キャラクタの基本情報が決定されると、次にイベントデッキの設定が行われる。ここでイベントデッキとは、主人公キャラクタが進学する高校において一緒に練習等を行うチームメイトとなるイベントキャラクタを設定するためのデッキである。なお、イベントキャラクタとは、主人公キャラクタの育成過程においてイベントが発生することにより主人公キャラクタの育成に影響を及ぼす（ユーザにとって有利な効果を及ぼす）キャラクタであり、ユーザは所持するイベントキャラクタの中からイベントデッキに設定するイベントキャラクタを選択する。なお、イベントキャラクタは、ＣＰＵ対戦モードやリアルタイム対戦モードでの勝利報酬で獲得したり、前述の抽選入手モードにおける抽選によって獲得したりすることができる。

ユーザがゲーム内で獲得したイベントキャラクタは、ユーザの所持キャラクタとしてユーザＩＤに関連付けられて記憶装置（データベースＤＢ、補助記憶装置１４、補助記憶装置３４等）に記憶されて、ゲームシステム１において管理される。なお、各ユーザが所持できるイベントキャラクタの数には上限が設けられている。ユーザは、所持しているイベントキャラクタを必要に応じて売却することができる。イベントキャラクタを売却すれば、ゲーム内で使用できるポイントやゲーム内通貨に変換される。

また、ユーザは、所持しているイベントキャラクタの中から一つのベースキャラクタと、１つ以上の強化素材キャラクタとを選択し、ベースキャラクタに強化素材キャラクタを合成してベースキャラクタを強化することができる。この強化処理により、ベースキャラクタとして選択したイベントキャラクタのレベルを向上させることができる。一方、強化素材キャラクタとして使用されたイベントキャラクタは、ユーザの所持キャラクタではなくなる。

育成モードでのシナリオを開始する前に、ユーザは強化モードの上記強化処理によりイベントキャラクタのレベルを予め上げておくことが望ましい。なぜならば、イベントキャラクタのレベルが高いほど、練習による主人公キャラクタの能力の上昇値や主人公キャラクタに対する初期評価などが高くなるため、主人公キャラクタの育成を有利に進めることができるからである。

図２には、イベントデッキの表示画面Ｇ１００の例を示す。イベントデッキを設定する際には、図２に示す表示画面Ｇ１００が表示される。表示領域Ａ１１０にはデッキ名が表示される。ユーザはイベントデッキ内でのイベントキャラクタの組み合わせを、育成モードでのシナリオを開始する前に予め登録することができる。変更ボタンＢ１１０１は、デッキ名を変更するためのボタンである。

表示領域Ａ１１２には、選択されたイベントキャラクタが表示される。イベントデッキには、例えば、最大で６人のイベントキャラクタを設定することができる。なお、イベントキャラクタはユーザが所持するイベントキャラクタから選択されるが、その一部を他のユーザ（例えば、ユーザに関連付けられた他のユーザ）が所持するイベントキャラクタから選択できる。

表示領域Ａ１１１には、それぞれのイベントキャラクタのレアリティが表示される。レアリティとは、入手し難さを表すものであり、レアリティの種類としては、「ノーマル（Ｎ）」、「パワフルノーマル（ＰＮ）」、「レア（Ｒ）」、「パワフルレア（ＰＲ）」、「スーパーレア（ＳＲ）」、「パワフルスーパーレア（ＰＳＲ）」の６種類がある。Ｎ、ＰＮ、Ｒ、ＰＲ、ＳＲ、ＰＳＲの順にレアリティが高くなり、レアリティが高いほどイベントが発生した場合など主人公キャラクタを育成する際の恩恵が大きくなる。また、表示領域Ａ１１３には、そのイベントキャラクタのレベルが表示される。

また、イベントキャラクタには、それぞれ得意練習が関連付けられている場合があり、そのイベントキャラクタの得意練習で主人公キャラクタとともに練習を行うと、主人公キャラクタはそのイベントキャラクタから能力のコツを教わったり、特別な練習を行うイベントが発生したりする。

表示領域Ａ１１４には、イベントキャラクタの得意練習の一覧が表示される。練習の種類には、「打撃」、「筋力」、「走塁」、「肩力」、「球速」、「コントロール」、「スタミナ」、「変化球」、「守備」、「メンタル」がある。イベントデッキにイベントキャラクタが設定されると、表示領域Ａ１１５に得意練習となるイベントキャラクタの倍数が表示される。図４に示す例では、打撃を得意練習とするイベントキャラが１人、筋力を得意練習とするイベントキャラが２人、走塁を得意練習とするイベントキャラが１人、肩力を得意練習とするイベントキャラが１人、メンタルを得意練習とするイベントキャラが１人設定されていることを示している。なお、１つのイベントキャラクタの得意練習が２種類以上あってもよい。

以上のようにイベントデッキへのイベントキャラクタの設定が完了すると、次に、育成モードで使用可能なアイテムの選択が行われる。アイテムは対戦モードでの勝利報酬で獲得したり、抽選によって獲得したりすることができ、例えば、ユーザは最大２つのアイテムを育成モードで使用することができる。アイテムの種類としては、イベント発生率を上昇させるためのアイテムや、体力を回復させるためのアイテム、ケガの発生率を下げるアイテムなどがある。

以上のようにゲームアイテムの選択まで終了すると、シナリオが開始される。ここで、シナリオの内容を説明する前に、育成される主人公キャラクタの能力パラメータについて説明する。図３には、主人公キャラクタを野手として育成した場合の能力一覧画面Ｇ２００の一例を示す。表示領域Ａ２１０には、主人公キャラクタの画像が表示される。

表示領域Ａ２１１には、主人公キャラクタの名前が表示される。表示領域Ａ２１２には、主人公キャラクタのポジションの番号が表示される。表示領域Ａ２１３には、主人公キャラクタの打撃フォームおよび利き腕が表示される。表示領域Ａ２１４には、主人公キャラクタの守備ポジションが表示される。

表示領域Ａ２１５～Ａ２２１には、野手としての基本能力が表示される。なお、表示領域Ａ２１６～Ａ２２１に表示させる基本能力は、Ｓ、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇの８段階の評価ランクで表示され、能力値が９０以上の場合はＳ、８０～８９の場合はＡ、７０～７９の場合はＢ、６０～６９の場合はＣ、５０～５９の場合はＤ、４０～４９の場合はＥ、２０～３９の場合はＦ、１９以下の場合はＧとなる。

表示領域Ａ２１５には、「弾道」に関する基本能力が表示され、評価ランクとして１～４の数値で表される。数値が高いほど打撃での打球の軌道が高くなり、本塁打が出やすくなる。表示領域Ａ２１６には、「ミート」に関する基本能力が表示され、「ミート」の能力が高いほどバットをボールに当てやすく、ヒットが出やすくなる。表示領域Ａ２１７には、「パワー」に関する基本能力が表示され、「パワー」の能力が高いほど打撃で長打が出やすくなる。表示領域Ａ２１８には、「走力」に関する基本能力が表示され、「走力」の能力が高いほど走塁が速くなり、内野安打が出やすくなる。表示領域Ａ２１９には、「肩力」に関する基本能力が表示され、「肩力」の能力が高いほど守備でボールを速く送球することができる。表示領域Ａ２２０には、「守備力」に関する基本能力が表示され、「守備力」の能力が高いほど守備範囲が広くなる。表示領域Ａ２２１には、「捕球」に関する基本能力が表示され、「捕球」の能力が高いほど守備で上手に捕球しやすく、エラーが発生しにくくなる。

表示領域Ａ２２２には、主人公キャラクタが保持する野手に関する特殊能力の一覧が表示される。図３に示す例では、主人公キャラクタは、「内野安打」、「代打」、「インコース」、「送球」、「調子安定」の５種類の特殊能力を保持している。つまり、主人公キャラクタは、内野安打が出やすく、代打で登場する場合は能力値がアップし、打撃では「インコース」が得意で、守備時には正確な送球ができ、調子が安定していることを示している。

なお、図３に示す例は、主人公キャラクタが野手である場合を示しているため、野手に関する基本能力や特殊能力が表示されている。主人公キャラクタが投手である場合には、投手に関する基本能力（例えば、球速、コントロール、スタミナ等）や特殊能力が表示される。

次に、育成モードにおけるシナリオの進行について説明する。例えば、シナリオは４つのセクションで構成され、第１セクションから第３セクションは、それぞれ１２ターンで構成され、第４セクションのみ１５ターンで構成されている。ユーザは１ターンごとに、複数種類の練習コマンドの選択肢から任意の練習コマンドを選択して主人公キャラクタを練習させたり、休むコマンドを選択して主人公キャラクタを休ませたりすることができる。なお、第４セクションの途中から高校野球の予選および甲子園での高校野球の試合が含まれるため、途中で試合に負けて敗退となった場合には、強制的に第４セクションは終了するようにしてもよい。

各セクションの各ターンでは、主人公キャラクタの他に複数のチームメイトが登場し、主人公キャラクタの育成効果に大きな影響を及ぼす。チームメイトには、イベントデッキに設定されたイベントキャラクタと、そのシナリオ固有で予め定められたイベントキャラクタと、その他のデフォルトキャラクタ（非イベントキャラクタ）とが含まれる。

また、１つのターンを挟んで前イベントと後イベントが発生する場合がある。発生するイベントには、イベントデッキに設定されたイベントキャラクタに応じたイベント、イベントデッキに設定された複数のイベントキャラクタの組み合わせに応じたイベント、シナリオ固有のシナリオイベント等がある。発生するイベントが前イベントか後イベントかは、シナリオイベントの内容およびイベントキャラクタによって予め決定されており、各イベントの発生条件はイベント発生抽選で当選した場合に発生する。これらのイベントが発生すると、発生したイベントに応じた育成効果が主人公キャラクタに与えられる。

各ターンでユーザが選択した練習コマンドの実行結果や発生したイベントの結果等に基づいて、主人公キャラクタの能力値を上げたり特殊能力を取得したりするために必要な経験値を獲得できる。ユーザは、獲得した経験値の範囲で、どの能力パラメータの能力値を高めるのか、どの特殊能力を取得するのかを検討する。

なお、経験値を介さずに、ユーザが選択した練習コマンドの実行結果や発生したイベントの結果等に応じて、主人公キャラクタの能力値が向上したり、特殊能力が取得できたりしてもよい。

基本的に、１つのシナリオの終了により主人公キャラクタの育成が完了する。育成が完了した主人公キャラクタは、基本能力や特殊能力等に基づいて査定され、選手総合力の値が算出されるとともに、選手総合力の値に基づいて選手ランクが決定される。育成モードで育成が完了した主人公キャラクタは、育成モード以外のゲームモードにおいてユーザが使用可能な「育成選手」として、ユーザＩＤに関連付けられて登録される。また、「育成選手」は、育成に適用したシナリオの情報と関連付けられるようにしてもよい。そして、シナリオの終了後は、再度、最初からシナリオを開始して主人公キャラクタを育成することにより、別の「育成選手」を作成できる。すなわち、育成モードにおける育成を繰り返せば、ユーザは様々な能力を有する複数の「育成選手」を作成できる。
また、ユーザが複数のシナリオから選択したシナリオを進行させて、チーム（複数のオブジェクトから構成されるグループ）を育成するチーム育成モードを設けてもよい。この場合、１つのシナリオの実行により１つのチームが作成できる。このチーム育成モードで育成されたチームも、リアルタイム対戦モード等の他のゲームモードにおいてユーザが使用可能な「育成チーム」として、ユーザＩＤに関連付けられて登録される。また、「育成チーム」は、育成に適用したシナリオの情報と関連付けられるようにしてもよい。

（２－２．リアルタイム対戦モード）
以下、前述の育成選手（第１オブジェクトの一例）とイベントキャラクタ（第２オブジェクトの一例）とを使用したリアルタイム対戦モードについて説明する。

本実施形態のリアルタイム対戦モードでは、各ユーザが任意に参加可能な２つのゲーム内リーグが設けられている。ゲーム内リーグの１つは、各ユーザが所持する所定数（本実施の形態では２５名）の育成選手で編成された「育成選手オーダー」（第１使用対象の一例）をそれぞれ使用してユーザ間で対戦できる「育成選手リーグ」である。もう１つのゲーム内リーグは、各ユーザが所持する所定数（本実施の形態では２５名）のイベントキャラクタで編成された「イベントキャラクタオーダー（以下、「イベキャラオーダー」と称す）」（第２使用対象の一例）をそれぞれ使用してユーザ間で対戦できる「イベキャラリーグ」である。

（育成選手オーダーについて）
育成選手オーダーは、ユーザが所持する２５名の育成選手（例えば、野手スターティングメンバ８名、野手控え８名、先発投手３名、中継ぎ投手５名、抑え投手１名）で構成される。

ゲーム開始時より、各ユーザには、所定数（例えば２５名）のデフォルトの育成選手が付与される。通常、デフォルトの育成選手の能力値は、ユーザが育成モードで育成する育成選手よりも低くなるように設定されている。デフォルトの育成選手の能力パラメータは、各ユーザ共通である。すなわち、各ユーザは育成モードで２５名以上の育成選手を育成する前から、デフォルトの育成選手を含む育成選手オーダーを編成することが可能である。

リアルタイム対戦モードを最初に実行する際には、デフォルトの育成選手オーダーが初期設定される。例えば、リアルタイム対戦モードを最初に実行する際には、当該モードの遊び方のチュートリアルが実行され、このチュートリアルのユーザ操作においてデフォルトの育成選手オーダーが初期設定される。例えば、その時点でユーザのユーザＩＤに関連付けられている全ての育成選手（すなわち、ユーザが育成モードで育成した全ての育成選手およびデフォルトの全ての育成選手）の中から、ゲームシステム１のＣＰＵ１１が最適であると判断した育成選手が自動的に選出され、デフォルトの育成選手オーダーが自動設定される。

あるいは、前述のＣＰＵ対戦モードで使用される育成選手で構成されるオーダーを、リアルタイム対戦モードのデフォルトの育成選手オーダーとしてもよい。なお、リアルタイム対戦モードの育成選手オーダーは専用オーダーであり、ＣＰＵ対戦モードのオーダーとは異なるオーダーとしてユーザが編集できる。バリエーションとしては、ＣＰＵ対戦モードのオーダーとリアルタイム対戦モードの育成選手オーダー（育成選手オーダーが複数ある場合はそのうちの１つ）とを共通のオーダーとしてもよい。

図４は、ユーザによってリアルタイム対戦モードが選択された場合に表示部１７に表示される、リアルタイム対戦モードのトップ画面Ｇ３００の一例を示す。このトップ画面Ｇ３００には、育成選手オーダーを編集するための育成選手オーダー編集ボタンＢ３０１が含まれる。育成選手オーダー編集ボタンＢ３０１をタップすると、図５に例示する育成選手オーダー編集画面Ｇ４００に遷移する。

図５の育成選手オーダー編集画面Ｇ４００の領域Ａ４１０には、ユーザのチームにおける野手の育成選手オーダーが表示される。育成選手オーダーに含まれる育成選手は、スターティングオーダーのメンバと、控えのメンバとに分けて表示される。メンバを入れ替える場合、あるメンバの選手名が記載されているパーツＰ４１１を他のメンバの選手名が記載されているパーツＰ４１１にドラッグすることにより可能である。また、現在のオーダーに含まれていない育成選手とメンバを入れ替える場合、パーツＰ４１１をパーツＰ４１２へドラッグすると、入れ替え可能な育成選手の一覧が表示される。ボタンＢ４２１は、おまかせボタンであり、ユーザがボタンＢ４２１をタップすると、ゲームシステム１がユーザの育成選手チームの最適なオーダーを自動で編成する。例えば、その時点でユーザのユーザＩＤに関連付けられている全ての育成選手の中から、各ポジションで選手総合力の最も高い育成選手が自動的に選出される。

ボタンＢ４３０は、投手の育成選手オーダーの編集画面に切り替えるためのボタンである。前述の野手と同様に、投手の育成選手オーダーも編集可能である。
領域Ａ４４０には、現在の育成選手オーダーにおけるチームランクおよびチーム総合力が表示される。例えば、チームランクおよびチーム総合力は、育成選手オーダーに含まれる全ての育成選手の能力パラメータに基づいて算出される。育成選手オーダーが編集された場合、領域Ａ４４０には編集前後のチームランクおよびチーム総合力の変化が表示される。ユーザが決定ボタンＢ４２２をタップすると、育成選手オーダーの編集内容が確定され、図４のトップ画面Ｇ３００へ遷移する。また、現在の育成選手オーダーを確認して編集せずにトップ画面Ｇ３００へ戻る場合は、戻るボタンＢ４５０をタップする。

上述のように、育成選手オーダーはユーザの所持する育成選手と入れ替えて強化していくことができる。例えば、育成モードでより能力パラメータの高い育成選手が育成できた場合、ユーザは育成選手オーダーを編集すれば、自分のチームを強化できる。

（イベキャラオーダーについて）
イベキャラオーダーは、ユーザが所持する２５名のイベントキャラクタ（例えば、野手スターティングメンバ８名、野手控え８名、先発投手３名、中継ぎ投手５名、抑え投手１名）で構成される。

リアルタイム対戦モードを最初に実行する際には、各ユーザには、所定数（例えば２７名）のデフォルトのイベントキャラクタが付与される。そして、デフォルトのイベキャラオーダーが初期設定される。例えば、リアルタイム対戦モードを最初に実行する際には、当該モードの遊び方のチュートリアルが実行され、このチュートリアルのユーザ操作において所定数（例えば２７名）のイベントキャラクタがユーザに付与される。ここで付与されるイベントキャラクタは、各ユーザ共通である。
なお、バリエーションとしては、リアルタイム対戦モードの初回実行時に各ユーザに付与される所定数のイベントキャラクタは、抽選入手モードと同様にして抽選により決定されるようにしてもよい。この場合、ユーザによって初回に獲得できる所定数のイベントキャラクタは異なる。

ここで、ゲームシステム１が提供するゲーム内で扱うイベントキャラクタについて説明する。図８は、キャラクタ情報テーブルＴＢＬ１０２の一例を示す。キャラクタ情報テーブルＴＢＬ１０２は、ゲームシステム１が提供するゲーム内で扱う全てのイベントキャラクタを管理するためのマスターデータである。キャラクタ情報テーブルＴＢＬ１０２には、全てのイベントキャラクタの初期データが基準パラメータとして記憶されている。例えば、キャラクタ情報テーブルＴＢＬ１０２は、サーバ３０及びゲーム端末１０のそれぞれの記憶装置（例えば、ＲＡＭ１３、補助記憶装置１４、ＲＡＭ３３、補助記憶装置３４、データベースＤＢ等）に記憶されて管理されている。サーバ３０及びゲーム端末１０に記憶されるキャラクタ情報テーブルＴＢＬ１０２は基本的に同じものであり、例えば、サーバ３０においてゲーム運営側がキャラクタ情報テーブルＴＢＬ１０２を変更した場合、変更した情報がネットワークＮを介してサーバ３０からゲーム端末１０へ配信される。

キャラクタ情報テーブルＴＢＬ１０２は、各イベントキャラクタの「オリジナルＩＤ」、「プロファイルＩＤ」、「名称」、「レアリティ」、「限界レベル」、「ポジション」、「能力」、「イベント」等のフィールドを含む。

オリジナルＩＤは、イベントキャラクタの名称（選手名）毎に付与される識別情報である。プロファイルＩＤは、イベントキャラクタのレアリティに応じて付与される識別情報である。同一名称のイベントキャラクタには同一のオリジナルＩＤが付される。同一名称のイベントキャラクタでもレアリティが異なれば、異なるプロファイルＩＤが付される。例えば、同一名称でレアリティが異なるイベントキャラクタは、プロファイルＩＤの一桁目だけが異なっている。キャラクタ情報テーブルＴＢＬ１０２においてイベントキャラクタを一意に識別する情報はプロファイルＩＤである。

同一名称でレアリティが異なるイベントキャラクタは、能力パラメータの値は同じであるが、限界レベルが異なる。ここで、限界レベルは、イベントキャラクタのレベルの上限である。ユーザがイベントキャラクタを入手した際の初期レベルは、「レベル１」である。この入手後に、ユーザは、前述の強化モードの強化処理によりイベントキャラクタのレベルを、前記限界レベルを上限として向上させることができる。そして、イベントキャラクタのレアリティが高いほど、限界レベルも高く設定されており、より高いレベルまでイベントキャラクタのレベルを向上させることができる。なお、所定の条件を満たすことにより限界突破効果が発動し、イベントキャラクタの限界レベルが向上するようにしてもよい。

各イベントキャラクタにも、育成選手と同様に、守備ポジションおよび能力パラメータが設定されている。イベントキャラクタの能力パラメータは、図３に例示する育成選手（主人公キャラクタ）と同様に、野手の場合は弾道、ミート、パワー、走力、肩力、守備力、捕球の基本能力と、特殊能力を含む。また、投手の場合も、イベントキャラクタの能力パラメータは、育成選手と同様に、球速、コントロール、スタミナ、変化球の基本能力と、特殊能力を含む。

イベントキャラクタの能力には、イベントキャラクタのレアリティおよびレベルが反映される。例えば、同一名称でレアリティが異なるイベントキャラクタの場合、レアリティが高いほど、能力値が高くなるように能力パラメータが補正される。
また、例えば、同一名称でレアリティが異なるイベントキャラクタの場合、レベルが高いほど、能力値が高くなるように能力パラメータが補正される。よって、イベキャラオーダーに含まれているイベントキャラクタについて、ユーザが強化モードでレベルを向上させることにより、イベキャラオーダーのチームを強化できる。

キャラクタ情報テーブルＴＢＬ１０２の「イベント」フィールドには、イベントキャラクタに関連付けられているイベントの情報が記憶される。この「イベント」フィールドの情報は、育成モードにおいて、イベントキャラクタがイベントデッキに設定された場合に使用される。なお、リアルタイム対戦モード等の育成モード以外のモードにおいてイベントキャラクタが使用される場合は、当該イベントキャラクタに関連付けられているイベントを発生させる効果は生じないので、「イベント」フィールドの情報は参照されない。

なお、図８では省略されているが、その他のフィールドもキャラクタ情報テーブルＴＢＬ１０２に含まれる。例えば、イベントキャラクタの画像情報や初期評価等のフィールドが、キャラクタ情報テーブルＴＢＬ１０２に含まれる。

リアルタイム対戦モードを最初に実行する際には、デフォルトのイベキャラオーダーが初期設定される。例えば、リアルタイム対戦モードを最初に実行する際には、当該モードの遊び方のチュートリアルが実行され、このチュートリアルのユーザ操作においてデフォルトのイベキャラオーダーが初期設定される。例えば、その時点でユーザのユーザＩＤに関連付けられている全ての育成選手（すなわち、ユーザが抽選入手モード等により既に所持している全てのイベントキャラクタおよび前述の初回実行時にユーザに付与された所定数のイベントキャラクタ）の中から、ゲームシステム１のＣＰＵ１１が最適であると判断したイベントキャラクタが自動的に選出され、デフォルトのイベキャラオーダーが自動設定される。

図４のリアルタイム対戦モードのトップ画面Ｇ３００には、イベキャラオーダーを編集するためのイベキャラオーダー編集ボタンＢ３０２が含まれる。ユーザがイベキャラオーダー編集ボタンＢ３０２をタップすると、前述の育成選手オーダー編集画面Ｇ４００（図５参照）と同様のイベキャラオーダー編集画面が表示される。このイベキャラオーダー編集画面において、前述の育成選手オーダーと同様に、イベキャラオーダーを編集することができる。すなわち、おまかせボタンを選択すれば、ゲームシステム１がユーザのイベントキャラクタチームの最適なオーダーを自動で編成する。例えば、その時点でユーザのユーザＩＤに関連付けられている全てのイベントキャラクタの中から、各ポジションで選手総合力（能力）の最も高いイベントキャラクタが自動的に選出される。また、ユーザが手動操作でイベキャラオーダーのメンバを入れ替えることも可能である。

このように、イベキャラオーダーはユーザの所持するイベントキャラクタと入れ替えて強化していくことができる。例えば、抽選入手モードでより能力パラメータの高いイベントキャラクタを獲得したり、強化モードでイベントキャラクタのレベルを向上させた場合、ユーザはイベキャラオーダーを編集すれば、自分のチームを強化できる。

なお、育成選手オーダーに含まれる育成選手およびイベキャラオーダーに含まれるイベントキャラクタは、売却や強化素材の対象にできないようにロックされる。

また、図４のリアルタイム対戦モードのトップ画面Ｇ３００には、リアルタイム対戦の試合のルールに相当するゲーム条件（マッチングの検索条件）を設定してマッチング相手を検索するための検索設定ボタンＢ３０３が含まれる。ユーザが検索設定ボタンＢ３０３をタップすると、図６に例示する検索設定画面Ｇ５００に遷移する。

図６の検索設定画面Ｇ５００には、ユーザがリアルタイム対戦モードの対戦で使用するチームオーダーに関する条件を設定するための使用オーダー条件設定領域Ａ５１０を含む。この使用オーダー条件設定領域Ａ５１０には、選択肢Ｐ５１１～Ｐ５１３を含む。選択肢Ｐ５１２は、前述の育成選手オーダーを使用するというゲーム条件を設定するための選択肢である。選択肢Ｐ５１３は、前述のイベキャラオーダーを使用するというゲーム条件を設定するための選択肢である。「おまかせ」の選択肢Ｐ５１１は、対戦で使用するオーダーについては育成選手オーダーとイベキャラオーダーとの何れでもよいとするゲーム条件を設定するための選択肢である。換言すれば、「おまかせ」の選択肢Ｐ５１１は、対戦で使用するオーダーについてはゲームシステム１に委任するという選択肢である。

ユーザは、選択肢Ｐ５１１～Ｐ５１３の何れかをタップすることにより、使用オーダー条件を設定可能である。図６では、「おまかせ」の選択肢Ｐ５１１が選択されている例を示している。
なお、デフォルトで選択肢Ｐ５１１～Ｐ５１３の何れかが初期設定されているようにしてもよい。例えば、ゲーム内でのマッチングの機会を増やすために、「おまかせ」の選択肢Ｐ５１１が初期設定されているようにする。

図６の検索設定画面Ｇ５００には、ユーザがリアルタイム対戦モードの試合のイニング数に関する条件を設定するためのイニング数条件設定領域Ａ５２０が含まれる。このイニング数条件設定領域Ａ５２０には、選択肢Ｐ５２１～Ｐ５２４が含まれる。選択肢Ｐ５２２は、試合のイニング数を「３回裏まで」とするゲーム条件を設定するための選択肢である。選択肢Ｐ５２３は、試合のイニング数を「６回裏まで」とするゲーム条件を設定するための選択肢である。選択肢Ｐ５２４は、試合のイニング数を「９回裏まで」とするゲーム条件を設定するための選択肢である。「おまかせ」の選択肢Ｐ５２１は、「３回裏まで」、「６回裏まで」、「９回裏まで」の何れでもよいとするゲーム条件を設定するための選択肢である。換言すれば、「おまかせ」の選択肢Ｐ５２１は、試合のイニング数についてはゲームシステム１に委任するという選択肢である。

ユーザは、選択肢Ｐ５２１～Ｐ５２４の何れかをタップすることにより、イニング数の条件を設定可能である。図６では、「３回裏まで」の選択肢Ｐ５２２が選択されている例を示している。
なお、デフォルトで選択肢Ｐ５２１～Ｐ５２４の何れかが初期設定されているようにしてもよい。例えば、ゲーム内でのマッチングの機会を増やすために、「おまかせ」の選択肢Ｐ５２１が初期設定されているようにする。

ユーザが確定ボタンＢ５３０をタップすると、マッチングの検索のためのゲーム条件（本実施の形態では上述の使用オーダー条件およびイニング数条件）の条件設定が確定され、図４のトップ画面Ｇ３００へ遷移する。また、現在のゲーム条件の条件設定を確認してトップ画面Ｇ３００へ戻る場合は、戻るボタンＢ５４０をタップする。

図４のトップ画面Ｇ３００には、マッチング要求を行うためのマッチングボタンＢ３０４が含まれる。マッチングボタンＢ３０４がタップされると、ユーザのゲーム端末１０からサーバ３０へ、前述の条件設定を伴うマッチング要求が送信される。

ここで、サーバ３０におけるマッチング処理の一例について説明する。図９はキューおよびバッファを含むデータ構造を示すものであり、当該キューおよびバッファを用いたマッチング処理の一例を説明するための図である。ここでは説明を簡略化するため、イニング数「３回裏まで」というゲーム条件を含む各ユーザのマッチング要求を対象としたマッチング処理の一例について説明する。

図９に示すキューＱＵ３は、イニング数「３回裏まで」のゲーム条件を含む各ユーザのマッチング要求のデータを要素とするキューイングを実行するためのキューである。サーバ３０は、各ユーザのゲーム端末１０から前記ゲーム条件が設定されたマッチング要求を受信した場合、受信した順にマッチング要求をキューＱＵ３にエンキューする。各マッチング要求には、当該マッチング要求を行ったユーザのユーザＩＤが含まれている。

図９において、マッチング要求を、エンキューの順番を示すシリアル番号＋［使用オーダー条件］で示している。ここで、［使用オーダー条件］の［Ａ］はイベキャラオーダーを使用するという条件、［Ｂ］は育成選手オーダーを使用するという条件、［ａｌｌ］はイベキャラオーダーと育成選手オーダーの何れでもよいとする「おまかせ」の条件である。例えば、マッチング要求１［Ａ］は、キューＱＵ３に最初にエンキューされた、イベキャラオーダーを使用するという条件設定を伴うマッチング要求である。また、マッチング要求データ２［ａｌｌ］は、キューＱＵ３に２番目にエンキューされた、イベキャラオーダーと育成選手オーダーの何れでもよいとする「おまかせ」の条件設定を伴うマッチング要求である。また、マッチング要求３［Ｂ］は、キューＱＵ３に３番目にエンキューされた、育成選手オーダーを使用するという条件設定を伴うマッチング要求である。

ここでは、図９中の（Ａ）に示すように、キューＱＵ３には、５つのマッチング要求１［Ａ］、２［ａｌｌ］、３［Ｂ］、４［Ａ］、５［ａｌｌ］がこの順でエンキューされたものとして説明を続ける。

バッファＢＵ［Ａ］は、キューＱＵ３からデキューされた、イベキャラオーダーを使用するという条件設定を伴うマッチング要求を一時的に格納する領域を有する。バッファＢＵ［Ｂ］は、キューＱＵ３からデキューされた、育成選手オーダーを使用するという条件設定を伴うマッチング要求を一時的に格納する領域を有する。バッファＢＵ［ａｌｌ］は、キューＱＵ３からデキューされた、イベキャラオーダーと育成選手オーダーの何れでもよいとする「おまかせ」の条件設定を伴うマッチング要求を一時的に格納する領域を有する。

図９中の（Ａ）において、キューＱＵ３からデキューされたマッチング要求１［Ａ］に対する処理は、次のとおりである。デキューされたマッチング要求１［Ａ］については、バッファＢＵ［Ａ］とバッファＢＵ［ａｌｌ］とに格納されているマッチング要求がマッチングの対象となる。サーバ３０は、対象のバッファＢＵ［Ａ］とバッファＢＵ［ａｌｌ］の何れかにマッチング要求が格納されているか否かを確認する。この場合の確認順序は、例えばランダムである。なお、バッファＢＵ［Ａ］またはバッファＢＵ［ａｌｌ］の何れか一方を優先的に確認するような優先順位を予め設定していてもよい。図９中の（Ａ）の場合、対象のバッファＢＵ［Ａ］およびバッファＢＵ［ａｌｌ］の何れにもマッチング要求が格納されていないので、図９中の（Ｂ）に示すように、マッチング要求１［Ａ］はバッファＢＵ［Ａ］に一時的に格納され、これ以降にデキューされるマッチング要求とのマッチング成立を待つ。

次に、図９中の（Ｂ）において、キューＱＵ３からデキューされたマッチング要求２［ａｌｌ］に対する処理は、次のとおりである。デキューされたマッチング要求２［ａｌｌ］については、全てのバッファＢＵ［Ａ］、ＢＵ［Ｂ］、ＢＵ［ａｌｌ］に格納されているマッチング要求がマッチングの対象となる。サーバ３０は、対象のバッファＢＵ［Ａ］、ＢＵ［Ｂ］、ＢＵ［ａｌｌ］の何れかにマッチング要求が格納されているか否かを確認する。この場合の確認順序は、例えばランダムである。なお、各バッファを確認する優先順位を予め設定していてもよい。また、例えば、所定期間（例えば２４時間）毎に、育成選手オーダーを使用するという条件設定のマッチング要求の数と、イベキャラオーダーを使用するという条件設定のマッチング要求の数をそれぞれカウントし、より少ない方のマッチング要求を格納するバッファを、より多い方のマッチング要求を格納するバッファよりも優先的に確認（検索）するようにしてもよい。

図９中の（Ｂ）の場合、バッファＢＵ［Ａ］にマッチング要求１［Ａ］が格納されているので、図９中の（Ｃ）に示すように、サーバ３０は、マッチング要求１［Ａ］のユーザとマッチング要求２［ａｌｌ］のユーザとをマッチングする。

次に、図９中の（Ｃ）において、キューＱＵ３からデキューされたマッチング要求３［Ｂ］に対する処理は、次のとおりである。デキューされたマッチング要求３［Ｂ］については、バッファＢＵ［Ｂ］とバッファＢＵ［ａｌｌ］とに格納されているマッチング要求がマッチングの対象となる。サーバ３０は、対象のバッファＢＵ［Ｂ］とバッファＢＵ［ａｌｌ］の何れかにマッチング要求が格納されているか否かを確認する。この場合の確認順序は、例えばランダムである。なお、バッファＢＵ［Ｂ］またはバッファＢＵ［ａｌｌ］の何れか一方を優先的に確認するような優先順位を予め設定していてもよい。図９中の（Ｃ）の場合、対象のバッファＢＵ［Ｂ］およびバッファＢＵ［ａｌｌ］の何れにもマッチング要求が格納されていないので、図９中の（Ｄ）に示すように、マッチング要求３［Ｂ］はバッファＢＵ［Ｂ］に一時的に格納され、これ以降にデキューされるマッチング要求とのマッチング成立を待つ。

次に、図９中の（Ｄ）において、キューＱＵ３からデキューされたマッチング要求４［Ａ］に対する処理は、次のとおりである。デキューされたマッチング要求４［Ａ］については、バッファＢＵ［Ａ］とバッファＢＵ［ａｌｌ］とに格納されているマッチング要求がマッチングの対象となる。図９中の（Ｄ）の場合、対象のバッファＢＵ［Ａ］およびバッファＢＵ［ａｌｌ］の何れにもマッチング要求が格納されていないので、図９中の（Ｅ）に示すように、マッチング要求４［Ａ］はバッファＢＵ［Ａ］に一時的に格納される。

次に、図９中の（Ｅ）において、キューＱＵ３からデキューされたマッチング要求５［ａｌｌ］に対する処理は、次のとおりである。デキューされたマッチング要求５［ａｌｌ］については、全てのバッファＢＵ［Ａ］、ＢＵ［Ｂ］、ＢＵ［ａｌｌ］に格納されているマッチング要求がマッチングの対象となる。図９中の（Ｅ）の場合、バッファＢＵ［Ａ］にマッチング要求４［Ａ］、バッファＢＵ［Ｂ］にマッチング要求３［Ｂ］がそれぞれ格納されているので、確認順序をランダムとした場合、これらの何れかとマッチング要求５［ａｌｌ］がマッチングされる可能性が発生する。例えば、バッファＢＵ［Ａ］を先に確認（検索）した場合、サーバ３０は、マッチング要求４［Ａ］のユーザとマッチング要求５［ａｌｌ］のユーザとをマッチングする。一方、バッファＢＵ［Ｂ］を先に確認（検索）した場合、図９中の（Ｆ）に示すように、サーバ３０は、マッチング要求３［Ｂ］のユーザとマッチング要求５［ａｌｌ］のユーザとをマッチングする。

上記のマッチング処理は一例であり、これに限定されるものではなく、既存のアルゴリズムによる様々なマッチング処理を適用できる。

なお、使用オーダー条件およびイニング数条件の何れも「おまかせ」の条件設定を行ったユーザ同士をマッチングする場合、例えば使用オーダーおよびイニング数をランダムに決定してもよいし、予め設定しておいた優先度に従って使用オーダーおよびイニング数を決定してもよい。

また、上記のマッチング処理においては、ユーザのゲームレベルやチームランクが近いユーザ同士を優先的にマッチングする等のマッチング優先度の設定は行われていないが、そのようなマッチング優先度の設定を行ってもよい。例えば、リアルタイム対戦の総対戦回数、累計勝率、または直近の勝率（例えば、直近１０試合の勝率、直近１週間の勝率等）が所定範囲以内のユーザ同士を優先的にマッチングするようにしてもよい。また、ＣＰＵ対戦モード（すなわち他のゲームモード）のチームランクが所定範囲以内のユーザ同士を優先的にマッチングするようにしてもよい。

サーバ３０は、マッチングが成立した両ユーザのゲーム端末に対して、マッチング情報を送信する。マッチング情報には、マッチングが成立したゲーム条件の情報および対戦相手の情報が含まれる。ここで、マッチングが成立したゲーム条件の情報は、本実施の形態では使用オーダー条件およびイニング数条件である。また、対戦相手の情報には、対戦相手のユーザ名、マッチングが成立したゲーム条件に対応する使用オーダー、リーダーキャラクタ、通信強度、先攻または後攻の情報等が含まれる。リーダーキャラクタおよび通信強度については後述する。

サーバ３０からマッチング情報を受信したユーザ（ユーザ名をユーザＡとする）のゲーム端末１０の表示部１７には、図７に例示する対戦前確認画面Ｇ６００が表示される。図７では、サーバ３０によってユーザと対戦相手のユーザ（ユーザ名をユーザＢとする）とがマッチングされ、ユーザが先攻で対戦相手が後攻に決定されたものとする。

対戦前確認画面Ｇ６００には、ユーザに関する情報および対戦相手に関する情報が表示される。ユーザに関する情報には、ユーザ名Ｐ６１１、リーダーキャラクタの画像Ｐ６１２および通信強度の情報Ｐ６１３が含まれる。ここで、リーダーキャラクタとは、ユーザが所持するイベントキャラクタの中からユーザが任意に設定した特定のキャラクタである。なお、例えば、使用オーダーの４番打者や先発投手のキャラクタ等のユーザのチーム内の所定のキャラクタが自動でリーダーキャラクタに設定されるようにしてもよい。

通信強度の情報Ｐ６１３は、ユーザのゲーム端末１０の無線通信の電波強度（例えば、移動体通信基地局との間の電波強度、または無線ネットワークのアクセスポイントやルータとの間の電波強度等）を可視化したものである。本実施の形態では、電波強度を複数段階（例えば５段階）で可視化したアンテナアイコンを、通信強度の情報Ｐ６１３として表示する例を示している。なお、通信強度の情報Ｐ６１３を数値、記号、文字（例えば、微弱、弱、普通、強、最強）等で表示してもよい。例えば、スマートフォン等の無線通信機能を有するゲーム端末１０において測定される受信信号強度（ＲＳＳＩ：Received Signal Strength Indicator）の値を、通信強度の情報Ｐ６１３として適用することができる。

また、対戦前確認画面Ｇ６００に表示される対戦相手に関する情報には、対戦相手のユーザ名Ｐ６２１、リーダーキャラクタの画像Ｐ６２２および通信強度の情報Ｐ６２３が含まれる。

例えば、各ユーザのゲーム端末１０からマッチング要求を送信する際に、当該マッチング要求に現時点の通信強度の情報を含めてサーバ３０へ送信する。そして、サーバ３０はマッチングが成立した両ユーザに対してマッチング情報をそれぞれ送信する際に、当該マッチング情報に両ユーザの通信強度の情報（少なくとも相手ユーザの通信強度の情報）を含めるようにしてもよい。

あるいは、サーバ３０からマッチング情報を受領した両ユーザのゲーム端末１０間でＰ２Ｐ接続等により直接通信して、リアルタイムで一定周期毎に互いの通信強度の情報を交換し合うことにより、対戦前確認画面Ｇ６００に対戦相手の通信強度の情報Ｐ６２３が表示されるようにしてもよい。例えば、マッチングされた両ユーザのゲーム端末１０は、一定周期毎（例えば、１フレーム：１／６０秒毎）に、自端末の通信強度を測定し、測定した通信強度の情報を互いに相手側へ送信する。これにより、対戦前確認画面Ｇ６００において、ユーザ自身のゲーム端末１０の通信強度の情報Ｐ６１３および対戦相手のゲーム端末１０の通信強度の情報Ｐ６２３が、一定周期毎に更新される。

あるいは、マッチングされた両ユーザのゲーム端末１０間のデータのやり取りを、サーバ３０を経由して行うことも可能であり、リアルタイムで一定周期毎に互いの通信強度の情報をサーバ３０経由で交換し合ってもよい。この場合も、上記のＰ２Ｐ接続等による直接通信の場合と同様に、対戦前確認画面Ｇ６００において、ユーザ自身のゲーム端末１０の通信強度の情報Ｐ６１３および対戦相手のゲーム端末１０の通信強度の情報Ｐ６２３が、一定周期毎に更新される。

ユーザは、対戦前確認画面Ｇ６００に表示される、ユーザ自身のゲーム端末１０の通信強度の情報Ｐ６１３または対戦相手のゲーム端末１０の通信強度の情報Ｐ６２３を確認し、マッチングされた対戦相手との試合を開始するか否かを判断することができる。

なお、対戦前確認画面Ｇ６００に表示されるユーザに関する情報および対戦相手に関する情報としては、上記の情報以外にも、例えば、ユーザおよび対戦相手のゲームレベル、チームランク、リアルタイム対戦の総対戦回数、累計勝率、または直近の勝率等の情報を含めてもよい。

また、対戦前確認画面Ｇ６００には、マッチングが成立したゲーム条件の情報Ｐ６３１（図７の例では、イベキャラオーダーの使用、イニング数が３回裏まで）が表示される。また、対戦前確認画面Ｇ６００には、試合開始ボタンＢ６３２および制限時間を可視化するゲージＢ６３３が表示される。各ユーザは、マッチングが成立してから（例えば、対戦前確認画面Ｇ６００が表示されてから）制限時間以内に試合開始ボタンＢ６３２をタップしないと、マッチングされた対戦相手との対戦が自動的にキャンセルされる。前記制限時間以内であっても、ユーザが戻るボタンＢ６４０をタップすれば、対戦をキャンセルして図４のリアルタイム対戦のトップ画面Ｇ３００に戻る。マッチングされた両ユーザの何れもが、前記制限時間以内に試合開始ボタンＢ６３２をタップした場合に、マッチングが成立したゲーム条件の対戦が開始される。この対戦では、両ユーザは、マッチングが成立したゲーム条件に対応するオーダーを使用する。図７の例では、イベキャラオーダーを使用するというゲーム条件のマッチングが成立しているので、イベキャラオーダーを使用した対戦が実行される。

対戦が終了すると、表示部１７に対戦結果が表示される。また、両ユーザには対戦結果に応じたポイントやアイテム等の報酬が付与される。また、付与されたポイントを反映したリーグランキングが表示されるようにしてもよい。対戦後、ユーザは、所定の操作を行うことにより、今回の対戦内容をリプレイとして保存することができる。保存できるリプレイの数には上限が設定されており、上限を超えた保存の場合は、最も古いリプレイが消去される。

報酬の受け取りや上記リプレイの保存等の操作が完了すると、図４のリアルタイム対戦のトップ画面Ｇ３００に遷移する。トップ画面Ｇ３００には、戦績確認ボタンＢ３０５、リプレイボタンボタンＢ３０６および戻るボタンＢ３０７が含まれる。ユーザが戦績確認ボタンＢ３０５をタップすると、これまでのリアルタイム対戦の戦績を表示する画面に遷移する。ユーザがリプレイボタンボタンＢ３０６をタップすると、再生可能なリプレイのリストを表示する画面に遷移する。ユーザが前記リスト内からリプレイを選択すると、選択されたリプレイが再生される。ユーザが戻るボタンＢ３０７をタップすると、様々なゲームモードを選択可能な本ゲームのホーム画面に遷移する。

［３．ゲームシステムの機能的構成］
図１０は、ゲームシステム１の機能的な構成の一例を示す概略の機能ブロック図である。図１０に示すように、ゲームシステム１はデータ記憶部１００を含む。例えば、データ記憶部１００は、データベースＤＢ、ＲＯＭ１２、ＲＡＭ１３、補助記憶装置１４、ＲＯＭ３２、ＲＡＭ３３、及び補助記憶装置３４の少なくとも一つによって実現される。データ記憶部１００はゲームを提供するために必要なデータを記憶する。

データ記憶部１００に記憶されるデータの具体例として、上記で説明した野球ゲームを提供するために必要なデータについて説明する。データ記憶部１００は、ユーザ情報テーブルＴＢＬ１０１、キャラクタ情報テーブルＴＢＬ１０２、ゲーム条件テーブルＴＢＬ１０３、チームオーダーテーブルＴＢＬ１０４、所持キャラクタデータＤＴ１０５、チームオーダーデータＤＴ１０６等を記憶する。なお、キャラクタ情報テーブルＴＢＬ１０２（図８参照）については既に説明済みであるため、ここではその説明を省略する。

例えば、データ記憶部１００に記憶されているゲームを実行するための各種データは、データベースＤＢ又はサーバ３０の補助記憶装置３４等に記憶されており、ゲーム端末１０がサーバ３０にアクセスした場合に、必要なデータがゲーム端末１０のＲＡＭ１３又は補助記憶装置１４にダウンロードされるようにすることができる。また、ゲーム端末１０で実行されたゲームの結果やデータの変更についての情報は、リアルタイムで又は所定のタイミングでゲーム端末１０からサーバ３０へ送信され、データベースＤＢ又はサーバ３０の補助記憶装置３４等に記憶されているデータが適宜更新されるようにすることができる。また、例えば、ゲームの少なくとも一部を、各ユーザのゲーム端末１０において、サーバ３０にログインせずにオフラインでもゲームが実行できるように、必要なデータをゲーム端末１０の補助記憶装置１４等に記憶しておくようにしてもよい。

図１１は、ユーザ情報テーブルＴＢＬ１０１の一例を示す。図１１の例ではユーザＩＤ「Ｕ１」のユーザ１人分のユーザ情報が記憶されるユーザ情報テーブルＴＢＬ１０１を示しているが、ゲームシステム１に登録されている全てのユーザを対象としたユーザ情報テーブルＴＢＬ１０１が、ゲームシステム１のデータ記憶部１００（例えば、データベースＤＢや補助記憶装置３４等）に記憶されている。また、ユーザのゲーム端末１０の記憶装置（例えば、補助記憶装置１４等）には、当該ユーザのユーザＩＤに関連付けられたユーザ情報が記憶されている。

ユーザ情報テーブルＴＢＬ１０１は、「ユーザＩＤ」、「ユーザ名」、「育成モード」、「ＣＰＵ対戦モード」、「リアルタイム対戦モード」等のフィールドを含む。「ユーザＩＤ」は各ユーザを一意に特定するための識別情報である。「ユーザ名」フィールドはユーザの名前を示す。「育成モード」、「ＣＰＵ対戦モード」および「リアルタイム対戦モード」フィールドには、ぞれぞれのゲームモードに関する各種情報が記憶される。例えば、「育成モード」フィールドには、現在育成中の主人公キャラクタの情報、イベントデッキの情報（イベントデッキに設定されているイベントキャラクタのＩＤ等）、現在のターン等の情報が記憶される。例えば、「ＣＰＵ対戦モード」フィールドには、現在の所属リーグレベル、累計ポイント、リーグランキング等の情報が記憶される。例えば、「リアルタイム対戦モード」フィールドには、現在保存されているマッチングの条件設定の情報、戦績情報、リプレイ情報等が記憶される。

マッチングの条件設定の情報に関し、例えば、前回のマッチングで適用されたマッチングの条件設定の情報は保存され、次回のマッチングでユーザが条件設定を変更しなければ、前回のマッチングの条件設定が適用されるようにしてもよい。あるいは、マッチングの都度、デフォルトの条件設定（例えば、使用オーダー「おまかせ」、イニング数「おまかせ」）が適用され、必要に応じてユーザが条件設定を変更するようにしてもよい。

なお、図１１では省略されているが、その他のフィールドもユーザ情報テーブルＴＢＬ１０１に含まれる。例えば、ユーザが所有しているゲーム内の様々なポイント、ユーザのユーザＩＤに関連付けられる他のユーザ（仲間、フレンド等）のユーザＩＤのフィールドが、ユーザ情報テーブルＴＢＬ１０１に含まれる。

図１２は、ゲーム条件テーブルＴＢＬ１０３の一例を示す。このゲーム条件テーブルＴＢＬ１０３は、マッチングの際のゲーム条件に関するマスタテーブルである。ゲーム条件テーブルＴＢＬ１０３は、「条件種別」、「ゲーム条件ＩＤ」および「ゲーム条件」のフィールドを含む。前述の野球ゲームの例では、「条件種別」フィールドに、「使用オーダー」と「イニング数」とが設定されている。「ゲーム条件ＩＤ」は各ゲーム条件を一意に特定するための識別情報である。「ゲーム条件」フィールドにはゲーム条件の情報が記憶される。

図１３は、チームオーダーテーブルＴＢＬ１０４の一例を示す。このチームオーダーテーブルＴＢＬ１０４は、本ゲームで設定可能なチームオーダーに関するマスタテーブルである。チームオーダーテーブルＴＢＬ１０４は、「オーダーＩＤ」、「チームオーダー名」、「対応ゲーム条件」および「対応リーグ」のフィールドを含む。「オーダーＩＤ」は各チームオーダーを一意に特定するための識別情報である。「チームオーダー名」フィールドにはチームオーダー名の情報が記憶される。「対応ゲーム条件」フィールドにはチームオーダーと関連付けられるマッチングのゲーム条件の情報（例えばゲーム条件ＩＤ）が記憶される。「対応リーグ」フィールドにはチームオーダーと関連付けられるゲーム内リーグが関連付けられる。

図１４は、所持キャラクタデータＤＴ１０５の一例を示す。この所持キャラクタデータＤＴ１０５は、ユーザが所持しているキャラクタ（すなわち、ユーザのユーザＩＤと関連付けられているキャラクタ）の情報を示すデータである。図１４の例では、ユーザＩＤ「Ｕ１」に関連付けられている１人分の情報が記憶される所持キャラクタデータＤＴ１０５を示しているが、ゲームシステム１に登録されている全てのユーザを対象とした所持キャラクタデータＤＴ１０５が、データ記憶部１００に記憶されている。

所持キャラクタデータＤＴ１０５では、イベントキャラクタと育成選手とが分けて管理される。所持キャラクタデータＤＴ１０５は、「キャラクタＩＤ」、「プロファイルＩＤ」、「能力パラメータ」および「レベル」等のフィールドを含む。「キャラクタＩＤ」は、ユーザが所持しているキャラクタを一意に識別する識別情報である。例えば、ユーザが抽選等により同一名称且つ同一レアリティの複数のイベントキャラクタを獲得することがある。この場合、当該複数のイベントキャラクタのプロファイルＩＤはどれも同じであるが、それぞれに異なるキャラクタＩＤが付与されて、ユーザＩＤと関連付けられる。「パラメータ」フィールドには、各キャラクタの能力パラメータ等の各種パラメータの情報が記憶される。キャラクタの入手後に変化したパラメータも「パラメータ」フィールドに反映される。

図１５は、チームオーダーデータＤＴ１０６の一例を示す。チームオーダーデータＤＴ１０６は、本ゲームにおいて設定される複数のチームオーダーのデータである。前述の野球ゲームの例では、イベキャラオーダー（オーダーＩＤ：ＯＤ１）および育成選手オーダー（オーダーＩＤ：ＯＤ２）を含む。ユーザチームデータＤＴ１０６は、ユーザ毎に（ユーザＩＤと関連付けて）記憶される。ユーザチームデータＤＴ１０６は、投手メンバ（先発投手、中継ぎ投手、抑え投手）、及び野手メンバ（スターティングメンバ及び控え）のキャラクタＩＤを含む。また、ユーザチームデータＤＴ１０６は、ユーザの操作に基づいて設定された（又はゲームシステム１により自動で設定された）チーム内のポジションの情報および打順の情報を含む。

図１０に示すように、ゲームシステム１は制御部１１０を含む。制御部１１０は、記憶装置（ＲＯＭ１２、ＲＡＭ１３、補助記憶装置１４、ＲＯＭ３２、ＲＡＭ３３又は補助記憶装置３４等）に記憶されているゲームプログラムを、ゲーム端末１０のＣＰＵ１１又はサーバ３０のＣＰＵ３１が実行することにより実現される。制御部１１０の機能の一部をゲーム端末１０のＣＰＵ１１によって実現し、残りの機能をサーバ３０のＣＰＵ３１によって実現してもよい。または、制御部１１０の機能の全てをサーバ３０のＣＰＵ３１によって実現してもよいし、制御部１１０の機能の全てをゲーム端末１０のＣＰＵ１１によって実現してもよい。

制御部１１０は、登録部１１１（登録手段の一例）、条件設定部１１２（条件設定手段の一例）、マッチング部１１３（マッチング手段の一例）及びゲーム実行部１１４（ゲーム実行手段の一例）を含む。例えば、登録部１１１、条件設定部１１２およびゲーム実行部１１４をゲーム端末１０のＣＰＵ１１によって実現し、マッチング部１１３をサーバ３０のＣＰＵ３１によって実現してもよい。

前記登録部１１１は、ユーザの操作に基づいて、少なくとも１つのオブジェクトを含む使用対象を複数登録する機能を有する。

ここで、前記「ユーザ」とは、例えば、ゲーム端末１０を操作してゲームをプレイする人である。例えば、ユーザ識別情報（ユーザＩＤ）が各ユーザまたは各ユーザが操作するゲーム端末１０に対して設定され、各ユーザはユーザ識別情報によって識別（特定）される。

また、前記「オブジェクト」とは、ゲームにおいて使用され得るものである。例えば、ゲームキャラクタ、ゲームカード（デジタルカード）、又はゲームアイテム等が「オブジェクト」の一例に相当する。例えば、スポーツ選手等の人物、競走馬等の生物、競走馬等の生物を擬人化したもの、モンスター等の架空の人物や生物、ロボット・車・バイク・自転車等の非生物を示すゲームキャラクタやゲームカードが「オブジェクト」の一例に相当する。また、例えば、キャラクタに装備される装備アイテムが「オブジェクト」の一例に相当する。例えば、「オブジェクト」は、実在する人物や生物に対応するゲームキャラクタやゲームカードであってもよいし、実在する人物等に対応するものでなくてもよい。

また、前記「使用対象」は、マッチングにより実行されるゲームにおいてユーザによって使用され得る対象となるものであり、少なくとも１つのオブジェクトを含む。
マッチングにより実行されるゲームは、例えばユーザ間で「対戦」を行う対戦ゲームであってもよいし、複数のユーザによる「協力プレイ」等が可能なマルチプレイゲーム（またはマルチプレイヤゲームともいう）であってもよい。

ここで、「対戦ゲーム」とは、例えば、ユーザが対戦相手と対戦して優劣や勝敗を決するコンピュータゲームである。例えば、ネットワークを介して接続された複数のユーザのゲーム端末１０の間で行われるオンライン対戦ゲームが、「対戦ゲーム」の一例に相当する。ここで「対戦」とは、対戦相手と優劣、勝敗、順位等を決することである。対戦ゲームの結果は必ずしも勝敗が決まらなくてもよく、引き分けになる場合があってもよい。スポーツゲームにおける試合、競馬・車・オートバイ・自転車等のレース、格闘・戦闘ゲームにおけるバトル等が「対戦」の一例に相当する。

ユーザの対戦相手は、１人のユーザであってもよいし、２人以上であってもよい。１対１の対戦であってもよいし、１対多の対戦であってもよいし、多対多の対戦であってもよい。
例えば、２人のユーザがそれぞれ自分の野球チームの複数の選手キャラクタを使用して試合をする前述の野球ゲームが、「対戦ゲーム」の一例に相当する。また、例えば、３人以上のユーザが、同じゲーム空間内でそれぞれ自分のオブジェクトを使用して戦うゲームが、「対戦ゲーム」の一例に相当する。例えば、競馬レースゲームにおいて、複数のユーザが各自の競走馬キャラクタを所定数以内で出走させて順位を競うゲームが、「対戦ゲーム」の一例に相当する。

前述の「使用対象」に関し、例えば、ユーザが１つのオブジェクトを使用して対戦相手と対戦するゲームの場合であれば、当該１つのオブジェクトが「使用対象」の一例に相当する。例えば、野球ゲームのホームラン競争の対戦に使用する選手キャラクタが「使用対象」の一例に相当する。また、競馬レースで対戦する場合、競馬レースに使用する競走馬キャラクタ、競走馬を擬人化したキャラクタ、または競走馬に乗馬するジョッキキャラクタが「使用対象」の一例に相当する。また、カーレースで対戦する場合、カーレースに使用するレーシングカーキャラクタまたはレーシングカーに乗車するドライバキャラクタが「使用対象」の一例に相当する。

また、例えば、ユーザが２つ以上のオブジェクトを使用して対戦相手等のプレイ相手とプレイするゲームの場合であれば、当該２つ以上のオブジェクトまたは当該２つ以上のオブジェクトを含むグループ（デッキ、チーム、集団、隊、パーティ、ギルド等）が「使用対象」の一例に相当する。「使用対象」は、所定数のオブジェクトから構成されるデッキやチーム等のグループであってもよいし、所定数以内（１～所定数までの間でユーザが任意に設定可能）のオブジェクトから構成されるグループであってもよいし、所定数以上のオブジェクトから構成されるグループであってもよいし、ｎ以上且つｍ以下（ｎ及びｍは１以上の任意の自然数）のオブジェクトから構成されるグループであってもよい。
例えば、前述の野球ゲームの場合、所定数（例えば２５名）の選手キャラクタ（育成選手またはイベントキャラクタ）で構成されるチームが「使用対象」の一例に相当する。また、所定数の選手キャラクタの打順や守備ポジションの情報を含むチームオーダーも「使用対象」の一例に相当する。また、競馬レースやカーレースの場合、レースに出場する所定数以内（例えば３頭以内）の競走馬キャラクタやレーシングカーキャラクタで構成されるデッキが「使用対象」の一例に相当する。

登録部１１１における前記「ユーザの操作」に関し、使用対象を複数登録するためのユーザの操作は、マッチング要求を行う前であれば任意のタイミングで可能である。例えば、図５に例示する育成選手オーダー編集画面Ｇ４００において、おまかせボタンＢ４２１を操作して自動で使用対象としての育成選手オーダーを登録することも、「ユーザの操作」の一例に該当する。また、一度登録した使用対象の情報は保存され、ユーザが使用対象の変更（編集）操作をするまでは、同じ使用対象の登録情報が複数回のマッチングにおいて繰り返し適用されるようにしてもよい。

前述の野球ゲームの例では、登録部１１１は、ユーザの操作に基づいて、所定数（例えば２５名）の育成選手から構成される育成選手オーダー（使用対象の一例）と、所定数（例えば２５名）のイベントキャラクタから構成されるイベキャラオーダー（使用対象の一例）とを、記憶装置（例えば、補助記憶装置１４、補助記憶装置３４、データベースＤＢ等）に記憶させて登録する。登録部１１１によって登録される使用対象の数は３以上であってもよい。

登録部１１１によって登録される複数の使用対象は、それぞれマッチングに用いられるゲーム条件に対応している。例えば、図１３に示すように、イベキャラオーダー（オーダーＩＤ：ＯＤ１）は、イベキャラオーダー使用条件（ゲーム条件ＩＤ：ＧＡ１）に関連付けられている。また、育成選手オーダー（オーダーＩＤ：ＯＤ２）は、育成選手オーダー使用条件（ゲーム条件ＩＤ：ＧＡ２）に関連付けられている。

前記条件設定部１１２は、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を可能とする機能を有する。前述の野球ゲームの例では、条件設定部１１２は、図６に示すように２つの使用対象としてのイベキャラオーダーおよび育成選手オーダーのそれぞれに対応する２つのゲーム条件（イベキャラオーダー使用、育成選手オーダー使用）の何れでもよいとする「おまかせ」の条件設定を可能とする。

ここで、前記「ゲーム条件」とは、ユーザがマッチングの相手を探す場合に設定できる、マッチングにより実行されるゲームに関する条件である。この「ゲーム条件」を「マッチング条件」や「検索条件」等と称してもよい。
例えば、ユーザが参加可能なリーグが複数ある場合、ユーザが参加を希望するそれぞれのリーグを「ゲーム条件」として設定できるようにしてもよい。例えば、２つのリーグが設定されている場合、そのうちの１つのみ、または２つ（の何れでもよい）を「ゲーム条件」として設定できるようにしてもよい。また、例えば、３つのリーグが設定されている場合、そのうちの１つのみ、２つ（の何れでもよい）、３つ（の何れでもよい）を「ゲーム条件」として設定できるようにしてもよい。４つ以上のリーグが設定されている場合も同様である。また、リーグ以外のゲーム条件についても同様である。
例えば、複数のリーグにそれぞれ対応する複数のデッキが事前に登録されている場合、ユーザが使用を希望するそれぞれのデッキを「ゲーム条件」として設定できるようにしてもよい。

上記のように、前記条件設定部１１２は、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数の前記ゲーム条件の何れか１つを指定した前記条件設定も可能とする。

それ以外にも、「ゲーム条件」には様々な条件を設定可能である。一例を挙げると、野球ゲームの場合、試合のイニング数（例えば３回裏まで、６回裏まで、９回裏まで等）、天候（例えば晴、曇、雨、雪等）、季節（例えば春、夏、秋、冬）、球場（例えば日本のプロ野球の各球団の球場に対応する仮想的な球場の１つ以上を選択可能）、ユーザレベル、チームランク、選手キャラクタのパラメータ（例えば能力ランク）等を「ゲーム条件」として設定して、ユーザがマッチングの相手を探すことができるようにしてもよい。
また、前述の育成に適用した各シナリオ（複数のシナリオのうちの１つのみ、または２以上の何れでもい）を「ゲーム条件」として設定できるようにしてもよい。
また、例えばリアルスポーツを題材としたゲームの場合、実在選手に対応するオブジェクト（例えば選手キャラクタ、デジタルカード）がゲームに用いられる。このような場合、同一選手名のオブジェクトであっても、ユーザが抽選（いわゆるガチャ）等により入手した時期によって、能力パラメータが異なる場合がある。例えば、「２０２１年度シリーズ」の選手キャラクタＡと「２０２２年度シリーズ」の選手キャラクタＡとは選手名は同じでも能力パラメータの値は異なる。そこで、オブジェクトと関連付けられているオブジェクトの入手時期（またはガチャの実施時期、入手時期を示すシリーズ名等）の違いを、「ゲーム条件」として設定できるようにしてもよい。
また、例えば、実在選手に対応する同一選手名のオブジェクトであっても、オブジェクト種別によって、能力パラメータの値を異ならせてもよい。例えば、実在選手の現シーズンの成績を能力パラメータに反映させたオブジェクト種別Ａ、当該実在選手が過去に脚光を浴びた時期の成績を能力パラメータに反映させたオブジェクト種別Ｂ、当該実在選手のキャリア最高の瞬間を能力パラメータに反映させたオブジェクト種別Ｃ等である。そこで、オブジェクトと関連付けられている「オブジェクト種別」の違いを、「ゲーム条件」として設定できるようにしてもよい。
また、例えば、抽選入手モードにおいて、種別の異なる複数のガチャを設けて、実行するガチャの種別の違いによりユーザが入手できる（または入手し易くなる）オブジェクト種別が異なるようにしてもよい。ガチャの種別の違いの一例としては、例えば課金対象のアイテムまたはポイントを消費して実行できる種別のガチャ、課金対象ではないアイテムまたはポイントを消費して実行できる種別のガチャ、特定のオブジェクト種別のみを抽選対象とした種別のガチャ、特定のオブジェクト種別のみを抽選対象から除外した種別のガチャ、特定のオブジェクト種別の抽選確率を高くした（または低くした）種別のガチャ等がある。そこで、オブジェクトと関連付けられている「ガチャの種別」の違い（換言すればオブジェクトの入手ルートのバリエーション）を、「ゲーム条件」として設定できるようにしてもよい。
また、競馬ゲームのレースの場合、レース名（例えば実在する複数のレース名にそれぞれ対応する複数のレース名）、馬場（例えば芝、ダート）、距離（例えば短距離、マイル、中距離、長距離、または具体的な１２００ｍ、１６００ｍ等の数値による距離）、開催地（例えば実在する競馬場の複数の開催地にそれぞれ対応するゲーム内の仮想的な複数の開催地）、コースの特徴（例えば右回り、左回り、直線、内回り、外回り、１周目外回り２周目内回り、内外回りなし）、馬場状態（例えば良、稍重、重、不良等）、天候（例えば晴、曇、雨、雪等）、季節（例えば春、夏、秋、冬）、ユーザレベル、チームランク、競走馬キャラクタのパラメータ（例えば能力ランク）等を「ゲーム条件」として設定して、ユーザがマッチングの相手を探すことができるようにしてもよい。

また、前記「複数の前記使用対象にそれぞれ対応する複数のゲーム条件」とは、複数のゲーム条件にそれぞれ対応する複数の使用対象（例えばチームオーダー、デッキ等）が登録されているということである。

また、前記「複数のゲーム条件のうちの２以上の何れでもよいとする条件設定」には、「複数のゲーム条件の何れでもよいとする条件設定」と、「複数のゲーム条件の一部（２以上）のうちの何れでもよいとする条件設定」とを含む。
例えば、登録された２つの使用対象にそれぞれ対応する２つのゲーム条件がある場合、何れのゲーム条件でもよいとする条件設定は、「複数のゲーム条件のうちの２以上の何れでもよいとする条件設定」の一例である。
また、例えば、登録された３つの使用対象にそれぞれ対応する３つのゲーム条件がある場合、３つのゲーム条件の何れでもよいとする条件設定」も、「３つのゲーム条件のうちの任意の２つをユーザが選択して当該２つの何れでもよいとする条件設定」も、「複数のゲーム条件のうちの２以上の何れでもよいとする条件設定」の一例である。登録された４つ以上の使用対象にそれぞれ対応する４つ以上のゲーム条件がある場合も同様である。

上記のような条件設定を可能とする態様としては、次のような態様がある。
複数のゲーム条件をそれぞれ選択するための選択肢とは別に、例えば「おまかせ」、「何れでも可」、「指定なし」、「ランダム」等の特定の選択肢を設けて、ユーザが当該特定の選択肢を選択することにより、「複数のゲーム条件の何れでもよいとする条件設定」を可能としてもよい。前述の図６の検索設定画面Ｇ５００において「おまかせ」の選択肢Ｐ５１１を選択することにより使用オーダー条件を設定することが、その一例である。

また、複数のマッチング条件の選択肢をユーザが同時に複数選択可能とすることにより、「複数のマッチング条件の何れでもよいとする条件設定」や、「複数のゲーム条件の一部（２以上）のうちの何れでもよいとする条件設定」を可能としてもよい。この例を図１６に示す。図１６の検索設定画面Ｇ７００は、図６の検索設定画面Ｇ５００の変形例であり、同一の機能を有する構成要素には同一の部材番号を付す。検索設定画面Ｇ７００は、参加リーグ条件設定領域Ａ７１０、イニング数条件設定領域Ａ７２０、天候条件設定領域Ａ７３０を含む。参加リーグ条件設定領域Ａ７１０には、イベキャラリーグに参加するという選択肢Ｐ７１１と、育成選手リーグに参加するという選択肢７１２とを含む。ユーザは選択肢Ｐ７１１、Ｐ７１２の何れか一方を選択してもよいし、図１６の例のように選択肢Ｐ７１１、Ｐ７１２を同時に両方選択してもよく、両方選択した場合は、図６に例示する「おまかせ」の選択肢を選択した場合と同じ意味をなす。イニング数条件設定領域Ａ７２０は３つのゲーム条件の選択肢Ｐ７２１～Ｐ７２３を含み、図１６の例のように選択肢７２１、Ｐ７２２を選択すれば、イニング数に関する３つのゲーム条件の一部（２つ）のうちの何れでもよいとする条件設定が可能である。天候条件設定領域Ａ７３０には、晴れの選択肢Ｐ７３１と、雨の選択肢７３２とを含み、図１６の例のように、１つの選択肢のみを選択してもよい。

図１７は、図１６の例に対応するチームオーダーテーブルＴＢＬ２０４の一例を示す。図１７では、３つのイベキャラオーダーと３つの育成選手オーダーの合計６つのチームオーダーを登録できる例を示している。
「イベキャラオーダー１（オーダーＩＤ：ＯＤ１１）」は、「イベキャラリーグ参加（ゲーム条件ＩＤ：ＧＣ１）」且つ「イニング数３回裏まで（ゲーム条件ＩＤ：ＧＢ１）」の複合条件に対応付けられている。「イベキャラオーダー２（オーダーＩＤ：ＯＤ１２）」は、「イベキャラリーグ参加（ゲーム条件ＩＤ：ＧＣ１）」且つ「イニング数６回裏まで（ゲーム条件ＩＤ：ＧＢ２）」の複合条件に対応付けられている。「イベキャラオーダー３（オーダーＩＤ：ＯＤ１３）」は、「イベキャラリーグ参加（ゲーム条件ＩＤ：ＧＣ１）」且つ「イニング数９回裏まで（ゲーム条件ＩＤ：ＧＢ３）」の複合条件に対応付けられている。このように、同じ種類のオブジェクト（ここではイベントキャラクタ）で構成される同じ種類の使用対象（チームオーダー、デッキ等）を、複数登録できるようにしてもよい。
「育成選手オーダー１（オーダーＩＤ：ＯＤ２１）」は、「育成選手リーグ参加（ゲーム条件ＩＤ：ＧＣ２）」且つ「イニング数３回裏まで（ゲーム条件ＩＤ：ＧＢ１）」の複合条件に対応付けられている。「育成選手オーダー２（オーダーＩＤ：ＯＤ２２）」は、「育成選手リーグ参加（ゲーム条件ＩＤ：ＧＣ２）」且つ「イニング数６回裏まで（ゲーム条件ＩＤ：ＧＢ２）」の複合条件に対応付けられている。「育成選手オーダー３（オーダーＩＤ：ＯＤ２３）」は、「育成選手リーグ参加（ゲーム条件ＩＤ：ＧＣ２）」且つ「イニング数９回裏まで（ゲーム条件ＩＤ：ＧＢ３）」の複合条件に対応付けられている。
上記では２つのゲーム条件を含む複合条件の例を示したが、３つ以上のゲーム条件を含む複合条件であってもよい。

なお、図１７の例では、３つのイベキャラオーダー１～３を、それぞれ前述の複合条件に対応付けているが、単独のゲーム条件に対応付けてもよい。例えば、イベキャラリーグにのみ参加できる（育成選手リーグがない）対戦モードの場合、「育成選手オーダー１」を「イニング数３回裏まで」の単独のゲーム条件に対応付け、「育成選手オーダー２」を「イニング数６回裏まで」の単独のゲーム条件に対応付け、「育成選手オーダー３」を「イニング数９回裏まで」の単独のゲーム条件に対応付けるようにしてもよい。試合のイニング数が増えるほど、各選手のスタミナの能力や、中継ぎ投手、抑え投手、代打要員（控え）の役割がより重要になってくるので、試合のイニング数に応じて複数のチームオーダーを登録できるようにしてもよい。

前記マッチング部１１３は、前記条件設定（複数の使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を含む）を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングする機能を有する。マッチング部１１３によるマッチング処理は、前述のとおり既存の様々なアルゴリズムを適用できる。
ここで、前記「プレイ相手」とは、マッチングにより実行されるゲームにおいてユーザと一緒にプレイする他のユーザ（または他のユーザのゲーム端末１０）である。対戦ゲーム場合は対戦相手の他のユーザが「プレイ相手」の一例に相当する。「プレイ相手」は１人ではなく複数人であってもよい。

前記ゲーム実行部１１４は、前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行する機能を有する。
図１３に例示する２つのチームオーダーを登録できる前述の野球ゲームの例では、ゲーム実行部１１４は、例えば「イベキャラオーダー使用」のゲーム条件でマッチングが成立した場合（図６のイニング数の条件は何れでもよい）、当該ゲーム条件に対応するイベキャラオーダーを使用した対戦を実行する。なお、対戦相手のゲーム端末１０においても、同じゲーム条件が適用され、対戦相手のユーザが登録しているイベキャラオーダーがユーザとの対戦に使用される。「育成オーダー使用」のゲーム条件でマッチングが成立した場合（イニング数の条件は何れでもよい）も同様である。

また、図１７に例示する６つのチームオーダーを登録できる前述の野球ゲームの例では、ゲーム実行部１１４は、例えば「イベキャラオーダー使用」且つ「イニング数３回裏まで」のゲーム条件でマッチングが成立した場合（図１６の天候の条件は何れでもよい）、当該ゲーム条件に対応する「イベキャラオーダー１」を使用した対戦を実行する。図１７の「対応ゲーム条件」フィールドに記憶されている他のゲーム条件でマッチングが成立した場合（この例では天候の条件は何れでもよい）も同様に、成立したゲーム条件に対応するチームオーダーを使用した対戦が実行される。

前記図６の例におけるイニング数のゲーム条件は、マッチングの条件設定に含めることはできるが、イベキャラオーダーおよび育成選手オーダーには対応付けられていない（図１３参照）。また、前記図１６の例における天候のゲーム条件も、マッチングの条件設定に含めることはできるが、イベキャラオーダーおよび育成選手オーダーには対応付けられていない（図１７参照）。これらの例のように、前記条件設定部１１２は、前記使用対象に対応する前記ゲーム条件とは異なる他のゲーム条件を前記条件設定に含めることを可能としてもよい。

ゲーム実行部１１４が実行する「使用対象を使用したゲーム」は、例えば、ユーザ及びプレイ相手がそれぞれ使用対象のオブジェクトを自ら操作することによって進行するようなゲームであってもよい。また、前記「使用対象を使用したゲーム」は、例えば、コンピュータ（ＣＰＵ１１またはＣＰＵ３１）がユーザの使用対象のオブジェクトと、プレイ相手の使用対象のオブジェクトとに基づいてシミュレーション処理を実行して対戦等のゲーム経過を自動的に決定し、特定の場面に限って、ユーザ及びプレイ相手が自らの使用対象のオブジェクトを操作するようなゲームであってもよい。一例を挙げると、野球ゲームにおいて、基本的に試合が自動進行パートで進行し、試合経過の概要（試合のポイント）のみを画面に表示する。そして、自動進行パート中で試合状況が所定状況（例えば、三塁又は二塁に走者がいる状況）になった場合に限って、自動進行パートからアクションパートに切り替わり、ユーザ及びプレイ相手が選手キャラクタに対する操作を行う。

また、前記「使用対象を使用したゲーム」は、例えば、コンピュータがユーザの使用対象のオブジェクトと、プレイ相手の使用対象のオブジェクトとに基づいてシミュレーション処理を実行することによって対戦結果が自動的に決定されるようなゲームであってもよい。一例を挙げると、競馬レースゲームにおいて、ユーザの使用対象の競走馬キャラクタ（複数であってもよい）と、プレイ相手（複数であってもよい）の使用対象の競走馬キャラクタ（複数であってもよい）とが、マッチングが成立したゲーム条件のレースに出走し、レースの経過および着順等の結果については、各競走馬キャラクタのパラメータに基づいてコンピュータが自動的に決定する。この場合、ユーザは、レース出走前に、使用対象の競走馬キャラクタ毎に作戦（逃げ、先行、差し、追込等）を設定する操作ができるようにしてもよい。

また、本ゲームでは、ユーザが参加可能な複数のゲーム内リーグを設定してもよい。前述の野球ゲームの例では、「育成選手リーグ」および「イベキャラリーグ」が設けられている。
ここで、前記「ゲーム内リーグ」とは、ゲーム内に仮想的に設けられ、ユーザ同士が試合やレース等のゲームを行うことができるリーグである。ゲーム内リーグは複数設けられており、ユーザは任意のリーグに参加可能である。「ゲーム内リーグ」は、ゲーム内に複数設けられてユーザが任意に参加できる「ステージ」であってもよい。

そして、前記登録部１１１は、ユーザの操作に基づいて、複数の前記ゲーム内リーグにそれぞれ対応する複数の前記使用対象を登録する機能を有する。前述の野球ゲームの例では、前記登録部１１１は、ユーザの操作に基づいて、「育成選手リーグ」および「イベキャラリーグ」にそれぞれ対応する「育成選手オーダー」および「イベキャラオーダー」を記憶装置に記憶して登録する。

ここで、上述のように複数の使用対象は複数のゲーム条件のそれぞれに対応付けることができるので、「おまかせ」の条件設定でマッチングが成立し、成立したゲーム条件に対応する使用対象が使用されることにより、当該使用対象に対応するゲーム内リーグへ参加したゲームが実行される。

また、「ユーザが参加したい前記ゲーム内リーグ」、または「ユーザが使用したい、前記ゲーム内リーグに対応する前記使用対象」を前記ゲーム条件に含めてもよい。
前述の野球ゲームの例では、図１６の参加リーグ（イベキャラリーグ又は育成選手リーグ）のゲーム条件が、「ユーザが参加したいゲーム内リーグ」のゲーム条件の一例に相当する。また、図６の使用オーダー（イベキャラオーダー又は育成選手オーダー）のゲーム条件が、「ユーザが使用したい、ゲーム内リーグに対応する使用対象」のゲーム条件の一例に相当する。

そして、前記条件設定部１１２は、ユーザの操作に基づいて、複数の前記ゲーム内リーグのうちの２以上の何れでもよいとする条件設定、または複数の前記ゲーム内リーグにそれぞれ対応する複数の前記使用対象のうちの２以上の何れを使用してもよいとする条件設定を可能としてもよい。
前述の野球ゲームの例では、図１６に示すように、参加リーグ（イベキャラリーグ又は育成選手リーグ）の２つの選択肢を両方とも選択することにより、何れでもよいとする条件設定が可能である。また、図６に示すように、使用オーダー（イベキャラオーダー又は育成選手オーダー）に関して「おまかせ」の選択肢を選択することにより、何れのオーダーを使用してもよいとする条件設定が可能である。

各ユーザは複数のゲーム内リーグのそれぞれに対応した使用対象（オーダー、デッキ等）を登録し、また同一のゲーム内リーグにおいて、マッチングされたプレイ相手（他ユーザ）とゲーム内リーグに対応する使用対象を用いてゲームプレイをする。よって、「ユーザが参加したい前記ゲーム内リーグ」のゲーム条件は、「ユーザが使用したい、ゲーム内リーグに対応する使用対象」のゲーム条件と同様の意味を持つ。

また、前記使用対象に含まれるオブジェクトには、種類の異なる第１オブジェクトと第２オブジェクトとを少なくとも含むようにしてもよい。前述の野球ゲームの例では、育成選手が第１オブジェクトの一例であり、イベントキャラクタが第２オブジェクトの一例である。

ここで、前記「種類の異なる第１オブジェクトと第２オブジェクト」に関し、オブジェクトの種類の違いの一例は、（１）ユーザがオブジェクトを獲得する入手ルートの違い（例えばゲームの実行により育成されるものか、抽選により獲得できるものか等）、（２）使用の態様の違い（例えばゲーム内の所定のモードで、操作対象のオブジェクトとして使用されるものか、非操作対象のオブジェクトとして使用されるものか等）、（３）入手後のパラメータの変更可能性の違い（例えば、強化等の処理によってパラメータを変更可能か否か等）、（４）変更可能なパラメータの違い等である。

そして、複数の前記使用対象には、前記第１オブジェクトが登録される第１使用対象と前記第２オブジェクトが登録される第２使用対象とを少なくとも含むようにしてもよい。前述の野球ゲームの例では、育成選手が登録される育成選手オーダーが「第１使用対象」の一例であり、イベントキャラクタが登録されるイベキャラオーダーが「第２使用対象」の一例である。

また、前記第１使用対象を構成する前記第１オブジェクトは、パラメータを変更又は設定することによって育成された育成オブジェクトとユーザ識別情報とが関連付けられたものとしてもよい。

ここで、「オブジェクトのパラメータ」とは、オブジェクトに設定されたパラメータである。換言すれば、「オブジェクトのパラメータ」とは、オブジェクトと関連付けられたパラメータである。「オブジェクトのパラメータ」は、数値パラメータであってもよいし、数値パラメータでなくてもよい。例えば、オブジェクトの総合的な能力又は性能の高低を示すパラメータ（例えば、総合能力値、レベル等）が、「オブジェクトのパラメータ」の一例に相当する。また、例えば、オブジェクトの特定の能力又は性能の高低を示すパラメータ（例えば攻撃力や守備力等）が、「オブジェクトのパラメータ」の一例に相当する。また、例えば、オブジェクトの能力又は性能を向上するために必要なパラメータ（例えば経験値等）が、「オブジェクトのパラメータ」の一例に相当する。また、例えば、オブジェクトの状態の良し悪しを示すパラメータ（例えば疲労度、やる気等）が、「オブジェクトのパラメータ」の一例に相当する。また、例えば、オブジェクトの希少性を示す希少度が、「オブジェクトのパラメータ」の一例に相当する。また、例えば、オブジェクトが有する特殊能力の情報が、「オブジェクトのパラメータ」の一例に相当する。また、例えば、オブジェクトの体形情報（身長、体重、足の長さ、手の大きさ等）、性別情報等を「オブジェクトのパラメータ」に含めてもよい。

また、前記「パラメータを変更する」とは、オブジェクトに設定されているパラメータを変化させることである。例えば、オブジェクトに設定されているパラメータを向上させること又は低下させることが「パラメータを変更する」の一例に相当する。

また、前記「パラメータを設定する」とは、例えば、オブジェクトにまだ設定されていないパラメータを当該オブジェクトに設定することである。例えば、オブジェクトが有していなかった特殊能力を当該オブジェクトに追加する（例えば、オブジェクトに特殊能力の情報を関連付ける）ことが、「パラメータを設定する」の一例に相当する。

前述の野球ゲームの例では、第１使用対象としての育成選手オーダーを構成する第１オブジェクトは、パラメータを変更又は設定することによって育成された育成選手（育成オブジェクトの一例）とユーザＩＤとが関連付けられたもの（すなわち、ユーザが所持する育成選手）である。

また、前記第２使用対象を構成する前記第２オブジェクトは、複数の第２オブジェクトの中から抽選により決定された少なくとも１つの第２オブジェクトとユーザ識別情報とが関連付けられたものとしてもよい。

前述の野球ゲームの例では、第２使用対象としてのイベキャラオーダーを構成する第２オブジェクトは、ゲーム内で管理されている複数のイベントキャラクタの中から抽選により決定された少なくとも１つのイベントキャラクタとユーザＩＤとが関連付けられたもの（すなわち、ユーザが所持するイベントキャラクタ）である。

上記の構成によれば、育成選手オーダーとイベキャラオーダーという種類の異なる２つの使用対象をそれぞれゲーム条件に対応させて登録できる。ここで、ゲームの習熟度（やり込み度）の高いユーザほどパラメータの高い育成選手を育成できる傾向にあり、ゲームを始めたばかりのユーザでは、比較的能力の低い育成選手からなる育成選手オーダーしか作れない。そうなると、育成選手オーダーを使用した育成選手リーグでは、ゲーム習熟度の高いユーザがあまりに強いため、当該リーグに参加するユーザが少なくなることが予想される。一方、抽選により入手できるイベントキャラクタは、ユーザのゲーム習熟度によらず誰でも比較的パラメータの高いものを入手できる可能性がある。よって、ゲームを始めたばかりのユーザでも、ある程度の強さのイベキャラオーダーを作り上げることも可能である。このように、種類の異なる育成選手オーダーとイベキャラオーダーとをそれぞれ異なるゲーム条件に対応させて登録できるようにすることにより、ゲーム習熟度によらず様々なユーザがゲームに参加し易くなり、マッチングの機会も増加する。

また、ユーザ識別情報と関連付けられている前記第２オブジェクトは、前記第１オブジェクトの育成において前記第１オブジェクトのパラメータを変更又は設定するための補助のオブジェクトとして使用可能なものとしてもよい。

ここで、前記「補助のオブジェクト」とは、ゲームで用いられる他のオブジェクトのパラメータに影響を与えるために補助的に使用されるオブジェクトである。例えば、「補助のオブジェクト」は、ゲーム内においてユーザによる直接の操作の対象とならない、いわゆる「ノンプレイヤキャラクタ」であるが、操作の対象である「プレイヤキャラクタ」のパラメータに影響を与える。例えば、第１オブジェクトの育成を開始する前に、１以上の第２オブジェクトをデッキに設定すれば、育成中に第２オブジェクトに応じたイベントが発生し、当該イベントに基づいて第１オブジェクトのパラメータが変更又は設定される場合、第２オブジェクトは「補助のオブジェクト」の一例に相当する。
また、「補助のオブジェクト」は、他のオブジェクトに関連付けられて、当該他のオブジェクトのパラメータを変更又は設定するものであってもよい。例えば、第１オブジェクトにコーチやトレーナーとして関連付けられて、当該選第１オブジェクトのパラメータを向上させるキャラクタが、「補助のオブジェクト」の一例に相当する。また、例えば、第１オブジェクトに装備されて（関連付けられて）、当該選第１オブジェクトのパラメータを向上させる効果を生じる装備アイテムが、「補助のオブジェクト」の一例に相当する。

前述の野球ゲームの例では、育成モードにおいて育成選手の能力パラメータを変更または設定するためのイベントキャラクタが「補助のオブジェクト」の一例に相当する。この構成によれば、ユーザが所持するイベントキャラクタは、マッチングを伴う対戦モードだけではなく、育成選手の育成において補助のオブジェクトとしても使用される。これにより、ゲーム内のキャラクタの増大を効果的に抑制し、キャラクタ資源を有効に活用することができる。

［４．処理］
次に、本実施の形態のゲームシステム１で実行される処理の一例を以下に説明する。

図１８は、前述のリアルタイム対戦モードを実行するゲームシステム１の処理の一例を示すフローチャートである。また、図１９は、リアルタイム対戦モードを実行するゲームシステム１の処理の一例を示すシーケンスチャートである。以下に説明する処理は、記憶装置（ＲＯＭ１２、ＲＡＭ１３、補助記憶装置１４、ＲＯＭ３２、ＲＡＭ３３又は補助記憶装置３４等）に記憶されているゲームプログラムを、制御部１１０（ゲーム端末１０のＣＰＵ１１又はサーバ３０のＣＰＵ３１）が実行することにより実現される。

ここでは一例として、サーバ３０が主にマッチング処理を実行し、各ユーザのゲーム端末１０が主にマッチング処理以外を実行する例を説明する。よって、図１８に記載の処理は各ユーザのゲーム端末１０のＣＰＵ１１によって実行されるものとする。

Ｓ１００では、ＣＰＵ１１は、ユーザの操作に基づいて、育成選手オーダーを記憶装置（補助記憶装置１４、補助記憶装置３４、データベースＤＢ等）に記憶させて登録する。ユーザは、図４に例示するリアルタイム対戦モードのトップ画面Ｇ３００の育成選手オーダー編集ボタンＢ３０１をタップして図５に例示する育成選手オーダー編集画面Ｇ４００を開き、育成選手オーダーを編集して登録できる。この育成選手オーダーの登録は、マッチング要求（図１８のＳ１０６）の前であれば、いつでも可能である。

一度登録された育成選手オーダーの情報は不揮発性の記憶装置に保存されているので、それ以降のマッチングでユーザが育成選手オーダーを変更しなければ、登録されている育成選手オーダーが適用されることになる。よって、ユーザは、必ずしもマッチングの度に育成選手オーダーを編集する必要はない。例えば、ユーザは、育成モードで能力の高い育成選手が育成できた場合に、育成選手オーダーを編集すればよい。

Ｓ１０２では、ＣＰＵ１１は、ユーザの操作に基づいて、イベキャラオーダーを記憶装置（補助記憶装置１４、補助記憶装置３４、データベースＤＢ等）に記憶させて登録する。ユーザは、図４のトップ画面Ｇ３００のイベキャラオーダー編集ボタンＢ３０２をタップしてイベキャラオーダー編集画面を開き、イベキャラオーダーを編集して登録できる。このイベキャラオーダーの登録も、マッチング要求（図１８のＳ１０６）の前であれば、いつでも可能である。

育成選手オーダーと同様に、一度登録されたイベキャラオーダーの情報は不揮発性の記憶装置に保存されているので、それ以降のマッチングでユーザがイベキャラオーダーを変更しなければ、登録されているイベキャラオーダーが適用される。よって、ユーザは、必ずしもマッチングの度にイベキャラオーダーを編集する必要はない。例えば、ユーザは、抽選入手モードでレアリティの高いイベントキャラクタを入手したり、強化モードでイベントキャラクタのレベルを高めたりした場合に、イベキャラオーダーを編集すればよい。

Ｓ１０４では、ＣＰＵ１１は、ユーザの操作に基づいて、マッチングの条件設定の情報を記憶装置（補助記憶装置１４、補助記憶装置３４、データベースＤＢ等）に記憶させて登録する。ユーザは、図４のトップ画面Ｇ３００の検索設定ボタンＢ３０３をタップして図６に例示する検索設定画面Ｇ５００を開き、マッチングのゲーム条件を設定して登録できる。このマッチングの条件設定も、マッチング要求（図１８のＳ１０６）の前であれば、いつでも可能である。

本実施形態のゲームでは、マッチングのゲーム条件（マッチング相手の検索条件）として、使用オーダーおよびイニング数の条件を設定できる。使用オーダーの条件に関し、対戦で使用するオーダーについては育成選手オーダーとイベキャラオーダーとの何れでもよいとする「おまかせ」の選択肢Ｐ５１１を選択した条件設定が可能である（図６参照）。また、育成選手オーダーとイベキャラオーダーの何れか一方のみを使用オーダーとして指定した条件設定も可能である。

なお、一度登録されたマッチングの条件設定の情報は不揮発性の記憶装置に保存されているので、それ以降のマッチングでユーザが条件設定を変更しなければ、登録されている条件設定が適用されるようにしてもよい。この場合、ユーザは、必ずしもマッチングの度にマッチングの条件設定を行う必要がなく、必要に応じてユーザが条件設定を変更するようにしてもよい。あるいは、マッチングの都度、基本的にデフォルトの条件設定（例えば、使用オーダー「おまかせ」、イニング数「おまかせ」）が適用され、マッチング要求前に必要に応じてユーザが条件設定を変更するようにしてもよい。

なお、前記Ｓ１００、Ｓ１０２、Ｓ１０４の処理順はこれに限定されるものではなく、何れの処理を先に実行してもよい。

Ｓ１０６では、ＣＰＵ１１は、前記マッチングの条件設定を伴うマッチング要求をサーバ３０へ送信する。ユーザは、図４のトップ画面Ｇ３００のマッチングボタンＢ３０４をタップすることにより、前記マッチングの条件設定を伴うマッチング要求を行うことができる。ゲーム端末１０からサーバ３０へ送信されるマッチング要求のデータには、前記条件設定の情報およびユーザＩＤが含まれている。また、マッチング要求に前述の通信強度の情報等を含めてもよい。

ゲーム端末１０では、マッチング要求をサーバ３０へ送信した後は、マッチングが成立するまで待機状態になる。

ここで、図１９のシーケンスチャートを併せて用いて説明する。この図１９は、ユーザＩＤ：Ｕ１のユーザのゲーム端末１０－１と、ユーザＩＤ：Ｕ２のユーザのゲーム端末１０－２との間で、マッチングが行われる場合の処理の一例を示している。

以下では、ユーザＩＤ：Ｕ１のユーザを「ユーザＡ」、ユーザＩＤ：Ｕ２のユーザを「ユーザＢ」と称する。また、ユーザＡは使用オーダー「おまかせ」の条件設定を行ったものとし、ユーザＢは育成選手オーダーまたはイベキャラオーダーの何れか１つを指定した条件設定を行ったものとする。

ユーザＡのゲーム端末１０－１及びユーザＢのゲーム端末１０－２において、それぞれ上述の条件設定を伴うマッチング要求がサーバ３０へ送信される（Ｓ２００－１及びＳ２００－２）。サーバ３０は、ゲーム端末１０－１、１０－２を含む複数のゲーム端末１０－ｎからのマッチング要求を受け付けて、マッチング処理を実行する（Ｓ３００）。このマッチング処理により、ユーザＡのゲーム端末１０－１とユーザＢのゲーム端末１０－２とのマッチングが成立したものとする。この場合、サーバ３０は、ユーザＡのゲーム端末１０－１及びユーザＢのゲーム端末１０－２に対して、対戦相手の情報（対戦相手のユーザＩＤ等）およびマッチングが成立したゲーム条件（使用オーダー、イニング数）の情報を含むマッチング情報を送信する（Ｓ３０２－１及びＳ３０２－２）。

図１８に戻って説明を続けると、ユーザＡおよびユーザＢのゲーム端末１０のＣＰＵ１１は、サーバ３０から前記マッチング情報を受信してマッチングが成立した場合（Ｓ１０８でＹＥＳ）、マッチングが成立したゲーム条件に対応するチームオーダー（事前に登録されている育成選手オーダーまたはイベキャラオーダー）を適用する（Ｓ１１０）。これにより、例えば、ゲーム端末１０の表示部１７には図７の対戦前確認画面Ｇ６００が表示され、各ユーザＡ、Ｂは、対戦相手の情報（対戦相手のユーザ名、リーダーキャラクタの画像、通信強度の情報等）やマッチングが成立したゲーム条件を確認する。ここで、ユーザＡは使用オーダー「おまかせ」の条件設定を行っていたので、マッチング成立後に、登録している２つの使用オーダーのどちらを使うことになったかを確認できる。本実施の形態では、マッチングされたユーザＡおよびユーザＢの何れもが制限時間以内に試合開始ボタンＢ６３２を操作することにより対戦が開始される（Ｓ１１２）。

図１９において、対戦ゲームは、例えば、ゲーム端末１０－１とゲーム端末１０－２との間でＰ２Ｐ接続等による直接通信で実行することができる（Ｓ２０２）。なお、対戦ゲームはサーバ３０経由で実行されてもよい。対戦ゲーム中は、ユーザＡ及びユーザＢが、それぞれマッチングが成立したゲーム条件に対応するチームオーダーの選手キャラクタを操作することによりゲームが進行する。

その後、ユーザＡ及びユーザＢによる対戦ゲームが終了すると（図１８のＳ１１４でＹＥＳ）、両ゲーム端末１０のＣＰＵ１１は、対戦の終了処理を実行する（Ｓ１１６）。すなわち、図１９に示すように、ゲーム端末１０－１及びゲーム端末１０－２は、対戦ゲームの結果をサーバ３０に対して送信する（Ｓ２０４－１及びＳ２０４－２）。なお、対戦ゲームがサーバ３０経由で実行された場合は、Ｓ２０４－１及びＳ２０４－２を省略できる。

その後、サーバ３０は、対戦ゲームの結果に応じて、ユーザＡ及びユーザＢにポイントやアイテム等の報酬を付与するための情報を、ゲーム端末１０－１及びゲーム端末１０－２に送信する（Ｓ３０４－１及びＳ３０４－２）。これにより、ゲーム端末１０－１及びゲーム端末１０－２の表示部１７には、対戦結果および報酬の情報が表示される。

［５．まとめ］
以上に説明した実施形態に係るゲームシステム１では、複数のゲーム条件のそれぞれに対応する複数のチームオーダーやデッキを予め登録しておくことができる。そして、複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を伴うマッチング要求を行うことにより、マッチングが成立したゲーム条件に対応するチームオーダーやデッキを使用したゲームを実行できる。これにより、２以上の何れのゲーム条件でもよいのでゲームをプレイしたいというユーザはマッチングの機会が増えるとともに、マッチングされ難かったゲーム条件においてもマッチングの機会を増やすことができる。本構成により、ゲーム条件によるチームオーダーやデッキの使い分けを可能としながら、全体のマッチングの機会を増やし、特にマッチングされ難かったゲーム条件においてもマッチングの機会を増やすことができ、ゲームの興趣性の向上が図れる。

［６．変形例］
本発明は以上に説明した実施形態に限定されるものではない。

［６－１］以上では、所定数の育成選手（第１オブジェクトの一例）から構成される育成選手オーダー（第１使用対象の一例）、および所定数のイベントキャラクタ（第２オブジェクトの一例）から構成されるイベキャラオーダー（第２使用対象の一例）を事前に登録しておく例を示したが、少なくとも１つの育成選手および少なくとも１つのイベントキャラクタを含む混成オーダー（第３使用対象の一例）を事前に登録できるようにしてもよい。そして、混成オーダーについても、育成選手オーダーやイベキャラオーダーと同様に、マッチングのゲーム条件の少なくとも一部と対応付けるようにしてもよい。また、使用オーダーのゲーム条件について、育成選手オーダー、イベキャラオーダー、混成オーダーの何れでもよい（または当該３つのオーダーのうちの任意の２つの何れでもよい）という「おまかせ」の条件設定を可能とし、マッチングが成立したゲーム条件に対応するオーダーを使用した対戦ゲームが実行されるようにしてもよい。

［６－２］以上では、育成選手およびイベントキャラクタという種類の異なる２つのオブジェクトを用いたゲームの例を示したが、３種類以上のオブジェクトを用いるゲームにも適用できる。すなわち、３種類以上のオブジェクトをそれぞれ含む複数の使用対象（オーダー、デッキ等）を事前に登録できるようにして、複数の使用対象のそれぞれをマッチングのゲーム条件の少なくとも一部と対応付けるようにしてもよい。一例としては、育成により取得できるオブジェクト（例えば育成選手）、抽選により取得できるオブジェクト（例えばイベントキャラクタ）、ゲーム内で開催される大会イベント等において全ユーザに共通で付与されるオブジェクト（例えば期間限定の共通オブジェクト）という取得方法が異なる３種類のオブジェクトを用いたゲームに適用できる。

［６－３］以上では、ユーザが所持する（すなわちユーザのユーザ識別情報とが関連付けられた）オブジェクト（育成選手、ベントキャラクタ等）から構成される使用対象（チームオーダー、デッキ等）を用いる例を示したが、使用対象に含まれるオブジェクトの一部にユーザが所持していないオブジェクトを含めてもよい。例えば、ユーザに関連付けられた他ユーザ（すなわち、ユーザのユーザ識別情報にユーザ識別情報が関連付けられた他ユーザであり、フレンド、仲間等と称されるもの）が所持するオブジェクトを、ユーザの使用対象としてのチームオーダー等に含めることができるようにしてもよい。

［６－４］以上では、育成選手オーダーを構成する育成選手の選択に制限を設けていないが、次のような制限を設けてもよい。例えば、育成選手の能力の高さに応じてコスト（査定値）を設定し、育成選手オーダーを構成する複数の育成選手の合計コストがチームコスト最大値以下になるようにしなければならないとする制限を設けてもよい。この場合、能力の高い育成選手を育成すれば育成選手オーダーを強化できるが、各育成選手のコストパフォーマンスもある程度重要になる。単純に能力の高い育成選手ばかりのオーダーを組むのではなく、チームコスト最大値を考慮したオーダーの編集が要求される。
同様にイベントキャラクタの能力の高さに応じてコスト（査定値）を設定し、イベキャラオーダーを構成する複数のイベントキャラクタの合計コストがチームコスト最大値以下になるようにしなければならないとする制限を設けてもよい。

［６－５］以上では、育成選手オーダーおよびイベキャラオーダーの編集（登録）は、マッチング要求を送信する前であればいつでも可能である例を示したが、対戦が開始される前までオーダーの編集を可能としてもよい。例えば、マッチングの成立後であって対戦が開始される前に、マッチングされた各ユーザにオーダー編集が可能な所定期間を設けてもよい。

［６－６］以上では、マッチング成立後に、図７に例示する対戦前確認画面Ｇ６００を表示して、マッチングされた両ユーザが試合開始ボタンＢ６３２を操作しなければ対戦が開始されない例を説明したが、これに限定されない。例えば、マッチング成立後は試合開始ボタンＢ６３２を操作せずとも自動的に対戦が開始される（すなわち、マッチング成立後は対戦開始前にユーザの意思でマッチングをキャンセルできない）ようにしてもよい。

［６－７］前述の「育成に適用したシナリオ」の違いをマッチングの「ゲーム条件」として設定できるようにする場合、次のような構成にすることができる。例えば、育成に適用したシナリオＡに関連付けられた「育成チーム」（すなわち、シナリオＡの実行により育成された「育成チーム」）が複数ある場合、その中から任意の１つの「育成チーム」を使用対象としてユーザが指定して登録できるようにする。同様に、シナリオＢ、Ｃ、…に関連付けられた「育成チーム」についても、シナリオごとに１つの「育成チーム」を使用対象としてユーザが指定して登録できるようにする。そして、育成に適用した各シナリオを「ゲーム条件」として、２以上のシナリオの何れでもよいとする「おまかせ」のマッチングの条件設定を可能とし、マッチングが成立したゲーム条件のシナリオに対応する「育成チーム」を使用した対戦ゲームが実行されるようにする。

［６－８］前述の「オブジェクトの入手時期」、「オブジェクト種別」または「ガチャの種別」の違いをマッチングの「ゲーム条件」として設定できるようにする場合、次のような構成にすることができる。
例えば、ユーザは「オブジェクトの入手時期」ごとに、少なくとも１つのオブジェクトを含む使用対象（１つだけのオブジェクト、又は複数のオブジェクトからなるチームやデッキ等）を予め登録できる。例えば「２０２１年シリーズ」に対応付けて、所定数の２０２１年シリーズのオブジェクトから構成されるデッキを登録でき、「２０２２年シリーズ」に対応付けて、所定数の２０２２年シリーズのオブジェクトから構成されるデッキを登録できる。そして、２以上の「オブジェクトの入手時期」の何れでもよいとする「おまかせ」のマッチングの条件設定を可能とし、マッチングが成立したゲーム条件に対応するデッキを使用したゲームが実行されるようにする。「オブジェクト種別」または「ガチャの種別」の違いをマッチングの「ゲーム条件」とする場合も同様である。すなわち、「オブジェクト種別」ごと、または「ガチャの種別」ごとに、少なくとも１つのオブジェクトを含む使用対象を予め登録できるようにし、これらのゲーム条件について前述の「おまかせ」のマッチングの条件設定を可能とし、マッチングが成立したゲーム条件に対応するデッキを使用したゲームが実行されるようにする。

［６－９］以上では、主に野球ゲームの例について説明したが、本発明は他のゲームにも適用できる。例えば、他のスポーツゲーム（サッカー、テニス、アメリカンフットボール、バスケットボール、アイスホッケー、バレーボール、ラグビー等を題材としたゲーム）、格闘ゲーム、戦闘ゲーム、デジタルカードゲーム、ロールプレイングゲーム、シミュレーションゲーム、アドベンチャーゲーム又は育成ゲームのように、ゲーム形式・ジャンルを問わず、「少なくとも１つのオブジェクトを含む使用対象を複数登録することができ、マッチングされたユーザ同士が使用対象を使用するゲーム」なら様々なゲームに適用できる。

［６－１０］ゲーム端末１０とサーバ３０は、互いに通信して各種データの送受が可能であり、共にＣＰＵ、ＲＯＭ、ＲＡＭ、補助記憶装置、通信部等を備えた情報処理装置（コンピュータ）であって、基本的には同様のハード構成を有する。よって、以上に説明した各種機能の一部をゲーム端末１０のＣＰＵ１１によって実現し、残りをサーバ３０のＣＰＵ３１によって実現してもよい。又は、以上に説明した各種機能のすべてをゲーム端末１０のＣＰＵ１１によって実現してもよい。あるいは、以上に説明した各種機能のすべてをサーバ３０のＣＰＵ３１によって実現してもよい。

［６－１１］各種情報を記憶装置に記憶する記憶制御機能を有する構成に関し、記憶装置そのものについては当該構成に含まれないので、ゲームシステム１の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームシステム１内の記憶装置（例えば、ＲＡＭ１３、補助記憶装置１４、ＲＡＭ３３、補助記憶装置３４、データベースＤＢ等）、あるいはこれらとは別構成のファイルサーバ（オンラインストレージ）等であってもよい。

［６－１２］本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームシステム１又はゲーム制御装置を構成するコンピュータのＣＰＵにより実行される。また、プログラムをコンピュータに提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。

［７．付記］
以上の記載から本発明は例えば以下のように把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。

１）本発明の一態様に係るゲームシステム（１）は、ユーザの操作に基づいて、少なくとも１つのオブジェクト（例えば育成選手、イベントキャラクタ）を含む使用対象（例えば育成選手オーダー、イベキャラオーダー）を複数登録する登録手段（１１１）と、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件（例えばイベキャラオーダーを使用するという条件、育成選手オーダーを使用するという条件）、のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段（１１２）と、前記条件設定を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングするマッチング手段（１１３）と、前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段（１１４）と、を含む。

９）本発明の一態様に係るゲーム制御装置（１０又は３０）は、ユーザの操作に基づいて、少なくとも１つのオブジェクト（例えば育成選手、イベントキャラクタ）を含む使用対象（例えば育成選手オーダー、イベキャラオーダー）を複数登録する登録手段（１１１）と、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件（例えばイベキャラオーダーを使用するという条件、育成選手オーダーを使用するという条件）、のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段（１１２）と、前記条件設定を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングするマッチング手段（１１３）と、前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段（１１４）と、を含む。

１０）本発明の一態様に係るゲーム制御装置（１０）は、ユーザの操作に基づいて、少なくとも１つのオブジェクト（例えば育成選手、イベントキャラクタ）を含む使用対象（例えば育成選手オーダー、イベキャラオーダー）を複数登録する登録手段（１１１）と、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件（例えばイベキャラオーダーを使用するという条件、育成選手オーダーを使用するという条件）、のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段（１１２）と、前記条件設定を伴うマッチング要求に基づいてマッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段（１１４）と、を含む。

１１）本発明の一態様に係るプログラムは、１）～８）のいずれかに記載のゲームシステム（１）、又は、９）若しくは１０）に記載のゲーム制御装置（１０又は３０）としてコンピュータを機能させるためのプログラムである。

１２）本発明の一態様に係る情報記憶媒体は、１１）に記載のプログラムを記録したコンピュータで読み取り可能な情報記憶媒体である。

１３）本発明の一態様に係るゲームシステム（１）又はゲーム制御装置（１０又は３０）の制御方法は、ユーザの操作に基づいて、少なくとも１つのオブジェクト（例えば育成選手、イベントキャラクタ）を含む使用対象（例えば育成選手オーダー、イベキャラオーダー）を複数登録する登録ステップ（Ｓ１００、Ｓ１０２）と、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件（例えばイベキャラオーダーを使用するという条件、育成選手オーダーを使用するという条件）、のうちの２以上の何れでもよいとする条件設定を可能とする条件設定ステップ（Ｓ１０４）と、前記条件設定を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングするマッチングステップ（Ｓ３００）と、前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行ステップ（Ｓ１１０、Ｓ１１２）と、を含む。

上記１）、９）～１３）に記載の態様によれば、複数のゲーム条件のそれぞれに対応する使用対象を予め登録しておくことができる。そして、複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を伴うマッチング要求を行うことにより、マッチングが成立したゲーム条件に対応する使用対象を使用したゲームを実行できる。これにより、２以上の何れのゲーム条件でもよいのでゲームをプレイしたいというユーザはマッチングの機会が増えるとともに、マッチングされ難かったゲーム条件においてもマッチングの機会を増やすことができる。本構成により、ゲーム条件による使用対象の使い分けを可能としながら、全体のマッチングの機会を増やし、特にマッチングされ難かったゲーム条件においてもマッチングの機会を増やすことができ、ゲームの興趣性の向上が図れる。

２）本発明の一態様では、上記１）、９）または１０）に記載の態様において、ユーザが参加可能な複数のゲーム内リーグが設定されており、前記登録手段（１１１）は、ユーザの操作に基づいて、複数の前記ゲーム内リーグにそれぞれ対応する複数の前記使用対象を登録するようにしてもよい。

上記２）に記載の態様によれば、複数のゲーム内リーグと複数の前記使用対象とがそれぞれ対応しており、例えばゲーム内リーグＡでのゲームプレイには対応する使用対象Ａが使用され、ゲーム内リーグＢでのゲームプレイには対応する使用対象Ｂが使用される。複数の使用対象は複数のゲーム条件のそれぞれにも対応しているので、「おまかせ」の条件設定でマッチングが成立し、成立したゲーム条件に対応する使用対象が使用されることにより、当該使用対象に対応するゲーム内リーグへ参加したゲームが実行される。これにより、ゲーム条件による使用対象の使い分けを可能としながら、マッチングされ難かったゲーム内リーグにおいてもマッチングの機会を増やすことができる。

３）本発明の一態様では、上記２）に記載の態様において、ユーザが参加したい前記ゲーム内リーグ、またはユーザが使用したい前記ゲーム内リーグに対応する前記使用対象を前記ゲーム条件に含み、
前記条件設定手段（１１２）は、ユーザの操作に基づいて、複数の前記ゲーム内リーグのうちの２以上の何れでもよいとする条件設定、または複数の前記ゲーム内リーグにそれぞれ対応する複数の前記使用対象のうちの２以上の何れを使用してもよいとする条件設定を可能としてもよい。

各ユーザは複数のゲーム内リーグのそれぞれに対応した使用対象を登録し、また同一のゲーム内リーグにおいてマッチングされたプレイ相手（他ユーザ）とゲームプレイをする。よって、「ユーザが参加したい前記ゲーム内リーグ」のゲーム条件は、「ユーザが使用したいゲーム内リーグに対応する使用対象」のゲーム条件と同様の意味を持つ。上記３）に記載の態様によれば、ゲーム条件による使用対象の使い分けを可能としながら、マッチングされ難かったゲーム内リーグにおいてもマッチングの機会を増やすことができる。

４）本発明の一態様では、上記１）～３）、９）、１０）の何れかに記載の態様において、前記オブジェクトには、種類の異なる第１オブジェクト（例えば育成選手）と第２オブジェクト（例えばイベントキャラクタ）とを少なくとも含み、複数の前記使用対象には、前記第１オブジェクトが登録される第１使用対象（例えば育成選手オーダー）と前記第２オブジェクトが登録される第２使用対象（例えばイベキャラオーダー）とを少なくとも含むようにしてもよい。

上記４）に記載の態様によれば、第１オブジェクトが登録される第１使用対象と、第２オブジェクトが登録される第２使用対象という種類の異なる２つをそれぞれゲーム条件に対応させて登録できる。オブジェクトの種類によっては、例えばゲームの習熟度（やり込み度）の高いユーザほどパラメータの高いオブジェクト（例えば第１オブジェクト）を獲得しやすいものもある。このような場合、ゲームを始めたばかりの初心者ユーザでは、比較的低いパラメータのオブジェクトからなる使用対象しか使用できないが、初心者ユーザでも比較的パラメータの高いものを入手できる別の種類のオブジェクト（例えば第２オブジェクト）があれば、ある程度の使用対象を使用できるようになる。この例のように、種類の異なるオブジェクトから構成される複数の使用対象を登録できるようにすることにより、使用対象のバリエーションが増えて、様々なユーザがゲームに参加し易くなり、マッチングの機会も増加する。

５）本発明の一態様では、上記４）に記載の態様において、前記第１オブジェクトは、パラメータを変更又は設定することによって育成された育成オブジェクト（例えば育成選手）とユーザ識別情報とが関連付けられたものであり、前記第２オブジェクトは、複数の第２オブジェクトの中から抽選により決定された少なくとも１つの第２オブジェクト（例えばイベントキャラクタ）とユーザ識別情報とが関連付けられたものであってもよい。

上記５）に記載の態様によれば、ユーザが育成により入手した育成オブジェクトから構成される第１使用対象と、ユーザが抽選により入手した第２オブジェクトから構成される第２使用対象という種類の異なる２つをそれぞれゲーム条件に対応させて登録できる。育成オブジェクトはゲーム習熟度の高いユーザほどパラメータを高め易い一方、抽選により入手できる第２オブジェクトは、ユーザのゲーム習熟度によらず誰でも比較的パラメータの高いものを入手できる可能性がある。このように、種類の異なる第１使用対象と第２使用対象とをそれぞれ異なるゲーム条件に対応させて登録できるようにすることにより、ゲーム習熟度によらず様々なユーザがゲームに参加し易くなり、マッチングの機会も増加する。

６）本発明の一態様では、上記５）に記載の態様において、ユーザ識別情報と関連付けられている前記第２オブジェクト（例えばイベントキャラクタ）は、前記第１オブジェクトの育成において前記第１オブジェクトのパラメータを変更又は設定するための補助のオブジェクトとして使用可能なものとしてもよい。

上記６）に記載の態様によれば、ユーザが所持する第２オブジェクトは、第１オブジェクトの育成において補助のオブジェクトとしても使用される。これにより、ゲーム内のオブジェクト資源を有効に活用することができる。

７）本発明の一態様では、上記１）ないし６）、９）、１０）の何れかに記載の態様において、前記条件設定手段（１１２）は、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数の前記ゲーム条件の何れかを指定した前記条件設定も可能としてもよい。

上記７）に記載の態様によれば、複数の使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を伴うマッチング要求だけではなく、当該複数のゲーム条件の何れか１つを指定したマッチング要求も可能である。

８）本発明の一態様では、上記１）ないし７）、９）、１０）の何れかに記載の態様において、前記条件設定手段（１１２）は、前記使用対象に対応する前記ゲーム条件（例えば育成選手オーダーを使用する条件とイベキャラオーダーを使用する条件）とは異なる他のゲーム条件（例えばイニング数に関するゲーム条件）を前記条件設定に含めることを可能としてもよい。

上記８）に記載の態様によれば、使用対象に対応するゲーム条件だけではなく、使用対象に対応しない他のゲーム条件も条件設定に含めたマッチング要求も可能である。

１…ゲームシステム、Ｎ…ネットワーク、ＤＢ…データベース、１０…ゲーム端末、１１…ＣＰＵ、１３…ＲＡＭ、１４…補助記憶装置、１７…表示部、３０…サーバ、３１…ＣＰＵ、３３…ＲＡＭ、３４…補助記憶装置、１００…データ記憶部、１１０…制御部、１１１…登録部、１１２…条件設定部、１１３…マッチング部、１１４…ゲーム実行部、ＴＢＬ１０１…ユーザ情報テーブル、ＴＢＬ１０２…キャラクタ情報テーブル、ＴＢＬ１０３…ゲーム条件テーブル、ＴＢＬ１０４…チームオーダーテーブル、ＤＴ１０５…所持キャラクタデータ、ＤＴ１０６…チームオーダーデータ

Claims (11)

1. ユーザの操作に基づいて、少なくとも１つのオブジェクトを含む使用対象を複数登録する登録手段と、
   ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段と、
   前記条件設定を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングするマッチング手段と、
   前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段と、
   を含むゲームシステム。
2. ユーザが参加可能な複数のゲーム内リーグが設定されており、
   前記登録手段は、ユーザの操作に基づいて、複数の前記ゲーム内リーグにそれぞれ対応する複数の前記使用対象を登録する
   請求項１に記載のゲームシステム。
3. ユーザが参加したい前記ゲーム内リーグ、またはユーザが使用したい前記ゲーム内リーグに対応する前記使用対象を前記ゲーム条件に含み、
   前記条件設定手段は、ユーザの操作に基づいて、複数の前記ゲーム内リーグのうちの２以上の何れでもよいとする条件設定、または複数の前記ゲーム内リーグにそれぞれ対応する複数の前記使用対象のうちの２以上の何れを使用してもよいとする条件設定を可能とする
   請求項２に記載のゲームシステム。
4. 前記オブジェクトには、種類の異なる第１オブジェクトと第２オブジェクトとを少なくとも含み、
   複数の前記使用対象には、前記第１オブジェクトが登録される第１使用対象と前記第２オブジェクトが登録される第２使用対象とを少なくとも含む
   請求項１ないし３の何れか１項に記載のゲームシステム。
5. 前記第１オブジェクトは、パラメータを変更又は設定することによって育成された育成オブジェクトとユーザ識別情報とが関連付けられたものであり、
   前記第２オブジェクトは、複数の第２オブジェクトの中から抽選により決定された少なくとも１つの第２オブジェクトとユーザ識別情報とが関連付けられたものである
   請求項４に記載のゲームシステム。
6. ユーザ識別情報と関連付けられている前記第２オブジェクトは、前記第１オブジェクトの育成において前記第１オブジェクトのパラメータを変更又は設定するための補助のオブジェクトとして使用可能なものである
   請求項５に記載のゲームシステム。
7. 前記条件設定手段は、ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数の前記ゲーム条件の何れかを指定した前記条件設定も可能とする
   請求項１ないし６の何れか１項に記載のゲームシステム。
8. 前記条件設定手段は、前記使用対象に対応する前記ゲーム条件とは異なる他のゲーム条件を前記条件設定に含めることを可能とする
   請求項１ないし７の何れか１項に記載のゲームシステム。
9. ユーザの操作に基づいて、少なくとも１つのオブジェクトを含む使用対象を複数登録する登録手段と、
   ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段と、
   前記条件設定を伴うマッチング要求に基づいて、ユーザのプレイ相手をマッチングするマッチング手段と、
   前記マッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段と、
   を含むゲーム制御装置。
10. ユーザの操作に基づいて、少なくとも１つのオブジェクトを含む使用対象を複数登録する登録手段と、
    ユーザの操作に基づいて、複数の前記使用対象にそれぞれ対応する複数のゲーム条件のうちの２以上の何れでもよいとする条件設定を可能とする条件設定手段と、
    前記条件設定を伴うマッチング要求に基づいてマッチングが成立した前記ゲーム条件に対応する前記使用対象を使用したゲームを実行するゲーム実行手段と、
    を含むゲーム制御装置。
11. 請求項１ないし８の何れか１項に記載のゲームシステムまたは請求項９若しくは１０に記載のゲーム制御装置としてコンピュータを機能させるためのプログラム。

Images