JP2013034826A - ゲームシステム及びその制御方法、プログラム - Google Patents

Abstract

【課題】交流のあるユーザと同一グループに割り当てられる確率を上昇させる、対戦リーグに係る処理負荷を軽減させる、あるいは公平な階級制度を実現する。
【解決手段】ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当て、さらに予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する。また登録されているユーザのうち、第１のユーザのユーザ端末より、第２のユーザについてのフレンド登録要求を受け付け、第１のユーザ及び第２のユーザそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤを追加することにより、第１のユーザと第２のユーザとの間にフレンド関係を構築する。
【選択図】図１

Description

本発明は、ゲームシステム及びその制御方法、プログラムに関し、特にゲーム上でのカードを用いたユーザ同士の対戦を実現するゲームシステム及びその制御方法、プログラムに関する。

例えば、野球やサッカー等の対戦型ゲームの中には、勝ち抜き戦や総当たり戦等、オンライン上で多人数参加型の大会（リーグ戦）を開催するものがある。

このような対戦型ゲームでは、例えばリーグ戦を行う期間の単位であるシーズンを複数設けて、１シーズンごとにユーザの勝敗成績に応じて順位付けを行うことでユーザの向上意識を高め、長期的な利用を促す工夫がなされている。

また対戦型ゲームの中には、ユーザがより飽きにくいゲームシステムとするために、例えばリーグ戦の成績によって昇格・降格を行う階級制度を導入しているものもある。このようなシステムでは、ユーザがより上位の階級を目指して継続的かつ積極的にリーグ戦へ参加することが望まれる。また階級制度を導入したゲームシステムでは、ユーザは自身と同じレベルの戦力や熟練度を有するユーザを選んで対戦することができるため、新規ユーザが参加しやすく、ユーザ数の増加が見込まれる。

特許文献１には、対戦の終了後にユーザによりなされた対戦相手の評価を集計することよって各ユーザの操作スキルを評価し、同レベルの操作スキルを有するユーザ同士が対戦相手となるように、ユーザ同士の対戦を制御するゲームシステムが開示されている。

特開２００６−１４９４２５号公報

対戦型ゲームにおいて管理するユーザ数が増加した場合、１回のリーグ戦の開催期間が長期化してしまい、ユーザがゲームに飽きてしまう可能性がある。このため、リーグ戦の参加ユーザを、シーズンごとにランダムに複数のグループのいずれかに割り当て、対戦成績の順位付けをグループで完結させることで、１回のリーグ戦の開催期間を短縮することが好ましい。

オンラインの対戦型ゲームでは、特許文献１のように、システムによってランダムに決定された見ず知らずのユーザと対戦を行うよりも、学校の友人や家族等、現実世界の知人であるユーザと対戦を行う方が、現実世界での友好関係の向上も見込まれるため好まれる。しかしながら、参加ユーザのグループ分けがランダムに行われる場合、必ずしも知人のユーザと同一のグループに振り分けされないため、ユーザの興趣をそいでしまう可能性があった。例えば、仲間内でリーグ戦の順位を競うことをユーザが所望したとしても、仲間内の各ユーザが別々のグループに割り当てられた場合は、グループごとの成績による相対的な順位での評価しかできないため、ユーザのリーグ戦への参加意欲を減退させてしまう可能性があった。オンラインゲームにおいてユーザ同士の交流関係を増進することは、より長期的な利用ユーザを増加させることにもつながるため、ユーザ間の交流を阻害しないグループ分けが考慮されることが望ましい。

一方で、運営開始当初の参加ユーザの絶対数が少ない場合や、参加ユーザ数がグループ分けにおいて端数が生じうる場合等、１グループの参加ユーザ数が予め設定された定員に満たない場合は、ＮＰＣ（Non Player Character）と呼ばれる仮想ユーザを参加させることにより、定員のユーザでリーグ戦を行うことができる。

対戦型ゲームの場合、少なくとも一方にユーザが参加する対戦では、戦況を如何に魅力的に提示するかが重要であるため、詳細な戦況を生成する処理が実行される必要があるが、ＮＰＣ同士の対戦については、大抵のユーザにとって当該対戦の戦況は興味のない情報であるため、詳細な戦況を生成する処理は省略することができる。

しかしながら、上述したようにリーグ戦のグループ分けがランダムに行われる場合、例えばリーグ戦の全てのグループにおいてユーザとＮＰＣとが存在するように振り分けされる可能性がある。この場合、戦況の生成処理が省略不可能なユーザ同士あるいはユーザ対ＮＰＣの対戦数が増加するため、対戦を管理するサーバの処理を軽減することができなかった。

また、階級制度を導入した対戦ゲームにおいて、ゲームバランスのために各階級の上限ユーザ数を制限する場合、リーグ戦に長期間参加していないユーザが階級に参加対象として含まれてしまい、後からゲームを始めたユーザがリーグ戦に参加したとしても、人数制限によって昇格ができなくなってしまうことがあった。

本発明は、上述の問題点の少なくともいずれかを解決することを目的とする。

前述の目的の１つを達成するために、本発明の１つの態様のゲームシステムは、以下の構成を備える。

登録されているユーザが参加するリーグ戦であって、登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録手段と、登録されているユーザの各々について、ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、１以上のグループを生成するグループ生成手段と、登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、１以上のグループに分類する分類手段と、を有し、登録されているユーザは、ユーザ端末より登録要求を受け付けてユーザ管理データベースに登録された実ユーザと、登録要求を受けずにゲームシステムが生成してユーザ管理データベースに登録した仮想ユーザとで構成され、分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加することを特徴とする。

このような構成により本発明によれば、対戦リーグに係る処理負荷を軽減させることが可能となる。

本発明の実施形態に係るオンライン対戦カードゲームにおいてユーザ端末の表示装置に表示される対戦画面例を示す図 本発明の実施形態に係るゲームシステムのシステム構成を示した図 本発明の実施形態に係るゲームサーバ２０１の機能構成を示した図 本発明の実施形態に係るオンライン対戦カードゲームにおいて、提供されるゲームの種類を説明するための図 本発明の実施形態に係るオンライン対戦カードゲームにおいて、公式リーグ及び各階級について定められている情報を示した図 本発明の実施形態に係るオンライン対戦カードゲームにおいて、公式リーグにユーザが参加している場合のユーザ端末の表示装置に表示される画面構成例を示す図 本発明の実施形態に係る公式リーググループ決定処理のフローチャート 本発明の実施形態に係るユーザ同士のフレンド登録を説明するための図 本発明の実施形態に係るグループ分類処理のフローチャート 本発明の実施形態２に係るエラー回避処理のフローチャート 本発明の実施形態３に係る長期未ログインユーザ排除処理のフローチャート 本発明の実施形態３に係るオンライン対戦カードゲームにおいて、公式リーグにおける階級変更を通知する際に、ユーザ端末の表示装置に表示される通知画面例を示す図 本発明の実施形態４に係る参加対象決定処理のフローチャート 本発明の実施形態に係るデータ構造を示した図

［実施形態１］
＜ゲーム概要＞
本発明の１つの実施形態に係るゲームシステムは、各ユーザが予め登録した、複数のカードからなるデッキを用いたユーザ同士の対戦を実現する、シミュレーション型のオンライン対戦カードゲームを実行する。

図１は、ユーザ同士が対戦する際の、各ユーザが所有する表示装置に表示される、対戦画面の画面構成を示している。対戦画面１００は、対戦相手のユーザの手持ちカードが表示される相手エリア１０１、自身の手持ちカードが表示される自エリア１０２、及び各ユーザのカードが並べられ、カード毎に設定されたパラメータに応じて、カードに描かれたキャラクタ同士が戦闘を行う戦闘エリア１０３から構成される。

相手エリア１０１及び自エリア１０２にはそれぞれ、ユーザの分身となるアバター１０４、対戦に使用するデッキを構成するカードがランダムに設定された順序で積み上げられたカード山１０５、戦闘エリア１０３に配置するカードの待機エリア１０６、使用不可能になったカードが配置される廃棄エリア１０７、アバター１０４の体力ゲージ等を含むゲージ１０８が含まれる。

ユーザ同士の対戦は、各ユーザが自身のエリアのカード山１０５からカードを１枚ずつ取得するターン制で行われる。カード山１０５から取得されたカードは、待機エリア１０６に置かれた後、所定数のターンが経過後に戦闘エリア１０３に移動され、当該カードに描かれたキャラクタが戦闘可能な状態になる。なお、カード山１０５に積み上げられたカードは、次に取得されるカードがわからないよう、例えば裏返された状態で表示される。また、各カードには描かれたキャラクタに応じた待機時間（ターン数）が設定されており、待機エリア１０６に置かれてからカードに応じた待機時間の経過後に、当該カードは戦闘エリア１０３に移動される。

カードが戦闘エリア１０３に移動されると、同じく戦闘エリア１０３に置かれている相手ユーザのカードとの間で、描かれているキャラクタ同士の戦闘イベントが実行される。当該キャラクタ同士の戦闘イベントの結果、体力がなくなったキャラクタのカードは、使用不可能な状態となり、廃棄エリア１０７に移動される。なお、戦闘エリア１０３に相手ユーザのカードが置かれていない場合は、戦闘エリア１０３に移動したカードに描かれたキャラクタの攻撃対象は、相手ユーザのアバター１０４となる。

このように、ユーザ同士が戦闘エリア１０３にカードを出し合うことにより対戦は進行し、デッキのカードが全て廃棄エリア１０７に移動された、あるいはアバター１０４の体力ゲージが０になったユーザが当該対戦の敗者となる。

＜システム構成＞
上述のようなユーザ同士のオンライン対戦カードゲームのゲームプログラムを実行するゲームシステムのシステム構成について説明する。図２は、本実施形態のゲームシステムの例示的な構成を示している。

本実施形態のゲームシステムでは、各ユーザが使用する例えばＰＣ等のユーザ端末２０２ａあるいはｂは、ネットワーク２０３を介してゲームサーバ２０１に接続する。各ユーザは、ユーザ端末２０２上において、例えばインターネットブラウザを起動し、ゲームサーバ２０１が提供するＵＲＬにアクセスしてゲームサーバ２０１にログイン処理を行うことにより、上述したオンライン対戦カードゲームのサービスを利用することができる。

ゲームサーバ２０１は、オンライン対戦カードゲームに登録しているユーザの管理、及びオンライン対戦カードゲームに係るゲームプログラムの実行を行う。ゲームサーバ２０１はゲームプログラムに従って、ユーザ端末２０２で実行されているブラウザにおいて所定の表示を行うようにネットワーク２０３を介して情報を出力する。ゲームサーバ２０１においてゲームプログラムを実行することにより、ユーザ端末２０２を使用する各ユーザのデッキ編成、及びユーザ同士の対戦を実現する。なお、ユーザ端末２０２の各々は、例えば表示装置及びポインティングデバイスを有するＰＣであってよい。

（ゲームサーバ２０１の機能構成）
ここで、ゲームサーバ２０１の機能構成について図３を用いて詳細に説明する。

ＣＰＵ３０１は、ゲームサーバ２０１が備える各ブロックの動作を制御する。具体的にはＣＰＵ３０１は、例えばＲＯＭ３０２に記憶されている本実施形態のオンライン対戦カードゲームのゲームプログラムを読み出し、ＲＡＭ３０３に展開して実行することにより、各ブロックの動作を制御する。

ＲＯＭ３０２は、不揮発性メモリであり、本実施形態のオンライン対戦カードゲームのゲームプログラムに加えて、例えば各ブロックの動作及びゲームプログラム上で用いる動作パラメータを記憶する。

ＲＡＭ３０３は、揮発性メモリであり、ゲームプログラムの展開領域としてだけでなく、例えば各ブロックの動作において出力された中間データの一時的な記憶領域としても用いられる。

ネットワークＩ／Ｆ３０６は、ゲームサーバ２０１をネットワーク２０３に接続するためのインタフェースであり、所定のプロトコルに準拠した通信接続を実現する。ゲームサーバ２０１は、ネットワークＩ／Ｆ３０６を介してネットワーク２０３に接続されることにより、同じくネットワーク２０３に接続されているユーザ端末２０２からのログイン要求を受信する。またゲームサーバ２０１は、当該ゲームサーバ２０１にログインしたユーザ端末２０２との間で、ネットワークＩ／Ｆ３０６を介して情報の送受信を行う。

例えば１人のユーザが使用するユーザ端末２０２に対してゲームサーバ２０１からの情報送信を行う場合は、まず当該ユーザがゲームサーバ２０１にログインした際に、使用しているユーザ端末２０２を特定するアドレス情報をＣＰＵ３０１が当該ユーザのユーザＩＤ（各ユーザ固有の識別情報）に関連付けて、後述するユーザ管理データベース３０４に記憶する。ＣＰＵ３０１は、ゲームプログラムの実行において当該ユーザＩＤについて生成した情報を、当該ユーザＩＤに関連付けられたアドレス情報で定義された通信経路を用いてユーザ端末２０２に送信する。

ユーザ管理データベース３０４は、上述したように、ゲームサーバ２０１にログインする全てのユーザについて、各ユーザに固有のユーザＩＤを割り当てて管理する。ユーザ管理データベース３０４において管理される情報（ユーザデータ）は、ユーザＩＤに限らず、例えば図１４（ａ）に示すように、各ユーザの階級を示す階級ＩＤ１４０２、各ユーザが所有するカードの情報１４０５及び作成したデッキの情報１４０６等のユーザ情報を含む。当該ユーザ情報は、それぞれのユーザＩＤに関連付けられて管理される。

なお、ユーザ管理データベース３０４への新規ユーザの登録は、ユーザ端末２０２からのネットワーク２０３を介した登録要求がネットワークＩ／Ｆ３０６において受信された場合に、ＣＰＵ３０１が行う。ＣＰＵ３０１は、ネットワークＩ／Ｆ３０６において受信された登録要求に含まれる情報を取得し、当該登録要求を行なったユーザに対して固有のユーザＩＤを割り当てるとともに、例えばユーザ名１４０３や接続端末アドレス情報１４０４等の取得した情報を当該ユーザＩＤに関連付けて記憶する。なお、ユーザＩＤは、ユーザ管理データベース３０４への登録順の情報を含むようにＣＰＵ３０１が所定の規則に従って生成してもよいし、ユーザにより指定された文字列の情報を用いてもよい。ユーザにより指定された文字列の情報を用いる場合は、ユーザＩＤにはさらに、ユーザ管理データベース３０４の内部ＩＤとして登録順を示すＩＤが割り当てられるものとする。

カードデータベース３０５は、本実施形態のオンライン対戦カードゲームにおいて使用する全種類のカードの情報を管理する。カードは、各々異なるカードＩＤが割り当てられたカードデータとして管理される。例えば図１４（ｄ）に示すように、カードデータには、カードに描かれているキャラクタのキャラクタ名１４４１や、ゲーム上での当該キャラクタの攻撃力や防御力等のパラメータ１４４２の情報が含まれる。パラメータ１４４２は、それぞれのカードのカードＩＤ１４４０に関連付けられている。なお、上述した各ユーザの所有するカードの情報１４０５は、例えば全種類のカードＩＤに対して所有するか否かの論理型の情報、及び所有する枚数を示す情報等であり、ユーザＩＤに関連付けてユーザ管理データベース３０４に記憶される。

また本実施形態のオンライン対戦カードゲームでは、ユーザは後述するゲームの種類ごとに、１以上のカードで構成される「デッキ」を編成することができる。デッキの情報１４０６は、ユーザＩＤに関連付けられてユーザ管理データベース３０４に管理される。ゲームの１つの種類について編成するデッキの情報は、当該ゲームの種類を示すゲームＩＤ、ユーザが管理するデッキを識別するデッキＩＤ、及びデッキを構成する１以上のカードのカードＩＤ等を有する。

グラフィックデータベース３０７は、本実施形態のオンライン対戦カードゲームにおいて、ユーザ端末２０２の表示装置に表示するグラフィカルユーザインタフェース（ＧＵＩ）を生成するデータ群を記憶する。ＣＰＵ３０１は、ユーザ端末２０２におけるユーザ入力、及びゲームの進行に応じたＧＵＩを生成するデータ群をグラフィックデータベース３０７より読み出し、ネットワークＩ／Ｆ３０６からネットワーク２０３を介して各ユーザのユーザ端末２０２に送信する。

グループデータベース３０８は、本実施形態のオンライン対戦カードゲームにおいて、後述する公式リーグにおけるユーザ振り分け単位である「グループ」ごとに作られたグループテーブルを管理する。グループテーブルには、グループに振り分けされたユーザのユーザＩＤが追加される。各グループテーブルは、例えば図１４（ｃ）のように、固有のグループＩＤ１４３０が割り当てられて管理される。本実施形態のオンライン対戦カードゲームでは、公式リーグに参加するユーザを、付与さえている後述の階級が同一であるユーザでグループが構成されるように振り分ける。このため各グループテーブルには、階級ＩＤ１４３１が含まれ、当該階級ＩＤと同一の階級ＩＤが付与されたユーザの情報（１４３２、１４３３）が含まれる。

このように構成された本実施形態のゲームシステムにおいて、ユーザに提供されるゲーム及びその処理について、以下に説明する。

＜ゲーム種類＞
ユーザがゲームサーバ２０１にログインすると、図４に示すようなメニュータブを有する画面がユーザ端末２０２の表示装置に表示される。メニュータブ４０１ａ乃至ｄに示されるように、本実施形態のオンライン対戦カードゲームでは、ユーザに対し、「フリーバトル」（４０１ａ）、「オリジナルリーグ」（４０１ｂ）、「公式リーグ」（４０１ｃ）、「迎撃戦」（４０１ｄ）の４つのゲームを提供する。

提供されるゲームは、それぞれ以下のような特徴を有する。
・フリーバトル ：ユーザが、現在ログインしている他のユーザの中から対戦ユーザを
任意に選択し、当該対戦ユーザが予めフリーバトル用に設定したデ
ッキと対戦を行う（なお、フリーバトルに限りデッキ構築の手間を
省くためにもオリジナルリーグ用又は公式リーグ用に設定したデッ
キで代用するようにしても良い）。
・オリジナルリーグ：１人のユーザがホストとなり、ホストが設定したレギュレーション
で複数のユーザの参加を募って開催するリーグ戦。
・公式リーグ ：ゲームシステム上で開催される、ユーザの戦績によって順位付けを
行う、公式リーグ用のデッキを編成済みの全ユーザが参加となるリ
ーグ戦。リーグ戦の会期が長期化しないよう、全ユーザは１以上の
グループに振り分けされて対戦を行う。
・迎撃戦 ：他のユーザにフリーバトルの対戦ユーザとして選択された際の対戦
の内容及び結果の表示を行う。

なお、本実施形態においては「リーグ戦」とは、リーグ戦内の１グループに参加しているユーザ同士の総当たり戦を行うものとして説明するが、例えばトーナメント戦や、予め定められた会期内で実行可能な所定数の対戦を行うものであってもよい。

＜公式リーグ詳細＞
ここで、本発明に係る公式リーグの詳細について、以下に説明する。なお、以下の説明では便宜上、以下の定数を用いて説明する。各定数を示す情報は、ＲＯＭ３０２あるいはＲＡＭ３０３に記憶されているものとする。

・参加上限数Ｕmaxt ：公式リーグに参加可能なユーザ数
・上限ユーザ数Ｕcmax ：公式リーグの各階級について設定されたユーザの上限数
・グループ総数Ｇmax ：公式リーグの各階級について設定されたグループ数
・階級実ユーザ数Ｕruser ：公式リーグの各階級について、当該階級が付与されてい
る実ユーザの数
・昇格順位Ｒup ：公式リーグの各階級について設定された１つのグループ
から１つ上位の階級に昇格するユーザ順位の条件
・降格順位Ｒdown ：公式リーグの各階級について設定された１つのグループ
から１つ下位の階級に降格するユーザ順位の条件
・昇格人数Ｕup ：公式リーグの各階級について設定された１つのグループ
から１つ上位の階級に昇格するユーザの数
・残留人数Ｕstay ：公式リーグの各階級について設定された１つのグループ
から同一の階級に残留するユーザの数
・降格人数Ｕdown ：公式リーグの各階級について設定された１つのグループ
から１つ下位の階級に降格するユーザの数
・非降格人数Ｕndown ：公式リーグの各階級について設定された１つのグループ
から１つ下位の階級に降格しないユーザの数
（昇格人数Ｕup＋残留人数Ｕstay）
・昇格総人数Ｕupt ：公式リーグの各階級から１つ上位の階級に昇格するユー
ザの総数
・残留総人数Ｕstayt ：公式リーグの各階級に残留するユーザの総数
・降格総人数Ｕdownt ：公式リーグの各階級から１つ下位の階級に降格するユー
ザの総数
・非降格総人数Ｕndownt ：公式リーグの各階級から１つ下位の階級に降格しないユ
ーザの総数（昇格総人数Ｕupt＋残留総人数Ｕstayt）
・振り分けグループ数Ｇruser ：公式リーグの各階級について、実ユーザが振り分けされ
るグループの数

上述したように公式リーグは、基本的には公式リーグ用のデッキを編成済みの全ユーザが参加対象者となる。例えば１人のユーザが公式リーグ用のデッキを編成済みであるか否かは、ＣＰＵ３０１が、ユーザ管理データベース３０４に記憶されている当該ユーザのユーザＩＤを有するユーザデータを参照して判断する。具体的にはＣＰＵ３０１は、当該ユーザＩＤに関連付けられている編成デッキ情報１４０６に、公式リーグのゲームＩＤが含まれるデッキ情報が存在するか否かを判断する。

公式リーグは、１つの会期として「シーズン」という単位を設ける。シーズンの長さは、リーグ戦の１グループにおけるユーザの総当たり戦の実行に要する期間に応じて設定される。例えば１グループに１６人のユーザが振り分けされ、１シーズンあたり１人のユーザについて３回対戦する総当たり戦を行う場合、シーズンの長さは（１６−１）×３＝４５戦分の長さとなる。

ユーザの順位付けは１シーズンの勝利数に応じてグループごとに行う。本実施形態では、公式リーグに参加している全ユーザに対してグループごとに順位付けを行い、グループ内の順位に応じて階級の昇格あるいは降格を行う。

（階級制度）
ここで、本実施形態のオンライン対戦カードゲームにおける、階級制度について説明する。

公式リーグでは、同じようなレベル（操作スキル、あるいはデッキ構成）を有するユーザ同士を同一グループに振り分けることで、どちらかのユーザが有利に戦況を進めてしまうような対戦を回避する。このようにすることでユーザの興趣を長続きさせることができる。具体的にはＣＰＵ３０１は、グループへのユーザの振り分けを行う際にユーザ管理データベースに記憶されているユーザデータを参照し、同一の階級ＩＤが関連付けられているユーザＩＤでグループを構成するように分類する。即ち、１つのグループには、同一の階級が付与されたユーザが分類される。階級の情報は、例えば新規ユーザがユーザ登録後、公式リーグ用のデッキを編成した際に当該ユーザに対して最初に付与される。このとき付与される階級は、予め定められた種類の階級のうちの最下位の階級である。ＣＰＵ３０１は、当該最下位の階級を示す階級ＩＤをユーザのユーザＩＤに関連付けてユーザ管理データベース３０４に記憶させる。

本実施形態のオンライン対戦カードゲームでは、図５（ａ）に示すように５段階の階級が設けられている。各階級には上限ユーザ数（Ｕcmax1、Ｕcmax2、Ｕcmax3、Ｕcmax4、及びＵcmax5）が設定されている。また、公式リーグの各グループに属するユーザは、１シーズン終了後のグループ内順位に応じて、階級の昇格あるいは降格が実行される。具体的には、階級の昇格あるいは降格の条件は階級のグループごとに例えば図５（ｂ）のように定められており、各階級間では公式リーグの１シーズンごとに決められた人数のユーザの階級が変動する。

例えば、階級の１つであるＣ３では、当該階級の１つのグループにおいて、１シーズン終了後の順位が１〜３位の３名（昇格人数Ｕup）のユーザは１つ上の階級のＣ２に昇格する。また、順位が１１〜１６位の６名（降格人数Ｕdown）のユーザは１つ下の階級のＣ４に降格する。また、順位が４〜１０位の７名（残留人数Ｕstay）のユーザについては階級の変更はなく、階級Ｃ３に残留する。図示されるように、Ｃ３のグループ総数は１６００であるため、１シーズン終了後にはＣ３全体で１６００×３＝４８００人（昇格総人数Ｕupt）のユーザがＣ２に昇格し、１６００×６＝９６００人（降格総人数Ｕdownt）のユーザがＣ４に降格することになる。

なお、上述したオリジナルリーグは、公式リーグとは無関係に１人のユーザがホストとなって一部のユーザを対象に開催するものであるため、当該オリジナルリーグの対戦の戦績は階級の変動に用いられない。

（ボーナスマッチ）
グループ内の総当たり戦による勝利数によって階級の昇格あるいは降格を行う場合、昇格あるいは降格の対象となる順位（昇格順位Ｒup、降格順位Ｒdown）に、勝利数が同数であるユーザが複数存在することが生じうる。これに対し、勝利数、及び引分数の各々について予め設定された係数を、それぞれの数に応じて加算して得られる点数（勝ち点）を用いることにより、同一の勝利数のユーザ間に点数の差をつけて、順位に差を付ける方法が考えられる。しかしながら、本実施形態のオンライン対戦カードゲームのようにターン制を有するゲームでは対戦結果が引き分けとなる可能性が低く、差がつかない可能性がある。

本実施形態では、勝利数が同数のユーザが複数存在する場合に当該ユーザの順位に差が付くように、上述したグループに属するユーザの総当たり戦に加え、複数回のボーナスマッチを設ける。ボーナスマッチではユーザは、登録要求を受けずにゲームシステムが生成してユーザ管理データベース３０４に記憶した、ＮＰＣと呼ばれる仮想ユーザ（以下、ボーナスＮＰＣ）と対戦する。当該ボーナスマッチでユーザがボーナスＮＰＣに勝利した場合、当該勝利はグループの総当たり戦における勝利数には影響しないが、上述した勝ち点に対して、一定の点数を加えるものとする。このようにすることで、総当たり戦の勝利数では階級の昇格あるいは降格を行うユーザが決定できない場合に、当該総当たり戦の戦績には無関係のボーナスマッチの対戦結果による勝ち点の加算を考慮して、同一の順位のユーザに差をつけることができる。

なお、公式リーグにおける各ユーザの対戦の戦績の情報は、図１４（ｃ）に示すように、グループに参加する各ユーザのユーザＩＤに関連付けられてグループテーブルに含まれればよい。具体的にはグループテーブルに含まれる各ユーザの情報（１４３２、１４３３）には、ユーザのユーザＩＤ、公式リーグで使用するデッキ情報、勝利数、引分数、勝ち点、及びボーナスマッチでのボーナスＮＰＣとの戦績が含まれる。

なお、例えばゲームのシナリオに登場する重要キャラクタ等をボーナスＮＰＣとして割り当てることにより、ユーザ同士の対戦だけでなく、ゲームの世界観をユーザに楽しませる効果も与えることができる。またボーナスマッチにユーザが勝利した場合に勝ち点に加えられる一定の点数は、総当たり戦の１つの対戦で勝利した場合に勝ち点に加えられる点数よりも大きくすることで、同一の順位のユーザがいた場合に差がつきやすくしてもよい。

（仮想ユーザの種類）
本実施形態のオンライン対戦カードゲームでは、ユーザ端末２０２からの登録要求を受けてユーザ管理データベース３０４に追加されたユーザ（以下、実ユーザ）を公式リーグの１以上のグループに振り分ける。この結果、グループの実ユーザの数が定員に満たないグループが存在する場合には、ＣＰＵ３０１は、仮想ユーザ（以下、穴埋めＮＰＣ）を追加することで当該グループを定員にする。なお、穴埋めＮＰＣはボーナスＮＰＣとは別に設けられているものとする。また、実ユーザと仮想ユーザとは、異なるルールで生成されたユーザＩＤが付与されてユーザ管理データベース３０４に管理される。実ユーザ及び仮想ユーザのいずれであるか否かは、ＣＰＵ３０１が当該ユーザＩＤを参照することにより判別可能であるものとする。しかしながら、実ユーザと仮想ユーザとの区別はこれに限らず、例えばユーザ管理データベース３０４において実ユーザであるか否かを示す論理型の情報がユーザＩＤに関連付けられて記憶されることによって判別可能であってもよい。

本実施形態のオンライン対戦カードゲームでは、図５（ｂ）に示すように各階級について予め定められた固定数（グループ総数Ｇmax1、Ｇmax2、Ｇmax3、Ｇmax4、及びＧmax5）のグループを毎シーズン作成してリーグ戦を開催する。公式リーグの１シーズンを開始する前に行われるグループ分けでは、実ユーザは付与されている階級について作成されるグループのうちのいずれかに振り分けされる。この結果、振り分けられた実ユーザの数が定員に満たないグループについては、定員になるまで穴埋めＮＰＣが追加される。

例えば、ある階級を示す階級ＩＤが付与されている実ユーザをグループに振り分けるときを考える。このとき、１つのグループのグループテーブルに追加された実ユーザのユーザＩＤの数が、グループの定員（例：１６人）に満たない数（例：５人）であった場合、当該グループテーブルにはユーザ数が定員になるまで、穴埋めＮＰＣのユーザＩＤが追加される（例：１６ー５＝１１人）。

上述したように対戦型ゲームにおいては、実ユーザ同士の対戦及び実ユーザと仮想ユーザとの対戦は、詳細な戦況を生成する処理を実行する必要がある。本実施形態のオンライン対戦カードゲームでは、各階級において実ユーザが振り分けされるグループ数を制限して実ユーザの振り分けを行うことで、当該詳細な戦況を生成する処理の実行を最小限にしてサーバ負荷を軽減する。即ち、実ユーザが振り分けされないグループについては、詳細な戦況の生成処理の実行及びグループの戦績の通知を行う必要がない。このため、当該グループの対戦に係る戦況の生成処理は省略することができる。

公式リーグ戦においてユーザ端末２０２の表示装置に表示される表示画面構成は、例えば図６のようになっている。図示されるように、公式リーグ戦における表示画面には、ユーザ端末２０２を使用するユーザが参加しているグループの詳細情報６０１、総当たり戦において次にユーザが対戦する相手ユーザの情報６０２、次に行われるグループ内の対戦情報６０３、及びグループに参加している全ユーザの現在のシーズンの戦績６０４が含まれる。このように、公式リーグに参加している各ユーザに対しては、当該ユーザが参加しているグループの情報のみが、公式リーグ戦における表示画面として提供される。即ち、ユーザが参加していないグループについてはユーザに通知しないことにより、グループの戦績を生成する処理を省略可能である。

なお、図６に示されるようにシーズン戦績６０４には、グループに参加している全ユーザのユーザ名（ユーザＩＤであってもよい）、勝利数、勝率、勝ち点等の情報が、現在の順位に応じてリスト表示されている。当該リストにおいて、穴埋めＮＰＣは例えば「ＮＰＣ」と明示されることにより識別可能にされている。またグループの詳細情報６０１には、シーズン終了後に当該グループに参加しているユーザのうち、上位の階級に昇格するユーザ数及び下位の階級に降格するユーザ数の情報、及び当該グループに参加している実ユーザ数である「プレイ人数」の情報が表示される。

一方で、当該オンライン対戦カードゲームの運営開始直後は、昇格人数が限られているため、実ユーザは下位の階級に偏る。このとき、グループに昇格人数Ｕupと残留人数Ｕdownの合計数（非降格人数Ｕndown）を超える実ユーザがグループに振り分けた場合、シーズン終了後に階級が降格する実ユーザが存在することになる。例えば１グループが定員１６人であり、階級Ｃ４のグループに実ユーザ４８人を振り分ける場合、実ユーザが振り分けられる最小のグループ数は３となる。そして３つのグループに４８人の実ユーザを振り分けてゲームを行うと、シーズン終了後には図５（ｂ）に従って、各グループの１１〜１６位の１８人のユーザは降格することになる。即ち、上位の階級は上限ユーザ数となる実ユーザが存在しないにも関わらず、下位の階級に降格する実ユーザが存在するため、上位の階級に実ユーザが増加しづらい。つまり、実ユーザの中には上位の階級になかなか昇格できない実ユーザもおり、当該実ユーザのゲームへの参加意欲を削ぐことになってしまう。また、上位の階級に昇格した実ユーザも、対戦相手となる実ユーザが増加しにくく、決まった実ユーザあるいは穴埋めＮＰＣとの対戦の機会が多いため、ゲームに飽きてしまう可能性がある。

このため、本実施形態のオンライン対戦カードゲームでは階級の各々について、当該階級が付与された実ユーザの数が、シーズン終了後に当該階級から降格しない非降格総人数Ｕndowntを超えるまでは、少なくとも１つのグループに降格人数Ｕdownの穴埋めＮＰＣを追加するものとする。例えば、上述したようにＣ３全体における非降格総人数Ｕndownt3は、Ｃ３の上限ユーザ数Ｕcmax3から降格総人数Ｕdownt3を減算した２５６００−９６００＝１６０００人となる。このため、本実施形態ではＣ３の階級ＩＤが付与された実ユーザの数が１６０００人を超えるまでは、ＣＰＵ３０１は１つのグループに降格人数Ｕdown3に相当する６人の穴埋めＮＰＣを少なくとも追加してグループ分けを行う。このときＣＰＵ３０１は、例えば穴埋めＮＰＣは実ユーザとの対戦時には敗北するように戦況を生成するものとし、シーズン終了後には降格順位に実ユーザがならないようにしてもよい。

即ち、ＣＰＵ３０１は、当該階級が付与された実ユーザの数が当該階級の非降格人数Ｕndownを超えるまでは、公式リーグの１つの階級における１つのグループに、非降格人数Ｕndownずつ実ユーザを振り分けする。そして実ユーザが振り分けされたグループの各々には、グループのユーザ数が定員となるまで、少なくとも降格人数Ｕdownの穴埋めＮＰＣであって、実ユーザとの対戦に必ず敗北する穴埋めＮＰＣを追加する。このようにすることで、階級が降格する実ユーザをなくし、かつ戦況を生成する必要があるグループ数を最小限にすることができる。

また、１つの階級が付与された実ユーザの数が当該階級の非降格総人数Ｕndowntを超えた場合は、当該階級のグループ総数Ｇmaxのグループに実ユーザの数を均等に振り分ける。さらに実ユーザが振り分けされたグループの各々には、グループのユーザ数が定員となるまで、実ユーザとの対戦に必ず敗北する穴埋めＮＰＣを追加することで、少なくとも降格順位Ｒdownになる実ユーザの数を最小限にすることができる。

なお、ＣＰＵ３０１は、実ユーザとの対戦において穴埋めＮＰＣを必ず敗北させるか否かを、階級ごとに判断するものとする。即ち、穴埋めＮＰＣを必ず敗北させる処理は、当該処理が行われるグループの階級よりも上位の階級において、当該階級が付与された実ユーザの数が、例えば同階級の上限ユーザ数Ｕcmaxあるいは所定数に満たない場合に行われる処理であってよい。つまり、当該処理は上位の階級が付与された実ユーザの数を増やすための処理であり、上位の階級が付与された実ユーザの数が所望の数になった場合には停止してよい。具体的にはＣＰＵ３０１は、１つの階級について公式リーグの対戦の戦況を生成する処理を行う際に、当該階級よりも上位の階級が付与された実ユーザの人数の情報をユーザ管理データベース３０４から取得し、当該人数が各階級について予め設定された数に満たない場合にのみ、穴埋めＮＰＣが必ず敗北するように戦況を生成するものとする。

なお、穴埋めＮＰＣやボーナスＮＰＣの仮想ユーザは、所有するカードやデッキ構成等が各階級に応じて異なることが好ましい。即ち、階級が上位に行くほど仮想ユーザが所有するカードは、パラメータの平均値が高くなるように設定されるものとする。本実施形態のオンライン対戦カードゲームでは、各階級について一定数の穴埋めＮＰＣ及びボーナスＮＰＣが用意されている。穴埋めＮＰＣ及びボーナスＮＰＣは、実ユーザと同様にそれぞれ異なるユーザＩＤが割り当てられて、ユーザ管理データベース３０４に記憶されている。グループに含まれるユーザの総当たり戦では、同一のユーザＩＤを含めることは戦績の処理上不可能であるため、各階級のグループ分けにおいては、１つのグループ内に同一の穴埋めＮＰＣが存在しないようにする必要がある。このため、１つの階級について用意する穴埋めＮＰＣの数は、１つのグループに実ユーザが１人のみが振り分けられた場合であっても、当該グループに追加する穴埋めＮＰＣについて、同一の穴埋めＮＰＣが存在しない数であればよい。即ち、本実施形態のように１グループにおける実ユーザと穴埋めＮＰＣの合計数が１６人として設定されている場合は、各階級に用意される穴埋めＮＰＣの数は、最低１５人あればよい。

なお、例えば最上位の階級のみ、グループ内だけでなく階級内でのユーザの順位付けを行って前ユーザに公表する場合は、最上位の階級用に用意する穴埋めＮＰＣを、当該階級の上限ユーザ数分用意するようにすればよい。これは、実ユーザが最上位の階級に存在しない場合であっても、最上位の階級における順位付けを生成するためである。またボーナスＮＰＣの数は、ゲームのシナリオに応じて決定されればよいが、例えばシーズン毎に異なるボーナスＮＰＣとの対戦を行えるように、１回のシーズン中には用意されているボーナスＮＰＣのうちの一部と対戦が組まれるようにしてもよい。

（公式リーググループ決定処理）
ここで、本実施形態のゲームシステムにおける、実ユーザが分類されるグループ数を考慮した、公式リーグにおける公式リーググループ決定処理について、図７のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本公式リーググループ決定処理は、公式リーグの１シーズンの開始前に実行されるものとして説明する。

Ｓ７０１で、ＣＰＵ３０１は、ＲＯＭ３０２に記憶されている予め定められた種類の階級のうち、まだ実ユーザのグループ分けがなされていない１つの階級の階級ＩＤを選択する。またＣＰＵ３０１は、選択した階級ＩＤで示される階級について、公式リーグで設けるグループ総数Ｇmaxを示す情報、当該階級の１つのグループについて設定された非降格人数Ｕndownを示す情報、及びシーズン終了後に当該階級から降格しない非降格総人数Ｕndownt（非降格人数Ｕndown×グループ総数Ｇmax、あるいは昇格総人数Ｕupt＋残留総人数Ｕstayt）を示す情報をＲＯＭ３０２より取得する。

Ｓ７０２で、ＣＰＵ３０１は、Ｓ７０１で選択した階級ＩＤで示される階級が付与された実ユーザの数（階級実ユーザ数Ｕruser）を取得する。具体的にはＣＰＵ３０１は、Ｓ７０１で選択した階級ＩＤが関連付けられてユーザ管理データベース３０４に記憶されている実ユーザの数を計数し、階級実ユーザ数Ｕruserを示す情報を取得する。

Ｓ７０３で、ＣＰＵ３０１は、階級実ユーザ数Ｕruserがシーズン終了後に少なくともＳ７０１で取得した、当該階級から降格しない非降格総人数Ｕndownt以下であるか否かを判断する。ＣＰＵ３０１は、階級実ユーザ数Ｕruserが非降格総人数Ｕndownt以下であると判断した場合は処理をＳ７０４に移し、非降格総人数Ｕndowntより大きいと判断した場合は処理をＳ７０５に移す。

Ｓ７０４で、ＣＰＵ３０１は、選択した階級ＩＤが示す階級が付与された実ユーザを振り分けるグループの数（振り分けグループ数Ｇruser）を算出する。具体的にはＣＰＵ３０１は階級実ユーザ数Ｕruserを各グループにおいて非降格人数Ｕndownで除し、端数を切り上げることにより振り分けグループ数Ｇruserを算出する。

またＳ７０３で、階級実ユーザ数Ｕruserが、選択した階級ＩＤが示す階級から降格しない非降格総人数Ｕndowntより大きいと判断した場合、ＣＰＵ３０１はＳ７０５で、振り分けグループ数をＳ７０１で取得した当該階級について設けるグループ総数Ｇmaxに設定する。

Ｓ７０６では、ＣＰＵ３０１は、選択した階級ＩＤが示す階級が付与された実ユーザを、予め定められた規則に従って、振り分けグループ数Ｇruserのグループに振り分けるグループ分類処理を実行する。なお、当該グループ分類処理の詳細については後述するが、階級実ユーザ数Ｕruserが非降格総人数Ｕndownt以下である場合は、ＣＰＵ３０１は１つのグループに振り分ける実ユーザの数が非降格人数Ｕndownとなるように、順にグループを選択して実ユーザを振り分ける。また階級実ユーザ数Ｕruserが非降格総人数Ｕndowntより大きい場合は、ＣＰＵ３０１は各グループに振り分ける実ユーザの数が均等になるように振り分けを行う。即ち、１つのグループには非降格人数Ｕndownの実ユーザが優先的に振り分けられる。

Ｓ７０７で、ＣＰＵ３０１は、ＲＯＭ３０２に記憶されている予め定められた種類の階級の全てについて、実ユーザのグループ分けを行なったか否かを判断する。ＣＰＵ３０１は、まだ実ユーザのグループ分けを行っていない階級がある場合は処理をＳ７０１に戻し、全ての階級について実ユーザのグループ分けが完了している場合は公式リーググループ決定処理を完了する。

（フレンド登録）
また、本実施形態のオンライン対戦カードゲームでは、ユーザ同士の交流を促進するためにフレンド登録機能を有し、フレンド登録を行なったユーザ同士は公式リーグ戦において同一のグループに振り分けされるようにグループ分類処理が行われる。

ここで、ユーザ同士のフレンド登録を行う方法について、図を用いて説明する。例えばユーザＡがユーザＢをフレンドとして登録したい場合、ユーザＡは、ユーザ検索画面においてユーザＢを検索する、あるいはゲームシステムにログイン中のユーザの一覧リストの中からユーザＢを選択することにより、図８（ａ）のようなユーザＢの詳細画面に遷移する。そして当該画面においてフレンド登録ボタン８０１を選択することにより、ユーザＢをフレンドとして登録することができる。フレンドとして登録されたユーザＢは、例えば図８（ｂ）に示されるようなユーザＡに関する詳細情報を確認する画面におけるフレンドリスト領域８０２にフレンドアイコン８０３を用いて表示される。

当該フレンド登録に係る処理は、例えば以下のようにＣＰＵ３０１によって処理される。ＣＰＵ３０１は、ネットワークＩ／Ｆ３０６を介してユーザＡのユーザ端末２０２からユーザＢについてのフレンド登録要求を受信すると、ユーザ管理データベース３０４に記憶されている、ユーザＡのユーザＩＤに関連付けられたフレンドテーブルの情報を読み出す。フレンドテーブルは、例えば図１４（ｂ）に示すようにユーザによってフレンド登録要求がなされたユーザのユーザＩＤが追加されたリストであり、ＣＰＵ３０１は読み出したユーザＡのユーザＩＤに関連付けられたフレンドテーブルに、ユーザＢのユーザＩＤを追加して再びユーザ管理データベース３０４に記憶させることにより、ユーザＡとユーザＢとのフレンド関係を構築する。なお、本実施形態ではユーザからフレンド登録要求を受信した際に、当該ユーザＩＤに関連付けられたフレンドテーブルに被登録ユーザのユーザＩＤを追加するものとして説明するが、本発明のフレンド登録方法はこれに限られない。例えばＣＰＵ３０１は、ユーザＡのユーザ端末２０２からユーザＢのフレンド登録要求を受信した場合に、まずユーザＢに対してユーザＡのフレンド登録の承認の可否を要求し、ユーザＢが当該承認を認可した際にユーザＡ及びユーザＢそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤの情報を追加し、ユーザＡとユーザＢとの間にフレンド関係を構築する構成であってもよい。

なお、ＣＰＵ３０１は、ユーザ端末２０２よりユーザに関する詳細情報の表示要求を受信した場合は、まず当該ユーザのユーザＩＤに関連付けられているフレンドテーブルをユーザ管理データベース３０４より読み出す。そしてＣＰＵ３０１は、当該テーブルに含まれるユーザＩＤに関連付けられているグラフィック情報をグラフィックデータベース３０７より取得して、図８（ｂ）のフレンドリスト領域８０２にフレンドアイコン８０３として描画するものとする。

（グループ分類処理）
ここで、任意のユーザと、当該ユーザとフレンド関係を有し、かつ当該ユーザと同一の階級を有するフレンドユーザとを同一のグループに分類する、上述した公式リーググループ決定処理におけるグループ分類処理について、図９のフローチャートを用いて詳細に説明する。なお、本グループ分類処理は、上述した公式リーググループ決定処理において呼び出される処理であるため、決定された実ユーザを分類するグループ数（振り分けグループ数）の情報に基づいて階級ごとに実行される。

Ｓ９０１で、ＣＰＵ３０１は、処理対象の階級ＩＤが示す階級が付与された実ユーザの集合を、ユーザとフレンド関係を有するフレンドユーザが当該集合内に含まれるか否かによって２つの集合に分類する。

具体的にはＣＰＵ３０１は、まず処理対象の階級ＩＤが関連付けられている実ユーザのユーザＩＤをユーザ管理データベース３０４より読み出してＲＡＭ３０３の実ユーザリストに追加する。そしてＣＰＵ３０１は、当該実ユーザリストに追加されているユーザＩＤの各々について、当該ユーザＩＤに関連付けられているフレンドテーブルの情報をユーザ管理データベース３０４より読み出す。さらにフレンドテーブルと実ユーザリストの両方に含まれるユーザＩＤが存在する場合は、ＣＰＵ３０１は当該両方に含まれるユーザＩＤと、フレンドテーブルが関連付けられているユーザＩＤとを、同じ階級内にフレンドユーザが存在する実ユーザのリストであるＲＡＭ３０３のリストＡに追加するとともに、実ユーザリストからリストＡに追加したユーザＩＤを削除する。

このような処理を実ユーザリストに含まれるユーザＩＤの各々について繰り返し実行することにより、同じ階級内にフレンドユーザが存在する実ユーザのユーザＩＤをリストＡに分離することができる。なお、本ステップの処理後の実ユーザリストは、同じ階級内にフレンドユーザが存在しない実ユーザのユーザＩＤのみが含まれるリストとなっている。以下の説明では、処理後の実ユーザリストをリストＢとして説明する。

Ｓ９０２で、ＣＰＵ３０１は、リストＡに含まれる実ユーザを、ユーザ関係を有するユーザの組に分類する。具体的にはＣＰＵ３０１は、リストＡに含まれるユーザＩＤをランダムに選択し、当該ユーザＩＤとフレンド関係を有する、リストＡに含まれるフレンドユーザのユーザＩＤのうちから、４人のフレンドユーザのユーザＩＤをランダムに選択する。なお、このときフレンド関係を有するフレンドユーザが４人に満たない場合は、ＣＰＵ３０１はフレンド関係を有する全てのフレンドユーザのユーザＩＤを選択する。そしてＣＰＵ３０１は、当該ランダムに選択したユーザＩＤと、最大４人のフレンドユーザのユーザＩＤとを、フレンド関係を有する最大５人のユーザのユーザＩＤで構成される構造体としてＲＡＭ３０３のリストＣに追加する。このとき、ＣＰＵ３０１はリストＡから当該構造体に含められたユーザＩＤを削除する。即ち、本ステップにおいてＣＰＵ３０１は、処理対象の階級における１つのグループについての非降格人数Ｕndownの半数以下で構成される、フレンド関係を有するユーザの組を作る。

本ステップでは、ＣＰＵ３０１はこのような組分け処理を、リストＡに含まれるユーザＩＤがなくなるまで、あるいはリストＣに追加された構造体の数が振り分けグループ数Ｇruserの２倍になるまで繰り返す。なお、組分け処理を実行することにより、ランダムに選択したユーザについて、当該ユーザのフレンドユーザが既に組分けされており、リストＡに含まれるフレンドユーザのユーザＩＤの数が０である場合がある。このような場合は当該選択したユーザに対して組分けを行うことができないため、ＣＰＵ３０１は当該選択したユーザのユーザＩＤをリストＢに移動するものとする。また、リストＣに追加された構造体の数が振り分けグループ数Ｇruserの２倍になり組分け処理を停止した場合、ＣＰＵ３０１はリストＡ似含まれる残りのユーザＩＤについては、リストＢに移すものとする。

Ｓ９０３で、ＣＰＵ３０１は、処理対象の階級ＩＤに関連付けて、振り分けグループ数Ｇruserのグループテーブルをグループデータベース３０８に作成する。このとき、作成された振り分けグループ数Ｇruserのグループテーブルは、それぞれ異なるグループＩＤが関連付けられ、独立して管理されるものとする。

Ｓ９０４乃至Ｓ９０７の処理で、ＣＰＵ３０１は、リストＢ及びリストＣに含まれる実ユーザのユーザＩＤをグループテーブルに順に追加することで、Ｓ９０３でグループデータベース３０８に作成した振り分けグループ数Ｇruserのグループテーブルのそれぞれに非降格人数Ｕndownの実ユーザを追加する。

Ｓ９０４で、ＣＰＵ３０１は、グループデータベース３０８に作成した振り分けグループ数のグループテーブルのうち、実ユーザのユーザＩＤをまだ追加していないグループテーブルを選択する。

Ｓ９０５で、ＣＰＵ３０１は、リストＣから２つの構造体を読み出し、当該構造体に含まれるユーザＩＤの全てをＳ９０４で選択したグループテーブルに追加する。またＣＰＵ３０１は、読み出した２つの構造体をリストＣから削除する。なお、リストＣに１つの構造体しか存在しない場合は、ＣＰＵ３０１は当該１つの構造体に含まれるユーザＩＤのみを選択したグループテーブルに追加するものとする。また、リストＣに含まれる構造体が存在しない場合は、ＣＰＵ３０１は本ステップの処理を行わずに、処理をＳ９０６に移す。

Ｓ９０６で、ＣＰＵ３０１は、選択中のグループテーブルに追加したユーザＩＤの数、即ちＳ９０５で読み出した２つの構造体に含まれていたユーザＩＤの数が非降格人数Ｕndownと等しい否かを判断する。ＣＰＵ３０１は、選択中のグループテーブルに追加したユーザＩＤの数が非降格人数Ｕndownと等しいと判断した場合は処理をＳ９０７に移し、非降格人数Ｕndownに満たないと判断した場合は処理をＳ９０６に移す。

Ｓ９０６で、ＣＰＵ３０１は、リストＢに含まれるユーザＩＤをグループテーブルにランダムに選択して追加することで、選択中のグループテーブルに含まれるユーザＩＤの数を非降格人数Ｕndownとする。このとき、ＣＰＵ３０１は、Ｓ９０５と同様に、グループテーブルに追加したユーザＩＤをリストＢから削除する。なお、本ステップにおいてリストＢに含まれる全てのユーザＩＤを追加しても選択中のグループテーブルに含まれるユーザＩＤの数が非降格人数Ｕndownに達しない場合は、ＣＰＵ３０１は選択中のグループテーブルに当該全てのユーザＩＤを追加して処理をＳ９０７に移せばよい。また、リストＢに含まれるユーザＩＤが存在しない場合は、ＣＰＵ３０１は本ステップの処理を行わずに処理をＳ９０７に移す。

Ｓ９０７で、ＣＰＵ３０１は、グループデータベース３０８に作成した振り分けグループ数のグループテーブルの全てに、ユーザＩＤを追加したか否かを判断する。ＣＰＵ３０１は、振り分けグループ数のグループテーブルの全てにユーザＩＤを追加したと判断した場合は処理をＳ９０８に移し、ユーザＩＤを追加していないグループテーブルが存在すると判断した場合は処理をＳ９０４に戻す。

Ｓ９０８で、ＣＰＵ３０１は、リストＢに含まれるユーザＩＤが存在するか否かを判断する。即ち、本ステップにおいてＣＰＵ３０１は、処理対象の階級の実ユーザのうち、まだグループテーブルに追加されていないユーザＩＤが存在するか否かを判断する。ＣＰＵ３０１は、リストＢに含まれるユーザＩＤが存在すると判断した場合は処理をＳ９０９に移し、リストＢに含まれるユーザＩＤは存在しないと判断した場合は処理をＳ９１０に移す。

Ｓ９０９で、ＣＰＵ３０１は、リストＢに含まれるユーザＩＤを、グループデータベース３０８に作成された振り分けグループ数Ｇruserのグループテーブルに均等に配分して追加する。なお、リストＢに含まれるユーザＩＤの数を振り分けグループ数Ｇruserで除した際に端数が存在する場合は当該配分は均等ではなく、端数分のグループは、他のグループよりもグループテーブルに追加されるユーザＩＤの数が多くなることは言うまでもない。

Ｓ９１０で、ＣＰＵ３０１は、グループデータベース３０８に作成された振り分けグループ数のグループテーブルの各々を参照し、追加した実ユーザのユーザＩＤがグループに含めるユーザの定員に満たない場合は、処理対象の階級ＩＤに関連付けられている仮想ユーザのユーザＩＤをユーザ管理データベース３０４から読み出して追加して当該グループテーブルに含まれるユーザＩＤの数を定員数として、本グループ分類処理を完了する。

このようにすることで、本実施形態のオンライン対戦カードゲームでは、公式リーグにおける実ユーザのグループ分類において、フレンド関係を有するユーザ同士が同一のグループに含まれるように実ユーザを分類することができる。なお、本実施形態では、フレンド関係を有するユーザの組を、非降格人数Ｕndownの半数となるように組分けするものとして説明したが、本発明の実施はこれに限らず、組分けは任意の階級においてフレンド関係を有するユーザ同士が同一のグループに含まれるように行えばよい。

また、このように公式リーグにおける実ユーザのグループ分類において、フレンド関係を有するユーザが同一グループに分類されていることは、例えば図６に示すように、ユーザ端末２０２の表示装置に表示される表示画面に含まれるフレンドリスト６０５において通知される。具体的には、フレンド関係を有するユーザのアイコンに対して参加通知６０６が付加されることによりユーザに通知されればよい。

以上説明したように、本実施形態のゲームシステムは、交流のあるユーザと同一グループに割り当てられる確率を上昇させる、対戦リーグに係る処理負荷を軽減させることができる。具体的にはゲームシステムは、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当て、さらに予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する。また登録されているユーザのうち、第１のユーザのユーザ端末より、第２のユーザについてのフレンド登録要求を受け付け、第１のユーザ及び第２のユーザそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤを追加することにより、第１のユーザと第２のユーザとの間にフレンド関係を構築する。そして登録されているユーザを同一の階級に属する所定数のユーザで構成される１以上のグループテーブルに追加する際に、当該ユーザのユーザＩＤに関連付けられたフレンドテーブルに、当該ユーザＩＤに関連付けられた階級ＩＤと同一の階級ＩＤが関連付けられたユーザＩＤが存在する場合は、追加するユーザのユーザＩＤと当該同一の階級ＩＤが関連付けられたユーザＩＤとを同一のグループテーブルに追加する。

［実施形態２］
上述した実施形態１のオンライン対戦カードゲームでは、公式リーグのシーズン終了後の各グループにおける戦績に応じて、実ユーザに付与されている階級の昇格あるいは降格が行われる。図５（ｂ）に示したように、基本的には昇格及び降格が行われる２つの階級間において、上位の階級に昇格する実ユーザの合計数（昇格総人数Ｕupt）と、下位の階級に降格する実ユーザの合計数（降格総人数Ｕdownt）とは等しくなるように設定される。しかしながら、ゲームサーバ２０１に高い処理負荷が与えられた場合等で想定外の処理が発生すると、１つの階級において上限ユーザ数を超える実ユーザが割り当てられてしまう可能性が考えられる。このような状況が発生した場合、上述したグループ分類時にゲームサーバ２０１がフリーズしてしまうこともあり得るため、本実施形態では当該状況を想定したエラー回避処理について説明する。

＜エラー回避処理＞
以下、本実施形態のゲームシステムにおける、１つの階級に上限ユーザ数を超える実ユーザが割り当てられた場合のエラー回避処理について、図１０のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本エラー回避処理は、公式リーグのシーズン終了後に各グループにおける戦績に応じて階級変更処理を行う際に、１つの階級ＩＤが関連付けられるユーザＩＤの数が当該階級ＩＤが示す階級について予め定められたグループ総数Ｇmaxのグループテーブルに追加できるユーザＩＤの数（上限ユーザ数Ｕcmax）を超えるとＣＰＵ３０１が判断した場合に実行されるものとする。

Ｓ１００１で、ＣＰＵ３０１はまず、階級変更処理を行った場合に、階級について予め定められた上限ユーザ数Ｕcmaxを超える実ユーザのユーザＩＤに当該階級の階級ＩＤが関連付けられる階級（エラー階級）を特定する。そして特定したエラー階級について、グループ総数Ｇmaxを一時的に引き上げる。このとき、一時的に引き上げるグループ総数Ｇ’maxは、引き上げ後のグループ総数Ｇ’maxのグループテーブルに追加できるユーザＩＤの数が、当該エラー階級の階級ＩＤが関連付けられるユーザＩＤの数を超えるように設定される。

Ｓ１００２で、ＣＰＵ３０１は、エラー階級から昇格及び降格可能な階級の各々ついて、各階級の上限ユーザ数Ｕcmaxと、階級変更処理後に当該階級が付与される実ユーザの数（階級実ユーザ数Ｕruser）との差分の情報を取得し、階級変更処理後に階級実ユーザ数Ｕruser実ユーザが上限ユーザ数Ｕcmaxに満たない階級を把握する。

具体的にはＣＰＵ３０１は、エラー階級（例：Ｃ３）の１つ上位（例：Ｃ２）及び１つ下位（例：Ｃ４）の階級のそれぞれについて、階級変更処理を行なった場合に当該階級の階級ＩＤが関連付けられるユーザＩＤの数（階級実ユーザ数Ｕruser2、Ｕruser4）をユーザ管理データベース３０４より取得する。またこのときＣＰＵ３０１は、エラー階級の１つ上位及び１つ下位の階級のそれぞれについて上限ユーザ数（Ｕcmax2、Ｕcmax4）の情報をＲＯＭ３０２より取得する。そしてＣＰＵ３０１は、エラー階級の１つ上位及び１つ下位の階級のそれぞれについて、上限ユーザ数から階級変更処理後の階級実ユーザ数を減算する。ＣＰＵ３０１は当該減算結果が０より大きい階級、即ち階級変更処理後に実ユーザの数が上限ユーザ数に満たない階級が、エラー階級の１つ上位の階級、エラー階級の１つ下位の階級、及びエラー階級の１つ上位及び１つ下位の両方の階級、のいずれであるかを判断する。

そしてＣＰＵ３０１は、階級変更処理後の階級実ユーザ数Ｕruserが上限ユーザ数Ｕcmaxに満たない階級がエラー階級の１つ上位の階級であると判断した場合は処理をＳ１００３に移し、エラー階級の１つ下位の階級であると判断した場合は処理をＳ１００４に移す。またＣＰＵ３０１は、階級変更処理後の階級実ユーザ数Ｕruserが上限ユーザ数Ｕcmaxに満たない階級がエラー階級の１つ上位及び１つ下位の階級の両方であると判断した場合は処理をＳ１００５に移す。

Ｓ１００３で、ＣＰＵ３０１は、次のシーズン終了後にエラー階級の１つ上位の階級に昇格する、エラー階級が付与された実ユーザの数を増加させる。具体的にはＣＰＵ３０１は、次のシーズン終了後には当該エラー階級の階級ＩＤが割り当てられるユーザＩＤの数が引き上げ前の上限ユーザ数（Ｕcmax3）となるように、階級を昇格させる実ユーザの数（昇格総人数Ｕupt）を設定する。

同様にＳ１００４で、ＣＰＵ３０１は、次のシーズン終了後にエラー階級の１つ下位の階級に降格する、エラー階級が付与された実ユーザの数を増加させる。具体的にはＣＰＵ３０１は、次のシーズン終了後には当該エラー階級の階級ＩＤが割り当てられるユーザＩＤの数が引き上げ前の上限ユーザ数Ｕcmaxとなるように、階級を降格させる実ユーザの数（降格総人数Ｕdownt）を設定する。

またＳ１００５で、ＣＰＵ３０１は、次のシーズン終了後にエラー階級の１つ上位の階級に昇格する、及び１つ下位の階級に降格する、エラー階級が付与された実ユーザの数（昇格総人数Ｕupt及び降格総人数Ｕdownt）を増加させる。具体的にはＣＰＵ３０１は、次のシーズン終了後にはエラー階級、当該エラー階級の１つ上位の階級、及び当該エラー階級の１つ下位の階級の階級ＩＤが割り当てられるユーザＩＤの数（階級実ユーザ数Ｕruser2、Ｕruser3、及びＵruser4）が、それぞれの階級にもともと割り当てられた上限ユーザ数（Ｕcmax2、Ｕcmax3、及びＵcmax4）となるように、階級を昇格させるあるいは降格させる実ユーザの数を設定する。

このように、１シーズンの終了時の階級変更処理を行う際に、１つの階級についての階級実ユーザ数Ｕruserが、当該階級について予め定められた上限ユーザ数Ｕcmaxを超える場合であっても、一時的に上限ユーザ数Ｕcmaxを引き上げることで、当該エラーを許容し、さらに階級の昇格及び降格を制御することで、次のシーズン終了後にエラーを修正する。

なお、本実施形態では上述した処理は、上位及び下位の階級が存在するＣ２〜Ｃ４に適用可能であることは容易に想像されよう。また、最上位である階級Ｃ１についても、上位の階級についての上限ユーザ数Ｕcmaxと階級実ユーザ数Ｕruserの比較の処理を除外すれば適用可能であることは理解されよう。即ち、Ｃ１については、ＣＰＵ３０１はＳ１００２の処理は省略してＳ１００４に処理を移してもよい。

また、最下位である階級Ｃ５については、公式リーグ用のデッキを編成したユーザが新たに追加される可能性があるため、公式リーグの実ユーザの振り分けを行う公式リーググループ決定処理の直前に以下のように処理すればよい。ＣＰＵ３０１は、Ｃ５の階級ＩＤが付与された階級実ユーザ数Ｕruser5と、１つ上位の階級に当たるＣ４の階級が付与された階級実ユーザ数Ｕruser4、及びそれぞれの階級の上限ユーザ数Ｕcmax4、Ｕcmax5の情報を、それぞれユーザ管理データベース３０４及びＲＯＭ３０２より取得する。そしてＣＰＵ３０１は、Ｃ５において上限ユーザ数Ｕcmax5を超える実ユーザの数（Ｕruser5−Ｕcmax5）と、Ｃ４に追加可能な実ユーザの数（Ｕcmax4−Ｕruser4）とを比較する。このときＵruser5−Ｕcmax5＞Ｕcmax4−Ｕruser4である場合は、シーズン終了後にＣ５の階級実ユーザ数Ｕruser5を上限ユーザ数Ｕcmax5にすることができないため、ＣＰＵ３０１は（Ｕruser5−Ｕcmax5）−（Ｕcmax4−Ｕruser4）人のＣ５の実ユーザについては、シーズン終了後にユーザ数が定員に達したことを通知し、次のシーズンには振り分け対象としないようにすればよい。

なお、本実施形態では、１つの階級についてユーザ上限数を超えるようなユーザＩＤに当該階級の階級ＩＤが関連付けられるエラーが発生した場合に、次のシーズン終了後に当該エラーを修正する方法について説明したが、本発明の実施はこれに限らず、ユーザ上限数を永続的に引き上げられる構成にすることで、さらなるエラーを生じないようにしてもよい。

［実施形態３］
本実施形態及び上述した実施形態のオンライン対戦カードゲームは、ユーザが全ての対戦のためにゲームシステムにログインする必要がないよう、あるいはリーグ戦に参加する全てのユーザがログインしなくても進行するように、公式リーグの１シーズンに係る処理が自動的に開始される。ユーザ同士の対戦について生成される詳細な戦況は、対戦するユーザの各々が使用するデッキに応じて自動的に生成されるように構成されている。なお、上述したように公式リーグの１シーズンは、基本的には公式リーグ用のデッキを編成済みの全ユーザが参加対象者となる。
しかしながら、このように自動的に進行するオンライン対戦カードゲームでは、長期間ログインしていないユーザも参加対象者として含まれるため、サービスを破綻させてしまう可能性がある。具体的には、実際にはサービスの利用意欲がないユーザのユーザＩＤの情報が公式リーグに自動的に登録されることにより、公式リーグに参加する実ユーザの数が公式リーグ全体の参加上限数Ｕmaxtに到達してしまうことがあるため、新規のユーザは公式リーグに参加することができない可能性がある。

本実施形態では、このように長期間ログインしていないユーザを強制的に排除することで、公式リーグに参加する実ユーザの数が公式リーグ全体の参加上限数Ｕmaxtとなりにくくする方法について説明する。

＜長期未ログインユーザ排除処理＞
以下、本実施形態のゲームシステムにおける、公式リーグの参加対象者となるユーザのうち、長期間ログインしていないユーザを強制的に排除する長期未ログインユーザ排除処理について、図１１のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本長期未ログインユーザ排除処理は、公式リーグの１シーズン終了後、次のシーズンに係る公式リーググループ決定処理を実行する前に行われるものとする。

また、本実施形態ではネットワークＩ／Ｆ３０６を介してユーザ端末２０２よりユーザのログイン要求を受け付けた場合、ＣＰＵ３０１はログイン要求を受け付けたユーザのユーザＩＤに関連付けて、最後にログイン要求を受け付けた日時の情報１４０８（図１４（ａ））をユーザ管理データベース３０４に記憶させるものとする。

Ｓ１１０１で、ＣＰＵ３０１は、公式リーグの参加対象者の全実ユーザのうち、１人の実ユーザのユーザＩＤを選択し、当該ユーザＩＤに関連付けられてユーザ管理データベース３０４に記憶されている、最後にログイン要求を受け付けた日時の情報が、現在日時から所定期間以上前の日時を示しているか否かを判断する。ＣＰＵ３０１は、選択した実ユーザのユーザＩＤに関連付けられている、最後にログイン要求を受け付けた日時の情報が、現在日時から所定期間以上前の日時を示していると判断した場合は処理をＳ１１０２に移し、所定期間内の日時を示していると判断した場合は処理をＳ１１０３に移す。

Ｓ１１０２で、ＣＰＵ３０１は、選択したユーザＩＤで示される実ユーザを公式リーグに参加させないことを示す論理型のフラグ情報１４０９を、当該ユーザＩＤに関連付けてユーザ管理データベース３０４に記憶する。

Ｓ１１０３で、ＣＰＵ３０１は、公式リーグの参加対象者の全実ユーザのユーザＩＤに対して、最後にログイン要求を受け付けた日時に基づく、公式リーグへの参加可否の判断が完了したか否かを判断する。ＣＰＵ３０１は、公式リーグの参加対象者の全実ユーザのユーザＩＤに対して公式リーグへの参加可否の判断が完了していると判断した場合は本長期未ログインユーザ排除処理を完了し、参加可否の判断が完了していないユーザＩＤが存在すると判断した場合は処理をＳ１１０１に戻す。

本実施形態では、このように最後にログイン要求を受け付けた日時が現在日時から所定期間以上前である実ユーザについては、当該ユーザのユーザＩＤに公式リーグにさせないことを示すフラグ情報を関連付けることにより、上述した公式リーググループ決定処理及びグループ分類処理において、当該ユーザをグループテーブルに追加する対象から除外することができる。

なお、公式リーグにさせないことを示すフラグ情報がユーザＩＤに関連付けられているユーザから、ネットワークＩ／Ｆ３０６を介して再度ログイン要求を受信した場合、ＣＰＵ３０１は当該ユーザのユーザＩＤに関連付けられているフラグ情報を削除する。これにより当該ユーザは公式リーグに再度参加可能な状態となるが、公式リーグに参加不可能な状態にされる前に当該ユーザに付与されていた階級の情報は削除され、予め定められた種類の階級のうちの最下位の階級の階級ＩＤが当該ユーザのユーザＩＤに関連付けられるものとする。これは、当該ユーザに付与されていた階級が付与された実ユーザの数が、既に当該階級について予め定められているユーザ上限数となっている可能性があるからである。なお、このときＣＰＵ３０１は、例えば図１２に示すような最下位の階級が付与されたことを示す通知画面を当該ユーザのユーザ端末２０２の表示装置にさせればよい。

［実施形態４］
上述した実施形態１乃至３では、公式リーグ用のデッキを編成済みの全ユーザを公式リーグの参加対象者とするものとして説明したが、実施形態３で説明したように参加対象者となる実ユーザの数が公式リーグ全体の参加上限数Ｕmaxtを超えた場合、公式リーグに参加できなくなる実ユーザが現れることになる。

上述した実施形態１乃至３のようなオンライン対戦カードゲームでは、運営上、単発的な利用ユーザよりも長期的な利用ユーザを増加させることが好ましいが、以下のような場合、長期的な利用ユーザであっても、公式リーグに参加することができない状況になる可能性がある。例えば長期的な利用ユーザが、公式リーグ用に編成したデッキを一度削除することにより１度公式リーグから外れ、その後再度公式リーグ用のデッキを編成して公式リーグに参加しようとしても、公式リーグに参加しているユーザの数が公式リーグ全体の参加上限数に達していた場合、当該ユーザはサーバの増設が行われるまでは公式リーグに参加できなくなってしまう可能性がある。結果として、長期的な利用ユーザの興趣をそいでしまうことになる。

本実施形態では、このような問題を解決するために、長期的な利用ユーザが公式リーグの参加対象者として選択されやすくする方法について説明する。

（参加対象決定処理）
以下、本実施形態のゲームシステムにおける、公式リーグの参加対象者となるユーザを決定する参加対象決定処理について、図１３のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本参加対象決定処理は、上述した公式リーググループ決定処理を実行する前に行われるものとする。

また、本実施形態ではＣＰＵ３０１は、最後に終了した公式リーグのシーズンに参加していたユーザの各々について、当該最後に終了したシーズンに参加していたことを示すフラグ情報１４２０をユーザＩＤに関連付けてユーザ管理データベース３０４に記憶するものとする。また、公式リーグ全体の参加上限数Ｕmaxtは、各階級について予め定められている上限ユーザ数Ｕcmaxを足しあわせた数よりも小さい値（例えば１０万人等）に設定されてもよいものとする。

Ｓ１３０１で、ＣＰＵ３０１は、ユーザ管理データベース３０４に記憶されている実ユーザのユーザＩＤのうち、当該ユーザＩＤに最後に終了したシーズンに参加していたことを示すフラグ情報が関連付けられているユーザＩＤを、まず次のシーズンの公式リーグへの参加対象者の実ユーザとして選択する。具体的にはＣＰＵ３０１は、最後に終了したシーズンに参加していたことを示すフラグ情報が関連付けられているユーザＩＤに対して、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報１４１１を関連付けてユーザ管理データベース３０４に記憶する。

なお、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報は、次のシーズンが終了した際には、最後に終了したシーズンに参加していたことを示すフラグ情報として用いられてもよい。また本ステップは、上述した実施形態３の長期未ログインユーザ排除処理が実行された後に、公式リーグに参加させないことを示すフラグ情報が関連付けられていないユーザＩＤを対象としてもよい。

Ｓ１３０２で、ＣＰＵ３０１は、ユーザ管理データベース３０４を参照し、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザＩＤの数が、公式リーグ全体の参加上限数Ｕmaxtより小さいか否かを判断する。ＣＰＵ３０１は、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザＩＤの数が公式リーグ全体の参加上限数Ｕmaxtより小さい場合は処理をＳ１３０３に移し、公式リーグ全体の参加上限数以上である場合は本参加対象者決定処理を完了する。

Ｓ１３０３で、ＣＰＵ３０１は、ユーザ管理データベース３０４に記憶されている、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられていない実ユーザのユーザＩＤのうち、当該ユーザＩＤのユーザ管理データベース３０４への登録順の情報が最も若い、即ち時系列順で最も古いユーザＩＤを選択する。なお、本ステップにおいて、既にＳ１３０４以降の処理を行うために選択したユーザＩＤについては選択対象外とし、選択対象のユーザＩＤが存在しない場合は本参加対象者決定処理を完了するものとする。

Ｓ１３０４で、ＣＰＵ３０１は、Ｓ１３０３で選択したユーザＩＤに関連付けられている階級ＩＤをユーザ管理データベース３０４より取得する。そしてＣＰＵ３０１は、当該階級ＩＤが関連付けられ、かつ次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザＩＤの数が、当該階級ＩＤが示す階級について予め定められた上限ユーザ数Ｕcmaxを超えているか否かを判断する。即ち、ＣＰＵ３０１は本ステップで、Ｓ１３０３で選択したユーザＩＤに関連付けられた階級のグループに、さらに実ユーザを加えられる空きが存在するか否かを判断する。ＣＰＵ３０１は、選択したユーザＩＤに関連付けられた階級のグループに、さらに実ユーザを加えられる空きが存在すると判断した場合は処理をＳ１３０５に写、存在しないと判断した場合は処理をＳ１３０２に戻す。

Ｓ１３０５で、ＣＰＵ３０１は、Ｓ１３０３で選択したユーザＩＤに対して、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報を関連付けてユーザ管理データベース３０４に記憶し、処理をＳ１３０２に戻す。

このようにすることで、長期的な利用ユーザであると思われる、登録要求がなされた日時が古いユーザを優先的に公式リーグへの参加対象者とすることができる。

なお、上述した各実施形態の説明では、ネットワークを介して、カードを用いたユーザ同士の対戦を実現するゲームシステムについて説明したが、本発明のゲームシステムはこれに限られない。本発明の実施は、ユーザ同士の対戦を実現する形態としてリーグ戦を有する如何なるゲームシステムにおいても適用可能であることは容易に理解されよう。

登録されているユーザが参加するリーグ戦であって、登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録手段と、登録されているユーザの各々について、ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、１以上のグループを生成するグループ生成手段と、登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、１以上のグループに分類する分類手段と、ユーザ同士の対戦のうち、実ユーザのユーザＩＤが含まれるグループテーブルで示されるグループにおける対戦の結果は通知し、仮想ユーザのユーザＩＤのみが含まれるグループテーブルで示されるグループ対戦の結果は非通知とする対戦結果通知手段と、を有し、登録されているユーザは、ユーザ端末より登録要求を受け付けてユーザ管理データベースに登録された実ユーザと、登録要求を受けずにゲームシステムが生成してユーザ管理データベースに登録した仮想ユーザとで構成され、分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加することを特徴とする。

Claims (8)

1. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、
   ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録手段と、
   前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、
   グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成手段と、
   前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類手段と、を有し、
   前記登録されているユーザは、ユーザ端末より前記登録要求を受け付けて前記ユーザ管理データベースに登録された実ユーザと、前記登録要求を受けずに前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザとで構成され、
   前記分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加する
   ことを特徴とするゲームシステム。
2. それぞれの階級について前記ユーザ管理データベースに登録されている前記仮想ユーザの数は固定であり、
   前記分類手段は、各グループテーブルに、同一の階級ＩＤが関連付けられた実ユーザのユーザＩＤと仮想ユーザのユーザＩＤとを追加し、当該グループテーブルに追加したユーザＩＤの数を定員にする
   ことを特徴とする請求項１に記載のゲームシステム。
3. 前記ユーザ同士の対戦のうち、実ユーザのユーザＩＤが含まれるグループテーブルで示されるグループにおける対戦の結果は通知し、仮想ユーザのユーザＩＤのみが含まれるグループテーブルで示されるグループ対戦の結果は非通知とする対戦結果通知手段をさらに有することを特徴とする請求項１または２に記載のゲームシステム。
4. 前記登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザＩＤに関連付けて管理するログイン管理手段をさらに有し、
   前記分類手段は、ユーザＩＤに関連付けられている前記ログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザＩＤをグループテーブルに追加しないことにより、当該ユーザを前記リーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザＩＤに関連付け、
   前記階級付与手段は、前記フラグが関連付けられたユーザＩＤについて前記ログイン管理手段がログイン要求を受け付けた後に、前記予め定められた種類の階級のうちの最下位の階級を示す階級ＩＤを当該ユーザＩＤに関連付けるともに、当該フラグの関連付けを削除する
   ことを特徴とする請求項１乃至３のいずれか１項に記載のゲームシステム。
5. 前記リーグ戦は所定の開催期間をシーズンとして定義し、少なくとも最後に終了したシーズンのリーグ戦に参加していたユーザの各々について、当該最後に終了したシーズンのリーグ戦に参加していたことを示すフラグをユーザＩＤに関連付ける参加管理手段をさらに有し、
   前記登録手段は、ユーザの前記ユーザ管理データベースへの登録を時系列順に管理しており、
   前記分類手段は、各階級について、当該階級の階級ＩＤが関連付けられたユーザＩＤの数が、当該階級について予め定められたグループ上限数のグループテーブルに追加できるユーザＩＤの数を超える場合、当該階級の階級ＩＤが関連付けられたユーザＩＤのうち、前記最後に終了したシーズンのリーグ戦に参加していたことを示すフラグが関連付けられているユーザＩＤを優先的にグループテーブルに追加した後、前記最後に終了したシーズンのリーグ戦に参加していたことを示すフラグが関連付けられていないユーザＩＤを、前記ユーザ管理データベースに登録された順に当該グループテーブルに追加する
   ことを特徴とする請求項１乃至４のいずれか１項に記載のゲームシステム。
6. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムの制御方法であって、
   前記ゲームシステムの登録手段が、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録工程と、
   前記ゲームシステムの階級付与手段が、前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与工程と、
   前記ゲームシステムのグループ生成手段が、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成工程と、
   前記ゲームシステムの分類手段が、前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類工程と、を有し、
   前記登録されているユーザは、ユーザ端末より前記登録要求を受け付けて前記ユーザ管理データベースに登録された実ユーザと、前記登録要求を受けずに前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザとで構成され、
   前記分類工程において前記分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加する
   ことを特徴とするゲームシステムの制御方法。
7. コンピュータを、請求項１乃至５のいずれか１項に記載のゲームシステムの各手段として機能させるためのプログラム。
8. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、
   前記登録されているユーザは、ユーザ端末より登録要求を受け付けてユーザ管理データベースに登録された実ユーザと、前記登録要求を受けずに前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザとで構成され、
   前記ゲームシステムは、表示手段に表示するユーザインタフェースにおいて
   登録要求を行なったユーザに割り当てられた、前記ユーザ管理データベースにおける固有のユーザＩＤを示すユーザＩＤ表示部と、
   前記登録要求を行なったユーザに付与された、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級表示部と、
   前記各グループに分類されたユーザのユーザＩＤを通知するグループメンバリストであって、予め定められた実ユーザ下限数以上の実ユーザのユーザＩＤが含まれるグループメンバリストを表示するグループメンバ表示部と、
   前記ユーザ同士の対戦のうち、実ユーザが含まれるグループにおける対戦結果は表示して、仮想ユーザのみが含まれるグループにおける対戦の結果は非表示とする対戦結果表示部と、
   を有することを特徴とするゲームシステム。