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

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

Info

Publication number
WO2021241476A1
WO2021241476A1 PCT/JP2021/019526 JP2021019526W WO2021241476A1 WO 2021241476 A1 WO2021241476 A1 WO 2021241476A1 JP 2021019526 W JP2021019526 W JP 2021019526W WO 2021241476 A1 WO2021241476 A1 WO 2021241476A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
object information
update
information
charge
Prior art date
Application number
PCT/JP2021/019526
Other languages
English (en)
French (fr)
Inventor
修一 倉林
Original Assignee
株式会社Cygames
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 filed Critical 株式会社Cygames
Priority to CN202180059375.3A priority Critical patent/CN116235470A/zh
Publication of WO2021241476A1 publication Critical patent/WO2021241476A1/ja
Priority to US18/058,033 priority patent/US20230086992A1/en

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/352—Details 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/51—Server architecture
    • A63F2300/513—Server architecture server hierarchy, e.g. local, regional, national or dedicated for different tasks, e.g. authenticating, billing
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/534—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for network load management, e.g. bandwidth optimization, latency reduction

Definitions

  • the present invention relates to a server, a game system and a processing method.
  • the game space is divided into multiple areas, and one area corresponds to one load balancing unit. And since interactions such as movement of objects (characters, etc.), battles between characters, item exchange, and activation of magic may occur across units of load balancing, synchronization processing between distributed on-memory databases is performed. You will need it.
  • the server In a situation where an object moves and acts freely in an open world, the server automatically allows the object to move freely without setting a limit on the range of movement of the object, play that can be logged in at the same time, or a limit on the number of objects.
  • a new synchronization method that equalizes the load on the server is desired.
  • Non-Patent Documents 1 to 3 a lot of research has been done in the fields of data replication, data synchronization, and distributed databases. Further, as disclosed in Non-Patent Documents 4 to 6, research on database load balancing and data synchronization for MMO is also regarded as a development of data replication technology, and has been actively studied in North America and Canada. However, these label areas and objects in the game, distribute and subscribe to the labels as a Publish / Subscribe model, and are open-world type, virtual with an unspecified number of objects in one. We do not assume a situation where the space is shared and data is updated in real time.
  • Non-Patent Document 7 research on a data replication method utilizing IP (internet protocol) multicast has been made, and as disclosed in Patent Document 1, patent applications related to it have also been filed.
  • IP internet protocol
  • Non-Patent Document 8 the data replication method utilizing the geographical relationship is provided as disclosed in Non-Patent Document 8 and Non-Patent Document 9, the data replication method utilizing the information of the virtual space peculiar to the game is known.
  • the data replication method utilizing the information of the virtual space peculiar to the game is known.
  • the field of distributed shared memory especially software-based distributed shared memory that can be flexibly used in the public cloud
  • research and OSS projects such as Kerrighed, openMosix, and OpenSSI have been conducted as disclosed in Non-Patent Documents 10 and 11. It has been launched. However, they have not been widely used since the project was suspended in the mid-2000s.
  • Non-Patent Document 12 a mechanism for transparently realizing remote memory access at the kernel level has also been studied. However, they are mainly intended to perform large-scale scientific and technological operations, and applications such as games whose memory access patterns change significantly depending on the content status have not yet been studied. .. Currently, as disclosed in Non-Patent Documents 13 and 14, shared memory on the cloud is being actively studied, but its application to games is not considered, and it remains a general-purpose use case. ..
  • An object of the present invention is to provide a new data synchronization method suitable for a game system.
  • One of the servers of a game system having a plurality of servers in charge of each of a plurality of areas in a game space and managing object information indicating the state of each of the plurality of objects that can move between the areas.
  • An object information storage unit that stores the object information and Among the object information stored in the object information storage unit, a first update unit that updates the object information of the object existing in the area in charge, and a first update unit.
  • a MAC address storage unit that stores the MAC (media access control) address of the target server that is a part of the plurality of servers.
  • a first transmission unit that transmits updated information indicating information to the target server, and Based on the update information received from the other server, among the object information stored in the object information storage unit, the object information of the object existing outside the area in charge is updated, and the object information is updated.
  • a second update unit that realizes the update of the object information in chronological order based on the time information, and A server with is provided.
  • a game system having a plurality of the above servers is provided.
  • the server of one of the game systems having a plurality of servers in charge of each of a plurality of areas in the game space and managing object information indicating the state of each of the plurality of objects that can move between the areas.
  • the object information and the MAC address of the target server which is a part of the plurality of servers are stored.
  • the first update step of updating the object information of the object existing in the area in charge and By packet transfer based on the data of the data link layer destined to the MAC address, the target is the update information indicating the update content of the object information in the first update step and the time information indicating the in-game time at the time of update.
  • the first transmission process to send to the server and Of the stored object information the object information of the object existing outside the area in charge is updated based on the update information received from the other server, and the time series is based on the time information.
  • a second update process that realizes the update of the object information in order, and Is provided with a processing method to execute.
  • a new data synchronization method suitable for a game system is provided.
  • the object of this embodiment is, for example, for an open world type MMO game having no explicit server division unit, and a large scale capable of appropriately synchronizing the state information of the game managed by each server between the servers. It is to realize a good load distribution. Therefore, in this embodiment, the connection between the servers in charge of geographically close areas on the virtual space of the game is implemented as direct communication between the OS (operating system) kernels that do not go through the application, and distributed sharing is performed. Adopt a method to manage state information efficiently on the memory.
  • the game space is divided into a plurality of areas, and the server in charge is determined for each area. Then, in order to speed up communication between the servers in charge of each of the two areas where objects frequently move between each other, pseudo IP multicast processing using the kernel of the OS running on each server is introduced.
  • This mechanism allows the kernel's packet forwarding filter to be preset so that if there are nodes that are known to have a high object movement frequency [0], those nodes will automatically receive the same packet. It focuses on the points. [0]
  • individual applications can be moved from the memory area managed by the kernel of the OS using inter-kernel communication.
  • the pseudo-IP multicast network structure is constructed by setting packet forwarding (registering the destination MAC address) on the kernel.
  • servers registered with each other's MAC addresses as destination MAC addresses are directly connected. Data can be sent and received between directly connected servers using the pseudo-multicast function with the kernel of each node that builds the distributed shared memory as a router.
  • the routing of write instructions is performed by highly efficient inter-kernel communication without the need for advanced routing processing of a centrally controlled router or application layer. Consistency control is performed by Tick-ID.
  • the present embodiment realizes a function of delivering a predetermined packet to an appropriate receiver only by a standard kernel function without using a dedicated network device such as a router or application-specific packet transmission / reception processing. It has the feature.
  • Update information can be sent / received (synchronized) in a pull type when necessary.
  • this embodiment uses pseudo IP multicast using the packet forwarding filter of the kernel, it is possible to flexibly change the synchronization destination from the server without changing the network settings. It is also possible for one server to accept synchronization from multiple servers.
  • the game system of this embodiment has a plurality of servers. Then, each of the plurality of servers is in charge of each of the plurality of areas in the game space. Each server updates the object information (corresponding to the above state information) of the objects existing in the area in charge of the own server based on the player input or the control information generated in the own device.
  • the multiple servers perform the process of synchronizing the object information managed by each server.
  • Push-type synchronization is performed by pseudo-IP multicast processing using the OS kernel between the servers in charge of each of the two areas where objects frequently move between each other.
  • the OS of each server is updated by packet transfer based on the data of the data link layer (L2) addressed to the MAC address of the target server registered in advance without a request from another server. Information is sent to the target server.
  • L2 data link layer
  • the target server is a part of a plurality of servers. Which server is the target server is determined for each server. The server in charge of the area where objects are frequently exchanged with and from the area in charge of each server is set as the target server of each server.
  • push-type synchronization for example, all data received by a server is always copied to a predetermined server group. This is called replication.
  • packets may be buffered for a certain period of time and then copied instead of being copied sequentially.
  • synchronization When synchronization is required between servers that do not perform push-type synchronization, for example, normal application layer communication, such as IP communication, should be adopted, and update information should be sent and received in a pull-type when necessary. Can be done (pull type synchronization). For example, a server that is not set as a target server of the first server and does not perform push-type synchronization with the first server requests update information from the first server as needed. Push synchronization means that the server that receives the packet actively forwards the packet to another server. In pull-type synchronization, a server that needs information requests and acquires the information from another server, and synchronization is inevitably performed.
  • pull type synchronization a server that needs information requests and acquires the information from another server, and synchronization is inevitably performed.
  • pull-type synchronization the application running on each server sends the update information to the other server in response to the request from the other server, for example, by IP communication. Only applications that can recognize the situation where data is needed can generate a request. Therefore, this pull-type synchronization inevitably requires application layer processing. In communication that requires processing of the application layer, data is transferred between different layers and a context switch is required. Therefore, the time required for transmission / reception per byte is generally large. Therefore, the pull-type synchronization is slower than the push-type synchronization. In pull-type synchronization, only the updated contents may be sent and received, or only the contents specified in the request may be sent and received.
  • the servers in which objects are frequently exchanged between the areas in charge of each other are directly connected by a pseudo IP multicast network structure (in the packet forwarding setting on the kernel, the MAC addresses of each other are set. Register as a destination), perform immediate and high-speed synchronization with push-type synchronization.
  • push-type synchronization based on the geographical relationship on the virtual space, it is possible to keep the CPU load and network load related to push synchronization low while keeping the data sharing rate by push-type synchronization high. can.
  • time information such as Tick-ID is included in the update information sent and received between the servers. Then, using this time information, the memory update / read operation is serialized. This makes it possible to manage consistency and consistency between data.
  • the game system has a plurality of servers 10.
  • the plurality of servers 10 are located in the same network or the same virtual network on the cloud, and can send and receive data to and from each other by packet transfer based on the data link layer address (MAC address).
  • the plurality of servers 10 can exist in the same virtual network (for example, a subnet generated by logically dividing a virtual network server).
  • the technique disclosed in Non-Patent Document 15 can be used to realize such a configuration of a plurality of servers 10.
  • the plurality of servers 10 are connected to the plurality of player terminals 20 via the Internet 30.
  • the player terminal 20 is a terminal operated by the player, and examples thereof include, but are not limited to, smartphones, tablet terminals, PCs (personal computers), mobile phones, game terminals, and the like.
  • Each functional unit included in the server 10 of the present embodiment includes a CPU (Central Processing Unit) of an arbitrary computer, a memory, a program loaded into the memory, and a storage unit such as a hard disk for storing the program (a stage in which the device is shipped in advance).
  • a storage unit such as a hard disk for storing the program (a stage in which the device is shipped in advance).
  • programs stored from it can also store programs downloaded from storage media such as CDs (Compact Discs) and servers on the Internet), any hardware and software centered on the network connection interface. It is realized by the combination. And, it is understood by those skilled in the art that there are various variations in the method of realizing the device and the device.
  • FIG. 2 is a block diagram illustrating a hardware configuration of the server 10 of the present embodiment.
  • the server 10 has a processor 1A, a memory 2A, an input / output interface 3A, a peripheral circuit 4A, and a bus 5A.
  • the peripheral circuit 4A includes various modules.
  • the server 10 does not have to have the peripheral circuit 4A.
  • the server 10 may be composed of a plurality of physically and / or logically separated devices. That is, one server 10 may be configured as a cluster of a plurality of devices. In this case, each device can be provided with the above hardware configuration. In addition, the server 10 may be physically and logically composed of one device.
  • the bus 5A is a data transmission path for the processor 1A, the memory 2A, the peripheral circuit 4A, and the input / output interface 3A to transmit and receive data to each other.
  • the processor 1A is, for example, an arithmetic processing unit such as a CPU or a GPU (Graphics Processing Unit).
  • the memory 2A is, for example, a memory such as a RAM (RandomAccessMemory) or a ROM (ReadOnlyMemory).
  • the input / output interface 3A includes an interface for acquiring information from an input device, an external device, an external server, an external sensor, and the like, an interface for outputting information to an output device, an external device, an external server, and the like.
  • the input device is, for example, a keyboard, a mouse, a microphone, or the like.
  • the output device is, for example, a display, a speaker, a printer, a mailer, or the like.
  • the processor 1A can issue a command to each module and perform a calculation based on the calculation result thereof.
  • the game provided by the game system of the present embodiment is, for example, an open world type MMO game.
  • the game space is divided into a plurality of areas.
  • Objects that exist in the game space can move between areas (ie, move across areas).
  • Objects include player objects controlled by the player and non-player objects not controlled by the player.
  • Objects include any object such as characters, bows, ammunition, birds, etc.
  • Each server 10 is in charge of each of the plurality of areas.
  • the server 10 in charge of the first area among the plurality of areas stores the object information indicating the state of the objects existing in the first area, and determines the control information generated by the player input or the own device. The object information is updated based on the control information. Then, the server 10 in charge of the first area transmits the update information indicating the update content of the object information of the object existing in the first area to the other server 10. In this way, the server 10 in charge of the first area updates the object information of the object existing in the area in charge of the process as described above, and transmits the updated contents to the other server 10.
  • the server 10 in charge of the first area includes not only the object information of the object existing in the first area but also the object information of the object existing outside the area in charge.
  • the server 10 in charge of the first area exists in the area received by push-type synchronization from the server 10 in charge of the area in which objects are frequently exchanged with and from the first area.
  • the server 10 in charge of the first area stores and updates the object information of the objects existing in the area received from the server 10 in charge of the other areas in a pull-type synchronization.
  • the method of updating the object information of the object existing in the area in charge and the method of updating the object information of the object existing outside the area in charge are different. Specifically, the method of updating the object information of the object existing in the area in charge is as described above. On the other hand, the object information of the object existing outside the area in charge is updated based on the update information received from the other server 10 by the push type or pull type synchronization. Further, even if the server 10 updates the object information of the object existing outside the area in charge, the server 10 does not send the updated information indicating the updated content to the other server 10. In this respect as well, the handling of objects existing in the area in charge and objects existing in other areas is different.
  • FIG. 4 shows an example of a functional block diagram of the server 10.
  • the server 10 includes an object information storage unit 11, a first update unit 12, a first transmission unit 13, a MAC address storage unit 14, a second update unit 15, and a second unit. It has a transmission unit 16.
  • the object information storage unit 11 stores object information indicating the state of an object existing in the game space.
  • the object information includes all kinds of information such as position information indicating the position of the object in the game space, orientation information indicating the direction of the object, hit points, attack power, defense power, and level.
  • the object information storage unit 11 of each server 10 stores the object information of some of the objects existing in the game space.
  • the object information storage unit 11 stores the object information of the objects existing in the area in charge of the own server 10.
  • the "own server 10" will be described.
  • the functional unit object information storage unit 11, first update unit 12, first transmission unit 13, MAC address storage unit
  • the first server 10 is the "own server 10" for the first functional unit.
  • the server 10 other than the first server 10 becomes an "other server 10".
  • the object information storage unit 11 can also store the object information of the object existing outside the area in charge of the own server 10. Specifically, the object information storage unit 11 stores object information received from another server 10 in the synchronization process. That is, the object information storage unit 11 stores the object information received from another server 10 directly connected to the own server 10 in the pseudo IP multicast network structure by the push-type synchronization process. Further, the object information storage unit 11 stores object information received from another server 10 that is not directly connected to the own server 10 in a pseudo IP multicast network structure, for example, by pull-type synchronization processing.
  • FIG. 5 schematically shows an example of object information.
  • the object information can further include information indicating the update timing of each parameter.
  • the update timing is indicated by, for example, time information indicating the in-game time.
  • Tick-ID is exemplified as an example of time information indicating in-game time.
  • the time information indicating the in-game time is Tick-ID.
  • a method of managing the update timing for each object may be adopted.
  • Tick-ID will be described.
  • the Tick-ID is generated by the same process by each of the plurality of servers 10.
  • Each server 10 updates the Tick-ID at predetermined time intervals.
  • the Tick-ID is indicated by a numerical value, and each server 10 increases the Tick-ID by a predetermined number (for example, "1") at predetermined time intervals.
  • the update cycle of the Tick-ID is, for example, 0.03 to 0.05 seconds (about 20 Hz to 30 Hz).
  • Multiple servers 10 are synchronized to generate the same value of Tick-ID at the same timing by any means such as a method using NTP (network time protocol) or a method of deploying an atomic clock on all servers 10. ing.
  • NTP network time protocol
  • the first updating unit 12 updates the object information of the object existing in the area in charge of the own server 10 among the object information stored in the object information storage unit 11.
  • the first updating unit 12 receives the control information of the player object existing in the area in charge of the own server 10 from the player terminal 20, and updates the object information of the player object based on the control information.
  • the control information of the player object is generated based on the player input via, for example, the player terminal 20.
  • the control information may be information indicating the content of the player input (data indicating the touch position in time series, data indicating the size and direction calculated based on the data, etc.), or the player based on the content of the player input. It may be information indicating the control content (movement amount, movement direction, position after movement, etc. of the player object) determined by the terminal 20.
  • the first update unit 12 determines the control content of the non-player object existing in the area in charge of the own server 10, and updates the object information of the non-player object.
  • the algorithm that determines the control content of the non-player object is a design matter.
  • the first update unit 12 that updates the object information by the process as described above only updates the object information of the object existing in the area in charge of the own server 10, and exists outside the area in charge of the own server 10. Does not update the object information of the object to be used.
  • the first update unit 12 realizes the update of the object information in chronological order based on the Tick-ID. For example, when the first updating unit 12 updates a predetermined parameter of the object information of a predetermined object, the first updating unit 12 first refers to the object information stored in the object information storage unit 11 (see FIG. 5), and the parameter is changed. Specify the Tick-ID of the latest update timing. Then, if the Tick-ID of the latest update timing is earlier than the Tick-ID of the current update timing (current Tick-ID), there is no problem, so the first update unit 12 performs the update process. Run.
  • the first update unit 12 performs the update process. Do not execute. In this case, the first update unit 12 executes arbitrary error processing.
  • the MAC address storage unit 14 stores the MAC address of the target server which is a part of the plurality of servers 10.
  • FIG. 6 schematically shows an example of the target server information stored in the MAC address storage unit 14. The content of the target server information differs for each server 10. That is, which server 10 is the target server differs for each server 10.
  • the MAC address storage unit 14 stores the MAC address of the server 10 in charge of the area in which the geographical relationship with the area in charge of the own server 10 satisfies a predetermined condition. That is, the server 10 in charge of the area in which the geographical relationship with the area in charge of the own server 10 satisfies a predetermined condition is the target server of the own server 10.
  • the predetermined conditions are "the shortest time required to move an object from one area to the other area is less than or equal to the reference value", "adjacent to each other", “adjacent to each other, and between areas at the boundary between each other".
  • the target server information as shown in FIG. 6 is generated by the operator who manages the game system.
  • the operator may generate the target server information as shown in FIG. 6 by inputting the MAC address of the target server for each server 10.
  • each server 10 may store server information regarding another server 10 as shown in FIG. 7.
  • the server information is associated with the server identification information of each of the other servers 10, the MAC address of each of the other servers 10, and the identification information of the area in charge of each of the other servers 10.
  • the operator may input the server identification information of the server 10 as the target server for each server 10. Then, the server 10 may acquire the MAC address associated with the input server identification information from the server information and register it in the target server information.
  • the operator may input the area identification information of the area in charge of the server 10 as the target server for each server 10. Then, the server 10 may acquire the MAC address associated with the input area identification information from the server information and register it in the target server information.
  • the MAC address of the target server is registered in the MAC address storage unit 14, for example, by registering the MAC address of the packet transmission destination (filtering setting) in the network traffic control function provided by the kernel of the OS installed in the server 10. It will be realized.
  • the first transmission unit 13 is the first by packet transfer based on the data (MAC address or the like) of the data link layer addressed to the MAC address stored in the MAC address storage unit 14 without a request from the target server.
  • the update information indicating the update content of the object information by the update unit 12 is transmitted to the target server.
  • the first transmission unit 13 can transmit the update information indicating the update content to the target server in response to the update of the object information by the first update unit 12. It is preferable that the time lag (elapsed time) from the timing at which the update is performed to the transmission of the update information is as small as possible.
  • the update information includes information indicating the timing of the update (Tick-ID at the time of update).
  • the transmission of update information to some servers 10 (target servers) using the above-mentioned data link layer data (MAC address, etc.) is realized by, for example, the packet filtering function in the network traffic control function of the OS.
  • the second update unit 15 is an area in charge of the own server 10 among the object information stored in the object information storage unit 11 based on the update information received from the other server 10 in the push type synchronization or the pull type synchronization.
  • the object information of the object existing outside the (area not in charge of the own server 10) is updated.
  • the second update unit 15 that updates the object information by the above-mentioned process only updates the object information of the object existing outside the area in charge of the own server 10, and the area in charge of the own server 10. The object information of the object existing in is not updated.
  • the second update unit 15 realizes the update of the object information in chronological order based on the Tick-ID. For example, when the second updating unit 15 updates a predetermined parameter of the object information of a predetermined object, the second updating unit 15 first refers to the object information stored in the object information storage unit 11 (see FIG. 5), and the parameter is changed. Specify the Tick-ID of the latest update timing. Then, if the Tick-ID of the latest update timing is earlier than the Tick-ID (Tick-ID when the update is performed on the other server 10) included in the update information, there is no problem. The update unit 15 of 2 executes the update process.
  • the update unit 15 of 2 does not execute the update process. In this case, the second update unit 15 executes arbitrary error processing.
  • the second update unit 15 serializes the update / read operation based on the Tick-ID associated with the update / read operation (update / read order). To determine). Then, after the order is determined, when the problem of data conflict arises, the second update unit 15 notifies the game logic of the exception.
  • the game logic side resolves the data conflict by, for example, a method of setting a priority for each player or a method of cheating the race condition with an effect (game logic processing is a design matter).
  • the problem of data conflict is, for example, when a read operation and a write operation are performed with the same Tick-ID and the same memory block address, or with the same Tick-ID and the same memory block address. This is the case when two or more write operations are performed.
  • the second transmission unit 16 transmits the object information stored in the object information storage unit 11 to the other server 10 by IP communication in response to the request from the other server 10.
  • the second transmission unit 16 can transmit the object information including the update timing of each parameter to the other server 10.
  • the network layer protocol in the IP communication is an IP protocol
  • the transport layer protocol is a TCP (Transmission Control Protocol) protocol, a UDP (User Datagram Protocol) protocol, or the like.
  • the request from the other server 10 may include information that specifies the object. Then, the second transmission unit 16 may transmit the object information of the designated object among the object information stored in the object information storage unit 11 to another server 10.
  • the first update unit 12 is waiting for acquisition of control information regarding an object existing in the area in charge of the own server 10 (S10).
  • the first update unit 12 can receive the control information of the player object existing in the area in charge of the own server 10 from the player terminal 20. Further, the first update unit 12 can acquire the control information of the non-player object existing in the area in charge of the own server 10 generated in the own server 10.
  • the first update unit 12 determines the update content of the object based on the control information (S11). For example, when the control information indicates the moving direction or the moving distance of the object, the first updating unit 12 determines a new position of the object based on the current position of the object and the control information. It should be noted that the details of the process of determining the update content based on the control information are design matters and are not limited to this example.
  • the first update unit 12 refers to the object information stored in the object information storage unit 11 (see FIG. 5), and acquires a Tick-ID indicating the latest update timing of the update target parameter of the update target object. (S12). Then, the Tick-ID indicating the latest update timing and the Tick-ID (current Tick-ID) of the current update timing are compared (S13).
  • the first update unit 12 determines the update content in S11.
  • the object information stored in the object information storage unit 11 is updated based on (S14).
  • the first update unit 12 updates the information indicating the update timing associated with the updated parameter of the updated object to the Tick-ID indicating the current update timing.
  • the first transmission unit 13 responds to the update of S14 and receives a packet based on the data of the data link layer destined for all the MAC addresses stored in the MAC address storage unit 14 without a request from the target server.
  • the update information indicating the update content of the object information in S14 is transmitted to the target server (S15).
  • the first update unit 12 is determined in S11. Arbitrary error processing is performed without updating the object information based on the updated content (S16).
  • the server 10 repeats the same process.
  • the second transmission unit 16 is waiting for a request from another server 10 (S20). Then, when the second transmission unit 16 receives the object information request from the other server 10 (Yes in S20), the second transmission unit 16 transfers the object information stored in the object information storage unit 11 to the other server 10 by IP communication. Transmit (S21).
  • the request from the other server 10 may include information that specifies the object. Then, the second transmission unit 16 may transmit the object information of the designated object among the object information stored in the object information storage unit 11 to another server 10.
  • the server 10 repeats the same process.
  • the second update unit 15 is waiting for update information to be received from another server 10 (S30). Then, when the second update unit 15 receives the update information from the other server 10 (Yes in S30), the second update unit 15 refers to the object information stored in the object information storage unit 11 (see FIG. 5), and the object to be updated refers to the object. Acquires a Tick-ID indicating the latest update timing of the parameter to be updated (S31). Then, the Tick-ID indicating the latest update timing and the Tick-ID of the update timing included in the update information (Tick-ID when the update is performed by the other server 10) are compared (S32).
  • the second update unit 15 receives the update.
  • the object information stored in the object information storage unit 11 is updated based on the update content indicated by the information (S33).
  • the second update unit 15 updates the information indicating the update timing associated with the updated parameter of the updated object to the Tick-ID indicating the update timing included in the update information.
  • the second update unit 15 receives. Arbitrary error processing is performed without updating the object information based on the updated content indicated by the updated information (S34).
  • the server 10 repeats the same process.
  • FIG. 11 shows an overall picture of synchronization between the servers 10 according to this embodiment.
  • the game space is divided into a plurality of areas, and each server 10 is in charge of each area.
  • the above-mentioned push-type synchronization is executed between a plurality of servers 10 in charge of a plurality of areas close to each other.
  • the push-type synchronization described above is not executed between the plurality of servers 10 in charge of the plurality of areas that are not close to each other.
  • a substantially uniform distributed database can be formed without synchronizing the contents of all the servers 10.
  • each area may be sharded and replicated, and the load may be distributed.
  • the distribution unit of the shard may be a player unit, an object unit, or any other unit.
  • the distribution unit of the shard is the player unit, the information of the same player managed by each of the plurality of servers 10 is stored in the same shard. For example, since all shards share a hash function applied to the player ID, nearby same-level shards store the same player information. Therefore, the synchronous processing may be performed between the shards of the same layer, and the processing load of the server 10 is reduced.
  • the transaction isolation level problem can be solved by controlling the execution order and consistency with the Tick-ID for all data update / reference operations. That is, all operations can be serialized, and all areas can be treated as a flat referenceable database.
  • each node (EC2 instance) of AWS can be substantially multicast by setting packet forwarding on the kernel, and the kernel of each node of distributed shared memory. It realizes "DSM (Distributed Shared Memory) with embedded router function" that makes the router a router.
  • DSM Distributed Shared Memory
  • embedded router function makes the router a router.
  • FIG. 1 The system configuration diagram of this embodiment is shown in FIG.
  • This system does not seamlessly provide a completely linear address space across all servers 10, but as shown by "Key-A" in the figure, each variable that can be identified by a character string is set. It is a mechanism that automatically synchronizes between the servers 10. That is, if "key-name” is regarded as a variable, it can be said that it is a mechanism for providing a variable (memory block) shared between a plurality of servers 10. In that respect, it differs significantly from existing distributed shared memory.
  • This embodiment is composed of three modules that can be closed and mounted on one node (server 10).
  • the first module, [M1] Tick Manager is a module that manages the Tick-ID, which is the time unit of the game, and is synchronized with the real time in principle. This synchronization can be easily implemented by using an existing stable implementation such as NTP (Network Time Protocol).
  • NTP Network Time Protocol
  • the second module, [M2] Memory Manager is a module that manages distributed shared memory by providing the API described later to the logic on the server 10 side.
  • Memory manager serializes memory update / read operations using Tick-ID. If Memory Manager detects a data conflict using Tick-ID, an exception is notified to the game logic type.
  • the game logic side resolves the data conflict by, for example, a method of setting a priority for each player or a method of cheating the race condition with an effect (game logic processing is a design matter).
  • the problem of data conflict is, for example, that an operation (read / write) to the same memory block address is performed with the same Tick-ID.
  • the third most important module is the [M3] Custom L2 Multicast Module that runs inside the kernel.
  • This module forms a network structure (pseudo-IP multicast network structure) for packet forwarding at the data link layer by mutually registering the MAC addresses of the servers in the multicast destination.
  • This network structure corresponds to the neighborhood relationship of the area (the area in charge of each server 10) in the virtual space of the game, and the geographically close server 10 is connected, and the distant server 10 is not connected.
  • the writing to the shared memory is immediately shared between the servers 10 linked in this way through the L2 packet transfer.
  • management information such as the MAC address of each node can be dynamically obtained from the cloud management system without relying on a router. Therefore, the node on the cloud can know the node structure of the entire cloud. Therefore, by processing the multicast packet on each node and performing the multicast independently, it is possible to implement the multicast on the cloud in a pseudo manner. In this embodiment, this is referred to as pseudo IP multicast.
  • the destination of the packet can be changed only by setting the packet filter in the network traffic control function provided by the kernel of the OS. Therefore, it is possible to flexibly change the multicast processing.
  • the application In the conventional distributed processing of an on-memory database, only the application can have the application-specific information such as the positional relationship of the virtual space, so that it cannot be used for the optimization processing in the OS layer.
  • the application-specific information such as the positional relationship of the virtual space
  • the API provided by this embodiment will be described.
  • the APIs that make up this system are five core APIs and four attached APIs.
  • (1) chain [MAC_ADDRESS1, MAC_ADDRESS2, MAC_ADDRESS3, ... MAC_ADDRESSn]
  • the chain API sets packet forwarding from the server 10 on which this API is started to the server 10 having MAC_ADDRESS1 to n.
  • the multicast packet is simply sent to the server 10 and transferred to the server 10 having MAC_ADDRESS1 to n only by processing the L2 packet.
  • the memory write via the smart pointer generated by the open described later is immediately shared between the servers 10 connected by this chain through the L2 packet transfer.
  • Open API is an API that creates a reference to shared memory.
  • sptr which is the return value of the function, is an abbreviation for Smart Pointer to Distributed Shared Memory, and is an object that manages a reference to the shared memory. Any ASCII character string that does not include spaces can be specified for key-name. It is not necessary to divide the directory by "/" etc. as in the above example. It is not desirable to unnecessarily squeeze the packet size, and it is preferable to impose a limit such as 255 characters at the maximum. If the "key-name" memory block does not exist, an exception will be thrown.
  • FIG. 13 shows a schematic diagram of the memory block provided by this embodiment. All memory blocks (objects) are given a Tick-ID when the information stored at that time is generated / updated.
  • the size L1 of the object stored in the shared memory is preferably a fixed length. It is preferable that the size L2 of the entire shared memory is sufficiently secured at the time of system startup and has a fixed length. A variable length can be obtained by using a linked list or the like, but this is not preferable because the random access performance deteriorates.
  • Shared memory is modeled, for example, as an array of fixed-length objects and identified by name.
  • the system notifies the game logic of an exception.
  • the game logic side resolves the data conflict by, for example, a method of setting a priority for each player or a method of cheating the race condition with an effect. It is preferable that the size of the variable a is statically determined, but in the case of completely dynamic processing, the writing logic may be devised.
  • this replicate API When the kernel receives the multicast L2 packet, this replicate API is called. This API overwrites the address after index of the memory block bound to a specific key-name with blocks. blocks are bytes that represent one or more objects. In this system, it is assumed that a computer of the same architecture is used, and since the shared memory does not include pointers and the like, the objects are stored in the memory as they are without undergoing special serialization / deserialization processing. If the "key-name" memory block does not exist, an invalid state has occurred and it is treated as a serious error.
  • the read API and (5) replicate API, which is called when the data to be replicated arrives as a multicast packet are the main APIs.
  • the main functions are substantially implemented by these five APIs.
  • the APIs (6) to (9) shown below are APIs necessary for implementation, they do not provide the essential functions of this embodiment.
  • create (“key-name", size)
  • the create API secures a block of distributed shared memory for the size by the name of "key-name”.
  • the memory segment reservation instruction is immediately replicated on the server 10 side, and is processed by the other server 10 as a create API call. If a "key-name" memory block already exists, an exception will be thrown.
  • delete ("key-name")
  • the delete API deletes a block of distributed shared memory with the name "key-name”.
  • the memory segment deletion instruction is immediately replicated on the server 10 side and processed by the other server 10 as a delete API call. If the "key-name" memory block does not exist, an exception will be thrown.
  • (9) resize ("key-name", size)
  • the resize API expands the block of distributed shared memory secured by the name of "key-name” by the size.
  • the memory segment resizing instruction is immediately replicated on the server 10 side and processed by the other server 10 as a resolve API call. If the "key-name" memory block does not exist, an exception will be thrown. If the specified size is smaller than the size of the memory block already reserved, the memory block is reduced, but it is not preferable to dynamically reduce the memory size.
  • This embodiment can be implemented on any server 10 having a Tick management function by implementing the above API. Furthermore, if an object-oriented wrapper library that can be used more easily is implemented in the upper layer of this embodiment, the developer of the server 10 can have a huge and high-speed key-value store on the network. You will be able to implement game logic as if it were in.
  • a method of using the packet filtering function of the Linux (registered trademark) kernel by using the ct (TrafficControl) command, copying the multicast packet for the destination, and replacing the MAC address with unicast for transmission can be used in the implementation of this embodiment.
  • packets are captured at the data link layer, the captures are copied by the number of destinations, and unicast is performed to each destination.
  • the MAC address of the destination can be acquired by AWS SDK, and it is also possible to acquire only the MAC address of any group by utilizing the instance name and tag.
  • the servers in which objects are frequently exchanged between the areas in charge of each other are directly connected by a pseudo IP multicast network structure (in the packet forwarding setting on the kernel, each other is connected. Register the MAC address as the destination), and perform immediate and high-speed synchronization with push-type synchronization.
  • push-type synchronization By setting push-type synchronization based on geographical relationships in virtual space, push synchronization can be performed while keeping the data sharing rate (a concept close to the so-called cache hit rate) of push-type synchronization high.
  • the CPU load and network load can be kept low.
  • the time information is included in the update information sent and received between the servers. Then, using this time information, the memory update / read operation is serialized. This makes it possible to manage consistency and consistency between data.
  • the time information is included in the update information transmitted and received between the servers 10. Then, using this time information, the memory update / read operation is serialized. This makes it possible to manage consistency and consistency between data.
  • the data synchronization path between the kernels of this embodiment can be implemented only by writing a shell script using the tk command of Linux (registered trademark). Therefore, the cost at the time of introducing the present embodiment is extremely small.
  • the game system of the present embodiment realizes load distribution in a game system having a highly flexible game content without restricting the actions of the player, and is used not only for open world MMO games but also for FPS (FPS). It can also be applied to various games that provide a high degree of freedom to players such as First Person Shooter). That is, the game system of this embodiment is highly convenient.
  • FPS FPS
  • the game system of this embodiment can be implemented in an existing cloud without introducing a unique virtual machine or router. Therefore, the cost burden can be reduced. In addition, the hurdle for introduction can be lowered.
  • the game system of this embodiment can distribute the load without impairing the user experience.
  • the game system of the present embodiment is a technology for accelerating network communication that is completely closed and implemented in the cloud without affecting the game performance, and load balancing without imposing any compulsory restrictions on the player. Can be done. This advantage is extremely useful for games in genres where maintaining immersiveness in the gaming world is essential to the user experience, such as open-world MMO games.
  • load balancing is a mechanism unrelated to the rules in the game, such as explicitly recommending to move to another world, making it impossible to log in due to congestion, or forcing you to log out. Has been realized.
  • the game system of the present embodiment can dramatically increase the interaction between players in the game as compared with the conventional case.
  • the same world information can be acquired regardless of which server 10 accesses which storage server, so that the amount of user interaction that can be processed in one area can be reduced.
  • the game system of this embodiment can also be applied as a load balancing technology for non-open world type MMO games.
  • the game system of the present embodiment can be applied as a technique for realizing load balancing in one world even in an MMO game in which the world is divided into a plurality of worlds. Therefore, it is also effective as a load balancing technology for existing MMO games. Further, it can be applied to a wide range of games such as FPS and Second Life type communication services, which involve interaction between players and provide a high degree of freedom to users.
  • One of the servers of a game system having a plurality of servers in charge of each of a plurality of areas in a game space and managing object information indicating the state of each of the plurality of objects that can move between the areas.
  • An object information storage unit that stores the object information and Among the object information stored in the object information storage unit, a first update unit that updates the object information of the object existing in the area in charge, and a first update unit.
  • a MAC address storage unit that stores the MAC (media access control) address of the target server that is a part of the plurality of servers.
  • a first transmission unit that transmits updated information indicating information to the target server, and Based on the update information received from the other server, among the object information stored in the object information storage unit, the object information of the object existing outside the area in charge is updated, and the object information is updated.
  • a second update unit that realizes the update of the object information in chronological order based on the time information, and Server with. 2. 2. The server according to 1, wherein the time information is generated by the same process by each of the plurality of servers. 3. 3. 3.
  • the server described in 2. 4.
  • the MAC address storage unit stores the MAC address of the packet transmission destination set by the network traffic control function provided by the kernel of the OS (operating system) installed in the server.
  • the server according to any one of 1 to 4, wherein the transmission of the update information to the target server by the first transmission unit is realized by the network traffic control function of the OS. 6.
  • a game system having a plurality of the servers according to any one of 1 to 5. 7.
  • the server of one of the game systems having a plurality of servers in charge of each of a plurality of areas in the game space and managing object information indicating the state of each of the plurality of objects that can move between the areas.
  • the object information and the MAC address of the target server which is a part of the plurality of servers are stored.
  • the first update step of updating the object information of the object existing in the area in charge and By packet transfer based on the data of the data link layer destined to the MAC address, the target is the update information indicating the update content of the object information in the first update step and the time information indicating the in-game time at the time of update.
  • processors 1A processor 2A memory 3A input / output I / F 4A Peripheral circuit 5A Bus 10 Server 11 Object information storage unit 12 First update unit 13 First transmission unit 14 MAC address storage unit 15 Second update unit 16 Second transmission unit 20 Player terminal 30 Internet

Abstract

本発明は、ゲーム空間内の複数のエリア各々を担当し、エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバ（１０）を有するゲームシステムの１つのサーバ（１０）であって、オブジェクト情報を記憶するオブジェクト情報記憶部（１１）と、記憶されているオブジェクト情報のうち、担当するエリア内に存在するオブジェクトのオブジェクト情報の更新を行う第１の更新部（１２）と、複数のサーバ（１０）の中の一部である対象サーバのＭＡＣアドレスを記憶するＭＡＣアドレス記憶部（１４）と、記憶されているＭＡＣアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、第１の更新部（１２）によるオブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を対象サーバに送信する第１の送信部（１３）と、他のサーバ（１０）から受信した更新情報に基づき、記憶されているオブジェクト情報のうち、担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第２の更新部（１５）と、を有するサーバ（１０）を提供する。

Description

サーバ、ゲームシステム及び処理方法
　本発明は、サーバ、ゲームシステム及び処理方法に関する。
　近年流行しているオープンワールド型のゲームを大規模なＭＭＯ（Massively Multiplayer Online）として提供することが出来れば、開発コストの高いオープンワールド型のゲームから、長期的に利益を得ることが出来るようになる。
　オープンワールド型のＭＭＯゲームでは、例えばゲーム空間が複数のエリアに分かれており、１つのエリアが１つの負荷分散の単位に対応する。そして、オブジェクト（キャラクタ等）の移動、キャラクタ同士の戦闘、アイテム交換、魔法の発動などの相互作用が負荷分散の単位をまたがって行われることがあるため、分散したオンメモリデータベース間の同期処理が必要となる。
　このようなオープンワールド型のＭＭＯゲームを対象としたオンメモリデータベースを実現する際の最大の課題は、オブジェクトが複数のエリアをまたいで自由に移動する状況において、複数のノードによる適切な負荷分散機能を実現する点にある。
　オブジェクトがオープンワールドにおいて自由に移動・行動する状況において、オブジェクトの移動範囲の制限や、同時ログイン可能なプレイや数の制限を設定することなく、オブジェクトの自由行動を許可したまま、自動的にサーバへの負荷を平準化させる新たな同期方式が望まれている。
　例えば、非特許文献１乃至３に開示のように、データ・レプリケーションや、データ同期、分散データベースの分野において、数多くの研究がなされてきた。また、非特許文献４乃至６に開示のように、ＭＭＯを対象としたデータベース負荷分散やデータ同期の研究も、データ・レプリケーション技術の発展として捉えられ、北米やカナダで活発に研究されてきた。しかしながら、これらは、ゲーム内のエリアやオブジェクトにラベル付けを行い、そのラベルへのPublish/Subscribeモデルとしてデータの分散と購読を行っており、オープンワールド型の、不特定多数のオブジェクトが１つの仮想空間を共有して、リアルタイムにデータを更新しあうような状況は想定していない。
　また、非特許文献７に開示のように、ＩＰ（internet protocol）マルチキャストを活用したデータ・レプリケーション方式の研究がなされ、特許文献１に開示のようにそれに関連する特許出願もなされている。しかし、ＩＰマルチキャストを柔軟に行うことは難しい。特に、データ・レプリケーションが求める柔軟性と効率性を達成することが難しく、発展的な研究は行われていない。
　非特許文献８や非特許文献９に開示のように、地理的関係を活用したデータ・レプリケーションの方式は提供されているものの、ゲーム固有の仮想空間の情報を活用したデータ・レプリケーション方法は知られていない。また、分散共有メモリ、特に、パブリッククラウドで柔軟に利用可能なソフトウェアベースの分散共有メモリの分野においては、非特許文献１０及び１１に開示のように、Kerrighed、openMosix、OpenSSIといった研究とＯＳＳプロジェクトが立ちあげられてきた。しかしながら、それらは２０００年代半ばにプロジェクトが休止し、広く活用されるには至っていない。
　近年、非特許文献１２に開示のように、カーネルレベルでのリモートメモリアクセスを透過的に実現する仕組みも研究されている。しかし、それらは主に大規模な科学技術演算を行うことを想定しており、ゲームのように、コンテンツの状況に応じてメモリへのアクセスパターンが大きく変化するアプリケーションは、いまだ研究されてこなかった。現在は、非特許文献１３及び１４に開示のように、クラウド上での共有メモリが活発に研究されているが、ゲームへの応用は考慮されておらず、汎用的なユースケースにとどまっている。
ＵＳ９３３０１５４Ｂ２
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/
　本発明は、ゲームシステムに適した新たなデータ同期方式を提供することを課題とする。
　本発明によれば、
　ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの１つの前記サーバであって、
　　前記オブジェクト情報を記憶するオブジェクト情報記憶部と、
　　前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第１の更新部と、
　　前記複数のサーバの中の一部である対象サーバのＭＡＣ（media access control）アドレスを記憶するＭＡＣアドレス記憶部と、
　　前記ＭＡＣアドレス記憶部に記憶された前記ＭＡＣアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第１の更新部による前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第１の送信部と、
　　他の前記サーバから受信した前記更新情報に基づき、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第２の更新部と、
を有するサーバが提供される。
　また、本発明によれば、前記サーバを複数有するゲームシステムが提供される。
　また、本発明によれば、
　ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの１つの前記サーバが、
　　前記オブジェクト情報と、前記複数のサーバの中の一部である対象サーバのＭＡＣアドレスを記憶し、
　　記憶している前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第１の更新工程と、
　　前記ＭＡＣアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第１の更新工程での前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第１の送信工程と、
　　他の前記サーバから受信した前記更新情報に基づき、記憶している前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第２の更新工程と、
を実行する処理方法が提供される。
　本発明によれば、ゲームシステムに適した新たなデータ同期方式が提供される。
本実施形態のゲームシステムの全体像を説明するための図である。 本実施形態のサーバのハードウエア構成の一例を示す図である。 本実施形態のサーバの機能を説明するための図である。 本実施形態のサーバの機能ブロックの一例を示す図である。 本実施形態のサーバが処理する情報の一例を模式的に示す図である。 本実施形態のサーバが処理する情報の一例を模式的に示す図である。 本実施形態のサーバが処理する情報の一例を模式的に示す図である。 本実施形態のサーバの処理の流れの一例を説明するためのフローチャートである。 本実施形態のサーバの処理の流れの一例を説明するためのフローチャートである。 本実施形態のサーバの処理の流れの一例を説明するためのフローチャートである。 本実施例のサーバを説明するための図である。 本実施例のサーバを説明するための図である。 本実施例のサーバを説明するための図である。
＜技術思想＞
　まず、本実施形態のゲームシステムの技術思想を説明する。本実施形態の目的は、例えば明示的なサーバ分割の単位を持たないオープンワールド型ＭＭＯゲームを対象として、各サーバが管理するゲームのステート情報を適切にサーバ間で同期することが可能な大規模な負荷分散を実現することである。そのために、本実施形態では、ゲームの仮想空間上で地理的に近いエリアを担当するサーバ間の接続を、アプリケーションを介さないＯＳ（operating system）カーネル間の直接的な通信として実装し、分散共有メモリ上で高効率にステート情報を管理する方式を採用する。
　具体的には、本実施形態では、ゲーム空間は複数のエリアに分割され、エリアごとに担当サーバが決定される。そして、互いの間をオブジェクトが頻繁に移動する２つのエリア各々を担当するサーバ間の通信を高速化させるために、それぞれのサーバで動作するＯＳのカーネルを用いた疑似ＩＰマルチキャスト処理を導入する。この仕組みは、オブジェクトの移動頻度[0]が高いことが予めわかっているノード群があれば、それらのノード群が同一パケットを自動的に受け取るように、カーネルのパケット転送フィルタを予め設定できるという点に着目したものである。[0]これにより、互いの間を高頻度にオブジェクトが移動する２つのエリア各々を担当するサーバ間では、カーネル間通信を用いて、すなわち、ＯＳのカーネルが管理するメモリ領域から個別のアプリケーションが管理するメモリ領域へ、パケットのデータをコピーすることや、ＣＰＵの実行権限をカーネルからアプリケーションへ移譲するコンテクスト・スイッチングをすることなく、オブジェクトの更新情報を即時かつ高速にプッシュ型で送受信（同期）することができる。当該構成により、ゲームのマップ情報と完全に一致する疑似ＩＰマルチキャストネットワーク構造を静的に構築することができる。
　ここで、「擬似ＩＰマルチキャストネットワーク構造」について説明する。疑似ＩＰマルチキャストネットワーク構造は、カーネル上でパケット転送設定（宛先ＭＡＣアドレスの登録）を行うことで構築される。当該擬似ＩＰマルチキャストネットワーク構造においては、互いのＭＡＣアドレスを宛先ＭＡＣアドレスとして登録したサーバ間が直接接続される。直接接続されたサーバ間においては、擬似的なマルチキャスト機能を用いて、分散共有メモリを構築する各ノードのカーネルをルータにしてデータを送受信可能となっている。
　本実施形態は、分散共有メモリの各ノードのカーネルをルータにすることにより、中央制御されたルータやアプリケーション層の高度なルーティング処理を必要とせずに、高効率なカーネル間通信でwrite命令のルーティングとＴｉｃｋ－ＩＤによる一貫性制御を行う。このように、本実施形態は、ルータ等の専用ネットワーク機器やアプリケーション固有のパケット送受信処理を用いずに、標準的なカーネルの機能のみで所定のパケットを適切な受信先へと送り届ける機能を実現するという特徴を有する。
　なお、上記カーネル間通信が行われないサーバ間（疑似ＩＰマルチキャストネットワーク構造で直接接続されていないサーバ間）で同期が必要になった時は、例えば、通常のアプリケーションレベルのＩＰ通信を採用し、必要な時にプル型で更新情報を送受信（同期）することができる。
　また、本実施形態は、カーネルのパケット転送フィルタを用いた疑似ＩＰマルチキャストを用いるため、ネットワークの設定を変更することなく、柔軟にサーバからの同期先を変更することができる。１つのサーバが複数のサーバからの同期を受け入れることも可能である。
　一般的に、プッシュ型同期では、プッシュされたデータ間の整合性、一貫性を管理することが極めて重要となるが、本実施形態では、ゲーム固有の時間情報（Ｔｉｃｋ－ＩＤ等）を用いてメモリの更新／読み出し操作を直列化する。このため、従来の分散データベースの問題であった、データ整合性の問題を生じさせずに分散処理を行うことができる。したがって、ゲーム用途においては、ほとんどの場合はロックフリーで動作するインメモリデータベースとしてふるまうことが可能である。
＜処理の概要＞
　次に、本実施形態のゲームシステムの処理の概要を説明する。本実施形態のゲームシステムは複数のサーバを有する。そして、複数のサーバ各々がゲーム空間内の複数のエリア各々を担当する。各サーバは、プレイヤ入力又は自装置内で生成された制御情報に基づき、自サーバが担当するエリア内に存在するオブジェクトのオブジェクト情報（上記ステート情報に対応）の更新を行う。
　そして、複数のサーバは、各サーバが管理するオブジェクト情報を同期する処理を行う。互いの間をオブジェクトが頻繁に移動する２つのエリア各々を担当するサーバ間では、ＯＳのカーネルを用いた疑似ＩＰマルチキャスト処理でプッシュ型の同期を行う。
　プッシュ型の同期では、各サーバのＯＳは、他のサーバからのリクエストなしで、予め登録されている対象サーバのＭＡＣアドレスを宛先としたデータリンク層（Ｌ２）のデータに基づくパケット転送により、更新情報を当該対象サーバに送信する。このような処理により、即時かつ高速な同期が実現される。対象サーバは、複数のサーバの中の一部である。どのサーバを対象サーバとするかはサーバごとに決定される。各サーバが担当するエリアとの間でのオブジェクトの行き来が高頻度で行われるエリアを担当するサーバが、各サーバの対象サーバとして設定される。
　プッシュ型の同期は、例えば、サーバが受信した全データを常に所定のサーバ群へとコピーすることとする。これを、レプリケーションと呼ぶ。変形例として、プッシュ型の同期では、逐次的にパケットをコピーするのではなく、一定期間バッファリングしてからコピーしてもよい。
　なお、プッシュ型の同期が行われないサーバ間で同期が必要になった時は、例えば、通常のアプリケーション層の通信、例えばＩＰ通信を採用し、必要な時にプル型で更新情報を送受信することができる（プル型の同期）。例えば、第１のサーバの対象サーバとして設定されておらず、第１のサーバとの間でプッシュ型の同期が行われないサーバが、必要に応じて第１のサーバに更新情報を要求する。プッシュ型の同期は、パケットを受け取ったサーバが能動的にパケットを他のサーバに転送することを意味する。プル型の同期は、情報が必要になったサーバがその情報を他のサーバに要求して取得することで、必然的に同期が行われるというものである。
　プル型の同期では、各サーバ上で稼働するアプリケーションは、他のサーバからのリクエストに応じて、例えばＩＰ通信で、更新情報を他のサーバに送信する。リクエストを発生させることができるのは、データが必要とされているという状況を認識できるアプリケーションのみである。このため、このプル型の同期は、必然的に、アプリケーション層の処理が必要になる。なお、アプリケーション層の処理を要する通信では、異なる階層間でのデータの受け渡し等が発生するうえ、コンテキストスイッチが必要になるため、一般的に、１バイトあたりの送受信に必要な時間が大きくなる。このため、当該プル型の同期は、プッシュ型の同期に比べて低速な同期となる。プル型の同期では、更新内容のみを送受信してもよし、リクエストで指定された内容のみを送受信してもよい。
　以上、本実施形態では、互いが担当するエリア間でオブジェクトの行き来が高頻度で行われるサーバ間は、疑似ＩＰマルチキャストネットワーク構造で直接接続し（カーネル上のパケット転送設定において、互いのＭＡＣアドレスを宛先として登録）、プッシュ型の同期で即時かつ高速な同期を行う。プッシュ型の同期の設定を、仮想空間上の地理的関係に基づいて行うことにより、プッシュ型の同期によるデータの共有率を高く保ちながら、プッシュ同期にかかるＣＰＵ負荷、ネットワーク負荷を低く抑えることができる。
　また、本実施形態では、サーバ間で送受信する更新情報の中にＴｉｃｋ－ＩＤ等の時間情報を含める。そして、この時間情報を用いて、メモリの更新／読み出し操作を直列化する。これによりデータ間の整合性や一貫性を管理することが可能となる。
＜ゲームシステムの全体構成＞
　次に、本実施形態のゲームシステムの全体構成を説明する。図１に示すように、ゲームシステムは、複数のサーバ１０を有する。
　複数のサーバ１０は、同一のネットワークもしくはクラウド上の同一の仮想ネットワーク内に位置し、データリンク層のアドレス（ＭＡＣアドレス）に基づくパケット転送により、互いにデータの送受信ができるようになっている。例えば、複数のサーバ１０は、同一の仮想ネットワーク内（例えば、仮想ネットワークサーバを論理的に分割することで生成されたサブネット）に存在することができる。例えば、非特許文献１５に開示の技術を利用して、このような複数のサーバ１０の構成を実現することができる。
　複数のサーバ１０は、インターネット３０を介して、複数のプレイヤ端末２０と接続される。プレイヤ端末２０は、プレイヤが操作する端末であり、例えばスマートフォン、タブレット端末、ＰＣ（personal computer）、携帯電話、ゲーム端末等が例示されるが、これらに限定されない。
＜サーバ１０の構成＞
　次に、サーバ１０の構成を説明する。まず、サーバ１０のハードウエア構成を説明する。本実施形態のサーバ１０が備える各機能部は、任意のコンピュータのＣＰＵ（Central Processing Unit）、メモリ、メモリにロードされるプログラム、そのプログラムを格納するハードディスク等の記憶ユニット（あらかじめ装置を出荷する段階から格納されているプログラムのほか、ＣＤ（Compact Disc）等の記憶媒体やインターネット上のサーバ等からダウンロードされたプログラムをも格納できる）、ネットワーク接続用インターフェイスを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
　図２は、本実施形態のサーバ１０のハードウエア構成を例示するブロック図である。図２に示すように、サーバ１０は、プロセッサ１Ａ、メモリ２Ａ、入出力インターフェイス３Ａ、周辺回路４Ａ、バス５Ａを有する。周辺回路４Ａには、様々なモジュールが含まれる。サーバ１０は周辺回路４Ａを有さなくてもよい。
　なお、サーバ１０は物理的及び／又は論理的に分かれた複数の装置で構成されてもよい。すなわち、１つのサーバ１０は、複数の装置のクラスタとして構成されてもよい。この場合、各装置が上記ハードウエア構成を備えることができる。その他、サーバ１０は、物理的及び論理的に１つの装置で構成されてもよい。
　バス５Ａは、プロセッサ１Ａ、メモリ２Ａ、周辺回路４Ａ及び入出力インターフェイス３Ａが相互にデータを送受信するためのデータ伝送路である。プロセッサ１Ａは、例えばＣＰＵ、ＧＰＵ（Graphics Processing Unit）などの演算処理装置である。メモリ２Ａは、例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリである。入出力インターフェイス３Ａは、入力装置、外部装置、外部サーバ、外部センサ等から情報を取得するためのインターフェイスや、出力装置、外部装置、外部サーバ等に情報を出力するためのインターフェイスなどを含む。入力装置は、例えばキーボード、マウス、マイク等である。出力装置は、例えばディスプレイ、スピーカ、プリンター、メーラ等である。プロセッサ１Ａは、各モジュールに指令を出し、それらの演算結果をもとに演算を行うことができる。
　次に、サーバ１０の機能構成を説明する。本実施形態のゲームシステムが提供するゲームは、例えばオープンワールド型ＭＭＯゲームである。図３に示すように、ゲーム空間は複数のエリアに分かれている。ゲーム空間内に存在するオブジェクトは、エリア間を移動可能である（すなわち、エリアを跨いだ移動が可能）。オブジェクトは、プレイヤにより制御されるプレイヤオブジェクトや、プレイヤにより制御されないノンプレイヤオブジェクトを含む。オブジェクトは、キャラクタ、弓、銃弾、鳥等のあらゆるオブジェクトを含む。各サーバ１０は、複数のエリア各々を担当する。
　ここで、「エリアを担当する」の概念を説明する。複数のエリアの中の第１のエリアを担当するサーバ１０は、第１のエリアに存在するオブジェクトの状態を示すオブジェクト情報を記憶し、プレイヤ入力で生成された制御情報、又は、自装置で決定した制御情報に基づき、そのオブジェクト情報を更新する。そして、第１のエリアを担当するサーバ１０は、第１のエリアに存在するオブジェクトのオブジェクト情報の更新内容を示す更新情報を、他のサーバ１０に送信する。このように、第１のエリアを担当するサーバ１０は、上述のような処理で担当するエリアに存在するオブジェクトのオブジェクト情報を更新するとともに、その更新内容を他のサーバ１０に送信する。
　なお、以下の説明で明らかになるが、第１のエリアを担当するサーバ１０は、第１のエリアに存在するオブジェクトのオブジェクト情報のみならず、担当するエリアの外に存在するオブジェクトのオブジェクト情報も記憶し、更新する。例えば、第１のエリアを担当するサーバ１０は、第１のエリアとの間でのオブジェクトの行き来が高頻度で行われるエリアを担当するサーバ１０からプッシュ型の同期で受信したそのエリアに存在するオブジェクトのオブジェクト情報を記憶し、更新する。また、例えば、第１のエリアを担当するサーバ１０は、その他のエリアを担当するサーバ１０からプル型の同期で受信したそのエリアに存在するオブジェクトのオブジェクト情報を記憶し、更新する。
　しかし、担当するエリアに存在するオブジェクトのオブジェクト情報の更新方法と、担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新方法は異なる。具体的には、担当するエリアに存在するオブジェクトのオブジェクト情報の更新方法は上述の通りである。これに対し、担当するエリアの外に存在するオブジェクトのオブジェクト情報は、他のサーバ１０からプッシュ型又はプル型の同期で受信した更新情報に基づき更新される。また、サーバ１０は、担当するエリアの外に存在するオブジェクトのオブジェクト情報を更新しても、その更新内容を示す更新情報を他のサーバ１０に送信しない。この点でも、担当するエリアに存在するオブジェクトと他のエリアに存在するオブジェクトとの扱いが異なる。
　図４に、サーバ１０の機能ブロック図の一例を示す。図示するように、サーバ１０は、オブジェクト情報記憶部１１と、第１の更新部１２と、第１の送信部１３と、ＭＡＣアドレス記憶部１４と、第２の更新部１５と、第２の送信部１６とを有する。
　オブジェクト情報記憶部１１は、ゲーム空間内に存在するオブジェクトの状態を示すオブジェクト情報を記憶する。オブジェクト情報は、ゲーム空間におけるオブジェクトの位置を示す位置情報、オブジェクトの向きを示す向き情報、ヒットポイント、攻撃力、防御力、レベル等のあらゆる情報を含む。
　各サーバ１０のオブジェクト情報記憶部１１は、ゲーム空間内に存在する複数のオブジェクトの中の一部のオブジェクトのオブジェクト情報を記憶する。オブジェクト情報記憶部１１は、自サーバ１０が担当するエリア内に存在するオブジェクトのオブジェクト情報を記憶する。
　ここで、「自サーバ１０」について説明する。まず、複数のサーバ１０の中の１つである第１のサーバ１０内に実現された機能部（オブジェクト情報記憶部１１、第１の更新部１２、第１の送信部１３、ＭＡＣアドレス記憶部１４、第２の更新部１５及び第２の送信部１６）を第１の機能部と定義する。この場合、第１の機能部にとって第１のサーバ１０は「自サーバ１０」となる。そして、第１の機能部にとって、第１のサーバ１０以外のサーバ１０は「他のサーバ１０」となる。
　オブジェクト情報記憶部１１の構成の説明に戻る。オブジェクト情報記憶部１１は、自サーバ１０が担当するエリアの外に存在するオブジェクトのオブジェクト情報を記憶することもできる。具体的には、オブジェクト情報記憶部１１は、同期処理で他のサーバ１０から受信したオブジェクト情報を記憶する。すなわち、オブジェクト情報記憶部１１は、プッシュ型の同期処理により、疑似ＩＰマルチキャストネットワーク構造で自サーバ１０と直接接続されている他のサーバ１０から受信したオブジェクト情報を記憶する。また、オブジェクト情報記憶部１１は、例えばプル型の同期処理により、疑似ＩＰマルチキャストネットワーク構造で自サーバ１０と直接接続されていない他のサーバ１０から受信したオブジェクト情報を記憶する。
　図５に、オブジェクト情報の一例を模式的に示す。図示するように、オブジェクト情報は、各パラメータの更新タイミングを示す情報をさらに含むことができる。更新タイミングは、例えばゲーム内時間を示す時間情報で示される。ゲーム内時間を示す時間情報の一例として、Ｔｉｃｋ－ＩＤが例示される。以下、ゲーム内時間を示す時間情報はＴｉｃｋ－ＩＤである前提とする。なお、パラメータ毎に更新タイミングを管理する手法に代えて、オブジェクト毎に更新タイミングを管理する手法を採用してもよい。
　ここで、Ｔｉｃｋ－ＩＤについて説明する。Ｔｉｃｋ－ＩＤは、複数のサーバ１０各々により同一の処理で生成される。各サーバ１０は、所定時間毎にＴｉｃｋ－ＩＤを更新する。例えば、Ｔｉｃｋ－ＩＤは数字で示され、各サーバ１０は、所定時間毎にＴｉｃｋ－ＩＤを所定数ずつ（例えば「１」）増加させる。Ｔｉｃｋ－ＩＤの更新周期は、例えば０．０３～０．０５秒（２０Ｈｚ～３０Ｈｚ程度）である。ＮＴＰ（network time protocol）を用いる方法や、全てのサーバ１０に原子時計を配備する方法等の任意の手段で、複数のサーバ１０は同じタイミングで同じ値のＴｉｃｋ－ＩＤを生成するように同期されている。
　図４に戻り、第１の更新部１２は、オブジェクト情報記憶部１１に記憶されているオブジェクト情報のうち、自サーバ１０が担当するエリア内に存在するオブジェクトのオブジェクト情報の更新を行う。
　例えば、第１の更新部１２は、自サーバ１０が担当するエリアに存在するプレイヤオブジェクトの制御情報をプレイヤ端末２０から受信し、その制御情報に基づきそのプレイヤオブジェクトのオブジェクト情報を更新する。プレイヤオブジェクトの制御情報は、例えばプレイヤ端末２０を介したプレイヤ入力に基づき生成される。制御情報は、プレイヤ入力の内容を示す情報（タッチ位置を時系列に示すデータ、当該データに基づき算出された大きさや方向を示すデータ等）であってもよいし、プレイヤ入力の内容に基づきプレイヤ端末２０が決定した制御内容（プレイヤオブジェクトの移動量、移動方向、移動後の位置等）を示す情報であってもよい。
　また、例えば、第１の更新部１２は、自サーバ１０が担当するエリアに存在するノンプレイヤオブジェクトの制御内容を決定し、そのノンプレイヤオブジェクトのオブジェクト情報を更新する。ノンプレイヤオブジェクトの制御内容を決定するアルゴリズムは設計的事項である。
　上述のような処理でオブジェクト情報を更新する第１の更新部１２は、自サーバ１０が担当するエリアに存在するオブジェクトのオブジェクト情報の更新のみを行い、自サーバ１０が担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新は行わない。
　第１の更新部１２は、Ｔｉｃｋ－ＩＤに基づき、時系列順のオブジェクト情報の更新を実現する。例えば、第１の更新部１２は、所定のオブジェクトのオブジェクト情報の所定のパラメータを更新する際、まず、オブジェクト情報記憶部１１が記憶するオブジェクト情報を参照して（図５参照）、そのパラメータの最新の更新タイミングのＴｉｃｋ－ＩＤを特定する。そして、最新の更新タイミングのＴｉｃｋ－ＩＤが、今回の更新タイミングのＴｉｃｋ－ＩＤ（現時点のＴｉｃｋ－ＩＤ）よりも時間的に前である場合、問題ないので第１の更新部１２は更新処理を実行する。一方、最新の更新タイミングのＴｉｃｋ－ＩＤが、今回の更新タイミングのＴｉｃｋ－ＩＤ（現時点のＴｉｃｋ－ＩＤ）よりも時間的に後である場合、問題ありなので第１の更新部１２は更新処理を実行しない。この場合、第１の更新部１２は任意のエラー処理を実行する。
　ＭＡＣアドレス記憶部１４は、複数のサーバ１０の中の一部である対象サーバのＭＡＣアドレスを記憶する。図６に、ＭＡＣアドレス記憶部１４が記憶する対象サーバ情報の一例を模式的に示す。対象サーバ情報の内容は、サーバ１０毎に異なる。すなわち、サーバ１０毎に、どのサーバ１０を対象サーバとするかは異なる。
　例えば、ＭＡＣアドレス記憶部１４は、自サーバ１０が担当するエリアとの地理的関係が所定条件を満たすエリアを担当するサーバ１０のＭＡＣアドレスを記憶する。すなわち、自サーバ１０が担当するエリアとの地理的関係が所定条件を満たすエリアを担当するサーバ１０が、自サーバ１０の対象サーバとなる。所定条件は、「一方のエリア内から他方のエリア内へのオブジェクトの移動に要する最短の時間が基準値以下」、「互いに隣接する」、「互いに隣接し、かつ、互いの境界部分にエリア間移動を妨げる障害物がない」、「互いの最短距離が、任意のオブジェクト（弓矢や砲弾等のキャラクタ外のオブジェクト等）の移動距離以内」、「ゲーム上、他のエリアを介さずに互いのエリア間を移動可能になっている（徒歩等での隣接エリア間移動、ワープ等での互いに離れたエリア間移動等）」等が例示されるが、これに限定されない。
　図６に示すような対象サーバ情報は、ゲームシステムを管理するオペレータにより生成される。例えば、オペレータは、サーバ１０毎に対象サーバのＭＡＣアドレスを入力することで、図６に示すような対象サーバ情報を生成してもよい。
　その他、各サーバ１０は、図７に示すような他のサーバ１０に関するサーバ情報を記憶しておいてもよい。サーバ情報は、他のサーバ１０各々のサーバ識別情報と、他のサーバ１０各々のＭＡＣアドレスと、他のサーバ１０各々が担当するエリアの識別情報とが紐づけられている。この場合、オペレータは、サーバ１０毎に対象サーバとするサーバ１０のサーバ識別情報を入力してもよい。そして、サーバ１０は、入力されたサーバ識別情報に紐づくＭＡＣアドレスをサーバ情報から取得し、対象サーバ情報に登録してもよい。その他、オペレータは、サーバ１０毎に対象サーバとするサーバ１０が担当しているエリアのエリア識別情報を入力してもよい。そして、サーバ１０は、入力されたエリア識別情報に紐づくＭＡＣアドレスをサーバ情報から取得し、対象サーバ情報に登録してもよい。
　なお、ＭＡＣアドレス記憶部１４への対象サーバのＭＡＣアドレスの登録は、例えばサーバ１０にインストールされたＯＳのカーネルが提供するネットワークトラフィック制御機能におけるパケット送信先のＭＡＣアドレスの登録（フィルタリングの設定）で実現される。
　第１の送信部１３は、対象サーバからのリクエストなしで、ＭＡＣアドレス記憶部１４に記憶されたＭＡＣアドレスを宛先としたデータリンク層のデータ（ＭＡＣアドレス等）に基づくパケット転送により、第１の更新部１２によるオブジェクト情報の更新内容を示す更新情報を対象サーバに送信する。第１の送信部１３は、第１の更新部１２によるオブジェクト情報の更新に応じて、その更新内容を示す更新情報を対象サーバに送信することができる。更新が行われたタイミングから更新情報の送信までのタイムラグ（経過時間）はできるだけ小さいのが好ましい。
　更新情報には、更新が行われたタイミングを示す情報（更新時のＴｉｃｋ－ＩＤ）が含まれる。
　なお、上述したデータリンク層のデータ（ＭＡＣアドレス等）を利用した一部のサーバ１０（対象サーバ）への更新情報の送信は、例えばＯＳのネットワークトラフィック制御機能におけるパケットフィルタリング機能で実現される。
　第２の更新部１５は、プッシュ型同期又はプル型同期で他のサーバ１０から受信した更新情報に基づき、オブジェクト情報記憶部１１に記憶されているオブジェクト情報のうち、自サーバ１０が担当するエリアの外（自サーバ１０が担当しないエリア）に存在するオブジェクトのオブジェクト情報の更新を行う。
　なお、上述のような処理でオブジェクト情報を更新する第２の更新部１５は、自サーバ１０が担当するエリアの外に存在するオブジェクトのオブジェクト情報の更新のみを行い、自サーバ１０が担当するエリアに存在するオブジェクトのオブジェクト情報の更新は行わない。
　第２の更新部１５は、Ｔｉｃｋ－ＩＤに基づき、時系列順のオブジェクト情報の更新を実現する。例えば、第２の更新部１５は、所定のオブジェクトのオブジェクト情報の所定のパラメータを更新する際、まず、オブジェクト情報記憶部１１が記憶するオブジェクト情報を参照して（図５参照）、そのパラメータの最新の更新タイミングのＴｉｃｋ－ＩＤを特定する。そして、最新の更新タイミングのＴｉｃｋ－ＩＤが、更新情報に含まれるＴｉｃｋ－ＩＤ（他のサーバ１０で更新が行われ時のＴｉｃｋ－ＩＤ）よりも時間的に前である場合、問題ないので第２の更新部１５は更新処理を実行する。一方、最新の更新タイミングのＴｉｃｋ－ＩＤが、更新情報に含まれるＴｉｃｋ－ＩＤ（他のサーバ１０で更新が行われ時のＴｉｃｋ－ＩＤ）よりも時間的に後である場合、問題ありなので第２の更新部１５は更新処理を実行しない。この場合、第２の更新部１５は任意のエラー処理を実行する。
　例えば、第２の更新部１５は、プッシュ型同期で更新情報が送受信された場合、更新・読み出しの操作に紐付くＴｉｃｋ－ＩＤに基づいて更新・読み出し操作を直列化する（更新・読み出しの順序を決定する）。そして、順序を決定した後、データ競合の問題が生じるときは、第２の更新部１５は例外をゲームロジックへ通知する。ゲームロジック側は、例えば、プレイヤごとに優先順位を設ける方式や、あるいは、エフェクトで競合状態をごまかすなどの方法（ゲームロジックの処理は設計事項）で、データ競合を解消する。データ競合の問題は、例えば、同一のＴｉｃｋ－ＩＤで、かつ、同一のメモリブロックアドレスへ、ｒｅａｄ操作とｗｒｉｔｅ操作が行われる場合や、同一のＴｉｃｋ－ＩＤで、かつ、同一のメモリブロックアドレスへ、２つ以上のｗｒｉｔｅ操作が行われる場合である。
　図４に戻り、第２の送信部１６は、他のサーバ１０からのリクエストに応じて、ＩＰ通信で、オブジェクト情報記憶部１１に記憶されているオブジェクト情報を他のサーバ１０に送信する。第２の送信部１６は、各パラメータの更新タイミングを含むオブジェクト情報を他のサーバ１０に送信することができる。当該ＩＰ通信におけるネットワーク層のプロトコルはＩＰプロトコルであり、トランスポート層のプロトコルは、ＴＣＰ（Transmission Control Protocol）プロトコルやＵＤＰ（User Datagram Protocol）プロトコル等である。
　他のサーバ１０からのリクエストは、オブジェクトを指定する情報が含まれてもよい。そして、第２の送信部１６は、オブジェクト情報記憶部１１に記憶されているオブジェクト情報のうち、指定されたオブジェクトのオブジェクト情報を他のサーバ１０に送信してもよい。
　次に、サーバ１０の処理の流れの一例を説明する。
　まず、図８のフローチャートを用いて、「自サーバ１０が担当するエリアに存在するオブジェクトのオブジェクト情報を更新し、更新情報を対象サーバに送信する処理」の流れの一例を説明する。
　第１の更新部１２は、自サーバ１０が担当するエリアに存在するオブジェクトに関する制御情報の取得待ちとなっている（Ｓ１０）。例えば、第１の更新部１２は、自サーバ１０が担当するエリアに存在するプレイヤオブジェクトの制御情報をプレイヤ端末２０から受信することができる。また、第１の更新部１２は、自サーバ１０内で生成された自サーバ１０が担当するエリアに存在するノンプレイヤオブジェクトの制御情報を取得することができる。
　制御情報を取得すると（Ｓ１０のＹｅｓ）、第１の更新部１２は、制御情報に基づきオブジェクトの更新内容を決定する（Ｓ１１）。例えば、制御情報がオブジェクトの移動方向や移動距離を示す場合、第１の更新部１２は、現在のそのオブジェクトの位置と当該制御情報とに基づき、そのオブジェクトの新たな位置を決定する。なお、制御情報に基づく更新内容の決定処理の詳細は設計的事項であり、この例示に限定されない。
　その後、第１の更新部１２は、オブジェクト情報記憶部１１が記憶するオブジェクト情報を参照し（図５参照）、更新対象のオブジェクトの更新対象のパラメータの最新の更新タイミングを示すＴｉｃｋ－ＩＤを取得する（Ｓ１２）。そして、最新の更新タイミングを示すＴｉｃｋ－ＩＤと、今回の更新タイミングのＴｉｃｋ－ＩＤ（現時点のＴｉｃｋ－ＩＤ）と、を比較する（Ｓ１３）。
　最新の更新タイミングのＴｉｃｋ－ＩＤが、今回の更新タイミングのＴｉｃｋ－ＩＤよりも時間的に前であり、矛盾しない場合（Ｓ１３のＮｏ）、第１の更新部１２は、Ｓ１１で決定した更新内容に基づき、オブジェクト情報記憶部１１が記憶するオブジェクト情報を更新する（Ｓ１４）。この時、第１の更新部１２は、更新したオブジェクトの更新したパラメータに紐づく更新タイミングを示す情報を、今回の更新タイミングを示すＴｉｃｋ－ＩＤに更新する。
　次いで、第１の送信部１３は、Ｓ１４の更新に応じて、対象サーバからのリクエストなしで、ＭＡＣアドレス記憶部１４に記憶されたすべてのＭＡＣアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、Ｓ１４でのオブジェクト情報の更新内容を示す更新情報を対象サーバに送信する（Ｓ１５）。
　一方、最新の更新タイミングのＴｉｃｋ－ＩＤが、今回の更新タイミングのＴｉｃｋ－ＩＤよりも時間的に後であり、矛盾する場合（Ｓ１３のＹｅｓ）、第１の更新部１２は、Ｓ１１で決定した更新内容に基づくオブジェクト情報の更新を行わず、任意のエラー処理を行う（Ｓ１６）。
　以降、サーバ１０は同様の処理を繰り返す。
　次に、図９のフローチャートを用いて、「他のサーバ１０からのリクエストに応じて他のサーバ１０にオブジェクト情報を送信する処理」の流れの一例を説明する。
　第２の送信部１６は、他のサーバ１０からのリクエスト待ちとなっている（Ｓ２０）。そして、第２の送信部１６は、他のサーバ１０からオブジェクト情報のリクエストを受信すると（Ｓ２０のＹｅｓ）、ＩＰ通信で、オブジェクト情報記憶部１１に記憶されているオブジェクト情報を他のサーバ１０に送信する（Ｓ２１）。
　他のサーバ１０からのリクエストは、オブジェクトを指定する情報が含まれてもよい。そして、第２の送信部１６は、オブジェクト情報記憶部１１に記憶されているオブジェクト情報のうち、指定されたオブジェクトのオブジェクト情報を他のサーバ１０に送信してもよい。
　以降、サーバ１０は同様の処理を繰り返す。
　次に、図１０のフローチャートを用いて、「他のサーバ１０からの更新情報の取得に応じて、自サーバ１０が担当するエリアの外に存在するオブジェクトのオブジェクト情報を更新する処理」の流れの一例を説明する。
　第２の更新部１５は、他のサーバ１０からの更新情報受信待ちとなっている（Ｓ３０）。そして、第２の更新部１５は、他のサーバ１０から更新情報を受信すると（Ｓ３０のＹｅｓ）、オブジェクト情報記憶部１１が記憶するオブジェクト情報を参照し（図５参照）、更新対象のオブジェクトの更新対象のパラメータの最新の更新タイミングを示すＴｉｃｋ－ＩＤを取得する（Ｓ３１）。そして、最新の更新タイミングを示すＴｉｃｋ－ＩＤと、更新情報に含まれる更新タイミングのＴｉｃｋ－ＩＤ（他のサーバ１０で更新が行われ時のＴｉｃｋ－ＩＤ）と、を比較する（Ｓ３２）。
　最新の更新タイミングのＴｉｃｋ－ＩＤが、更新情報に含まれる更新タイミングのＴｉｃｋ－ＩＤよりも時間的に前であり、矛盾しない場合（Ｓ３２のＮｏ）、第２の更新部１５は、受信した更新情報で示される更新内容に基づき、オブジェクト情報記憶部１１が記憶するオブジェクト情報を更新する（Ｓ３３）。この時、第２の更新部１５は、更新したオブジェクトの更新したパラメータに紐づく更新タイミングを示す情報を、更新情報に含まれる更新タイミングを示すＴｉｃｋ－ＩＤに更新する。
　一方、最新の更新タイミングのＴｉｃｋ－ＩＤが、更新情報に含まれる更新タイミングのＴｉｃｋ－ＩＤよりも時間的に後であり、矛盾する場合（Ｓ３２のＹｅｓ）、第２の更新部１５は、受信した更新情報で示される更新内容に基づくオブジェクト情報の更新を行わず、任意のエラー処理を行う（Ｓ３４）。
　以降、サーバ１０は同様の処理を繰り返す。
＜実施例＞
　次に、本実施形態のサーバ１０をより具体化した実施例を説明する。なお、当該実施例は上述した実施形態を具体化する一例であり、本実施形態の具体化手段はこれに限定されない。
　従来の分散共有メモリにおいてリモートノードへのメモリアクセス頻度を低減するためには、ノード間で更新されたメモリ内容を頻繁に同期する必要がある。このため、Ｎ台のノードがあるとき、Ｎ２の通信量が発生してしまっていた。本実施例は、ＭＭＯというアプリケーション固有の制約として、仮想空間上のメッシュ構造をデータ同期の範囲として採用することにより、Ｎ２よりもはるかに小さい同期範囲で、実質的に必要なデータ同期を実現する。
　本実施例によるサーバ１０間の同期の全体像を図１１に示す。本実施例では、ゲーム空間を複数のエリアに分割し、各サーバ１０が各エリアを担当する。そして、本実施例では、例えば互いに近傍する複数のエリアを担当する複数のサーバ１０間で、上述したプッシュ型の同期が実行される。なお、互いに近傍しない複数のエリアを担当する複数のサーバ１０間では、上述したプッシュ型の同期が実行されない。これにより、全サーバ１０の内容を同期せずとも、実質的に均一な分散データベースを形成できる。
　また、本実施例では、上記実施形態では説明しなかったが、各エリアはシャード化かつレプリカ化され、負荷分散されてもよい。シャードの分散単位は、プレイヤ単位としてもよいし、オブジェクト単位としてもよいし、その他であってもよい。一例としてシャードの分散単位をプレイヤ単位とした場合、複数のサーバ１０各々で管理される同一プレイヤの情報は同じシャードに格納される。例えばすべてのシャードはプレイヤＩＤに適用するハッシュ関数を共有するため、近傍の同一階層シャードは同一プレイヤの情報を格納することになる。このため、同一階層のシャード間で同期処理を行えばよく、サーバ１０の処理負担が軽減される。
　また、本実施例では、全てのデータ更新／参照操作について、Ｔｉｃｋ－ＩＤで実行順序と整合性を制御することにより、トランザクション隔離レベル問題を解消することができる。すなわち、全ての操作が直列化可能で、全てのエリアをフラットに参照可能なデータベースとして扱うことができる。
　本実施例は、ＡＷＳ（非特許文献１５参照）の各ノード（ＥＣ２インスタンス）で、カーネル上でパケット転送設定をすると、実質的にマルチキャストできるという機能に着目し、分散共有メモリの各ノードのカーネルをルータにするという、「ルータ機能埋め込み型のＤＳＭ（Distributed Shared Memory）」を実現するものである。これにより、ゲームのマップ情報と完全に一致する疑似ＩＰマルチキャストネットワーク構造をクラウド上で静的に構築すると、ゲームのＴｉｃｋ－ＩＤさえパケット内に含まれていれば、ＩＰマルチキャストだけの超高効率なデータレプリケーション・データ同期が可能になる。
　本実施例のシステム構成図を、図１２に示す。本システムは、完全にリニアなアドレス空間を、全サーバ１０をまたがる形でシームレスに提供するわけではなく、図中の"Ｋｅｙ－Ａ"に示されるように、文字列で識別可能な変数を各サーバ１０間で自動的に同期する仕組みである。すなわち、"ｋｅｙ－ｎａｍｅ"を変数ととらえれば、複数のサーバ１０間で共有される変数（メモリブロック）を提供する仕組みといえる。その点で、既存の分散共有メモリと大きく異なる。
　本実施例は、１つのノード（サーバ１０）に閉じて実装することができる３つのモジュールから構成される。
　１つ目のモジュールである［Ｍ１］Ｔｉｃｋ Ｍａｎａｇｅｒは、ゲームの時間単位であるＴｉｃｋ－ＩＤを管理するモジュールであり、原則的には実時間に同期している。この同期は、ＮＴＰ（Network Time Protocol）などの既存の安定した実装を用いることで容易に実装することができる。
　２つ目のモジュールである［Ｍ２］Ｍｅｍｏｒｙ Ｍａｎａｇｅｒは、後述のＡＰＩをサーバ１０側のロジックに提供することにより、分散共有メモリを管理するモジュールである。Ｍｅｍｏｒｙ　ｍａｎａｇｅｒは、Ｔｉｃｋ－ＩＤを用いてメモリの更新／読み出し操作を直列化する。もし、Ｍｅｍｏｒｙ　ＭａｎａｇｅｒがＴｉｃｋ－ＩＤを用いてデータ競合を検出した場合、ゲームロジック型に例外が通知される。ゲームロジック側は、例えば、プレイヤごとに優先順位を設ける方式や、あるいは、エフェクトで競合状態をごまかすなどの方法（ゲームロジックの処理は設計事項）で、データ競合を解消する。データ競合の問題は、例えば、同一のＴｉｃｋ－ＩＤで、かつ、同一のメモリブロックアドレスへの操作（ｒｅａｄ／ｗｒｉｔｅ）が行われた等である。
　最も重要な３つめのモジュールは、カーネル内部で動作する［Ｍ３］Ｃｕｓｔｏｍ Ｌ２ Ｍｕｌｔｉｃａｓｔ Ｍｏｄｕｌｅである。このモジュールは、サーバのＭＡＣアドレスを相互にマルチキャスト先に登録することにより、データリンク層でのパケット転送のネットワーク構造（疑似ＩＰマルチキャストネットワーク構造）を形成する。このネットワーク構造は、ゲームの仮想空間におけるエリア（各サーバ１０が担当するエリア）の近傍関係に対応しており、地理的に近いサーバ１０が接続され、遠いサーバ１０は接続されない。本実施例は、このように連結されたサーバ１０間で共有メモリへの書き込みが、直ちにＬ２パケット転送を通じて共有されるものである。
　このＬ２パケット転送について詳述する。パブリッククラウドを構成する仮想ルータの多くは、ＩＰマルチキャストをサポートしておらず、ネットワーク設定だけでマルチキャストを行うことはできない（非特許文献１５参照）。そのため、マルチキャストをクラウドサービス上で活用することは困難だと考えられてきた。
　しかしながら、クラウドサービスでは、各ノードのＭＡＣアドレスなどの管理情報を、ルータに頼らずに、クラウドの管理システムから動的に入手することができる。このため、クラウド上のノードは、クラウド全体のノード構造を知ることができる。したがって、各ノードでマルチキャストパケットを処理し、独自にマルチキャストを行うことにより、疑似的にマルチキャストをクラウド上で実装することができる。本実施例では、これを疑似ＩＰマルチキャストと呼ぶ。
　さらに、この疑似ＩＰマルチキャストでは、パケットの送信先を、ＯＳのカーネルが提供するネットワークトラフィック制御機能におけるパケットフィルタの設定だけで変更することができる。このため、柔軟にマルチキャスト処理を変更することも可能になる。従来のオンメモリデータベースの分散処理では、仮想空間の位置関係、というアプリケーション固有の情報はアプリケーションしか持ちえないため、ＯＳレイヤでの最適化処理に用いることはできなかった。本実施例では、データ同期／データ・レプリケーションという、シンプルな情報伝搬に着目することにより、データリンク層での高効率な実装を可能にしている。
　本実施例が提供するＡＰＩについて説明する。本システムを構成するＡＰＩは、５つのコアＡＰＩと、４つの付属ＡＰＩである。
（１） chain([MAC_ADDRESS1, MAC_ADDRESS2, MAC_ADDRESS3, ... MAC_ADDRESSn])
　ｃｈａｉｎ ＡＰＩは、このＡＰＩが起動されたサーバ１０から、ＭＡＣ＿ＡＤＤＲＥＳＳ１～ｎを有するサーバ１０へのパケット転送設定を行う。これにより、マルチキャストパケットをこのサーバ１０へ送るだけで、ＭＡＣ＿ＡＤＤＲＥＳＳ1～ｎを有するサーバ１０へＬ２パケット処理だけで転送が行われる。本システムは、このｃｈａｉｎにより連結されたサーバ１０間で、後述のｏｐｅｎで生成されたスマートポインタ経由のメモリ書き込みが、直ちにＬ２パケット転送を通じて共有されるというものである。
（２） open("key-name(e.g. /root/world1/cell-id)", [READ_ONLY, WRITE_ONLY, RW]) → sptr
　ｏｐｅｎ ＡＰＩは、共有メモリへの参照を作成するＡＰＩである。ここで、関数の戻り値であるｓｐｔｒとは、Smart Pointer to Distributed Shared Memoryの略で、共有メモリへの参照を管理するオブジェクトである。ｋｅｙ－ｎａｍｅには、空白を含まない、任意のＡＳＣＩＩ文字列を指定することができる。上述の例のように、"/"等でディレクトリに分かれている必要はない。パケットサイズを不要に圧迫することは好ましくなく、例えば、最大で２５５文字、というような制限を加えることが好ましい。"ｋｅｙ－ｎａｍｅ"のメモリブロックが存在しない場合は、例外が発生する。
　本実施例が提供するメモリブロックの概要図を図１３に示す。すべてのメモリブロック（オブジェクト）にはその時点で格納されている情報が生成／更新された時のＴｉｃｋ－ＩＤが付与される。共有メモリに格納されるオブジェクトのサイズＬ１は固定長であることが好ましい。共有メモリ全体のサイズＬ２もシステム起動時に十分確保され、固定長であることが好ましい。連結リスト等を用いることにより、可変長とすることができるが、ランダムアクセス性能が落ちるため好ましくない。共有メモリは、例えば、固定長オブジェクトの配列としてモデル化され、名前で識別される。
（３）(write) sptr[i] = a 
　これは、共有メモリへの書き込みを行うＡＰＩである。書き込まれたメモリセグメントは直ちにサーバ１０側でレプリケーションされる。このとき、ａとして示されているオブジェクトには、そのオブジェクトの状態が生成されたときのゲーム内時間であるＴｉｃｋ－ＩＤが記録されており、本システムは、メモリブロックへの書き込み時に、その書き込みのＴｉｃｋ－ＩＤを使って、書き込みの直列化をする。
　これにより、メモリへの並列書き込みをロックフリーで実行することができる。同一のＴｉｃｋ－ＩＤで、かつ、同一のメモリブロックアドレス（上記の例ではｉで示されている）への操作が行われたときは、本システムは例外をゲームロジックへ通知する。ゲームロジック側は、例えば、プレイヤごとに優先順位を設ける方式や、あるいは、エフェクトで競合状態をごまかすなどの方法で、データ競合を解消する。変数ａのサイズは静的に決まっていることが好ましいが、完全に動的に処理する場合は、書き込みロジックを工夫すればよい。
（４）a = sptr[i]
　これは、共有メモリからの読み込みを行うＡＰＩである。なお、書き込み時と同様に、変数ａが有するＴｉｃｋ－ＩＤと、当該ブロック［ｉ］に格納されているＴｉｃｋ－ＩＤを比較し、もし、ブロック［ｉ］のＴｉｃｋ－ＩＤが変数ａのＴｉｃｋ－ＩＤと同じか新しいときは、データ競合が発生しているため、本システムは例外をゲームロジックへ通知する。この例外処理は、変数ａの＝演算子により実装される。
（５）replicate("key-name", index, blocks)
　マルチキャストされたＬ２パケットをカーネルが受信すると、このｒｅｐｌｉｃａｔｅ ＡＰＩが呼ばれる。このＡＰＩは、特定のｋｅｙ－ｎａｍｅにバインドされたメモリブロックの、ｉｎｄｅｘ以降のアドレスをｂｌｏｃｋｓで上書きする。ｂｌｏｃｋｓは、１つ以上のオブジェクトを示すバイト列である。本システムでは、同一アーキテクチャの計算機を用いることを想定し、かつ、共有メモリ内にはポインタ等を含まないため、オブジェクトは特別なシリアライズ／デシリアライズ処理を経ずにそのままメモリ内に格納される。"ｋｅｙ－ｎａｍｅ"のメモリブロックが存在しない場合は、不正な状態が発生しているので、深刻なエラーとして処理する。
　本実施例は、カーネルのパケット転送フィルタを用いた疑似ＩＰマルチキャストを設定するための（１）ｃｈａｉｎ ＡＰＩと、共有メモリブロックへの参照を作成する（２）ｏｐｅｎ ＡＰＩ、（３）書き込みＡＰＩ、（４）読み込みＡＰＩ、そして、レプリケーションされるデータがマルチキャストパケットとして到着したときに呼び出される（５）ｒｅｐｌｉｃａｔｅ ＡＰＩを主要なＡＰＩとしている。本実施例は、実質的にはこの５つのＡＰＩにより主要な機能が実装される。以下に示す（６）～（９）のＡＰＩは、実装上必要なＡＰＩではあるが、本実施例の本質的な機能を提供するものではない。
（６）close(sptr)
　分散共有メモリへの参照を閉じる。スマートポインタなので、スコープを外れれば参照は消えるので、基本的にはｃｌｏｓｅは呼ばなくて良い。
（７）create("key-name", size)
　ｃｒｅａｔｅ ＡＰＩは、ｓｉｚｅ分だけ、分散共有メモリのブロックを、"ｋｅｙ－ｎａｍｅ"の名前で確保する。メモリセグメントの確保命令は、直ちにサーバ１０側でｒｅｐｌｉｃａｔｉｏｎされ、ｃｒｅａｔｅ ＡＰＩコールとして他サーバ１０で処理される。既に"ｋｅｙ－ｎａｍｅ"のメモリブロックが存在する場合は、例外が発生する。
（８）delete("key-name")
　ｄｅｌｅｔｅ ＡＰＩは、"ｋｅｙ－ｎａｍｅ"の名前を有する分散共有メモリのブロックを削除する。メモリセグメントの削除命令は、直ちにサーバ１０側でｒｅｐｌｉｃａｔｉｏｎされ、ｄｅｌｅｔｅ ＡＰＩコールとして他サーバ１０で処理される。"ｋｅｙ－ｎａｍｅ"のメモリブロックが存在しない場合は、例外が発生する。
（９）resize("key-name", size)
　ｒｅｓｉｚｅ ＡＰＩは、"ｋｅｙ－ｎａｍｅ"の名前で確保された分散共有メモリのブロックを、ｓｉｚｅ分だけ、拡張する。メモリセグメントのリサイズ命令は、直ちにサーバ１０側でｒｅｐｌｉｃａｔｉｏｎされ、ｒｅｓｉｚｅ ＡＰＩコールとして他サーバ１０で処理される。"ｋｅｙ－ｎａｍｅ"のメモリブロックが存在しない場合は、例外が発生する。既に確保されているメモリブロックのサイズよりも、指定されたｓｉｚｅが小さい場合は、メモリブロックが縮小するが、メモリサイズを動的に縮小することは好ましくない。
　本実施例は、上述のＡＰＩを実装することにより、Ｔｉｃｋ管理機能を有する任意のサーバ１０に実装することができる。さらに、本実施例の上位層に、より簡便に使用することができるようなオブジェクト指向のラッパーライブラリを実装すれば、サーバ１０の開発者は、あたかも巨大で高速なキー・バリュー・ストアがネットワーク上に存在するかのように、ゲームロジックを実装することができるようになる。
　なお、ＡＷＳ上では、ｔｃ（Traffic Control）コマンドを用いて、Ｌｉｎｕｘ（登録商標）カーネルのパケットフィルタリング機能を利用し、マルチキャストパケットを宛先分コピーして、ＭＡＣアドレスをユニキャストに置き換えて送信する方法を、本実施例の実装に用いることができる。この方法では、データリンク層でパケットをキャプチャし、キャプチャを宛先の分だけコピーして、それぞれの宛先にユニキャストを行う。宛先のＭＡＣアドレスは、ＡＷＳ ＳＤＫにより取得でき、インスタンス名やタグを活用することで、任意のグループのＭＡＣアドレスのみを取得することも可能である。
＜作用効果＞
　以上、本実施形態のゲームシステムでは、互いが担当するエリア間でオブジェクトの行き来が高頻度で行われるサーバ間は、疑似ＩＰマルチキャストネットワーク構造で直接接続し（カーネル上のパケット転送設定において、互いのＭＡＣアドレスを宛先として登録）、プッシュ型の同期で即時かつ高速な同期を行う。プッシュ型の同期の設定を、仮想空間上の地理的関係に基づいて行うことにより、プッシュ型の同期によるデータの共有率（いわゆるキャッシュのヒット率に近い概念）を高く保ちながら、プッシュ同期にかかるＣＰＵ負荷、ネットワーク負荷を低く抑えることができる。
　また、本実施形態では、サーバ間で送受信する更新情報の中に時間情報を含める。そして、この時間情報を用いて、メモリの更新／読み出し操作を直列化する。これによりデータ間の整合性や一貫性を管理することが可能となる。
　また、本実施形態のゲームシステムでは、サーバ１０間で送受信する更新情報の中に時間情報を含める。そして、この時間情報を用いて、メモリの更新／読み出し操作を直列化する。これによりデータ間の整合性や一貫性を管理することが可能となる。
　また、実施例で説明したように、本実施形態のカーネル間のデータ同期経路は、Ｌｉｎｕｘ（登録商標）のｔｃコマンドを用いたシェルスクリプトを記述するだけで実装できる。したがって、本実施形態を導入する実行時のコストは極めて小さい。
　また、本実施形態のゲームシステムは、プレイヤの行動を制限することなく、自由度の高いゲーム内容を有するゲームシステムにおける負荷分散を実現するものであり、オープンワールド型ＭＭＯゲームのみならず、ＦＰＳ（First Person Shooter）などのプレイヤに高い自由度を提供する様々なゲームにも適用可能である。すなわち、本実施形態のゲームシステムは、利便性が高い。
　また、本実施形態のゲームシステムは、独自の仮想マシンやルータを導入することなく、既存のクラウドに実装することが可能である。このため、コスト負担を軽減できる。また、導入のハードルを低くすることができる。
　また、本実施形態のゲームシステムは、ユーザ・エクスペリエンスを損なわずに負荷分散可能である。本実施形態のゲームシステムは、ゲーム性に影響を与えず、完全にクラウド内に閉じて実装されるネットワーク通信の高速化技術であり、プレイヤに一切の強制的な制約を加えずに、負荷分散を行うことが出来る。オープンワールド型ＭＭＯゲームのように、ゲーム世界への没入感を維持することが、ユーザ・エクスペリエンスにとって本質的に重要なジャンルのゲームの場合、この利点は、極めて有効である。既存の方式では、他の世界への移動を明示的に推奨したり、混雑のためにログイン不可能にしたり、強制的にログアウトさせるなどの、ゲーム内のルールとは無関係な仕組みとして、負荷分散が実現されている。
　また、本実施形態のゲームシステムは、ゲーム内におけるプレイヤ間インタラクションを、従来よりも劇的に増加させることが可能である。本実施形態のゲームシステムを適用することにより、どのサーバ１０がどのストレージサーバにアクセスしても、同一のワールド情報を獲得することができるため、１つのエリア内で処理可能なユーザインタラクションの量を、従来の負荷分散技術との比較において増大させることが可能となる。具体的には、ＭＭＯゲームにおける戦闘をより複雑化させたり、アクションを増加させたりしても、スケーラブルにゲームサービスを提供可能となる。
　また、本実施形態のゲームシステムは、非オープンワールド型ＭＭＯゲームの負荷分散技術としても適用可能である。本実施形態のゲームシステムは、複数に世界が分割されたＭＭＯゲームにおいても、１つの世界の中での負荷分散を実現する技術として適用可能である。したがって、既存のＭＭＯゲームの負荷分散技術としても有効である。また、ＦＰＳやＳｅｃｏｎｄ Ｌｉｆｅ型のコミュニケーション・サービスなど、プレイヤ間のインタラクションを伴い、かつ、利用者に高い自由度を提供する幅広いゲームに適用可能である。
　以下、参考形態の例を付記する。
１．　ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの１つの前記サーバであって、
　　前記オブジェクト情報を記憶するオブジェクト情報記憶部と、
　　前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第１の更新部と、
　　前記複数のサーバの中の一部である対象サーバのＭＡＣ（media access control）アドレスを記憶するＭＡＣアドレス記憶部と、
　　前記ＭＡＣアドレス記憶部に記憶された前記ＭＡＣアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第１の更新部による前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第１の送信部と、
　　他の前記サーバから受信した前記更新情報に基づき、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第２の更新部と、
を有するサーバ。
２．　前記時間情報は、複数の前記サーバ各々により同一の処理で生成されている１に記載のサーバ。
３．　他の前記サーバからのリクエストに応じて、ＩＰ（internet protocol）通信で、前記オブジェクト情報記憶部に記憶されている前記オブジェクト情報を他の前記サーバに送信する第２の送信部をさらに有する１又は２に記載のサーバ。
４．　前記ＭＡＣアドレス記憶部は、自サーバが担当する前記エリアとの地理的関係が所定条件を満たす前記エリアを担当する前記サーバのＭＡＣアドレスを記憶する１から３のいずれかに記載のサーバ。
５．　前記ＭＡＣアドレス記憶部は、前記サーバにインストールされたＯＳ（operating system）のカーネルが提供するネットワークトラフィック制御機能で設定されたパケット送信先のＭＡＣアドレスを記憶し、
　前記第１の送信部による前記対象サーバへの前記更新情報の送信は、前記ＯＳの前記ネットワークトラフィック制御機能で実現される１から４のいずれかに記載のサーバ。
６．　１から５のいずれかに記載の前記サーバを複数有するゲームシステム。
７．　ゲーム空間内の複数のエリア各々を担当し、前記エリア間を移動可能な複数のオブジェクト各々の状態を示すオブジェクト情報を管理する複数のサーバを有するゲームシステムの１つの前記サーバが、
　　前記オブジェクト情報と、前記複数のサーバの中の一部である対象サーバのＭＡＣアドレスを記憶し、
　　記憶している前記オブジェクト情報のうち、担当する前記エリア内に存在する前記オブジェクトの前記オブジェクト情報の更新を行う第１の更新工程と、
　　前記ＭＡＣアドレスを宛先としたデータリンク層のデータに基づくパケット転送により、前記第１の更新工程での前記オブジェクト情報の更新内容及び更新時のゲーム内時間を示す時間情報を示す更新情報を前記対象サーバに送信する第１の送信工程と、
　　他の前記サーバから受信した前記更新情報に基づき、記憶している前記オブジェクト情報のうち、担当する前記エリアの外に存在する前記オブジェクトの前記オブジェクト情報の更新を行い、前記時間情報に基づき時系列順の前記オブジェクト情報の更新を実現する第２の更新工程と、
を実行する処理方法。
　この出願は、２０２０年５月２９日に出願された日本出願特願２０２０－０９３９９２号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１Ａ　　プロセッサ
　２Ａ　　メモリ
　３Ａ　　入出力Ｉ／Ｆ
　４Ａ　　周辺回路
　５Ａ　　バス
　１０　　サーバ
　１１　　オブジェクト情報記憶部
　１２　　第１の更新部
　１３　　第１の送信部
　１４　　ＭＡＣアドレス記憶部
　１５　　第２の更新部
　１６　　第２の送信部
　２０　　プレイヤ端末
　３０　　インターネット

Claims (7)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180059375.3A CN116235470A (zh) 2020-05-29 2021-05-24 服务器、游戏系统和处理方法
US18/058,033 US20230086992A1 (en) 2020-05-29 2022-11-22 Server, game system, and processing method

Applications Claiming Priority (2)

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

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/058,033 Continuation US20230086992A1 (en) 2020-05-29 2022-11-22 Server, game system, and processing method

Publications (1)

Publication Number Publication Date
WO2021241476A1 true WO2021241476A1 (ja) 2021-12-02

Family

ID=74673626

Family Applications (1)

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

Country Status (4)

Country Link
US (1) US20230086992A1 (ja)
JP (1) JP6838187B1 (ja)
CN (1) CN116235470A (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 ゲームのためのロードバランシング
JP2017037446A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 ゲームサーバ装置および分散処理方法
JP2017037445A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 サーバ管理装置およびサーバ管理方法
CN107609895A (zh) * 2017-08-10 2018-01-19 腾讯科技（深圳）有限公司 一种合并业务区域的处理方法及其设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030177187A1 (en) * 2000-11-27 2003-09-18 Butterfly.Net. Inc. Computing grid for massively multi-player online games and other multi-user immersive persistent-state and session-based applications
KR20040052131A (ko) * 2002-12-13 2004-06-19 한국전자통신연구원 거리기반 분산형 온라인 게임 서버 시스템
KR20050079606A (ko) * 2004-02-10 2005-08-10 엔에이치엔(주) 온라인 게임 서버의 데이터 분산 처리 방법 및 데이터분산 처리 시스템
CN101266633B (zh) * 2006-11-29 2011-06-08 优万科技（北京）有限公司 无缝超大规模虚拟游戏世界平台
CN111124301B (zh) * 2019-12-18 2024-02-23 深圳供电局有限公司 一种对象存储设备的数据一致性存储方法及系统
CN114470746A (zh) * 2022-02-10 2022-05-13 北京字跳网络技术有限公司 服务器系统、数据传输方法、装置、设备及存储介质

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 ゲームのためのロードバランシング
JP2017037446A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 ゲームサーバ装置および分散処理方法
JP2017037445A (ja) * 2015-08-10 2017-02-16 日本電信電話株式会社 サーバ管理装置およびサーバ管理方法
CN107609895A (zh) * 2017-08-10 2018-01-19 腾讯科技（深圳）有限公司 一种合并业务区域的处理方法及其设备

Also Published As

Publication number Publication date
US20230086992A1 (en) 2023-03-23
JP2021186224A (ja) 2021-12-13
JP6838187B1 (ja) 2021-03-03
CN116235470A (zh) 2023-06-06

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
US20040153473A1 (en) Method and system for synchronizing data in peer to peer networking environments
US11513863B2 (en) Game server architecture
US11038959B2 (en) State management and object storage in a distributed cloud computing network
Douglas et al. Enabling massively multi-player online gaming applications on a p2p architecture
Newell et al. Optimizing distributed actor systems for dynamic interactive services
Belaramani et al. PADS: A Policy Architecture for Distributed Storage Systems.
CN108200211A (zh) 集群中镜像文件下载的方法、节点和查询服务器
WO2021241476A1 (ja) サーバ、ゲームシステム及び処理方法
CN112988377B (zh) 用于云服务的资源分配方法、系统和介质
Deen et al. Running Quake II on a grid
Najaran et al. SPEX: scalable spatial publish/subscribe for distributed virtual worlds without borders
US9578120B1 (en) Messaging with key-value persistence
Meiklejohn et al. {PARTISAN}: Scaling the Distributed Actor Runtime
Kim Towards elastic and resilient in-network computing
Bharambe et al. A distributed architecture for interactive multiplayer games
CN112156475B (zh) 一种业务数据处理方法、装置、电子设备及存储介质
Diao et al. Cloud data management for online games: potentials and open issues
Xu et al. A Comparison of Architectures in Massive Multiplayer Online Games”
Gorlatch et al. Designing multiplayer online games using the real-time framework
Cassell Building Efficient Software to Support Content Delivery Services
Seshan A Distributed Architecture for Online Multiplayer Games
Saito et al. Realtime Physics Simulation of Large Virtual Space with Docker Containers
Pu Towards Practical Serverless Analytics

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21813325

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21813325

Country of ref document: EP

Kind code of ref document: A1