WO2022085585A1 - ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法 - Google Patents

ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法 Download PDF

Info

Publication number
WO2022085585A1
WO2022085585A1 PCT/JP2021/038229 JP2021038229W WO2022085585A1 WO 2022085585 A1 WO2022085585 A1 WO 2022085585A1 JP 2021038229 W JP2021038229 W JP 2021038229W WO 2022085585 A1 WO2022085585 A1 WO 2022085585A1
Authority
WO
WIPO (PCT)
Prior art keywords
edge
side server
request
cloud
result
Prior art date
Application number
PCT/JP2021/038229
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 CN202180085978.0A priority Critical patent/CN116670648A/zh
Publication of WO2022085585A1 publication Critical patent/WO2022085585A1/ja
Priority to US18/302,550 priority patent/US20230256334A1/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/355—Performing operations on behalf of clients with restricted processing capabilities, e.g. servers transform changing game scene into an encoded video stream for transmitting to a mobile phone or a thin client
    • 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
    • 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/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/332—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using wireless networks, e.g. cellular phone 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
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A63F13/822—Strategy games; Role-playing games
    • 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
    • A63F9/00—Games not otherwise provided for
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present invention relates to a game system, an edge side server, a cloud side server, a game terminal, and a game control method.
  • MEC Multi-access Edge Computing
  • Vertical distribution in which the servers that have them are distributed, enables communication between the edge-side server and the client with a low delay of only a few milliseconds.
  • Non-Patent Document 1 describes a 5G network and MEC, and proposes a game as an application example of MEC.
  • Non-Patent Document 2 incorporates an edge-side server in the data center of a communication provider at the edge of a 5G network, and realizes low latency in games, live video streaming, machine learning inference at the edge, augmented reality, virtual reality, etc. It discloses what it can do.
  • Non-Patent Document 3 discloses the contents regarding the Comet that keeps the HTTP session connected.
  • Non-Patent Documents 1 and 2 propose a game as a use case of MEC, but do not disclose the detailed technique thereof.
  • An object of the present invention is to simultaneously achieve a much higher level of scalability (multi-connection) and response performance (low delay) of a game service than before.
  • the edge side server is An edge receiving unit that receives a request transmitted by the player terminal, and A first edge processing unit that executes a process based on the request and transmits the result of the process based on the request to the player terminal as a first response to the request.
  • the aggregation result that aggregates the results of the processing based on the request is transmitted to the cloud side server, the result of the processing based on the aggregation result executed by the cloud side server is received, and the aggregation result is used.
  • a second edge processing unit that transmits the result of the processing based on the request to the player terminal as a second response to the request.
  • the cloud side server is A cloud receiver that receives the aggregation result transmitted by the edge-side server, and A cloud processing unit that executes processing based on the aggregation result and transmits the result of the processing based on the aggregation result to the edge side server.
  • the player terminal is A terminal transmission / reception unit that transmits the request and receives the first response and the second response from the edge-side server in this order by asynchronous I / O for one request.
  • a game system is provided.
  • the edge side server is Upon receiving the request sent by the player terminal, The process based on the request is executed, and the result of the process based on the request is transmitted to the player terminal as the first response to the request.
  • the aggregation result that aggregates the results of the processing based on the request is transmitted to the cloud side server, the result of the processing based on the aggregation result executed by the cloud side server is received, and the aggregation result is used.
  • the result of the processing based on the above is transmitted to the player terminal as a second response to the request, and the result is transmitted to the player terminal.
  • the cloud side server is Upon receiving the aggregation result transmitted by the edge side server, The process based on the aggregation result is executed, and the result of the process based on the aggregation result is transmitted to the edge side server.
  • the player terminal is A game control method is provided in which the request is transmitted and the first response and the second response are received from the edge-side server in this order by asynchronous I / O for one request.
  • an edge side server of the game system is provided.
  • a cloud-side server of the game system is provided.
  • the player terminal of the game system is provided.
  • This embodiment captures the spread of a new edge computing infrastructure called 5G + MEC, and is a new WebAPI implementation method suitable for vertical distribution in which servers with computing power are distributed and arranged on the network path.
  • 5G + MEC new edge computing infrastructure
  • WebAPI exposed to the outside returns a response as soon as possible after being called, which is extremely simple. It was a thing.
  • the technical feature of this embodiment is that when a large number of clients call one WebAPI, the edge-side server immediately returns a provisional response to the client (in a few milliseconds) and aggregates the received multiple requests.
  • the point is to make a gradual response by calling the same WebAPI on the cloud and then additionally returning the final calculation result obtained from the cloud-side server (after several hundred milliseconds).
  • aggregated request handling Aggregative Request Handling
  • progressive response Progressive Response
  • the client that calls WebAPI only reads one WebAPI asynchronously, and first receives an immediate response that reflects the local information of the edge side server, and then the global and finalized cloud side server. Response can be additionally received.
  • the client since the client receives the above two responses by asynchronous I / O, it is possible to receive the response from the cloud side server while drawing the effect according to the response from the edge side server by animation or the like. can. While performing the first screen display corresponding to the quick response from the edge side server in this way, the response from the cloud side server is received and connected to the above first screen display seamlessly on the cloud side.
  • the game system has a cloud-side server 10, a plurality of edge-side servers 20, and a plurality of player terminals 30.
  • the player terminal 30 is a mobile terminal operated by the player, and examples thereof include smartphones, tablet terminals, personal computers, game machines, smart watches, and mobile phones, but the player terminals 30 are not limited thereto.
  • the edge side server 20 is a so-called MEC server.
  • the cloud side server 10 is a server installed on the cloud side.
  • the player terminal 30 and the cloud-side server 10 communicate with each other via the 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, and the like.
  • the Internet 60 of the present embodiment is a concept that does not include the mobile network 70 to which the player terminal 30 is connected.
  • the edge side server 20 is located in the mobile network 70. Then, the player terminal 30 and the edge side server 20 communicate with each other without going through the Internet 60.
  • the installation position of the edge side server 20 is not particularly limited, but examples thereof include the inside of the base station 71 of the telecommunications carrier and the inside of the equipment of the core network 72.
  • each of the plurality of player terminals 30 communicates with any one of the plurality of edge-side servers 20. This means that each of the plurality of player terminals 30 does not communicate with the plurality of edge-side servers 20 at the same time.
  • the edge-side server 20 that is the communication partner of the player terminal 30 can be changed according to the change of the position of the player terminal 30.
  • Each player terminal 30 communicates with, for example, an edge-side server 20 installed in a base station 71 to which the own terminal is connected.
  • FIG. 3 shows an example of a functional block diagram of the player terminal 30.
  • the player terminal 30 has an input unit 31, an output unit 32, a processing unit 33, a storage unit 34, and a terminal transmission / reception unit 35.
  • a function to accept input from the player a function to send a request based on the input content to the server, a function to receive a response to the request from the server, a function to display a screen according to the received response, etc. are realized. To.
  • FIG. 4 shows an example of a functional block diagram of the edge side server 20.
  • the edge side server 20 has an edge receiving unit 21, a first edge processing unit 22, a second edge processing unit 23, and a storage unit 24.
  • the function of receiving the request transmitted by the player terminal 30 communicating with the own device (edge side server 20) and the result of the processing based on the request received from the player terminal 30 are obtained by the player as the result of provisional processing.
  • a function of receiving and returning to the player terminal 30 is realized.
  • FIG. 5 shows an example of a functional block diagram of the cloud-side server 10.
  • the cloud-side server 10 has a cloud receiving unit 11, a cloud processing unit 12, and a storage unit 13.
  • a function of transmitting the final processing result to the edge side server 20 is realized.
  • FIG. 6 is a sequence diagram showing an example of the processing flow of the game system. More specifically, from the time when a plurality of players perform a predetermined operation (eg, attack) on each player terminal 30 at an arbitrary timing during the progress of the game until the screen display corresponding to the operation is performed on the player terminal 30. The flow of processing performed in a relatively short time is shown.
  • a predetermined operation eg, attack
  • MMORPG Massively Multiplayer Online Role-Playing Game
  • FIG. 6 shows a plurality of first player terminals 30, a first edge side server 20, a plurality of mth player terminals 30, a third mth edge side server 20, and a cloud side server 10.
  • the plurality of first player terminals 30 are player terminals 30 operated by some of the plurality of players participating in the game.
  • the plurality of first player terminals 30 are common in that they communicate with the same edge-side server 20 (first edge-side server 20).
  • the plurality of first player terminals 30 are connected to the same base station.
  • the first edge-side server 20 is installed in, for example, a base station to which a plurality of first player terminals 30 are connected.
  • the plurality of mth player terminals 30 are player terminals 30 operated by some players among the plurality of players participating in the game.
  • the plurality of mth player terminals 30 are common in that they communicate with the same edge side server 20 (mth edge side server 20).
  • the plurality of m-th player terminals 30 are connected to the same base station.
  • the m-th edge-side server 20 is installed in, for example, a base station to which a plurality of m-th player terminals 30 are connected.
  • the figure shows two edge-side servers 20 and two sets of a plurality of player terminals 30, the number of these is not limited to those shown in the figure.
  • each of the plurality of first player terminals 30 transmits a request generated based on the input from the player to the server (S101).
  • the requests transmitted by the plurality of first player terminals 30 are received by the first edge-side server 20.
  • the input unit 31 receives an operation from the player via an arbitrary input device such as a touch panel, a physical button, a microphone, a keyboard, and a mouse. For example, it accepts operations to attack or defend against enemy characters.
  • the processing unit 33 generates a request (attack request, defense request, etc.) indicating the input content.
  • the terminal transmission / reception unit 35 calls a predetermined WebAPI and transmits the generated request.
  • the first edge-side server 20 When the first edge-side server 20 receives the requests transmitted by the plurality of first player terminals 30 (S101), the first edge-side server 20 executes a process based on the received plurality of requests (S102), and obtains the result of the process based on the request. It is transmitted to a plurality of first player terminals 30 as a first response to the request (S103).
  • the reception of the request of S101 is realized by the edge receiving unit 21.
  • the processing of S102 and S103 is realized by the first edge processing unit 22.
  • the first edge processing unit 22 is locally consistent using data related to a part of the plurality of players participating in the game (players operating the plurality of first player terminals 30). Calculate a certain processing result.
  • the first edge processing unit 22 calculates a result (whether or not the enemy character is damaged, the amount of damage, etc.) based on the attack requests transmitted by each of the plurality of first player terminals 30, and then the plurality of attacks. Calculate the aggregation result (total damage amount given to the enemy character by the multiple attack requests, etc.) that aggregates the request results. Then, the first edge processing unit 22 obtains the aggregated result (whether or not the enemy character is damaged by the plurality of attack requests, the total amount of damage given to the enemy character, etc.) by aggregating the results of the plurality of attack requests. It is transmitted to a plurality of first player terminals 30 as a response of 1.
  • the second edge processing unit 23 transmits, at regular intervals, to the cloud-side server 10 the aggregated result of aggregating the processing results based on the requests transmitted by each of the plurality of first player terminals 30. S105).
  • the aggregation result calculated by each edge-side server 20 is the result of a request from a part of a plurality of players spreading in the spatial direction (a player who operates a player terminal 30 that communicates with each edge-side server 20). This is the result of aggregation.
  • the aggregation result calculated by each edge side server 20 is referred to as "" provisional aggregation result of requests received in parallel "".
  • the first display corresponding to the first response is performed (S104). That is, when the terminal transmission / reception unit 35 receives the first response, the processing unit 33 generates data that realizes the first display based on the first response and the data stored in the storage unit 34, and then outputs the data. The unit 32 is made to execute the first display.
  • the request transmitted in S101 is an attack request
  • an effect display Q indicating that the enemy character P has been damaged can be considered.
  • the damage amount R given to the enemy character P indicated by the "provisional aggregation result of requests received in parallel" may be included.
  • the duration of the first display (S104) is designed to continue until the second display (S116) corresponding to the subsequent second response is started.
  • the same processing as the processing by the plurality of first player terminals 30 and the first edge-side server 20 described above is executed by the other player terminal 30 and the other edge-side server 20 at the same timing (S106 to S110).
  • the content of the response can be different. Therefore, the content of the first display displayed on the first player terminal 30 and the content of the first display displayed on the mth player terminal 30 may be different.
  • the damage amount R shown in the example shown in FIG. 8 can have different values.
  • the contents of the first response received from the first edge-side server 20 by the plurality of first player terminals 30 are the same. Therefore, the content of the first display displayed on the plurality of first player terminals 30 is the same.
  • the damage amount R shown in the example shown in FIG. 8 has the same value.
  • the contents of the first response received by the plurality of mth player terminals 30 from the mth edge side server 20 are the same. Therefore, the content of the first display displayed on the plurality of mth player terminals 30 is the same.
  • the damage amount R shown in the example shown in FIG. 8 has the same value.
  • the cloud-side server 10 executes processing based on the "provisional aggregation result of requests received in parallel" received from each of the plurality of edge-side servers 20 (S111), and the processing results are obtained from the plurality of edge-side servers. It is transmitted to 20 (S112, S113).
  • the process of receiving the "provisional aggregation result of requests received in parallel" from each of the plurality of edge-side servers 20 is realized by the cloud receiving unit 11.
  • the processing of S111 to S113 is realized by the cloud processing unit 12.
  • the cloud processing unit 12 calculates the total damage value given to the enemy character indicated by each of the "provisional aggregation results of requests received in parallel" received from each of the plurality of edge side servers 20. Then, the cloud processing unit 12 transmits the total of the damage values to the plurality of edge-side servers 20.
  • the processing result calculated by the cloud processing unit 12 is an aggregation of "provisional aggregation results of requests received in parallel" received from a plurality of edge-side servers 20, that is, spreads in the spatial direction. This is the result of aggregating the results of all the requests of a plurality of players.
  • the processing result calculated by the cloud processing unit 12 is referred to as "" final aggregation result of requests received in parallel "".
  • the first edge-side server 20 When the first edge-side server 20 receives the "final aggregation result of requests received in parallel" from the cloud-side server 10 (S112), the "final aggregation result of requests received in parallel” is displayed. It is transmitted to a plurality of first player terminals 30 as a second response to the request received in S101 (S114). The processing of S112 and S114 is realized by the second edge processing unit 23.
  • the plurality of first player terminals 30 When the plurality of first player terminals 30 receive the second response (S114), the plurality of first player terminals 30 perform the second display corresponding to the second response (S116). That is, when the terminal transmission / reception unit 35 receives the second response, the processing unit 33 generates data that realizes the second display based on the data stored in the second response and the storage unit 34, and then outputs the data. Have unit 32 execute the second display.
  • the duration of the first display (S104) is designed to be continued until the second display (S116) corresponding to the subsequent second response is started. Therefore, the processing unit 33 starts the second display (S116) before the first display (S104) ends. That is, the first display (S104) and the second display (S116) are seamlessly connected.
  • the effect display Q indicating that the enemy character P has been damaged and the effect display Q "received in parallel" It is conceivable to display the amount of damage R given to the enemy character P shown in "Final aggregation result of the requested request".
  • the contents of are the same. Therefore, the content of the second display displayed on the first player terminal 30 and the content of the second display displayed on the third player terminal 30 are the same.
  • the damage amount R shown in the example shown in FIG. 9 has the same value.
  • the player terminal 30 transmits a request (S101, S106)
  • the player terminal 30 receives the first response and the second response from the edge side server 20 in this order by asynchronous I / O (S101, S106).
  • S103, S114, S108, S115 the first display corresponding to the first response can be performed between the time when the first response is received and the time when the second response is received (S104, S109).
  • each functional unit included in each device of the present embodiment is a storage unit such as a CPU (Central Processing Unit) of an arbitrary computer, a memory, a program loaded into the memory, and a hard disk for storing the program (the stage of shipping the device in advance).
  • a storage unit such as a CPU (Central Processing Unit) of an arbitrary computer, a memory, a program loaded into the memory, and a hard disk for storing the program (the stage of shipping the device in advance).
  • a storage unit such as a CPU (Central Processing Unit) of an arbitrary computer, a memory, a program loaded into the memory, and a hard disk for storing the program (the stage of shipping the device in advance).
  • CDs Compact Discs
  • FIG. 10 is a block diagram illustrating a hardware configuration of each device of the present embodiment. As shown in FIG. 2, each device 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. It should be noted that each device does not have to have the peripheral circuit 4A.
  • the cloud-side server 10 and the edge-side server 20 may be composed of a plurality of physically and / or logically separated devices. In this case, each device can be provided with the above hardware configuration. In addition, the cloud-side server 10 and the edge-side server 20 may be physically and logically configured by 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.
  • FIG. 1 An outline of this example is shown in FIG.
  • an API operated on a conventional cloud is used with a 5G MEC infrastructure.
  • the modules constituting the game system of this embodiment are the following six.
  • GameServer on the Edge is a game server placed on the MEC infrastructure and corresponds to the edge side server 20. Although it implements the same functions as the conventional game server (cloud side server 10) that operates on the cloud, it differs in that the database used is limited. [M1] implements the following two functions.
  • [M1-1] API Implementation processes requests with the same logic as [M2-1] API Implementation provided by [M2] GameServer on the Cloud, calculates the result of in-game actions, and makes a client (player terminal). It is an implementation of API that returns immediately to 30). Although this [M1-1] implements different functions for each game and each embodiment, it interprets a request received from the outside as an in-game command, performs some calculation, and then returns a response. Can be positioned as a general REST API.
  • [M1-1] uses only the information that the module [M1] knows, that is, the information of the player in a specific area, and the result is consistent. Is calculated, and the first response is returned immediately (eg, within 5 ms). Local information limited to [M1] referred to here is stored in [M3] SmallDB. Also, at this time, after the first response is transmitted, the connection (session) between [M1] GameServer on the Edge and the client is maintained without being disconnected.
  • Request Aggregator is a module that aggregates requests (for example, totaling the number of damages of enemy characters) and calls the corresponding API of [M2] at regular intervals.
  • requests for example, totaling the number of damages of enemy characters
  • APIs for example, totaling the number of damages of enemy characters
  • a method of summing up the total amount of damage given to one enemy character by a plurality of players can be considered.
  • [M2] GameServer on the Cloud is a game server that has been used conventionally, and corresponds to the cloud side server 10.
  • the function called from the client is open to the outside as Web API.
  • [M2] executes the API with a fixed frequency (at most, the frequency set in [M1] is the upper limit) and a low number of simultaneous connections (at most, the number of M1s installed).
  • the database [M4] can be used to calculate globally consistent results and can be positioned as a module to be returned to [M1].
  • [M2] is composed of at least one submodule as follows.
  • [M2-1] API Implementation is a module that implements the same logic of the game server on the cloud side as before. This module will share almost all functions with [M1-1].
  • [M3] SmallDB is a database for storing a part of the game state among a plurality of players participating in the game.
  • the [M3] included in each [M1] stores the game state of the player who operates the client communicating with each [M1].
  • M4 LargeDB is a database that stores the game status of all players participating in the game, and is a database for games that has been used conventionally.
  • FIG. 11 shows a guideline for the time required to send and receive each data. It should be noted that this is just a guide and is not limited to this.
  • the guideline for the communication time between [M1] and the client is about 2 ms.
  • the guideline for the communication time between [M1] and [M2] is about 100 ms.
  • the player terminal 30 When the player terminal 30 is connected to the Internet 60 via a network other than 5G (mobile network such as 3G, 4G, wireless LAN, etc.), the player terminal 30 does not directly go through the edge side server 20. Since it only communicates with the cloud-side server 10 and calls the API of the same URL, it can easily fall back. In that case, the response can simply be used as an API with the same speed as it is now.
  • 5G mobile network such as 3G, 4G, wireless LAN, etc.
  • [M1-2] of [M1] is the above-mentioned specific area.
  • the total amount of damage in is transmitted to [M2].
  • [M2] calculates, for example, the total amount of damage (global damage amount) given by all players (for example, about 1 million people) by adding up the total damage amount (local damage amount) for the number of base stations. Attack processing can be implemented.
  • [M2] After an elapsed time of about 200 ms, [M2] returns the total amount of damage (global damage amount) given by all players (for example, about 1 million people) to [M1] as a response. [M1] additionally returns this global damage amount to the client and ends the response.
  • the client draws the effect of the global damage amount by seamlessly updating the animation according to the provisional response during drawing (for example, seamlessly changing from FIG. 7 to FIG. 9, from FIG. 8). Seamlessly changed to Fig. 9).
  • the client draws the effect of the global damage amount by seamlessly updating the animation according to the provisional response during drawing (for example, seamlessly changing from FIG. 7 to FIG. 9, from FIG. 8). Seamlessly changed to Fig. 9).
  • a local calculation result peculiar to 5G in about 3 ms, for example, and after about 200 ms, it is calculated in the conventional cloud. It is possible to receive the global calculation result to be performed.
  • data having a tree structure such as JSON is often adopted.
  • JSON When the JSON is read (parsed) by the client, a method is often adopted in which the entire JSON data is read into the memory and the tree structure is reproduced at once as a data structure (object) of a programming language.
  • data such as JSON is returned as a gradual response with a time lag, for example, only the head portion is returned after 5 ms, and the entire data is returned after 100 ms, for example, so that it is a conventional standard.
  • the JSON parsing method the low delay which is the merit of this embodiment cannot be enjoyed.
  • an event-driven API that expresses a JSON document as a series of events can be used instead of treating it as a tree structure.
  • SAX SimpleAPI for XML
  • the JSON parser also provides an event-driven API as "SAX-like API".
  • SAX-like API For example, stream-json (https://github.com/uhop/stream-json) for JavaScript and RapidJSON (http://rapidjson.org) for C ++ support the SAX-like API.
  • stream-json https://github.com/uhop/stream-json
  • RapidJSON http://rapidjson.org
  • a response can be immediately returned to the player terminal 30 from the MEC infrastructure on the mobile network. Therefore, the time required for replying the response is, for example, about 10 ms, which can be significantly reduced as compared with the time required for returning the response from the cloud side (about 100 ms to 200 ms). This means that even in a 60 FPS game, the server-side function can be used at a frequency of every frame (about 16 ms), and it is possible to realize a low latency completely different from the conventional game.
  • the edge-side server 20 when one Web API is called by, for example, millions of player terminals 30, the edge-side server 20 immediately returns a provisional response to the player terminal 30 (in a few milliseconds), and receives a plurality of receptions. Aggregate the requests and call the same Web API on the cloud side server 10. Therefore, in the cloud-side server 10, the number of simultaneous connections can be limited to the number of edge-side servers 20 at most.
  • the API that combines the first response with low delay and the second response with normal delay is used, and the API of the cloud side server 10 is not significantly changed, and the player terminal is kept as a simple REST API. It is possible to construct a game in which the apparent delay of network access from the player who operates 30 is suppressed to less than 10 milliseconds. Furthermore, in the transition period from 4G to 5G or in an environment where fixed lines and 5G coexist, connections other than 5G can be load-balanced with a conventional load balancer on the cloud side, so this embodiment is smoothly existing. It can be additionally introduced to the system of.
  • the edge-side server 20 of the first embodiment has calculated a “provisional aggregation result of requests received in parallel” that aggregates the results of requests of a plurality of players spreading in the spatial direction.
  • the edge-side server 20 of the present embodiment calculates a "provisional aggregation result of continuously received requests” that aggregates the results of a plurality of requests transmitted by one player with a time lag.
  • the edge receiving unit 21 of the edge side server 20 receives a plurality of requests transmitted by one player terminal 30 with a time lag.
  • the first edge processing unit 22 executes the processing based on the request, and transmits the result of the processing based on the request to the player terminal 30 as the first response to the request.
  • the second edge processing unit 23 calculates a "provisional aggregation result of continuously received requests” that aggregates the processing results based on a plurality of requests transmitted by the player terminal 30 with a time lag, and "continuously”.
  • the "provisional aggregation result" of the received request is transmitted to the cloud side server 10.
  • the cloud processing unit 12 of the cloud-side server 10 executes processing based on the "provisional aggregation result of continuously received requests", and obtains the result of the processing based on the “provisional aggregation result of continuously received requests”. It is transmitted to the edge side server 20.
  • the second edge processing unit 23 of the edge side server 20 receives the processing result based on the "provisional aggregation result of continuously received requests" from the cloud side server 10, the second edge processing unit 23 receives the result as the second request for the above request. It is transmitted to the player terminal 30 as a response.
  • FIG. 12 shows an example of the flow of the process.
  • the edge side server 20 executes a process based on the request (S201), and the result of the process is used as the first response to the request to the player terminal 30. Transmit (S202).
  • the edge side server 20 executes a process based on the request (S204), and the result of the process is used as the first response to the request. It is transmitted to 30 (S205).
  • the edge side server 20 executes a process based on the request (S207), and the result of the process is used as the first response to the request. It is transmitted to 30 (S208).
  • the request and the first response are sent and received three times, but the number of times is not limited to this.
  • the second edge processing unit 23 aggregates the processing results for the requests (S200, S203, S206) received so far.
  • the "aggregation result” is transmitted to the cloud-side server 10 (S209).
  • the cloud-side server 10 executes processing based on the "provisional aggregation result of continuously received requests" (S210), and transmits the processing result to the edge-side server 20 (S209).
  • the edge-side server 20 transmits the processing result received from the cloud-side server 10 to the player terminal 30 as a second response to the request (S200, S203, S206) (S212).
  • the player terminal 30 receives the first response and the second response to the request by asynchronous I / O. Therefore, the player terminal 30 can perform other processing between the time when the first response is received and the time when the second response is received.
  • the details of the request transmitted from the player terminal 30 are not limited, but one example is a synchronization request for storing management information (player character status information, etc.) managed by the player terminal 30 on the server side.
  • the player terminal 30 and the edge-side server 20 can send and receive the latest management information and synchronization request every predetermined time T1 (S200, S203, S206).
  • the first edge processing unit 22 of the edge side server 20 executes a process of storing the received management information in the edge storage device (storage unit 24) (S201, S204, S207), and the processing is successful. Is transmitted to the player terminal 30 as the first response (S202, S205, S208).
  • the second edge processing unit 23 of the edge side server 20 stores the latest management information stored in the edge storage device (storage unit 24) every T 2 for a predetermined time (T 2 is larger than T 1 ). It is transmitted to the cloud-side server 10 as a "provisional aggregation result" of continuously received requests (S209).
  • the cloud processing unit 12 of the cloud side server 10 executes a process of storing the management information received as the "provisional aggregation result of continuously received requests" in the cloud storage device (storage unit 13) (S210).
  • the success of the process is transmitted to the edge side server 20 as a result of the process based on the "provisional aggregation result of continuously received requests” (S211).
  • the game system of the present embodiment may be configured to be able to execute the spatial direction aggregation process described in the first embodiment in addition to the time direction aggregation process described in the present embodiment.
  • Example Next, an embodiment of the second embodiment will be described. An outline of this example is shown in FIG.
  • data is stored and synchronized on the server side at a frequency of every frame.
  • communication with the cloud server was a process with a relatively large delay, so communication was performed at a timing that would not hinder even if there was a predetermined delay, such as at a stage break or before and after a battle.
  • a predetermined delay such as at a stage break or before and after a battle.
  • processing such as making a uniform invalid match was taken. Since this is a stressful process for a player who has not cheated, it is essential to enjoy the game in a place where the communication state is stable.
  • the state of the game can be saved (synchronized) on the server side frequently (for example, multiple times per second) even during a game such as a battle, so that communication is disconnected.
  • cloud-native operation that reads the status data from the server and restores it without restarting the client side becomes possible.
  • [M1-1] and [M2-1] in FIG. 11 implement the same game data verification / save API as the conventional game server, and further, as [M1-2], a plurality of them.
  • a save function with low latency and a significantly reduced load on the cloud side is realized. be able to.
  • the edge side server 20 calculates a "provisional aggregation result of continuously received requests" that aggregates the results of a plurality of requests transmitted by one player with a time lag, and transmits the result to the cloud side server 10. Can be done. Therefore, the usage scene of the edge side server 20 is expanded, and the range of utilization is expanded.
  • the edge side server is An edge receiving unit that receives a request transmitted by the player terminal, and A first edge processing unit that executes a process based on the request and transmits the result of the process based on the request to the player terminal as a first response to the request.
  • the aggregation result that aggregates the results of the processing based on the request is transmitted to the cloud side server, the result of the processing based on the aggregation result executed by the cloud side server is received, and the aggregation result is used.
  • a second edge processing unit that transmits the result of the processing based on the request to the player terminal as a second response to the request.
  • the cloud side server is A cloud receiver that receives the aggregation result transmitted by the edge-side server, and A cloud processing unit that executes processing based on the aggregation result and transmits the result of the processing based on the aggregation result to the edge side server.
  • the player terminal is A terminal transmission / reception unit that transmits the request and receives the first response and the second response from the edge-side server in this order by asynchronous I / O for one request.
  • the player terminal is When the first response is received, the first display corresponding to the first response is performed, and when the second response is received, the second display corresponding to the second response is performed.
  • Each of the plurality of player terminals communicates with any one of the plurality of edge-side servers, and communicates with any one of the plurality of edge-side servers.
  • the edge receiving unit receives a plurality of the requests transmitted by each of the plurality of player terminals communicating with the own edge side server, and receives the plurality of requests.
  • the second edge processing unit calculates a provisional aggregation result of requests received in parallel, which aggregates the processing results based on the plurality of requests transmitted by each of the plurality of player terminals communicating with the own edge side server. Then, the provisional aggregation result of the requests received in parallel is transmitted to the cloud side server.
  • the cloud receiving unit receives the provisional aggregation result of the requests received in parallel from each of the plurality of edge-side servers, and receives the provisional aggregation result.
  • the cloud processing unit aggregates the provisional aggregation results of the plurality of requests received in parallel, calculates the final aggregation result of the requests received in parallel, and finally aggregates the requests received in parallel.
  • the second edge processing unit transmits the final aggregation result of the received requests received in parallel to the plurality of player terminals communicating with the own edge side server as the second response.
  • the request is an attack request indicating the content of the attack on the enemy character.
  • the provisional aggregation result of the requests received in parallel calculated by each of the edge-side servers is the enemy calculated based on the plurality of attack requests transmitted by the plurality of player terminals communicating with each of the edge-side servers. It is the damage value given to the character.
  • the final aggregation result of the requests received in parallel is the total of the damage values given to the enemy character indicated by each of the provisional aggregation results of the requests received in parallel calculated by each of the edge-side servers3.
  • the game system described in. 5. The edge receiving unit receives a plurality of the requests transmitted by one player terminal with a time lag, and receives the plurality of requests.
  • the second edge processing unit calculates a provisional aggregation result of continuously received requests that aggregates the results of processing based on the plurality of requests transmitted by one player terminal with a time lag, and continuously.
  • the provisional aggregation result of the received request is sent to the cloud side server, and the result is sent to the cloud side server.
  • the cloud processing unit executes processing based on the provisional aggregation result of the continuously received requests, and transmits the processing result based on the provisional aggregation result of the continuously received requests to the edge side server.
  • the game system according to 1 or 2. 6.
  • the request is a synchronization request for storing management information managed by the player terminal on the server side.
  • the edge receiving unit receives the latest management information and the synchronization request every predetermined time T1 and receives the latest management information and the synchronization request.
  • the first edge processing unit executes a process of storing the received management information in the edge storage device, and transmits to the player terminal as the first response that the process is successful.
  • the second edge processing unit provisionally receives the latest management information stored in the edge storage device every T 2 for a predetermined time (T 2 is larger than T 1 ). As a result of the aggregation, it is sent to the cloud side server and The cloud processing unit executes a process of storing the management information received as a provisional aggregation result of the continuously received requests in the cloud storage device, and the request continuously received to the effect that the process is successful.
  • the game system according to 1 which is transmitted to the edge-side server as a result of processing based on the provisional aggregation result of. 7. It is a game control method executed by a game system including a cloud side server, an edge side server, and a player terminal.
  • the edge side server is Upon receiving the request sent by the player terminal, The process based on the request is executed, and the result of the process based on the request is transmitted to the player terminal as the first response to the request. At regular intervals, the aggregation result that aggregates the results of the processing based on the request is transmitted to the cloud side server, the result of the processing based on the aggregation result executed by the cloud side server is received, and the aggregation result is used. The result of the processing based on the above is transmitted to the player terminal as a second response to the request, and the result is transmitted to the player terminal.
  • the cloud side server is Upon receiving the aggregation result transmitted by the edge side server, The process based on the aggregation result is executed, and the result of the process based on the aggregation result is transmitted to the edge side server.
  • the player terminal is A game control method in which the request is transmitted, and the first response and the second response are received from the edge-side server in this order by asynchronous I / O for one request. 8.
  • the edge-side server of the game system according to any one of 1 to 6.
  • the cloud-side server of the game system according to any one of 1 to 6. 10.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

エッジ側サーバ（２０）は、プレイヤ端末３０が送信したリクエストを受信すると、リクエストに対する第１のレスポンスをプレイヤ端末（３０）に送信するとともに、一定期間ごとに、リクエストに基づく処理の結果を集約した集約結果をクラウド側サーバ（１０）に送信する。そして、エッジ側サーバ（２０）は、クラウド側サーバ（１０）で実行された当該集約結果に基づく処理の結果を受信し、それを第２のレスポンスとしてプレイヤ端末（３０）に送信する。プレイヤ端末（３０）は、１つのリクエストに対し、非同期Ｉ／Ｏで第１のレスポンス及び第２のレスポンスをこの順にエッジ側サーバ（２０）から受信する。

Description

ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法
　本発明は、ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法に関する。
　次世代のモバイルネットワークである５Ｇでは、単にラストワンマイルの広帯域化に止まらず、インターネットの外側にサーバを設置可能になるというネットワークアーキテクチャの大規模な変更が行われる。関連する技術として、ＭＥＣ（Multi-access Edge Computing）が知られている。従来のクラウドコンピューティングが、クラウド側に大量のサーバを分散配置するという水平方向の分散（Horizontal Distribution）であることとの比較において、このＭＥＣの最大の特徴は、ネットワークの経路上に計算能力を持ったサーバを分散配置するという垂直方向の分散（Vertical Distribution）により、わずか数ミリ秒ほどの低遅延で、エッジサイドのサーバとクライアントとが通信できるようになる点にある。
　関連する技術が、非特許文献１及び２に開示されている。非特許文献１は、５Ｇネットワーク及びＭＥＣについて説明するとともに、ＭＥＣのアプリケーション例としてゲームを提案していている。非特許文献２は、５Ｇネットワークのエッジにある通信プロバイダのデータセンターにエッジサイドのサーバを組み込み、ゲーム、ライブ動画ストリーミング、エッジでの機械学習推論、拡張現実やバーチャルリアリティなどにおいて、低遅延を実現できることを開示している。
　その他、非特許文献３は、ＨＴＴＰのセッションをつないだままにするＣｏｍｅｔに関する内容を開示している。
日本仮想化技術株式会社、"hbstudy#88　５Ｇ＋ＭＥＣ時代のシステム設計"、［online］、２０２０年１月１７日、［２０２０年７月２０日検索］、インターネット＜URL: https://www.slideshare.net/VirtualTech-JP/hbstudy88-5gmec＞ Amazon Web Services, Inc. "AWS Wavelength"、［online］、［２０２０年７月２０日検索］、インターネット＜URL: https://aws.amazon.com/jp/wavelength/＞ "Comet: Low Latency Data for the Browser"、２００６年３月３日、［２０２０年７月２０日検索］、インターネット＜URL: https://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/＞
　非特許文献１及び２はいずれも、ＭＥＣの利用ケースとしてゲームを提案しているものの、その詳細な技術は開示していない。本発明の課題は、従来よりもはるかに高いレベルのゲームサービスのスケーラビリティ（多接続化）とレスポンス性能（低遅延化）を同時に達成することである。
　本発明によれば、
　クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備え、
　前記エッジ側サーバは、
　　前記プレイヤ端末が送信したリクエストを受信するエッジ受信部と、
　　前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信する第１のエッジ処理部と、
　　一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理部と、
を有し、
　前記クラウド側サーバは、
　　前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信部と、
　　前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理部と、
を有し、
　前記プレイヤ端末は、
　　前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信部と、
を有するゲームシステムが提供される。
　また、本発明によれば、
　クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備えるゲームシステムが実行するゲーム制御方法であって、
　前記エッジ側サーバは、
　　前記プレイヤ端末が送信したリクエストを受信し、
　　前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信し、
　　一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信し、
　前記クラウド側サーバは、
　　前記エッジ側サーバが送信した前記集約結果を受信し、
　　前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信し、
　前記プレイヤ端末は、
　　前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信するゲーム制御方法が提供される。
　また、本発明によれば、前記ゲームシステムのエッジ側サーバが提供される。
　また、本発明によれば、前記ゲームシステムのクラウド側サーバが提供される。
　また、本発明によれば、前記ゲームシステムのプレイヤ端末が提供される。
　本発明によれば、従来よりもはるかに高いレベルのゲームサービスのスケーラビリティ（多接続化）とレスポンス性能（低遅延化）を同時に達成することができる。
本実施形態のゲームシステムの全体像を説明するための図である。 本実施形態のゲームシステムの全体像を説明するための図である。 本実施形態のプレイヤ端末の機能ブロックの一例を示す図である。 本実施形態のエッジ側サーバの機能ブロックの一例を示す図である。 本実施形態のクラウド側サーバの機能ブロックの一例を示す図である。 本実施形態のゲームシステムの処理の流れの一例を示すシーケンス図である。 本実施形態のゲームシステムで実現される第１の表示の一例を示す図である。 本実施形態のゲームシステムで実現される第１の表示の一例を示す図である。 本実施形態のゲームシステムで実現される第２の表示の一例を示す図である。 本実施形態の装置のハードウエア構成の一例を示す図である。 本実施形態のゲームシステムの実施例を説明するための図である。 本実施形態のゲームシステムの処理の流れの一例を示すシーケンス図である。
＜第１の実施形態＞
「概要」
　本実施形態は、５Ｇ＋ＭＥＣという新しいエッジコンピューティング・インフラストラクチャの普及を捉えて、ネットワークの経路上に計算能力を持ったサーバを分散配置するという垂直方向の分散に適した、新たなＷｅｂＡＰＩの実装方式を提案するものである。従来のクラウドコンピューティングは、クラウド側に大量のサーバを分散配置するという水平方向の分散であったため、外部に露出するＷｅｂＡＰＩは、呼び出された後に可能な限り速やかにレスポンスを返すという、極めてシンプルなものであった。本実施形態の技術的特徴は、１つのＷｅｂＡＰＩを多数のクライアントが呼び出す時に、エッジ側サーバは暫定的なレスポンスを即座に（数ミリ秒で）クライアントに返しつつ、受信した複数のリクエストを集約してクラウド上の同一ＷｅｂＡＰＩを呼び出し、クラウド側サーバから得られる最終的な演算結果をその後で（数百ミリ秒後に）追加的に返すという、漸進的な応答を行う点にある。このような、集約的なリクエストのハンドリング（Aggregative Request Handling）と漸進的な応答（Progressive Response）により、サービスのスケーラビリティとレスポンス性能を同時に達成する。
　本実施形態によるＷｅｂＡＰＩを呼び出すクライアントは、１つのＷｅｂＡＰＩを非同期処理で読み込むだけで、エッジ側サーバの局所的な情報を反映した即時的なレスポンスをまずは受け取り、その後にクラウド側サーバの大局的かつ確定的なレスポンスを追加的に受け取ることができる。また、クライアントは非同期Ｉ／Ｏで上記２つのレスポンスを受信するので、エッジ側サーバからのレスポンスに応じたエフェクトをアニメーションなどで描画している間に、クラウド側サーバからのレスポンスを受信することができる。このようにエッジ側サーバからの迅速なレスポンスに対応した第１の画面表示を行っている間に、クラウド側サーバからのレスポンスを受信し、上記第１の画面表示に繋げてシームレスに、クラウド側サーバからのレスポンスに対応した第２の画面表示を行うことで、プレイヤから見た時には、あたかもエッジ側サーバからのレスポンスのスピードで、クラウド側サーバからのレスポンスを受け取って画面表示されているように感じられる（すなわち、通信遅延を感じない）、という効果が得られる。
「全体像」
　次に、本実施形態のゲームシステムの全体像を説明する。図１に示すように、ゲームシステムは、クラウド側サーバ１０と、複数のエッジ側サーバ２０と、複数のプレイヤ端末３０とを有する。
　プレイヤ端末３０は、プレイヤが操作するモバイル端末であり、スマートフォン、タブレット端末、パーソナルコンピュータ、ゲーム機、スマートウォッチ、携帯電話等が例示されるが、これらに限定されない。エッジ側サーバ２０は、いわゆるＭＥＣサーバである。クラウド側サーバ１０は、クラウド側に設置されるサーバである。
　図２に示すように、プレイヤ端末３０とクラウド側サーバ１０とは、モバイルネットワーク７０及びインターネット６０経由で通信する。モバイルネットワーク７０は、５Ｇネットワークである。モバイルネットワーク７０は、基地局７１、コア網７２及びインターネットゲートウェイ７３等を含む。図２から明らかなように、本実施形態のインターネット６０は、プレイヤ端末３０が繋がっているモバイルネットワーク７０を含まない概念である。
　図２中に示していないが、エッジ側サーバ２０は、モバイルネットワーク７０内に位置する。そして、プレイヤ端末３０とエッジ側サーバ２０とは、インターネット６０を経由せずに通信する。エッジ側サーバ２０の設置位置は特段制限されないが、通信事業者の基地局７１内やコア網７２の設備内が例示される。
　図１に示すように、複数のプレイヤ端末３０各々は、複数のエッジ側サーバ２０の中のいずれか１つと通信する。これは、複数のプレイヤ端末３０各々は、同時に複数のエッジ側サーバ２０と通信しないことを意味する。例えば、プレイヤ端末３０の位置の変更に応じて、そのプレイヤ端末３０の通信相手となるエッジ側サーバ２０は変更し得る。各プレイヤ端末３０は、例えば、自端末が繋がった基地局７１に設置されているエッジ側サーバ２０と通信する。
「機能構成」
　次に、図３乃至図６を用いて、ゲームシステムの機能構成を説明する。
　図３は、プレイヤ端末３０の機能ブロック図の一例を示す。図示するように、プレイヤ端末３０は、入力部３１と、出力部３２と、処理部３３と、記憶部３４と、端末送受信部３５とを有する。
　これらの機能部により、プレイヤから入力を受付ける機能、入力内容に基づくリクエストをサーバに送信する機能、リクエストに対するレスポンスをサーバから受信する機能、受信したレスポンスに応じた画面表示を行う機能等が実現される。
　図４は、エッジ側サーバ２０の機能ブロック図の一例を示す。図示するように、エッジ側サーバ２０は、エッジ受信部２１と、第１のエッジ処理部２２と、第２のエッジ処理部２３と、記憶部２４とを有する。
　これらの機能部により、自装置（エッジ側サーバ２０）と通信するプレイヤ端末３０が送信したリクエストを受信する機能、プレイヤ端末３０から受信したリクエストに基づく処理の結果を暫定的な処理の結果としてプレイヤ端末３０に返信する機能、プレイヤ端末３０から受信したリクエストに基づく処理の結果を集約した集約結果をクラウド側サーバ１０に送信する機能、集約結果に基づく最終的な処理の結果をクラウド側サーバ１０から受信し、プレイヤ端末３０に返信する機能等が実現される。
　図５は、クラウド側サーバ１０の機能ブロック図の一例を示す。図示するように、クラウド側サーバ１０は、クラウド受信部１１と、クラウド処理部１２と、記憶部１３とを有する。
　これらの機能部により、複数のエッジ側サーバ２０各々から上記集約結果を受信する機能、複数のエッジ側サーバ２０各々から受信した複数の集約結果に基づく最終的な処理の結果を算出する機能、算出した最終的な処理の結果をエッジ側サーバ２０に送信する機能等が実現される。
　図６は、ゲームシステムの処理の流れの一例を示すシーケンス図である。より詳細には、ゲーム進行中の任意のタイミングで複数のプレイヤが各プレイヤ端末３０に所定の操作（例：攻撃）を行ってから、当該操作に応じた画面表示がプレイヤ端末３０においてなされるまでの比較的短い時間の中で行われる処理の流れを示す。以下、処理の流れとともに、図３乃至図５に示す各機能部の機能構成を詳細に説明する。
　前提として、本実施形態のゲームシステムが提供するゲームは、多数のプレイヤが同時に参加し、各プレイヤの操作が他のプレイヤのゲーム進行に影響するものである。例えば、ＭＭＯＲＰＧ（Massively Multiplayer Online Role-Playing Game）のレイドバトル等が例示されるが、これに限定されない。
　図６では、複数の第１のプレイヤ端末３０、第１のエッジ側サーバ２０、複数の第ｍのプレイヤ端末３０、第ｍのエッジ側サーバ２０及びクラウド側サーバ１０が示されている。
　複数の第１のプレイヤ端末３０は、ゲームに参加している複数のプレイヤの中の一部のプレイヤが操作するプレイヤ端末３０である。複数の第１のプレイヤ端末３０は、同じエッジ側サーバ２０（第１のエッジ側サーバ２０）と通信する点で共通する。例えば、複数の第１のプレイヤ端末３０は、同じ基地局に繋がっている。そして、第１のエッジ側サーバ２０は、例えば、複数の第１のプレイヤ端末３０が繋がっている基地局内に設置されている。
　複数の第ｍのプレイヤ端末３０も同様に、ゲームに参加している複数のプレイヤの中の一部のプレイヤが操作するプレイヤ端末３０である。複数の第ｍのプレイヤ端末３０は、同じエッジ側サーバ２０（第ｍのエッジ側サーバ２０）と通信する点で共通する。例えば、複数の第ｍのプレイヤ端末３０は、同じ基地局に繋がっている。そして、第ｍのエッジ側サーバ２０は、例えば、複数の第ｍのプレイヤ端末３０が繋がっている基地局内に設置されている。
　なお、図では、２つのエッジ側サーバ２０と、２組の複数のプレイヤ端末３０が示されているが、これらの数は図示するものに限定されない。
　まず、複数の第１のプレイヤ端末３０の各々は、プレイヤからの入力に基づき生成されたリクエストをサーバに送信する（Ｓ１０１）。複数の第１のプレイヤ端末３０が送信したリクエストは、第１のエッジ側サーバ２０に受信される。
　Ｓ１０１の処理に関連して、入力部３１は、タッチパネル、物理ボタン、マイク、キーボード、マウス等の任意の入力装置を介してプレイヤからの操作を受付ける。例えば、敵キャラクタに攻撃する操作や、防御する操作等を受付ける。処理部３３は、入力された内容を示すリクエスト（攻撃リクエストや防御リクエスト等）を生成する。端末送受信部３５は所定のＷｅｂＡＰＩを呼び出し、生成されたリクエストを送信する。
　第１のエッジ側サーバ２０は、複数の第１のプレイヤ端末３０が送信したリクエストを受信すると（Ｓ１０１）、受信した複数のリクエストに基づく処理を実行し（Ｓ１０２）、リクエストに基づく処理の結果をリクエストに対する第１のレスポンスとして複数の第１のプレイヤ端末３０に送信する（Ｓ１０３）。Ｓ１０１のリクエストの受信はエッジ受信部２１により実現される。Ｓ１０２及びＳ１０３の処理は第１のエッジ処理部２２により実現される。
　第１のエッジ処理部２２は、ゲームに参加している複数のプレイヤの中の一部（複数の第１のプレイヤ端末３０を操作するプレイヤ）に関連するデータを用いて、局所的に一貫性のある処理結果を算出する。
　例えば、第１のエッジ処理部２２は、複数の第１のプレイヤ端末３０各々が送信した攻撃リクエストに基づく結果（敵キャラクタのダメージの有無やダメージ量等）を算出し、その後、その複数の攻撃リクエストの結果を集約した集約結果（その複数の攻撃リクエストで敵キャラクタに与えた総ダメージ量等）を算出する。そして、第１のエッジ処理部２２は、その複数の攻撃リクエストの結果を集約した集約結果（その複数の攻撃リクエストによる敵キャラクタのダメージの有無や敵キャラクタに与えた総ダメージ量等）を、第１のレスポンスとして複数の第１のプレイヤ端末３０に送信する。
　また、第２のエッジ処理部２３は、一定期間ごとに、上記複数の第１のプレイヤ端末３０各々が送信したリクエストに基づく処理の結果を集約した集約結果を、クラウド側サーバ１０に送信する（Ｓ１０５）。
　なお、各エッジ側サーバ２０で算出される上記集約結果は、空間方向に広がる複数のプレイヤの中の一部（各エッジ側サーバ２０と通信するプレイヤ端末３０を操作するプレイヤ）のリクエストの結果を集約した結果である。以降、各エッジ側サーバ２０で算出される当該集約結果を「"並列的に受信したリクエストの暫定的集約結果"」と呼ぶ。
　複数の第１のプレイヤ端末３０は、第１のレスポンスを受信すると（Ｓ１０３）、第１のレスポンスに対応する第１の表示を行う（Ｓ１０４）。すなわち、端末送受信部３５が第１のレスポンスを受信すると、処理部３３は第１のレスポンス及び記憶部３４に記憶されているデータに基づき第１の表示を実現するデータを生成し、その後、出力部３２に第１の表示を実行させる。
　Ｓ１０１で送信されたリクエストが攻撃リクエストである場合、第１の表示の一例として、例えば図７に示すように、敵キャラクタＰにダメージを与えたことを示すエフェクト表示Ｑが考えられる。その他、図８に示すように、エフェクト表示Ｑに加えて、"並列的に受信したリクエストの暫定的集約結果"で示される敵キャラクタＰに与えたダメージ量Ｒを含んでもよい。
　第１の表示（Ｓ１０４）の継続時間は、その後の第２のレスポンスに対応する第２の表示（Ｓ１１６）が開始されるまで継続されるように設計される。
　上述した複数の第１のプレイヤ端末３０及び第１のエッジ側サーバ２０による処理と同様の処理が、同タイミングで、他のプレイヤ端末３０と他のエッジ側サーバ２０とにより実行される（Ｓ１０６乃至Ｓ１１０）。
　なお、複数の第１のプレイヤ端末３０が第１のエッジ側サーバ２０から受信する第１のレスポンスの内容と、複数の第ｍのプレイヤ端末３０が第ｍのエッジ側サーバ２０から受信する第１のレスポンスの内容は異なり得る。このため、第１のプレイヤ端末３０に表示される第１の表示の内容と、第ｍのプレイヤ端末３０に表示される第１の表示の内容は異なり得る。例えば、図８に示す例で示されるダメージ量Ｒは異なる値になり得る。
　一方で、複数の第１のプレイヤ端末３０が第１のエッジ側サーバ２０から受信する第１のレスポンスの内容は同一である。このため、複数の第１のプレイヤ端末３０に表示される第１の表示の内容は同一である。例えば、図８に示す例で示されるダメージ量Ｒは同じ値になる。同様に、複数の第ｍのプレイヤ端末３０が第ｍのエッジ側サーバ２０から受信する第１のレスポンスの内容は同一である。このため、複数の第ｍのプレイヤ端末３０に表示される第１の表示の内容は同一である。例えば、図８に示す例で示されるダメージ量Ｒは同じ値になる。
　その後、クラウド側サーバ１０は、複数のエッジ側サーバ２０各々から受信した"並列的に受信したリクエストの暫定的集約結果"に基づく処理を実行し（Ｓ１１１）、処理の結果を複数のエッジ側サーバ２０に送信する（Ｓ１１２、Ｓ１１３）。複数のエッジ側サーバ２０各々から"並列的に受信したリクエストの暫定的集約結果"を受信する処理は、クラウド受信部１１により実現される。Ｓ１１１乃至Ｓ１１３の処理は、クラウド処理部１２により実現される。
　例えば、クラウド処理部１２は、複数のエッジ側サーバ２０各々から受信した"並列的に受信したリクエストの暫定的集約結果"各々が示す敵キャラクタに与えたダメージ値の合計を算出する。そして、クラウド処理部１２は、当該ダメージ値の合計を、複数のエッジ側サーバ２０に送信する。
　なお、クラウド処理部１２で算出される上記処理結果は、複数のエッジ側サーバ２０から受信した"並列的に受信したリクエストの暫定的集約結果"を集約したものであり、すなわち、空間方向に広がる複数のプレイヤの全てのリクエストの結果を集約した結果である。以降、クラウド処理部１２で算出される当該処理結果を「"並列的に受信したリクエストの最終的集約結果"」と呼ぶ。
　第１のエッジ側サーバ２０は、クラウド側サーバ１０から"並列的に受信したリクエストの最終的集約結果"を受信すると（Ｓ１１２）、その"並列的に受信したリクエストの最終的集約結果"を、Ｓ１０１で受信したリクエストに対する第２のレスポンスとして複数の第１のプレイヤ端末３０に送信する（Ｓ１１４）。Ｓ１１２及びＳ１１４の処理は、第２のエッジ処理部２３により実現される。
　複数の第１のプレイヤ端末３０は、第２のレスポンスを受信すると（Ｓ１１４）、第２のレスポンスに対応する第２の表示を行う（Ｓ１１６）。すなわち、端末送受信部３５が第２のレスポンスを受信すると、処理部３３は第２のレスポンス及び記憶部３４に記憶されているデータに基づき第２の表示を実現するデータを生成し、その後、出力部３２に第２の表示を実行させる。
　なお、上述の通り、第１の表示（Ｓ１０４）の継続時間は、その後の第２のレスポンスに対応する第２の表示（Ｓ１１６）が開始されるまで継続されるように設計される。このため、処理部３３は、第１の表示（Ｓ１０４）が終了する前に第２の表示（Ｓ１１６）を開始させることとなる。すなわち、第１の表示（Ｓ１０４）と第２の表示（Ｓ１１６）はシームレスにつながっている。
　Ｓ１０１で送信されたリクエストが攻撃リクエストである場合、第２の表示の一例として、例えば図９に示すように、敵キャラクタＰにダメージを与えたことを示すエフェクト表示Ｑと、"並列的に受信したリクエストの最終的集約結果"で示される敵キャラクタＰに与えたダメージ量Ｒの表示が考えられる。
　なお、上述した複数の第１のプレイヤ端末３０及び第１のエッジ側サーバ２０による処理と同様の処理が、同タイミングで、他のプレイヤ端末３０と他のエッジ側サーバ２０とにより実行される（Ｓ１１３、Ｓ１１５及びＳ１１７）。
　複数の第１のプレイヤ端末３０が第１のエッジ側サーバ２０から受信する第２のレスポンスの内容と、複数の第ｍのプレイヤ端末３０が第ｍのエッジ側サーバ２０から受信する第２のレスポンスの内容は同一である。このため、第１のプレイヤ端末３０に表示される第２の表示の内容と、第ｍのプレイヤ端末３０に表示される第２の表示の内容は同一である。例えば、図９に示す例で示されるダメージ量Ｒは同じ値になる。
　ところで、プレイヤ端末３０は、リクエストを送信すると（Ｓ１０１、Ｓ１０６）、その１つのリクエストに対し、非同期Ｉ／Ｏで第１のレスポンス及び前記第２のレスポンスをこの順にエッジ側サーバ２０から受信する（Ｓ１０３、Ｓ１１４、Ｓ１０８、Ｓ１１５）。このため、第１のレスポンスを受け取ってから第２のレスポンスを受け取るまでの間に、第１のレスポンスに対応する第１の表示を行うことができる（Ｓ１０４、Ｓ１０９）。
「ハードウエア構成」
　次に、ゲームシステムを実現する各装置（クラウド側サーバ１０、エッジ側サーバ２０及びプレイヤ端末３０）のハードウエア構成を説明する。本実施形態の各装置が備える各機能部は、任意のコンピュータのＣＰＵ（Central Processing Unit）、メモリ、メモリにロードされるプログラム、そのプログラムを格納するハードディスク等の記憶ユニット（あらかじめ装置を出荷する段階から格納されているプログラムのほか、ＣＤ（Compact Disc）等の記憶媒体やインターネット上のサーバ等からダウンロードされたプログラムをも格納できる）、ネットワーク接続用インターフェイスを中心にハードウエアとソフトウエアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
　図１０は、本実施形態の各装置のハードウエア構成を例示するブロック図である。図２に示すように、各装置は、プロセッサ１Ａ、メモリ２Ａ、入出力インターフェイス３Ａ、周辺回路４Ａ、バス５Ａを有する。周辺回路４Ａには、様々なモジュールが含まれる。なお、各装置は周辺回路４Ａを有さなくてもよい。
　なお、クラウド側サーバ１０及びエッジ側サーバ２０は物理的及び／又は論理的に分かれた複数の装置で構成されてもよい。この場合、各装置が上記ハードウエア構成を備えることができる。その他、クラウド側サーバ１０及びエッジ側サーバ２０は、物理的及び論理的に１つの装置で構成されてもよい。
　バス５Ａは、プロセッサ１Ａ、メモリ２Ａ、周辺回路４Ａ及び入出力インターフェイス３Ａが相互にデータを送受信するためのデータ伝送路である。プロセッサ１Ａは、例えばＣＰＵ、ＧＰＵ（Graphics Processing Unit）などの演算処理装置である。メモリ２Ａは、例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリである。入出力インターフェイス３Ａは、入力装置、外部装置、外部サーバ、外部センサ等から情報を取得するためのインターフェイスや、出力装置、外部装置、外部サーバ等に情報を出力するためのインターフェイスなどを含む。入力装置は、例えばキーボード、マウス、マイク等である。出力装置は、例えばディスプレイ、スピーカ、プリンター、メーラ等である。プロセッサ１Ａは、各モジュールに指令を出し、それらの演算結果をもとに演算を行うことができる。
「実施例」
　次に、第１の実施形態の実施例を説明する。本実例の概要を図１１に示す。本実施例は、従来のクラウド上で運用されるＡＰＩを、５ＧのＭＥＣインフラストラクチャを用いて、
（１） クラウド側サーバ１０と同じＡＰＩをエッジ側サーバ２０で公開し、エッジ側サーバ２０でプレイヤ端末３０からのリクエストを集約してからクラウド側サーバ１０へ送信する機能、及び、
（２） エッジ側サーバ２０からプレイヤ端末３０への即時の応答と、クラウド側サーバ１０からプレイヤ端末３０への応答を非同期的に送信する機能、
の２つを実現することにより、高い応答性と高いスケーラビリティを同時に実現するものである。本実施例のゲームシステムを構成するモジュールは、次の６つである。
　［Ｍ１］Game Server on the Edgeは、ＭＥＣインフラストラクチャ上に配置されたゲームサーバであり、エッジ側サーバ２０に該当する。従来の、クラウド上で動作するゲームサーバ（クラウド側サーバ１０）と同じ機能を実装しているものの、使用するデータベースが限定されている点が異なる。［Ｍ１］は、次の２つの機能を実装する。
　［Ｍ１－１］API Implementationは、［Ｍ２］Game Server on the Cloudが備える［Ｍ２－１］API Implementationと同じロジックでリクエストを処理し、ゲーム内のアクションの結果を計算して、クライアント（プレイヤ端末３０）に即座に返却するＡＰＩの実装である。この［Ｍ１－１］は、ゲーム毎、実施形態毎に異なる機能を実装しているものの、外部から受信したリクエストをゲーム内のコマンドとして解釈し、何らかの演算を行なった後にレスポンスを返すという点においては、一般的なＲＥＳＴ　ＡＰＩとして位置付けることができる。
　このモジュールと、クラウド側のモジュールの大きな違いは、［Ｍ１－１］は、モジュール［Ｍ１］が把握している情報、すなわち、特定の地域のプレイヤの情報のみを用いて、一貫性のある結果を算出し、最初のレスポンスを即座に（例：５ｍｓ以内）に返却する点にある。ここで参照する［Ｍ１］に限定された局所的な情報は、［Ｍ３］Small DBに格納されている。また、この時、最初のレスポンスの送信後、［Ｍ１］Game Server on the Edgeとクライアントの接続（セッション）を切断せずに維持しておく。
　［Ｍ１－２］Request Aggregatorは、一定期間ごとに、リクエストを集約（例えば、敵キャラクタのダメージ数を合計するなど）して、対応する［Ｍ２］のＡＰＩを呼び出すモジュールである。ここで、リクエストを集約する例として、複数のプレイヤが、１つの敵キャラクタに与えたダメージの総量を合計する方式などが考えられる。
　［Ｍ２］Game Server on the Cloudは、従来から用いられているゲームサーバであり、クラウド側サーバ１０に該当する。クライアントから呼び出される機能をＷｅｂ　ＡＰＩとして外部に公開している。本発明では、［Ｍ２］は、固定の頻度（高々、［Ｍ１］で設定されている頻度が上限となる）、低い同時接続数（高々、Ｍ１の設置数となる）で、ＡＰＩを実行し、データベース［Ｍ４］を用いて大局的に一貫性のある結果を計算して、［Ｍ１］に返却するモジュールとして位置付けることができる。［Ｍ２］は、少なくとも次の１つのサブモジュールから構成される。
　［Ｍ２－１］API Implementationは、従来と同じクラウド側のゲームサーバのロジックを実装するモジュールである。このモジュールは、ほぼ全ての機能を、［Ｍ１－１］と共有することとなる。
　［Ｍ３］Small DBは、ゲームに参加する複数のプレイヤの中の一部のゲーム状態を保存するためのデータベースである。各［Ｍ１］が備える［Ｍ３］は、各［Ｍ１］と通信するクライアントを操作するプレイヤのゲーム状態を保存する。
　［Ｍ４］Large DBは、ゲームに参加する全てのプレイヤのゲーム状態を保存するデータベースであり、従来から用いられているゲーム用データベースである。
　図１１には、各データの送受信に要する時間の目安を示している。なお、あくまで目安であり、これに限定されない。［Ｍ１］とクライアントとの間の通信時間の目安は、２ｍｓ程度である。［Ｍ１］と［Ｍ２］との間の通信時間の目安は、１００ｍｓ程度である。
　なお、プレイヤ端末３０が５Ｇ以外のネットワーク（３Ｇ、４Ｇ等のモバイルネットワークや、無線ＬＡＮ等）を介してインターネット６０に繋がっている場合には、プレイヤ端末３０が直接（エッジ側サーバ２０を介さないで）クラウド側サーバ１０と通信し、同一のＵＲＬのＡＰＩを呼び出すだけであるため、容易にフォールバックさせることができる。その場合は、単にレスポンスが現在と同じ速度のＡＰＩとして使用することができる。
　次に、本実施例による通信方式の具体例を示す。
（１）クライアントが攻撃のＲＥＳＴ　ＡＰＩを呼び出したとき、１回の攻撃リクエストの結果を、ネットワークのエッジサイド（下流）にある［Ｍ１］の［Ｍ１－１］が３ｍｓ程度の応答速度で暫定的なレスポンスを返す。ただし、伝統的なＣｏｍｅｔ接続のようにレスポンスのコネクションは切断せずに維持しておく。ここで、［Ｍ１］は、同じ携帯基地局（もしくはコアネットワーク設備）につながっているクライアントからのリクエストを受け取るので、ある特定の地域内における総ダメージ量（ローカル・ダメージ量）を計算することができ、その特定地域内の総ダメージ量をレスポンスとして返すことができる。このような合計値の算出を［Ｍ１－２］が担う。
（２）その暫定的なレスポンスに応じたアニメーションをクライアントがＵＩに描画している間（２００ｍｓ以上のアニメーションであることが好ましい）に、［Ｍ１］の［Ｍ１－２］は、上述した特定地域内の総ダメージ量を［Ｍ２］に送信する。［Ｍ２］は、例えば、基地局数分の総ダメージ量（ローカル・ダメージ量）を足し合わせて、全プレイヤ（例えば１００万人程度）が与えたダメージ量の合計（グローバル・ダメージ量）を算出する攻撃処理を実装することができる。
（３）２００ｍｓ程度の経過時間後に、［Ｍ２］は、全プレイヤ（例えば１００万人程度）が与えたダメージ量の合計（グローバル・ダメージ量）をレスポンスとして［Ｍ１］に返す。［Ｍ１］は、このグローバル・ダメージ量を、追加的にクライアントに返し、レスポンスを終了する。
（４）クライアントは、描画中の暫定的なレスポンスに応じたアニメーションをシームレスに更新する形で、グローバル・ダメージ量のエフェクトを描画する（例えば、図７から図９にシームレスに変更、図８から図９にシームレスに変更等）。このように、クライアントからは単一のＡＰＩからのレスポンスを非同期的に読むだけで、例えば３ｍｓ程度で５Ｇ固有の局所的な演算結果を受け取ることができ、その２００ｍｓ程度後に、従来のクラウドで計算される大局的な演算結果を受け取ることができる。
　次に、本実施例におけるクライアント側でのレスポンスのパース方法の一例を示す。
　一般的に、ＨＴＭＬ５やネイティブアプリ等のリッチクライアントが利用するＷｅｂ　ＡＰＩの戻り値は、ＪＳＯＮ等の木構造を有するデータが採用されることが多い。このＪＳＯＮをクライアントで読み込む（パースする）時に、ＪＳＯＮデータ全体をメモリ上に読み込んで、その木構造をプログラミング言語のデータ構造（オブジェクト）として一気に再現する方式がよく採用されている。しかしながら、本実施例は、ＪＳＯＮ等のデータを、例えば５ｍｓ後に先頭部分だけを返し、例えば１００ｍｓ後にその後の全体を返す、というような時間差のある漸進的なレスポンス返却を行うため、従来の標準的なＪＳＯＮのパース方法では、本実施例のメリットである低遅延を享受することができない。
　そこで、ＪＳＯＮのパース方法として、ＪＳＯＮ文書を木構造として扱うのではなく、一連のイベントとして表現するイベント駆動型のＡＰＩを使用することができる。ＸＭＬパーサの分野で、このようなイベント駆動型のＡＰＩがＳＡＸ（Simple API for XML）と呼ばれており、ＪＳＯＮパーサも、「SAX-like API」としてイベント駆動型のＡＰＩを提供している。例えば、JavaScriptではstream-json (https://github.com/uhop/stream-json)、C++ではRapidJSON (http://rapidjson.org)が、SAX-like APIをサポートしている。このSAX-like APIでは、ＪＳＯＮの階層構造の開始と終了、属性の定義などがイベントとして逐次的にアプリケーションに通知されるため、断片的なＪＳＯＮを直ちにパースすることができる。
「作用効果」
　本実施形態は、５Ｇ＋ＭＥＣという新しいエッジコンピューティング・インフラストラクチャの普及を捉えて、ネットワークの経路上に計算能力を持ったサーバが分散配置されるという垂直方向の分散（Vertical Distribution）に適した、新たなＷｅｂ　ＡＰＩの実装方式を初めて提案するものであり、５Ｇ時代のＡＰＩ実装方法のデファクトスタンダードになりうるものである。本実施形態の作用効果として、次の３点が挙げられる。
－超低遅延－
　本実施形態は、モバイルネットワーク上のＭＥＣインフラストラクチャから直ちにプレイヤ端末３０にレスポンスを返すことができる。このため、レスポンスの返信に要する時間が例えば１０ｍｓ程度となり、クラウド側からレスポンスを返す場合に要する時間（100msから200ms程度）に比べて著しく低下させることができる。これは、６０ＦＰＳのゲームにおいても毎フレーム（約１６ｍｓ）の頻度でサーバ側の機能を使用することができることを意味しており、従来のゲームと全く異なる低遅延性を実現することができる。
－スケーラビリティ－
　本実施形態は、１つのＷｅｂ　ＡＰＩを例えば数百万のプレイヤ端末３０が呼び出す時、エッジ側サーバ２０は暫定的なレスポンスを即座に（数ミリ秒で）プレイヤ端末３０に返しつつ、受信した複数のリクエストを集約（Aggregate）してクラウド側サーバ１０上の同一Ｗｅｂ　ＡＰＩを呼び出す。したがって、クラウド側サーバ１０においては、同時接続数を、高々、エッジ側サーバ２０の数だけに抑えることができる。
－互換性－
　本実施形態は、低遅延の第１のレスポンスと通常の遅延の第２のレスポンスを組み合わせたＡＰＩにより、クラウド側サーバ１０のＡＰＩを大きく変更することなく、シンプルなＲＥＳＴ　ＡＰＩにしたまま、プレイヤ端末３０を操作するプレイヤからのネットワークアクセスの見た目の遅延を１０ミリ秒未満に抑えたゲームを構築することができる。さらに、４Ｇから５Ｇへの移行期や固定回線と５Ｇが混在する環境においては、５Ｇ以外の接続を、従来のクラウド側のロードバランサで負荷分散させることができるため、スムースに本実施形態を既存のシステムへ追加的に導入することができる。
＜第２の実施形態＞
「構成」
　第１の実施形態のエッジ側サーバ２０は、空間方向に広がる複数の一部のプレイヤのリクエストの結果を集約した"並列的に受信したリクエストの暫定的集約結果"を算出した。これに対し、本実施形態のエッジ側サーバ２０は、１人のプレイヤが時間差で送信した複数のリクエストの結果を集約した"連続的に受信したリクエストの暫定的集約結果"を算出する。以下、詳細に説明する。
　エッジ側サーバ２０のエッジ受信部２１は、１つのプレイヤ端末３０が時間差で送信した複数のリクエストを受信する。第１のエッジ処理部２２は、リクエストに基づく処理を実行し、リクエストに基づく処理の結果をリクエストに対する第１のレスポンスとしてそのプレイヤ端末３０に送信する。第２のエッジ処理部２３は、そのプレイヤ端末３０が時間差で送信した複数のリクエストに基づく処理の結果を集約した"連続的に受信したリクエストの暫定的集約結果"を算出し、"連続的に受信したリクエストの暫定的集約結果"をクラウド側サーバ１０に送信する。
　クラウド側サーバ１０のクラウド処理部１２は、"連続的に受信したリクエストの暫定的集約結果"に基づく処理を実行し、"連続的に受信したリクエストの暫定的集約結果"に基づく処理の結果をエッジ側サーバ２０に送信する。エッジ側サーバ２０の第２のエッジ処理部２３は、"連続的に受信したリクエストの暫定的集約結果"に基づく処理の結果をクラウド側サーバ１０から受信すると、その結果を上記リクエストに対する第２のレスポンスとしてそのプレイヤ端末３０に送信する。
　図１２に当該処理の流れの一例を示す。プレイヤ端末３０がエッジ側サーバ２０にリクエストを送信すると（Ｓ２００）、エッジ側サーバ２０はそのリクエストに基づく処理を実行し（Ｓ２０１）、処理の結果をそのリクエストに対する第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０２）。
　その後、プレイヤ端末３０がエッジ側サーバ２０にリクエストを送信すると（Ｓ２０３）、エッジ側サーバ２０はそのリクエストに基づく処理を実行し（Ｓ２０４）、処理の結果をそのリクエストに対する第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０５）。
　その後、プレイヤ端末３０がエッジ側サーバ２０にリクエストを送信すると（Ｓ２０６）、エッジ側サーバ２０はそのリクエストに基づく処理を実行し（Ｓ２０７）、処理の結果をそのリクエストに対する第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０８）。
　なお、ここではリクエストと第１のレスポンスの送受信を３回繰り返しているが、その回数はこれに限定されない。
　そして、予め定められた所定のタイミングになると、第２のエッジ処理部２３は、それまでに受信したリクエスト（Ｓ２００、Ｓ２０３、Ｓ２０６）に対する処理の結果を集約した"連続的に受信したリクエストの暫定的集約結果"を、クラウド側サーバ１０に送信する（Ｓ２０９）。
　クラウド側サーバ１０は、"連続的に受信したリクエストの暫定的集約結果"に基づく処理を実行し（Ｓ２１０）、処理の結果をエッジ側サーバ２０に送信する（Ｓ２０９）。エッジ側サーバ２０は、クラウド側サーバ１０から受信した処理の結果を、リクエスト（Ｓ２００、Ｓ２０３、Ｓ２０６）に対する第２のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２１２）。
　本実施形態でも、プレイヤ端末３０は、リクエストに対する第１のレスポンス及び第２のレスポンスを非同期Ｉ／Ｏで受信する。このため、プレイヤ端末３０は、第１のレスポンスを受信してから第２のレスポンスを受信するまでの間に、他の処理を行うことができる。
　なお、プレイヤ端末３０から送信されるリクエストの詳細は限定されないが、一例として、プレイヤ端末３０が管理している管理情報（プレイヤキャラクタの状態情報等）をサーバ側で保存する同期リクエストが挙げられる。
　この場合、プレイヤ端末３０及びエッジ側サーバ２０は、所定時間Ｔ１毎に、最新の管理情報及び同期リクエストを送受信することができる（Ｓ２００、Ｓ２０３、Ｓ２０６）。
　そして、エッジ側サーバ２０の第１のエッジ処理部２２は、受信された管理情報をエッジ記憶装置（記憶部２４）に記憶させる処理を実行し（Ｓ２０１、Ｓ２０４、Ｓ２０７）、処理に成功した旨を第１のレスポンスとしてプレイヤ端末３０に送信する（Ｓ２０２、Ｓ２０５、Ｓ２０８）。
　エッジ側サーバ２０の第２のエッジ処理部２３は、所定時間Ｔ２毎に（Ｔ２はＴ１より大）、エッジ記憶装置（記憶部２４）に記憶されている最新の管理情報を、"連続的に受信したリクエストの暫定的集約結果"としてクラウド側サーバ１０に送信する（Ｓ２０９）。
　クラウド側サーバ１０のクラウド処理部１２は、"連続的に受信したリクエストの暫定的集約結果"として受信された管理情報をクラウド記憶装置（記憶部１３）に記憶させる処理を実行し（Ｓ２１０）、処理に成功した旨を"連続的に受信したリクエストの暫定的集約結果"に基づく処理の結果としてエッジ側サーバ２０に送信する（Ｓ２１１）。
　なお、本実施形態のゲームシステムは、本実施形態で説明した時間方向の集約処理に加えて、第１の実施形態で説明した空間方向の集約処理を実行可能に構成されてもよい。
　本実施形態のゲームシステムのその他の構成は、第１の実施形態と同様である。
「実施例」
　次に、第２の実施形態の実施例を説明する。本実例の概要は図１１で示される。本実施例では、ネイティブのゲームアプリにおいて、例えば毎フレームの頻度でデータをサーバ側に保存・同期する例を示す。
　従来のネイティブアプリでは、クラウドサーバとの通信は比較的遅延が大きい処理であったため、ステージの区切りやバトルの前後などの、所定の遅延を挟んでも支障の無いタイミングで通信を行なっていた。しかしながら、このような実装方法では、ゲームの途中に通信が一時的に切断した場合などに、意図的な不正行為（チート）による切断か、それとも、止むを得ない通信切断かを区別することが難しいため、一律で無効試合にする等の処理が取られていた。これは、不正行為を行っていないプレイヤにとってはストレスとなる処理であるため、通信状態が安定した場所でゲームを楽しむことが必須となっていた。
　本実施例を適用すると、バトル等のゲーム中であっても高頻度（例えば、１秒間に複数回）にゲームの状態をサーバ側に保存（同期）することができるため、通信の切断が起きてもクライアント側を再起動せずにサーバから状態データを読み取り復帰させるようなクラウド・ネイティブな運用が可能になる。
　このようなリアルタイムセーブでは、図１１の［Ｍ１－１］と［Ｍ２－１］が、従来のゲームサーバと同じゲームデータの検証・保存ＡＰＩを実装し、さらに、［Ｍ１－２］として、複数回のデータ保存を行ったのちの最新のバージョンのデータのみを［Ｍ２］に送信する処理を実装することにより、低遅延で、かつ、クラウド側の負荷が大幅に低下されたセーブ機能を実現することができる。
「作用効果」
　以上説明した本実施形態のゲームシステムによれば、第１の実施形態と同様の作用効果が実現される。また、エッジ側サーバ２０は、１人のプレイヤが時間差で送信した複数のリクエストの結果を集約した"連続的に受信したリクエストの暫定的集約結果"を算出し、クラウド側サーバ１０に送信することができる。このため、エッジ側サーバ２０の利用場面が広がり、活用の幅が広がる。
　以下、参考形態の例を付記する。
１．　クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備え、
　前記エッジ側サーバは、
　　前記プレイヤ端末が送信したリクエストを受信するエッジ受信部と、
　　前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信する第１のエッジ処理部と、
　　一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理部と、
を有し、
　前記クラウド側サーバは、
　　前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信部と、
　　前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理部と、
を有し、
　前記プレイヤ端末は、
　　前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信部と、
を有するゲームシステム。
２．　前記プレイヤ端末は、
　　前記第１のレスポンスを受信すると前記第１のレスポンスに対応する第１の表示を行い、前記第２のレスポンスを受信すると前記第２のレスポンスに対応する第２の表示を行い、
　　前記第１の表示が終了する前に前記第２の表示を開始する１に記載のゲームシステム。
３．　複数の前記プレイヤ端末各々は、複数の前記エッジ側サーバの中のいずれか１つと通信し、
　前記エッジ受信部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストを受信し、
　前記第２のエッジ処理部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストに基づく処理の結果を集約した並列的に受信したリクエストの暫定的集約結果を算出し、前記並列的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
　前記クラウド受信部は、複数の前記エッジ側サーバ各々から、前記並列的に受信したリクエストの暫定的集約結果を受信し、
　前記クラウド処理部は、複数の前記並列的に受信したリクエストの暫定的集約結果を集約して並列的に受信したリクエストの最終的集約結果を算出し、前記並列的に受信したリクエストの最終的集約結果を複数の前記エッジ側サーバに送信し、
　前記第２のエッジ処理部は、受信した前記並列的に受信したリクエストの最終的集約結果を前記第２のレスポンスとして自エッジ側サーバと通信する複数の前記プレイヤ端末に送信する１又は２に記載のゲームシステム。
４．　前記リクエストは、敵キャラクタに対する攻撃内容を示す攻撃リクエストであり、
　前記エッジ側サーバ各々が算出する前記並列的に受信したリクエストの暫定的集約結果は、前記エッジ側サーバ各々と通信する複数の前記プレイヤ端末が送信した複数の前記攻撃リクエストに基づき算出された前記敵キャラクタに与えたダメージ値であり、
　前記並列的に受信したリクエストの最終的集約結果は、前記エッジ側サーバ各々が算出した前記並列的に受信したリクエストの暫定的集約結果各々が示す前記敵キャラクタに与えたダメージ値の合計である３に記載のゲームシステム。
５．　前記エッジ受信部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストを受信し、
　前記第２のエッジ処理部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストに基づく処理の結果を集約した連続的に受信したリクエストの暫定的集約結果を算出し、前記連続的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
　前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果に基づく処理を実行し、前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果を前記エッジ側サーバに送信する１又は２に記載のゲームシステム。
６．　前記リクエストは、前記プレイヤ端末が管理している管理情報をサーバ側で保存する同期リクエストであり、
　前記エッジ受信部は、所定時間Ｔ１毎に最新の前記管理情報及び前記同期リクエストを受信し、
　前記第１のエッジ処理部は、受信された前記管理情報をエッジ記憶装置に記憶させる処理を実行し、処理に成功した旨を前記第１のレスポンスとして前記プレイヤ端末に送信し、
　前記第２のエッジ処理部は、所定時間Ｔ２毎に（Ｔ２はＴ１より大）、前記エッジ記憶装置に記憶されている最新の前記管理情報を、前記連続的に受信したリクエストの暫定的集約結果として前記クラウド側サーバに送信し、
　前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果として受信された前記管理情報をクラウド記憶装置に記憶させる処理を実行し、処理に成功した旨を前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果として前記エッジ側サーバに送信する１に記載のゲームシステム。
７．　クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備えるゲームシステムが実行するゲーム制御方法であって、
　前記エッジ側サーバは、
　　前記プレイヤ端末が送信したリクエストを受信し、
　　前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信し、
　　一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信し、
　前記クラウド側サーバは、
　　前記エッジ側サーバが送信した前記集約結果を受信し、
　　前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信し、
　前記プレイヤ端末は、
　　前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信するゲーム制御方法。
８．　１から６のいずれかに記載のゲームシステムのエッジ側サーバ。
９．　１から６のいずれかに記載のゲームシステムのクラウド側サーバ。
１０．　１から６のいずれかに記載のゲームシステムのプレイヤ端末。
　この出願は、２０２０年１０月２１日に出願された日本出願特願２０２０－１７６４６３号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１Ａ　　プロセッサ
　２Ａ　　メモリ
　３Ａ　　入出力Ｉ／Ｆ
　４Ａ　　周辺回路
　５Ａ　　バス
　１０　　クラウド側サーバ
　１１　　クラウド受信部
　１２　　クラウド処理部
　１３　　記憶部
　２０　　エッジ側サーバ
　２１　　エッジ受信部
　２２　　第１のエッジ処理部
　２３　　第２のエッジ処理部
　２４　　記憶部
　３０　　プレイヤ端末
　３１　　入力部
　３２　　出力部
　３３　　処理部
　３４　　記憶部
　３５　　端末送受信部
　６０　　インターネット
　７０　　モバイルネットワーク
　７１　　基地局
　７２　　コア網
　７３　　インターネットゲートウェイ

Claims (10)

  1. 　クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備え、
    　前記エッジ側サーバは、
    　　前記プレイヤ端末が送信したリクエストを受信するエッジ受信部と、
    　　前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信する第１のエッジ処理部と、
    　　一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信する第２のエッジ処理部と、
    を有し、
    　前記クラウド側サーバは、
    　　前記エッジ側サーバが送信した前記集約結果を受信するクラウド受信部と、
    　　前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信するクラウド処理部と、
    を有し、
    　前記プレイヤ端末は、
    　　前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信する端末送受信部と、
    を有するゲームシステム。
  2. 　前記プレイヤ端末は、
    　　前記第１のレスポンスを受信すると前記第１のレスポンスに対応する第１の表示を行い、前記第２のレスポンスを受信すると前記第２のレスポンスに対応する第２の表示を行い、
    　　前記第１の表示が終了する前に前記第２の表示を開始する請求項１に記載のゲームシステム。
  3. 　複数の前記プレイヤ端末各々は、複数の前記エッジ側サーバの中のいずれか１つと通信し、
    　前記エッジ受信部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストを受信し、
    　前記第２のエッジ処理部は、自エッジ側サーバと通信する複数の前記プレイヤ端末各々が送信した複数の前記リクエストに基づく処理の結果を集約した並列的に受信したリクエストの暫定的集約結果を算出し、前記並列的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
    　前記クラウド受信部は、複数の前記エッジ側サーバ各々から、前記並列的に受信したリクエストの暫定的集約結果を受信し、
    　前記クラウド処理部は、複数の前記並列的に受信したリクエストの暫定的集約結果を集約して並列的に受信したリクエストの最終的集約結果を算出し、前記並列的に受信したリクエストの最終的集約結果を複数の前記エッジ側サーバに送信し、
    　前記第２のエッジ処理部は、受信した前記並列的に受信したリクエストの最終的集約結果を前記第２のレスポンスとして自エッジ側サーバと通信する複数の前記プレイヤ端末に送信する請求項１又は２に記載のゲームシステム。
  4. 　前記リクエストは、敵キャラクタに対する攻撃内容を示す攻撃リクエストであり、
    　前記エッジ側サーバ各々が算出する前記並列的に受信したリクエストの暫定的集約結果は、前記エッジ側サーバ各々と通信する複数の前記プレイヤ端末が送信した複数の前記攻撃リクエストに基づき算出された前記敵キャラクタに与えたダメージ値であり、
    　前記並列的に受信したリクエストの最終的集約結果は、前記エッジ側サーバ各々が算出した前記並列的に受信したリクエストの暫定的集約結果各々が示す前記敵キャラクタに与えたダメージ値の合計である請求項３に記載のゲームシステム。
  5. 　前記エッジ受信部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストを受信し、
    　前記第２のエッジ処理部は、１つの前記プレイヤ端末が時間差で送信した複数の前記リクエストに基づく処理の結果を集約した連続的に受信したリクエストの暫定的集約結果を算出し、前記連続的に受信したリクエストの暫定的集約結果を前記クラウド側サーバに送信し、
    　前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果に基づく処理を実行し、前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果を前記エッジ側サーバに送信する請求項１又は２に記載のゲームシステム。
  6. 　前記リクエストは、前記プレイヤ端末が管理している管理情報をサーバ側で保存する同期リクエストであり、
    　前記エッジ受信部は、所定時間Ｔ１毎に最新の前記管理情報及び前記同期リクエストを受信し、
    　前記第１のエッジ処理部は、受信された前記管理情報をエッジ記憶装置に記憶させる処理を実行し、処理に成功した旨を前記第１のレスポンスとして前記プレイヤ端末に送信し、
    　前記第２のエッジ処理部は、所定時間Ｔ２毎に（Ｔ２はＴ１より大）、前記エッジ記憶装置に記憶されている最新の前記管理情報を、前記連続的に受信したリクエストの暫定的集約結果として前記クラウド側サーバに送信し、
    　前記クラウド処理部は、前記連続的に受信したリクエストの暫定的集約結果として受信された前記管理情報をクラウド記憶装置に記憶させる処理を実行し、処理に成功した旨を前記連続的に受信したリクエストの暫定的集約結果に基づく処理の結果として前記エッジ側サーバに送信する請求項１に記載のゲームシステム。
  7. 　クラウド側サーバと、エッジ側サーバと、プレイヤ端末とを備えるゲームシステムが実行するゲーム制御方法であって、
    　前記エッジ側サーバは、
    　　前記プレイヤ端末が送信したリクエストを受信し、
    　　前記リクエストに基づく処理を実行し、前記リクエストに基づく処理の結果を前記リクエストに対する第１のレスポンスとして前記プレイヤ端末に送信し、
    　　一定期間ごとに、前記リクエストに基づく処理の結果を集約した集約結果を前記クラウド側サーバに送信し、前記クラウド側サーバで実行された前記集約結果に基づく処理の結果を受信し、前記集約結果に基づく処理の結果を前記リクエストに対する第２のレスポンスとして前記プレイヤ端末に送信し、
    　前記クラウド側サーバは、
    　　前記エッジ側サーバが送信した前記集約結果を受信し、
    　　前記集約結果に基づく処理を実行し、前記集約結果に基づく処理の結果を前記エッジ側サーバに送信し、
    　前記プレイヤ端末は、
    　　前記リクエストを送信し、１つの前記リクエストに対し、非同期Ｉ／Ｏで前記第１のレスポンス及び前記第２のレスポンスをこの順に前記エッジ側サーバから受信するゲーム制御方法。
  8. 　請求項１から６のいずれか１項に記載のゲームシステムのエッジ側サーバ。
  9. 　請求項１から６のいずれか１項に記載のゲームシステムのクラウド側サーバ。
  10. 　請求項１から６のいずれか１項に記載のゲームシステムのプレイヤ端末。
PCT/JP2021/038229 2020-10-21 2021-10-15 ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法 WO2022085585A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180085978.0A CN116670648A (zh) 2020-10-21 2021-10-15 游戏***、边缘侧服务器、云侧服务器、游戏终端和游戏控制方法
US18/302,550 US20230256334A1 (en) 2020-10-21 2023-04-18 Game system, edge-side server, cloud-side server, game terminal, and game control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-176463 2020-10-21
JP2020176463A JP6913809B1 (ja) 2020-10-21 2020-10-21 ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/302,550 Continuation US20230256334A1 (en) 2020-10-21 2023-04-18 Game system, edge-side server, cloud-side server, game terminal, and game control method

Publications (1)

Publication Number Publication Date
WO2022085585A1 true WO2022085585A1 (ja) 2022-04-28

Family

ID=77057570

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/038229 WO2022085585A1 (ja) 2020-10-21 2021-10-15 ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法

Country Status (4)

Country Link
US (1) US20230256334A1 (ja)
JP (1) JP6913809B1 (ja)
CN (1) CN116670648A (ja)
WO (1) WO2022085585A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200269132A1 (en) * 2019-02-25 2020-08-27 Niantic, Inc. Augmented Reality Mobile Edge Computing

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200269132A1 (en) * 2019-02-25 2020-08-27 Niantic, Inc. Augmented Reality Mobile Edge Computing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MASAKAZU HONDA, @ROKUZOUHONDA: "Game streaming will (maybe) be a symbol of 5G: Masakazu Honda's Weekly 5G Summary", JP, pages 1 - 7, XP009536345, Retrieved from the Internet <URL:https://web.archive.org/web/20201022090052/https://japanese.engadget.com/jp-2019-03-23-5g-5g.html> [retrieved on 20210216] *

Also Published As

Publication number Publication date
JP6913809B1 (ja) 2021-08-04
CN116670648A (zh) 2023-08-29
US20230256334A1 (en) 2023-08-17
JP2022067727A (ja) 2022-05-09

Similar Documents

Publication Publication Date Title
US11717749B2 (en) Cloud gaming device handover
Laghari et al. Quality of experience (QoE) in cloud gaming models: A review
JP6982684B2 (ja) ビデオゲームのゲームプレイをスケジューリングする方法及びシステム
WO2022022281A1 (zh) 一种游戏数据处理方法、装置、计算机及可读存储介质
WO2018003174A1 (ja) 情報処理装置の制御方法、情報処理装置及びプログラム
US20230321532A1 (en) Game picture display methods and apparatuses, device and storage medium
US9814979B2 (en) Data provision system, provision apparatus, execution apparatus, control method, and recording medium
CN109889576B (zh) 一种基于博弈论的移动云游戏资源优化方法
CN102016821B (zh) 限制对共享媒体内容的访问
US11524229B2 (en) Methods, systems, and media for enhancing multiplayer game sessions with asymmetric information
WO2002092177A2 (en) Method and arrangement for providing an interactive game including three-dimensional graphics
CN112169327A (zh) 一种云游戏的控制方法以及相关装置
US11925861B2 (en) System for multiview games experience
Süselbeck et al. Peer-to-peer support for low-latency massively multiplayer online games in the cloud
WO2022085585A1 (ja) ゲームシステム、エッジ側サーバ、クラウド側サーバ、ゲーム端末及びゲーム制御方法
CN111111182B (zh) 一种游戏视角确定方法、装置和服务器
Anand et al. Gamelets—multiplayer mobile games with distributed micro-clouds
KR20230034182A (ko) 온라인 게임들에서의 관전자 시스템
JP2018200675A (ja) データ生成装置およびアプリケーション実行装置
CN105245558B (zh) 支持虚拟在线的应用程序运行方法、***、服务器
EP2861313B1 (en) Processing system, information processing apparatus, control method, program and storage medium
CN116363286A (zh) 一种游戏处理的方法、设备、存储介质及程序产品
JP6314274B1 (ja) データ生成装置およびアプリケーション実行装置
CN116650942A (zh) 业务处理方法、装置、计算机设备和业务处理***
JP2018033706A (ja) プログラム、及びシステム

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: 21882726

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 202180085978.0

Country of ref document: CN

122 Ep: pct application non-entry in european phase

Ref document number: 21882726

Country of ref document: EP

Kind code of ref document: A1