JP2013176623A - サーバシステム - Google Patents

Abstract

【課題】ネットワークゲームシステムにおいて、マッチングの待ち時間にかかる問題を解決する新たな手法を実現すること。
【解決手段】ゲームシステム１では、第１のオンラインゲームであるＭＭＯＲＰＧと、第２のオンラインゲームであるＭＯＲＰＧとが行われる。すなわち、ゲーム端末２０においてプレーヤがゲームシステム１にログインすると、先ずはＭＭＯＲＰＧに参加する。それとともに、設定したマッチング条件を満たすようにＭＯＲＰＧのためのマッチング処理が行われる。そして、マッチングが完了すると、現在参加しているＭＭＯＲＰＧからＭＯＲＰＧに移行する。このとき、プレーヤキャラクタは２つのゲーム世界で共通であり、ＭＭＯＲＰＧのゲーム世界からＭＯＲＰＧのゲーム世界にそのまま移行する。
【選択図】図１

Description

本発明は、サーバシステムに関する。

従来、ゲームの一形態として、サーバシステムに通信ネットワークを介して複数のゲーム端末が接続して構成されるネットワークゲームシステムが（オンラインゲームシステム）知られている。ネットワークゲーム（オンラインゲームシステム）では、サーバシステムにおいて、現在接続しているプレーヤの中から任意の数のプレーヤ同士を組み合わせるマッチング処理を行い、マッチングされたプレーヤ同士で同一のゲーム空間を共有したゲームを行わせる（例えば、特許文献１参照）。

特開２００６−４３０９９号公報

上述のようなネットワークゲームでは、必ずマッチングが完了するまでの待ち時間が生じる。そこで、どのようにマッチングを行えばマッチングの待ち時間を短縮することができるかについて開発・研究されていた。その１つとして、例えば特許文献１のように、マッチングの待ち時間の短縮を優先させて、マッチング条件を満たさない場合であってもマッチングしてしまう方法も考えられている。しかし、かかる方法では、マッチング条件を満たしたマッチングとなっていない。また、マッチングの待ち時間が長い短いといった感じ方は人それぞれであり、単に待ち時間を短縮すればよいものでもなかった。本発明は上記事情に鑑みてなされたものであり、ネットワークゲームシステムにおいて、マッチングの待ち時間にかかる問題を解決するための新たな手法を実現することを目的としている。

上記課題を解決するための第１の発明は、
ゲーム端末と通信接続されるサーバシステム（例えば、図１のサーバシステム３０）であって、
各プレーヤのプレーヤキャラクタと、ゲームの進行に応じて変更される当該プレーヤキャラクタのパラメータ値とを対応付けて記憶する記憶手段（例えば、図５のプレーヤＤＢ４４１）と、
前記ゲーム端末と所定通信を行って新プレーヤのログイン処理を行うログイン処理手段（例えば、図４のプレーヤ管理部４２１）と、
多数のプレーヤキャラクタを第１のゲーム空間に配置して参加型のマルチプレーヤ・オンラインゲームである第１のオンラインゲーム（例えば、実施形態の「ＭＭＯＲＰＧ」）を実行し、参加している各プレーヤのプレーヤキャラクタの前記パラメータ値を当該ゲームの進行に応じて更新するとともに、前記ログイン処理手段により新たなログイン処理がなされた場合には、ログイン処理された新プレーヤのプレーヤキャラクタを前記記憶手段から読み出して、前記第１のゲーム空間に配置して当該新プレーヤを第１のマルチプレーヤ・オンラインゲームに参加させる第１ゲーム処理手段（例えば、図４のＭＭＯＲＰＧ管理部４２２）と、
所与のマッチング条件に基づき、マッチング可能なプレーヤ同士を探索してグループを作成するマッチング処理を実行するマッチング処理手段（例えば、図１のマッチングサーバ５０）と、
前記マッチング処理手段により作成されたグループの各プレーヤのプレーヤキャラクタを前記第１のゲーム空間から消失させ、当該グループのプレーヤ同士のプレーヤキャラクタのみがプレーヤキャラクタとして存在するグループ毎に設定される第２のゲーム空間における第２のマルチプレーヤ・オンラインゲーム（例えば、実施形態の「ＭＯＲＰＧ」）に係る処理を実行し、当該プレーヤキャラクタの前記パラメータ値を当該ゲームの進行に応じて更新する第２ゲーム処理手段（例えば、図４のＭＯＲＰＧ管理部４２３）と、
を備えたサーバシステムである。

この第１の発明によれば、ログイン処理された新プレーヤのプレーヤキャラクタを第１のゲーム空間に配置して、当該新プレーヤを参加型のマルチプレーヤ・オンラインゲームである第１のオンラインゲームに参加させる。また、所与のマッチング条件に基づき、マッチング可能なプレーヤ同士を探索してグループを作成するマッチング処理が実行され、作成されたグループの各プレーヤのプレーヤキャラクタが第１のゲーム空間から消失され、当該グループのプレーヤ同士のプレーヤキャラクタのみがプレーヤキャラクタとして存在するグループ毎に設定される第２のゲーム空間における第２のマルチプレーヤ・オンラインゲームが実行される。つまり、ログインした新プレーヤは、先ず、プレーヤキャラクタが第１のゲーム世界に配置されて第１のオンラインゲームに参加し、マッチング処理によりグループが作成されると、プレーヤキャラクタが存在する第２のゲーム空間における第２のオンラインゲームを行うことになる。これにより、プレーヤは、マッチング処理によってグループが作成されるまでの時間（マッチングの待ち時間）を気にすることなく、ゲームを楽しむことができる。また、プレーヤキャラクタのパラメータ値は、第１のオンラインゲームの進行に応じて更新されるとともに、第２のオンラインゲームの進行に応じても更新される。これにより、第１のオンラインゲームが第２のオンラインゲームに移行する前の単なる時間つぶしのためのゲームではなく、互いに関連するゲームとして楽しむことができき、マッチングの待ち時間にかかる問題他を新たな方法で解決することができる。

第２の発明は、第１の発明のサーバシステムであって、
前記マッチング処理手段により作成されたグループの各プレーヤの各ゲーム端末に、前記第１のオンラインゲームから前記第２のオンラインゲームへの移行の許否を問い合わせる（例えば、「マッチング完了通知」）移行問合せ手段（例えば、図４のプレーヤ管理部４２１）を更に備え、
前記第２ゲーム処理手段は、前記移行問合せ手段による問合せの結果、容認回答が得られた（例えば、実施形態の「移行希望通知」）プレーヤ同士による前記第２のオンラインゲームに係る処理を実行する、
サーバシステムである。

この第２の発明によれば、マッチング処理によって作成されたグループの各プレーヤのゲーム端末に、第１のオンラインゲームから第２のオンラインゲームへの移行の許否の問い合わせが行われ、この問い合わせの結果、容認回答が得られたプレーヤ同士による第２のオンラインゲームが実行される。つまり、マッチング処理によって作成されたグループの各プレーヤのうち、第２のオンラインゲームへの移行を希望するプレーヤ同士によって第２のオンラインゲームが実行される。すなわち、マッチングされたグループで第２のオンラインゲームを行うかを、プレーヤの意志で決定することができる。

第３の発明は、第２の発明のサーバシステムであって、
前記第１ゲーム処理手段は、前記移行問合せ手段による問合せの結果、容認回答が得られなかった（例えば、実施形態の「移行許否通知」）プレーヤのプレーヤキャラクタを引き続き前記第１のゲーム空間に存在させて前記第１のオンラインゲームを実行するサーバシステムである。

この第３の発明によれば、第１のオンラインゲームから第２のオンラインゲームへの移行の許否の問い合わせの結果、容認回答が得られなかったプレーヤのプレーヤキャラクタを引き続き第１のゲーム空間に存在させて第１のオンラインゲームが実行される。つまり、第２のオンラインゲームへの移行を希望しないプレーヤについては、そのまま、第１のオンラインゲームを行うことができる。

第４の発明は、第１〜第３の何れかの発明のサーバシステムであって、
前記ログイン処理手段によりログイン処理されたプレーヤそれぞれのマッチング条件を前記ゲーム端末から受信して記憶するマッチング条件記憶手段（例えば、図６のマッチング要求リスト４５２）を更に備え、
前記マッチング処理手段は、前記マッチング条件記憶手段に記憶されたマッチング条件に基づき、マッチング可能なプレーヤ同士を探索してマッチング処理を実行する、
サーバシステムである。

この第４の発明によれば、ログイン処理されたプレーヤそれぞれのマッチング条件がゲーム端末から受信・記憶され、記憶されたマッチング条件に基づいてマッチング処理が実行される。これにより、例えばプレーヤによって入力されたマッチング条件に基づいて、マッチング処理が実行されてグループを作成することが可能となる。

第５の発明は、第４の発明のサーバシステムであって、
前記マッチング処理手段によるマッチングの待ち時間を前記各プレーヤ毎に管理する待ち時間管理手段（例えば、図６のマッチング要求リスト４５２）と、
前記待ち時間が一定時間に達したプレーヤのプレーヤ端末に、前記マッチング条件記憶手段に記憶されている当該プレーヤの前記マッチング条件の変更依頼をする（例えば、実施形態の「マッチング条件変更要求」）マッチング条件変更依頼手段（例えば、図４のプレーヤ管理部４２１）と、
前記マッチング条件変更依頼手段による依頼への応答信号（例えば、実施形態の「マッチング条件再通知」）に基づいて、対応するプレーヤの前記マッチング条件記憶手段に記憶されているマッチング条件を変更する条件変更手段（例えば、図４のプレーヤ管理部４２１）と、
を備えたサーバシステムである。

この第５の発明によれば、マッチングの待ち時間がプレーヤ毎に管理され、待ち時間が一定時間に達したプレーヤのプレーヤ端末に、当該プレーヤのマッチング条件の変更依頼がなされる。そして、この変更依頼への応答信号に基づいて、対応するプレーヤのマッチング条件が変更される。つまり、一定時間が経過してもマッチングが成立しないプレーヤに対してマッチング条件の変更が依頼され、マッチング条件が変更される。これにより、速やかにマッチング処理によるグループの作成を行わせ、プレーヤを第１のオンラインゲームから第２のオンラインゲームに移行させることが可能となる。

第６の発明は、第４の発明のサーバシステムであって、
前記マッチング処理手段によるマッチングの待ち時間を前記各プレーヤ毎に管理する待ち時間管理手段を更に備え、
前記マッチング条件記憶手段は、各プレーヤの前記マッチング条件として、優先順位づけされた所定数のマッチング条件を記憶し、
前記マッチング処理手段は、前記待ち時間管理手段により管理されている待ち時間に応じて、優先順位づけされて前記マッチング条件記憶手段に記憶された当該プレーヤのマッチング条件を切り替えて前記マッチング処理を実行する、
サーバシステムである。

この第６の発明によれば、マッチングの待ち時間がプレーヤ毎に管理されるとともに、各プレーヤのマッチング条件として優先順位づけされた所定数のマッチング条件が記憶され、管理されているマッチングの待ち時間に応じて、優先順位づけされて記憶されたプレーヤのマッチング条件を切り替えてマッチング処理が実行される。つまり、マッチングの待ち時間に応じて、優先順位づけされたマッチング条件が切り替えられる。これにより、例えばマッチングの待ち時間が所定時間に達すると、優先順位に従ってマッチング条件を切り替えるといったことで、速やかにマッチング処理によるグループの作成を行わせ、プレーヤを第１オンラインゲームから第２オンラインゲームに移行させることが可能となる。

第７の発明は、第１〜第６の何れかの発明のサーバシステムであって、
各プレーヤそれぞれのゲームプレイに対する課金処理の対象期間を、当該プレーヤの前記第２のオンラインゲームの実行開始をもって開始する課金処理手段を更に備えたサーバシステムである。

この第７の発明によれば、各プレーヤそれぞれのゲームプレイに対する課金処理の対象期間が、当該プレーヤの第２のオンラインゲームの実行開始をもって開始される。つまり、第２のオンラインゲームの実行に対して課金がなされる。

第８の発明は、第３の発明のサーバシステムであって、
各プレーヤそれぞれについて、前記移行問合せ手段による問合せに対する回答が、容認回答であったプレーヤについては当該プレーヤの前記第２のオンラインゲームの実行開始をもって当該プレーヤのゲームプレイに対する課金処理の対象期間を開始し、容認回答でなかったプレーヤについては当該回答をもって課金処理の対象期間を開始する課金処理手段を更に備えたサーバシステムである。

この第８の発明によれば、各プレーヤそれぞれについて、第１のオンラインゲームから第２のオンラインゲームへの移行の許否の問い合わせに対する回答が容認回答であったプレーヤについては、第２のオンラインゲームの実行開始をもってゲームプレイに対する課金処理の対象期間が開始され、容認回答でなかったプレーヤについては、当該回答をもって課金処理の対象期間が開始される。つまり、マッチング処理によってグループが作成されると、作成されたグループの各プレーヤは、第２のオンラインゲームに移行するか或いは第１のオンラインゲームを継続するかの何れかとなるが、どちらにしても、その時点から課金の対象となる。

ゲームシステムの構成図。 ゲームシステにおける通信接続の説明図。 ゲーム端末の機能構成図。 ゲームサーバの機能構成図。 プレーヤＤＢのデータ構成例。 マッチング要求リストのデータ構成例。 マッチングＤＢのデータ構成例。 プレーヤ戦用マッチングデータのデータ構成例。 敵キャラ戦用マッチングデータのデータ構成例。 マッチングサーバの機能構成図。 プレーヤ戦用待ちプレーヤリストのデータ構成例。 敵キャラ戦用待ちプレーヤリストのデータ構成例。 ゲーム処理のフローチャート。 ゲーム管理処理のフローチャート。 マッチング処理のフローチャート。

以下、図面を参照して、本発明の好適な実施形態を説明する。なお、以下では、本発明をネットワークゲームシステム（オンラインゲームシステム）に適用した場合を説明するが、本発明の適用可能な実施形態がこれに限定されるものではない。

［ゲームシステム］
図１は、本実施形態におけるゲームシステム１の構成図である。同図によれば、ゲームシステム１は、ゲーム端末２０と、サーバシステム３０と、プレーヤ端末６０とを備えて構成されるネットワークゲームシステムである。ゲーム端末２０とサーバシステム３０とは、通信回線Ｎ１を介して通信可能に接続されている。また、サーバシステム３０とプレーヤ端末６０とは、通信回線Ｎ２を介して通信可能に接続されている。ここで、通信回線Ｎ１，Ｎ２とは、データ授受が可能な通信路を意味する。即ち、通信回線Ｎとは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮの他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。また、通信回線Ｎ１，Ｎ２は、それぞれ異なる通信網であっても同一の通信網であっても構わない。

ゲーム端末２０は、ゲームセンタ等の店舗に設置されてプレーヤがゲームプレイを行うための端末装置であり、例えば業務用のゲーム装置で実現される。本実施形態では、ゲーム端末２０では、ネットワークゲーム（オンラインゲーム）の一種であるＭＭＯＲＰＧ（Massively Multi-player Online Role-Playing Game）及びＭＯＲＰＧ（Multi-player Online Role-Playing Game）の２種類のゲームが行われる。

また、本実施形態のゲームシステム１では、ゲームカード１０を所有しゲームシステム１に登録することで、プレーヤキャラクタや保有するアイテム等のプレイデータを保持しておくことができ、どの店舗のどのゲーム端末２０においても、自分のオリジナルなプレーヤキャラクタを用いてゲームプレイを楽しむことができる。勿論、ゲームカード１０を用いなくともゲームプレイを行うことができる。ここで、ゲームカード１０は、販売等によって事前にプレーヤに提供されるものであり、例えば固有のカードＩＤが記憶されたＩＣチップを内蔵するＩＣカードにより実現される。

サーバシステム３０は、ゲームシステム１の運営会社側に設置・管理され、公知のサーバコンピュータを用いて実現される。また、サーバシステム３０は、ゲームサーバ４０と、マッチングサーバ５０とから構成される。なお、ゲームサーバ４０とマッチングサーバ５０とは、独立したサーバとして構成されても良いし、同一のサーバとして構成されても良い。

ゲームサーバ４０は、ゲームシステム１にて行われるゲーム（ＭＭＯＲＰＧ及びＭＯＲＰＧ）を管理する。「ＭＭＯＲＰＧ」は、常に存在する１つのゲーム世界において、数百人から数千人規模のプレーヤが自分のプレーヤキャラクタを操作して楽しむ参加型のマルチプレーヤ・オンラインゲームである。このＭＭＯＲＰＧへの参加／退出は、任意のタイミングで可能である。また、「ＭＯＲＰＧ」は、比較的少人数（数名〜十数名程度）のプレーヤから構成されるグループそれぞれが、互いに独立したゲーム世界で楽しむマルチプレーヤ・オンラインゲームである。あるグループでのゲームが終了すると、該当するゲーム世界は消去される。

マッチングサーバ５０は、ＭＯＲＰＧのために、マッチング条件を満たすようにプレーヤ同士を組み合わせてグループを形成するマッチング処理を行う。

プレーヤ端末６０は、プレーヤがサーバシステム３０から提供されるサービスを受けるための端末装置であり、例えばプレーヤが所有する携帯電話機やＰＣ等である。具体的には、プレーヤ端末６０は、ブラウザプログラムを起動してゲーム運営会社により開設されているホームページにアクセスすることで、サーバシステム３０にて管理されている当該プレーヤのプレーヤデータを閲覧することができる。

［ゲーム概要］
本実施形態におけるネットワークゲームの概要を説明する。本実施形態では、ＭＭＯＲＰＧ及びＭＯＲＰＧの２種類のゲームを楽しむことができる。また、各ゲームにおいて、共通のプレーヤキャラクタが用いられる。このプレーヤキャラクタは、予め定められた２つの勢力Ａ，Ｂの何れかに属する。所属する勢力は、プレーヤキャラクタの生成時に決定される。

具体的には、ゲームシステム１にログインすると、先ずはＭＭＯＲＰＧに参加する。このＭＭＯＲＰＧでは、全てのプレーヤで共通のゲーム世界において、自分のプレーヤキャラクタを操作してゲームを楽しむ。このＭＭＯＲＰＧでは、２つの勢力のプレーヤ同士が対戦する集団対集団の大規模な対人戦闘が行われる。その後、ＭＯＲＰＧのためのマッチングが完了すると、ＭＭＯＲＰＧから退出してＭＯＲＰＧに参加（移行）することになる。ＭＯＲＰＧでは、プレーヤは、同じ勢力の所定数（例えば、数人程度）のプレーヤ同士で形成されたグループ（自グループ）が、他勢力のグループと対戦する「プレーヤ戦」や、コンピュータ制御される敵キャラクタと対戦する「敵キャラ戦」を楽しむ。また、２つのゲーム世界（ＭＭＯＲＰＧ及びＭＯＲＰＧ）において、プレーヤキャラクタは共通である。つまり、自身のプレーヤキャラクタは、ＭＭＯＲＰＧのゲーム世界から、そのままＭＯＲＰＧに移行する。そして、各ゲームでのプレイ結果が、体力値の増減や獲得された経験値といったキャラクタのパラメータに反映される。

また、本実施形態において、ゲームシステム１におけるゲームサーバ４０とゲーム端末２０との接続形態は、ＭＭＯＲＰＧとＭＯＲＰＧとでは異なる。

図２（ａ）は、ＭＭＯＲＰＧの実行中のシステム構成を示す図である。同図（ａ）に示すように、ＭＭＯＲＰＧでは、ゲーム世界を管理しているゲームサーバ４０に、ＭＭＯＲＰＧに参加している全てのプレーヤのゲーム端末２０が通信接続される。そして、各ゲーム端末２０がゲームサーバ４０と通信を行うことで、ＭＭＯＲＰＧが実現される。

また、同図（ｂ）は、ＭＯＲＰＧの実行中のシステム構成を示す図である。同図（ｂ）に示すように、ＭＯＲＰＧでは、マッチングされた複数のゲーム端末２０のうち、１台が「ホスト」の機能を有するとともに、他のゲーム端末２０が「クライアント」となり、ホストであるゲーム端末２０にクライアントである各ゲーム端末２０が通信接続されたシステム構成となる。すなわち、マッチングされた各ゲーム端末２０はゲームサーバ４０から独立し、ホストとクライアントという２台のゲーム端末２０のピア・ツー・ピア型の直接接続によって実現される。そして、クライアントである各ゲーム端末２０がホストであるゲーム端末２０と通信を行うことで、ＭＯＲＰＧが実現される。具体的には、クライアントの各ゲーム端末２０で入力された操作情報が、一旦ホストのゲーム端末２０に集約された後、このホストのゲーム端末２０からクライアントの各ゲーム端末２０に配信されることでゲームの進行時間の同期が図られる。このとき、コンピュータ制御のキャラクタの制御データもホストのゲーム端末２０によって生成され、クライアントの各ゲーム端末２０に配信される。なお、ホストのゲーム端末２０はクライアントの機能も実現し、一台二役となる。

［ゲーム端末］
図３は、ゲーム端末２０の機能構成を示すブロック図である。同図によれば、ゲーム端末２０は、機能的には、操作入力部２１１と、カードリーダ／ライタ２１２と、処理部２２０と、画像表示部２１３と、音出力部２１４と、通信部２１５と、コイン検知部２１６と、記憶部２３０とを備えて構成される。

操作入力部２１１は、プレーヤの操作指示を受け付け、操作に応じた操作信号を処理部２２０に出力する。この機能は、例えばボタンスイッチやレバー、マウス、キーボード、タッチパネル、各種センサによって実現される。

カードリーダ／ライタ２１２は、挿入されたゲームカード１０に記録されているカードデータ１２を読み出し、読み出したデータを処理部２２０に出力するとともに、処理部２２０からの書き込み指示に従って、ゲームカード１０のカードデータ１２を更新する。カードデータ１２には、当該ゲームカード１０のカードＩＤや、所有者であるプレーヤのプレーヤＩＤ及びプレーヤ名、プレーヤキャラクタのデータ等が含まれる。

処理部２２０は、記憶部２３０から読み出したプログラムやデータ、操作入力部２１１から入力された操作信号、カードリーダ／ライタ２１２で読み出されたデータ等に基づいて、ゲーム端末２０の全体制御やゲーム進行、画像生成等の各種演算処理を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型やＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）等の演算装置やその制御プログラムで実現される。また、処理部２２０は、主にゲームの実行に係る演算処理を行うゲーム演算部２２１と、ゲーム演算部２２１の処理によって求められた各種のデータに基づきゲーム画像を生成する画像生成部２２３と、効果音やＢＧＭ等のゲーム音を生成する音生成部２２４とを含んでいる。

ゲーム演算部２２１は、ゲームプログラム２３１に従ったゲーム処理を行う。このゲーム処理では、ゲームサーバ４０或いは他のゲーム端末２０と通信を行うことで、ＭＭＯＲＰＧ及びＭＯＲＰＧを行う。

具体的には、ゲームシステム１にログインすると、先ず、操作入力部２１１から入力されるプレーヤの操作指示に従って、ＭＯＲＰＧにおけるマッチング条件を選択する。マッチング条件には、「対戦種別」及び「対戦条件」が含まれる。対戦種別は、プレーヤグループと対戦する「プレーヤ戦」、或いはコンピュータ制御の敵グループと対戦する「敵キャラ戦」の何れかである対戦条件は対戦種別に応じて異なり、プレーヤ戦ならば「自グループ条件」及び「相手グループ条件」であり、敵キャラ戦ならば「自グループ条件」及び「敵キャラ条件」である。

自グループ条件は、自プレーヤキャラクタが含まれるグループの条件であり、具体的には、自プレーヤキャラクタのレベルに近い（例えば、レベル差が±１以内）を含む、或いは自グループの平均レベルが所定レベル以上といったプレーヤキャラクタのレベルに関する条件や、自プレーヤキャラクタと同じ職業のプレーヤキャラクタを含むといったプレーヤキャラクタの職業に関する条件である。また、相手グループ条件は、自グループと対戦する他勢力のプレーヤグループ（相手グループ）の条件であり、具体的には、平均レベルが自グループの平均レベルと近い（例えば、平均レベル差が±２以内）といったプレーヤキャラクタのレベルに関する条件や、自プレーヤキャラクタと同じ職業のプレーヤが含まれるといったプレーヤキャラクタの職業に関する条件である。また、敵キャラ条件は、自グループと対戦する敵キャラクタの条件であり、具体的には、各敵キャラクタのレベルが自グループの平均レベル以下といった、キャラクタのレベルに関する条件である。これらのマッチング条件は、例えば、予め定められた複数の選択肢のうちから１つを選択して入力される。

次いで、選択したマッチング条件を、自ゲーム端末２０の端末ＩＤや設置店舗ＩＤ、ゲームカードから読み出したカードＩＤやプレーヤＩＤとともに、ゲームサーバ４０に通知する。また、ゲームサーバ４０と通信を行ってＭＭＯＲＰＧを実行するＭＭＯＲＰＧ処理を開始する。

そして、ゲームサーバ４０からマッチング要求に応答したマッチング完了通知を受信すると、操作入力部２１１から入力されるプレーヤの操作指示に従って、ＭＯＲＰＧに移行するか否かを選択する。ＭＯＲＰＧに移行するならば、「移行希望通知」をゲームサーバ４０に送信し、続いてゲームサーバ４０から送信されてくるマッチングデータをもとに、他のゲーム端末２０との通信を行ってＭＯＲＰＧを実行するＭＯＲＰＧ処理を行う。一方、ＭＯＲＰＧに移行しないならば、「移行拒否通知」をゲームサーバ４０に送信する。そして、マッチング完了通知の受信から所定時間（例えば、１０分）が経過した後、ＭＭＯＲＰＧ処理を終了する。

画像表示部２１３は、画像生成部２２３からの画像信号に基づいて、例えば１／６０秒毎に１フレームの画像を再描画しながらゲーム画面を表示する。この機能は、例えばＣＲＴやＬＣＤ、ＥＬＤ、ＰＤＰ等の表示装置によって実現される。音出力部２１４は、音生成部２２４からの音信号に基づいてＢＧＭや効果音等のゲーム音声を出力する。この機能は、例えばスピーカによって実現される。

通信部２１５は、処理部２２０からの制御信号に従って通信回線Ｎ１に接続し、外部装置（サーバシステム３０や他のゲーム端末２０）との間でデータ通信を行う。この機能は、無線通信モジュールやＴＡ、ルータ、有線用の通信ケーブルのジャックや制御回路等によって実現される。コイン検知部２１６は、ゲーム対価として投入される硬貨（コイン）の種類や数を検知し、検知信号を処理部２２０に出力する。

記憶部２３０は、処理部２２０にゲーム端末２０を統合的に制御させるための諸機能を実現するためのシステムプログラムや、本実施形態における各種機能を実現するためのプログラムやデータ等を記憶するとともに、処理部２２０の作業領域として用いられ、処理部２２０が各種プログラムに従って実行した演算結果や操作入力部２１１からの入力データ等を一時的に記憶する。この機能は、例えば各種ＩＣメモリやハードディスク、ＭＯ、ＲＯＭ、ＲＡＭ等によって実現される。本実施形態では、記憶部２３０には、ゲームプログラム２３１が記憶されるとともに、当該ゲーム端末２０の端末ＩＤ２３２と、設置店舗の店舗ＩＤ２３３とが記憶されている。

［ゲームサーバ］
図４は、ゲームサーバ４０の機能構成を示すブロック図である。同図によれば、ゲームサーバ４０は、機能的には、操作部４１１と、処理部４２０と、表示部４１２と、通信部４１３と、記憶部４３０とを備えて構成される。

操作部４１１は、ゲームサーバ４０の管理者による操作指示を受け付け、操作指示に応じた操作信号を処理部４２０に出力する。この機能は、例えばボタンスイッチやレバー、キーボード、マウス、タッチパネル、各種センサ等によって実現される。

処理部４２０は、記憶部４３０に記憶されているプログラムやデータ、操作部４１１から入力された操作信号、通信部４１３を介して外部装置（主に、ゲーム端末２０やマッチングサーバ５０）から受信したデータ等に基づいて、ゲームサーバ４０の全体制御を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型やＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）等の演算装置やその制御プログラムによって実現される。本実施形態では、処理部４２０は、プレーヤ管理部４２１と、ＭＭＯＲＰＧ管理部４２２と、ＭＯＲＰＧ管理部４２３とを含む。

プレーヤ管理部４２１は、ゲームシステム１に登録されているプレーヤを、プレーヤＤＢ４４１によって管理する。

図５は、プレーヤＤＢ４４１のデータ構成の一例を示す図である。同図によれば、プレーヤＤＢ４４１は、登録されているプレーヤそれぞれについての複数のプレーヤデータ４４２から構成される。プレーヤデータ４４２は、該当するプレーヤのプレーヤＩＤ４４２ａ及びプレーヤ名４４２ｂと、所有するゲームカード１０のカードＩＤ４４２ｃと、所属勢力４４２ｄと、プレーヤキャラデータ４４３とを格納している。プレーヤキャラデータ４４３は、プレーヤキャラクタのキャラクタＩＤ４４３ａ及びキャラクタ名４４３ｂと、レベル４４３ｃと、経験値４４３ｄと、職業４４３ｅとを格納している。

また、プレーヤ管理部４２１は、ゲーム端末２０から「マッチング条件通知」を受信すると、このマッチング条件にもとづく「マッチング要求」をマッチングサーバ５０に送信する。そして、このマッチング要求から所定時間（例えば、５分）が経過しても、当該要求にマッチング結果がマッチングサーバ５０から受信されない場合には、該当するプレーヤのゲーム端末２０に対して、対戦条件の変更を要求する「対戦条件変更要求」を送信する。

要求したマッチングについてのデータは、マッチング要求リスト４５２に格納される。図６は、マッチング要求リスト４５２の一例を示す図である。同図によれば、マッチング要求リスト４５２は、マッチングサーバ５０に対して行ったマッチング要求それぞれについて、要求を行った日時４５２ａと、プレーヤＩＤ４５２ｂ及びプレーヤ名４５２ｃと、店舗４５２ｄ及びゲーム端末２０の端末ＩＤ４５２ｅと、マッチング条件４５２ｆとを対応付けて格納している。マッチング条件４５２ｆは、対戦種別と、対戦条件とを含んでいる。

また、プレーヤ管理部４２１は、各プレーヤのＭＭＯＲＰＧからＭＯＲＰＧへの移行を管理する。具体的には、マッチングサーバ５０からのマッチング結果をもとに、マッチングされた各ゲーム端末２０に対して、マッチングが完了したのでＭＯＲＰＧに移行（参加）するか否かを問う「マッチング完了通知」を送信する。次いで、この通知に応答して、各ゲーム端末２０からから送信されてくる、ＭＯＲＰＧに移行する旨の「移行希望通知」、或いはＭＯＲＰＧに移行しない旨の「移行拒否通知」を受信する。

各ゲーム端末２０からの移行希望／許否通知を受信すると、マッチングされたゲーム端末２０のうち、移行拒否通知を送信してきたゲーム端末２０を除くゲーム端末２０でマッチングを確定する。続いて、マッチングを確定したゲーム端末２０のうちから１台のゲーム端末２０を選択し、「ホスト」として決定する。ここで、ホストは、何れのゲーム端末２０でも良いが、例えば１番最初に「移行希望通知」が受信されたゲーム端末２０とする。そして、マッチングを確定した各ゲーム端末２０に、マッチングした各ゲーム端末２０の端末ＩＤや通信アドレス、そのプレーヤ、ホスト等のデータを含むマッチングデータを送信する。

確定されたマッチングについてのデータは、マッチングＤＢ４６１に格納される。図７は、マッチングＤＢ４６１のデータ構成の一例を示す図である。マッチングＤＢ４６１は、成立しているマッチングそれぞれについてのマッチングデータであって、「プレーヤ戦」のマッチングについてのプレーヤ戦用マッチングデータ４６２と、「敵キャラ戦」のマッチングについての敵キャラ戦用マッチングデータ４６４とから構成される。

図８は、プレーヤ戦用マッチングデータ４６２のデータ構成の一例を示す図である。同図によれば、プレーヤ戦用マッチングデータ４６２は、当該マッチングを識別するマッチングＩＤ４６２ａと、対戦の舞台となるバトルフィールドのＩＤ４６２ｂと、互いに対戦する勢力Ａ，Ｂそれぞれのプレーヤグループについてのプレーヤグループデータ４６３とを格納している。プレーヤグループデータ４６３は、当該グループに含まれるプレーヤそれぞれについて、プレーヤＩＤ４６３ａ及びプレーヤ名４６３ｂと、ゲームを行っている店舗４６３ｃ及びゲーム端末２０の端末ＩＤ４６３ｄと、ホストフラグ４６３ｅとを対応付けて格納している。ホストフラグ４６３ｅは、当該ゲーム端末２０をホストとするかを指定するフラグである。マッチングされた両勢力Ａ，Ｂのゲーム端末２０のうちの１台がホストとなり、それ以外がクライアントとなる。

図９は、敵キャラ戦用マッチングデータ４６４のデータ構成の一例を示す図である。同図によれば、敵キャラ戦用マッチングデータ４６４は、当該マッチングを識別するマッチングＩＤ４６４ａと、バトルフィールド４６４ｂと、プレーヤグループデータ４６５と、敵グループデータ４６６とを格納している。敵グループデータ４６６は、プレーヤグループと対戦する敵グループのデータであり、当該敵グループのグループＩＤ４６６ａと、含まれる敵キャラクタのキャラクタＩＤ４６６ｂ及びキャラクタ名４６６ｃとを対応付けて格納している。

ＭＭＯＲＰＧ管理部４２２は、ＭＭＯＲＰＧを制御する。具体的には、常に存在する１つのゲーム世界を構築し、参加している各ゲーム端末２０と通信を行って当該ゲーム端末２０のプレーヤのプレーヤキャラクタを当該ゲーム世界に配置・制御することで、各ゲーム端末２０でのＭＭＯＲＰＧを制御する。ここで、ＭＭＯＲＰＧに参加しているプレーヤは、ＭＭＯＲＰＧ参加プレーヤリスト４５１に格納されている。

ＭＯＲＰＧ管理部４２３は、ＭＯＲＰＧを制御する。具体的には、マッチングサーバ５０によりマッチングが成立されたゲーム端末２０同士を通信接続させて共通のゲーム世界を構築させ、このゲーム世界におけるＲＰＧ（ＭＯＲＰＧ）を実行させる。

表示部４１２は、処理部４２０からの表示信号に基づく表示画面を表示する。この機能は、例えばＣＲＴやＬＣＤ、ＥＬＤ、ＰＤＰ等の表示装置によって実現される。通信部４１３は、処理部４２０からの制御信号に従って通信回線Ｎ１，Ｎ２に接続し、外部装置（主に、ゲーム端末２０やマッチングサーバ５０）とのデータ通信を行う。この機能は、無線通信モジュールやＴＡ、ルータ、有線用の通信ケーブルのジャックや制御回路等によって実現される。

記憶部４３０は、処理部４２０にゲームサーバ４０を統合的に制御させるためのシステムプログラムや、本実施形態における各種機能を実現するためのプログラムやデータ等を記憶するとともに、処理部４２０の作業領域として用いられ、処理部４２０が各種プログラムに従って実行した演算結果や操作部４１１からの入力データ等を一時的に記憶する。この機能は、例えばＩＣメモリやハードディスク、ＭＯ、ＲＡＭ、ＶＲＡＭ、ＣＤ−ＲＯＭ等によって実現される。本実施形態では、記憶部４３０には、プログラムとしてゲーム管理プログラム４３１が記憶されるとともに、データとして、プレーヤＤＢ４４１と、マッチング要求リスト４５２と、ＭＭＯＲＰＧ参加プレーヤリスト４５１と、マッチングＤＢ４６１とが記憶される。

［マッチングサーバ］
図１０は、マッチングサーバ５０の機能構成を示すブロック図である。同図によれば、マッチングサーバ５０は、機能的には、操作部５１１と、処理部５２０と、表示部５１２と、通信部５１３と、記憶部５３０とを備えて構成される。

操作部５１１は、マッチングサーバ５０の管理者による操作指示を受け付け、操作指示に応じた操作信号を処理部５２０に出力する。この機能は、例えばボタンスイッチやレバー、キーボード、マウス、タッチパネル、各種センサ等によって実現される。

処理部５２０は、記憶部５３０に記憶されているプログラムやデータ、操作部５１１から入力された操作信号、通信部５１３を介して外部装置（主に、ゲームサーバ４０）から受信したデータ等に基づいて、マッチングサーバ５０の全体制御を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型やＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）等の演算装置やその制御プログラムによって実現される。本実施形態では、処理部５２０は、マッチング部５２１を含む。

マッチング部５２１は、ゲームサーバ４０からのマッチング要求に応じて、要求されたマッチング条件を満足するようにゲーム端末２０をマッチングさせる。具体的には、ゲームサーバ４０からマッチング要求を受信すると、要求されたマッチングの対戦種別を判断する。

対戦種別が「プレーヤ戦」ならば、該当するプレーヤをプレーヤ戦用待ちプレーヤリスト５４２に追加する。図１１は、プレーヤ戦用待ちプレーヤリスト５４２のデータ構成の一例を示す図である。同図によれば、プレーヤ戦用待ちプレーヤリスト５４２は、勢力Ａ，Ｂそれぞれについて、待ちプレーヤそれぞれのプレーヤＩＤ５４２ａ及びプレーヤ名５４２ｂと、ゲームプレイを行っている店舗５４２ｃ及びゲーム端末２０の端末ＩＤ５４２ｄと、対戦条件５４２ｅとを対応付けて格納している。対戦条件５４２ｅは、自グループ条件及び相手グループ条件である。

マッチング部５２１は、勢力Ａ，Ｂそれぞれについて、各待ちプレーヤの自グループ条件を満たすよう、所定数（例えば、５〜１０人）の待ちプレーヤで構成されるグループ候補を生成する。ここで、１人の待ちプレーヤが異なるグループ候補に含まれていても良い。そして、生成した各勢力のグループ候補のうち、異なるグループ候補同士の組合せであって各プレーヤの相手グループ条件を満たす組合せを選出し、マッチングを成立させる。

また、マッチング部５２１は、要求された対戦種別が「敵キャラ戦」ならば、該当するプレーヤを敵キャラ戦用待ちプレーヤリスト５４３に追加する。図１２は、敵キャラ戦用待ちプレーヤリスト５４３のデータ構成の一例を示す図である。同図によれば、敵キャラ戦用待ちプレーヤリスト５４３は、勢力Ａ，Ｂそれぞれについて、待ちプレーヤそれぞれのプレーヤＩＤ５４３ａ及びプレーヤ名５４３ｂと、店舗５４３ｃ及びゲーム端末２０の端末ＩＤ５４３ｄと、対戦条件５４３ｅとを対応付けて格納している。対戦条件５４３ｅは、自グループ条件及び敵キャラ条件である。

マッチング部５２１は、当該プレーヤの所属勢力について、各待ちプレーヤの自グループ条件を満たすよう、所定数（例えば、５〜１０人）の待ちプレーヤで構成されるグループ候補を生成する。次いで、生成したグループ候補それぞれと敵グループとの組合せであって、各プレーヤの敵キャラ条件を満たす組合せを選出し、マッチングを成立させる。「敵グループ」は、１又は複数の敵キャラクタで構成されるグループであり、敵キャラＤＢ５４１にて予め定められている。マッチングを成立させると、マッチングさせた各ゲーム端末２０に、マッチングさせた各ゲーム端末２０やその設置店舗、プレーヤ、敵グループ等のデータを含むマッチング結果を送信する。

表示部５１２は、処理部５２０からの表示信号に基づく表示画面を表示する。この機能は、例えばＣＲＴやＬＣＤ、ＥＬＤ、ＰＤＰ等の表示装置によって実現される。通信部５１３は、処理部５２０からの制御信号に従って通信回線Ｎ１，Ｎ２に接続し、外部装置（主に、ゲームサーバ４０）とのデータ通信を行う。この機能は、無線通信モジュールやＴＡ、ルータ、有線用の通信ケーブルのジャックや制御回路等によって実現される。

記憶部５３０は、処理部５２０にマッチングサーバ５０を統合的に制御させるためのシステムプログラムや、本実施形態における各種機能を実現するためのプログラムやデータ等を記憶するとともに、処理部５２０の作業領域として用いられ、処理部５２０が各種プログラムに従って実行した演算結果や操作部５１１からの入力データ等を一時的に記憶する。この機能は、例えばＩＣメモリやハードディスク、ＭＯ、ＲＡＭ、ＶＲＡＭ、ＣＤ−ＲＯＭ等によって実現される。本実施形態では、記憶部５３０には、プログラムとしてマッチングプログラム５３１が記憶されるとともに、データとして、敵キャラＤＢ５４１と、プレーヤ戦用待ちプレーヤリスト５４２と、敵キャラ戦用待ちプレーヤリスト５４３とが記憶される。

［処理の流れ］
（Ａ）ゲーム処理
図１３は、ゲーム端末２０におけるゲーム処理の流れを説明するフローチャートである。同図によれば、ゲーム演算部２２１は、先ずログイン処理を行う（ステップＡ１）。このログイン処理は、挿入されたゲームカード１０に記録されているカードデータを読み出し、読み出したカードＩＤやプレーヤＩＤをもとに、ゲームサーバ４０にプレーヤの認証を要求する処理である。

ログイン処理が終了し、所定のゲーム対価が投入されると（ステップＡ３）、次いで、プレーヤの入力指示に従って、ＭＯＲＰＧにおけるマッチング条件を選択する（ステップＡ５）。すなわち、対戦種別（プレーヤ戦／敵キャラ戦）を選択し、続いて、選択した対戦種別に応じた対戦条件（自グループ条件や相手グループ条件、敵キャラ条件）を選択する。そして、選択したマッチング条件を、自ゲーム端末ＩＤや設置店舗ＩＤ、ゲームカード１０から読み出したカードＩＤやプレーヤＩＤとともに、ゲームサーバ４０に通知する（ステップＡ７）。

その後、ゲームサーバ４０と通信を行ってＭＭＯＲＰＧ処理を開始し、ＭＭＯＲＰＧに参加する（ステップＡ９）。ＭＭＯＲＰＧに参加中、ゲームサーバ４０から「マッチング条件変更要求」を受信すると（ステップＡ１１：ＹＥＳ）、ゲーム演算部２２１は、プレーヤの入力指示に従って、現在のマッチング条件を変更するか否かを選択する。マッチング条件を変更するならば（ステップＡ１３：ＹＥＳ）、プレーヤの操作入力に従ってマッチング条件を変更する（ステップＡ１５）。このマッチング条件の変更は、対戦種別及び対戦条件の変更を含む。そして、変更後のマッチング条件をゲームサーバ４０に再通知する（ステップＡ１７）。

また、ゲームサーバ４０から「マッチング完了通知」を受信すると（ステップＡ１９：ＹＥＳ）、プレーヤの入力指示に従ってＭＯＲＰＧに移行するかを決定する。ＭＯＲＰＧに移行するならば（ステップＡ２１：ＹＥＳ）、「移行希望通知」をゲームサーバ４０に送信する（ステップＡ２７）。次いで、ゲームサーバ４０から送信されてくるマッチングデータを受信する（ステップＡ２９）。

続いて、受信したマッチングデータをもとに、自ゲーム端末２０が「ホスト」であるか「クライアント」であるかを判断し、マッチングされた他のゲーム端末２０との通信接続を確立する（ステップＡ３１）。そして、実行中のＭＭＯＲＧＰ処理を終了してＭＭＯＲＰＧから退出した後（ステップＡ３３）、マッチングされた他のゲーム端末２０との通信を行ってＭＯＲＰＧ処理を実行するとともに、このＭＯＲＰＧ処理の開始時点を、ゲームプレイに対する課金対象期間の開始時点とする（ステップＡ３５）。ＭＯＲＰＧ処理が終了すると、続いて、当該ＭＯＲＰＧのプレイ結果をゲームサーバ４０に通知する（ステップＡ３７）。

一方、ＭＯＲＰＧに移行しないならば（ステップＡ２１：ＮＯ）、ゲーム演算部２２１は、「移行拒否通知」をゲームサーバ４０に送信する（ステップＡ２３）。そして、マッチング完了通知の受信時点を課金対象期間の開始時点として、当該時点からの経過時間が所定時間（例えば、１０分）に達すると（ステップＡ２５：ＹＥＳ）、課金対象期間の終了と判断して、ＭＭＯＲＰＧ処理を終了してＭＭＯＲＰＧから退出する。

ＭＭＯＲＰＧ処理／ＭＯＲＰＧ処理を終了すると、プレイ結果を画像表示部２１３に表示させるとともに（ステップＡ３９）、プレイ結果をもとにゲームカード１０のカードデータを更新し（ステップＡ４１）、ゲームカード１０を排出させる（ステップＡ４３）。以上の処理を行うと、ゲーム処理を終了する。

（Ｂ）ゲーム管理処理
図１４は、ゲームサーバ４０におけるゲーム管理処理の流れを説明するフローチャートである。同図によれば、プレーヤ管理部４２１は、新たなプレーヤがログインすると（ステップＢ１：ＹＥＳ）、該当するゲーム端末２０から送信される「マッチング条件通知」を受信し（ステップＢ３）、このマッチング条件にもとづく「マッチング要求」を、マッチングサーバ５０に送信する（ステップＢ５）。

また、マッチングサーバ５０から「マッチング結果」を受信したならば（ステップＢ７：ＹＥＳ）、該当するゲーム端末２０それぞれに「マッチング完了通知」を送信する（ステップＢ９）。そして、これらの各ゲーム端末２０から送信されるＭＭＯＲＰＧへの「移行希望／拒否通知」を受信する（ステップＢ１１）。

次いで、マッチングされたゲーム端末２０のうち、「移行拒否通知」を送信したゲーム端末２０を除いてマッチングを確定し（ステップＢ１３）、マッチングを確定したゲーム端末２０のうちから１台のホストを決定する（ステップＢ１５）。そして、マッチングを確定したゲーム端末２０それぞれに、マッチングデータを送信する（ステップＢ１７）。

また、プレーヤ管理部４２１は、マッチングサーバ５０への送信から所定時間（例えば、５分）を経過した「マッチング要求」があるか否かを判断し、あるならば（ステップＢ１９：ＹＥＳ）、そのマッチング要求に該当するゲーム端末２０に、「マッチング条件変更要求」を送信する（ステップＢ２１）。

また、ゲーム端末２０におけるＭＭＯＲＰＧ処理が終了すると（ステップＢ２３）、該当するプレーヤのプレーヤデータ４４２を更新する（ステップＢ２５）。また、ゲーム端末２０からＭＯＲＰＧのプレイ結果を受信すると（ステップＢ２７：ＹＥＳ）、該当するプレーヤのプレーヤデータ４４２を更新する（ステップＢ２９）。以上の処理を行うと、ステップＢ１に戻り、同様の処理を繰り返す。

（Ｃ）マッチング処理
図１５は、マッチングサーバ５０におけるマッチング処理の流れを説明するフローチャートである。同図によれば、ゲームサーバ４０から「マッチング要求」を受信したならば（ステップＣ１：ＹＥＳ）、マッチング部５２１は、先ず、該当するプレーヤが既に待ちプレーヤリストに存在するかを判断し、存在するならば（ステップＣ３：ＹＥＳ）、当該プレーヤを待ちプレーヤリストから削除する（ステップＣ５）。

次いで、要求されたマッチング条件の対戦種別を判断し、「プレーヤ戦」ならば（ステップＣ７：「プレーヤ戦」）、当該プレーヤを、所属勢力のプレーヤ戦用待ちプレーヤリストに追加する（ステップＣ９）。続いて、当該勢力について、各待ちプレーヤの自グループ条件を満たす全てのグループ候補を生成する（ステップＣ１１）。また、相手勢力についても同様に、各待ちプレーヤの自プレーヤ条件を満たす全てのグループ候補を生成する（ステップＣ１３）。各勢力について１以上のグループ候補を生成できたならば（ステップＣ１５：ＹＥＳ）、異なる勢力のグループ候補の組合せのうち、各プレーヤの相手グループ条件を満たす組合せを選出する（ステップＣ１７）。１つ以上の組合せを選出できたならば（ステップＣ１９：ＹＥＳ）、選出した組合せのうちから１つの組合せを選択し、マッチングを成立させる（ステップＣ２１）。そして、成立させたマッチング結果をゲームサーバ４０に送信する（ステップＣ３５）。また、マッチングさせた各グループのプレーヤを待ちプレーヤリストから削除する（ステップＣ３７）。

一方、対戦種別が「敵キャラ戦」ならば（ステップＣ７：「敵キャラ戦」）、マッチング部５２１は、そのプレーヤを、所属勢力の敵キャラ戦用待ちプレーヤリストに追加する（ステップＣ２３）。次いで、当該勢力について、各待ちプレーヤの自グループ条件を満たす全てのグループ候補を生成する（ステップＣ２５）。１つ以上のグループ候補を生成できたならば（ステップＣ２７：ＹＥＳ）、生成した各グループ候補と各敵グループとの全ての組合せのうち、各プレーヤの敵キャラ条件を満たす組合せを選出する（ステップＣ２９）。１つ以上の組合せを選出できたならば（ステップＣ３１：ＹＥＳ）、選出した組合せのうちから１つの組合せを選択し、マッチングを成立させる（ステップＣ３３）。そして、成立させたマッチング結果をゲームサーバ４０に送信する（ステップＣ３５）。また、マッチングさせたグループのプレーヤを待ちプレーヤリストから削除する（ステップＣ３７）。その後、ステップＣ１に戻り、同様の処理を繰り返す。

［作用・効果］
このように、本実施形態によれば、ゲームシステム１では、第１のオンラインゲームであるＭＭＯＲＰＧと、第２のオンラインゲームであるＭＯＲＰＧとが行われる。すなわち、ゲーム端末２０においてプレーヤがゲームシステム１にログインすると、先ずはＭＭＯＲＰＧに参加する。それとともに、設定したマッチング条件を満たすようにＭＯＲＰＧのためのマッチング処理が行われ、マッチングが完了すると、現在参加しているＭＭＯＲＰＧからＭＯＲＰＧに移行する。このとき、プレーヤキャラクタは２つのゲーム世界で共通であり、ＭＭＯＲＰＧのゲーム世界からＭＯＲＰＧのゲーム世界にそのまま移行する。これにより、プレーヤは、マッチングが成立してＭＯＲＰＧに移行するまでの時間を気にすることなく、ゲームを楽しむことができる。また、プレーヤキャラクタのパラメータ値は、ＭＭＯＲＰＧ及びＭＯＲＰＧの両方のゲームにおいて共通である。これにより、ＭＭＯＲＰＧが第２のＭＯＲＰＧに移行する前の単なる時間つぶしのためのゲームではなく、互いに関連するゲームとして楽しむことができる。

［変形例］
なお、本発明の適用可能な実施形態は、上述の実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で適宜変更可能なのは勿論である。

（Ａ）マッチング条件
例えば、上述の実施形態では、マッチング条件の対戦条件をプレーヤキャラクタのレベル及び職業としたが、他の条件としても良い。例えば、プレーヤのプレイ履歴を蓄積記憶しておき、このプレイ履歴を参照して、過去に同じグループとなったことがあるプレーヤを同じグループとしたり、或いは対戦したことがあるプレーヤや敵キャラクタを相手グループとしてマッチングすることにしてもよい。

（Ｂ）マッチング条件の優先順
また、上述の実施形態では、マッチングが成立しない場合には、ゲーム端末２０に「マッチング変更要求」を送信してマッチング条件を変更させるようにしたが、複数のマッチング条件に優先順位を付けておき、この優先順位に従ってマッチング条件を切り替えることにしても良い。具体的には、ゲーム端末２０において、プレーヤがマッチング条件を選択するときに、複数のマッチング条件を優先度（例えば、第１優先〜第３優先）と対応付けて選択する。そして、マッチングサーバ５０では、先ずは、優先度が最も高い（例えば、第１優先）マッチング条件を満たすようにマッチング処理を行い、所定時間が経過してもマッチングが成立しない場合には、次に優先度が高い（例えば、第２優先）マッチング条件を満たすようにマッチング処理を行う。このように、所定時間が経過する毎に、順次、次の優先度のマッチング条件に切り替えてマッチング処理を行う。

（Ｃ）課金
また、ゲームメーカ側から店舗側へ課金を行うシステムが知られている。このシステムに対して上述した実施形態を適用する場合には、プレーヤに対する課金と同様にして、絵ゲームサーバ４０からゲーム端末２０に対するマッチング完了通知があった時点をもって、ゲームプレイ１回分の課金が発生することにしても良い。

（Ｄ）ゲーム端末
また、上述の実施形態では、ゲーム端末２０を業務用のゲーム装置としたが、家庭用のゲーム装置や携帯型ゲーム装置、ＰＣといった、通信ネットワークＮ１に接続する通信機能を備えた端末装置であれば同様に適用可能である。この場合、ゲームカード１０は不要とし、予め与えられたプレーヤＩＤを入力或いは機器ＩＤを取得することで、プレーヤ個人を識別することとしても良い。

（Ｅ）ゲームの種類
また、上述の実施形態では、ゲームシステム１において、ＭＭＯＲＰＧ及びＭＯＲＰＧを行うこととしたが、同一のゲーム世界において複数のプレーヤのプレーヤキャラクタが同時にプレイするマルチプレイネットワークゲームであればＲＰＧでなくとも良い。

１ ゲームシステム
１０ ゲームカード、２０ ゲーム端末
３０ サーバシステム
４０ ゲームサーバ、５０ マッチングサーバ
６０ プレーヤ端末
Ｎ１，Ｎ２ 通信回線

Claims (8)

1. ゲーム端末と通信接続されるサーバシステムであって、
   各プレーヤのプレーヤキャラクタのパラメータ値を記憶する記憶手段と、
   前記ゲーム端末と所定通信を行ってログイン処理を行うログイン処理手段と、
   参加型のマルチプレーヤ・オンラインゲームである第１のオンラインゲームを実行し、参加している各プレーヤのプレーヤキャラクタの前記パラメータ値を当該ゲームの進行に応じて更新するとともに、前記ログイン処理手段によりログイン処理がなされた場合には、当該ログイン処理されたプレーヤに係るパラメータ値を前記記憶手段から読み出して、当該第１のオンラインゲームに参加させる第１ゲーム処理手段と、
   所与のマッチング条件に基づき、前記ログイン処理されたプレーヤについてマッチング処理を実行するマッチング処理手段と、
   前記マッチング処理手段によるマッチングが成立した場合に、マッチングされたプレーヤ同士のプレーヤキャラクタのみがプレーヤキャラクタとして存在する第２のオンラインゲームに係る処理を、前記第１のオンラインゲームにおいて更新されたパラメータ値を用いて実行開始し、当該第２のオンラインゲームの進行に応じて当該パラメータ値を更新する第２ゲーム処理手段と、
   を備えたサーバシステム。
2. 前記マッチング処理手段によるマッチングが成立した各プレーヤの各ゲーム端末に、前記第１のオンラインゲームから前記第２のオンラインゲームへの移行の許否を問い合わせる移行問合せ手段を更に備え、
   前記第２ゲーム処理手段は、前記移行問合せ手段による問合せの結果、容認回答が得られたプレーヤ同士による前記第２のオンラインゲームに係る処理を実行する、
   請求項１に記載のサーバシステム。
3. 前記第１ゲーム処理手段は、前記移行問合せ手段による問合せの結果、容認回答が得られなかったプレーヤのプレーヤキャラクタを引き続き前記第１のゲーム空間に存在させて前記第１のオンラインゲームを実行する請求項２に記載のサーバシステム。
4. 前記マッチング処理手段は、前記ログイン処理されたプレーヤのゲーム端末から受信したマッチング条件に基づき、マッチング可能なプレーヤ同士を探索してマッチング処理を実行する、
   請求項１〜３の何れか一項に記載のサーバシステム。
5. 前記マッチング処理手段によるマッチングの待ち時間を前記各プレーヤ毎に管理する待ち時間管理手段と、
   前記待ち時間が一定時間に達したプレーヤのプレーヤ端末に、当該プレーヤの前記マッチング条件の変更依頼をするマッチング条件変更依頼手段と、
   を備えた請求項４に記載のサーバシステム。
6. 前記マッチング処理手段によるマッチングの待ち時間を前記各プレーヤ毎に管理する待ち時間管理手段と、
   各プレーヤの前記マッチング条件を優先順位と対応づけて記憶するマッチング条件記憶手段と、
   を更に備え、
   前記マッチング処理手段は、前記待ち時間管理手段により管理されている待ち時間に応じて、前記マッチング条件記憶手段に記憶された当該プレーヤのマッチング条件を、対応づけられた優先順位に従って切り替えて前記マッチング処理を実行する、
   請求項４に記載のサーバシステム。
7. 各プレーヤそれぞれのゲームプレイに対する課金処理の対象期間を、当該プレーヤの前記第２のオンラインゲームの実行開始をもって開始する課金処理手段を更に備えた請求項１〜６の何れか一項に記載のサーバシステム。
8. 各プレーヤそれぞれについて、前記移行問合せ手段による問合せに対する回答が、容認回答であったプレーヤについては当該プレーヤの前記第２のオンラインゲームの実行開始をもって当該プレーヤのゲームプレイに対する課金処理の対象期間を開始し、容認回答でなかったプレーヤについては当該回答をもって課金処理の対象期間を開始する課金処理手段を更に備えた請求項３に記載のサーバシステム。