JP2011194144A - ネットワークの構築方法、プログラム、及び、そのプログラムを記録した記録媒体 - Google Patents

Abstract

【課題】オンラインゲームを実行する複数のノードでネットワークを構築する際に、有益な情報を効率的に共有可能となる適切な接続先を選択する。また、ノード間でのデータ転送負荷を低減するとともに、ノードで保持するデータ量の低減を図る。
【解決手段】各ノードが接続可能なノードの最大数が予め決められている。各ノードは、自ノードと接続している接続ノードから、ゲームを実行することによって形成される仮想世界における該接続ノードのプレイヤーの位置の情報を含むＰＣデータを受信する。そして、各ノードは、ＰＣデータを用いて前記仮想世界内でのプレイヤー間の距離を求め、前記仮想世界内でのプレイヤー間の距離が短い他ノードとの接続が優先的に維持されるように、他ノードとの接続を切り替える。
【選択図】図３

Description

本発明は、ネットワークの構築方法、プログラム、及び、そのプログラムを記録した記録媒体に関する。

近年、ビデオゲームとして、通信回線を利用したオンラインゲームが普及しつつある。そのようなオンラインゲームに関する技術は、例えば、特許文献１などに開示されている。

しかしながら、従来のオンラインゲームでは、予め用意されたサーバが、全プレイヤーの情報を管理する。そのため、プレイヤーの数の増加に伴いサーバや各端末でのトラフィックが大きくなり、プレイヤーが安定してゲームをプレイすることができなくなる虞がある。また、自分にとって不要な情報を受信するといった無駄なトラフィックが発生することも問題となる。

特開２００９−２４７５４８号公報

本発明の目的の一つは、オンラインゲームを実行する複数のノードでネットワークを構築する際に、有益な情報を効率的に共有可能となる適切な接続先を選択するための技術を提供することにある。また本発明の目的の一つは、オンラインゲームを実行する複数のノードで構成されたネットワークにおいて、ノード間でのデータ転送負荷を低減するための技術を提供することにある。また本発明の目的の一つは、オンラインゲームを実行する複数のノードで構成されたネットワークにおいて、ノードで保持するデータ量を低減するための技術を提供することにある。

本発明のネットワークの構築方法は、ゲームを実行する複数のノードで構成されるネットワークの構築方法であって、各ノードが接続可能なノードの最大数が予め決められており、各ノードが、自ノードと接続している接続ノードから、前記ゲームを実行することによって形成される仮想世界における該接続ノードのプレイヤーの位置の情報を含むＰＣデータを受信するステップと、各ノードが、ＰＣデータを用いて前記仮想世界内でのプレイヤー間の距離を求め、前記仮想世界内でのプレイヤー間の距離が短い他ノードとの接続が優先的に維持されるように、他ノードとの接続を切り替えるステップと、を有する。
このように接続可能な最大数を制限したことで、データ転送に関わる負荷が増大するのを未然に防ぐことができる。また仮想世界内において近くにいるプレイヤーのノードは、自ノードのプレイヤーにとって有益な情報を持っている可能性が高い。よって、仮想世界内において近くにいるプレイヤーのノードとの接続を優先することで、互いのノードで有益な情報を効率的に共有できるものと期待できる。

あるノードが新たにネットワークに参加する場合には、そのノードが、所定のサーバに一時的に接続し、前記所定のサーバから前記所定のサーバに接続している他ノードのネットワークアドレスを取得し、その他ノードとの接続を確立すればよい。また、既にネット
ワークに参加しているノードが新たなノードと接続を行う場合には、各ノードが、自ノードと接続するために必要なデータであるリンクチケットを発行し、自ノードと接続している接続ノードを介して自ノードと接続していない未接続ノードへ前記リンクチケットを送信して、リンクチケットを発行したノードと該リンクチケットを受信したノードとが新たな接続を確立するようにすればよい。
この構成によれば、所定のサーバを利用して他ノードと接続した後は、リンクチケットを用いて未接続ノードとの接続が行われる。そのため、サーバに負荷を与えることなくネットワークを拡大することができる。またリンクチケットの発行量によって、接続ノードの数や接続処理の負荷をコントロールできるという利点もある。

各ノードは、前記他ノードとの接続を切り替えるステップにおいて、前記仮想世界内で自ノードのプレイヤーの移動先にプレイヤーが存在するノードとの接続も維持することが好ましい。
このような構成にすることにより、仮想世界におけるプレイヤーの移動先で有益となる情報を先行して取得することができる。

あるノードが新たにネットワークに参加する場合、そのノードが、前記所定のサーバに接続している複数の他ノードの内、前記仮想世界内でのプレイヤー間の距離が最も短い他ノードと接続することが好ましい。これにより、ネットワークに参加してすぐに有益な情報を取得することができるものと期待できる。

前記ネットワークを構成しているノードのうちのいずれかのノードが、所定のサーバを介して、前記ネットワークに属していない新たなノードの情報を取得し、該新たなノードとの間で接続を確立するステップを更に有することが好ましい。具体的には、各ノードが、前記所定のサーバに接続していない時間を計測時間として計測するステップと、各ノードが、前記計測時間が所定の配布時間に達した場合に、該計測時間を蓄積時間として記録したデータであるタイムチケットを接続ノードに送信するステップと、各ノードが、接続ノードからタイムチケットを受信した場合に、該タイムチケットに記録されている蓄積時間に前記計測時間を加算するステップと、各ノードが、前記蓄積時間に前記計測時間を加算した時間が所定の満了時間に達した場合には、前記所定のサーバに一時的に接続して新たなノードの情報を取得し該新たなノードとの間で接続を確立し、前記蓄積時間に前記計測時間を加算した時間が所定の満了時間に満たない場合には、前記加算した時間を蓄積時間として記録したタイムチケットを接続ノードに送信するステップと、を更に有することが好ましい。
このような構成にすることにより、ネットワークに属していない新たなノードとの接続が行われるため、ネットワーク間の交流（情報の交換・共有）を促進することができる。

ノード間で伝送される前記ゲームのデータは、消滅までの時間を表す情報を含み、前記ゲームのデータのうち、前記仮想世界において近い位置に存在するプレイヤーに対してのみ意味のある第１データは、前記仮想世界において離れた位置に存在するプレイヤーに対しても意味のある第２データよりも、消滅までの時間が短く設定されることが好ましい。
このような構成にすることにより、仮想世界において離れた位置に存在するプレイヤーに対してあまり有効とならないデータの伝達が抑制されるため、有益な情報は残しつつデータの転送量を低減することができる。その結果、各ノードの負荷を低減することができ、プレイヤーが安定してゲームをプレイすることが可能となる。

前記第２データの送信頻度は、第１データの送信頻度よりも低く設定されることが好ましい。
一般に、第２データは、古いデータであっても意味のあるデータである可能性が高い。そのため、そのようなデータの送信頻度を低く設定することにより、有益な情報は残しつ
つデータの転送量を低減することができる。その結果、各ノードの負荷を低減することができ、プレイヤーが安定してゲームをプレイすることが可能となる。

各ノードは、接続ノードのうち、前記仮想世界内でのプレイヤー間の距離が短い他ノードに対して前記第１データと前記第２データの両方を送信し、前記仮想世界において、プレイヤーが自ノードのプレイヤーの移動先にいる他ノードに対して前記第２データのみを送信することが好ましい。
または、各ノードは、接続ノードのうち、前記仮想世界において、プレイヤーが自ノードのプレイヤーの移動先にいる他ノードに対して、前記第１データを、前記仮想世界内でのプレイヤー間の距離が短い他ノードに対する送信頻度よりも低い送信頻度で送信することが好ましい。
第１データは、仮想世界において近い位置に存在するプレイヤーに対してのみ意味のあるデータであるため、このような構成にすることにより、有益な情報は残しつつデータの転送量を低減することができる。その結果、各ノードの負荷を低減することができ、プレイヤーが安定してゲームをプレイすることが可能となる。

各ノードは、他ノードから受信した前記ゲームのデータを蓄積するための記憶装置を有しており、前記ゲームのデータのうち、前記仮想世界において離れた位置に存在するプレイヤーに対しても意味のあるデータは、プレイヤーへの影響度合いを表す評価値の情報を含み、各ノードは、前記評価値の情報を含むデータに対し、評価値の高いデータを優先的に前記記憶装置に蓄積することが好ましい。
このような構成にすることにより、ノードで保持するデータ量を低減することができる。また、プレイヤーに影響のあるデータ（プレイヤーにとって有益なデータ）が残される。

また、本発明は、上記処理の少なくとも一部を有するネットワークの構築方法として捉えてもよいし、かかる方法を実現するためのプログラムやそのプログラムを記録した記録媒体として捉えることもできる。なお、上記処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。

本発明によれば、オンラインゲームを実行する複数のノードでネットワークを構築する際に、有益な情報を効率的に共有可能となる適切な接続先を選択することができる。また、ノード間でのデータ転送負荷を低減するとともに、ノードで保持するデータ量の低減を図ることもできる。

図１は、自ノードが所定のサーバを利用して他ノードに接続する様子を示す概略図である。 図２（ａ）は、リンクチケットのデータ構造の一例を示す図であり、図２（ｂ）は、タイムチケットのデータ構造の一例を示す図である。 図３は、リンクチケットを用いてネットワークが拡大される様子を示す概略図である。 図４は、リンクチケットを用いてネットワークを拡大する際の処理の流れの一例を示すフローチャートである。 図５は、タイムチケットを用いてネットワークが拡大される様子を示す概略図である。 図６は、タイムチケットを用いてネットワークを拡大する際の処理の流れの一例を示すフローチャートである。

以下、本実施形態に係るネットワークの構築方法について説明する。本実施形態では、ゲームを実行する複数のノードで構成されるネットワークを構築する。また、以下の説明では１つのノードに注目し、該ノードを“自ノード”、それ以外のノードを“他ノード”と呼ぶ。他ノードのうち、自ノードに接続されているノードを“接続ノード”、自ノードに接続されていないノードを“未接続ノード”と呼ぶ。ノード間の接続のことを“リンク”と呼ぶ。

＜ノード間の接続について＞
図１は、自ノードが所定のサーバを利用して他ノードに接続する様子を示す概略図である。

図１において、ノード（自ノード１０１及び他ノード１０２）は、ゲームを実行するノードであり、例えば、ゲーム装置本体やパーソナルコンピュータなどである。なお、ノードは、これらに限らず、ゲームを実行することができ、且つ、インターネットへ接続可能な端末であればよい。

所定のサーバ１０３は、ゲームソフトやゲーム装置（ノード）のメーカーなどが予め用意したサーバである。本実施形態では、所定のサーバ１０３は、ロビーサーバ１１１とＳＴＵＮ(Simple Traversal of UDP through NATs)サーバ１１２とからなるものとする。ロビーサーバ１１１は、ロビーサーバ１１１に接続されているノードの情報（ノードデータ）を管理する。具体的には、ロビーサーバに登録されているノードデータを管理する。ノードデータは、ノード間の接続（Ｐ２Ｐ接続；リンク）に必要なデータであり、例えば、ＩＰアドレス、ポート、ネットワーク内での識別子（ログインＩＤ）などである。ＳＴＵＮサーバ１１２は、ロビーサーバ１１１に接続されているノードの有効なＩＰアドレスを管理する。なお、本実施形態では、ノード間の接続をＵＤＰ(User Datagram Protocol)で行う場合を想定しており、ＴＣＰ(Transmission Control Protocol)で行う場合にはＳＴ
ＵＮサーバ１１２は必要ない。

以下、ネットワークに参加していない自ノード１０１と他ノード１０２が接続するまでの流れについて説明する。なお、以下の処理は、少なくとも、自ノード１０１のユーザ（プレイヤー）がゲームのプレイを開始する際に行われる。

まず、自ノード１０１は、ゲームを起動すると、ロビーサーバ１１１に接続し、自ノード１０１のノードデータをロビーサーバ１１１に登録する（図１の矢印１１）。
そして、自ノード１０１は、ロビーサーバ１１１から他ノード１０２のノードデータを取得する（図１の矢印１２）。
次に、自ノード１０１は、取得したノードデータを用いて、ＳＴＵＮサーバ１１２に有効なＩＰアドレスを問い合わせ、取得する（図１の矢印１３，１４）。
そして、自ノード１０１は、ＳＴＵＮサーバ１１２から取得したＩＰアドレスのノード（他ノード１０２）に対し、Ｐ２Ｐ接続を開始する（図１の矢印１５）。

以上の工程を経て、自ノード１０１は所定のサーバ１０３を介さずに他ノード１０２に接続される。そして、自ノード１０１は、他ノード１０２とのＰ２Ｐ接続を確立した後に、ロビーサーバ１１１から切断する（ロビーサーバ１１１から自ノード１０１のノードデータを削除する）。例えば、自ノード１０１は、他ノード１０２との接続から所定時間後や、所定数の他ノード１０２との接続を確立したタイミングで、ロビーサーバ１１１から自ノード１０１のノードデータを削除する。このように、本実施例では、ロビーサーバ１１１は一時的（例えば、初回のゲーム起動時のみ）に利用されるため、ネットワークの参加人数（プレイヤーの数）が増加した場合におけるサーバの負荷を軽減することができる
。

また、自ノードは、ゲームを実行することで形成される仮想世界におけるプレイヤー間の距離が短い他ノードと接続することが好ましい（以後、仮想世界でのプレイヤーを現実世界でのプレイヤーと区別し、ＰＣ(Player Character)と記載する）。これは、ＰＣが自ノードのＰＣの近くにいるノードは、一般的に、自ノードのプレイヤーにすぐに有益となる情報（データ）を持っている可能性が高いからである。そのような接続を実現するためには、各ノードが、ノードデータの他に、ＰＣの位置の情報を含むＰＣデータをロビーサーバ１１１に登録すればよい。そして、自ノードは、他ノードのノードデータとＰＣデータをロビーサーバから取得し、ＰＣデータを用いて、ＰＣ間の距離が最も短い他ノードを探索し、該他ノードに対して接続を行えばよい。具体的には、自ノードが、自ノードのＰＣデータと他ノードのＰＣデータとから接続の好ましさの指標であるリンクスコア（本実施形態では、ＰＣ間の距離が短いほど高くなるスコア）を算出し、リンクスコアが最も高い他ノードに対して接続を行えばよい。このような構成にすることにより、プレイヤーは、ゲーム開始直後から他のプレイヤーに関わる有益な情報を取得することができるため、プレイヤーに対しオンラインでプレイしているメリットを享受させることができる。

＜リンクチケットを用いたネットワークの拡大方法＞
次に、上記ネットワークの拡大方法について説明する。本実施形態では、リンクチケットを用いて、各ノードがサーバに接続することなく上記ネットワークを拡大する。リンクチケットは、他ノード（未接続ノード）が自ノードに接続するために必要なチケット（データ）である。リンクチケットは接続（若しくは接続を試みること）を許可するデータでもあるし、接続を確立するのに必要な情報が記述されたデータでもある。

図２（ａ）は、リンクチケットのデータ構造の一例を示す図である。
図２（ａ）に示すように、リンクチケットは、枚数、生成元のノードデータ、生成日時、有効時間などの情報を有する。リンクチケットに枚数の情報を導入することにより、１枚ずつ送信するよりもデータ量を軽減することができる。有効時間はリンクチケットが有効な時間であり、リンクチケットは、生成されてから有効時間経過後に消滅または使用不可能となる。

図３は、リンクチケットを用いてネットワークが拡大される様子を示す概略図である。
図３に示すように、自ノード３０１は自身のリンクチケット（ＬＴ＿Ａ）や受信したリンクチケット（ＬＴ＿Ｂ）を接続ノード３０２へ送信する。このようなリンクチケットの送信・転送により、自ノード３０１は未接続ノード３０３のリンクチケット（ＬＴ＿Ｃ）を受信することとなる。自ノードは、リンクチケット（ＬＴ＿Ｃ）を受信すると、そのリンクチケットを用いて、対応する未接続ノード３０３へ接続を要求する。

また、プレイヤーがオンラインプレイのメリットをできるだけ享受するためには、自ノードはより多くの他ノードと接続していることが望ましい。
そこで、本実施形態では、自ノードは、未接続ノードのリンクチケットを受信した場合に、該未接続ノードに対し必ず接続を要求し（能動リンク）、未接続ノードから接続の要求があった場合には、それを受け入れる（受動リンク）ものとする。

また、本実施形態では、自ノードは、自ノードのリンクチケットを、定期的に、接続ノードへ送信するものとする。例えば、一度リンクチケットを送信してから所定時間後に再度リンクチケットを送信する。なお、送信するリンクチケットの枚数は、自ノードの空きリンク数（自ノードが接続できる総ノード数−接続ノード数）に応じて変更される。空きリンク数が多いことは、接続ノード数が少ないことを意味する。そのため、自ノードは空きリンク数が多いほど多くのリンクチケットを発行（送信）する。なお、図３には１つの
接続ノードにリンクチケットを送信する例を示しているが、リンクチケットは複数の接続ノードに送信してもよい。例えば、６枚のリンクチケットを２枚ずつ３つの接続ノードに送信してもよい。接続ノード毎にリンクチケットの枚数を異ならせてもよい。例えば、帯域に余裕のある接続ノードやリンク数（接続しているノードの数）の多い接続ノードに対してより多くのリンクチケットを送信する構成であってもよい。

以下、図４のフローチャートを用いて、リンクチケットを用いてネットワークを拡大する際の処理の流れについて説明する。

まず、自ノードは、接続ノードからリンクチケットを受信すると（Ｓ４０１：ＹＥＳ）、該リンクチケットをすでに所有しているか否かを判断する（Ｓ４０２）。

受信したリンクチケットがすでに所有しているリンクチケットである場合には（Ｓ４０２：ＹＥＳ）、自ノードは、受信したリンクチケットを送信元の接続ノードとは異なる接続ノードへ転送する（Ｓ４０６）。受信したリンクチケットがまだ所有していないリンクチケットである場合には（Ｓ４０２：ＮＯ）、自ノードは、該リンクチケットを用いて対応する他ノード（未接続ノード）へ接続を要求する（Ｓ４０３）。

そして、Ｓ４０３の次に、自ノードは、Ｓ４０２で受信したリンクチケットの枚数が２枚以上か否かを判断する（Ｓ４０４）。枚数が１枚である場合には（Ｓ４０４：ＮＯ）、Ｓ４０１へ戻る。枚数が２枚以上である場合には（Ｓ４０４：ＹＥＳ）、（自ノードが１枚使用するため）受信したリンクチケットの枚数を１枚減らし（Ｓ４０５）、該リンクチケットを送信元の接続ノードとは異なる接続ノードへ送信する（Ｓ４０６）。そして、Ｓ４０１へ戻る。

以上の処理を繰り返すことにより、ネットワークが拡大される。
また、本実施形態では、ノード間でリンクチケットを送受信して（サーバに接続することなく）ネットワークが拡大されるため、サーバに負荷を与えることなくネットワークを拡大することができる。そして、リンクチケットを使用しなければ他ノードと接続できないため、１つのノードに接続要求が集中することを抑制することができる。

＜接続の切り替え方法＞
上述したように、本実施形態において、自ノードは積極的に能動リンク及び受動リンクを行う。しかしながら、空きリンクが無ければ、自ノードは他ノードと接続を行うことができない。また、自ノードは、プレイヤーのプレイ中に、現在の接続ノードよりも好ましい未接続ノードのリンクチケットを取得することや、そのような未接続ノードから接続を要求されることがある。その場合に、自ノードに空きリンクが無ければ、自ノードは、そのような未接続ノードとの接続を行うことができない。そこで、本実施形態では、各ノードは必ず所定数の空きリンクを確保しているものとする。具体的には、自ノードが、空きリンクの数（空きリンク数）が所定数未満となった場合に、接続ノードの中から好ましい接続ノードを選択し、それら以外の接続ノードとの接続を切断するものとする。それにより、所定数の空きリンクが確保される。

例えば、自ノードは、接続ノードと定期的にＰＣデータの送受信を行う。そして、空きリンク数が所定数未満となった場合（接続ノードの数が所定数を超えた場合）に、ＰＣデータに基づいて接続ノードの接続を切り替える。具体的には、リンクスコアが高い順に所定数のノードとの接続は維持し、リンクスコアが低いノードのうちのいくつかの接続を切断する。なお、リンクスコアが高いノードとのリンクを通常リンクと呼ぶ。これにより、自ノードはＰＣ間の距離がより短いノードとの接続が優先されるため、有益な情報の取得が期待できる。

また、自ノードのＰＣの移動先にＰＣが存在するいくつかのノードとの接続も維持されるように、接続ノードの接続を切り替えてもよい。例えばゲームの仮想世界が複数のエリアで構成されている場合に、自ノードのＰＣがエリアＸからエリアＹに向かって移動中であれば、エリアＹの中にＰＣが存在している他のノードともリンクをもつのである。このようなリンクを先読みリンクと呼ぶ。このような構成にすることにより、自ノードのＰＣの移動先の情報を先行して取得することができる。

なお、リンクスコアを算出するための関数として、通常リンク用の関数と先読みリンク用の関数とを用意し、それぞれのリンクスコアを算出してもよい。その場合には、通常リンクと先読みリンクのそれぞれについてリンクスコアが高い所定数の他ノードと接続される構成とすればよい。

なお、リンクチケットとともにＰＣデータを転送する構成であってもよい。それにより、能動リンクにおいては、取得したＰＣデータを用いてリンクスコアを算出し、接続するにふさわしい他ノードか否かを判断した後で、他ノードとの接続を行うことができる。そのため、不必要に他ノードと接続することを防ぐことができる。

また、上記接続の切り替えのタイミングは、自ノードが決定してもよい。例えば、一度接続した他ノードのノードデータ（リンクチケットを含む）と該他ノードのＰＣデータをノードリストとして格納しておき、定期的に接続ノードとのリンクスコア、及び、未接続ノードとのリンクスコア（接続したと仮定した場合のリンクスコア）を算出し、上記判断指標に基づいて接続の切り替えを行ってもよい。

また、接続ノードからのデータ（例えば、ＰＣデータ）の転送が途絶えた場合には、その接続ノードとのリンクを解除してもよい。接続ノードからのデータの転送が途絶えた場合には、該接続ノードがネットワークから切断した可能性が高いため、そのような接続ノードとのリンクを解除することにより、無駄なリンクを減らすことができる。

＜タイムチケットを用いたネットワークの拡大方法＞
また、上述した方法でネットワークを構築しようとすると、ネットワーク内に“小島”（一部のノードで構成され、他のノードとの接続を行わない小規模なネットワーク）ができてしまう虞がある。そのような“小島”内のプレイヤーは、接続先のプレイヤーが限定されてしまうため、取得できる情報に偏りがでる可能性がある。そこで、本実施形態では、タイムチケットを用いてノードをサーバへ定期的に接続させる。タイムチケットはロビーサーバへ強制的に接続させるためのチケット（データ）である。

図２（ｂ）は、タイムチケットのデータ構造の一例を示す図である。
図２（ｂ）に示すように、タイムチケットは、蓄積時間、満了時間などの情報を有する。蓄積時間はタイムチケットに蓄積された時間の情報であり、蓄積時間が満了時間に達したタイムチケットを所持しているノードはサーバへ接続しなければならない。

図５は、タイムチケットを用いてネットワークが拡大される様子を示す概略図である。
各ノードは、サーバへ接続していない時間を計測時間としてカウントしており、計測時間が所定の配布時間に達したノードは、該計測時間を蓄積時間としてタイムチケット（ＴＴ）に記録し、そのタイムチケットを接続されているノードに送信する。
タイムチケットを受信したノードは、自身の計測時間を受信したタイムチケットに記録されている蓄積時間に加算し、そのタイムチケットを接続されているノードに送信する。
以上の処理を繰り返し、加算の結果が満了時間以上となった場合には、そのノードはサーバに登録し、他のノードとの接続を行う。

以下、図６のフローチャートを用いて、タイムチケットを用いてネットワークを拡大する際の処理の流れについて説明する。

まず、自ノードは、計測時間のカウントを開始する（Ｓ６０１）。
そして、計測時間が配布時間以上となると（Ｓ６０３：ＹＥＳ）、自ノードは該計測時間を蓄積時間としてタイムチケットに記録し、そのタイムチケットを接続ノード（複数存在する場合にはいずれか１つ）に送信する（Ｓ６０４）。そして、Ｓ６０１へ戻る。
また、自ノードは、タイムチケットを受信すると（Ｓ６０２：ＹＥＳ）、該タイムチケットの蓄積時間に計測時間を加算する（Ｓ６０５）。

（Ｓ６０５の）次に、自ノードは、Ｓ６０５の加算処理により、蓄積時間が満了時間以上となったか否かを判断する（Ｓ６０６）。蓄積時間が満了時間未満の場合には（Ｓ６０６：ＮＯ）、自ノードは、該蓄積時間が記録されたタイムチケットを接続ノードに送信する（即ち、Ｓ６０４の処理を行う）。累積時間が満了時間以上となった場合には（Ｓ６０６：ＹＥＳ）、ロビーサーバへ接続し（Ｓ６０７）、他ノード（未接続ノード）との接続を行う（Ｓ６０８）。なお、自ノードは、他ノードとの接続が確立するまで、ロビーサーバに接続し続ける（ノードデータを登録し続ける）。

他ノードとの接続が確立すると（Ｓ６０８：ＹＥＳ）、自ノードはロビーサーバとの接続を切断し（Ｓ６０９）、Ｓ６０１へ戻る。即ち、自ノードはロビーサーバからノードデータを削除し、Ｓ６０１へ戻る。

このように、タイムチケットによってノードを強制的にサーバに接続させることにより、“小島”内のノードを“小島”外のノードと接続させることができ、ネットワーク間の交流（情報の交換・共有）を促進することができる。よって、ユーザに対してより有益な情報を与える機会が増える。

なお、Ｓ６０２において、自ノードは、複数の接続ノードから同時にタイムチケットを受信する可能性がある。そのような場合には、自ノードは、受信した複数のタイムチケットの蓄積時間と自身の計測時間の総和を算出し、複数のタイムチケットの該総和を蓄積時間とする１つのタイムチケットに集約すればよい。

なお、タイムチケットの送信後（Ｓ６０４の処理の後）やロビーサーバとの接続の切断後（Ｓ６０９の処理の後）に、直ちに計測時間のカウント（Ｓ６０１の処理）を開始するのではなく、所定の猶予時間後に開始するようにしてもよい。また、猶予時間は、自ノードのリンク数（接続ノードの数）に応じて変動するものであってもよい。例えば、リンク数が多い場合には、ネットワークの大きさがある程度大きいことが予想される。そのような場合には、ロビーサーバへ頻繁に接続する必要はないため、猶予時間を長くしてもよい。

また、満了時間は、状況に応じて設定されてもよい。例えば、満了時間として、最初に初期値（例えば１０秒）が設定され、タイムチケットによりノードがロビーサーバに接続した場合には、該ノードは満了時間をロビーサーバの性能に応じて長い時間（例えば１分）に変更してもよい。満了時間を長い時間に変更するのは、一度タイムチケットによってロビーサーバに接続すれば、その後はロビーサーバに接続しなくてもある程度までネットワークが広がるからである。また、ロビーサーバへ登録されているノードの数が十分に多い場合にロビーサーバへ接続すると、ロビーサーバの負荷が大きくなってしまうため、そのような場合には、満了時間を長くしてもよい。一方、ロビーサーバへ登録されているノードの数が少ない場合には、ロビーサーバの処理に余裕があるため、満了時間を短くして
もよい。

また、満了時間の変更日時が古い場合には、その満了時間が妥当な時間である可能性は低くなる。例えば、ロビーサーバが混んでいたために満了時間を長くしたとしても、それが１０分前の情報であれば現在ロビーサーバが混んでいる可能性は低くなる。そこで、各ノードは、満了時間の変更の際に、その変更日時をタイムチケットに記録することが好ましい。そして、受信したタイムチケットに記録されている変更日時が現日時よりも所定時間前の日時である場合には、満了時間を初期値に戻せばよい。それにより、満了時間の妥当性を向上することができ、ひいては、好適にネットワークを拡大すること（“小島”の発生を抑制すること）ができる。なお、タイムチケットが複数のノードから同時に受信された場合（複数のタイムチケットを１つに集約する場合）には、満了時間として、各タイムチケットの満了時間のうち、変更日時が最も新しい満了時間を選択すればよい。

＜ノード間で送受信するデータについて＞
次に、ノード間で送受信するデータ（ゲームの情報；ゲームデータ）について説明する。ゲームデータは、各ノードで生成され送信される。具体的には、各ノードは、プレイヤーのゲームのプレイ状況に応じてゲームデータを生成する。そのため、ゲームデータの増加に伴い、ノード間を行き交うデータ量（転送量）が増大してしまう。このような転送量の増大は、ノードの負荷の増大を招き、好ましくない。そのような問題を解決するために、本実施形態では、ゲームデータを定期的に削除する。具体的には、ゲームデータに消滅までの時間（寿命）を設けることにより、ゲームデータを定期的に削除する。

例えば、ゲームデータとして、ＰＣが自ノードのＰＣの近くにいるノードのプレイヤーにのみ有効となるデータ（第１データ）と、ＰＣが自ノードのＰＣから離れた位置にいるノードのプレイヤーにも有効となるデータ（第２データ）とが考えられる。本実施形態では、第１データと第２データとで寿命を異ならせる。

具体的には、ゲームデータが到達するまでのホップ数（通過するノード数）が少ない接続ノードや未接続ノードのＰＣは、自ノードのＰＣの近くにいる可能性が高い。一方、ゲームデータが到達するまでのホップ数が多い未接続ノードのＰＣは、自ノードのＰＣから離れた位置にいる可能性が高い。そのため、第１データに対しては（第２データよりも）短い寿命を設定し、第２データに対しては（第１データよりも）長い寿命を設定する。それにより、ＰＣが自ノードのＰＣから離れた位置にいるノードのプレイヤーに対しあまり有効とならないデータの伝達が抑制されるため、有益な情報は残しつつデータの転送量を低減することができる。その結果、各ノードの負荷を低減することができ、プレイヤーが安定してゲームをプレイすることが可能となる。

また、一般に、第１データは古いデータであると意味の無くなるデータである可能性が高く、第２データは古いデータであっても意味のあるデータである可能性が高い。そこで、本実施形態では、第１データと第２データとで配信頻度（送信頻度）を異ならせる。

具体的には、第１データについては（第２データよりも）高い配信頻度を設定し、第２データについては（第１データよりも）低い配信頻度を設定する。それにより、古いデータであると意味の無くなるデータは積極的に生成、送信され、古いデータであっても意味のあるデータの転送量は減らされるため、有益な情報は残しつつデータの転送量を低減することができる。その結果、各ノードの負荷を低減することができ、プレイヤーが安定してゲームをプレイすることが可能となる。なお、古くても意味のあるデータは、寿命が無限大（無限時間）で、且つ、１つのノードに対し１回だけ送信されるデータであってもよい。

また、ゲームデータとして、プレイヤーが指示している間だけ有効となるデータが考えられる。例えば、プレイヤーの指示（操作）によって有効となり、プレイヤーの指示によって無効となるアプリケーションのデータが考えられる。そのようなデータを他のプレイヤーに対して有効にするために、本実施形態では以下のようなデータの送信を行う。

まず、自ノードのプレイヤーがアプリケーションを有効にすると、自ノードが、そのアプリケーションを識別する識別子を生成する。次に、自ノードが、その識別子とともに該アプリケーションのデータを繰り返し送信する（データに識別子が含まれていてもよい。例えば、データの名前が識別子であってもよい）。具体的には、自ノードは、データの寿命がくる前に同じデータを送信する。そして、他ノードは、以前に受信したデータと同じ識別子のデータを受信すると、受信したデータを以前に受信した同じ識別子のデータに上書きする。それにより、同一のデータの寿命だけが更新されることになり、有効性が維持される。なお、そのようなデータは、自ノードのプレイヤーがアプリケーションを無効にした後に寿命によって無効とされてもよいし、自ノードがアプリケーションを無効したことを示すデータ（無効データ）を送信し、該無効データの受信によって無効とされてもよい。

また、第１データは、ＰＣが自ノードのＰＣの近くにいるノードのプレイヤーにのみ有効となるデータであるため、先読みリンクの接続ノードに送信しても有効となる可能性は低い。そこで、本実施形態では、通常リンクと先読みリンクとで送信するデータまたは配信頻度を異ならせる。具体的には、通常リンクの接続ノードに対しては第１，２データを送信し、先読みリンクの接続ノードに対しては第２データを送信する。このような構成にすることにより、有益な情報は残しつつデータの転送量を低減することができる。その結果、各ノードの負荷を低減することができ、プレイヤーが安定してゲームをプレイすることが可能となる。なお、先読みリンクの接続ノードのＰＣは自ノードのＰＣに近づく可能性があるため、第１データを通常リンクの接続ノードに対する配信頻度よりも低い配信頻度で送信してもよい。ＰＣ間の距離が近いほど高くなるようなリンクスコアによって通常リンクと先読みリンクを区別する場合には、該リンクスコアに応じて送信するデータが異なることとなる。

また、ゲームデータ（例えば、古くても意味のある第２データ）を、記憶装置（例えば、ノードに内蔵または外付けされた不揮発性メモリ、磁気ディスクなど）に記憶させることが考えられる。しかしながら、受信した第２データを全て記憶すると、データ量が膨大になる虞がある。そこで、本実施形態では、第２データがプレイヤーへの影響度合いを表す評価値の情報を含むものとする。具体的には、第２データに対しプレイヤーが何らかの評価をすることを可能にし、該評価に基づいて評価値を算出する。そして、評価値の高いものを優先的に記憶装置に記憶させる（第２データに対し、評価値の低いデータから順に削除する）。このような構成にすることにより、ノード（具体的には、上述した記憶装置）が保持するデータ量を低減することができる。また、プレイヤーに影響のあるデータ（プレイヤーにとって有益なデータ）を優先的に残すことができる。
なお、ゲームデータは、記憶するデータ量を所定量以下に保つように削除されてもよいし、評価値が所定の閾値未満である場合に削除されてもよい。

＜具体例＞
以下、上述した各種技術の具体例について説明する。
（ＰＣデータの具体例）
まず、ＰＣデータ及び該ＰＣデータを用いたリンクスコアの算出方法の具体例について説明する。ゲームの種類によって接続の評価に重要なパラメータが異なるため、ＰＣデータやリンクスコアの算出方法もゲームの種類によって異なる。

例えば、アクションロールプレイングゲームなどのようなゲームの場合、リンクスコアを算出するためのパラメータ（ＰＣデータ）として、「ＰＣの位置座標」、「ＰＣのレベル」、及び、「空きリンク数」などが考えられる。そのような場合には、各パラメータに対し接続するにふさわしいほど高得点になるようなスコアを算出し、算出したそれらスコアの合計値をリンクスコアとすればよい。なお、スコアは、接続するにふさわしいか否かの判断において重要となるパラメータほど重みが大きくなるように算出されることが好ましい。

「ＰＣの位置座標」に対しては、例えば、ＰＣ間の距離が近いほど高くなるようにスコアを算出すればよい。具体的には、ＰＣ間の距離がある距離以上の場合はスコアを“０”とし、それよりも近い場合には、距離に応じて“１１〜２０”の範囲でスコアを算出すればよい。
「ＰＣのレベル」に対しては、例えば、ＰＣ間のレベル差が小さいほど高くなるようにスコアを算出すればよい。具体的には、ＰＣ間のレベル差に応じて“０〜１０”の範囲でスコアを算出すればよい。
「空きリンク数」に対しては、空きリンク数が多いほど高くなるようにスコアを算出すればよい。具体的には、空きリンク数に応じて“０〜５”の範囲でスコアを算出すればよい。

なお、すでに述べたように、近い位置にいるＰＣのノードは、自ノードのプレイヤーにとって有益な情報を持っている可能性が高い。そこで、上記例では、「ＰＣの位置座標」がリンクスコアに最も大きな影響を与えるようにスコアの範囲が設定されている。
なお、ゲームによってはＰＣの移動できる範囲が制限されている場合がある。即ち、ＰＣの移動できる経路が予め決められている場合がある。その場合には、「ＰＣの位置座標」から経路上の距離と（相手のＰＣがいる）方向を算出し、それらの結果を用いてスコアを算出すればよい。

次に、ゲームの種類（ゲームタイプ）ごとの必要なＰＣデータ及び評価基準の例について説明する。
・ＰＣの状態によってリンクスコアを変化させる場合
ＰＣが死亡してもプレイヤーが操作可能な魂として存在し続けるゲームの場合には、「生身」や「魂」などの「状態」を表すデータをＰＣデータとして用いてもよい。そのようなＰＣデータに対しては、例えば、状態が近い（または状態が離れている）ほど高くなるようにスコアを算出すればよい。

・ＰＣの属性によってリンクスコアを変化させる場合
チーム分けがあるゲームの場合には、自分のチームを表すデータをＰＣデータとして用いてもよい。そのようなＰＣデータに対しては、例えば、該データが自ノードのチームと同じチームを表す場合に高くなるようにスコアを算出すればよい。

・プレイ状況によってリンクスコアを変化させる場合
対戦ゲームであって、他のＰＣが助けに入ったり乱入したりできるゲームの場合には、助けに入るのか乱入するのかを表すデータをＰＣデータとして用いてもよい。そして、そのようなＰＣデータに対しては、例えば、自ノードのＰＣが優勢か劣勢かでスコアの算出方法を異ならせればよい。具体的には、優勢の場合には、乱入を表すＰＣデータに対して高いスコアを算出し、劣勢の場合には、助けに入ることを表すＰＣデータに対して高いスコアを算出すればよい。なお、優勢か劣勢かは、自ノードのＰＣの体力、レベル、装備、及び、敵の数、強さなどの情報から判断すればよい。

・プレイヤーの意思によってリンクスコアを変化させる場合
プレイヤーが他のプレイヤーの助けを求めるための“救援信号”を発信できるゲームの場合には、“救援信号”を受け入れるか否かを表すデータをＰＣデータとして用いてもよい。そのようなＰＣデータに対しては、例えば、該データが“救援信号”を受け入れること表す場合に高くなるようにスコアを算出すればよい。
また、プレイヤーが挑戦者を募集することができるゲームの場合には、挑戦を希望しているか否かを表すデータをＰＣデータとして用いてもよい。そして、例えば、自ノードのプレイヤーが挑戦者を募集しているときに、挑戦を希望していること表すＰＣデータに対して高いスコアを算出すればよい。

（ゲームデータの具体例）
次に、ゲームデータの具体例について説明する。
まず、ＰＣが自ノードのＰＣから離れた位置にいるノードのプレイヤーにも有効となり、且つ、古いデータであっても意味のあるデータ（第２データ）の例について説明する。

プレイヤーが仮想世界の所望の位置にテキストを残すことができるゲームの場合、ゲームデータとして、該テキストを表すテキストデータが考えられる。テキストデータは、例えば、テキストの内容、テキストが残された位置などの情報を含む。

自ノードのＰＣが過去に行った行動を他のプレイヤーが見ることのできるゲームの場合、ゲームデータとして、該行動を表すリプレイデータが考えられる。リプレイデータは、例えば、ＰＣの行った行動、該行動を行った位置などの情報を含む。

仮想世界のキャラクター（例えば、敵や商人など）がノード間を移動するゲームの場合、ゲームデータとしてキャラクターの情報を表すキャラクターデータが考えられる。キャラクターデータは、例えば、キャラクターが敵である場合には、該敵の種類、強さ、残りの体力、キャラクターが商人である場合には、商品（アイテム）のラインナップなどの情報を含む。

仮想世界におけるお店で売買されるアイテムの在庫をプレイヤー間で共有するゲームの場合、ＰＣがお店に売ったアイテムや捨てたアイテムがお店の在庫に反映されることが考えられる。そのため、その場合には、ゲームデータとして、自ノードのＰＣがお店に売ったアイテムや捨てたアイテムのデータ（アイテムデータ）が考えられる。アイテムデータは、例えば、ＰＣがお店に売ったアイテムの種類及びその個数、ＰＣが捨てたアイテム及びその個数などの情報を含む。

仮想世界におけるチーム毎の勢力を確認することができるゲームの場合、ゲームデータとして、該勢力を算出するために必要な勝敗データが考えられる。勝敗データは、例えば、各チームの勝敗数、メンバーなどの情報を含む。

仮想世界において、１つのものに対して各ＰＣが所定の動作を行うことができ、どれだけのＰＣが該動作を行ったかを確認することのできるゲームの場合、ゲームデータとして、上記動作の実行状況を表す動作状況データが考えられる。例えば、上記所定の動作が仮想世界の泉に対しコインを投げることである場合、動作状況データは、自ノードのＰＣが投げたコインの枚数などの情報を含む。

大局的にはストラテジーゲームであり、局地戦がアクションゲームであるようなゲームの場合、ゲームデータとして、戦局を表す戦局データが考えられる。戦局データは、例えば、局地戦の状況、局地戦での勝敗、局地戦の発生や消滅などの情報を含む。

これらのデータは全てのプレイヤーに伝達されることが好ましいため、寿命は長く設定
され、配信頻度は低く設定される。例えば、寿命は、３日、１週間、無限時間などが設定され、配信頻度は、１回／ノード、１回／時間などが設定される。

次に、ＰＣが自ノードのＰＣの近くにいるノードのプレイヤーにのみ有効となり、且つ、古いデータであると意味の無くなるデータ（第１データ）の例について説明する。

自ノードのＰＣの存在を他のプレイヤーに知らせるゲームの場合、ゲームデータとして、該ＰＣの存在を表すリアルタイムリプレイデータが考えられる。リアルタイムリプレイデータは、例えば、ＰＣの行った行動、該行動を行った位置などの情報を含む。

プレイヤーが他のプレイヤーとマルチプレイすることのできるゲームの場合、ゲームデータとして、マルチプレイを望んでいることを表すＳＯＳデータが考えられる。ＳＯＳデータは、例えば、マルチプレイを望んでいることを表す情報、他のＰＣの呼び出し位置などの情報を含む。なお、ＳＯＳデータは、プレイヤーの指示に応じて送信されてもよいし、プレイヤーの意思とは無関係に（例えば、ＰＣが所定のアイテムを取得した場合に）送信されてもよい。

自ノードのＰＣの状況を他のプレイヤーに知らせるゲームの場合、ゲームデータとして、ＰＣの状況を表すＰＣ状況データが考えられる。
ＰＣが敵を倒したことや、敵に倒されたことを他のプレイヤーに知らせる場合には、ＰＣ状況データは、例えば、ＰＣが倒した敵の種類や位置、ＰＣが倒された敵の種類や位置などの情報を含む。
ＰＣが特定の位置（拠点）に到達したことを他のプレイヤーに知らせる場合には、ＰＣ状況データは、例えば、ＰＣが到達した位置、拠点を占有している時間などの情報を含む。
ＰＣが特定のアイテムを取得したことを他のプレイヤーに知らせる場合には、ＰＣ状況データは、例えば、入手したアイテムの種類、自身（入手者）などの情報を含む。
ＰＣがアイテムを配置したことを他のプレイヤーに知らせる場合には、ＰＣ状況データは、例えば、配置したアイテムの種類、位置などの情報を含む。

また、プレイヤーに他のプレイヤーが協力することのできるゲームの場合には、ゲームデータとして、協力を求めたり、協力したりすることを表す協力データが考えられる。例えば、自ノードのＰＣに他ノードのＰＣがエネルギーを送り、そのエネルギーを利用して自ノードのＰＣが強力な技を繰り出すようなゲームでは、協力データとして、協力を要請していることを表す情報、協力を求めているＰＣに送るエネルギーの量などの情報を含むデータを用いればよい。

これらのデータは自ノードのＰＣの近くにいるＰＣのノードに伝達されればよいため、寿命は短く設定される。また、常に新しい情報を伝えることが好ましいため、配信頻度は高く設定される。例えば、寿命は、３０秒、４０秒などが設定され、配信頻度は、１回／６秒、１回／１０秒などが設定される。

（評価値の算出方法の具体例）
次に、評価値の算出方法の具体例について説明する。
上述したように、特定のゲームデータ（第２データ）は、記憶装置に記憶され、評価値に基づいて削除される。

評価値は、例えば、仮想世界におけるデータの生成位置、データの生成日時、データの最終更新日時、データの生成者、他のプレイヤーによるデータの参照回数、他のプレイヤーによるデータの評価回数、データの内容、データの希少さなどの情報に基づいて算出さ
れる。

仮想世界におけるデータの生成位置の情報を用いて評価値を算出する場合には、例えば、仮想世界における特定の場所で生成されたデータに対して評価値が高くなるようにすればよい。具体的には、宝箱などの付近に生成されたテキストのデータは、宝箱の存在などを知らせる重要な情報を含んだデータである可能性が高い。そのため、テキストのデータの生成位置が宝箱付近である場合に評価値を高くすればよい。

データの生成日時の情報を用いて評価値を算出する場合には、例えば、生成日時が新しいデータに対して評価値が高くなるようにすればよい。新しいデータは長時間プレイしたプレイヤーに刺激を与える可能性が高いため、このような構成にすることにより、長時間プレイしたプレイヤーに有益なデータを記憶装置に残すことができる。なお、生成日時が古いデータに対して評価値が高くなるようにしてもよい。

データの最終更新日時の情報を用いて評価値を算出する場合には、例えば、最終更新日時が新しいデータに対して評価値が高くなるようにすればよい。最終更新日時は、例えば、最後に評価された日時（評価されていない場合にはデータの生成日時）である。最終更新日時が新しいデータはプレイヤーに何らかの刺激を与えたデータである可能性が高いため、このような構成にすることにより、プレイヤーに刺激を与えることのできるデータを記憶装置に残すことができる。なお、最終更新日時が古いデータに対して評価値が高くなるようにしてもよい。

データの生成者の情報を用いて評価値を算出する場合には、例えば、特定のプレイヤーが生成したデータに対して評価値が高くなるようにすればよい。特定のプレイヤーとは、例えば、ＰＣのレベルが所定値以上、データの生成回数が所定数以上などのプレイヤーである。

他のプレイヤーによるデータの参照回数の情報を用いて評価値を算出する場合には、例えば、参照回数が多いほど高くなるように評価値を算出すればよい。参照回数が多いデータは、プレイヤーの興味をひくデータである可能性が高いため、このような構成にすることにより、プレイヤーの興味をひくデータを記憶装置に残すことができる。なお、参照回数が少ないほど高くなるように評価値を算出してもよい。

他のプレイヤーによるデータの評価回数の情報を用いて評価値を算出する場合には、例えば、評価回数が多いほど高くなるように評価値を算出すればよい。評価回数が多いデータは、プレイヤーに何らかの刺激を与えたデータである可能性が高いため、このような構成にすることにより、プレイヤーに刺激を与えることのできるデータを記憶装置に残すことができる。なお、評価回数が少ないほど高くなるように評価値を算出してもよい。なお、プレイヤーが、複数種類の評価（良い評価と悪い評価や、５段階の評価など）から選択してデータを評価する場合には、評価数は、所定の種類の評価数であってもよいし、全評価数（種類ごとの評価数の合計値）であってもよい。

データの内容の情報を用いて評価値を算出する場合には、例えば、重要であるほど高くなるように評価値を算出すればよい。重要か否かは、例えば、テキストデータなどの場合、データに所定のキーワードが含まれているか否かで判断すればよい。具体的には、データに所定のキーワードが含まれている場合に、該データは重要であると判断すればよい。また、仮想世界におけるテキストなどの生成位置に基づいて判断してもよい。プレイヤーが重要か否かを選択し、該選択結果に基づいて判断してもよい。

データの希少さの情報を用いて評価値を算出する場合には、例えば、希少であるほど高
くなるように評価値を算出すればよい。希少か否かは、例えば、記憶されているゲームデータの種類毎の数に基づいて判断すればよい。具体的には、データ数が所定数以下の種類のデータは希少であると判断すればよい。

次に、評価された回数（評価数）および最終更新日時に基づく評価値の算出方法の具体例について説明する。評価値は、例えば、以下の式により算出される。
評価値＝（評価数／５０）＋（（最終更新日時−現在日時）×（−３））＋６
上記式は、評価数が多いデータ及び最終更新日時が新しいデータほど高い評価値を得ることのできる式の例である。また、このような式に対し、「生成から２日以内のデータを削除しない」などの条件を加えてもよい。
なお、評価値の算出式は上記式に限らない。評価値は評価数のみから算出し、評価値が同じデータについては最終更新日時が新しいデータを優先して記憶してもよい。

（接続の切り替えタイミングの具体例）
次に、接続の切り替えタイミングの具体例について説明する。
例えば、自ノードに対し、リンク数の最大値（最大接続可能数）が３２、基準のリンク数（接続基準数）が２４（最大接続可能数の２／３）とする。即ち、自ノードは、８個の空きリンクを確保するものとする。また、３２個のリンクは、受動リンク用と能動リンク用にそれぞれ半分ずつ利用されるものとする。
この場合には、自ノードは、リンク数が接続基準数になるようにリンクスコアの低い接続ノードを定期的に切断する。

なお、上記切り替え方法は、ＰＣの周囲の状況が緩やかに変わる（例えば、ＰＣの移動によって最適な接続相手が変化する）ゲームなどに適用するのに好ましい方法である。
これに対し、レースゲームのように同じプレイヤーと長時間プレイさせることが望ましいゲームでは、例えば、１レースが終わる毎にレースの参加人数だけ接続の切り替えを行えばよい。
また、プレイヤーが他のプレイヤーと同じミッションをこなすようなゲームでは、例えば、ミッションの終了毎にミッションの参加人数だけ接続の切り替えを行えばよい。

１０１，３０１ 自ノード
１０２ 他ノード
１０３ サーバ
１１１ ロビーサーバ
１１２ ＳＴＵＮサーバ
３０２ 接続ノード
３０３ 未接続ノード

Claims (11)

1. ゲームを実行する複数のノードで構成されるネットワークの構築方法であって、
   各ノードが接続可能なノードの最大数が予め決められており、
   各ノードが、自ノードと接続している接続ノードから、前記ゲームを実行することによって形成される仮想世界における該接続ノードのプレイヤーの位置の情報を含むＰＣデータを受信するステップと、
   各ノードが、ＰＣデータを用いて前記仮想世界内でのプレイヤー間の距離を求め、前記仮想世界内でのプレイヤー間の距離が短い他ノードとの接続が優先的に維持されるように、他ノードとの接続を切り替えるステップと、
   を有するネットワークの構築方法。
2. 各ノードは、前記他ノードとの接続を切り替えるステップにおいて、前記仮想世界内で自ノードのプレイヤーの移動先にプレイヤーが存在するノードとの接続も維持する
   請求項１に記載のネットワークの構築方法。
3. 各ノードが、自ノードと接続するために必要なデータであるリンクチケットを発行し、自ノードと接続している接続ノードを介して自ノードと接続していない未接続ノードへ前記リンクチケットを送信するステップと、
   リンクチケットを発行したノードと該リンクチケットを受信したノードとが新たな接続を確立するステップと、
   を更に有する請求項１または２に記載のネットワークの構築方法。
4. 前記ネットワークを構成しているノードのうちのいずれかのノードが、所定のサーバを介して、前記ネットワークに属していない新たなノードの情報を取得し、該新たなノードとの間で接続を確立するステップ
   を更に有する請求項１〜３のいずれか１項に記載のネットワークの構築方法。
5. ノード間で伝送される前記ゲームのデータは、消滅までの時間を表す情報を含み、
   前記ゲームのデータのうち、前記仮想世界において近い位置に存在するプレイヤーに対してのみ意味のある第１データは、前記仮想世界において離れた位置に存在するプレイヤーに対しても意味のある第２データよりも、消滅までの時間が短く設定される
   請求項１〜４のいずれか１項に記載のネットワークの構築方法。
6. 前記第２データの送信頻度は、第１データの送信頻度よりも低く設定される
   請求項５に記載のネットワークの構築方法。
7. 各ノードは、接続ノードのうち、前記仮想世界内でのプレイヤー間の距離が短い他ノードに対して前記第１データと前記第２データの両方を送信し、前記仮想世界において、プレイヤーが自ノードのプレイヤーの移動先にいる他ノードに対して前記第２データのみを送信する
   請求項５または６に記載のネットワークの構築方法。
8. 各ノードは、接続ノードのうち、前記仮想世界において、プレイヤーが自ノードのプレイヤーの移動先にいる他ノードに対して、前記第１データを、前記仮想世界内でのプレイヤー間の距離が短い他ノードに対する送信頻度よりも低い送信頻度で送信する
   請求項５または６に記載のネットワークの構築方法。
9. 各ノードは、他ノードから受信した前記ゲームのデータを蓄積するための記憶装置を有しており、
   前記ゲームのデータのうち、前記仮想世界において離れた位置に存在するプレイヤーに対しても意味のあるデータは、プレイヤーへの影響度合いを表す評価値の情報を含み、
   各ノードは、前記評価値の情報を含むデータに対し、評価値の高いデータを優先的に前記記憶装置に蓄積する
   請求項１〜８のいずれか１項に記載のネットワークの構築方法。
10. 請求項１〜９のうちいずれか１項に記載のネットワークの構築方法における各ステップをコンピュータに実行させるプログラム。
11. 請求項１０に記載のプログラムを記録した記録媒体。

Images