JP6838187B1 - サーバ、ゲームシステム及び処理方法 - Google Patents

サーバ、ゲームシステム及び処理方法 Download PDF

Info

Publication number
JP6838187B1
JP6838187B1 JP2020093992A JP2020093992A JP6838187B1 JP 6838187 B1 JP6838187 B1 JP 6838187B1 JP 2020093992 A JP2020093992 A JP 2020093992A JP 2020093992 A JP2020093992 A JP 2020093992A JP 6838187 B1 JP6838187 B1 JP 6838187B1
Authority
JP
Japan
Prior art keywords
information
server
update
game
charge
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020093992A
Other languages
English (en)
Other versions
JP2021186224A (ja
Inventor
修一 倉林
修一 倉林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cygames Inc
Original Assignee
Cygames Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cygames Inc filed Critical Cygames Inc
Priority to JP2020093992A priority Critical patent/JP6838187B1/ja
Application granted granted Critical
Publication of JP6838187B1 publication Critical patent/JP6838187B1/ja
Publication of JP2021186224A publication Critical patent/JP2021186224A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35Details of game servers
    • A63F13/352Details of game servers involving special game server arrangements, e.g. regional servers connected to a national server or a plurality of servers managing partitions of the game world
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35Details of game servers
    • A63F13/358Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/55Controlling game characters or game objects based on the game progress
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]

Abstract

【課題】複数のサーバでゲーム空間内のオブジェクトの状態を管理するゲームシステムのデータ同期方式を提供する。【解決手段】ゲーム空間内のエリア各々を担当し、エリア間を移動可能な複数のオブジェクト情報を管理する複数のサーバ10を有するゲームシステムの1つのサーバ10であって、オブジェクト情報を記憶するオブジェクト情報記憶部11と、担当するエリア内に存在するオブジェクトのオブジェクト情報の更新を行う第1の更新部12と、第1の更新部12によるオブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を対象サーバに送信する第1の送信部13と、他のサーバ10から受信した更新情報に基づき、記憶されているオブジェクト情報のうち、担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新を行い、時間情報に基づき時系列順のオブジェクト情報の更新を実現する第2の更新部15と、を有する。【選択図】図4

Description

本発明は、サーバ、ゲームシステム及び処理方法に関する。
近年流行しているオープンワールド型のゲームを大規模なMMO(Massively Multiplayer Online)として提供することが出来れば、開発コストの高いオープンワールド型のゲームから、長期的に利益を得ることが出来るようになる。
オープンワールド型のMMOゲームでは、例えばゲーム空間が複数のエリアに分かれており、1つのエリアが1つの負荷分散の単位に対応する。そして、オブジェクト(キャラクタ等)の移動、キャラクタ同士の戦闘、アイテム交換、魔法の発動などの相互作用が負荷分散の単位をまたがって行われることがあるため、分散したオンメモリデータベース間の同期処理が必要となる。
このようなオープンワールド型のMMOゲームを対象としたオンメモリデータベースを実現する際の最大の課題は、オブジェクトが複数のエリアをまたいで自由に移動する状況において、複数のノードによる適切な負荷分散機能を実現する点にある。
オブジェクトがオープンワールドにおいて自由に移動・行動する状況において、オブジェクトの移動範囲の制限や、同時ログイン可能なプレイや数の制限を設定することなく、オブジェクトの自由行動を許可したまま、自動的にサーバへの負荷を平準化させる新たな同期方式が望まれている。
例えば、非特許文献1乃至3に開示のように、データ・レプリケーションや、データ同期、分散データベースの分野において、数多くの研究がなされてきた。また、非特許文献4乃至6に開示のように、MMOを対象としたデータベース負荷分散やデータ同期の研究も、データ・レプリケーション技術の発展として捉えられ、北米やカナダで活発に研究されてきた。しかしながら、これらは、ゲーム内のエリアやオブジェクトにラベル付けを行い、そのラベルへのPublish/Subscribeモデルとしてデータの分散と購読を行っており、オープンワールド型の、不特定多数のオブジェクトが1つの仮想空間を共有して、リアルタイムにデータを更新しあうような状況は想定していない。
また、非特許文献7に開示のように、IP(internet protocol)マルチキャストを活用したデータ・レプリケーション方式の研究がなされ、特許文献1に開示のようにそれに関連する特許出願もなされている。しかし、IPマルチキャストを柔軟に行うことは難しい。特に、データ・レプリケーションが求める柔軟性と効率性を達成することが難しく、発展的な研究は行われていない。
非特許文献8や非特許文献9に開示のように、地理的関係を活用したデータ・レプリケーションの方式は提供されているものの、ゲーム固有の仮想空間の情報を活用したデータ・レプリケーション方法は知られていない。また、分散共有メモリ、特に、パブリッククラウドで柔軟に利用可能なソフトウェアベースの分散共有メモリの分野においては、非特許文献10及び11に開示のように、Kerrighed、openMosix、OpenSSIといった研究とOSSプロジェクトが立ちあげられてきた。しかしながら、それらは2000年代半ばにプロジェクトが休止し、広く活用されるには至っていない。
近年、非特許文献12に開示のように、カーネルレベルでのリモートメモリアクセスを透過的に実現する仕組みも研究されている。しかし、それらは主に大規模な科学技術演算を行うことを想定しており、ゲームのように、コンテンツの状況に応じてメモリへのアクセスパターンが大きく変化するアプリケーションは、いまだ研究されてこなかった。現在は、非特許文献13及び14に開示のように、クラウド上での共有メモリが活発に研究されているが、ゲームへの応用は考慮されておらず、汎用的なユースケースにとどまっている。
US9330154B2
B. Kemme, R. Jimenez-Peris, and M. Patino-Martinez, "Database Replication," Vol. 2, No. 1, pp. 1-153, 2010., DOI:https://doi.org/10.2200/S00296ED1V01Y201008DTM007 B. Kemme and G. Alonso, "Database replication: a tale of research across communities," Proc. VLDB Endow. 3, 1-2, pp. 5-12, September 2010., DOI: http://dx.doi.org/10.14778/1920841.1920847 B. Kemme and G. Alonso, "A new approach to developing and implementing eager database replication protocols.," ACM Trans. Database Syst. 25, pp. 333-379, 3 September 2000., DOI: https://doi.org/10.1145/363951.363955 J. Gascon-Samson, J. Kienzle, and B. Kemme, "MultiPub: Latency and Cost-Aware Global-Scale Cloud Publish/Subscribe," 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS), Atlanta, GA, pp. 2075-2082, 2017., doi: 10.1109/ICDCS.2017.203 C. Canas, K. Zhang, B. Kemme, J. Kienzle, and H. A. Jacobsen, "Self-Evolving Subscriptions for Content-Based Publish/Subscribe Systems," 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS), Atlanta, GA, pp. 1597-1607, 2017., doi: 10.1109/ICDCS.2017.277 C. Canas, K. Zhang, B. Kemme, J. Kienzle, and H. A. Jacobsen, "Publish/subscribe network designs for multiplayer games," In Proceedings of the 15th International Middleware Conference (Middleware '14), ACM, New York, NY, USA, pp. 241-252, 2014., DOI: https://doi.org/10.1145/2663165.2663337 J. Holliday, D. Agrawal, A. E. Abbadi, "The performance of database replication with group multicast," Digest of Papers. Twenty-Ninth Annual International Symposium on Fault-Tolerant Computing (Cat. No.99CB36352), Madison, WI, USA, pp. 158-165, 1999., doi: 10.1109/FTCS.1999.781046 T. Groothuyse, S. Sivasubramanian, and G. Pierre, "GlobeTP: template-based database replication for scalable web applications," In Proceedings of the 16th international conference on World Wide Web (WWW '07), ACM, New York, NY, USA, pp. 301-310, 2007., DOI: https://doi.org/10.1145/1242572.1242614 C. Maihofer, "A survey of geocast routing protocols," in IEEE Communications Surveys & Tutorials, vol. 6, no. 2, pp. 32-42, Second Quarter 2004., doi: 10.1109/COMST.2004.5342238 R. Lottiaux, B. Boissinot, P. Gallard, G. Vallee, and C. Morin, "OpenMosix, OpenSSI and Kerrighed: A Comparative Study," [Research Report] RR-5399, INRIA, p.20, 2004. C. Amza et al., "TreadMarks: shared memory computing on networks of workstations," in Computer, vol. 29, no. 2, pp. 18-28, Feb. 1996., doi: 10.1109/2.485843. S. Ahn, E. Lim, W. Choi, S. Kang, H. Kim, "A Design of Kernel-Level Remote Memory Extension System," In IT Convergence and Security 2017, LNEE, vol 449, 2018., https://doi.org/10.1007/978-981-10-6451-7_13 J. Ousterhout, P. Agrawal, D. Erickson, C. Kozyrakis, J. Leverich, D. Mazieres, S. Mitra, A. Narayanan, G. Parulkar, M. Rosenblum, S. M. Rumble, E. Stratmann, and R. Stutsman, "The case for RAMClouds: scalable high-performance storage entirely in DRA," SIGOPS Oper. Syst. Rev. 43, 4 (January 2010), pp. 92-105, 2010., DOI: https://doi.org/10.1145/1713254.1713276 H. Han, Y. C. Lee, W. Shin, H. Jung, H. Y. Yeom and A. Y. Zomaya, "Cashing in on the Cache in the Cloud," in IEEE Transactions on Parallel and Distributed Systems, vol. 23, no. 8, pp. 1387-1399, Aug. 2012., doi: 10.1109/TPDS.2011.297 "Amazon VPCのよくある質問"、https://aws.amazon.com/jp/vpc/faqs/
本発明は、ゲームシステムに適した新たなデータ同期方式を提供することを課題とする。
本発明によれば、
ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの1つの前記サーバであって、
前記オブジェクト情報を記憶するオブジェクト情報記憶部と、
前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第1の更新部と、
前記複数のサーバの中の一部である対象サーバのMAC(media access control)アドレスを記憶するMACアドレス記憶部と、
前記MACアドレス記憶部に記憶された前記MACアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第1の更新部による前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第1の送信部と、
他の前記サーバから受信した前記更新情報に基づき、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第2の更新部と、
を有するサーバが提供される。
また、本発明によれば、前記サーバを複数有するゲームシステムが提供される。
また、本発明によれば、
ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの1つの前記サーバが、
前記オブジェクト情報と、前記複数のサーバの中の一部である対象サーバのMACアドレスを記憶し、
記憶している前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第1の更新工程と、
前記MACアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第1の更新工程での前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第1の送信工程と、
他の前記サーバから受信した前記更新情報に基づき、記憶している前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第2の更新工程と、
を実行する処理方法が提供される。
本発明によれば、ゲームシステムに適した新たなデータ同期方式が提供される。
本実施形態のゲームシステムの全体像を説明するための図である。 本実施形態のサーバのハードウエア構成の一例を示す図である。 本実施形態のサーバの機能を説明するための図である。 本実施形態のサーバの機能ブロックの一例を示す図である。 本実施形態のサーバが処理する情報の一例を模式的に示す図である。 本実施形態のサーバが処理する情報の一例を模式的に示す図である。 本実施形態のサーバが処理する情報の一例を模式的に示す図である。 本実施形態のサーバの処理の流れの一例を説明するためのフローチャートである。 本実施形態のサーバの処理の流れの一例を説明するためのフローチャートである。 本実施形態のサーバの処理の流れの一例を説明するためのフローチャートである。 本実施例のサーバを説明するための図である。 本実施例のサーバを説明するための図である。 本実施例のサーバを説明するための図である。
<技術思想>
まず、本実施形態のゲームシステムの技術思想を説明する。本実施形態の目的は、例えば明示的なサーバ分割の単位を持たないオープンワールド型MMOゲームを対象として、各サーバが管理するゲームのステート情報を適切にサーバ間で同期することが可能な大規模な負荷分散を実現することである。そのために、本実施形態では、ゲームの仮想空間上で地理的に近いエリアを担当するサーバ間の接続を、アプリケーションを介さないOS(operating system)カーネル間の直接的な通信として実装し、分散共有メモリ上で高効率にステート情報を管理する方式を採用する。
具体的には、本実施形態では、ゲーム空間は複数のエリアに分割され、エリアごとに担当サーバが決定される。そして、互いの間をオブジェクトが頻繁に移動する2つのエリア各々を担当するサーバ間の通信を高速化させるために、それぞれのサーバで動作するOSのカーネルを用いた疑似IPマルチキャスト処理を導入する。この仕組みは、オブジェクトの移動頻度[0]が高いことが予めわかっているノード群があれば、それらのノード群が同一パケットを自動的に受け取るように、カーネルのパケット転送フィルタを予め設定できるという点に着目したものである。[0]これにより、互いの間を高頻度にオブジェクトが移動する2つのエリア各々を担当するサーバ間では、カーネル間通信を用いて、すなわち、OSのカーネルが管理するメモリ領域から個別のアプリケーションが管理するメモリ領域へ、パケットのデータをコピーすることや、CPUの実行権限をカーネルからアプリケーションへ移譲するコンテクスト・スイッチングをすることなく、オブジェクトの更新情報を即時かつ高速にプッシュ型で送受信(同期)することができる。当該構成により、ゲームのマップ情報と完全に一致する疑似IPマルチキャストネットワーク構造を静的に構築することができる。
ここで、「擬似IPマルチキャストネットワーク構造」について説明する。疑似IPマルチキャストネットワーク構造は、カーネル上でパケット転送設定(宛先MACアドレスの登録)を行うことで構築される。当該擬似IPマルチキャストネットワーク構造においては、互いのMACアドレスを宛先MACアドレスとして登録したサーバ間が直接接続される。直接接続されたサーバ間においては、擬似的なマルチキャスト機能を用いて、分散共有メモリを構築する各ノードのカーネルをルータにしてデータを送受信可能となっている。
本実施形態は、分散共有メモリの各ノードのカーネルをルータにすることにより、中央制御されたルータやアプリケーション層の高度なルーティング処理を必要とせずに、高効率なカーネル間通信でwrite命令のルーティングとTick−IDによる一貫性制御を行う。このように、本実施形態は、ルータ等の専用ネットワーク機器やアプリケーション固有のパケット送受信処理を用いずに、標準的なカーネルの機能のみで所定のパケットを適切な受信先へと送り届ける機能を実現するという特徴を有する。
なお、上記カーネル間通信が行われないサーバ間(疑似IPマルチキャストネットワーク構造で直接接続されていないサーバ間)で同期が必要になった時は、例えば、通常のアプリケーションレベルのIP通信を採用し、必要な時にプル型で更新情報を送受信(同期)することができる。
また、本実施形態は、カーネルのパケット転送フィルタを用いた疑似IPマルチキャストを用いるため、ネットワークの設定を変更することなく、柔軟にサーバからの同期先を変更することができる。1つのサーバが複数のサーバからの同期を受け入れることも可能である。
一般的に、プッシュ型同期では、プッシュされたデータ間の整合性、一貫性を管理することが極めて重要となるが、本実施形態では、ゲーム固有の時間情報(Tick−ID等)を用いてメモリの更新/読み出し操作を直列化する。このため、従来の分散データベースの問題であった、データ整合性の問題を生じさせずに分散処理を行うことができる。したがって、ゲーム用途においては、ほとんどの場合はロックフリーで動作するインメモリデータベースとしてふるまうことが可能である。
<処理の概要>
次に、本実施形態のゲームシステムの処理の概要を説明する。本実施形態のゲームシステムは複数のサーバを有する。そして、複数のサーバ各々がゲーム空間内の複数のエリア各々を担当する。各サーバは、プレイヤ入力又は自装置内で生成された制御情報に基づき、自サーバが担当するエリア内に存在するオブジェクトのオブジェクト情報(上記ステート情報に対応)の更新を行う。
そして、複数のサーバは、各サーバが管理するオブジェクト情報を同期する処理を行う。互いの間をオブジェクトが頻繁に移動する2つのエリア各々を担当するサーバ間では、OSのカーネルを用いた疑似IPマルチキャスト処理でプッシュ型の同期を行う。
プッシュ型の同期では、各サーバのOSは、他のサーバからのリクエストなしで、予め登録されている対象サーバのMACアドレスを宛先としたデータリンク層(L2)のデータに基づくパケット転送により、更新情報を当該対象サーバに送信する。このような処理により、即時かつ高速な同期が実現される。対象サーバは、複数のサーバの中の一部である。どのサーバを対象サーバとするかはサーバごとに決定される。各サーバが担当するエリアとの間でのオブジェクトの行き来が高頻度で行われるエリアを担当するサーバが、各サーバの対象サーバとして設定される。
プッシュ型の同期は、例えば、サーバが受信した全データを常に所定のサーバ群へとコピーすることとする。これを、レプリケーションと呼ぶ。変形例として、プッシュ型の同期では、逐次的にパケットをコピーするのではなく、一定期間バッファリングしてからコピーしてもよい。
なお、プッシュ型の同期が行われないサーバ間で同期が必要になった時は、例えば、通常のアプリケーション層の通信、例えばIP通信を採用し、必要な時にプル型で更新情報を送受信することができる(プル型の同期)。例えば、第1のサーバの対象サーバとして設定されておらず、第1のサーバとの間でプッシュ型の同期が行われないサーバが、必要に応じて第1のサーバに更新情報を要求する。プッシュ型の同期は、パケットを受け取ったサーバが能動的にパケットを他のサーバに転送することを意味する。プル型の同期は、情報が必要になったサーバがその情報を他のサーバに要求して取得することで、必然的に同期が行われるというものである。
プル型の同期では、各サーバ上で稼働するアプリケーションは、他のサーバからのリクエストに応じて、例えばIP通信で、更新情報を他のサーバに送信する。リクエストを発生させることができるのは、データが必要とされているという状況を認識できるアプリケーションのみである。このため、このプル型の同期は、必然的に、アプリケーション層の処理が必要になる。なお、アプリケーション層の処理を要する通信では、異なる階層間でのデータの受け渡し等が発生するうえ、コンテキストスイッチが必要になるため、一般的に、1バイトあたりの送受信に必要な時間が大きくなる。このため、当該プル型の同期は、プッシュ型の同期に比べて低速な同期となる。プル型の同期では、更新内容のみを送受信してもよし、リクエストで指定された内容のみを送受信してもよい。
以上、本実施形態では、互いが担当するエリア間でオブジェクトの行き来が高頻度で行われるサーバ間は、疑似IPマルチキャストネットワーク構造で直接接続し(カーネル上のパケット転送設定において、互いのMACアドレスを宛先として登録)、プッシュ型の同期で即時かつ高速な同期を行う。プッシュ型の同期の設定を、仮想空間上の地理的関係に基づいて行うことにより、プッシュ型の同期によるデータの共有率を高く保ちながら、プッシュ同期にかかるCPU負荷、ネットワーク負荷を低く抑えることができる。
また、本実施形態では、サーバ間で送受信する更新情報の中にTick−ID等の時間情報を含める。そして、この時間情報を用いて、メモリの更新/読み出し操作を直列化する。これによりデータ間の整合性や一貫性を管理することが可能となる。
<ゲームシステムの全体構成>
次に、本実施形態のゲームシステムの全体構成を説明する。図1に示すように、ゲームシステムは、複数のサーバ10を有する。
複数のサーバ10は、同一のネットワークもしくはクラウド上の同一の仮想ネットワーク内に位置し、データリンク層のアドレス(MACアドレス)に基づくパケット転送により、互いにデータの送受信ができるようになっている。例えば、複数のサーバ10は、同一の仮想ネットワーク内(例えば、仮想ネットワークサーバを論理的に分割することで生成されたサブネット)に存在することができる。例えば、非特許文献15に開示の技術を利用して、このような複数のサーバ10の構成を実現することができる。
複数のサーバ10は、インターネット30を介して、複数のプレイヤ端末20と接続される。プレイヤ端末20は、プレイヤが操作する端末であり、例えばスマートフォン、タブレット端末、PC(personal computer)、携帯電話、ゲーム端末等が例示されるが、これらに限定されない。
<サーバ10の構成>
次に、サーバ10の構成を説明する。まず、サーバ10のハードウエア構成を説明する。本実施形態のサーバ10が備える各機能部は、任意のコンピュータのCPU(Central Processing Unit)、メモリ、メモリにロードされるプログラム、そのプログラムを格納するハードディスク等の記憶ユニット(あらかじめ装置を出荷する段階から格納されているプログラムのほか、CD(Compact Disc)等の記憶媒体やインターネット上のサーバ等からダウンロードされたプログラムをも格納できる)、ネットワーク接続用インターフェイスを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
図2は、本実施形態のサーバ10のハードウエア構成を例示するブロック図である。図2に示すように、サーバ10は、プロセッサ1A、メモリ2A、入出力インターフェイス3A、周辺回路4A、バス5Aを有する。周辺回路4Aには、様々なモジュールが含まれる。サーバ10は周辺回路4Aを有さなくてもよい。
なお、サーバ10は物理的及び/又は論理的に分かれた複数の装置で構成されてもよい。すなわち、1つのサーバ10は、複数の装置のクラスタとして構成されてもよい。この場合、各装置が上記ハードウエア構成を備えることができる。その他、サーバ10は、物理的及び論理的に1つの装置で構成されてもよい。
バス5Aは、プロセッサ1A、メモリ2A、周辺回路4A及び入出力インターフェイス3Aが相互にデータを送受信するためのデータ伝送路である。プロセッサ1Aは、例えばCPU、GPU(Graphics Processing Unit)などの演算処理装置である。メモリ2Aは、例えばRAM(Random Access Memory)やROM(Read Only Memory)などのメモリである。入出力インターフェイス3Aは、入力装置、外部装置、外部サーバ、外部センサ等から情報を取得するためのインターフェイスや、出力装置、外部装置、外部サーバ等に情報を出力するためのインターフェイスなどを含む。入力装置は、例えばキーボード、マウス、マイク等である。出力装置は、例えばディスプレイ、スピーカ、プリンター、メーラ等である。プロセッサ1Aは、各モジュールに指令を出し、それらの演算結果をもとに演算を行うことができる。
次に、サーバ10の機能構成を説明する。本実施形態のゲームシステムが提供するゲームは、例えばオープンワールド型MMOゲームである。図3に示すように、ゲーム空間は複数のエリアに分かれている。ゲーム空間内に存在するオブジェクトは、エリア間を移動可能である(すなわち、エリアを跨いだ移動が可能)。オブジェクトは、プレイヤにより制御されるプレイヤオブジェクトや、プレイヤにより制御されないノンプレイヤオブジェクトを含む。オブジェクトは、キャラクタ、弓、銃弾、鳥等のあらゆるオブジェクトを含む。各サーバ10は、複数のエリア各々を担当する。
ここで、「エリアを担当する」の概念を説明する。複数のエリアの中の第1のエリアを担当するサーバ10は、第1のエリアに存在するオブジェクトの状態を示すオブジェクト情報を記憶し、プレイヤ入力で生成された制御情報、又は、自装置で決定した制御情報に基づき、そのオブジェクト情報を更新する。そして、第1のエリアを担当するサーバ10は、第1のエリアに存在するオブジェクトのオブジェクト情報の更新内容を示す更新情報を、他のサーバ10に送信する。このように、第1のエリアを担当するサーバ10は、上述のような処理で担当するエリアに存在するオブジェクトのオブジェクト情報を更新するとともに、その更新内容を他のサーバ10に送信する。
なお、以下の説明で明らかになるが、第1のエリアを担当するサーバ10は、第1のエリアに存在するオブジェクトのオブジェクト情報のみならず、担当するエリアの外に存在するオブジェクトのオブジェクト情報も記憶し、更新する。例えば、第1のエリアを担当するサーバ10は、第1のエリアとの間でのオブジェクトの行き来が高頻度で行われるエリアを担当するサーバ10からプッシュ型の同期で受信したそのエリアに存在するオブジェクトのオブジェクト情報を記憶し、更新する。また、例えば、第1のエリアを担当するサーバ10は、その他のエリアを担当するサーバ10からプル型の同期で受信したそのエリアに存在するオブジェクトのオブジェクト情報を記憶し、更新する。
しかし、担当するエリアに存在するオブジェクトのオブジェクト情報の更新方法と、担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新方法は異なる。具体的には、担当するエリアに存在するオブジェクトのオブジェクト情報の更新方法は上述の通りである。これに対し、担当するエリアの外に存在するオブジェクトのオブジェクト情報は、他のサーバ10からプッシュ型又はプル型の同期で受信した更新情報に基づき更新される。また、サーバ10は、担当するエリアの外に存在するオブジェクトのオブジェクト情報を更新しても、その更新内容を示す更新情報を他のサーバ10に送信しない。この点でも、担当するエリアに存在するオブジェクトと他のエリアに存在するオブジェクトとの扱いが異なる。
図4に、サーバ10の機能ブロック図の一例を示す。図示するように、サーバ10は、オブジェクト情報記憶部11と、第1の更新部12と、第1の送信部13と、MACアドレス記憶部14と、第2の更新部15と、第2の送信部16とを有する。
オブジェクト情報記憶部11は、ゲーム空間内に存在するオブジェクトの状態を示すオブジェクト情報を記憶する。オブジェクト情報は、ゲーム空間におけるオブジェクトの位置を示す位置情報、オブジェクトの向きを示す向き情報、ヒットポイント、攻撃力、防御力、レベル等のあらゆる情報を含む。
各サーバ10のオブジェクト情報記憶部11は、ゲーム空間内に存在する複数のオブジェクトの中の一部のオブジェクトのオブジェクト情報を記憶する。オブジェクト情報記憶部11は、自サーバ10が担当するエリア内に存在するオブジェクトのオブジェクト情報を記憶する。
ここで、「自サーバ10」について説明する。まず、複数のサーバ10の中の1つである第1のサーバ10内に実現された機能部(オブジェクト情報記憶部11、第1の更新部12、第1の送信部13、MACアドレス記憶部14、第2の更新部15及び第2の送信部16)を第1の機能部と定義する。この場合、第1の機能部にとって第1のサーバ10は「自サーバ10」となる。そして、第1の機能部にとって、第1のサーバ10以外のサーバ10は「他のサーバ10」となる。
オブジェクト情報記憶部11の構成の説明に戻る。オブジェクト情報記憶部11は、自サーバ10が担当するエリアの外に存在するオブジェクトのオブジェクト情報を記憶することもできる。具体的には、オブジェクト情報記憶部11は、同期処理で他のサーバ10から受信したオブジェクト情報を記憶する。すなわち、オブジェクト情報記憶部11は、プッシュ型の同期処理により、疑似IPマルチキャストネットワーク構造で自サーバ10と直接接続されている他のサーバ10から受信したオブジェクト情報を記憶する。また、オブジェクト情報記憶部11は、例えばプル型の同期処理により、疑似IPマルチキャストネットワーク構造で自サーバ10と直接接続されていない他のサーバ10から受信したオブジェクト情報を記憶する。
図5に、オブジェクト情報の一例を模式的に示す。図示するように、オブジェクト情報は、各パラメータの更新タイミングを示す情報をさらに含むことができる。更新タイミングは、例えばゲーム内時間を示す時間情報で示される。ゲーム内時間を示す時間情報の一例として、Tick−IDが例示される。以下、ゲーム内時間を示す時間情報はTick−IDである前提とする。なお、パラメータ毎に更新タイミングを管理する手法に代えて、オブジェクト毎に更新タイミングを管理する手法を採用してもよい。
ここで、Tick−IDについて説明する。Tick−IDは、複数のサーバ10各々により同一の処理で生成される。各サーバ10は、所定時間毎にTick−IDを更新する。例えば、Tick−IDは数字で示され、各サーバ10は、所定時間毎にTick−IDを所定数ずつ(例えば「1」)増加させる。Tick−IDの更新周期は、例えば0.03〜0.05秒(20Hz〜30Hz程度)である。NTP(network time protocol)を用いる方法や、全てのサーバ10に原子時計を配備する方法等の任意の手段で、複数のサーバ10は同じタイミングで同じ値のTick−IDを生成するように同期されている。
図4に戻り、第1の更新部12は、オブジェクト情報記憶部11に記憶されているオブジェクト情報のうち、自サーバ10が担当するエリア内に存在するオブジェクトのオブジェクト情報の更新を行う。
例えば、第1の更新部12は、自サーバ10が担当するエリアに存在するプレイヤオブジェクトの制御情報をプレイヤ端末20から受信し、その制御情報に基づきそのプレイヤオブジェクトのオブジェクト情報を更新する。プレイヤオブジェクトの制御情報は、例えばプレイヤ端末20を介したプレイヤ入力に基づき生成される。制御情報は、プレイヤ入力の内容を示す情報(タッチ位置を時系列に示すデータ、当該データに基づき算出された大きさや方向を示すデータ等)であってもよいし、プレイヤ入力の内容に基づきプレイヤ端末20が決定した制御内容(プレイヤオブジェクトの移動量、移動方向、移動後の位置等)を示す情報であってもよい。
また、例えば、第1の更新部12は、自サーバ10が担当するエリアに存在するノンプレイヤオブジェクトの制御内容を決定し、そのノンプレイヤオブジェクトのオブジェクト情報を更新する。ノンプレイヤオブジェクトの制御内容を決定するアルゴリズムは設計的事項である。
上述のような処理でオブジェクト情報を更新する第1の更新部12は、自サーバ10が担当するエリアに存在するオブジェクトのオブジェクト情報の更新のみを行い、自サーバ10が担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新は行わない。
第1の更新部12は、Tick−IDに基づき、時系列順のオブジェクト情報の更新を実現する。例えば、第1の更新部12は、所定のオブジェクトのオブジェクト情報の所定のパラメータを更新する際、まず、オブジェクト情報記憶部11が記憶するオブジェクト情報を参照して(図5参照)、そのパラメータの最新の更新タイミングのTick−IDを特定する。そして、最新の更新タイミングのTick−IDが、今回の更新タイミングのTick−ID(現時点のTick−ID)よりも時間的に前である場合、問題ないので第1の更新部12は更新処理を実行する。一方、最新の更新タイミングのTick−IDが、今回の更新タイミングのTick−ID(現時点のTick−ID)よりも時間的に後である場合、問題ありなので第1の更新部12は更新処理を実行しない。この場合、第1の更新部12は任意のエラー処理を実行する。
MACアドレス記憶部14は、複数のサーバ10の中の一部である対象サーバのMACアドレスを記憶する。図6に、MACアドレス記憶部14が記憶する対象サーバ情報の一例を模式的に示す。対象サーバ情報の内容は、サーバ10毎に異なる。すなわち、サーバ10毎に、どのサーバ10を対象サーバとするかは異なる。
例えば、MACアドレス記憶部14は、自サーバ10が担当するエリアとの地理的関係が所定条件を満たすエリアを担当するサーバ10のMACアドレスを記憶する。すなわち、自サーバ10が担当するエリアとの地理的関係が所定条件を満たすエリアを担当するサーバ10が、自サーバ10の対象サーバとなる。所定条件は、「一方のエリア内から他方のエリア内へのオブジェクトの移動に要する最短の時間が基準値以下」、「互いに隣接する」、「互いに隣接し、かつ、互いの境界部分にエリア間移動を妨げる障害物がない」、「互いの最短距離が、任意のオブジェクト(弓矢や砲弾等のキャラクタ外のオブジェクト等)の移動距離以内」、「ゲーム上、他のエリアを介さずに互いのエリア間を移動可能になっている(徒歩等での隣接エリア間移動、ワープ等での互いに離れたエリア間移動等)」等が例示されるが、これに限定されない。
図6に示すような対象サーバ情報は、ゲームシステムを管理するオペレータにより生成される。例えば、オペレータは、サーバ10毎に対象サーバのMACアドレスを入力することで、図6に示すような対象サーバ情報を生成してもよい。
その他、各サーバ10は、図7に示すような他のサーバ10に関するサーバ情報を記憶しておいてもよい。サーバ情報は、他のサーバ10各々のサーバ識別情報と、他のサーバ10各々のMACアドレスと、他のサーバ10各々が担当するエリアの識別情報とが紐づけられている。この場合、オペレータは、サーバ10毎に対象サーバとするサーバ10のサーバ識別情報を入力してもよい。そして、サーバ10は、入力されたサーバ識別情報に紐づくMACアドレスをサーバ情報から取得し、対象サーバ情報に登録してもよい。その他、オペレータは、サーバ10毎に対象サーバとするサーバ10が担当しているエリアのエリア識別情報を入力してもよい。そして、サーバ10は、入力されたエリア識別情報に紐づくMACアドレスをサーバ情報から取得し、対象サーバ情報に登録してもよい。
なお、MACアドレス記憶部14への対象サーバのMACアドレスの登録は、例えばサーバ10にインストールされたOSのカーネルが提供するネットワークトラフィック制御機能におけるパケット送信先のMACアドレスの登録(フィルタリングの設定)で実現される。
第1の送信部13は、対象サーバからのリクエストなしで、MACアドレス記憶部14に記憶されたMACアドレスを宛先としたデータリンク層のデータ(MACアドレス等)に基づくパケット転送により、第1の更新部12によるオブジェクト情報の更新内容を示す更新情報を対象サーバに送信する。第1の送信部13は、第1の更新部12によるオブジェクト情報の更新に応じて、その更新内容を示す更新情報を対象サーバに送信することができる。更新が行われたタイミングから更新情報の送信までのタイムラグ(経過時間)はできるだけ小さいのが好ましい。
更新情報には、更新が行われたタイミングを示す情報(更新時のTick−ID)が含まれる。
なお、上述したデータリンク層のデータ(MACアドレス等)を利用した一部のサーバ10(対象サーバ)への更新情報の送信は、例えばOSのネットワークトラフィック制御機能におけるパケットフィルタリング機能で実現される。
第2の更新部15は、プッシュ型同期又はプル型同期で他のサーバ10から受信した更新情報に基づき、オブジェクト情報記憶部11に記憶されているオブジェクト情報のうち、自サーバ10が担当するエリアの外(自サーバ10が担当しないエリア)に存在するオブジェクトのオブジェクト情報の更新を行う。
なお、上述のような処理でオブジェクト情報を更新する第2の更新部15は、自サーバ10が担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新のみを行い、自サーバ10が担当するエリアに存在するオブジェクトのオブジェクト情報の更新は行わない。
第2の更新部15は、Tick−IDに基づき、時系列順のオブジェクト情報の更新を実現する。例えば、第2の更新部15は、所定のオブジェクトのオブジェクト情報の所定のパラメータを更新する際、まず、オブジェクト情報記憶部11が記憶するオブジェクト情報を参照して(図5参照)、そのパラメータの最新の更新タイミングのTick−IDを特定する。そして、最新の更新タイミングのTick−IDが、更新情報に含まれるTick−ID(他のサーバ10で更新が行われ時のTick−ID)よりも時間的に前である場合、問題ないので第2の更新部15は更新処理を実行する。一方、最新の更新タイミングのTick−IDが、更新情報に含まれるTick−ID(他のサーバ10で更新が行われ時のTick−ID)よりも時間的に後である場合、問題ありなので第2の更新部15は更新処理を実行しない。この場合、第2の更新部15は任意のエラー処理を実行する。
例えば、第2の更新部15は、プッシュ型同期で更新情報が送受信された場合、更新・読み出しの操作に紐付くTick−IDに基づいて更新・読み出し操作を直列化する(更新・読み出しの順序を決定する)。そして、順序を決定した後、データ競合の問題が生じるときは、第2の更新部15は例外をゲームロジックへ通知する。ゲームロジック側は、例えば、プレイヤごとに優先順位を設ける方式や、あるいは、エフェクトで競合状態をごまかすなどの方法(ゲームロジックの処理は設計事項)で、データ競合を解消する。データ競合の問題は、例えば、同一のTick−IDで、かつ、同一のメモリブロックアドレスへ、read操作とwrite操作が行われる場合や、同一のTick−IDで、かつ、同一のメモリブロックアドレスへ、2つ以上のwrite操作が行われる場合である。
図4に戻り、第2の送信部16は、他のサーバ10からのリクエストに応じて、IP通信で、オブジェクト情報記憶部11に記憶されているオブジェクト情報を他のサーバ10に送信する。第2の送信部16は、各パラメータの更新タイミングを含むオブジェクト情報を他のサーバ10に送信することができる。当該IP通信におけるネットワーク層のプロトコルはIPプロトコルであり、トランスポート層のプロトコルは、TCP(Transmission Control Protocol)プロトコルやUDP(User Datagram Protocol)プロトコル等である。
他のサーバ10からのリクエストは、オブジェクトを指定する情報が含まれてもよい。そして、第2の送信部16は、オブジェクト情報記憶部11に記憶されているオブジェクト情報のうち、指定されたオブジェクトのオブジェクト情報を他のサーバ10に送信してもよい。
次に、サーバ10の処理の流れの一例を説明する。
まず、図8のフローチャートを用いて、「自サーバ10が担当するエリアに存在するオブジェクトのオブジェクト情報を更新し、更新情報を対象サーバに送信する処理」の流れの一例を説明する。
第1の更新部12は、自サーバ10が担当するエリアに存在するオブジェクトに関する制御情報の取得待ちとなっている(S10)。例えば、第1の更新部12は、自サーバ10が担当するエリアに存在するプレイヤオブジェクトの制御情報をプレイヤ端末20から受信することができる。また、第1の更新部12は、自サーバ10内で生成された自サーバ10が担当するエリアに存在するノンプレイヤオブジェクトの制御情報を取得することができる。
制御情報を取得すると(S10のYes)、第1の更新部12は、制御情報に基づきオブジェクトの更新内容を決定する(S11)。例えば、制御情報がオブジェクトの移動方向や移動距離を示す場合、第1の更新部12は、現在のそのオブジェクトの位置と当該制御情報とに基づき、そのオブジェクトの新たな位置を決定する。なお、制御情報に基づく更新内容の決定処理の詳細は設計的事項であり、この例示に限定されない。
その後、第1の更新部12は、オブジェクト情報記憶部11が記憶するオブジェクト情報を参照し(図5参照)、更新対象のオブジェクトの更新対象のパラメータの最新の更新タイミングを示すTick−IDを取得する(S12)。そして、最新の更新タイミングを示すTick−IDと、今回の更新タイミングのTick−ID(現時点のTick−ID)と、を比較する(S13)。
最新の更新タイミングのTick−IDが、今回の更新タイミングのTick−IDよりも時間的に前であり、矛盾しない場合(S13のNo)、第1の更新部12は、S11で決定した更新内容に基づき、オブジェクト情報記憶部11が記憶するオブジェクト情報を更新する(S14)。この時、第1の更新部12は、更新したオブジェクトの更新したパラメータに紐づく更新タイミングを示す情報を、今回の更新タイミングを示すTick−IDに更新する。
次いで、第1の送信部13は、S14の更新に応じて、対象サーバからのリクエストなしで、MACアドレス記憶部14に記憶されたすべてのMACアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、S14でのオブジェクト情報の更新内容を示す更新情報を対象サーバに送信する(S15)。
一方、最新の更新タイミングのTick−IDが、今回の更新タイミングのTick−IDよりも時間的に後であり、矛盾する場合(S13のYes)、第1の更新部12は、S11で決定した更新内容に基づくオブジェクト情報の更新を行わず、任意のエラー処理を行う(S16)。
以降、サーバ10は同様の処理を繰り返す。
次に、図9のフローチャートを用いて、「他のサーバ10からのリクエストに応じて他のサーバ10にオブジェクト情報を送信する処理」の流れの一例を説明する。
第2の送信部16は、他のサーバ10からのリクエスト待ちとなっている(S20)。そして、第2の送信部16は、他のサーバ10からオブジェクト情報のリクエストを受信すると(S20のYes)、IP通信で、オブジェクト情報記憶部11に記憶されているオブジェクト情報を他のサーバ10に送信する(S21)。
他のサーバ10からのリクエストは、オブジェクトを指定する情報が含まれてもよい。そして、第2の送信部16は、オブジェクト情報記憶部11に記憶されているオブジェクト情報のうち、指定されたオブジェクトのオブジェクト情報を他のサーバ10に送信してもよい。
以降、サーバ10は同様の処理を繰り返す。
次に、図10のフローチャートを用いて、「他のサーバ10からの更新情報の取得に応じて、自サーバ10が担当するエリアの外に存在するオブジェクトのオブジェクト情報を更新する処理」の流れの一例を説明する。
第2の更新部15は、他のサーバ10からの更新情報受信待ちとなっている(S30)。そして、第2の更新部15は、他のサーバ10から更新情報を受信すると(S30のYes)、オブジェクト情報記憶部11が記憶するオブジェクト情報を参照し(図5参照)、更新対象のオブジェクトの更新対象のパラメータの最新の更新タイミングを示すTick−IDを取得する(S31)。そして、最新の更新タイミングを示すTick−IDと、更新情報に含まれる更新タイミングのTick−ID(他のサーバ10で更新が行われ時のTick−ID)と、を比較する(S32)。
最新の更新タイミングのTick−IDが、更新情報に含まれる更新タイミングのTick−IDよりも時間的に前であり、矛盾しない場合(S32のNo)、第2の更新部15は、受信した更新情報で示される更新内容に基づき、オブジェクト情報記憶部11が記憶するオブジェクト情報を更新する(S33)。この時、第2の更新部15は、更新したオブジェクトの更新したパラメータに紐づく更新タイミングを示す情報を、更新情報に含まれる更新タイミングを示すTick−IDに更新する。
一方、最新の更新タイミングのTick−IDが、更新情報に含まれる更新タイミングのTick−IDよりも時間的に後であり、矛盾する場合(S32のYes)、第2の更新部15は、受信した更新情報で示される更新内容に基づくオブジェクト情報の更新を行わず、任意のエラー処理を行う(S34)。
以降、サーバ10は同様の処理を繰り返す。
<実施例>
次に、本実施形態のサーバ10をより具体化した実施例を説明する。なお、当該実施例は上述した実施形態を具体化する一例であり、本実施形態の具体化手段はこれに限定されない。
従来の分散共有メモリにおいてリモートノードへのメモリアクセス頻度を低減するためには、ノード間で更新されたメモリ内容を頻繁に同期する必要がある。このため、N台のノードがあるとき、Nの通信量が発生してしまっていた。本実施例は、MMOというアプリケーション固有の制約として、仮想空間上のメッシュ構造をデータ同期の範囲として採用することにより、Nよりもはるかに小さい同期範囲で、実質的に必要なデータ同期を実現する。
本実施例によるサーバ10間の同期の全体像を図11に示す。本実施例では、ゲーム空間を複数のエリアに分割し、各サーバ10が各エリアを担当する。そして、本実施例では、例えば互いに近傍する複数のエリアを担当する複数のサーバ10間で、上述したプッシュ型の同期が実行される。なお、互いに近傍しない複数のエリアを担当する複数のサーバ10間では、上述したプッシュ型の同期が実行されない。これにより、全サーバ10の内容を同期せずとも、実質的に均一な分散データベースを形成できる。
また、本実施例では、上記実施形態では説明しなかったが、各エリアはシャード化かつレプリカ化され、負荷分散されてもよい。シャードの分散単位は、プレイヤ単位としてもよいし、オブジェクト単位としてもよいし、その他であってもよい。一例としてシャードの分散単位をプレイヤ単位とした場合、複数のサーバ10各々で管理される同一プレイヤの情報は同じシャードに格納される。例えばすべてのシャードはプレイヤIDに適用するハッシュ関数を共有するため、近傍の同一階層シャードは同一プレイヤの情報を格納することになる。このため、同一階層のシャード間で同期処理を行えばよく、サーバ10の処理負担が軽減される。
また、本実施例では、全てのデータ更新/参照操作について、Tick−IDで実行順序と整合性を制御することにより、トランザクション隔離レベル問題を解消することができる。すなわち、全ての操作が直列化可能で、全てのエリアをフラットに参照可能なデータベースとして扱うことができる。
本実施例は、AWS(非特許文献15参照)の各ノード(EC2インスタンス)で、カーネル上でパケット転送設定をすると、実質的にマルチキャストできるという機能に着目し、分散共有メモリの各ノードのカーネルをルータにするという、「ルータ機能埋め込み型のDSM(Distributed Shared Memory)」を実現するものである。これにより、ゲームのマップ情報と完全に一致する疑似IPマルチキャストネットワーク構造をクラウド上で静的に構築すると、ゲームのTick−IDさえパケット内に含まれていれば、IPマルチキャストだけの超高効率なデータレプリケーション・データ同期が可能になる。
本実施例のシステム構成図を、図12に示す。本システムは、完全にリニアなアドレス空間を、全サーバ10をまたがる形でシームレスに提供するわけではなく、図中の"Key−A"に示されるように、文字列で識別可能な変数を各サーバ10間で自動的に同期する仕組みである。すなわち、"key−name"を変数ととらえれば、複数のサーバ10間で共有される変数(メモリブロック)を提供する仕組みといえる。その点で、既存の分散共有メモリと大きく異なる。
本実施例は、1つのノード(サーバ10)に閉じて実装することができる3つのモジュールから構成される。
1つ目のモジュールである[M1]Tick Managerは、ゲームの時間単位であるTick−IDを管理するモジュールであり、原則的には実時間に同期している。この同期は、NTP(Network Time Protocol)などの既存の安定した実装を用いることで容易に実装することができる。
2つ目のモジュールである[M2]Memory Managerは、後述のAPIをサーバ10側のロジックに提供することにより、分散共有メモリを管理するモジュールである。Memory managerは、Tick−IDを用いてメモリの更新/読み出し操作を直列化する。もし、Memory ManagerがTick−IDを用いてデータ競合を検出した場合、ゲームロジック型に例外が通知される。ゲームロジック側は、例えば、プレイヤごとに優先順位を設ける方式や、あるいは、エフェクトで競合状態をごまかすなどの方法(ゲームロジックの処理は設計事項)で、データ競合を解消する。データ競合の問題は、例えば、同一のTick−IDで、かつ、同一のメモリブロックアドレスへの操作(read/write)が行われた等である。
最も重要な3つめのモジュールは、カーネル内部で動作する[M3]Custom L2 Multicast Moduleである。このモジュールは、サーバのMACアドレスを相互にマルチキャスト先に登録することにより、データリンク層でのパケット転送のネットワーク構造(疑似IPマルチキャストネットワーク構造)を形成する。このネットワーク構造は、ゲームの仮想空間におけるエリア(各サーバ10が担当するエリア)の近傍関係に対応しており、地理的に近いサーバ10が接続され、遠いサーバ10は接続されない。本実施例は、このように連結されたサーバ10間で共有メモリへの書き込みが、直ちにL2パケット転送を通じて共有されるものである。
このL2パケット転送について詳述する。パブリッククラウドを構成する仮想ルータの多くは、IPマルチキャストをサポートしておらず、ネットワーク設定だけでマルチキャストを行うことはできない(非特許文献15参照)。そのため、マルチキャストをクラウドサービス上で活用することは困難だと考えられてきた。
しかしながら、クラウドサービスでは、各ノードのMACアドレスなどの管理情報を、ルータに頼らずに、クラウドの管理システムから動的に入手することができる。このため、クラウド上のノードは、クラウド全体のノード構造を知ることができる。したがって、各ノードでマルチキャストパケットを処理し、独自にマルチキャストを行うことにより、疑似的にマルチキャストをクラウド上で実装することができる。本実施例では、これを疑似IPマルチキャストと呼ぶ。
さらに、この疑似IPマルチキャストでは、パケットの送信先を、OSのカーネルが提供するネットワークトラフィック制御機能におけるパケットフィルタの設定だけで変更することができる。このため、柔軟にマルチキャスト処理を変更することも可能になる。従来のオンメモリデータベースの分散処理では、仮想空間の位置関係、というアプリケーション固有の情報はアプリケーションしか持ちえないため、OSレイヤでの最適化処理に用いることはできなかった。本実施例では、データ同期/データ・レプリケーションという、シンプルな情報伝搬に着目することにより、データリンク層での高効率な実装を可能にしている。
本実施例が提供するAPIについて説明する。本システムを構成するAPIは、5つのコアAPIと、4つの付属APIである。
(1) chain([MAC_ADDRESS1, MAC_ADDRESS2, MAC_ADDRESS3, ... MAC_ADDRESSn])
chain APIは、このAPIが起動されたサーバ10から、MAC_ADDRESS1〜nを有するサーバ10へのパケット転送設定を行う。これにより、マルチキャストパケットをこのサーバ10へ送るだけで、MAC_ADDRESS1〜nを有するサーバ10へL2パケット処理だけで転送が行われる。本システムは、このchainにより連結されたサーバ10間で、後述のopenで生成されたスマートポインタ経由のメモリ書き込みが、直ちにL2パケット転送を通じて共有されるというものである。
(2) open("key-name(e.g. /root/world1/cell-id)", [READ_ONLY, WRITE_ONLY, RW]) → sptr
open APIは、共有メモリへの参照を作成するAPIである。ここで、関数の戻り値であるsptrとは、Smart Pointer to Distributed Shared Memoryの略で、共有メモリへの参照を管理するオブジェクトである。key−nameには、空白を含まない、任意のASCII文字列を指定することができる。上述の例のように、"/"等でディレクトリに分かれている必要はない。パケットサイズを不要に圧迫することは好ましくなく、例えば、最大で255文字、というような制限を加えることが好ましい。"key−name"のメモリブロックが存在しない場合は、例外が発生する。
本実施例が提供するメモリブロックの概要図を図13に示す。すべてのメモリブロック(オブジェクト)にはその時点で格納されている情報が生成/更新された時のTick−IDが付与される。共有メモリに格納されるオブジェクトのサイズL1は固定長であることが好ましい。共有メモリ全体のサイズL2もシステム起動時に十分確保され、固定長であることが好ましい。連結リスト等を用いることにより、可変長とすることができるが、ランダムアクセス性能が落ちるため好ましくない。共有メモリは、例えば、固定長オブジェクトの配列としてモデル化され、名前で識別される。
(3)(write) sptr[i] = a
これは、共有メモリへの書き込みを行うAPIである。書き込まれたメモリセグメントは直ちにサーバ10側でレプリケーションされる。このとき、aとして示されているオブジェクトには、そのオブジェクトの状態が生成されたときのゲーム内時間であるTick−IDが記録されており、本システムは、メモリブロックへの書き込み時に、その書き込みのTick−IDを使って、書き込みの直列化をする。
これにより、メモリへの並列書き込みをロックフリーで実行することができる。同一のTick−IDで、かつ、同一のメモリブロックアドレス(上記の例ではiで示されている)への操作が行われたときは、本システムは例外をゲームロジックへ通知する。ゲームロジック側は、例えば、プレイヤごとに優先順位を設ける方式や、あるいは、エフェクトで競合状態をごまかすなどの方法で、データ競合を解消する。変数aのサイズは静的に決まっていることが好ましいが、完全に動的に処理する場合は、書き込みロジックを工夫すればよい。
(4)a = sptr[i]
これは、共有メモリからの読み込みを行うAPIである。なお、書き込み時と同様に、変数aが有するTick−IDと、当該ブロック[i]に格納されているTick−IDを比較し、もし、ブロック[i]のTick−IDが変数aのTick−IDと同じか新しいときは、データ競合が発生しているため、本システムは例外をゲームロジックへ通知する。この例外処理は、変数aの=演算子により実装される。
(5)replicate("key-name", index, blocks)
マルチキャストされたL2パケットをカーネルが受信すると、このreplicate APIが呼ばれる。このAPIは、特定のkey−nameにバインドされたメモリブロックの、index以降のアドレスをblocksで上書きする。blocksは、1つ以上のオブジェクトを示すバイト列である。本システムでは、同一アーキテクチャの計算機を用いることを想定し、かつ、共有メモリ内にはポインタ等を含まないため、オブジェクトは特別なシリアライズ/デシリアライズ処理を経ずにそのままメモリ内に格納される。"key−name"のメモリブロックが存在しない場合は、不正な状態が発生しているので、深刻なエラーとして処理する。
本実施例は、カーネルのパケット転送フィルタを用いた疑似IPマルチキャストを設定するための(1)chain APIと、共有メモリブロックへの参照を作成する(2)open API、(3)書き込みAPI、(4)読み込みAPI、そして、レプリケーションされるデータがマルチキャストパケットとして到着したときに呼び出される(5)replicate APIを主要なAPIとしている。本実施例は、実質的にはこの5つのAPIにより主要な機能が実装される。以下に示す(6)〜(9)のAPIは、実装上必要なAPIではあるが、本実施例の本質的な機能を提供するものではない。
(6)close(sptr)
分散共有メモリへの参照を閉じる。スマートポインタなので、スコープを外れれば参照は消えるので、基本的にはcloseは呼ばなくて良い。
(7)create("key-name", size)
create APIは、size分だけ、分散共有メモリのブロックを、"key−name"の名前で確保する。メモリセグメントの確保命令は、直ちにサーバ10側でreplicationされ、create APIコールとして他サーバ10で処理される。既に"key−name"のメモリブロックが存在する場合は、例外が発生する。
(8)delete("key-name")
delete APIは、"key−name"の名前を有する分散共有メモリのブロックを削除する。メモリセグメントの削除命令は、直ちにサーバ10側でreplicationされ、delete APIコールとして他サーバ10で処理される。"key−name"のメモリブロックが存在しない場合は、例外が発生する。
(9)resize("key-name", size)
resize APIは、"key−name"の名前で確保された分散共有メモリのブロックを、size分だけ、拡張する。メモリセグメントのリサイズ命令は、直ちにサーバ10側でreplicationされ、resize APIコールとして他サーバ10で処理される。"key−name"のメモリブロックが存在しない場合は、例外が発生する。既に確保されているメモリブロックのサイズよりも、指定されたsizeが小さい場合は、メモリブロックが縮小するが、メモリサイズを動的に縮小することは好ましくない。
本実施例は、上述のAPIを実装することにより、Tick管理機能を有する任意のサーバ10に実装することができる。さらに、本実施例の上位層に、より簡便に使用することができるようなオブジェクト指向のラッパーライブラリを実装すれば、サーバ10の開発者は、あたかも巨大で高速なキー・バリュー・ストアがネットワーク上に存在するかのように、ゲームロジックを実装することができるようになる。
なお、AWS上では、tc(Traffic Control)コマンドを用いて、Linux(登録商標)カーネルのパケットフィルタリング機能を利用し、マルチキャストパケットを宛先分コピーして、MACアドレスをユニキャストに置き換えて送信する方法を、本実施例の実装に用いることができる。この方法では、データリンク層でパケットをキャプチャし、キャプチャを宛先の分だけコピーして、それぞれの宛先にユニキャストを行う。宛先のMACアドレスは、AWS SDKにより取得でき、インスタンス名やタグを活用することで、任意のグループのMACアドレスのみを取得することも可能である。
<作用効果>
以上、本実施形態のゲームシステムでは、互いが担当するエリア間でオブジェクトの行き来が高頻度で行われるサーバ間は、疑似IPマルチキャストネットワーク構造で直接接続し(カーネル上のパケット転送設定において、互いのMACアドレスを宛先として登録)、プッシュ型の同期で即時かつ高速な同期を行う。プッシュ型の同期の設定を、仮想空間上の地理的関係に基づいて行うことにより、プッシュ型の同期によるデータの共有率(いわゆるキャッシュのヒット率に近い概念)を高く保ちながら、プッシュ同期にかかるCPU負荷、ネットワーク負荷を低く抑えることができる。
また、本実施形態では、サーバ間で送受信する更新情報の中に時間情報を含める。そして、この時間情報を用いて、メモリの更新/読み出し操作を直列化する。これによりデータ間の整合性や一貫性を管理することが可能となる。
また、本実施形態のゲームシステムでは、サーバ10間で送受信する更新情報の中に時間情報を含める。そして、この時間情報を用いて、メモリの更新/読み出し操作を直列化する。これによりデータ間の整合性や一貫性を管理することが可能となる。
また、実施例で説明したように、本実施形態のカーネル間のデータ同期経路は、Linux(登録商標)のtcコマンドを用いたシェルスクリプトを記述するだけで実装できる。したがって、本実施形態を導入する実行時のコストは極めて小さい。
また、本実施形態のゲームシステムは、プレイヤの行動を制限することなく、自由度の高いゲーム内容を有するゲームシステムにおける負荷分散を実現するものであり、オープンワールド型MMOゲームのみならず、FPS(First Person Shooter)などのプレイヤに高い自由度を提供する様々なゲームにも適用可能である。すなわち、本実施形態のゲームシステムは、利便性が高い。
また、本実施形態のゲームシステムは、独自の仮想マシンやルータを導入することなく、既存のクラウドに実装することが可能である。このため、コスト負担を軽減できる。また、導入のハードルを低くすることができる。
また、本実施形態のゲームシステムは、ユーザ・エクスペリエンスを損なわずに負荷分散可能である。本実施形態のゲームシステムは、ゲーム性に影響を与えず、完全にクラウド内に閉じて実装されるネットワーク通信の高速化技術であり、プレイヤに一切の強制的な制約を加えずに、負荷分散を行うことが出来る。オープンワールド型MMOゲームのように、ゲーム世界への没入感を維持することが、ユーザ・エクスペリエンスにとって本質的に重要なジャンルのゲームの場合、この利点は、極めて有効である。既存の方式では、他の世界への移動を明示的に推奨したり、混雑のためにログイン不可能にしたり、強制的にログアウトさせるなどの、ゲーム内のルールとは無関係な仕組みとして、負荷分散が実現されている。
また、本実施形態のゲームシステムは、ゲーム内におけるプレイヤ間インタラクションを、従来よりも劇的に増加させることが可能である。本実施形態のゲームシステムを適用することにより、どのサーバ10がどのストレージサーバにアクセスしても、同一のワールド情報を獲得することができるため、1つのエリア内で処理可能なユーザインタラクションの量を、従来の負荷分散技術との比較において増大させることが可能となる。具体的には、MMOゲームにおける戦闘をより複雑化させたり、アクションを増加させたりしても、スケーラブルにゲームサービスを提供可能となる。
また、本実施形態のゲームシステムは、非オープンワールド型MMOゲームの負荷分散技術としても適用可能である。本実施形態のゲームシステムは、複数に世界が分割されたMMOゲームにおいても、1つの世界の中での負荷分散を実現する技術として適用可能である。したがって、既存のMMOゲームの負荷分散技術としても有効である。また、FPSやSecond Life型のコミュニケーション・サービスなど、プレイヤ間のインタラクションを伴い、かつ、利用者に高い自由度を提供する幅広いゲームに適用可能である。
以下、参考形態の例を付記する。
1. ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの1つの前記サーバであって、
前記オブジェクト情報を記憶するオブジェクト情報記憶部と、
前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第1の更新部と、
前記複数のサーバの中の一部である対象サーバのMAC(media access control)アドレスを記憶するMACアドレス記憶部と、
前記MACアドレス記憶部に記憶された前記MACアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第1の更新部による前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第1の送信部と、
他の前記サーバから受信した前記更新情報に基づき、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第2の更新部と、
を有するサーバ。
2. 前記時間情報は、複数の前記サーバ各々により同一の処理で生成されている1に記載のサーバ。
3. 他の前記サーバからのリクエストに応じて、IP(internet protocol)通信で、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報を他の前記サーバに送信する第2の送信部をさらに有する1又は2に記載のサーバ。
4. 前記MACアドレス記憶部は、自サーバが担当する前記エリアとの地理的関係が所定条件を満たす前記エリアを担当する前記サーバのMACアドレスを記憶する1から3のいずれかに記載のサーバ。
5. 前記MACアドレス記憶部は、前記サーバにインストールされたOS(operating system)のカーネルが提供するネットワークトラフィック制御機能で設定されたパケット送信先のMACアドレスを記憶し、
前記第1の送信部による前記対象サーバへの前記更新情報の送信は、前記OSの前記ネットワークトラフィック制御機能で実現される1から4のいずれかに記載のサーバ。
6. 1から5のいずれかに記載の前記サーバを複数有するゲームシステム。
7. ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの1つの前記サーバが、
前記オブジェクト情報と、前記複数のサーバの中の一部である対象サーバのMACアドレスを記憶し、
記憶している前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第1の更新工程と、
前記MACアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第1の更新工程での前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第1の送信工程と、
他の前記サーバから受信した前記更新情報に基づき、記憶している前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第2の更新工程と、
を実行する処理方法。
1A プロセッサ
2A メモリ
3A 入出力I/F
4A 周辺回路
5A バス
10 サーバ
11 オブジェクト情報記憶部
12 第1の更新部
13 第1の送信部
14 MACアドレス記憶部
15 第2の更新部
16 第2の送信部
20 プレイヤ端末
30 インターネット

Claims (7)

  1. ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの1つの前記サーバであって、
    前記オブジェクト情報を記憶するオブジェクト情報記憶部と、
    前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第1の更新部と、
    前記複数のサーバの中の一部である対象サーバのMAC(media access control)アドレスを記憶するMACアドレス記憶部と、
    前記MACアドレス記憶部に記憶された前記MACアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第1の更新部による前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第1の送信部と、
    他の前記サーバから受信した前記更新情報に基づき、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第2の更新部と、
    を有するサーバ。
  2. 前記時間情報は、複数の前記サーバ各々により同一の処理で生成されている請求項1に記載のサーバ。
  3. 他の前記サーバからのリクエストに応じて、IP(internet protocol)通信で、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報を他の前記サーバに送信する第2の送信部をさらに有する請求項1又は2に記載のサーバ。
  4. 前記MACアドレス記憶部は、自サーバが担当する前記エリアとの地理的関係が所定条件を満たす前記エリアを担当する前記サーバのMACアドレスを記憶する請求項1から3のいずれか1項に記載のサーバ。
  5. 前記MACアドレス記憶部は、前記サーバにインストールされたOS(operating system)のカーネルが提供するネットワークトラフィック制御機能で設定されたパケット送信先のMACアドレスを記憶し、
    前記第1の送信部による前記対象サーバへの前記更新情報の送信は、前記OSの前記ネットワークトラフィック制御機能で実現される請求項1から4のいずれか1項に記載のサーバ。
  6. 請求項1から5のいずれか1項に記載の前記サーバを複数有するゲームシステム。
  7. ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの1つの前記サーバが、
    前記オブジェクト情報と、前記複数のサーバの中の一部である対象サーバのMACアドレスを記憶し、
    記憶している前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第1の更新工程と、
    前記MACアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第1の更新工程での前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第1の送信工程と、
    他の前記サーバから受信した前記更新情報に基づき、記憶している前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第2の更新工程と、
    を実行する処理方法。
JP2020093992A 2020-05-29 2020-05-29 サーバ、ゲームシステム及び処理方法 Active JP6838187B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020093992A JP6838187B1 (ja) 2020-05-29 2020-05-29 サーバ、ゲームシステム及び処理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020093992A JP6838187B1 (ja) 2020-05-29 2020-05-29 サーバ、ゲームシステム及び処理方法
PCT/JP2021/019526 WO2021241476A1 (ja) 2020-05-29 2021-05-24 サーバ、ゲームシステム及び処理方法

Publications (2)

Publication Number Publication Date
JP6838187B1 true JP6838187B1 (ja) 2021-03-03
JP2021186224A JP2021186224A (ja) 2021-12-13

Family

ID=74673626

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020093992A Active JP6838187B1 (ja) 2020-05-29 2020-05-29 サーバ、ゲームシステム及び処理方法

Country Status (2)

Country Link
JP (1) JP6838187B1 (ja)
WO (1) WO2021241476A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013208426A (ja) * 2012-03-22 2013-10-10 Emprie Technology Development LLC ゲームのためのロードバランシング
JP2017037445A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 サーバ管理装置およびサーバ管理方法
JP2017037446A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 ゲームサーバ装置および分散処理方法
CN107609895A (zh) * 2017-08-10 2018-01-19 腾讯科技(深圳)有限公司 一种合并业务区域的处理方法及其设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013208426A (ja) * 2012-03-22 2013-10-10 Emprie Technology Development LLC ゲームのためのロードバランシング
JP2017037445A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 サーバ管理装置およびサーバ管理方法
JP2017037446A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 ゲームサーバ装置および分散処理方法
CN107609895A (zh) * 2017-08-10 2018-01-19 腾讯科技(深圳)有限公司 一种合并业务区域的处理方法及其设备

Also Published As

Publication number Publication date
WO2021241476A1 (ja) 2021-12-02
JP2021186224A (ja) 2021-12-13

Similar Documents

Publication Publication Date Title
Bharambe et al. Colyseus: A Distributed Architecture for Online Multiplayer Games.
Mai et al. Optimizing network performance in distributed machine learning
Nathan et al. Comicon: A co-operative management system for docker container images
Belaramani et al. PADS: A Policy Architecture for Distributed Storage Systems.
US20040153473A1 (en) Method and system for synchronizing data in peer to peer networking environments
US20120226738A1 (en) Simultaneous download of application file portions
Newell et al. Optimizing distributed actor systems for dynamic interactive services
Douglas et al. Enabling massively multi-player online gaming applications on a p2p architecture
US10498812B1 (en) State management and object storage in a distributed cloud computing network
WO2021104101A1 (zh) 游戏服务器架构
US20150156278A1 (en) Methods and systems for bandwidth-efficient remote procedure calls
CN108200211A (zh) 集群中镜像文件下载的方法、节点和查询服务器
JP6838187B1 (ja) サーバ、ゲームシステム及び処理方法
Najaran et al. SPEX: scalable spatial publish/subscribe for distributed virtual worlds without borders
Németh et al. {DAL}: A {Locality-Optimizing} Distributed Shared Memory System
Deen et al. Running Quake II on a grid
Bhojan et al. CloudyGame: Enabling cloud gaming on the edge with dynamic asset streaming and shared game instances
CN112076464A (zh) 一种数据请求处理方法、装置、计算机设备及存储介质
CN112138372A (zh) 分布式系统中的数据同步方法及相关设备
Bharambe et al. A distributed architecture for interactive multiplayer games
Kasenides et al. A systematic mapping study of MMOG backend architectures
Moll et al. Inter-Server game state synchronization using named data networking
Xu et al. A Comparison of Architectures in Massive Multiplayer Online Games
CN112156475B (zh) 一种业务数据处理方法、装置、电子设备及存储介质
Gorlatch et al. Designing multiplayer online games using the real-time framework

Legal Events

Date Code Title Description
A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20201111

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201111

TRDD Decision of grant or rejection written
A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20210121

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210126

R150 Certificate of patent or registration of utility model

Ref document number: 6838187

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210210