Method for allocating resources for an online game

Abstract

Methods for allocating resources for online games are described. One method includes executing an online game for a plurality of users, each user being provided access to a virtual location of a game world, one or more users being present in the virtual location; identifying one or more virtual locations of the game world; allocating one or more computing resources to each virtual location identified in the game world for processing game interactions provided by one or more users therein, wherein an amount of computing resources allocated to each virtual location is based on a processing load required to process the game interactions; monitoring the processing load of each of the one or more computing resources allocated to each virtual location identified in the game world; and dynamically adjusting the amount of computing resources allocated to each virtual location in order to process the processing load of each virtual location.

Description

[0001] This application is a divisional application of Chinese invention patent application No. 201980089637.3, filed on November 18, 2019. Technical Field

[0002] This disclosure relates to allocating resources for online games, and more specifically to a deterministic method of allocating computations when a large number of players enter a particular virtual game area. Background Technology

[0003] Online games are gaining popularity in the gaming world. Traditionally, games use client-server or peer-to-peer setups to execute gameplay. In a typical client-server setup, the server needs to provide sufficient computing power to handle the physical, audio, and transmission of game data generated during gameplay. With the increasing popularity of massively multiplayer online games (MMOs), traditional client-server setups cannot handle the processing load (i.e., game data) generated by inputs provided by multiple users (e.g., thousands of players) during gameplay. In MMOs, during gameplay, each player needs to be provided with their own perception of the game world. For example, the first player might approach a challenge from the right side of the game world, the second player from the left, and the third player from the front. Each of these players can provide input to overcome that challenge. The server needs to determine which player's input needs to be processed first and generate the overall game state. The server also needs to be able to generate different game data for each player to provide their own perception of the game world. Server resources are limited and can only support a certain number of players (i.e., users). When the number of players exceeds this limit, server resources may become overstretched, resulting in suboptimal gameplay quality. In a peer-to-peer setup, the processing load on the network used to exchange game data is greater, and this processing is distributed among the peers. Furthermore, one peer acts as a "server" and bears additional processing load, which increases the resource pressure on that peer.

[0004] In a typical MMO game, hundreds or even thousands of players may be available to play online at any given time. To provide the best gaming experience, multiple servers can be used to support hundreds or thousands of players, and players can be organized into logical groups, each assigned to a server domain. However, in the client-server setup described above, server domains have a limit on the number of users (i.e., game characters). When a new user requests to play in a specific server domain, if the number of users in that domain has reached the server limit, the new user may be placed in the server domain's queue, causing unnecessary delays in starting the game. Furthermore, if a new user requests to join a specific server domain located in a different time zone, they can be assigned to that specific server domain based on their current geographic location, even if it's not the optimal option. This is especially problematic when a new user wants to play online with their friends and wants to start at a certain level. Assigning a new user to a specific server domain will result in a delay, potentially leading to a poor user experience.

[0005] It is against this backdrop that the proposed implementation plan was developed. Summary of the Invention

[0006] This disclosure relates to systems and methods for supplying resources for online games. A distributed game engine is used to execute the online game to provide video frames of game data, including a view of the game world, for rendering on a client device of a user playing or watching the online game. The distributed game engine includes multiple components to track the online game context (i.e., game state), the location of each user within the online game, and proactively supply necessary computing / computing resources to assist in processing user-provided user input to generate game data for each user in the online game. The components of the distributed game engine are configured to identify multiple virtual locations within the online game, identify the processing load allocated to one or more computing devices (i.e., computing units) of a user present in each virtual location in the online game, and proactively increase or decrease the computing allocated to each virtual location to manage the processing load in each virtual location.

[0007] First, the distributed game engine can initially allocate computations to users identified in each virtual location within the online game and monitor the processing load on the allocated computations associated with the online game. The processing load may be affected by users moving in or out of defined areas within the virtual locations of the online game. Based on this monitoring, the distributed game engine can adjust the computations allocated to each virtual location in the online game so that the allocated computations are configured to handle the processing load at the corresponding virtual location. Adjustments to computations can include allocating additional computations to handle an increase in processing load at a particular virtual location, or deallocating one or more computations allocated to a particular virtual location based on a decrease in processing load. To add additional computations, the distributed game engine monitors the number of users within the area of ​​a particular virtual location and determines whether the number of users exceeds a predefined limit for the computations allocated to that particular virtual location. When the number of users in the area exceeds the predefined number for the allocated computations, the distributed game engine can subdivide the area within the particular virtual location into multiple sub-areas and allocate additional computations to handle user inputs that define the game interactions provided by the users in the areas. In some implementations, different computations can be allocated to handle user inputs in each sub-area. In some implementations, computations allocated to a region or a specific virtual location can be distributed to one of the sub-regions defined within that region. In another implementation, computations allocated to a specific virtual location or region can be used to coordinate the processing of game interactions handled by different computations allocated to various sub-regions generated within the region of that specific virtual location.

[0008] Alternatively, the distributed game engine can optimize the computational load allocated to the online game by offloading some of the computations allocated to it. To offload some computations, the distributed game engine can first allocate its computations for processing game interactions generated in the first virtual location, handling the game interactions in both the first and second virtual locations (i.e., processing load), and offload the second computations allocated for processing game interactions in the second virtual location. In this case, the computations allocated to the second virtual location are offloaded after synchronizing the game data generated by processing game interactions between the first and second computations. The distributed game engine continues to monitor the number of users in each region of each virtual location and proactively manages the computations allocated to the online game.

[0009] In one implementation, a method for managing processing resources for an online game that presents a game world is disclosed. The method includes executing the online game for one or more users. Providing each of the one or more users with access to one or more virtual locations in the game world. Allocating computations to the one or more users to handle game interactions within the game world. When the number of users accessing an area within a virtual location identified in the online game exceeds a predefined limit on the computations allocated to the users, the area is divided into multiple sub-areas. Additional computations are allocated to the areas such that the computations and additional computations are configured to handle game interactions within the game world for users in each of the sub-areas.

[0010] In some implementations, the number of sub-regions created within a region is based on the number of users existing in the region. Each sub-region created within a region includes at least one user from the region.

[0011] In some implementations, the game interactions received within a region correspond to user input provided by one or more users within the region. These users are either players or spectators.

[0012] In some implementations, different computations are assigned to each sub-region created within the region to process user input representing game interactions for said sub-region.

[0013] In some implementations, game interaction processing involves determining the optimal processing order for game interactions in each sub-region based on the relative context of the game interactions provided by each user. Game interactions are then processed in each sub-region according to this optimal processing order, which determines the order in which game video data is provided to each user at their client device for rendering.

[0014] In some implementations, the optimal processing order for each user's game video data is determined based on priority, importance, criticality, need, or any combination of two or more of these factors.

[0015] In some implementations, the optimal processing order is based on the timing of game interactions that occur during gameplay.

[0016] In some implementations, user movement within each sub-region of a region is tracked to determine the number of users accessing the region. User movement is used to adjust the calculations allocated to the region.

[0017] In some implementations, when the number of users in a region falls below a predefined limit for computation based on the movement of one or more users, adjusting the computation involves cancelling additional computation allocated to the region.

[0018] In some implementations, the computation allocated to a region is adjusted by detecting one or more users leaving the region, and in response, canceling the computation or additional computation allocated to that region. Cancellation is performed after successful synchronization of game-related data between the computation and additional computation in the game world. Game-related data is generated based on user game interactions within the region.

[0019] In some implementations, adjustments are made based on computing and additional computing resource capabilities, as well as the region's resource requirements.

[0020] In some implementations, each sub-region of a region is defined by a boundary and assigned a different computation to handle user game interactions within that sub-region. User movement within the region is tracked, and when it is determined that a user from a sub-region of the region has moved to the boundary between two consecutive sub-regions, communication between the computations assigned to each of the two consecutive sub-regions is managed to handle the user's game interactions. The processing of game interactions is synchronized between the computations.

[0021] In some implementations, user movement within a virtual location is tracked, and sub-regions within that region are adjusted based on the number of users accessing the region. Adjustments may include merging one or more sub-regions within the region or creating additional sub-regions within the region. Adjustments to sub-regions result in adjustments to the calculations allocated to the region.

[0022] In an alternative implementation, a method for managing resources for an online game is disclosed. The method includes executing the online game in response to user input received from multiple users. Execution of the online game provides access to virtual locations within the game world of the online game. Computation is allocated to one or more users present at each virtual location. The computation is configured to process user input from one or more users present at the corresponding virtual location to generate game video data for each of the users. Movement of each user is tracked within the game world to determine when a certain number of users access an area within one of the virtual locations. When the number of users exceeds a predefined limit on the computation allocated to users in the area, the area is subdivided into multiple sub-areas. Additional computation is allocated to the area such that the computation and the additional computation process user input provided by each of the users in the area to generate corresponding video game data for each of the users.

[0023] In one implementation, a method is disclosed, comprising: executing an online game for a plurality of users, each of the plurality of users being provided with access to a virtual location in a game world provided by the online game; identifying one or more virtual locations in the game world, in which one or more of the plurality of users reside; allocating one or more computing resources to each identified virtual location in the game world for processing game interactions provided by the one or more users in each virtual location, wherein the amount of computing resources allocated to each virtual location is based on the processing load required to process the game interactions; monitoring the processing load of each of the one or more computing resources allocated to each identified virtual location in the game world; and dynamically adjusting the amount of computing resources allocated to each virtual location to process the processing load of each virtual location.

[0024] In one implementation, a method is disclosed, comprising: executing an online game for multiple users, each of the multiple users being provided with access to a virtual location in a game world provided by the online game; identifying one or more virtual locations in the game world where one or more of the multiple users are located; allocating one or more computing resources in the game world to each identified virtual location for processing game interactions provided by the one or more users in the virtual location, wherein the amount of computing resources allocated to each virtual location is based on the processing load required to process the game interactions originating from the virtual location; monitoring the movement of the one or more users in each virtual location, wherein the monitoring includes identifying one or more users who have entered or left each virtual location; and dynamically adjusting the amount of computing resources allocated to each of the virtual locations based on the monitored movement to process the processing load at each of the virtual locations.

[0025] Other aspects of this disclosure will become apparent from the following detailed description of the principles of this disclosure, illustrated by way of example and in conjunction with the accompanying drawings. Attached Figure Description

[0026] This disclosure can be best understood by referring to the following description taken in conjunction with the accompanying drawings.

[0027] Figure 1 The diagram illustrates a simplified block diagram of a distributed game engine for supplying resources to an online game, executed on a game cloud system according to one implementation of the present disclosure.

[0028] Figure 2 The diagram illustrates a simplified block diagram of a distributed game engine that identifies some components used to supply resources for an online game, according to one implementation of this disclosure.

[0029] Figure 3A A simplified block diagram illustrating details of some components of a computational region manager module for a distributed game engine used to supply resources for online games, according to one implementation of this disclosure.

[0030] Figure 3B The diagram illustrates a simplified block diagram detailing some components of a computational region manager module within a distributed game engine used to supply resources for online games, according to an alternative implementation of this disclosure.

[0031] Figures 4A-4C The illustrations show different ways to generate sub-regions for virtual locations within the game world of an online game, according to one implementation of this disclosure.

[0032] Figure 5 The diagram illustrates a cloud gaming system according to one implementation of the present disclosure, which is used to execute an online game in order to provide game data frames to one or more client devices via a cloud gaming network.

[0033] Figure 6 The illustration shows the flow of a method for supplying resources to an online game using a resource allocation model, according to one implementation of this disclosure.

[0034] Figure 7 The illustration shows components of an example computing device for building and training a resource allocation model (artificial intelligence (AI) model) using a modeler, according to one implementation of the present disclosure. Detailed Implementation

[0035] While the following detailed description contains numerous specific details for illustrative purposes, those skilled in the art will recognize that many variations and modifications of these details are within the scope of this disclosure. Therefore, the various aspects of this disclosure described below are set forth without any general limitation or restriction imposed upon the preceding claims.

[0036] Generally, various embodiments of this disclosure describe systems and methods that provide ways to understand the resource requirements of an online game, the resource capacity allocated to each computation in the online game, and dynamically adjust the computation allocated to the online game during gameplay to provide optimal resource allocation for the online game. The online game can be a large-scale multiplayer online (MMO) game accessed by multiple users. The multiple users can be players accessing the online game to play, or spectators accessing the online game to watch the game progress or follow one or more specific players playing the online game, or a combination of both. MMO games provide game data based on user input received from the multiple users via game interaction. Game data generated for players and spectators following players includes the game state of the online game associated with the player. Game data generated for multiple players includes a game world view of the online game.

[0037] Multiple virtual locations are identified within the game world. Each virtual location is a region in the game world with defined boundaries, within which one or more users (players and / or spectators) of the online game reside. Game interactions in the form of user input are monitored in each virtual location to determine the amount of game interactions generated at each virtual location. Computation is allocated to users in the online game to handle the processing of game interactions generated in the game world. The computation allocated to the online game is identified based on the processing resources available to service the processing load defined for the game interactions. As each user progresses in the online game, their location in the game world can change from a first virtual location to a second virtual location. The distributed game engine monitors the movement of each user in the game world to determine when a certain number of users access a region within a specific virtual location. The number of users in a region can lead to an increase in game interactions within that region of a specific virtual location. Each computation has a predefined limit on the number of users whose game interactions it can handle. If the number of users in a region exceeds the predefined limit for the allocated computation, the region in the specific virtual location is dynamically subdivided into multiple sub-regions, each with at least one user from the region. Additional computation is allocated to the regions to handle the processing load generated by the users' game interactions in the game world, and game video data is generated for each user in each sub-region. In some implementations, different computations are allocated to each sub-region to handle user game interactions within that sub-region. The computations allocated to each sub-region are identified based on the resources required to handle the processing load generated by the game interactions within that sub-region.

[0038] After computation is assigned, user movement is monitored to determine when one or more users move from one area to a different area. In response to monitoring, the computation assigned to the online game can be evaluated to determine whether some computation can be deassigned or reallocated to handle user game interactions in different virtual environments within the online game. Deassignment or reallocation of computation is performed after game data generated based on user game interaction processing has been successfully migrated from the computation being deassigned to the computation assigned to handle game interactions in the online game.

[0039] Having gained a general understanding of the various implementation schemes above, we will now describe example details of the implementation schemes with reference to the various accompanying drawings.

[0040] Figure 1 The diagram illustrates a simplified block diagram of a distributed game engine 100 in a game cloud system, used to execute an MMO (i.e., online game) accessed by multiple users from different geographical locations. The distributed game engine 100 includes functional components for processing specific features of the online game. Instances of the distributed game engine 100, along with the game logic of the online game, can execute on one or more servers (i.e., compute units 102a to 102n) of the game cloud system, wherein one or more of the instances can be used to process specific features of the online game. The functional components include engines / modules for processing specific features of the online game. Some features of the online game that can be processed by the different functional components of the distributed game engine may include physics, audio, shading, texturing, assembly / encoding, scripting, artificial intelligence (AI), memory management, animation, scene graphs, to name a few.

[0041] According to one implementation of this disclosure, a game cloud system includes a network of backend servers (e.g., computing 1-n) executing instances of one or more online game applications. One or more client devices (not shown) are used to access the online games executed on the game servers of the game cloud system via a network 200 (such as the Internet). The client devices can be any computing device (such as a mobile phone, tablet, personal computer, etc.) that includes at least memory, a processor, and a network interface for interacting with the backend servers via the network 200, or they can be thin clients that provide an interface for interacting with the backend servers providing computing capabilities. The backend servers are game servers configured to execute one or more instances of one or more games. The game servers can be any type of server computing device available in the game cloud system. In one example implementation, the game server can be a virtual machine supporting a game processor that uses the host's resources to execute online game instances for users. In another example implementation, the game server can be a standalone physical server or a physical server as part of a single data center or multiple data centers. In one implementation, a central server (i.e., a central compute unit) 102, which executes instances of the distributed game engine 100 and game logic, can coordinate the inputs and outputs of different servers (i.e., compute units) 102a-102n via a network 200, assemble the outputs from the different servers, and encode the outputs of the online game for forward transmission via the network 200 to one or more client devices. The network 200 can be any type of network, including the Internet, a wide area network (WAN), a local area network (LAN), a private network, a game network, etc.

[0042] Online games can be remotely executed by multiple servers (i.e., calculators 102a-102n) of a game cloud system, and game data can be streamed via network 200 to the client devices of users (players or spectators). Players participate in the game by providing game interactions (user input) that influence the game state of the online game. Spectators are users who follow the general game progress of the online game, including game interactions (user input) from multiple players, or who focus on the game progress of specific players. The progress of the online game is controlled by players using control options provided on their client devices or using a controller communicatively connected to their client devices. In other implementations, the online game can be executed locally on the client device, and metadata from the executing online game can be transmitted via network 200 to the backend servers of the game cloud system to influence the game state.

[0043] Figure 2The diagram illustrates a block diagram of a distributed game engine 100, in one implementation, for supplying computation and computational resources to handle game interactions generated during gameplay in an online game. The online game can be an MMO game played or accessed by multiple users. Multiple users can access the online game from one geographical location or from different geographical locations. The distributed game engine includes algorithms that continuously track user movement within the game world of the online game and allocate different computations to the online game to handle game interactions generated within that game world. The algorithms provide users with access to different virtual locations within the game world and manage the processing of game interactions generated at each virtual location. To process online game user interactions quickly and efficiently, instances of the distributed game engine and the online game's game logic are executed on different computations (i.e., servers) for processing game interactions generated at each virtual location identified within the game world. Furthermore, one of the computations executing the game engine instances (e.g., a central server) can be used to manage the inputs and outputs of each computation allocated to the online game, assemble the outputs from all computations, and generate game video data, including the game state of the online game, for each user playing or following the online game. The computations allocated to the online game can be a single data center or part of multiple data centers. Distributed game engines use parallel processing to process the ever-changing game video data generated by game interactions (user input) provided by different users, and provide game video data frames to the corresponding client devices associated with different users.

[0044] The distributed game engine 100 includes multiple components for managing computation and computing resources allocated to process game interactions generated in different virtual locations identified within the game world of an online game. Some components of the distributed game engine 100 include a user location tracker 105, a location load analyzer 107, a computation allocator 109, a game context processor 111, and a dynamic computation area manager 120. The user location tracker 105 monitors the movement of each user within the game world and identifies the virtual location where each user exists within the game world. As part of the tracking, the user location tracker 105 can determine when a certain number of users in the online game access an area within a specific virtual location. The number of users within an area can be a subset of the users accessing the online game. As more users access an area, the area may experience an increase in game interactions from users within that area. This increase in game interactions leads to an increase in game video data (also referred to herein as game data) generated in the area, as each user in the area must be presented with the online game from their own perspective. Users can be players or spectators. A player's game data includes the player's game state in the online game. The game data generated for the audience includes the game status of the players the audience is following in the online game's areas. In some implementations, the computation can define separate predefined limits for the number of players and viewers it can handle. These predefined limits can be specific to the type of player accessing an area or virtual location within the game world (e.g., expert, intermediate, or novice players). In such implementations, user location tracker 105 can determine the type of user accessing an area in a specific virtual location within the game world and the number of users of each type, and generate signals to location load analyzer 107 to evaluate the computation allocated to the online game and determine whether the computation allocated to the online game is configured to handle the number of users in the area.

[0045] In some implementations, multiple computations can be allocated to an online game, such that different computations are assigned to users at each identified virtual location within the game world of the online game to handle game interactions generated by users at the corresponding virtual locations. Each computation allocated to the online game may have a predefined limit on the number of users the computation can handle. As mentioned above, each computation may have a predefined limit for each type of user accessing the online game. Location load analyzer 107 evaluates the user type and the number of users of each type in the area in response to signals from user location tracker 105. When the number of users of each type exceeds the corresponding predefined limit, location load analyzer 107 interacts with computation allocator 109 to adjust the computation in the area.

[0046] The computational allocator 109 determines the computational capacity allocated to each virtual location in the game world based on information exchanged with the location load analyzer 107, and identifies additional computational resources for allocation to regions within a specific virtual location. The computational allocator 109 dynamically supplies the identified additional computational resources, enabling both the existing computational resources and the additional computational resources to handle game interactions within the regions of the specific virtual location. The computational allocator 109 can supply additional computational resources (such as additional CPU cores) to existing computational resources at a micro level, or supply additional computational resources (such as adding one or more servers (i.e., computational resources)) to specific virtual locations at a macro level. The allocation of additional computational resources involves migrating game interactions of certain users within a region of a specific virtual location to the additional computational resources to allow the additional computational resources to handle the processing of game interactions generated within the region. The computational resources allocated to users in a specific virtual location and the additional computational resources work together to process user game interactions within the region and the specific virtual location, and to generate game data for each user in the specific virtual location.

[0047] After allocating additional computation to the online game to handle the processing load generated by user interactions within the game, the distributed game engine uses a dynamic computational region manager 120 to continuously monitor user movement within the game world and manage the computation allocated to the online game. Monitoring may lead to adjustments in the computation allocated to the online game. For example, during gameplay, the amount of game interaction in virtual locations may be affected by user movement into or out of virtual locations, or by increased interaction between any two users within a virtual location or between two different virtual locations. The computational region manager 120 tracks user movement and game interactions identified in different virtual locations within the game world, assesses the number of users, user interactions in different virtual locations, and dynamically adjusts the computation allocated to the online game by scaling up or down the computation allocated to handle user interactions in each different virtual location of the online game.

[0048] When a certain number of users access a specific area within a virtual location at a given time, the number of users is verified against predefined limits defined for allocating computations to handle user game interactions within the virtual location. When it is determined that the number of users in a specific area exceeds the capacity of one or more computations allocated to the virtual location, the computational area manager 120, in some implementations, divides the specific area into multiple sub-areas. Each sub-area is defined by a sub-boundary. The number of sub-areas created is based on the types of users present in the specific area and the number of users of each type. In some implementations, segmentation criteria identifying user types (e.g., players or spectators) and the number of users of each type can be used to determine the number of sub-areas to be created within the specific area. Sub-areas created within the area can have the same size or different sizes. Each sub-area includes at least one user from the area.

[0049] Figures 4A-4C This diagram illustrates various scenarios of how sub-regions can be defined within a region of a virtual location identified in a game world. As mentioned above, a virtual location can include a region, each of which can be subdivided into multiple sub-regions, and the number of sub-regions is based on the user density within the specific region of the virtual location. When a user selects to play an online game, they are given access to a virtual location in the game world defined within the online game. As users move around in the game world, a certain number of users can enter a specific region within a particular virtual location at a given time. A specific region is defined as a part of a particular virtual location. When the number of users in a specific region exceeds a predefined limit for the computation allocated to the online game, the region can be divided into multiple sub-regions, each allocated a different computation, in order to distribute the processing load across the specific region of the particular virtual location. The processing load on the computation allocated to a particular virtual location corresponds to the amount of game interaction provided by the users in that particular virtual location. The number of sub-regions is based on the user density within the region. In some implementations, sub-regions can cover the entire area of ​​the region based on the distribution of users within the region. In alternative implementations, sub-regions can cover only a portion of the region based on the distribution of users within the region.

[0050] Figure 4A The diagram illustrates a representation where a certain number of users access a region (region A) representing a specific virtual location (location 1) at a given time. It is determined that the number of users in region A exceeds a predefined limit on the computational resources allocated to process game interactions from users in location 1. As a result, region A is subdivided into four distinct sub-regions – sub-regions A1, A2, A3, and A4. Figure 4A In the example illustration, the number of sub-regions is based on the number of users in virtual location 1. The sub-regions are of the same size, and each sub-region includes one or more users from region A. The number of users in each sub-region may be the same or may differ. Users in each sub-region include players and / or spectators of the online game. It should be noted that even when users are spectators who do not provide game interaction (i.e., user input) to influence the game state of the online game, each spectator focusing on a player may still need to be presented with the online game from the perspective of the corresponding player. Alternatively, each spectator may typically be focused on the overall flow of the online game and may be provided with a view of the game world.

[0051] Different computations are allocated to each created sub-region to handle the game interactions generated within it, thereby providing game data to each user in the corresponding sub-region. For example, CPU 1 is allocated to sub-region A1, CPU 2 to sub-region A2, CPU 3 to sub-region A3, and CPU 4 to sub-region A4, where each of the computations (CPU 1, CPU 2, CPU 3, and CPU 4) allocated to sub-regions A1, A2, A3, and A4 is identified based on the resources available to handle the processing load generated by the game interactions produced in the corresponding sub-region. Figure 4A In the example shown, one computation is assigned to each sub-region. In other examples, multiple computations could be assigned to each sub-region to handle the processing load generated therein.

[0052] Figure 4B The illustration shows the implementation, where virtual location 1 comprises multiple regions (regions AC), each allocated different computations (CPUs 1-3 respectively) to handle game interactions generated within that region. Since a certain number of users from other regions within virtual location 1 or from other virtual locations in the game world access region A of virtual location 1 at a given time, region A is divided into multiple sub-regions based on the number of users accessing region A. Each sub-region includes one or more users from region A, and different computations are allocated to them to handle the processing load within that sub-region. The number of sub-regions generated within virtual location 1 is only an example, and fewer or more sub-regions can be generated within virtual location 1. Figure 4B-1 , Figure 4B-2 and Figure 4B-3 This illustrates different ways that region A can be divided. For example, as... Figure 4B-1 As shown, region A is divided into three additional sub-regions A-1, A-2, and A-3 by dividing it along the vertical axis. Figure 4B-2 As shown, region A is divided into three additional sub-regions A'-1, A'-2, and A'-3 by dividing region A along the horizontal axis. Figure 4B-3 An example is shown where region A is subdivided into 6 sub-regions (A”-1 to A”-6). The number of sub-regions created based on the division of region A may vary depending on the number of users within region A.

[0053] exist Figure 4B-1 , Figure 4B-2 and Figure 4B-3 In the example shown, the sub-regions created by dividing region A are of equal size, and each sub-region includes one or more users from region A. Figures 4B-1 to 4B-3An example of dividing a region within a virtual location into sub-regions is shown. The same example can be extended to dividing a virtual location or defining sub-regions within a virtual location. The number of sub-regions and the direction of the division are provided only as examples, and each region can be subdivided vertically, horizontally, diagonally, or in any other way into fewer or more sub-regions, and the number of sub-regions is based on user density and predefined constraints on the computations allocated to the regions. A different computation is assigned to each newly created sub-region, separate from the computation allocated to region A. For example, in Figure 4B-1 In this context, CPUs 4-6 are allocated to sub-regions A-1 to A-3 created within region A, while CPUs 1-3 are allocated to region AC created in virtual location 1 (see [link to relevant documentation]). Figure 4B Similarly, in Figure 4B-2 In the middle, CPUs 4-6 are allocated to sub-regions A'-1 to A'-3 respectively, and... Figure 4B-3 In the middle, CPUs 4-9 are allocated to sub-regions A”-1 to A”-6 respectively.

[0054] exist Figure 4B-1 , Figure 4B-2 and Figure 4B-3 In the example scenario shown, the computation allocated to region A can coordinate all sub-regions created within region A. Figure 4B-1 Subregions A-1 to A-3 Figure 4B-2 Subregions A'-1 to A'-3, or Figure 4B-3 The game interaction processing is performed in sub-regions A”-1 to A”-6. In an alternative implementation, different computations are assigned to each sub-region within region A to handle game interactions generated by one or more users in the corresponding sub-region, and the computation assigned to one of the sub-regions within region A can coordinate the processing of game interactions within the sub-regions of region A. Coordination includes managing the inputs and outputs of the different computations within region A and providing the output of the coordinated computation to the computation assigned to region A. As previously stated, the number of regions created within the virtual location and within the sub-regions of the virtual location, and the number of computations assigned to each created sub-region, are provided as examples only and should not be considered limiting.

[0055] In an alternative implementation, a sub-region can be created within a specific part of the virtual location's area, or an additional sub-region can be created within a specific part of the sub-region, based on the number of users who access a specific part of the area or sub-region during gameplay. Figure 4CThe illustration depicts one such implementation, in which the portion of region A identified within virtual location 1 is further divided into three additional sub-regions A”'-1 to A”'-3 based on user density within a portion of region A. In this implementation, the remaining portion of region A is considered a fourth sub-region A”'-4. The three sub-regions A”'-1 to A”'-3 are of the same size, and the size of the fourth sub-region A”'-4 differs from that of the three sub-regions created within the portion of region A. Figure 4C In the example shown, each of subregions A”'-1 to A”'-3 includes one or more users from region A, while subregion A”'-4 may or may not include any users from region A. This could be a situation where users from region A are all accessing the portion of region A where the subregions were created, while the remaining portion of region A has no users. As the game progresses, one or more users may move from one or more of subregions A”'-1 to A”'-3 or from other regions or from other virtual locations to subregion A”'-4. As a result, in one implementation, when a subregion is created, a different computation (CPU 4-7) is allocated to each of subregions A”'-1 to A”'-4. In another implementation, a different computation (CPU 4-6) is allocated to each of subregions A”'-1 to A”'-3, while subregion A”'-4 is allocated the computation of region A (CPU 3). Although Figure 4C The example shown illustrates assigning one computation to each of the subregions A”'-1 to A”'-4, but there can be multiple computations assigned to each subregion, depending on the processing load detected at each subregion.

[0056] After assigning one or more computations to each sub-region A created within region A of virtual location 1, computation region manager 120 migrates the relevant game interaction of each user within region A to the corresponding computation assigned to the newly created sub-region. As long as users continue to access one or more regions or virtual locations and participate in online game interactions, the process of managing virtual locations by generating regions, sub-regions, and assigning computations to different virtual locations, regions, and / or sub-regions will continue to provide sufficient resources for the online game to handle game interactions.

[0057] As input, the game context processor 111 receives processing load information (i.e., game interaction volume) from the location load analyzer 107 regarding the computational load allocated to different virtual locations, and user movement in the game world from the computational region manager 120 (including information related to users accessing specific areas or sub-regions created within one or more virtual locations), and uses this information to optimize the processing of each user's game interactions to generate user game data. Optimization of the game data may include determining the processing order of game interactions provided by different users and for different parts of each user's game interactions based on the importance of the data to each user, and processing user inputs representing each user's game interactions accordingly. The processing order allows processing some portions of each user's user input first, and then processing the remaining portions. Optimizing game interaction processing helps reduce computational load because only some portions of each user's user input need to be processed immediately. It should be noted that in this application, game interaction and user input are used interchangeably to refer to inputs provided by a user during gameplay of an online game. Player-provided input may be the game state controlling the player's game, while spectator-provided input may be controlling which player's gameplay the spectator wishes to focus on.

[0058] For example, considering the virtual locations of three areas identified in a virtual environment, the first group of users in the first area might approach from the right side of the game world, facing or adjacent to the first area, and see / interact with the second group of users or game objects in the second area. Similarly, the second group of users in the second area might approach from the left side of the game world, facing or adjacent to the first area, and see / interact with the first group of users or game objects in the first area. In this scenario, a processing order for handling game interactions of the first group of users in the first area is defined such that the portion of interactions pointing to the right of the first group of users is processed first (i.e., game data related to the direction the users in the first sub-area are facing), and interactions pointing to the left of the first group of users (i.e., game data related to the direction opposite to the direction the users in the first sub-area are facing) are processed again or later. This is because the first group of users in the first sub-area are more interested in what is happening to their right (i.e., the direction they are facing) than to their left (i.e., the direction behind them – the direction opposite to their facing). The order of interaction processing for each user can be based on the corresponding user's field of vision.

[0059] Similarly, a processing order for handling interactions of the second group of users in the second region is defined such that interactions pointing to the left of the second group of users (i.e., game data related to the direction the user is facing) are processed first, and interactions pointing to the right of the second group of users (i.e., game data related to the direction opposite the direction the user is facing) are processed later. Alternatively, the processing order can be based on the timing associated with the interaction. For example, a first user in region A fires at a second user in region B, resulting in the second user being injured. In response, a third user in region B fires at a first or fourth user in region A, resulting in the first or fourth user being injured. The game scenario processor 111 determines which interaction needs to be processed first by utilizing the timing of each user's activity and processing the interactions of different users accordingly to achieve the game state of the online game, so that game data suitable for each user (first, second, third, and fourth users) can be presented. The computational region manager manages the input (interactions) from users, which are located in different virtual locations and different regions and sub-regions within one or more virtual locations, and shares the game state among different virtual locations and regions and sub-regions within one or more virtual locations. Information from the compute region manager 120 is used to assign users to different sub-regions within a virtual location and / or different virtual locations. Game data generated by the compute region manager, containing the game state for each user, is forwarded to the user's corresponding client device for rendering.

[0060] Figure 3A The diagram illustrates some components used to supply resources for an online game in one implementation. A distributed game engine 100 includes multiple components for processing user input from multiple users to generate game data for each user, identifying the user's virtual location within the game world, detecting when a user visits an area within a specific virtual location at a given time, and supplying computing resources to the area in response so that user game interactions within the area can be processed in a timely manner. When multiple users access an online game (such as an MMO game running on a game cloud system) to play, the distributed game engine 100 uses a user location tracker 105 to follow them as they move within the online game. User input provided through game interactions is used to generate game data for the corresponding user. A virtual location in an online game can be defined as an area within the game world, which includes game objects and challenges at a specific level of the online game. For example, in an interstellar space game, a virtual location can be defined as an area within a galaxy, such as an area covered by astronomical objects (such as planets, stars, asteroids, spaceships, etc.) or the space between any two astronomical objects accessible to the user. Similarly, in international war games that cover the entire world, virtual locations can be defined as countries or continents, and regions can be defined as states, cities, towns, mountains, rivers, dams, etc. within a country.

[0061] When a user selects an online game to play, they are offered access to one or more virtual locations within the game world. A user location tracker 105 is used to identify each user's current virtual location during gameplay. The information provided by the user location tracker 105 can be used to determine when a certain number of users access an area within a specific virtual location. Multiple users may have gathered in an area of ​​a specific virtual location at a given time, while attempting to overcome challenges in the game. The number of users in an area may lead to an increase in user input (i.e., game interaction) in the area, resulting in an increase in the game data generated in the area.

[0062] At least one computation is allocated to each user in a virtual location within the game world to handle their game interactions and generate game data for each user. In some implementations, each computation may have a predefined limit on the number of users it can handle. Location load analyzer 107 determines whether the number of users accessing the virtual location area can be handled by the computation allocated to the virtual location or exceeds the predefined limit defined for the computation. When the number of users exceeds the computational capacity, location load analyzer 107 signals computation allocator 109 to supply additional computation to assist the existing computation in handling game interactions in the virtual location. Computation allocator 109 determines whether the increase in game interactions can be handled simply by increasing the computational resources of the existing computation, or whether new computation needs to be allocated to the virtual location. Based on this determination, computation allocator either supplies additional resources to the existing computation or signals dynamic region creation engine 121 to provide additional computation to the virtual location.

[0063] The dynamic region creation engine 121 analyzes the type of game being played (e.g., graphics-intensive or compute-intensive), the type of users who have visited regions within a specific virtual location in the game world (e.g., advanced players, intermediate players, novice players, or spectators), and determines whether the existing computing power allocated to the online game is sufficient to handle the number of users accessing the regions of the virtual locations. Each computing power allocated to the online game may have a predefined limit on the number of users it can handle, and this predefined limit may be based on the type and quantity of resources available in the computing power. To assist in providing game data to each of the multiple users playing the online game, one or more computing powers may be provided to each virtual location in the game world where one or more users reside. Based on the analysis, when the number of users in a region within a specific virtual location exceeds the predefined limit for the allocated computing power, the dynamic region creation engine 121 may divide the region in the specific virtual location into multiple sub-regions. Each sub-region is defined by a boundary, within which at least one user resides. The dynamic region creation engine 121 then interacts with the computing power allocator 109 to allocate additional computing power to the regions to assist in handling game interactions within the regions. In some implementations, one or more different computations are assigned to each sub-region to handle user game interactions within that sub-region and to generate game data for each user in the corresponding sub-region. Each user's game data includes the user's online game state based on the interactions provided by the user. The game data generated by the computations assigned to the sub-region is assembled from one of the computations assigned to the sub-region or from computations assigned to the region or a specific virtual location. The assembled game data is used to generate the game state of the online game. The dynamic region creation engine 121 uses a game state coordinator 121a to coordinate the game data from the different computations and generate the game state for the online game.

[0064] Game status information and user location information are forwarded by the dynamic region creation engine 121 to the user region allocation manager 125. The user region allocation manager 125 stores the user's current location in the online game locally and shares this location information with the user data migration agent 127. The user data migration agent 127 uses each user's location information to determine the order in which game data frames need to be provided to each user and are forwarded accordingly to the client device of the corresponding user. The order of the game data is determined by the game scenario processor 111.

[0065] The game context processor 111 processes user input within each virtual location by determining the current context of the online game and the processing order of game data for each user. For example, the processing order for each user can be determined by the data priorityr 111a based on each user's field of vision, the criticality of different parts of the game data, and the temporal sequence associated with the game data. The data priorityr 111a can determine each user's field of vision by examining the direction each user faces during gameplay and / or the direction the user moves within the online game. If the user moves from left to right in the game world, the field of vision will be the side the user faces in the game world (i.e., the right side). As a result, while the user is facing right, game data related to the game world to the user's right will be given higher priority compared to the game world behind the user (i.e., the left side of the game world). If the user jumps around to address challenges on the left side of the game world after overcoming challenges on the right, the left side of the game world in the user's field of vision is given higher priority while the user is facing left, and the right side of the game world behind the user is given lower priority. The game context processor 111 uses the processing order information provided by the data priorityr 111a to process each user's game interactions. Since online games receive input from multiple players (i.e., hundreds or thousands of players) at any given time, prioritizing and processing each user's game interaction will reduce the amount of game data being generated by each computation allocated to a virtual location, thus making efficient use of the allocated processing resources while ensuring that appropriate game data is presented to users in a timely manner to enrich their gaming experience.

[0066] The processed game data for each user is forwarded to the user data migration agent 127 to assemble, encode, and stream the game data frames to the user's corresponding client device. Each user's game data is received at the user migration agent 127, assembled, and transmitted according to a processing order determined for each user. The processed game data is also stored in data storage area 260 to determine user metrics and game data metrics for the online game. These metrics can be used to classify users and determine the types of computations that need to be allocated to the online game. As users continue to interact with the online game, more users may move into areas within a specific virtual location, or existing users may move out of areas within a specific virtual location. The dynamic region creation engine 121 and the game scenario processor 111 work together to ensure that the computations allocated to processing user game interactions in each virtual location and each sub-region within a given virtual location have sufficient resources to handle the processing load of the online game.

[0067] Figure 3BThe illustration shows various components of a computational region manager 120 in an alternative implementation of a distributed game engine 100. This computational region manager tracks a user's virtual location within the game world of an online game, manages computations allocated to those virtual locations, and migrates user game data to different computations. In this implementation, a dynamic region creation engine 121 can interact with additional components within the computational region manager 120 to coordinate user game interactions within the online game by generating sub-regions and generating signals to spin-up or spin-down computational resources at different virtual locations. Some components within the computational region manager 120 include the dynamic region creation engine 121, a region boundary coordinator 123, a user region allocation manager 125, a user data migration agent 127, a data synchronizer 129, and a spin-up / spin-down guide 131, to name a few.

[0068] A distributed game engine executes the game logic of an MMO (i.e., online game) that processes game interactions received from multiple users and generates game data for the online game. Since the online game is accessed by multiple users distributed across various geographical locations, instances of the distributed game engine and game logic execute on multiple servers within a game cloud system and are accessed by users via a network 200 (such as the Internet). A user location tracker 105 within the distributed game engine is used to monitor user movement within virtual locations in the online game's game world. Users can be identified within virtual locations in the game world using game objects or avatars. Different virtual locations can be defined for different levels of the game, and users can be identified in different virtual locations based on the level of the game and the progress made within the online game. The user location tracker 105 can analyze game data generated during gameplay to determine the virtual location of each user in the online game and detect when a certain number of users access an area within a virtual location in the game world.

[0069] Upon detecting the number of users in an area of ​​a specific virtual location, the location load analyzer 107 of the distributed game engine 100 determines whether the number of users in the area exceeds a predefined limit for computation allocated to process interactions generated within the identified virtual locations in the game world. As each user moves around within the game world during gameplay, the number of users accessing an area of ​​a specific virtual location may vary. Consequently, the location load analyzer 107 continuously monitors the number of users present in an area of ​​a specific virtual location to determine whether the number of users exceeds a predefined limit for computation allocated to that specific virtual location.

[0070] The computational allocator 109 uses information from the location load analyzer 107 and the user location tracker 105 to determine the amount of computation required to handle the game data processing load in a specific virtual location. The computational allocator 109 can also determine the type and amount of computation already allocated to the online game to handle game data generated at different virtual locations identified in the game world. Using information related to the allocated computation and the computation required by the online game, as well as the number of users accessing the area at a given time during gameplay, the computational allocator can determine whether the computation allocated to the online game is sufficient to handle the interactions in the area of ​​the virtual location, and thus to handle the online game, or whether any adjustments to the computation allocated to the online game are needed. For example, the currently allocated computation may be insufficient to handle the interactions of multiple users gathered in the area of ​​a specific virtual location, and additional computation may need to be allocated to handle the interactions of multiple users in the specific virtual location. In such cases, the location load analyzer 107 can signal the dynamic region creation engine 121 within the computational region manager 120 to allocate additional computation to the specific virtual location.

[0071] Alternatively, the computation currently allocated to a specific virtual location in the online game may exceed the computation required to handle the number of users already gathered in the area. As a result, it may be necessary to offload some computation allocated to the virtual location and migrate user interactions to other computations allocated to the online game. The location load analyzer 107 can signal to the dynamic region creation engine 121 within the computation region manager 120 to allocate additional computation to the specific virtual location. User location information from the user location tracker 105, computation information provided by the computation allocator 109, and location load information provided by the location load analyzer 107 are shared with the dynamic region creation engine 121.

[0072] The dynamic region creation engine 121 uses signals from the location load analyzer 107 to adjust the computations allocated to specific virtual locations in the online game. Since the online game is an MMO game with multiple players (i.e., users) accessing and playing, each player may progress in the online game at their own pace. As a result, each player may be in a different virtual location within the online game. Therefore, different computations are allocated to the online game to allow different computations to handle user interactions in corresponding virtual locations. When multiple users access a specific region within a particular virtual location, there is an increase in the number of interactions in the region that the allocated computations may or may not be able to handle. When the currently allocated computations cannot handle the number of users in a region of a particular virtual location, the dynamic region creation engine 121 divides the region into multiple sub-regions, each sub-region having at least one user in the region. Each sub-region is defined as having a boundary where users in the sub-region exist within the boundary. The dynamic region creation engine then interacts with the spin-up / spin-down director 131 to allocate additional computations to the region. In some implementations, the spin-up / spin-down director 131 may allocate additional computations at a micro or macro level.

[0073] Users can be players or viewers. Players can be further categorized into novice, intermediate, or expert categories. Similarly, viewers can be categorized into viewers who are interested in the general gameplay of the online game, or viewers who are interested in one of the player types (expert, intermediate, or novice). The dynamic region creation engine 121 can determine whether the number of users gathered in a region within a specific virtual location is within a predefined limit for the computation allocated to that specific virtual location. If the number of users exceeds the predefined limit within a threshold percentage (e.g., 5% or 10%), the dynamic region creation engine 121 can signal the spin-up / spin-down guide 131 to adjust the computation at a micro level. However, if the number of users in a region of a specific virtual location exceeds the predefined limit for computation by more than a threshold percentage, the dynamic region creation engine 121 can signal the spin-up / spin-down guide 131 to adjust the computation at a macro level. It should be noted that the dynamic region creation engine 121 can determine the type of user and the number of users of each type already gathered in the region when adjusting the computation allocated to a specific virtual location of the online game.

[0074] In one implementation, micro-level adjustments may include adding additional CPU cores, GPU bandwidth (if the GPU is shared), memory, or other computing resource components to existing computing to allow these additional computing resources to assist in processing game data at a specific virtual location. The above micro-level adjustment is an example, and other forms of micro-level adjustments are also possible. In one implementation, macro-level adjustments may include adding additional servers or server clusters to a specific virtual location to assist in processing game data generated therein. Additional servers may be physical servers, virtual servers operating using the host's computing resources, container servers, or any combination thereof. The above macro-level adjustment is an example, and other forms of macro-level adjustments are also possible.

[0075] Once a sub-region is created, information associated with the sub-region (such as the virtual sub-boundaries used to define the sub-region) is shared with the region boundary coordinator 123. The region boundary coordinator 123 uses boundary definition logic 123a and a region stitcher 123b to identify and manage users within each sub-region created in a region of a specific virtual location. Boundary definition logic 123a uses the boundaries of the sub-regions created within the region, the boundaries of the region within the virtual location, and the boundaries of the virtual locations identified within the game world to determine, through interaction with the region stitcher 123b, whether one or more users exist on the boundary separating two consecutive sub-regions, two consecutive regions, or two consecutive virtual locations. The region stitcher 123b stitches together the sub-regions within each region, the regions within each virtual location, and the virtual locations within the game world by coordinating the game states of each user within the sub-regions, the regions within each virtual location, and the virtual locations within the game world to provide a seamless virtual world view of the online game's game world. The region boundary coordinator 123 uses information from this seamless virtual world view of the game world to determine whether any user is located on the boundary between any two sub-regions created within a specific virtual location or on the boundary between any two consecutively defined regions within a virtual location. For example, when creating sub-regions, the dynamic region creation engine 121 attempts to subdivide regions within a specific virtual location, ensuring that most users within the region are included within the boundaries of each sub-region. However, one or more users may fall on the boundary separating two consecutively defined sub-regions. Therefore, the region boundary coordinator 123 identifies those users who fall on the boundary between any two consecutive sub-regions and coordinates the synchronization of those users' game states between computations allocated to the respective sub-regions, ensuring that users present on the boundary are provided with the appropriate game state for the online game.

[0076] User Region Assignment Manager 125 uses information from the virtual world view provided by Region Boundary Coordinator 123 to identify the sub-region and / or virtual location to which each user belongs, and stores this information locally for use during gameplay. As users move around in the game world, their locations constantly change, and Region Assignment Manager 125 updates the changes when a change associated with each user is detected. The user's current location is also shared by User Region Assignment Manager 125 with User Data Migration Agent 127 and Spin Up / Spin Down Guide 131. Spin Up / Spin Down Guide 131 obtains each user's current location within the game world, queries Calculator Assignment 109 to identify the computations allocated to the corresponding virtual location / sub-region, and signals Calculator Assignment 109 to perform spin up additional computations for each sub-region. The additional computations supplied to a specific virtual location, along with previously supplied computations, are used to process game interactions generated by users within each sub-region.

[0077] In other implementations, some sub-regions and / or virtual locations can be reconfigured by merging them together to form improved sub-regions / virtual locations. For example, an area within a specific virtual location in a game world might be subdivided into multiple sub-regions, with different computations allocated to each sub-region to handle game interactions generated by users present in those sub-regions. During gameplay, when one or more users in a first sub-region move from the first sub-region to a second sub-region or to a different region or virtual location, the computations allocated to the first sub-region may be underutilized or idle. To optimize computational resources allocated to the online game, computations allocated to one or more sub-regions of a specific virtual location can be reallocated by reconfiguring them. Reconfiguring one or more sub-regions may include merging a first sub-region with a second sub-region to create a combined sub-region and allocating the computations allocated to the first sub-region to the combined sub-region, or reallocating the computations allocated to the second sub-region to another sub-region, virtual location, or another online game. Similarly, when an area within a specific virtual location is subdivided into multiple sub-regions, where only some sub-regions have users during gameplay, computation allocation may cause the computation allocated to one of the sub-regions containing users to also be allocated to sub-regions that do not contain any users. For example, in Figure 4C In the example shown, different calculations are assigned to each of the first three sub-regions that include one or more users, and a calculation of one of the virtual locations or sub-regions is assigned to the fourth sub-region that does not include any users.

[0078] When one or more users from the first sub-region move to the second sub-region, the computing power allocated to the second sub-region can be redistributed to handle the excess processing load generated by the users moving to the second sub-region. As users move from the first sub-region, the first computing power may become idle or underutilized. Consequently, by merging the first and second sub-regions and allowing the second computing power to handle the processing load generated by game interactions in the combined sub-region, the first computing power can be reallocated to different virtual locations or online games. Spin-up / spin-down director 131 is used to determine the processing load that each computing power can handle, the extent to which each computing resource of the computing power can be stretched, which computing power / computing resources need to be actively utilized, and which computing power / computing resources should be reduced or inactive. In some implementations, spin-up / spin-down director 131 can signal to increase or decrease the computing power allocated to the online game based on cost or demand. For example, spin-up / spin-down director 131 can interact with power manager scheduler 133 to determine which computing power remains active and which computing power is inactive, and such determination can be made based on electricity costs. For example, if power costs are high at a certain time, the power manager scheduler 133 can signal the spin-up / spin-down director 131 to maintain the computing allocated to the virtual location or sub-region and prioritize the allocated computing rather than allocating additional computing to handle the processing load of the virtual location or sub-region. Similarly, if power costs are low at other times, the power manager scheduler 133 can signal the spin-up / spin-down director 131 to increase additional computing to provide more processing capacity to handle the processing load of the virtual location or sub-region. Therefore, the power manager scheduler 133 is used to ensure optimal supply and utilization of computing provided to different virtual locations in the game world of the online game, so that the allocated resources can efficiently handle the processing load while being cost-effective.

[0079] Once computations are assigned to different sub-regions and / or virtual locations, user data migration agent 127 migrates relevant game interactions associated with different users to corresponding computations assigned to the respective sub-regions / virtual locations. Migrating game interactions between different users includes migrating the game state of a user's online game to the corresponding computation assigned to the user's sub-region or virtual location. Migrating the game state of an online game includes migrating the physical state, rendering state, any damage information connected within the game world, and any other game data of one or more users' online games from one computation to another. For example, if a sub-region has been created within a region of a specific virtual location, the game state and game interactions of users existing in the corresponding sub-region need to be migrated from the computation assigned to the region or specific virtual location to the corresponding computation assigned to the different sub-region. Game interactions can be migrated to the appropriate computation by migrating said parts based on the priority assigned to each part of the interaction, where the priority assigned to a part can be based on the timing, importance, criticality, need, each user's field of vision, etc., associated with the interaction. For example, when the game world includes a game object explosion caused by the user's interaction with a game object, the user's explosion-related interaction needs to be migrated first so that the user's interaction is processed first and the explosion-related game data is presented to the user. Later, other interactions can be migrated based on the priority of other interactions assigned to the user. Information related to the processing priority of different game interactions assigned to each user can be provided by the game context processor 111. Processing priorities are used to optimize computational data processing in order to use computing resources efficiently, while ensuring that appropriate game data is presented to each user in a timely manner.

[0080] The game context processor 111 receives user location information and virtual locations defined in the game world of the online game from the area boundary coordinator 123, and processes each user's interactions. In some implementations, the game context processor 111 uses a data priorityr 111a to prioritize the processing of each user's interactions. The data priorityr 111a can process game world-related interactions based on relative context, so that the game data provided to the user includes game content presented in order of relevance to the user. For example, portions of game data related to the game world within the user's field of vision (such as game object explosions from the example above) can be provided first, and other game content outside the user's field of vision can be provided later. The game context processor 111 processes the different portions of game data associated with each user in order of relevance and provides them to the user data migration agent 127, so that the user data migration agent 127 can encode and forward the different portions of game data to the appropriate client device for each user in order of relevance.

[0081] When a user is located on the boundary between two consecutive sub-regions or within a virtual location, data synchronizer 129 synchronizes data between two or more computations assigned to the user in the two consecutive sub-regions / regions. For example, if a first computation is assigned to a first sub-region and a second computation is assigned to a second sub-region, then the user's game data (including game state) existing on the boundary between the first and second sub-regions is synchronized between the first and second computations. Data synchronizer 129 identifies the first and second computations assigned to the two consecutive sub-regions / regions and generates synchronization signals to the first and second computations to allow them to synchronize the game data associated with the user. User game data synchronization follows a priority assigned to different parts of the game data, and the synchronized data is forwarded to the user's client device by user data migration agent 127.

[0082] User location information and computational allocation are stored in the user profile of each user accessing the online game. When a new user accesses the online game and enters a specific virtual location within the game world, the distributed game engine 100 uses the user profile information along with computational allocation to assign the new user to the appropriate computation to process the game data generated by the new user.

[0083] In some implementations, the distributed game engine can train an artificial intelligence (AI) model to determine the type and amount of computation required for different levels of online games and for different users based on the game state of different users' online games, the type and amount of input provided by users in different virtual locations, the user's skill level, etc., and the computing area manager 120 of the distributed game engine can use the information included in the AI ​​model to identify and supply the required computing resources for different virtual locations in the game world, where computing resources can be supplied at the micro or macro level.

[0084] Game state provides the complexity of an online game's progress at a specific point in time. For example, game state can include game characters, game objects, game object attributes, game properties, game object states, graphics overlays, etc. Game state also includes the state of each device, module, or component of the server network used in the execution of the online game instance, such as CPU, GPU, memory, register values, program counter values, programmable DMA status, DMA buffer data, audio chip status, CD-ROM status, available communication bandwidth, etc., used to generate and process game progress data for rendering. Game state also identifies the currently executing portions of the online game's executable code and the portions that need to be loaded to continue the game. Game state can also include saved data for each user, including player user profiles, user customizations of game objects, game type, player-selected game level / difficulty, number of game tools, bonuses, points, cash, rewards, etc. Game state can also include randomly generated features or AI overlays or game complexity, which help understand the game details associated with the online game's progress. Game state and other relevant game-related data provide comprehensive details from which the processing load of the online game can be easily estimated.

[0085] Online games running on a game cloud system can be massively multiplayer online (MMO) games, and the game servers assigned to these online games can include instances of multiplayer distributed game engines that communicate with the game logic of the online games to capture player (i.e., user) activities and use those activities to generate game data for each player. The game logic is configured to manage the game state of each player during an MMO game session and provide this state to the distributed game engine. The distributed game engine provides functional components for handling different features of the online game, such as game physics, shading, scripting, texturing, audio, animation, memory management, scene graphing, assembly, and encoding, for the game data generated for each player or spectator participating in the MMO game session.

[0086] The distributed game engine 100 includes multiple processing engines or components to enable parallel processing of different characteristics of game data generated in response to user input provided during gameplay in an online game. Therefore, during a gameplay session in an online game, instances of the distributed game engine 100, along with instances of game logic, execute on multiple servers within a Game Cloud System (GCS) to allow the distributed game engine to process game data quickly and efficiently. When a user plays the online game, user input is collected and processed to influence the game state and generate gameplay data for transmission to the user's client device. The game state of the online game is analyzed to identify user metrics and game state metrics of the online game. User metrics are updated to reflect the user's user data. Similarly, game state metrics of the online game are updated to reflect the game data of the online game. User metrics and game state metrics are used to prioritize game data generated by different users during gameplay and forward it to the client devices of the appropriate users.

[0087] Various components of the distributed game engine 100 are used to determine the types of resources and the quantity of each type of resource required to process game data generated in each virtual location of the online game's game world. This determination is based on each user's online game state, user input, and processing criteria defined for the online game. For example, processing criteria might indicate that certain portions of a player's game data must have a higher priority than certain other portions of the game data. Based on this determination, the game scenario processor 111 processes different portions of the game data, and spin-up / spin-down guides direct computational resources or computational supplies to different virtual locations identified in the online game's game world to process the online game's game data in a fast and efficient manner for each player.

[0088] Generally, a game engine is a software layer that forms the foundation of games (such as MMOs) and provides a framework for developing online games. The game engine abstracts the execution details of the common, related tasks required by each online game (i.e., game engine tasks), while the corresponding game logic provides the details of how each online game will be played. The game engine framework includes multiple reusable functional components that handle the core features of online games that bring them to life. The basic core features handled by the game engine can include physics (e.g., for collision detection, collision response, trajectory, gravity-based object motion, friction, etc.), graphics, audio, artificial intelligence, scripting, animation, networking, streaming, optimization, memory management, threading, localization support, and more. Reusable components include a processing engine for handling the core features identified by the online game. During game runtime, the game engine manages the game logic of the online game, manages the allocation and synchronization of the game engine's functional parts to process game data optimally, and generates game data frames, which are transmitted back to the client device for rendering. The various game engines currently available offer different core functionalities, and a suitable game engine can be selected based on the functionalities available for executing online games.

[0089] In some implementations, instances of the game engine and game logic are distributed across multiple servers, with each server executing a specific functional part of the game engine. Different servers can process game data in parallel by executing different instances simultaneously. In this way, a distributed game engine allows for faster and more efficient processing of game data. The game engine is configured to handle the multiple functional parts required for an online game to come alive. Each online game developed for an MMO game environment can identify the different functional parts of the game engine required for the online game to function.

[0090] The functional components can be identified by the online game developers or determined by analyzing the game logic of the online game. Based on the specifications of the online game, each instance of the game engine (i.e., interchangeably referred to as "computation") executing on a server uses a specific processing engine of the distributed game engine to process the functional components related to the specific characteristics of the game data generated according to the online game's gameplay. Instances of the game engine provide iterative processing of game data by using the output from a first server (i.e., the result of the functional component processing) as input to a second server, using the output from the second server as input to a third server (or the first server), and so on. In some implementations, a single server can be allocated to execute instances of the game engine and game logic to process the specific functional components of the game engine. In other implementations, multiple servers (each executing an instance of the game engine and game logic) can be allocated to process the specific functional components. Multiple servers can be identified and allocated based on the amount of processing data generated at the virtual location. Because the game engine and game logic are instantiated on multiple servers to process the different functional components of the game engine required to bring the online game to life, the game engine is referred to as "distributed." Therefore, any reference to the distributed game engine used in this application refers to the following configuration: the corresponding parts of the game engine and game logic are instantiated on multiple servers.

[0091] The game engine synchronizes, assembles, encodes, and transmits game data output from different servers to the corresponding client devices for rendering. To assist in game data assembly, the game engine may include a synchronization engine to distribute and synchronize the various functionalities of the game engine across different servers, synchronize the processing of different functionalities of the game engine allocated to different servers, and route the processed results between servers and between servers and the user migration agent. The distributed game engine's user data migration agent tracks the servers (i.e., compute units) processing game data for specific users, collects output game data from different servers / compute units, assembles the output game data for each user, encodes it, and forwards the encoded game data to different client devices for rendering.

[0092] When a distributed game engine uses an AI model to determine the type of computing / computing resources required to process game data, it can use machine learning algorithms to populate the neural networks of the AI ​​model's nodes with information from game data generated during previous game sessions. The machine learning algorithms may include classifiers for providing output to generate / improve the AI ​​model. Each classifier may have an engine / module configured to identify and process specific features of game data generated at specific virtual locations or sub-regions identified in the game world, and update the AI ​​model's nodes with information related to processing load and type, and the amount of resources available for processing the specific features. The processed information, along with the game data, is forwarded downstream to other classifiers for further processing. The output from the AI ​​model is used to supply computing / computing resources to the online game, determining whether existing computing resources or server computation are sufficient to process the game data, or whether adjustments to the server / server resources are needed for optimal processing of the online game's game data.

[0093] The spin-up / spin-down guide 131 dynamically adjusts the computational / computing resources allocated to each virtual location in the game world of the online game, and assigns game interactions related to different users to appropriate computational / computing resources so that each user's interaction can be processed efficiently, and the generated game data can be transmitted to the user's client device in a timely manner for rendering. The game data provided to each user includes the user's own perception of the game world. For users acting as viewers, the game data provided to them may include their own perception of the online game or the perception of players they follow. When a new user joins a game session, the distributed game engine system is configured to route the new user so that all users of the online game (i.e., existing and new users) can have a satisfactory gaming experience.

[0094] In some example implementations, various types of servers can be provisioned to execute instances of game logic for distributed game engines and online games, and to process game data generated for online games. Servers can be physical servers. A physical server (or simply "server") can be a standalone server or part of a data center within a game cloud system. Servers in a data center can be standalone servers within the data center or part of racks, each rack containing multiple server computing units. Physical servers include the necessary resources, such as an operating system, memory, and microprocessors, for executing one or more applications and / or one or more functional parts of the game engine. The application or functional parts of the game engine are stored in memory, processed using a microprocessor, and managed by the operating system.

[0095] Alternatively, the server can be a virtual machine (VM) as part of a game cloud system. The game cloud system may include multiple VMs running on a host hypervisor, one or more of which are configured to support game processors that utilize the hardware resources available to the host hypervisor to execute instances of online games. When multiple game processors associated with multiple VMs execute instances of the online game, user input is collected, organized, and processed by one or more backend servers (i.e., physical servers or virtual servers) of the game cloud system to influence the game state of the online game. Game data generated for the online game in response to user input is assembled, encoded, and forwarded as streaming frames of game data to the user's client device for rendering. Where the distributed game engine uses AI models to supply computation and computing resources, user input is also used to generate training data to train the AI ​​model. Each VM may include one or more applications (e.g., one or more online game applications) that are executed by the operating system using the hardware resources available to the host's virtualization layer (i.e., the hypervisor).

[0096] In another alternative implementation, the server can be part of a cloud container that allows applications (such as online game applications) to be bundled together with all their dependencies, libraries, and configuration files required to run the online game application into a virtual container (or hereinafter referred to as a "container"), where the application uses the resources allocated within the container to run the application. Containers run without a complete operating system, thus providing operating system-level virtualization. Containers are able to run with minimal resources to perform tasks, such as instances of game engines and game logic for online games, where resources (i.e., physical hardware resources) are virtualized. Cloud containers are portable because they can be fully deployed across different servers. In one implementation, containers provide application isolation through process and namespace isolation techniques by sharing the kernel with the container host. In an alternative implementation, the container host's kernel is not shared, thus providing enhanced isolation by running containerized applications from virtual machines. The types of computing described above (i.e., servers) are provided as examples only and should not be considered limiting. Other forms of servers or computing (i.e., computing devices) that provide resources for instantiating game engines and game logic can also be used.

[0097] In some implementations, users can connect to online game applications of a cloud gaming system from anywhere in the world. Online game applications achieve this connection by launching multiple game instances on different servers distributed across different data centers worldwide. User input generated at the corresponding client device during gameplay is collected from the server network and game data is generated. Game data is returned to the corresponding client device as game data frames using any network model. Some examples of network models that can be used for communication between servers in the game cloud system described in this application include the TCP / UDP network model or the Open Systems Interconnection (OSI) network architecture based on the International Organization for Standardization (ISO). Data processing and communication between distributed servers can follow any of a variety of existing protocols. The ISO model includes a set of application layers (application layer, presentation layer, session layer) and data flow layers (transport layer, network layer, data link layer, and physical layer). The application layer is configured to identify sending and receiving entities, transmit application (such as online games) data between sending and receiving entities in a manner understood by the respective entities, and manage and synchronize communication between sending and receiving entities with minimal data loss. The data stream layer is configured to determine whether data transmission should be performed in a sequential or parallel path, determine the protocol to be followed for packetizing data, assembling the packetized data into frames, and transmitting the data frames along the preferred route. It should be noted that the above description provides only an overview of the ISO model for communicating data over a server network for online games, and more detailed descriptions of the roles of the various layers are understood by those skilled in the art and are therefore not provided in further detail.

[0098] Figure 5 The illustration shows an overview of an example system 300A according to one implementation of this disclosure, which supports collecting user input to update game data and using the updated game data to build and / or train AI models related to the gameplay of online games. Specifically, system 300A enables access to and play of video games stored in a Game Cloud System (GCS) 300. Generally, the Game Cloud System GCS 300 can be a cloud computing system operating via network 200 to support multiple players playing online game applications through corresponding game actions. Data related to those game actions can be used to build and / or train AI models related to the gameplay of online game applications. Specifically, system 300A includes a GCS 300, one or more social media providers 240, and multiple client devices 101, all connected via network 200 (e.g., the Internet). Multiple client devices associated with multiple users can connect to network 200 to access services provided by the GCS 300 and social media providers 240. Users can be players or viewers following the gameplay of specific players or online games.

[0099] In one implementation, the game cloud system 300 includes a game server 205, a video recorder 271, a tag processor 273, an account manager 274 (which includes a user profile manager), a game selection engine (i.e., a game selector) 275, a game session manager 285, user access logic 280, a network interface 290, and a social connection manager 295. The GCS 300 may also include multiple storage systems, such as game state storage, user account storage, and user data storage, which are typically stored in data storage area 260. Other game storage systems may include a game code storage area 261, a game recording storage area 262, a tag data storage area 263, a video game name storage area 264, and a game network user storage area 265. In one implementation, the GCS 300 is a system that can provide online game applications, services, game-related digital content, and interconnectivity between the system, applications, users, and social networks. The GCS 300 can communicate with the user's client device 101 and social media provider 240 via the network interface 290 and the social connection manager 295. The social connection manager 295 can be configured to associate one or more friends. In one implementation, each social media provider 240 includes at least one social graph 245 that illustrates a user's social network connections.

[0100] Players (i.e., users) can access services provided by the GCS 300 via the game session manager 285. For example, the account manager 274 enables player authentication and access to game names on the GCS 300. The account manager 274 stores information about users (players, spectators) and manages user profiles for each user. The account manager 274 can use user information for authentication purposes. Additionally, game names owned by users can be managed by the account manager 274. For example, video games stored in the game name store 264 are available to users who own those video games or have the ability to access them.

[0101] In one implementation, a user can access services provided by GCS 300 and social media provider 240 via a connection on network 200 through client device 101. Client device 101 can include any type of device with a processor and memory, whether wired or wireless, portable or non-portable. In one implementation, client device 101 can take the form of a smartphone, tablet computer, or a hybrid device that provides touchscreen functionality in a portable form factor. An exemplary client device can include a portable telephone device running an operating system and having the ability to access various applications (apps) that can be obtained through network 200 and executed locally on a portable device (e.g., smartphone, tablet computer, laptop computer, desktop computer, etc.).

[0102] Client device 101 includes a display 132, which acts as an interface for the user to send input commands 236 and display data and / or information 135 received from the GCS 300 and social media provider 240. Display 132 may be configured as a touchscreen, or a display typically provided by a flat panel display, cathode ray tube (CRT), or other device capable of providing a display. Alternatively, client device 100 may detach its display 132 from the device, similar to a desktop or laptop computer.

[0103] In one implementation, client device 101 is configured to communicate with GCS 300 to enable a user (player) to play a video game. For example, the player can select a video game available in the game name data storage area 264 via game selection engine 275 (e.g., by game name, etc.). The selected video game is enabled and an instance of the video game is loaded for execution by game server 205 on GCS 300. In one implementation, the game execution primarily occurs within GCS 300, such that client device 101 receives game video frame streams 135 from GCS 300 and transmits user input commands 236 used to drive the game execution back to GCS 300. The video frames 135 received from the streaming game execution are rendered on display 132 of client device 101.

[0104] In one implementation, after a player selects an available game name to play, the player can initiate a game session for the selected game name via game session manager 285. Game session manager 285 first accesses the game state store in data storage area 260 to retrieve, if any, the saved game state from the previous session played by the player (for the selected game), allowing the player to resume the game from the previous stop point. Once the resume point or start point is identified, game session manager 285 can instruct the game execution engine in game server 205 to execute the game code for the selected game name from game code store 261. After the game session is initiated, game session manager 285 can transmit game video frames 135 (i.e., streaming video data) to the client device (e.g., client device 100) via network interface 290.

[0105] During gameplay, the game session manager 285 can communicate with the game server 205, the recording engine in the video recorder 271, and the tag processor 273 to generate or save recordings (e.g., video) of gameplay or gameplay sessions. In one embodiment, the video recording of gameplay may include tag content entered or provided during gameplay, as well as other game-related metadata. Tag content may also be saved via snapshots. The video recording of gameplay, along with any game metrics corresponding to that gameplay, can be saved in the game recording storage area 262. Any tag content can be saved in the tag data storage area 263.

[0106] During gameplay, the game session manager 285 can communicate with the game server 205 to transmit and receive user input commands 236 that influence the outcome of the corresponding game progression in the video game. Player-input commands 236 can be transmitted from the client device 101 to the game session manager 285 of the GCS 300. Input commands (e.g., controller inputs or user inputs) 236 include input commands for driving game progression and user interaction inputs such as labeled content (e.g., text, images, video recording clips, etc.). Game input commands, along with any user game metrics (such as the duration of gameplay), can be stored in the game network user store. Selection information related to the gameplay of the video game can be used to enable multiple features available to the user.

[0107] Accordingly, the systems and methods described in this disclosure are used to implement algorithms to identify virtual locations within the game world of an online game, and to supply computation and computational resources to handle the processing load at each virtual location to ensure efficient processing of the online game.

[0108] Figure 6The illustration shows an example operational flow of a method for managing processing resources for an online game that presents a game world, according to one implementation. The method begins at operation 610, where an online game is executed for one or more users. One or more instances of the online game may be executed in response to multiple users accessing the online game to play. Access to a virtual location defined in the game world of the online game is provided to each of the one or more users. As shown in operation 620, computation is allocated to process game interactions of the one or more users in the game world. Different computations may be allocated to process game interactions generated by users present in each virtual location in the game world. The computation allocated to each virtual location may include a predefined limit on the number of users that the allocated computation can handle. The predefined limit may be based on the amount of game interactions generated by users, where game interactions include user input provided by users (such as players) during gameplay.

[0109] The system monitors user movement within the online game and determines the number of users accessing an area within a specific virtual location. When the number of users in an area exceeds a predefined limit for computation allocated to that specific virtual location (as shown in operation 630), the area is dynamically divided into multiple sub-regions (as shown in operation 640). The number of sub-regions created for the area can be based on the user density in the area and the partitioning criteria used by the distributed game engine. Sub-regions are created with defined boundaries such that each sub-region includes at least one user from the area. In some implementations, an entire portion of the area is divided into sub-regions. In other implementations, depending on the users' clustering locations within the area, a portion of the area within a specific virtual location is subdivided into sub-regions, while the remainder of the area is treated as separate sub-regions. In such implementations, sub-regions created within a portion of a specific virtual location may each have one or more users from that specific virtual location, while the remainder may or may not include any users.

[0110] After dividing the region into sub-regions, additional computations are assigned to the regions, such that the assigned computations and additional computations handle the user's game interactions within each sub-region, as shown in operation 650. In some implementations, different computations are assigned to each sub-region, and each different computation is configured to handle the user's game interactions within that sub-region. The processing of the computations assigned to the regions and the additional computations is coordinated to generate a game state for each user. The game state, along with each user's game data, is forwarded to each user's corresponding client device. Each user's game data includes the user's perception of the online game's game world, and this perception is determined based on the online game's game state.

[0111] Therefore, distributed game engines provide a method to track user movement within the game world and proactively take real-time actions to supply computing resources to handle the processing load of each virtual location / region within each virtual location during online gameplay. This ensures that the necessary computing resources are provided to each virtual location / region within each virtual location to handle the processing load generated within it. Actions may include generating sub-regions within a region or sub-regions within a sub-region, or resetting two or more sub-regions, based on the number of users within a sub-region / region within a virtual location, and accordingly allocating / deallocating computing resources. Dynamic allocation / deallocation of computing resources in the online game ensures optimal use of computing resources while generating game data for each user in a fast and efficient manner.

[0112] Active tracking and provisioning allow users from one time zone to seamlessly join online game sessions with other users in another time zone (such as their social circles) without queuing or waiting. Online game sessions are serviced by different computing / computing resources allocated to different virtual locations identified within the game world, providing each user with game data that includes their own perception of the game world. Computing / computing resources allocated to virtual locations can be provisioned from different data centers, and game data can be synchronized, processed, assembled, and transmitted with minimal latency. Of course, the processing and transmission of game data between computing systems located in different time zones and between computing systems and client devices must account for time delays due to transmission distances between computing systems and client devices, and may require additional bandwidth for transmission or prioritization of game data based on available bandwidth to make the game data appear to be presented to the user in real time.

[0113] Information related to user location can be obtained from the user region allocation manager and supplied with computing / computing resources by the spin-up / spin-down guide 131, and synchronized with user data by the data synchronizer 129. The data synchronizer 129 prioritizes user interactions in virtual locations to generate game data based on the game context and information provided by the data priorityr 111a, so as to provide users with their own perspective of the online game in a timely manner. Since each player needs their own perception of the online game, it is more efficient to supply separate computing / computing resources to handle the processed data generated in each virtual location, so as not to overstretch computing / computing resources. Sub-regions created within the area of ​​a virtual location are defined such that most users are within the boundaries of each sub-region. The computing allocated to the virtual location is configured to process the game data generated for users in a constantly changing space in parallel.

[0114] The various implementations described in this paper represent a deterministic approach to computation when a large number of players enter the same virtual location within the game world of an online game at a given time. The computational resources allocated to different virtual locations are flexibly increased or decreased based on the processing demands at those locations, ensuring efficient utilization of these resources. The subdivision of virtual locations and the distribution of computational resources are based on the user density (represented by characters / game objects / avatars) within each virtual location in the game world.

[0115] Figure 7 The illustration shows components of an example apparatus 700 that can be used to carry out various embodiments of the present disclosure. For example, Figure 7 An exemplary hardware system suitable for training an AI model capable of performing various functions related to online games and / or gameplay, according to one embodiment of the present disclosure, is illustrated. The block diagram illustrates device 700, which may be incorporated into or may be a personal computer, server computer, game console, mobile device, or other digital device, each suitable for practicing embodiments of the present disclosure. Alternatively, the functionality of the device may be implemented on a physical server or a virtual machine or container server. Device 700 includes a central processing unit (CPU) 702 for running software applications and optionally an operating system. CPU 702 may consist of one or more homogeneous or heterogeneous processing cores.

[0116] According to various implementations, CPU 702 is one or more general-purpose microprocessors having one or more processing cores. Further implementations may use one or more CPUs with a microprocessor architecture particularly suitable for highly parallel and computationally intensive applications configured for deep learning, content classification, and user classification, such as media and interactive entertainment applications. For example, CPU 702 may be configured to include a deep learning (AI) engine 701 configured to support and / or perform learning operations regarding the provision of various functionalities (e.g., predictions) related to online games and / or game performance. Deep learning engine 701 may include a modeler 720 configured to build and / or train an AI model configured to provide various functionalities related to online games and / or game performance. Furthermore, CPU 702 includes an analyzer 740 configured to generate and train the AI ​​model. The trained AI model provides outputs in response to a specific set of user inputs, where the outputs depend on predefined functionalities of the trained AI model. The trained AI model can be used to determine resource allocations to be implemented during game performance to meet success criteria defined for online games. The analyzer 740 is configured to perform various functions related to online games and / or the gameplay of online games, including analyzing the output from the trained AI model for a given input (e.g., controller input, game state data, success criteria) and providing a response.

[0117] Memory 704 stores applications and data for use by CPU 702. Storage device 706 provides non-volatile storage and other computer-readable media for applications and data, and may include fixed disk drives, removable disk drives, flash memory devices, and CD-ROMs, DVD-ROMs, Blu-ray discs, HD-DVDs, or other optical storage devices, as well as signal transmission and storage media. User input device 708 conveys user input from one or more users to device 700, examples of which may include a keyboard, mouse, joystick, touchpad, touchscreen, still or video recorder / camera, game controller, and / or microphone. Network interface 714 allows device 700 to communicate with other computer systems via electronic communication networks and may include wired or wireless communication over local area networks and wide area networks such as the Internet. Audio processor 712 is adapted to generate analog or digital audio output from instructions and / or data provided by CPU 702, memory 704, and / or storage device 706. The components of the device 700 (including CPU 702, memory 704, data storage device 706, user input device 708, network interface 710, and audio processor 712) are connected via one or more data buses 722.

[0118] The graphics subsystem 713 is also connected to the data bus 722 and components of the device 700. The graphics subsystem 713 includes a graphics processing unit (GPU) 716 and a graphics memory 718. The graphics memory 718 includes display memory (e.g., a frame buffer) for storing pixel data for each pixel of the output image. The graphics memory 718 may be integrated with the GPU 716 in the same device, connected to the GPU 716 as a separate device, and / or implemented within memory 704. Pixel data may be provided directly from the CPU 702 to the graphics memory 718. Alternatively, the CPU 702 provides the GPU 716 with data and / or instructions defining the desired output image, and the GPU 716 generates pixel data for one or more output images based on the data and / or instructions. The data and / or instructions defining the desired output image may be stored in memory 704 and / or graphics memory 718. In one implementation, the GPU 716 includes 3D rendering capabilities for generating pixel data for an output image based on instructions and data that define the geometry, lighting, shading, texturing, motion, and / or camera parameters of a scene. The GPU 716 may also include one or more programmable execution units capable of executing shader programs. In one implementation, the GPU 716 can be implemented within an AI engine to provide additional processing capabilities such as those for AI or deep learning functions.

[0119] The graphics subsystem 713 periodically outputs pixel data of an image from the graphics memory 718 for display on the display device 710 or projected by the projection system 740. The display device 710 can be any device capable of displaying visual information in response to signals from the device 700, including CRT, LCD, plasma, and OLED displays. The device 700 can provide, for example, analog or digital signals to the display device 710.

[0120] It should be understood that the various implementation schemes defined herein can be combined or assembled into specific implementations using the various features disclosed herein. Therefore, the examples provided are merely possible examples and not a limitation on the various implementations possible by combining various elements to define more implementations. In some examples, some implementations may include fewer elements without departing from the spirit of the disclosed or equivalent implementations.

[0121] The embodiments of this disclosure can be practiced with various computer system configurations, including handheld devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The embodiments of this disclosure can also be practiced in distributed computing environments where tasks are performed via remote processing devices based on wired or wireless network links.

[0122] In light of the above embodiments, it should be understood that embodiments of this disclosure can employ various computer-implemented operations involving data stored in a computer system. These operations are those that require the physical manipulation of physical quantities. Any operation described herein that forms part of embodiments of this disclosure is a useful machine operation. Embodiments of this disclosure also relate to means or apparatus for performing these operations. The apparatus may be specifically constructed for the desired purpose, or the apparatus may be a general-purpose computer selectively activated or configured by a computer program stored in a computer. Specifically, various general-purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct more specialized apparatus to perform the desired operations.

[0123] This disclosure can also be embodied in computer-readable code on a computer-readable medium. A computer-readable medium is any data storage device that can store data that can subsequently be read by a computer system. Examples of computer-readable media include hard disk drives, network attached storage devices (NAS), read-only memory, random access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices. The computer-readable medium may include computer-readable tangible media distributed across network-coupled computer systems, enabling the distributed storage and execution of computer-readable code.

[0124] Although the method operations are described in a specific order, it should be understood that other housekeeping operations may be performed between operations, or the operations may be adjusted so that they occur at slightly different times, or the operations may be distributed throughout the system. As long as the processing of the superimposed operations is performed in the desired manner, the system allows the processing operations to occur at various intervals associated with the processing.

[0125] While the foregoing disclosure has been described in considerable detail for the purpose of clarity, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Therefore, embodiments of the invention are to be considered illustrative rather than restrictive, and embodiments of this disclosure are not limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for allocating resources for an online game, comprising: An online game is played for multiple users, each of whom is provided with access to a virtual location in the game world provided by the online game; Identify one or more virtual locations in the game world, where one or more of the plurality of users exist in the virtual locations; One or more computing resources are allocated to each virtual location identified in the game world for processing game interactions provided by the one or more users in each virtual location, wherein the amount of computing resources allocated to each virtual location is based on the processing load required to process the game interactions; Monitor the processing load of each of one or more computing resources allocated to each of the virtual locations identified in the game world; as well as The amount of computing resources allocated to each virtual location is dynamically adjusted to handle the processing load of each virtual location.

2. The method as described in claim 1, wherein, Monitoring includes verifying whether the processing load of each computing resource allocated to a virtual location identified in the game world is within predefined limits established for the computing resource.

3. The method as described in claim 1, wherein, Dynamic adjustments also include: Based on the processing load detected at the virtual location, one or more additional computing resources are allocated to the virtual location, or one or more computing resources allocated to the virtual location are deallocated, wherein the processing load is distributed across the number of computing resources allocated to the virtual location.

4. The method of claim 1, wherein monitoring further comprises: Identify a region within a virtual location identified in the game world, wherein a certain number of users provide game interactions within that region, wherein the number of users in the region is associated with one or more computing resources for processing the game interactions provided by the number of users in the region; and Verify that the number of users accessing the area of ​​the virtual location is below a predefined limit of one or more allocated computing resources. The game interactions provided by each of the stated number of users affect the processing load in the area of ​​the virtual location.

5. The method of claim 4, wherein the dynamic adjustment further comprises: In response to detecting that the number of users exceeds a predefined limit, the region is divided into multiple sub-regions, each of the multiple sub-regions including at least one user of the region; as well as One or more additional computing resources are allocated to the region, such that the one or more computing resources and the one or more additional computing resources allocated to the region are configured to process user-provided game interactions in each sub-region of the region.

6. The method of claim 5, wherein, The number of the multiple sub-regions created in the region is based on the number of users existing in the region.

7. The method of claim 5, wherein, Allocating one or more additional computing resources includes allocating different computing resources to process user input representing game interactions associated with each sub-region.

8. The method of claim 5, wherein, Identifying the number of users accessing the region includes tracking the movement of each of the one or more users into or out of each of a plurality of sub-regions, the movement of each of the one or more users being used to dynamically adjust the computing resources allocated to the region.

9. The method of claim 8, wherein, Dynamically adjusting the amount of computing resources includes cancelling one or more additional computing resources allocated to the region when the number of users in the region falls below a predefined limit based on the movement of the one or more users.

10. The method of claim 9, wherein, After successfully synchronizing game-related data of the game world between one or more computing resources allocated to the region and additional computing resources and one or more additional computing resources being disposed of, the one or more additional computing resources are disposed of, wherein the game-related data is generated from game interactions of the one or more users in the region.

11. The method of claim 8, wherein, The adjustment is made dynamically based on the resource capabilities of the one or more computing resources, the one or more additional computing resources allocated to the region, and the resource requirements of the region.

12. The method of claim 8, wherein, Each of the multiple sub-regions is defined by a boundary and is allocated one or more different computing resources for processing game interactions originating from users present in that sub-region; and Tracking the movement of each of the one or more users includes: Detects the user moving from a first sub-region to a boundary defined between a first sub-region and a consecutive second sub-region within a plurality of sub-regions defined in the region; and In response to the detection of the user on the boundary, communication between computing resources allocated to each of the first and second sub-regions is managed to enable the processing of the user's game interactions, the processing of which is synchronized between the computing resources allocated to the first and second sub-regions.

13. The method of claim 8, wherein, Tracking the movement of each of the one or more users includes: Tracking the movement of each of the one or more users within the area; and The number of sub-regions within the region is adjusted based on the number of users accessing the region, wherein the adjustment includes merging two or more sub-regions within the region or creating additional sub-regions within the region, and wherein adjusting the sub-regions includes adjusting the computing resources allocated to the region.

14. The method of claim 4, wherein, The game interaction in the area corresponds to user input provided by one or more users during the playing of the online game, wherein one or more users include either a player or a spectator.

15. A method for allocating resources for an online game, comprising: An online game is played for multiple users, each of whom is provided with access to a virtual location in the game world provided by the online game; Identify one or more virtual locations in the game world, where one or more of the plurality of users exist in the virtual locations; One or more computing resources are allocated to each virtual location identified in the game world for processing game interactions provided by the one or more users in the virtual location, wherein the amount of computing resources allocated to each virtual location is based on the processing load required to process game interactions originating from the virtual location; Monitor the movement of one or more users in each virtual location, wherein the monitoring includes identifying one or more users who have entered or left each virtual location; as well as Based on the monitored movement, the amount of computing resources allocated to each of the virtual locations is dynamically adjusted in order to handle the processing load at each of the virtual locations.

16. The method of claim 15, wherein, Monitoring includes verifying whether the processing load of each computing resource allocated to a virtual location identified in the game world is within predefined limits established for the computing resource.

17. The method of claim 15, wherein, Each virtual location is defined by boundaries and allocated one or more distinct computing resources for processing game interactions originating from users present within those virtual locations. The monitoring of movement also includes: Detecting the user's movement from a first virtual location to a boundary defined between the first virtual location and consecutive second virtual locations; and In response to detecting that the user has moved to the boundary, communication between computing resources allocated to each of the first and second virtual locations is managed to enable the processing of the user's game interactions, the processing of which is synchronized between the computing resources allocated to the first and second virtual locations.

18. The method of claim 15, wherein, Monitoring the movement of each of the one or more users includes: Track the movement of each of the one or more users within the virtual location; and In response to detecting that the number of users in the virtual location exceeds a predefined limit, the virtual location is divided into multiple regions, each region including at least one user of the virtual location, and each region is associated with one or more different computing resources for processing game interactions originating from the region.

19. A non-transitory computer-readable storage medium for allocating resources for an online game, storing instructions that cause a processor to perform the following operations: An online game is played for multiple users, each of whom is provided with access to a virtual location in the game world provided by the online game; Identify one or more virtual locations in the game world, where one or more of the plurality of users exist in the virtual locations; One or more computing resources are allocated to each virtual location identified in the game world for processing game interactions provided by the one or more users in each virtual location, wherein the amount of computing resources allocated to each virtual location is based on the processing load required to process the game interactions; Monitor the processing load of each of one or more computing resources allocated to each of the virtual locations identified in the game world; as well as The amount of computing resources allocated to each virtual location is dynamically adjusted to handle the processing load of each virtual location.

20. A non-transitory computer-readable storage medium for allocating resources for an online game, storing instructions that cause a processor to perform the following operations: An online game is played for multiple users, each of whom is provided with access to a virtual location in the game world provided by the online game; Identify one or more virtual locations in the game world, where one or more of the plurality of users exist in the virtual locations; One or more computing resources are allocated to each virtual location identified in the game world for processing game interactions provided by the one or more users in the virtual location, wherein the amount of computing resources allocated to each virtual location is based on the processing load required to process game interactions originating from the virtual location; Monitor the movement of one or more users in each virtual location, wherein the monitoring includes identifying one or more users who have entered or left each virtual location; as well as Based on the monitored movement, the amount of computing resources allocated to each of the virtual locations is dynamically adjusted in order to handle the processing load at each of the virtual locations.

Images