Game system, edge-side server, cloud-side server, game terminal, and game control method

Abstract

The edge-side server (20) transmits a first response to the request to the player terminal (30) upon receiving the request transmitted from the player terminal (30), and transmits an aggregated result aggregated with a result of processing based on the request to the cloud-side server (10) every certain period of time. Then, the edge-side server (20) receives a result of processing based on the aggregated result executed at the cloud-side server (10), and transmits the result of the processing as a second response to the player terminal (30). The player terminal (30) receives the first response and the second response from the edge-side server (20) in sequence via asynchronous I / O for a single request.

Description

Technical Field

[0001] This invention relates to game systems, edge servers, cloud servers, game terminals, and game control methods. Background Technology

[0002] For 5G networks, which are the next generation of mobile networks, the network architecture will undergo a massive transformation, as servers can be installed outside the Internet in addition to simply increasing bandwidth for the last mile. Multi-access edge computing (MEC) is a known related technology. Compared to traditional cloud computing, which is based on horizontal distribution (i.e., providing a large number of servers in a distributed manner on the cloud side), the biggest feature of MEC is vertical distribution (i.e., providing servers with computing power in a distributed manner along the network path), which enables edge-side servers and clients to communicate with each other with latency as low as a few milliseconds.

[0003] Non-Patent Document 1 and Non-Patent Document 2 disclose related technologies. Non-Patent Document 1 describes 5G networks and MEC, and proposes games as an example application of MEC. Non-Patent Document 2 discloses the following technology: edge-side servers are integrated into the data center of a communication service provider located at the edge of the 5G network, which enables low latency through games, real-time video streaming, edge machine learning inference, augmented reality, virtual reality, etc.

[0004] In addition, Non-Patent Document 3 discloses content related to Comet, which keeps HTTP sessions connected.

[0005] Existing technical documents

[0006] Non-patent literature

[0007] Non-Patent Document 1: Japan Virtualization Technology Co., Ltd., "hbstudy#88 System Design for the 5G+MEC Era", [Online], January 17, 2020, [Searched July 20, 2020], Internet<URL:https: / / www.slideshare.net / VirtualTech-JP / hbstudy88-5G MEC>

[0008] Non-Patent Document 2: Amazon Web Services, Inc., “AWS Wavelength”, [online], [retrieved July 20, 2020], Internet<URL:https: / / aws.amazon.com / jp / wavelength / >

[0009] Non-patent document 3: "Comet: Low Latency Data for the Browser", March 3, 2006, [retrieved July 20, 2020], Internet<URL:https: / / infrequently.org / 2006 / 03 / comet-low-latency-data-for-the-browser / > Summary of the Invention

[0010] The problem the invention aims to solve

[0011] Both Non-Patent Literature 1 and Non-Patent Literature 2 propose games as a use case for MEC, but do not disclose their detailed techniques. This invention addresses the problem of simultaneously achieving higher levels of scalability (massive connectivity) and responsiveness (low latency) for game services compared to previous methods.

[0012] Solution for solving the problem

[0013] This invention provides a game system, including a cloud-side server, an edge-side server, and a player terminal.

[0014] The edge-side server includes:

[0015] An edge receiving unit is used to receive requests sent from the player's terminal;

[0016] A first edge processing unit is configured to perform processing based on the request and send the result of the processing based on the request as a first response to the request to the player terminal; and

[0017] The second edge processing unit is configured to, at regular intervals, send an aggregated result containing the processing results based on the request to the cloud-side server, receive the processing results based on the aggregated result executed at the cloud-side server, and send the processing results based on the aggregated result as a second response to the request to the player terminal.

[0018] The cloud-side server includes:

[0019] A cloud receiving unit is configured to receive aggregation results sent from the edge-side server; and a cloud processing unit is configured to perform processing based on the aggregation results and send the processing results based on the aggregation results to the edge-side server.

[0020] The player terminal includes:

[0021] The terminal sending / receiving unit is configured to send the request and, in response to one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O.

[0022] Furthermore, this invention provides a game control method executed by a game system comprising a cloud-side server, an edge-side server, and a player terminal.

[0023] The edge-side server:

[0024] Receive requests sent from the player's terminal;

[0025] Perform processing based on the request, and send the result of the processing based on the request as a first response to the request to the player terminal; and

[0026] At regular intervals, an aggregated result, which includes the processing results based on the request, is sent to the cloud-side server. The server receives the processing results based on the aggregated result, which are then executed on the cloud-side server. Finally, the processing results based on the aggregated result are sent to the player's terminal as a second response to the request.

[0027] Among them, the cloud-side server:

[0028] Receive the aggregation result sent from the edge-side server; and

[0029] Perform processing based on the aggregation result, and send the result of the processing based on the aggregation result to the edge-side server.

[0030] The player terminal:

[0031] Send the request, and for one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O.

[0032] Furthermore, the present invention provides an edge-side server in the aforementioned game system.

[0033] Furthermore, the present invention provides a cloud-side server in the aforementioned game system.

[0034] Furthermore, the present invention provides a player terminal in the aforementioned game system.

[0035] The effects of the invention

[0036] This invention enables the simultaneous achievement of higher levels of scalability (massive connectivity) and responsiveness (low latency) in game services compared to previous versions. Attached Figure Description

[0037] Figure 1 This is a diagram used to illustrate an overview of the game system according to this embodiment.

[0038] Figure 2 This is a diagram used to illustrate an overview of the game system according to this embodiment.

[0039] Figure 3 This is a diagram illustrating an example of the functional blocks of a player terminal according to this embodiment.

[0040] Figure 4 This is a diagram illustrating an example of functional blocks of an edge-side server according to this embodiment.

[0041] Figure 5 This is a diagram illustrating an example of functional blocks of a cloud-side server according to this embodiment.

[0042] Figure 6 This is a sequence diagram illustrating an example flow of processing using the game system according to this embodiment.

[0043] Figure 7 This is a diagram illustrating an example of a game system implemented according to this embodiment.

[0044] Figure 8 This is a diagram illustrating an example of a game system implemented according to this embodiment.

[0045] Figure 9 This is a second example diagram illustrating the implementation of the game system according to this embodiment.

[0046] Figure 10 This is a diagram illustrating an example hardware structure of the device according to this embodiment.

[0047] Figure 11 This is a diagram used to illustrate an example of a game system according to this embodiment.

[0048] Figure 12 This is a sequence diagram illustrating an example flow of processing using the game system according to this embodiment. Detailed Implementation

[0049] <First Embodiment>

[0050] "summary"

[0051] Given the increasing availability of 5G+MEC as a new edge computing infrastructure, this embodiment proposes a new Web API implementation method suitable for vertical distribution (where computing-capable servers are distributed across network paths). For traditional cloud computing based on horizontal distribution (where a large number of servers are distributed on the cloud side), this approach is extremely simple because the externally exposed Web API returns a response as quickly as possible after being invoked. The technical feature of this embodiment is progressive response: that is, when a large number of clients invoke a single Web API, the edge server immediately (within milliseconds) returns a provisional response to these clients. Simultaneously, the edge server aggregates the received multiple requests, invokes the same Web API on the cloud, and subsequently (within hundreds of milliseconds) additionally returns the final computation result obtained from the cloud server. This aggregated request processing and progressive response simultaneously achieve both service scalability and response performance.

[0052] For each client calling the Web API according to this embodiment, by loading a single Web API via asynchronous processing, it can first receive an immediate response reflecting local information at the edge server, and then additionally receive a global and final response from the cloud server. Furthermore, since the client receives both responses via asynchronous I / O, it can receive the response from the cloud server while simultaneously rendering the effect corresponding to the response from the edge server in the form of animation, etc. As described above, while displaying the first screen corresponding to the fast response from the edge server, the response from the cloud server is received, and a second screen corresponding to the response from the cloud server is seamlessly displayed alongside the first screen as described above. Therefore, the following advantage is provided: from the player's perspective, it appears as if the response from the cloud server is received and displayed on the screen at the same speed as the response from the edge server (i.e., no communication latency is perceived).

[0053] Overview

[0054] Next, an overview of the game system according to this embodiment will be described. For example... Figure 1 As shown, the game system includes a cloud server 10, multiple edge servers 20, and multiple player terminals 30.

[0055] Player terminal 30 is the mobile terminal operated by the player. Examples include, but are not limited to, smartphones, tablets, personal computers, game consoles, smartwatches, and mobile phones. Edge server 20 is a so-called MEC server. Cloud server 10 is a server installed on the cloud side.

[0056] like Figure 2As shown, the player terminal 30 and the cloud-side server 10 communicate with each other via a mobile network 70 and the Internet 60. The mobile network 70 is a 5G network. The mobile network 70 includes a base station 71, a core network 72, an Internet gateway 73, etc. (The last sentence appears to be incomplete and possibly refers to a different context.) Figure 2 Obviously, the Internet 60 in this embodiment does not include the concept of the mobile network 70 to which the player terminal 30 is connected.

[0057] Although not in Figure 2 As shown, the edge server 20 is located within the mobile network 70. Furthermore, the player terminal 30 and the edge server 20 communicate with each other without using the Internet 60. While there are no specific restrictions regarding the location where the edge server 20 is installed, examples include locations within the equipment of a communication service provider's base station 71 or core network 72.

[0058] like Figure 1 As shown, each of the multiple player terminals 30 communicates with one of the multiple edge-side servers 20. This means that the multiple player terminals 30 do not communicate with the multiple edge-side servers 20 simultaneously. For example, the edge-side server 20 communicating with a player terminal 30 may change depending on the location of that player terminal 30. For example, each player terminal 30 communicates with the edge-side server 20 installed in the base station 71 to which the local terminal is connected.

[0059] Functional structure

[0060] Next, refer to Figures 3 to 6 To explain the functional structure of the game system.

[0061] Figure 3 An example functional block diagram of a player terminal 30 is shown. As shown in the figure, the player terminal 30 includes an input unit 31, an output unit 32, a processing unit 33, a storage unit 34, and a terminal transmitting / receiving unit 35.

[0062] These functional units implement the following functions: a function for accepting input from the player; a function for sending a request based on the input to the server; a function for receiving a response to the request from the server; and a function for displaying a screen corresponding to the received response.

[0063] Figure 4 An example functional block diagram of an edge-side server 20 is shown. As shown in the figure, the edge-side server 20 includes an edge receiving unit 21, a first edge processing unit 22, a second edge processing unit 23, and a storage unit 24.

[0064] These functional units implement the following functions: receiving requests from player terminals 30 that communicate with local devices (edge ​​servers 20); returning the processing result based on the requests received from player terminals 30 as a provisional processing result to player terminals 30; sending an aggregated result that aggregates the processing results based on the requests received from player terminals 30 to cloud servers 10; and receiving a final processing result based on the aggregated result from cloud servers 10 and returning the final result to player terminals 30.

[0065] Figure 5 An example functional block diagram of a cloud-side server 10 is shown. As shown in the figure, the cloud-side server 10 includes a cloud receiving unit 11, a cloud processing unit 12, and a storage unit 13.

[0066] These functional units implement the following functions: functions for receiving aggregation results such as the aggregation results described above from multiple edge-side servers 20 respectively; functions for calculating a final processing result based on the multiple aggregation results received from multiple edge-side servers 20 respectively; and functions for sending the calculated final processing result to the edge-side server 20.

[0067] Figure 6 This is a sequence diagram illustrating an example flow of processing utilizing a game system. More specifically, Figure 6 The diagram illustrates the processing flow performed over a relatively short period, beginning when multiple players perform a predetermined action (e.g., an attack) at any time during the game's progression, and ending when the screen corresponding to these actions is displayed on the player's terminal 30. The following details this process. Figures 3 to 5 The functional structure and processing flow of each functional unit are shown.

[0068] This assumes that a large number of players are simultaneously participating in a game provided by the game system according to this embodiment, and that the actions performed by each player affect the progress of other players' games. Examples include, but are not limited to, raid battles in massively multiplayer online role-playing games (MMORPGs).

[0069] Figure 6 The diagram shows multiple first player terminals 30, a first edge server 20, multiple m-th player terminals 30, an m-th edge server 20, and a cloud server 10.

[0070] Multiple first player terminals 30 are player terminals operated by some of the multiple players participating in the game. Multiple first player terminals 30 communicate jointly with the same edge-side server 20 (first edge-side server 20). For example, multiple first player terminals 30 are connected to the same base station. Furthermore, the first edge-side server 20 is, for example, installed in a base station connected to the multiple first player terminals 30.

[0071] Similarly, multiple m-th player terminals 30 are player terminals 30 operated by some of the multiple players participating in the game. These multiple m-th player terminals 30 communicate jointly with the same edge-side server 20 (m-th edge-side server 20). For example, the multiple m-th player terminals 30 are connected to the same base station. Furthermore, the m-th edge-side server 20 is, for example, installed in a base station connected to the multiple m-th player terminals 30.

[0072] Note that although two edge-side servers 20 and two groups of multiple player terminals 30 are shown in the figure, the number of edge-side servers and the groups of multiple player terminals are not limited to those shown in the figure.

[0073] First, each of the multiple first players 30 sends a request generated based on input from the players to the server (S101). The requests sent from the multiple first player terminals 30 are received by the first edge-side server 20.

[0074] Regarding the processing in S101, the input unit 31 receives operations from the player via any input device such as a touch panel, physical button, microphone, keyboard, or mouse. For example, the input unit 31 accepts operations for attacking an enemy character or for defending against an enemy character. The processing unit 33 generates a request representing the input content (attack request or defense request, etc.). The terminal sending / receiving unit 35 calls the specified Web API and sends the generated request.

[0075] When the first edge server 20 receives requests from multiple first player terminals 30 (S101), it performs processing based on the received requests (S102) and sends the results of the processing based on these requests as first responses to these requests to the multiple first player terminals 30. The reception of requests in S101 is implemented by the edge receiving unit 21, and the processing in S102 and S103 is implemented by the first edge processing unit 22.

[0076] The first edge processing unit 22 calculates locally consistent processing results by using data related to some of the multiple players participating in the game (players operating multiple first player terminals 30).

[0077] For example, the first edge processing unit 22 calculates the results (whether the enemy character was damaged, the amount of damage, etc.) based on the attack requests sent from multiple first player terminals 30, and then calculates an aggregated result (the total amount of damage inflicted on the enemy character as a result of multiple attack requests, etc.). Then, the first edge processing unit 22 sends the aggregated result (the total amount of damage inflicted on the enemy character as a result of multiple attack requests regardless of whether the enemy character was damaged, etc.) as a first response to the multiple first player terminals 30.

[0078] In addition, the second edge processing unit 23 sends the following aggregation result to the cloud server 10 at regular intervals. The aggregation result is the result of aggregating the processing results based on the requests sent from multiple first player terminals 30 respectively (S105).

[0079] Note that the aggregation result calculated by each edge server 20 is the result of aggregating the results of requests from some of the multiple players (players operating player terminals 30 that communicate with the edge server 20) who are spatially distributed. In the following text, the aggregation result calculated by each edge server 20 will be referred to as the "provisional aggregation result of requests received in parallel".

[0080] When multiple first player terminals 30 receive a first response (S103), they perform a first presentation corresponding to the first response (S104). Specifically, when the first response is received by the terminal sending / receiving unit 35, the processing unit 33 generates data for implementing the first presentation based on the first response and the data stored in the storage unit 34, and then causes the output unit 32 to execute the first presentation.

[0081] In the case where the request sent in S101 is an attack request, for example, such as Figure 7 As shown, the first conceivable example is the effect presentation Q, indicating that damage has been dealt to the enemy character P. Alternatively, in addition to the effect presentation Q, such as... Figure 8 As shown, it may also include the amount of damage R given to the enemy character P, represented by "the provisional aggregation result of requests received in parallel".

[0082] The duration of the first presentation (S104) is designed such that the first presentation continues until the second presentation (S116) corresponding to the subsequent second response begins.

[0083] The same process as described above, which utilizes multiple first player terminals 30 and first edge-side servers 20, is executed by other player terminals 30 and other edge-side servers 20 at the same time (S106 to S110).

[0084] Note that the content of the first response received by multiple first player terminals 30 from the first edge-side server 20 may differ from the content of the first response received by multiple m-th player terminals 30 from the m-th edge-side server 20. Therefore, the content of the first presentation displayed on the multiple first player terminals 30 may differ from the content of the first presentation displayed on the multiple m-th player terminals 30. For example, in Figure 8 The damage amount R shown in the example can be different values.

[0085] On the other hand, the content of the first response received by the multiple first player terminals 30 from the first edge-side server 20 is identical. Therefore, the content of the first presentation displayed on the multiple first player terminals 30 is the same. For example, in Figure 8 The damage amount R shown in the example is the same value. Similarly, the content of the first response received by multiple m-th player terminals 30 from the m-th edge-side server 20 is identical. Therefore, the content of the first response displayed on multiple m-th player terminals 30 is identical. For example, in Figure 8 The damage amount R shown in the examples is the same value.

[0086] Then, the cloud server 10 performs processing based on the "provisional aggregation result of requests received in parallel" received from multiple edge servers 20 respectively (S111), and sends the processing result to the multiple edge servers 20 (S112 and S113). The processing for receiving the "provisional aggregation result of requests received in parallel" from multiple edge servers 20 is implemented by the cloud receiving unit 11, and the processing in S111 to S113 is implemented by the cloud processing unit 12.

[0087] For example, the cloud processing unit 12 calculates the sum of the damage values ​​inflicted on the enemy character, represented by the provisional aggregation results of the "parallel received requests" received from multiple edge-side servers 20. Then, the cloud processing unit 12 sends the sum of the damage values ​​to the multiple edge-side servers 20.

[0088] Note that the processing result calculated by the cloud processing unit 12 is the result of aggregating the "provisional aggregation result of requests received in parallel" from multiple edge servers 20, that is, the result of aggregating the results of all requests from multiple spatially distributed players. In the following text, the processing result calculated by the cloud processing unit 12 will be referred to as the "final aggregation result of requests received in parallel".

[0089] When the first edge server 20 receives the "final aggregation result of the parallel received requests" (S112) from the cloud server 10, it sends the "final aggregation result of the parallel received requests" as a second response to the requests received in S101 to multiple first player terminals 30 (S114). The processing in S112 and S114 is implemented by the second edge processing unit 23.

[0090] When multiple first player terminals 30 receive a second response (S114), they perform a second presentation corresponding to the second response (S116). Specifically, when the second response is received by the terminal sending / receiving unit 35, the processing unit 33 generates data for implementing the second presentation based on the second response and the data stored in the storage unit 34, and then causes the output unit 32 to execute the second presentation.

[0091] Note that, as described above, the duration of the first presentation (S104) is designed such that the first presentation continues until the subsequent second presentation (S116) corresponding to the second response begins. Therefore, the processing unit 33 begins the second presentation (S116) before the first presentation (S104) ends. That is, the first presentation (S104) and the second presentation (S116) are seamlessly connected.

[0092] In the case where the request sent in S101 is an attack request, for example, such as Figure 9 As shown, a conceivable example of the second presentation is the effect presentation Q representing damage already dealt to enemy character P, and the presentation of the amount of damage R given to enemy character P, represented by "the final aggregate result of requests received in parallel".

[0093] Note that the same process as described above, which utilizes multiple first player terminals 30 and first edge-side servers 20, is executed by other player terminals 30 and other edge-side servers 20 at the same time (S113, S115 and S117).

[0094] The content of the second response received by the multiple first player terminals 30 from the first edge-side server 20 is the same as the content of the second response received by the multiple m-th player terminals 30 from the m-th edge-side server 20. Therefore, the content of the second presentation displayed on the multiple first player terminals 30 is the same as the content of the second presentation displayed on the multiple m-th player terminals 30. For example, in Figure 9 The damage amount R shown in the examples is the same value.

[0095] On the other hand, after sending a request (S101 or S106), the player terminal 30 sequentially receives a first response and a second response from multiple edge-side servers 30 via asynchronous I / O for that single request (S103 and S114 or S108 and S115). Therefore, during the time period after receiving the first response and before receiving the second response, the player terminal 30 can perform a first presentation corresponding to the first response (S104 or S109).

[0096] Hardware structure

[0097] Next, the hardware structure of the various devices (cloud server 10, edge server 20, and player terminal 30) used to implement the game system will be described. The various functional units provided in the devices of this embodiment are implemented through any combination of hardware and software. This hardware and software mainly include the central processing unit of any computer, memory, a program loaded into the memory, a storage unit for storing the program (e.g., a hard disk, which may store programs pre-stored at the time of shipment of the device, as well as programs downloaded from storage media such as CDs or servers on the Internet), and a network connection interface. Furthermore, those skilled in the art will understand that various modifications exist for the methods and devices used in their implementation.

[0098] Figure 10 This is a block diagram illustrating an example hardware structure of each device in this embodiment. For example... Figure 2 As shown, each device includes a processor 1A, a memory 2A, an input / output interface 3A, peripheral circuitry 4A, and a bus 5A. Peripheral circuitry 4A includes various modules. Note that each device does not necessarily include peripheral circuitry 4A.

[0099] Note that the cloud-side server 10 and the edge-side server 20 may be composed of multiple physically and / or logically separate devices. In this case, each device may have the hardware structure described above. Alternatively, the cloud-side server 10 and the edge-side server 20 may be composed of a single physically and logically separate device.

[0100] Bus 5A is the data transmission path used by processor 1A, memory 2A, peripheral circuitry 4A, and input / output interface 3A to send and receive data to each other. Processor 1A is a computing processing device such as a CPU or graphics processing unit (GPU). Memory 2A is a memory such as random access memory (RAM) or read-only memory (ROM). Input / output interface 3A includes: an interface for obtaining information from input devices, external devices, external servers, external sensors, etc.; and an interface for outputting information to output devices, external devices, external servers, etc. Input devices include, for example, a keyboard, mouse, and microphone. Output devices include, for example, a monitor, speaker, printer, and email program. Processor 1A can issue instructions to various modules and perform calculations based on the results of calculations performed by these modules.

[0101] Example

[0102] Next, an example of the first embodiment will be described. Figure 11 This example provides an overview. It demonstrates how high responsiveness and high scalability can be achieved simultaneously by leveraging APIs used in the traditional cloud and utilizing 5G MEC infrastructure:

[0103] (1) A function for aggregating requests from player terminals 30 at edge server 20 and then sending the results to cloud server 10 while exposing the same API at edge server 20 as cloud server 10; and

[0104] (2) Functions for asynchronously sending instant responses from edge server 20 to player terminal 30 and sending responses from cloud server 10 to player terminal 30.

[0105] The game system in this example consists of the following six modules.

[0106] [M1] The game server on the edge is a game server deployed within the MEC infrastructure and corresponds to edge-side server 20. Although it implements the same functionality as a traditional game server (cloud-side server 10) running in the cloud, there are differences in the limitations of the database used. [M1] implements the following two functions.

[0107] The [M1-1] API implementation is as follows: it processes requests using the same logic as the [M2-1] API implementation set up in the game server on the [M2] cloud, calculates the results of actions in the game, and immediately returns the results to the client (player terminal 30). [M1-1] implements different functionalities for different games and implementations; however, [M1-1] can be considered a general REST API because this module interprets requests received from the outside as commands in the game and returns a response after performing some calculation.

[0108] The significant difference between this module and the cloud-side module is that [M1-1] calculates a consistent result using only information known to module [M1] (i.e., information related to players in a specific area) and returns a first response immediately (e.g., within 5ms). The local information referenced here, limited to [M1], is stored in the [M3] small database. Furthermore, after sending the first response, the connection (session) between the game server and the client at the [M1] edge is maintained without being disconnected.

[0109] The [M1-2] request aggregator is a module that aggregates requests at regular intervals (e.g., by summing the damage values ​​dealt to an enemy character) and calls the corresponding API of [M2]. Here, as a conceivable method for aggregating requests, it is conceivable to calculate the total damage dealt to a single enemy character by multiple players.

[0110] [M2] is a cloud-based game server of the type used to date, and corresponds to cloud-side server 10. Using [M2], functions invoked from clients are exposed externally as a Web API. In this invention, [M2] can be considered a module that executes the API at a fixed frequency (maximum frequency set in [M1]) and with a small number of simultaneous connections (maximum number of installed modules [M1]), calculates globally consistent results using a database [M4], and returns the results to [M1]. [M2] consists of at least one of the following sub-modules.

[0111] The [M2-1] API implementation is a module that implements the same cloud-side game server logic as before. This module shares almost all the functionality with [M1-1].

[0112] [M3] is a small database used to store the game status of some players among multiple players participating in the game. Each module [M1] is equipped with [M3] to store the game status of players on the client that communicates with that module [M1].

[0113] [M4] The BigDB is a database used to store the game status of all players participating in the game, and it is the type of game database used to date.

[0114] Figure 11 The approximate estimates of the time required to send / receive each piece of data are shown. Note that these are only approximate estimates, and the required time is not limited to these. The approximate estimate of the time required for communication between [M1] and the client is approximately 2 ms. The approximate estimate of the time required for communication between [M1] and [M2] is approximately 100 ms.

[0115] Note that when player terminal 30 connects to the Internet 60 via a network other than 5G (such as a mobile network like 3G or 4G, or a wireless LAN), player terminal 30 communicates directly with cloud server 10 (without using edge server 20) and simply calls an API with the same URL, making rollback easy. In this case, the API can simply be used as an API with the same response speed as the current one.

[0116] Next, a specific example of the communication method in this example will be described.

[0117] (1) When a client calls the attack's REST API, [M1-1] of [M1], located at the network edge (downstream), returns a provisional response for the result of a single attack request with a response time of approximately 3ms. However, note that, as with traditional Comet connections, the response connection is maintained and not disconnected. Here, since [M1] receives requests from clients connected to the same mobile station (or core network device), it can calculate the total damage (local damage) in a specific area, allowing it to return the total damage in that specific area as a response. [M1-2] is responsible for calculating this total value.

[0118] (2) While the client is drawing an animation (preferably lasting 200ms or longer) on the UI corresponding to the provisional response, [M1]'s [M1-2] sends the total damage amount in the specific area mentioned above to [M2]. [M2] can implement attack processing to calculate, for example, the sum of damage amounts given by all players (e.g., approximately 1 million) (global damage amount) by summing the total damage amounts (local damage amounts) corresponding to the number of base stations.

[0119] (3) After approximately 200ms, [M2] returns the sum of all damage dealt by all players (e.g., approximately 1 million) (global damage) as a response to [M1]. [M1] then returns the global damage to the client and ends the response.

[0120] (4) The client renders the global damage effect to seamlessly update the animation that is being rendered and corresponds to the provisional response (e.g., from...). Figure 7 Seamlessly transformed into Figure 9 Or from Figure 8 Seamlessly transformed into Figure 9 As mentioned above, for the client, by asynchronously reading the response from a single API, it is possible to receive, for example, 5G-specific local computation results in about 3ms, and then global computation results derived from conventional cloud computing in about 200ms thereafter.

[0121] Next, an example of how to parse the response at the client side will be explained.

[0122] Typically, values ​​returned by Web APIs used by rich clients (such as HTML5 and native apps) are data with a tree structure, such as JSON. When reading (parsing) JSON on the client side, the usual approach is to load the entire JSON data into memory and completely reproduce its tree structure as a data structure (object) in the programming language. However, according to this example, responses in the form of JSON data are returned progressively with time differences, such as returning only the beginning within 5ms and the rest within the next 100ms. Therefore, traditional standard JSON parsing methods cannot enjoy the low latency benefits that are the advantage of this example.

[0123] Therefore, as a method for parsing JSON, an event-driven API can be used. With this API, the JSON document is not treated as a tree structure, but rather represented as a series of events. This event-driven API is known as SAX (Simple API for XML) in the XML parser field, and JSON parsers also provide event-driven APIs as "SAX-like APIs." For example, JavaScript supports SAX-like APIs through stream-json (https: / / github.com / uhop / stream-json) and C++ through RapidJSON (http: / / rapidjson.org). Using a SAX-like API, the start and end points of the hierarchical structure in the JSON, attribute definitions, etc., are sequentially notified to the application as events, thus allowing JSON segments to be parsed immediately.

[0124] Operation and Advantages

[0125] In view of the increasing availability of 5G+MEC as a new edge computing infrastructure, this embodiment first proposes a new Web API implementation method suitable for vertical distribution (where computing-capable servers are distributed along network paths). This embodiment can become the de facto standard for API implementation in the 5G era. The operation and advantages of this embodiment include the following three points.

[0126] -Ultra-low latency-

[0127] According to this embodiment, a response can be immediately returned from the MEC infrastructure on the mobile network to the player terminal 30. Therefore, the time required to return a response is, for example, approximately 10ms, which is significantly reduced compared to the time required to return a response from the cloud side (approximately 100ms to 200ms). This means that server-side functions can be used at a frequency corresponding to each frame (approximately 16ms) in a 60FPS game; that is, a significantly lower latency than that in existing games can be achieved.

[0128] -Scalability-

[0129] According to this embodiment, for example, when a single Web API is called by millions of player terminals 30, the edge server 20 simultaneously aggregates the received multiple requests and calls the same Web API on the cloud server 10 while immediately (within milliseconds) returning a provisional response to the player terminals 30. Therefore, at the cloud server 10, the number of simultaneous connections can be reduced to the number of edge servers 20.

[0130] -compatibility-

[0131] According to this embodiment, by employing an API that combines a first response with low latency and a second response with normal latency, a game can be built that, without significantly altering the API of the cloud server 10, maintains a simple REST API while reducing the apparent latency of network access from players operating player terminals 30 to less than 10 milliseconds. Furthermore, during the transition period from 4G to 5G or in environments where fixed loops and 5G coexist, the load on connections other than 5G connections can be distributed using a conventional cloud-side load balancer, allowing this embodiment to be readily incorporated into existing systems.

[0132] <Second Embodiment>

[0133] "structure"

[0134] In the first embodiment, each edge server 20 calculates a "provisional aggregation result of parallel received requests," which aggregates the results of requests from some players among a plurality of spatially distributed players. On the other hand, in this embodiment, each edge server 20 calculates a "provisional aggregation result of consecutively received requests," which aggregates the results of multiple requests sent by a single player in a manner differing in time. This will be explained in detail below.

[0135] Each edge receiving unit 21 of the edge-side server 20 receives multiple requests sent from a single player terminal 30 with a time difference. A first edge processing unit 22 performs processing based on these requests and sends the results of this processing as a first response to the requests to the player terminal 30. A second edge processing unit 23 calculates a "temporary aggregation request of the continuously received requests," which aggregates the results of processing the multiple requests sent from the player terminal 30 with a time difference, and sends the "temporary aggregation result of the continuously received requests" to the cloud-side server 10.

[0136] The cloud processing unit 12 of the cloud-side server 10 performs processing based on the "provisional aggregation result of continuously received requests" and sends the result of the processing based on the "provisional aggregation result of continuously received requests" to the edge-side server 20. When the second edge processing unit 23 of the edge-side server 20 receives the result of the processing based on the "provisional aggregation result of continuously received requests" from the cloud-side server 10, it sends the result as a second response to these requests to the player terminal 30.

[0137] Figure 12 An example flow of this process is shown. When the player terminal 30 sends a request to the edge server 20 (S200), the edge server 20 performs processing based on the request (S201) and sends the result of the processing as a first response to the request to the player terminal 30 (S202).

[0138] Then, when the player terminal 30 sends a request to the edge server 20 (S203), the edge server 20 performs processing based on the request (S204) and sends the result of the processing as the first response to the request to the player terminal 30 (S205).

[0139] Then, when the player terminal 30 sends a request to the edge server 20 (S206), the edge server performs processing based on the request (S207) and sends the result of the processing as the first response to the request to the player terminal 30 (S208).

[0140] Note that although the sending and receiving of the request and the first response are repeated three times here, the number of times is not limited to this.

[0141] Then, at a predefined time interval, the second edge processing unit 23 sends the "provisional aggregation result of continuously received requests" (S209), which aggregates the processing results of the requests received so far (S200, S203 and S206), to the cloud-side server 10.

[0142] The cloud server 10 performs processing based on the "provisional aggregation result of continuously received requests" (S210) and sends the processing result to the edge server 20 (S209). The edge server 20 sends the processing result received from the cloud server 10 as a second response to the requests (S200, S203 and S206) to the player terminal 30 (S212).

[0143] Similarly, in this embodiment, each player terminal 30 receives a first response and a second response to the request via asynchronous I / O. Therefore, the player terminal 30 can perform other processing during the time period after receiving the first response and before receiving the second response.

[0144] Although there are no restrictions on the details of the requests sent from player terminal 30, the example is a synchronization request used to store management information (such as player character status information) managed by player terminal 30 on the server side.

[0145] In this scenario, player terminal 30 and edge server 20 can send and receive the latest management information and synchronization requests every specified time period T1 (S200, S203 and S206).

[0146] Then, the first edge processing unit 22 of the edge server 20 performs processing (S201, S204 and S207) to store the received management information in the edge storage device (storage unit 24), and sends a message indicating successful processing as the first response to the player terminal 30 (S202, S205 and S208).

[0147] Every specified time period T2 (T2 is greater than T1), the second edge processing unit 23 of the edge server 20 sends the latest management information stored in the edge storage device (storage unit 24) as "provisional aggregation result of continuously received requests" to the cloud server 10 (S209).

[0148] The cloud processing unit 12 of the cloud server 10 performs processing (S210) to store the management information received as a "provisional aggregation result of continuously received requests" in the cloud storage device (storage unit 13), and sends a message indicating successful processing as the result of processing based on the "provisional aggregation result of continuously received requests" to the edge server 20 (S211).

[0149] Note that the game system according to this embodiment can be configured to perform not only the time aggregation processing described in the context of this embodiment, but also the spatial aggregation processing described in the context of the first embodiment.

[0150] The game system according to this embodiment is configured similarly to that of the first embodiment in other respects.

[0151] Example

[0152] Next, an example of the second embodiment will be described. Figure 11 The image below provides an overview of this example. This example will be illustrated in the context of a native game app, for instance, saving and synchronizing data on a server-side frequency corresponding to each frame.

[0153] Using existing native apps, communication with cloud servers involves relatively high latency. Therefore, communication is typically limited to specific timeframes where latency won't cause problems (e.g., between phases, and before and after battles). However, with this approach, situations like temporary communication drops mid-game are difficult to distinguish between intentional fraud (cheating) and unavoidable disconnections. Consequently, such cases are often uniformly treated as invalid matches. This treatment is stressful for players who haven't engaged in fraudulent activities, requiring them to enjoy the game in environments with stable communication.

[0154] When applying this example, game status can be saved (synchronized) on the server side at a high frequency (e.g., multiple times per second), even during gameplay such as battles. This enables cloud-native services, allowing recovery by reading status data from the server even if communication is lost, without requiring a restart on the client side.

[0155] Through such real-time savings Figure 11 [M1-1] and [M2-1] implement the same APIs as traditional game servers for verifying and saving game data, while [M1-2] implements processing to send only the latest version of the data to [M2] after multiple data saves. This enables low latency and significantly reduces the load on the cloud side.

[0156] Operation and Advantages

[0157] By utilizing the game system according to this embodiment described above, similar operations and advantages as those of the first embodiment are achieved. Furthermore, each edge server 20 can calculate a "provisional aggregation result of consecutively received requests," aggregating the results of multiple requests sent from a single player in a time-different manner, and can send this result to the cloud server 10. This expands the use cases of the edge server 20, thereby broadening its scope of application.

[0158] The example reference pattern is explained below.

[0159] 1. A game system, comprising a cloud server, an edge server, and a player terminal.

[0160] The edge-side server includes:

[0161] An edge receiving unit is used to receive requests sent from the player's terminal;

[0162] A first edge processing unit is configured to perform processing based on the request and send the result of the processing based on the request as a first response to the request to the player terminal; and

[0163] The second edge processing unit is configured to, at regular intervals, send an aggregated result containing the processing results based on the request to the cloud-side server, receive the processing results based on the aggregated result executed at the cloud-side server, and send the processing results based on the aggregated result as a second response to the request to the player terminal.

[0164] The cloud-side server includes:

[0165] A cloud receiving unit is used to receive aggregation results sent from the edge-side server; and

[0166] A cloud processing unit is configured to perform processing based on the aggregation result, and send the processing result based on the aggregation result to the edge-side server.

[0167] The player terminal includes:

[0168] The terminal sending / receiving unit is configured to send the request and, in response to one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O.

[0169] 2. The game system described in 1,

[0170] The player terminal:

[0171] Upon receiving the first response, a first presentation corresponding to the first response is performed, and upon receiving the second response, a second presentation corresponding to the second response is performed.

[0172] The second presentation begins before the first presentation ends.

[0173] 3. The game system described in 1 or 2,

[0174] Each of the plurality of player terminals communicates with one of the plurality of edge-side servers.

[0175] The edge receiving unit receives multiple requests sent from multiple player terminals communicating with a local edge-side server.

[0176] The second edge processing unit calculates a provisional aggregation result of the requests received in parallel, and sends the provisional aggregation result of the requests received in parallel to the cloud-side server. The provisional aggregation result of the requests received in parallel aggregates the processing results of multiple requests sent from multiple player terminals communicating with the local edge-side server.

[0177] The cloud receiving unit receives provisional aggregation results of the parallel-received requests from multiple edge-side servers.

[0178] The cloud processing unit calculates the final aggregated result of the parallel-received requests by aggregating the provisional aggregation results of multiple parallel-received requests, and sends the final aggregated result of the parallel-received requests to multiple edge-side servers.

[0179] The second edge processing unit sends the final aggregated result of the received parallel requests as the second response to the multiple player terminals communicating with the local edge server.

[0180] 4. Based on the game system described in 3,

[0181] The request in question is an attack request that represents an attack against an enemy character.

[0182] The provisional aggregated result of the parallel received requests calculated by each of the edge-side servers is the damage value to the enemy character, which is calculated based on multiple attack requests sent from multiple player terminals communicating with the edge-side server.

[0183] The final aggregation result of the parallel received requests is the sum of the damage values ​​inflicted on the enemy character, represented by the provisional aggregation results of each parallel received request calculated separately by the edge-side server.

[0184] 5. The game system described in 1 or 2,

[0185] The edge receiving unit receives multiple requests sent from one of the player terminals with a time difference.

[0186] The second edge processing unit calculates a provisional aggregation result of consecutively received requests and sends the provisional aggregation result to the cloud-side server. This provisional aggregation result includes the processing results of multiple requests sent from one of the player terminals with a time difference.

[0187] The cloud processing unit performs processing based on the provisional aggregation results of the continuously received requests, and sends the processing results based on the provisional aggregation results of the continuously received requests to the edge server.

[0188] 6. The game system described in 1,

[0189] The request is a synchronization request used to save the management information managed by the player's terminal on the server side.

[0190] The edge receiving unit receives the latest management information and the synchronization request every specified time period T1.

[0191] The first edge processing unit performs processing to store the received management information in an edge storage device, and sends a message indicating successful processing as the first response to the player terminal.

[0192] In this process, the second edge processing unit sends the latest management information stored in the edge storage device as a provisional aggregation result of continuously received requests to the cloud-side server every predetermined time period T2, where T2 is greater than T1.

[0193] The cloud processing unit performs processing to store the management information received as a provisional aggregation result of the continuously received requests in a cloud storage device, and sends a message indicating successful processing as the result of processing based on the provisional aggregation result of the continuously received requests to the edge server.

[0194] 7. A game control method, executed by a game system comprising a cloud-side server, an edge-side server, and a player terminal.

[0195] The edge-side server:

[0196] Receive requests sent from the player's terminal;

[0197] Perform processing based on the request, and send the result of the processing based on the request as a first response to the request to the player terminal; and

[0198] At regular intervals, an aggregated result, which includes the processing results based on the request, is sent to the cloud-side server. The server receives the processing results based on the aggregated result, which are then executed on the cloud-side server. Finally, the processing results based on the aggregated result are sent to the player's terminal as a second response to the request.

[0199] Among them, the cloud-side server:

[0200] Receive the aggregation result sent from the edge-side server; and

[0201] Perform processing based on the aggregation result, and send the result of the processing based on the aggregation result to the edge-side server.

[0202] The player terminal:

[0203] Send the request, and for one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O.

[0204] 8. An edge-side server in a game system according to any one of 1 to 6.

[0205] 9. A cloud-side server in a game system according to any one of 1 to 6.

[0206] 10. A player terminal in a game system according to any one of 1 to 6.

[0207] This application claims the benefit based on priority of Japanese Patent Application 2020-176463, filed on October 21, 2020, the entire disclosure of which is incorporated herein by reference.

[0208] Explanation of reference numerals in the attached figures

[0209] 1A Processor

[0210] 2A memory

[0211] 3A Input / Output Interface

[0212] 4A peripheral circuit

[0213] 5A bus

[0214] 10 cloud-based servers

[0215] 11 Cloud Receiving Unit

[0216] 12 cloud processing units

[0217] 13 storage units

[0218] 20 edge servers

[0219] 21 Edge Receiving Unit

[0220] 22 First Edge Processing Unit

[0221] 23 Second Edge Processing Unit

[0222] 24 storage units

[0223] 30 player terminals

[0224] 31 Input Unit

[0225] 32 Output Units

[0226] 33 Processing Units

[0227] 34 storage units

[0228] 35 Terminal Transmit / Receive Unit

[0229] 60 Internet

[0230] 70 Mobile Networks

[0231] 71 base stations

[0232] 72 Core Network

[0233] 73 Internet Gateway

Claims

1. A game system, comprising a cloud server, an edge server, and a player terminal. in, The edge-side server includes: An edge receiving unit is used to receive requests sent from the multiple player terminals respectively; A first edge processing unit is configured to perform processing based on each of the requests sent from the plurality of player terminals respectively, calculate an aggregation result that aggregates the processing results of each of the requests received at each certain time interval, and send the aggregation result as a first response to the request to each of the plurality of player terminals; and The second edge processing unit is configured to send the aggregation result to the cloud-side server at regular intervals, receive the processing results based on the aggregation result executed at the cloud-side server, and send the processing results based on the aggregation result as a second response to the request to the player terminal. The cloud-side server includes: A cloud receiving unit is used to receive aggregation results sent from the edge-side server; and A cloud processing unit is configured to perform processing based on the aggregation result, and send the processing result based on the aggregation result to the edge-side server. The player terminal includes: The terminal sending / receiving unit is configured to send the request and, in response to one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O.

2. The game system according to claim 1, in, The player terminal: Upon receiving the first response, a first presentation corresponding to the first response is performed, and upon receiving the second response, a second presentation corresponding to the second response is performed. The second presentation begins before the first presentation ends.

3. The game system according to claim 1 or 2, in, Each of the plurality of player terminals communicates with one of the plurality of edge-side servers. The edge receiving unit receives multiple requests sent from multiple player terminals communicating with a local edge-side server. The second edge processing unit calculates a provisional aggregation result of the requests received in parallel, and sends the provisional aggregation result of the requests received in parallel to the cloud-side server. The provisional aggregation result of the requests received in parallel aggregates the processing results of multiple requests sent from multiple player terminals communicating with the local edge-side server. The cloud receiving unit receives provisional aggregation results of the parallel-received requests from multiple edge-side servers. The cloud processing unit calculates the final aggregated result of the parallel-received requests by aggregating the provisional aggregation results of multiple parallel-received requests, and sends the final aggregated result of the parallel-received requests to multiple edge-side servers. The second edge processing unit sends the final aggregated result of the received parallel requests as the second response to the multiple player terminals communicating with the local edge server.

4. The game system according to claim 3, in, The request is an attack request that represents an attack against an enemy character. The provisional aggregated result of the parallel received requests calculated by each of the edge-side servers is the damage value to the enemy character, which is calculated based on multiple attack requests sent from multiple player terminals communicating with the edge-side server. The final aggregation result of the parallel received requests is the sum of the damage values ​​inflicted on the enemy character, represented by the provisional aggregation results of each parallel received request calculated separately by the edge-side server.

5. The game system according to claim 1 or 2, in, The edge receiving unit receives multiple requests sent from one of the player terminals in a time-difference manner. The second edge processing unit calculates a provisional aggregation result of consecutively received requests and sends the provisional aggregation result to the cloud-side server. This provisional aggregation result includes the processing results of multiple requests sent from one of the player terminals with a time difference. The cloud processing unit performs processing based on the provisional aggregation results of the continuously received requests, and sends the processing results based on the provisional aggregation results of the continuously received requests to the edge server.

6. A game system, comprising a cloud server, an edge server, and a player terminal. in, The edge-side server includes: An edge receiving unit is used to receive requests sent from the player's terminal; A first edge processing unit is configured to perform processing based on the request and send the result of the processing based on the request as a first response to the request to the player terminal; and The second edge processing unit is configured to, at regular intervals, send an aggregated result containing the processing results based on the request to the cloud-side server, receive the processing results based on the aggregated result executed at the cloud-side server, and send the processing results based on the aggregated result as a second response to the request to the player terminal. The cloud-side server includes: A cloud receiving unit is used to receive aggregation results sent from the edge-side server; and A cloud processing unit is configured to perform processing based on the aggregation result and send the processing result based on the aggregation result to the edge-side server. The player terminal includes: The terminal sending / receiving unit is configured to send the request and, in response to one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O. The request is a synchronization request used to save the management information managed by the player's terminal on the server side. The edge receiving unit receives the latest management information and the synchronization request every specified time period T1. The first edge processing unit performs processing to store the received management information in an edge storage device, and sends a message indicating successful processing as the first response to the player terminal. In this process, the second edge processing unit sends the latest management information stored in the edge storage device as a provisional aggregation result of continuously received requests to the cloud-side server every predetermined time period T2, where T2 is greater than T1. The cloud processing unit performs processing to store the management information received as a provisional aggregation result of the continuously received requests in a cloud storage device, and sends a message indicating successful processing as the result of processing based on the provisional aggregation result of the continuously received requests to the edge server.

7. A game control method, executed by a game system comprising a cloud-side server, an edge-side server, and a player terminal. in, The edge-side server: Receive requests sent from the multiple player terminals respectively; The system performs processing based on each of the requests sent from the multiple player terminals respectively, calculates an aggregated result that aggregates the results of processing each of the requests received at each certain time interval, and sends the aggregated result as a first response to the request to each of the multiple player terminals. as well as At regular intervals, the aggregated results are sent to the cloud-side server, the results of processing based on the aggregated results are received at the cloud-side server, and the results of processing based on the aggregated results are sent to the player terminal as a second response to the request. Among them, the cloud-side server: Receive the aggregation result sent from the edge-side server; and Perform processing based on the aggregation result, and send the result of the processing based on the aggregation result to the edge-side server. The player terminal: Send the request, and for one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O.

8. A game control method, executed by a game system comprising a cloud-side server, an edge-side server, and a player terminal. in, The edge-side server performs: An edge receiving step is used to receive a request sent from the player's terminal; A first edge processing step is used to perform processing based on the request and send the result of the processing based on the request as a first response to the request to the player terminal; as well as The second edge processing step is used to send an aggregated result, which includes the processing results based on the request, to the cloud-side server at regular intervals; receive the processing results based on the aggregated result executed at the cloud-side server; and send the processing results based on the aggregated result as a second response to the request to the player terminal. The cloud-side server performs the following: The cloud receiving step is used to receive the aggregation result sent from the edge-side server; and The cloud processing step is used to perform processing based on the aggregation result, and send the result of the processing based on the aggregation result to the edge-side server. The player terminal executes: The terminal sending / receiving step is used to send the request and, in response to one of the requests, sequentially receive the first response and the second response from the edge-side server via asynchronous I / O. The request is a synchronization request used to save the management information managed by the player's terminal on the server side. The edge-side server: In the edge receiving step, the latest management information and the synchronization request are received every specified time period T1; In the first edge processing step, processing is performed to store the received management information in an edge storage device, and a message indicating successful processing is sent as the first response to the player terminal; and In the second edge processing step, every predetermined time period T2, the latest management information stored in the edge storage device is sent to the cloud-side server as a provisional aggregation result of continuously received requests, where T2 is greater than T1. Among them, the cloud-side server: In the cloud processing step, processing is performed to store the management information received as a provisional aggregation result of the continuously received requests in a cloud storage device, and a message indicating successful processing is sent as the result of processing based on the provisional aggregation result of the continuously received requests to the edge-side server.

9. An edge-side server in a game system according to any one of claims 1 to 6.

10. A cloud-side server in a game system according to any one of claims 1 to 6.

11. A player terminal in a game system according to any one of claims 1 to 6.

Images