U.S. Pat. No. 11,583,778
VALUE-BASED GAME SESSION PLACEMENTS
AssigneeAmazon Technologies Inc
Issue DateMarch 30, 2020
Illustrative Figure
Abstract
A game-hosting service of a service provider network is configured to place game sessions on fleets of virtual machine (VM) instances using a value-based approach. In order to place a game session on a fleet, the game-hosting service may determine one or more attributes of the game session request, such as player attributes and/or game attributes. The game-hosting service may also determine available fleets of VM instances allocated to a subscriber associated with the game session request, which may be located across disparate geographical regions. A value(s) may be determined based on the attributes of the game session request, and the value(s) may be used to select a fleet of the available fleets for hosting the game session.
Description
DETAILED DESCRIPTION Service providers offer various network-based (or “cloud-based”) services to users to fulfill computing needs of the users. These service providers may operate service provider networks that include clusters of managed servers stored in data centers located across different geographic regions. In this way, users who have subscribed for use of the network-based services (or “subscribers”) need not invest in and maintain the computing infrastructure required to implement the various services that they may need. Additionally, subscribers and their clients are able to access these network-based services over different geographic regions. To offer these network-based services across geographic areas, service providers operate and maintain service provider networks (e.g., cloud-based computing environments, network-based service architectures, network-based service infrastructures, etc.). In this way, service provider networks may provide subscribers with scalable, on-demand, and network-accessible computing platforms over large geographic regions such that the subscribers have readily-available VM instances at their disposal. These service provider networks allow subscribers to immediately have computing infrastructure over large geographic regions to fulfill individual computing needs of the subscriber, and also to provide computing resources to support services provided to clients of the subscribers. For example, a subscriber to the service provider network may be a game developer (e.g., individual, company, and/or other organization) that has developed an online game that they would like to provide to clients who desire to play the online game. However, the game developer may desire to provide access to their online game to clients over large geographic regions, and for large amounts of users. The amount of computing infrastructure (e.g., compute power, memory, storage, networking, security, etc.) used to support and maintain an online gaming platform over different geographic regions that hosts game sessions for clients may be large enough to be impractical for game developers, particularly new or emerging ...
DETAILED DESCRIPTION
Service providers offer various network-based (or “cloud-based”) services to users to fulfill computing needs of the users. These service providers may operate service provider networks that include clusters of managed servers stored in data centers located across different geographic regions. In this way, users who have subscribed for use of the network-based services (or “subscribers”) need not invest in and maintain the computing infrastructure required to implement the various services that they may need. Additionally, subscribers and their clients are able to access these network-based services over different geographic regions. To offer these network-based services across geographic areas, service providers operate and maintain service provider networks (e.g., cloud-based computing environments, network-based service architectures, network-based service infrastructures, etc.). In this way, service provider networks may provide subscribers with scalable, on-demand, and network-accessible computing platforms over large geographic regions such that the subscribers have readily-available VM instances at their disposal. These service provider networks allow subscribers to immediately have computing infrastructure over large geographic regions to fulfill individual computing needs of the subscriber, and also to provide computing resources to support services provided to clients of the subscribers.
For example, a subscriber to the service provider network may be a game developer (e.g., individual, company, and/or other organization) that has developed an online game that they would like to provide to clients who desire to play the online game. However, the game developer may desire to provide access to their online game to clients over large geographic regions, and for large amounts of users. The amount of computing infrastructure (e.g., compute power, memory, storage, networking, security, etc.) used to support and maintain an online gaming platform over different geographic regions that hosts game sessions for clients may be large enough to be impractical for game developers, particularly new or emerging game developers, to purchase and maintain on their own.
Accordingly, service provider networks may provide a game-hosting service that is a fully, or at least partially, managed online gaming platform. The game-hosting service may deploy, operate, and scale session-based online game servers in the service provider network on behalf of game developers. The game-hosting service may provide groups, or “fleets,” of virtual machine instances (e.g., VM instances, instances, etc.) that execute on computing resources of the service provider network and host game sessions for clients of a subscribing game developer. Game software included in a game build can be provisioned to a fleet of instances, and the game-hosting service may spin up the fleet of instances, where each instance in the fleet executes at least one process that is to host a game session. When clients of a game developer want to play a game that is hosted by a game-hosting service, the game-hosting service may be tasked with placing a new game session on one of multiple fleets of VM instances that are allocated to the subscribing game developer.
This disclosure describes, among other things, techniques and systems for placing game sessions on fleets of VM instances, and ultimately on a VM instance of the selected fleet, using a value-based approach. The techniques and systems described herein may be implemented by a game-hosting service of a service provider network, where the game-hosting service is configured to place one or more incoming game session requests in a queue, and to process an individual request in the queue for purposes of placing a corresponding game session on a fleet of VM instances. In order to place a game session on a fleet, the game-hosting service may determine one or more attributes of the game session request, such as player attributes of (or, information about) the players associated with the game session request, game attributes of (or, information about) a game corresponding to the game session request, and possibly other types of attributes of the game session request. The game-hosting service may also determine available fleets of VM instances allocated to a subscriber associated with the game session request, which may be located across disparate geographical regions. A value(s) may be determined (e.g., computed, calculated, etc.) based on the one or more attributes of the game session request, and the value(s) may be used to select a fleet of the available fleets for hosting the game session. In order to host the game session, an idle server process executing on a VM instance of the selected fleet may be spun up to host the server component of the game session.
In general, the value(s) (sometimes referred to herein as a “placement value(s)”) that is/are used to select a fleet of VM instances for game session placement may be indicative of a preference for placing the game session on a particular fleet of VM instances (e.g., a fleet executing a particular type(s) of VM instance(s)). In some embodiments, a single value (e.g., a score, a metric, etc.) determined from the attributes of a game session request may represent a value within a range of possible values at which a variable can be set, where a maximum value of the range may be indicative of a high-value game session request and/or a strong preference for placing the game session on a particular fleet of VM instances, and a minimum value of the range may be indicative of a low-value game session request and/or a weak preference for placing the game session on a particular fleet of VM instances. In some embodiments, a single placement value determined from the attributes of a game session request may represent a dollar value that may be indicative of a monetary value attributable to an entity (e.g., the game developer) that stands to benefit from hosting the game session on a particular fleet of VM instances.
In some embodiments, the attributes of a game session request can be used to determine multiple values, where each value of the multiple values corresponds to an individual fleet of multiple fleets that are available for placing a corresponding game session. For example, a first value may be determined for a first fleet, the first value being indicative of a preference for placing the game session on the first fleet, a second value may be determined for a second fleet, the second value being indicative of a preference for placing the game session on the second fleet, and so on and so forth, depending on the number of fleets that might be available for placing the game session. In the case of determining multiple placement values, the values can represent any suitable type of value. For example, the multiple values may comprise multiple Boolean values (e.g., true or false, yes or no) that indicate whether it is preferable to place a game session on a given fleet or not (e.g., Fleet 1: Yes, Fleet 2: No, etc.). In other examples, the values may be numerical values within a defined range of values (e.g., a range of [0,100], a normalized range of [0,1], etc.), where the range may be indicative of a weak-to-strong preference for placing the game session on a given fleet to which the value is assigned.
As mentioned, the attributes of the game session request—which are used to determine the placement value(s)—may include, without limitation, player attributes of the players associated with the game session request and/or game attributes of the game corresponding to the game session request. Using these types of attributes to determine the placement value(s) is based on the notion that both players and games may vary across incoming game session requests, which means that there may be a benefit in strategically placing a first game session on a first fleet, and placing a second, different game session on a second fleet, even if the first fleet happens to provide a lower average player latency for both sets of players. In other words, it may be beneficial to place some new game sessions on fleets of VM instances that perhaps do not provide the highest-performance player experience during gameplay, yet other metrics may be optimized, such as the overall cost of hosting a subscriber's game sessions.
Player attributes for an individual player associated with a game session request may include, without limitation, a player identifier (ID), a number of games played over a period of time, whether the player is a paying player (as opposed to a player that exclusively plays free-to-play games), and, if so, an amount of money spent by the player over the period of time, an amount of time spent playing games, a time(s) of day that games were played, other players that were involved in a common match, whether a player ID is a known player ID (e.g., a famous/professional gamer, a known blogger, a game reviewer, a person with an above-threshold number of social media followers, etc.), whether the player has purchased downloadable content (DLC)—which is additional content created for an already-released video game, and the like. Game attributes may be indicative of a game mode, a game situation, a game context, or the like. Game attributes may include, without limitation, whether a game is to be played in a tournament mode or in casual mode, and if the game is to be played in tournament mode, a phase of a tournament (e.g., Phase 3 out of a total of 5 Phases), whether the game is to be live-streamed (i.e., broadcast to one or more viewing users), and if so, a projected number of viewing users in the audience, and the like. These are merely example of player attributes and game attributes that may be used to determine a placement value(s), as described herein, for placing a game session on a fleet of VM instances.
An example process implemented by one or more computing devices of a game-hosting service for placing a game session on a fleet of VM instances may include determining one or more player attributes of players associated with a game session request, the one or more player attributes based at least in part on prior gameplay of the players, and the game session request associated with a subscriber of a service provider network, determining a first fleet of VM instances allocated to the subscriber, determining a second fleet of VM instances allocated to the subscriber, and determining a value based at least in part on the one or more player attributes. The process may further include selecting, based at least in part on the value, the first fleet or the second fleet as a selected fleet, and hosting a game session corresponding to the game session request on a VM instance of the selected fleet.
Also disclosed herein are techniques and systems for using a value-based approach to assign a VM instance to a game streaming request for use of the VM instance in streaming a game to a client device of a player associated with the game streaming request. The techniques and systems described herein may be implemented by a game-streaming service of a service provider network, where the game-streaming service is configured to place one or more incoming game streaming requests in a queue, and to process an individual request in the queue for purposes of assigning a VM instance to the game streaming request so that a game can be streamed to a client device of a player associated with the game streaming request. The assigned VM instance may stream the game to the client device by rendering frames and sending the rendered frames to the client device (e.g., over a network) during a game session (e.g., a multiplayer game session). In order to select a VM instance for streaming the game to a given client device, the game-streaming service may determine one or more attributes of the game streaming request, such as player attributes of (or, information about) the player associated with the game streaming request, game attributes of (or, information about) a game corresponding to the game streaming request, and possibly other types of attributes of the game streaming request. The game-streaming service may also determine available VM instances allocated to a subscriber associated with the game streaming request, which may be located across disparate geographical regions. A value(s) may be determined (e.g., computed, calculated, etc.) based on the one or more attributes of the game streaming request, and the value(s) may be used to select a VM instance of the available VM instances for streaming the game to a given client device.
In general, the value(s) (sometimes referred to herein as a “instance assignment value(s)”) that is/are used to select a VM instance for streaming a game may be indicative of a preference for streaming the game to a client device using a particular VM instance (e.g., a particular type of VM instance). Similar to the logic described herein for game session placement, a single value (e.g., a score, a metric, etc.) determined from the attributes of a game streaming request may represent a value within a range of possible values at which a variable can be set, where a maximum value of the range may be indicative of a high-value game streaming request and/or a strong preference for streaming the game to a client device using a particular VM instance, and a minimum value of the range may be indicative of a low-value game streaming request and/or a weak preference for streaming the game to the client device using a particular VM instance. In some embodiments, a single placement value determined from the attributes of a game streaming request may represent a dollar value that may be indicative of a monetary value attributable to an entity (e.g., the game developer) that stands to benefit from using a particular VM instance to stream the game to a given client device of a player associated with the game streaming request.
Similar to the logic described herein for game session placement, the attributes of a game streaming request can be used to determine multiple values, where each value of the multiple values corresponds to an individual VM instance of multiple VM instances that are available for streaming a game to a given client device. For example, a first value may be determined for a first VM instance, the first value being indicative of a preference for streaming the game to the client device using the first VM instance, a second value may be determined for a second VM instance, the second value being indicative of a preference for streaming the game to the client device using the second VM instance, and so on and so forth, depending on the number of instances that might be available for streaming the game to the client device associated with the game streaming request.
An example process implemented by one or more computing devices of a game-streaming service for assigning a VM instance to a game streaming request may include determining one or more player attributes of a player associated with a game streaming request, the one or more player attributes based at least in part on prior gameplay of the player, and the game streaming request associated with a subscriber of a service provider network, determining a first VM instance allocated to the subscriber for streaming a game to a client device of the player, determining a second VM instance allocated to the subscriber, and determining a value based at least in part on the one or more player attributes. The process may further include selecting, based at least in part on the value, the first VM instance or the second VM instance as a selected VM instance for streaming the game to the client device. In some embodiments, the selection of the selected VM instance is a first phase of a multi-phase process, and the selection of a fleet for game session placement is a second phase of the multi-phase process. In this manner, once a selected VM instance is assigned to the game streaming request associated with a player, and once a game session involving the player is placed on a selected fleet of VM instances, the game session may be hosted on a VM instance of the selected fleet, and the game may be streamed to the client device of the player using the selected VM instance for game streaming.
The value-based approach for game session placement described herein takes into account attributes of a game session request, such as player attributes and/or game attributes. By doing so, a game-hosting service can optimize the placement of game sessions across available fleets of VM instances that are deployed within a service provider network. This is, in part, based on the notion that there is some intrinsic value in placing certain players and/or certain games on certain types of fleets of VM instances, as compared to an approach that uniformly-places all game sessions onto the lowest-latency fleets available, regardless of the attributes of the players and/or the attributes of the game associated with the game session request. For example, there may be intrinsic value in placing, on relatively high-performance fleets, game sessions involving players who have, in the past, played an above-threshold number of games over a period of time, and/or players who have, in the past, spent an above-threshold amount of money playing games via the game-hosting service. Such high-performance fleets may be identified as fleets that can provide low-latency performance during gameplay (e.g., fleets that are instantiated on servers with high-performance/higher-quality hardware, fleets with ample capacity for spinning up and executing new server processes on VM instances, etc.). As another example, there may be intrinsic value in placing, on relatively high-performance fleets, game sessions involving competitive tournaments (e.g., games that are in a later phase of a tournament) and/or games that are to be live-streamed to a viewing audience. In addition, the game-hosting service may, in some embodiments, select a high-performance configuration for hosting a high-value game session, such as by selecting a relatively high frame rate (e.g., 30 frames per second (FPS), as opposed to a lower, 15 FPS frame rate), a relatively high resolution (4K, as opposed to a lower, 1080P resolution). On the other hand, game session requests with attributes (e.g., player attributes and/or game attributes) that fail to meet criteria for placing game sessions on high-performance fleets may, instead, be placed on relatively low-performance fleets and/or such game sessions may be hosted with relatively low-performance configurations, which may allow for packing more game sessions onto a single server process and/or a single VM instance to lower the cost (to the subscribing game developer) of hosting the game session. Accordingly, the techniques and systems described herein can make certain games viable that would not otherwise be viable, which is beneficial for both the game industry and for the players who play video games via the game-hosting service.
The value-based approach for assigning a streaming instance to a game streaming request described herein also takes into account attributes of the game streaming request, such as player attributes and/or game attributes. By doing so, a game-streaming service (which may be implemented as part of the game-hosting service) can optimize the assignment of VM instances deployed within the service provider network for streaming games to individual client devices. This is, in part, based on the notion that there is some intrinsic value in streaming games to client devices using certain VM instances. For example, there may be intrinsic value in using a relatively high-performance VM instance to stream a game to a client device of a player who has, in the past, played an above-threshold number of games over a period of time, and/or a player who has, in the past, spent an above-threshold amount of money playing games via the game-streaming service. In addition, the game-streaming service may, in some embodiments, select a high-performance configuration for streaming the game to such a player, such as by selecting a relatively high frame rate (e.g., 30 frames per second (FPS), as opposed to a lower, 15 FPS frame rate), a relatively high resolution (4K, as opposed to a lower, 1080P resolution).
In addition, the techniques and systems described herein place more control in the hands of a subscribing game developer, at least in terms of allowing the game developer to control how resources (e.g., fleets of VM instances) of the service provider network are allocated amongst their clients (e.g., players of the subscribing game developer's video games). For example, a subscriber may be able to create its own customized session placement algorithm that is utilized by the game-hosting service for game session placement and/or to create its own customized streaming instance assignment algorithm that is utilized by the game-hosting service for assignment of a VM instance for streaming a game to a given client device. Additionally, or alternatively, a subscriber may voluntarily provide its own attributes (e.g., player attributes, game attributes, etc.) that are usable by the game-hosting service to determine where to place game sessions and/or which VM instances to use for game streaming using the value-based approaches described herein, thereby optimizing game session placements for the subscriber. Additionally, or alternatively, a subscriber may specify customized weights for particular attributes (e.g., player attributes, game attributes, etc.) that may be taken into account by the game-hosting service in determining the placement values for different available fleets during game session placement and/or in determining instance assignment values for different available VM instances during the assignment of instances to game streaming requests. These and other aspects described herein provide subscribers of the service provider network with more control and more autonomy over how their players are dispersed across available resources (e.g., fleets of VM instances) within the service provider network.
While some of the techniques are described herein as being performed in a service provider network of a service provider, the techniques may similarly be applied in other computing networks, such as on-premise servers managed by the game developers themselves. Certain implementations and embodiments of the disclosure will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, the various aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. The disclosure encompasses variations of the embodiments, as described herein. Like numbers refer to like elements throughout.
FIG.1illustrates a system-architecture diagram of an example environment100in which a game-hosting service of a service provider network102can place game sessions on fleets of virtual machine (VM) instances using a value-based approach.
As illustrated, the service provider network102may be operated and/or managed by a service provider104. The service provider network102may provide various services to users to fulfill their computing resource needs, such as cloud-based computing resources. For example, the service provider network102may provide cloud-based, scalable, and network accessible compute power services, storage services, database services, and/or other services. As illustrated, the service provider network102may also provide a game-hosting service106that is a scalable, cloud-based runtime environment for online games, including session-based multiplayer games. The game-hosting service106may be fully managed by the service provider104and deploy, operate, and scale the session-based multiplayer game servers in the cloud-based, or network-based, environment. For example, the game-hosting service106may not only provide the hardware to host the game sessions, but also manage ongoing activity, security, storage, and performance tracking. Additionally, the game-hosting service106may provide auto-scaling capabilities such that instances supporting game sessions can be spun up or spun down based on player demand.
To utilize the game-hosting service106, developers110may utilize developer devices108to register for an account (e.g., a user account, subscriber account, etc.) with the game-hosting service106. This may allow the developers110(sometimes referred to herein as “subscribers”110) to subscribe to the game-hosting service106, provide a game build(s) for their online game(s), and to provide their clients112with access to the online game(s) via their client devices114without the developers110having to invest in the computing resources (e.g., on-premise resources) needed to host the online game sessions for their clients112. In order to utilize the game-hosting service106, the developers110may provide a game build118to the game-hosting service106via one or more developer portals116. The developer portal(s)116may include one or more of a web-based console, a software-development kit (SDK), a command-line interface (CLI), an application programming interface (API), and/or any other means by which a developer110may specify and/or provide, among other things, a game build118to the game-hosting service106.
The game build118may correspond to any type of online game that may host a game session for one or more clients112(sometimes referred to herein as “players”112). For instance, the game build118may correspond to a session-based single player online game, or a session-based multiplayer online game. The game build may represent any type of online game, such as real-time strategy (RTS) games, first person shooter (FPS) games, multiplayer online battle arena (MOBA) games, role playing (RPG) games, massively multiplayer online (MMO) games, massively multiplayer online role player games (MMORPG), virtual board games (e.g., chess, checkers, etc.), action-adventure games, simulation games, strategy games, sports games, virtual reality games, and/or any other game that may be played in an online environment.
Generally, the client devices114may comprise any type of computing device that may be utilized for online gaming. For instance, the client devices114may include laptop computing devices, desktop computing devices, mobile phones, gaming systems, controller-based devices, virtual and/or augmented reality devices (e.g., head-mounted displays (HMDs)), other wearable devices, biometric sensors, projectors, televisions, and/or any computing device usable on its own, or in conjunction with other devices, for online gaming. In some examples, at least part of the online game may execute and/or be stored locally on the client devices114.
The game build118may include the game software for the online game, and may further include server executables, supporting assets, libraries, and dependencies that are all used to host and/or execute the game software on an instance. The developers110may provide the game build118through the developer portal(s)116, such as by uploading the game build118over one or more networks120(e.g., the Internet, wireless wide area networks (WANs), personal area networks (PANs), wired and/or wireless local area networks (LANs), etc.). The network(s)120may comprise any type of network or combination of network, including wired and/or wireless networks. Once a developer110has uploaded their game build118, the game-hosting service106may deploy the game software130to one or more game servers124in a computing-resource network122. For instance, the game software130may be installed on one or more virtual machine (VM) instances126that are at least partially managed by a local agent128(e.g., script, program, application, etc.).
The computing-resource network122may include data centers that each include one or more computing resources, such as VM instances126(1) to126(N) where “N” is any integer greater than or equal to 2 (referred to herein collectively as “VM instances126” “or just “instances126”). The data centers may house the game server(s)124and may be located across disparate geographical regions such that computing resources are available to support functionality for cloud-based services provided by the service provider network102. The computing resources may include various combinations of hardware-based components, such as central processing units (CPU), graphics processing units (GPU), memory, storage, network capacity, security, and/or any other type of hardware-based resource to support cloud-based services, such as the game-hosting service106. In some examples, the computing resource network122may further include respective memories that store various firmware-based and/or software-based resources that provide the functionality of the services, such as the instances126on which an agent128executes, the game software130executes, and one or more processes132execute to support a game session(s).
Generally, the agent128may be responsible for handling various processes on an instance126, such as spinning up an instance126, spinning down an instance126, handling lifetime processes of the instance126, retrieving game session assignments for processes132executing on the instance126, executing processes132on the instance126to host a game session(s), managing resources of the instance126, installing patches and/or other software on the instance126and/or various other actions for managing the instance126. A data store134may, among other things, keep track of the placement of game sessions136on particular fleets138of VM instances126. It is to be appreciated that, in addition to fleet assignments, the data store134may track more granular data for game session placement, such as the instance ID of a VM instance126on which the game session136is placed, the server process132assigned to host the game session136, etc. The data store134may track additional data as well, such as the processes132that are executing on VM instances126across subscribers'110fleets138, the ownership of those processes132in terms of whether they are available (e.g., executing in idle mode without an owner), or already assigned to a game session136(or game session request), the regions in which fleets138are located, etc.
In some examples, each process132(sometimes referred to as a “server process”132) that executes on an instance126may support a game session136that engages one or more clients112via their client device(s)114. That is, each process132may support one game session136. For instance, the process(s)132may each be running the game software130to support a game session136for one or more clients112. Often, a process132supports a game session136for multiple clients112(e.g., as with a multi-player game). A game session136is an instance of the game software130running on a server that clients112can connect to and interact with. The game defines the basic characteristics of the game session136, such as the life span or the number of players112involved. Although many of the examples described herein pertain to a single process132supporting a single game session136, it is to be appreciated that, depending on the game (e.g., the size of the game, complexity of the game, the number of clients112engaged in a single game session136, and/or other factors), a process132may handle multiple game sessions (e.g., for “lighter weight” mobile games), and/or perform other tasks besides hosting a game session136to help manage game sessions, interact with client devices114and/or the game-hosting service106, manage the instance126, and/or perform other actions. The process(es)132may be binary processes132, executable processes132, etc., running on the VM instance126that consume or utilize the underlying hardware resources and/or other resources.
To play in a game session, the client devices114may interact directly with the game-hosting service106, and/or through various backend game services to retrieve information on current game sessions136, to request new game sessions136, and/or reserve slots in game sessions136. For instance, the client devices114may interact, over one or more networks120, with game services140that may handle communication between client devices114and the game-hosting service106. Further, the game services140may handle additional tasks or provide additional services, such as player authentication and authorizations, team building and matchmaking, and inventory control. For example, when a client112wants to start a new game, the client device114may call the authentication service to first verify the client's112identity, and then send a game session request to the game-hosting service106.
In further examples, the online game of a developer110may rely on or utilize one or more additional external services142, such as for validating a subscription membership and/or determining entitlements for a client's account. As shown, the information from the external services142may be passed to the game server(s)124via the game services140and the game-hosting service106without going through the client device(s)114.
To establish or join a game session, clients112may utilize their client devices114(e.g., applications, software, or other programs executing thereon) to request (e.g., via an API call) that the game-hosting service106place them in a game session136. To create a game session136, a match is generally formed or made as an initial step, followed by a step of placing the match. In some embodiments, the game services140may execute matchmaking logic to match players112together in matches. For example, if a player112connects to the game services140over the network120for playing a multiplayer game, the client device114of the player112may present a screen that lists other online players112for selection, and the player112can select another player112from the list to play against. Other matchmaking factors can be considered as well, or as an alternative, such as skill level (e.g., match players112with commensurate skill levels). In some embodiments, the game-hosting service106may execute matchmaking logic on behalf of a game developer110.
After forming a match, the game-hosting service106may be tasked with placing the match (or, the game session136for the match). It is to be appreciated that, in some embodiments, short of forming a new game session136, the game-hosting service106may identify an already running process132that is hosting a game session136, and if the active game session136has an open player slot(s) that the player(s)112associated with the game session request can be placed into, the game-hosting service106may assign the player(s)112to the open player slot(s) in the active game session136, without having to form a separate match of a new game session136. Otherwise, the game-hosting service106may have already spun up VM instances126in fleets138that are allocated for various subscribers110of the service provider network102, and each of the spun up VM instances126may have server processes132executing thereon in idle mode until the processes132are assigned to a game session request for hosting a corresponding game session136(associated with a match) until the game session136ends. Other than loading maps and other data for hosting a particular game session136, these idle processes132may be ready to start hosting a game session136as soon as they are assigned to a game session request. The game-hosting service106may be tasked with placing a new game session136on an available fleet138allocated to a subscriber110, and to identify a server process132executing on a VM instance126of the selected fleet138, which will serve multiple players112in a set (e.g., 2, 10, 100, etc.) of players112that have been matched together for playing a multi-player game. Accordingly, for an incoming game session request, the game-hosting service106may resolve a fleet alias by calling a routing service, load fleet data to determine available fleets138of VM instances126, select a fleet138for placing the game session136, and identify available (e.g., idle) processes132that are usable to host the game session136corresponding to the incoming game session request. It is to be appreciated that, for efficiency reasons, the game-hosting service106may “pack” server processes132as tight as possible to avoid overutilization of resources. That is, the game-hosting service106may try to minimize the number of processes132that are concurrently executing in idle mode in order to have available a sufficient number of processes132while also avoiding unnecessary computing resource consumption that could be utilized for other purposes.
When a game session136is created, the assigned process132executing on a VM instance126of the subscriber's fleet138may be instructed to host (or support) the created game session136for one or more clients112of the subscriber110that are associated with the game session136. The client application(s) running on the client device(s)114associated with the game session may receive connection information (e.g., a port of a server124, an IP address, etc.), and may create a game connection(s)144by connecting directly, over the network(s)120, to the open game server124using a player session ID(s). The server process132may then accept the player ID(s) as a valid ID(s) and accepts, or rejects, the game connection(s)144. If connected, the player session is set to active and the client(s)112begins playing the game using their client device(s)114and the game connection144that is established between the game server124that has the instance126with the process132executing to host the selection game session136. Once a game session136has ended (e.g., clients112quit, the game ends, time out, etc.), the client application on each of the involved client devices114may disconnect from the process132, and the game-hosting service106can change the game session136to terminated, upload a game session log to storage, and update a fleet utilization to indicate that the game server124has one less process executing132.
As mentioned, the game-hosting service106may deploy a group of instances126, often referred to as a “fleet”138of instances126, on game servers124. In various examples, a fleet138of instances126may all support the same game build118, or the same online game. Each instance126in a fleet138may run multiple processes132simultaneously, depending on the hardware capability, and each server process132can host at least one game session136. Since a game build118can have one or multiple executable files, a developer110and/or the service provider104may configure a fleet138to run multiple server processes132of each executable on each instance126. In order to configure a fleet138of instances126to run one or more processes132, the developer110and/or service provider104may generate configuration data146that describes what processes132run on each instance126in a fleet138. Each instance126in the fleet138launches the server processes132specified in the configuration data146and launches new ones as existing processes132end. Each instance126may regularly check for updated configuration data146and follows the new instructions.
The value-based game session placement techniques described herein may be implemented, at least in part, by a queue component148of the game-hosting service106. The queue component148may receive incoming game session requests associated with players112who are requesting to be matched with other players for playing a multiplayer game. The queue component148may place these incoming game session requests in a queue and may process each game session request to identify a fleet138on which to place a corresponding game session136. When a queued game session request is processed for game session placement, the queue component148may determine attributes of the game session request, which are used to determine (e.g., compute, calculate) one or more values150for game session placement. The value(s)150is/are sometimes referred to herein as a “placement value(s)150” because the value(s)150dictate(s) where a game session is to be placed within the service provider network102. The attributes of the game session request that are used to determine the value(s)150may include, without limitation, player attributes. Player attributes for an individual player112associated with a game session request may include, without limitation, a player identifier (ID), a number of games played over a period of time, whether the player112is a paying player (as opposed to a player that exclusively plays free-to-play games), and, if so, an amount of money spent by the player112over the period of time, an amount of time spent playing games, a time(s) of day that games were played, other players112that were involved in a common match, whether a player ID is a known player ID (e.g., a famous/professional gamer, a known blogger, a game reviewer, a person with an above-threshold number of social media followers, etc.), whether the player has purchased downloadable content (DLC)—which is additional content created for an already-released video game, and the like. In some cases, the service provider104may implicitly derive at least some of the player attributes based on running a subscriber's110game on behalf of the subscriber110within the service provider network102. However, at least some of the player attributes may additionally, or alternatively, be provided by the subscriber110associated with a game session request. Such voluntary submission of player attributes by the subscriber110may help optimize game session placement, so there may be an incentive for the subscriber110to do so.
The attributes of the game session request that are used to determine the value(s)150may additionally, or alternatively, include game attributes, which may be indicative of a game mode, a game situation, a game context, or the like. Game attributes may include, without limitation, whether a game is to be played in a tournament mode or in casual mode, and if the game is to be played in tournament mode, a phase of a tournament (e.g., Phase 3 out of a total of 5 Phases), whether the game is to be live-streamed (i.e., broadcast to one or more viewing users), and if so, a projected number of viewing users in the audience, and the like. In some cases, the service provider104may implicitly derive at least some game attributes based on running a subscriber's110game on behalf of the subscriber110within the service provider network102. However, at least some of the game attributes may additionally, or alternatively, be provided by the subscriber110associated with a game session request. Again, such voluntary submission of game attributes by the subscriber110may help optimize game session placement, so there may be an incentive for the subscriber110to do so.
The queue component148may also determine available fleets138of VM instances126that are allocated to the subscriber110associated with the game session request, and may utilize a session placement algorithm152to determine (e.g., calculate, compute, etc.) the value(s)150for game session placement. The available fleets138may be located across disparate geographical regions, and each may have different performance characteristics based on the region and/or based on the specific hardware and/or configurations of the VM instances126on those fleets138. For example, average player latency may vary across a set of available fleets138for game session placement such that a first fleet138(1) provides relatively lower latency (on average across all of the players112associated with the game session request) and a second fleet138(2) provides relatively higher latency (on average across all of the players112associated with the game session request), or vice versa. This can be based on various factors, as mentioned. In some cases, VM instances126of available fleets138may vary in terms of available capacity and/or current resource utilization. For example, a first fleet138(1) may include a VM instance126running one process, and a second fleet138(2) may include a VM instance126running multiple (e.g., four) processes. This can mean that different instances126of the different fleets138can have different capacities, where the VM instance126running the single process may be able to provide the snappiest response with relatively less jitter during gameplay, and the VM instance126running the multiple processes concurrently may have less capacity to host a new game session, yet it may be able to provide a lower cost for hosting the game session (e.g., at a relatively lower frame rate).
The value(s)150determined for a game session request is/are used to select a fleet138of VM instances126for game session placement. In some embodiments, a single value150(e.g., a score, a metric, etc.) determined from the attributes of a game session request may represent a value within a range of possible values at which a variable can be set, where a maximum value of the range may be indicative of a high-value game session request and/or a strong preference for placing the game session on a particular fleet of VM instances, and a minimum value of the range may be indicative of a low-value game session request and/or a weak preference for placing the game session on a particular fleet of VM instances. In some embodiments, a single placement value150determined from the attributes of a game session request may represent a dollar value (e.g., $0.50, $1.50, etc.) that may be indicative of a monetary value attributable to an entity (e.g., the game developer) that stands to benefit from hosting the game session on a particular fleet of VM instances.
In some embodiments, the attributes of a game session request can be used to determine multiple values150, where each value150of the multiple values150corresponds to an individual fleet138of multiple fleets138that are available for placing a corresponding game session136. For example, a first value150may be determined for a first fleet138(1), the first value150being indicative of a preference for placing the game session136on the first fleet138(1), a second value150may be determined for a second fleet138(2), the second value150being indicative of a preference for placing the game session136on the second fleet138(2), and so on and so forth, depending on the number “P” of fleets138that might be available for placing the game session136, “P” being any suitable integer greater than or equal to 2. In the case of determining multiple placement values150, the values150can represent any suitable type of value. For example, the multiple values150may comprise multiple Boolean values (e.g., true or false, yes or no) that indicate whether it is preferable to place a game session136on a given fleet138or not (e.g., Fleet 1: Yes. Fleet 2: No, etc.). In other examples, the values150may be numerical values within a defined range of values (e.g., a range of [0,100], a normalized range of [0,1], etc.), where the range may be indicative of a weak-to-strong preference for placing the game session on a given fleet138to which the value150is assigned.
For example, a first placement value150of 1 (in a range of [0,1]) may be determined for a first fleet138(1), a second placement value150of 0.5 (in a range of [0,1]) may be determined for a second fleet138(2), and so on and so forth, for any number of P available fleets138(1)-(P). In this example, a value150of 1 for the first fleet138(1) might represent a strong preference for placing the game session136on the first fleet138(1). Meanwhile, a value150of 0.5 for the second fleet138(2) might represent a relatively weaker preference for placing the game session136on the second fleet138(2). In this example, the queue component148may select the first fleet138(1) based on the placement values150determined for the available fleets138(1) and138(2), and the game session136may be hosted on a VM instance126of the selected first fleet138(1) by identifying an idle server process132on the VM instance126and instructing the server process132to host the game session136. As game sessions136are placed, the game session placements may be stored in the data store134, at least until the game sessions136are terminated, as shown inFIG.1. For example,FIG.1illustrates an example where a first game session136(1) has been placed on a first fleet138(1), a second game session136(2) has been placed on a second fleet138(2), and a Qthgame session136(Q) has been placed on a Pthfleet138(P), where “Q” is any suitable integer. It is to be appreciated that multiple game sessions136may be placed on the same fleet138due to the fact that each fleet138instantiates multiple VM instances126, and each VM instance126may execute one or more server processes132, considering that each process132may host one or more game sessions136. Example details of the session placement algorithms152that can be used by the queue component148for value-based game session placement are described in further detail with reference to the following figures. In general, the session placement algorithm152accounts for the attributes of a game session request in determining the value(s)150for game session placement.
In an illustrative example, an incoming game session request may be associated with player attributes that indicate at least one of the players112associated with the game session request has played an above-threshold number (e.g., over 1000) of games within a period of time (e.g., within the past 6 months). In this example, the session placement algorithm152—using a rule-based approach, a machine-learning model(s), etc.—might determine a relatively-high placement value150for this game session request in order to place the corresponding game session on a fleet138that can provide relatively-high performance (e.g., low latency, or an otherwise “snappy” gameplay experience) to the client devices114of the players112of the game session request. In another illustrative example, another incoming game session request may be associated with game attributes that indicate a game is to be live-streamed to an audience, and the session placement algorithm152—using a rule-based approach, a machine-learning model(s), etc.—may determine a relatively-high placement value150for this game session request in order to place the corresponding game session136on a fleet138that can provide relatively-high performance (e.g., low latency, or an otherwise “snappy” gameplay experience) to the client devices114of the players112of the game session request. By contrast, yet another incoming game session request may be associated with players112who are all non-paying players of a casual, free-to-play game. Given these player attributes and game attributes of the game session request, the session placement algorithm152—using a rule-based approach, a machine-learning model(s), etc.—may determine a relatively-low placement value150for this game session request in terms of placing the corresponding game session136on a high-performance fleet138, and/or the value(s)150may include a relatively-high placement value150for a low-performance fleet138that is indicative of a strong preference for placing the corresponding game session136on a fleet138that provides relatively-low performance (e.g., higher latency, as compared to other available fleets138), perhaps at a lower cost (to the subscriber110) of hosting the game session136. Placing a game session136on a low-performance fleet138and/or hosting the game session136with a low-performance configuration (e.g., a relatively low frame rate, a relatively low resolution, etc.) may allow for packing more game sessions onto a single server process132and/or a single VM instance126to lower the cost (to the subscribing game developer110) of hosting the game session136, thereby providing a cost savings for the developer110.
In some embodiments, the value(s)150may be recalculated during a game session136as attributes306change after a start of the game session136. Based on a recalculated value(s)150, a game session136may be replaced onto a different fleet138, such as by transferring the game session136from a hosting process132on a first fleet138(1) to a different process132on a second fleet138(2) where the game session136is resumed on a VM instance126of the second fleet138(2). To avoid an interruption in service to the players112, a real-time data migration procedure may be employed to transfer the game session136with little-to-no interruption.
FIG.2illustrates a component diagram200of an example service provider network102that provides a game-hosting service106that is configured to place game sessions136on fleets138of VM instances126using a value-based approach. As illustrated, the service provider network102may include one or more hardware processors202(processors) configured to execute one or more stored instructions. The processor(s)202may comprise one or more cores. Further, the service provider network102may include one or more network interfaces204configured to provide communications between the service provider network102and other devices, such as the developer device(s)108and/or the client device(s)114. The network interfaces204may include devices configured to couple to PANs, wired and wireless LANs, wired and wireless WANs, and so forth. For example, the network interfaces204may include devices compatible with Ethernet, Wi-Fi™, and so forth.
The service provider network102may also include computer-readable media206that stores various executable components (e.g., software-based components, firmware-based components, etc.). In addition to various components discussed inFIG.1, the computer-readable-media206may further store components to implement functionality described herein. While not illustrated, the computer-readable media206may store one or more operating systems utilized to control the operation of the one or more devices that comprise the service provider network102. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system(s) comprise the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Wash. According to further embodiments, the operating system(s) can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized.
The computer-readable media206may store portions, or components, of the game-hosting service106described herein. For instance, the computer-readable media206may store the developer portal(s)116through which developer(s)110may provide their game builds118, and/or other input for managing their online games and/or for managing the placement of game sessions136on fleets138of VM instances126within the service provider network102. Additionally, the computer-readable media206may store a user interface component208configured to provide portals, user interfaces, and/or other avenues through which clients112and/or subscribers110may interact with information (e.g., account settings) and/or the online games hosted by the game-hosting service106. In some embodiments, the user interface component208may provide interactive elements allowing subscribers110to customize a session placement algorithm(s)152for game session placement, as described herein, and/or to provide attribute data212(e.g., player attributes of their players112, game attributes of their games, etc.) and/or weights associated therewith for use in game session placement.
The computer-readable media206may further store a matchmaking component210configured to, when executed by the processor(s)202, provide various matchmaking functionality for the game-hosting service106. Generally, the matchmaking component210may include a customizable rules engine that allows developers110to design how to match clients112(or players112) together based on player attributes and game modes that are appropriate for the online game. The matchmaking component210may further manage the details for forming player groups for game sessions136, and placing the player groups into active or recently created/initiated game sessions136. As mentioned, the game services140may include its own matchmaking logic. In some embodiments, some matchmaking is performed by the game services140, while additional matchmaking logic may be executed by the matchmaking component210of the service provider network102to augment the matchmaking process.
The computer-readable media206may further store the queue component148introduced inFIG.1. The queue component148may be configured to, when executed by the processor(s)202, manage queues for assigning VM instances to game streaming requests and/or for placing new game sessions136on appropriate or available hosting resources (e.g., instances126) across fleets138and/or geographic regions. Generally, the queue component148search for available streaming resources (e.g., available processes132) on a VM instance used for streaming the game to a given client device114, the VM instance having been selected using the value-based approach described herein (SeeFIGS.10-12). For an incoming game session request involving multiple players112, the matchmaking component210builds on the queue component148because, once a match is created, the matchmaking component210may hand or send the match details to a queue that is managed by the queue component148. The queue component148may then search for available hosting resources (e.g., available processes132) in a fleet138of instances126, the fleet138having been selected using the value-based approach described herein. The queue component148may utilize a streaming instance assignment algorithm215that is configured to determine (e.g., output) one or more values238for assigning a streaming instance to a queued game streaming request, the instance assignment value(s)238indicating a value associated with the game streaming request and/or a preference for using a particular VM instance for streaming a game to a given client device114of a player112associated with the game streaming request. Therefore, the queue component148may provide attributes of a game streaming request as input to the streaming instance assignment algorithm215to determine a value(s)238that is/are used to select a VM instance for game streaming. Also, as mentioned, the queue component148may utilize a session placement algorithm152that is configured to determine (e.g., output) one or more placement values150for placing a game session136on an available fleet138, the value(s)150indicating a value of the game session136and/or a preference for placing the game session136on a particular fleet138. Therefore, the queue component148may provide attributes of a game session request as input to the session placement algorithm152to determine a value(s)150that are used to select a fleet138for game session placement.
The computer-readable media206may further store a session component216that, when executed by the processor(s)202, is configured to query the data store134for idle processes132executing on VM instances126of the selected fleet138, and to assign the queued game session request to an idle process132that will host the game session136. The assignment of processes132to a game session136may occur in various ways. In general, session component216may traverse a list of the available processes132returned in query results, one-by-one, attempting to assign the first process132in the list to the game session request, and if the assignment fails, running down the list, in order, until a process132in the list is successfully assigned to the game session request. If a batch of processes132are assigned in parallel, this assignment procedure may iterate for each game session request until all game session requests are assigned at least one process132. A list of available processes132that are traversed for this assignment procedure may be ordered in any suitable manner. For example, the data store134may keep track of the “age” of executing processes132and, thus, may order query results based on age (e.g., from the oldest process132to the youngest process132, from the youngest process132to the oldest process132, etc.). In this manner, the session component216may scan the list of available processes132with a preference to assign processes132based on the age of the processes132by traversing the list from top-to-bottom. In some embodiments, available processes132in the data store134may be filtered on an age-related criterion (e.g., return available processes132that were created in the last N days, N being any suitable number) to generate query results that include a filtered set of processes132that satisfy the criterion. The data store134is shown as storing the processes132, the attribute data212(e.g., the player attributes, game attributes, etc.), and the placement values150, among other data.
The computer-readable media206may further store a monitoring component222that, when executed by the processor(s)202, collects information for a game session136and logs the information in a storage location for a developer110. For instance, the monitoring component222may identify and collect metrics for game sessions136hosted on an instance126, such as length of the game sessions, players involved, type of game, events occurring in the game, hardware utilization metrics, players leaving and/or entering the game, and/or various other metadata for a game session136that may be of interest to a developer110.
The computer-readable media206may further store an auto-scaling component224that, when executed by the processor(s)202, scales up or down the number of instances126available to host game sessions or other processes132. For example, the auto-scaling component224may provide a fast, efficient, and accurate way to match fleet capacity to player usage. In some examples, the auto-scaling component224may track the fleet's138hosting metrics and determine when to add or remove instances126based on a set of guidelines, called policies, that may be defined by the developer110. The auto-scaling component224can adjust capacity in response to changes in player demand to help ensure that the fleet of instances126has availability for new players without maintaining an excessive amount of idle resources.
To utilize the services provided by the service provider network102, clients112and developers110may register for an account with the service provider network102. For instance, clients112and developers110may utilize a device to interact with an identity and access management (IAM) component226that allows the clients112and developers110to create an account with the service provider network102. Generally, the IAM component226may enable the clients112and developers110to manage access to their cloud-based services and computing resources securely. Using the IAM component226, the developers110may manage their game builds118and/or fleets138of instances126as described herein. Additionally, clients112may interact with their account to, for example, change settings for their gaming experience, management payments, and/or other functions.
The data store134(e.g., object storage) may represent one or more data stores that stores various data described herein at one or more locations in the service provider network102. The data store134may track processes132that are currently executing on VM instances126of the service provider network102. Records for these processes132may include additional data/metadata including, without limitation, an owner (e.g., whether the process is idle and available, or assigned to a game session136(or game session request) as an owner), identifiers of VM instance126, fleet138, subscriber110, etc. The data store134may further include the game builds118for developers110that include game software130and configuration data146, which may be updated at any suitable time by the developer110or otherwise, along with other data described herein. The data store134may further store the attribute data212that specifies attributes associated with game session requests, such as player attributes of players112associated with a game session request, game attributes associated with a game of the game session request, and similar attributes. The data store134may further store the placement values150determined by the session placement algorithm(s)152used for game session placement, queues228in which new player groups or game groups (i.e., game session requests) are queued before being placed into instances126(e.g., and assigned a process132executing thereon), user accounts230for the clients112and/or developers110, subscriber parameter values232, which may dictate attributes of a game session request and/or weights assigned to the attributes for use in value-based game session placement, and fleet data234, which may contain data on fleets138, such as the region of the fleet138, a number of VM instances126and/or processes132spun up on the fleet138, types of instances126, cost of the VM instances126, and other similar fleet attributes. The data store134may further store streaming instance data236, which may contain data on VM instances that are usable for streaming games to client devices114. This data may be included as part of the fleet data234or as separate data. The data store134may further store the instance assignment values238determined by the streaming instance assignment algorithm(s)215used for game streaming.
The computer-readable media206may be used to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the service provider network102. In some examples, the operations performed by the service provider network102, and or any components included therein, may be supported by one or more server devices. Stated otherwise, some or all of the operations performed by the service-provider network102, and or any components included therein, may be performed by one or more computer devices operating in a cloud-based arrangement.
By way of example, and not limitation, computer-readable storage media206can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM. ROM, erasable programmable ROM (“EPROM”), electrically-erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technology, compact disc ROM (“CD-ROM”), digital versatile disk (“DVD”), high definition DVD (“HD-DVD”), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion. The implementation of the various components described herein is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules can be implemented in software, in firmware, in special purpose digital logic, and any combination thereof.
FIG.3illustrates a schematic diagram300of an example technique, implemented by a game-hosting service106, for placing game sessions136on fleets138of VM instances126using a value-based approach. Initially, the game-hosting service106may cause VM instances126to be spun up and to execute associated processes132, at least some of which execute in idle mode so as to be available to host a new game session136. Thus, multiple first server processes132may execute on a fleet138of VM instances126. The fleet of instances126may be allocated to a particular subscriber110of the service provider network102and may be running on computing resources of the service provider network102.
As a number, R, of incoming game session requests302(1)-(R) are received by the game-hosting service106, the game-hosting service106(e.g., via the queue component148) may perform operations to handle the requests302by queuing304the requests302in a queue228. For a given game session request302(1) in the queue228, the queue component148may make a call (e.g., an API call) to get attributes306of the game session request302(1). The attributes306may be maintained in the attribute data212of the data store134, which may be populated with attributes306provided by the subscriber110and/or attributes306determined by the game-hosting service106based on hosting game sessions on behalf of the subscriber110.FIG.3illustrates an example where the attributes306include player attributes306(1) and game attributes306(2). The player attributes306(1) may represent attributes of a set of players112(1)-(S) associated with a first game session request302(1), where “S” is any integer greater than or equal to 2. The player attributes306(1) may be based at least in part on prior gameplay (e.g., prior gameplay of the players112(1)-(S)). Consider an example where players112(1)-(S) were grouped together in a match. In this example, the player attributes306(1) for individual players112may include, without limitation, a player identifier (ID)308, a number of games played310over a period of time, and an amount of money spent312over the period of time. As shown by the ellipses to the right of the player attributes306(1) table, the player attributes306(1) may include additional attributes, such as, without limitation, an amount of time spent playing games, a time(s) of day that games were played, other players112that were involved in a common match with the given player112, whether a player ID is a known player ID (e.g., a famous/professional gamer, a known blogger, a game reviewer, a person with an above-threshold number of social media followers, etc.), whether the player112has purchased DLC, and the like. In the example ofFIG.3, the first player112(1) has played 1000 games over a period of time, while another player112(S) has played 50 games over the period of time. Additionally, the first player112(1) has spent Sxxx over the period of time, or a different period of time, while the other player112(S) has spent Syyy, where “xxx” and “yyy” can be any suitable number.
The game attributes306(2) may represent attributes of a game associated with the game session request302(1). Consider an example where players112(1)-(S) requested to play a tournament game, and that the tournament game includes multiple (e.g., 5) sequential phases, where the players112progress through each phase from Phase 1 to Phase 5. In this example, the game attributes306(2) of the game may include, without limitation, a game mode314, such as whether the game is to be played in a tournament mode or in casual mode, or some other mode, and if the game is to be played in tournament mode, a phase316of the tournament, as well as whether the game is to be live-streamed318(i.e., broadcast to one or more viewing users). As shown by the ellipses to the right of the game attributes306(2) table, the game attributes306(2) may include additional player attributes, such as, without limitation, a projected number of viewing users in the audience of a game that is to be live-streamed, and the like. In the example ofFIG.3, the game associated with the game session request302(1) happens to be a tournament game where the players112(1)-(S) have progressed to Phase 3 out of a total of 5 Phases, and the game is also to be live-streamed to a viewing audience.
It is to be appreciated that, in addition to player attributes306(1) and game attributes306(2), other types of attributes306may be determined. For example, the attributes306may further include attributes of computing devices114used by the players112associated with the game session request302(1), such as a hardware configuration (e.g., model and/or version of graphics processing unit (GPU)), and/or a software configuration (e.g., a version of a graphics driver, etc.). The attributes306may further include attributes of the subscriber110(e.g., the developer of the game), such as number of games developed and deployed via the game-hosting service106, a number of clients112in the subscriber's110user base, etc.
In addition to the attributes306, the game-hosting service106(e.g., via the queue component148) may make a call (e.g., an API call) to get available fleets138allocated to the subscriber110who is associated with the game session request302(1). As shown inFIG.3, fleet data234may be maintained in the data store134to determine the available fleets for placing a game session136(1) corresponding to the game session request302(1). Fleets138may be identified by a fleet ID320, and each fleet138may comprise a set of identical VM instances126having identical properties. For example, the fleets138may vary by region322, as well as by performance metrics, such as, without limitation, average player latency324, capacity326(e.g., a number of concurrently running processes132, or some other utilization metric), and the like. Fleets138may also vary by cost327of the individual instances126in the fleet138. As shown by the ellipses to the right of the available fleets138table, the fleet data234describing properties of the available fleets138may include additional properties in addition to the properties specified inFIG.3. In some cases, a fleet138can be characterized by way of a tiered ranking system (e.g., low-tier, mid-tier, high-tier). A high-tier fleet138may be a fleet138with an above-threshold capacity, or one that can provide a user experience at a below-threshold average player latency. Fleets138may be classified into low-tier, mid-tier, or high-tier based on any suitable property (e.g., performance metric(s)) to indicate which are considered to be higher-performing, or higher-quality (and/or higher cost), fleets138and which are considered to be lower-performing, or lower-quality (and/or lower-cost), fleets138. As such, the user experience of the players112may vary depending on where the game session136(1) is placed, and/or depending on the configuration with which the game session136(1) is hosted (e.g., a frame rate and/or resolution at which the game is hosted, etc.).
With the attributes306and the available fleets138determined, the game-hosting service106(e.g., via the queue component148) may determine one or more values150for the game session request302(1) (e.g., multiple values150, each value corresponding to an individual fleets138) based on the attributes306. For example, the attributes306may be provided as input328to a session placement algorithm152, and the output330of the session placement algorithm152may include one or more values150indicative of a value of the game session request302(1) and/or a preference for placing the corresponding game session136(1) on a particular fleet138. In the example ofFIG.3, a number of P values150are determined for a number of P available fleets138.
In some embodiments, the session placement algorithm152may utilize one or more rules332to determine placement values150based on the attributes306provided as input to the session placement algorithm152. For example, a rule332may specify that, if the player attributes306(1) indicate a player112has played an above-threshold number of games (e.g., 1000 games or more) over a period of time, the placement value150for a high-tier fleet138may be set to a maximum value (e.g., a value of 1 on a scale [0,1]). The same rule332, or a different rule332, may specify that, if the player attributes306(1) indicate that the players112have all played a below-threshold number of games over the period of time, the placement value150for a low-tier fleet138may be set to a maximum value (e.g., a value of 1 on a scale of [0,1]), and/or the placement value150for a high-tier fleet138may be set to a relatively lower value on the scale. In some embodiments, a rule332may be expressed as a function(s) (e.g., a mathematical function, such as a linear or non-linear equation) that computes a value(s)150based on quantifiable attributes306that are provided as input to the function(s). Such quantifiable attributes306may include, for example, a number of games played, an amount of money spent, etc. In some embodiments, a different function may be defined for each available fleet138in order to compute a value150that is specific to each fleet138. For example, a quantifiable attribute306may be provided as input to a first function that computes a first value150for a first fleet138(1), the quantifiable attribute306may also be provided as input to a second function that computes a second value150for a second fleet138(2), and so on and so forth, depending on the number of available fleets138. In this manner, the session placement algorithm152may determine one or more values150that dictate where a game session136(1) is to be placed. For example, the queue component148may select the fleet138(1) with the highest value150of the “P” values shown inFIG.3as the fleet138(1) on which the game session136(1) is to be placed, and an idle server process132executing on a VM instance126of the selected fleet138(1) may be assigned to the game session136(1) for hosting the server component of the game session136(1).
In some embodiments, the session placement algorithm152may represent a machine learning model(s)334that is configured to receive attributes306as input328and to generate output330that assigns scores to available fleets138. Machine learning generally involves processing a set of examples (called “training data”) in order to train a machine learning model(s). A machine learning model(s), once trained, is a learned mechanism that can receive new data as input and estimate or predict a result as output. For example, a trained machine learning model can comprise a classifier that is tasked with classifying unknown input (e.g., an unknown image) as one of multiple class labels (e.g., labeling the image as a cat or a dog). In some cases, a trained machine learning model is configured to implement a multi-label classification task (e.g., labeling images as “cat,” “dog,” “duck.” “penguin,” and so on). Additionally, or alternatively, a trained machine learning model can be trained to infer a probability, or a set of probabilities, for a classification task based on unknown data received as input. In the context of the present disclosure, the unknown input328may be the attributes306(or attribute data212), as described herein, which is associated with a game session request302, and the trained machine learning model(s)334may be tasked with outputting a set of values (e.g., one, two, or more values, scores, metrics), referred to herein as placement values150, where each placement value150output by the machine learning model(s)334is indicative of a preference for placing the game session136on a fleet138(e.g., on a fleet138corresponding to the placement value150). In some embodiments, the placement value150may be viewed as a probability of the fleet138being an optimal placement for the game session136. In the event that two or more fleets138have the same placement value150, the tie may be broken by considering other factors, such as by selecting the fleet138with the lowest average player latency, and/or selecting the fleet138with the lowest-cost VM instance126running an idle server process(es)132.
In examples where the session placement algorithm152is implemented as a trained machine learning model(s)334, such a trained machine learning model(s)334may represent a single model or an ensemble of base-level machine learning models, and may be implemented as any type of machine learning model. For example, suitable machine learning models for use with the techniques and systems described herein include, without limitation, neural networks, tree-based models, support vector machines (SVMs), kernel methods, random forests, splines (e.g., multivariate adaptive regression splines), hidden Markov model (HMMs), Kalman filters (or enhanced Kalman filters), Bayesian networks (or Bayesian belief networks), expectation maximization, genetic algorithms, linear regression algorithms, nonlinear regression algorithms, logistic regression-based classification models, or an ensemble thereof. An “ensemble” can comprise a collection of machine learning models whose outputs (predictions) are combined, such as by using weighted averaging or voting. The individual machine learning models of an ensemble can differ in their expertise, and the ensemble can operate as a committee of individual machine learning models that is collectively “smarter” than any individual machine learning model of the ensemble.
The training data that is used to train a machine learning model(s)334may include various types of data. In general, training data for machine learning can include two components: features and labels. However, the training data used to train the machine learning model(s) may be unlabeled, in some embodiments. Accordingly, the machine learning model(s) may be trainable using any suitable learning technique, such as supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, and so on. The features included in the training data can be represented by a set of features, such as in the form of an n-dimensional feature vector of quantifiable information about an attribute of the training data, such as any of the attributes306described herein, and/or attributes of fleets138of VM instances.
FIG.4illustrates a schematic diagram400showing how a subscriber(s)110of the service provider network102may provide data for customizing a session placement algorithm152used by the game-hosting service106(e.g., via the queue component148) for game session placement. As mentioned, developers110may provide data to the game-hosting service106through the developer portal(s)116, such as by uploading the data over one or more networks120.
FIG.4depicts a first subscriber110(1) using a first subscriber device108(1) to send attributes306to the game-hosting service106, such as player attributes306(1) of their players112and/or game attributes306(2) of their games. These attributes306may be stored as attribute data212and used by the session placement algorithm152for the subscriber110(1) to determine placement values150during game session placement. In some embodiments, the subscriber-provided attributes306may be used to train a machine-learning model(s)334used as the session placement algorithm152.FIG.4also depicts a second subscriber110(2) using a second subscriber device108(2) to send a customized session placement algorithm402to the game-hosting service106. This customized algorithm402might be specified as a customized set of rules332, such as rules332that define criteria for valuing game session requests302at certain placement values150. The customized algorithm402might additionally, or alternatively, define a type of machine learning model(s)334that is to be utilized for game session placement by training the machine learning model(s)334on a sample set of the subscriber's110own data.FIG.4also depicts a third subscriber110(3) using a third subscriber device108(3) to send weights404to the game-hosting service106. These weights404may be assigned to particular attributes306used for game session placement. For example, the subscriber110(3) may choose to weight a “number of games played310” attribute more heavily than “an amount of money spent312” attribute. With these weights404, the session placement algorithm152may be customized to the subscriber's110(3) preferences in order to place more control in the hands of the subscriber110for game session placement. Any or all of the data received by the game-hosting service106inFIG.4may be used to update subscriber parameter values232in the data store134so that a customized session placement algorithm152can be created for a subscriber110.
The processes described herein are illustrated as a collection of blocks in a logical flow graph, which represent a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order and/or in parallel to implement the processes.
FIG.5illustrates a flow diagram of an example process500for using a value-based approach to place a game session136on a fleet138of VM instances126. For discussion purposes, the process500is described with reference to the previous figures.
At502, a queue component148of the game-hosting service106may queue304a game session request302in a queue228. Said another way, the game session request302may be placed in a queue228. This is depicted schematically inFIG.3. The game session request302may be associated with a subscriber110of a service provider network102. The subscriber110may represent a game developer of an online, multiplayer video game (or, game). Therefore, the game session request302may correspond to a game of the subscriber110. Furthermore, the game session request302may be associated with a set of multiple players112(1)-(S) who may have been matched together based on a matchmaking algorithm. Accordingly, the game session request302may also request player sessions for each player112included in the request302.
At504, the queue component148may determine one or more attributes306of the game session request302queued at block502. The queue component148may access attribute data212(e.g., from the data store134) in order to determine the attributes306at block504. In some embodiments, the queue component148may make a call (e.g., an API call) to get the attributes306at block504. In some examples, at least some of the attribute data212may have been provided by the subscriber110voluntarily. In some examples, at least some of the attribute data212may have been derived by the game-hosting service106from hosting past game sessions136on behalf of the subscriber110. As shown by sub-blocks506and508, the attributes306may include, without limitation, player attributes306(1) and/or game attributes306(2).
Accordingly, at506, the queue component148may determine player attributes306(1) of players112associated with the game session request302. As described herein, player attributes306(1) for an individual player112of the set of players112(1)-(S) may be based at least in part on prior gameplay of the player112, and may include, without limitation, a player ID308(e.g., an account name, an account number, a player alias, etc.), a number of games played310over a period of time, whether the player112is a paying player (as opposed to a player that exclusively plays free-to-play games), and, if so, an amount of money spent312by the player112over the period of time, an amount of time spent playing games, a time(s) of day that games were played, other players112that were involved in a common match, whether a player ID is a known player ID (e.g., a famous/professional gamer, a known blogger, a game reviewer, a person with an above-threshold number of social media followers, etc.), whether the player has purchased DLC, and the like.
Additionally, or alternatively, at508, the queue component148may determine game attributes306(2) of a game corresponding to the game session request302. Game attributes306(2) may be indicative of a game situation, a game context, or the like, and may include, without limitation, a game mode314(e.g., whether a game is to be played in a tournament mode or in casual mode), and if the game is to be played in tournament mode, a phase316of a tournament (e.g., Phase 3 out of a total of 5 Phases), whether the game is to be live-streamed318(i.e., broadcast to one or more viewing users), and if so, a projected number of viewing users in the audience, and the like.
At510, the queue component148may determine available fleets138of VM instances126that are allocated to the subscriber110. The queue component148may access fleet data234(e.g., from the data store134) in order to determine the available fleets138at block510. In some embodiments, the queue component148may make a call (e.g., an API call) to get the available fleets138(or fleet data234pertaining thereto) at block510. As described herein, a subscriber110may be allocated multiple fleets138of VM instances126that are located across disparate regions as part of a subscription to the game-hosting service106of the service provider network102. Accordingly, the operations performed at block510may include determining at least a first fleet138(1) of VM instances126(in a first region) allocated to the subscriber110, and determining a second fleet138(2) of VM instances126(in a second region) allocated to the subscriber110. In addition, the various fleets identified at block510may be characterized by different performance metrics, such as latency, capacity, current utilization, etc. For example, a first fleet138(1) (or, an available instance126thereon) may provide a first average latency to the players112associated with the request302, a second fleet138(2) (or, an available instance126thereon) may provide a second average latency to the players112, and so on and so forth, depending on the number, P, of available fleets138. As another example, the VM instances126of the available fleets138determined at block510may vary in terms of available capacity and/or current resource utilization. For example, a first fleet138(1) may include a VM instance126running one process, and a second fleet138(2) may include a VM instance126running multiple (e.g., four) processes. This can mean that different instances126of the different fleets138can have different capacities, where the VM instance126running the single process may be able to provide the snappiest response with relatively less jitter during gameplay, and the VM instance126running the multiple processes concurrently may have less capacity to host a new game session, yet it may be able to provide a lower cost for hosting the game session (e.g., at a relatively lower frame rate, a relatively lower resolution, etc.).
At512, the queue component148may determine a value(s)150based at least in part on the attributes306of the game session request302determined at block504. In some embodiments, the value(s)150may be determined at block512using a session placement algorithm152, as described herein. A session placement algorithm152may be a rule-based algorithm that evaluates one or more rules332. For example, a rule-based algorithm152may evaluate whether any of the players112(1)-(S) have played an above-threshold number of games over a period of time via the game-hosting service106, and/or whether any of the players112(1)-(S) have spent an above-threshold amount of money over the period of time via the game-hosting service, and similar rules. Thus, one or more rules can be evaluated based on the attributes306at block512. Additionally, or alternatively, a session placement algorithm152may be a machine-learning-based algorithm that provides the attributes306as input328to a trained machine learning model(s)334, as described herein. The output330of the trained machine learning model(s)334may be one or more values150at block512. In some embodiments, the value(s)150may be determined, at block512, based at least in part on properties of the available fleets138specified in the fleet data234, such as properties including, without limitation, average player latencies324of the available fleets138, capacities326(e.g., a number of concurrently running processes132, or some other utilization metric) of the available fleets138, cost327of instances126in the available fleet138, and the like.
At514, the queue component148may determine multiple values150, one value150per fleet138of the multiple available fleets138determined at block510. For example, the queue component148may determine, based on the attributes306, a first value150associated with the first fleet138(1), a second value150associated with a second fleet138(2), and possibly additional values150for additional fleets138. Here, the first value150may be indicative of a first preference for placing the corresponding game session136on the first fleet138(1), and the second value150may be indicative of a second preference for placing the game session136on the second fleet138(2), where the second preference may be a stronger or weaker preference, or the same preference (if the multiple values150are equal), as the first preference.
At516, the queue component148may select, based at least in part on the value(s)150determined at block512, a fleet138(e.g., the first fleet138(1) or the second fleet138(2)) as a selected fleet138. The selection at block516may be based at least in part on a comparison between multiple values determined at block514(e.g., a comparison between a first value150for the first fleet138(1) and the second value150for the second fleet138(2)). For example, if the first value150is greater than the second value150, the queue component148may select the fleet138associated with the greater, first value150. The selection at block516may be based on a comparison between fleet properties (e.g., performance metrics) of the available fleets138(e.g., a comparison between a first average latency that the first fleet138(1) provides to the players112and a second average latency that the second fleet138(2) provides to the players112). Accordingly, at block516, the queue component148may determine average latencies (and/or other fleet/instance properties such as capacity (and/or other performance metrics), cost, etc.) of multiple fleets138, such as a first average latency that the first fleet138(1) provides to the players112, a second average latency that the second fleet138(2) provides to the players112, and possibly additional average latencies, depending on the number of fleets138evaluated. If a first average latency is less than a second average latency, the queue component148may select the fleet138associated with the lower average latency (or the higher average latency, depending on how the value-based session placement is configured). In some embodiments, the value(s)150determined at block512may be based at least in part on fleet data234that specifies the fleet/instance properties of each available fleet138. In this way, the selection of the fleet138at block516can be based on the value(s)150, which, in turn, is/are based on the properties of the available fleets138(e.g., average latencies, capacities, costs, etc.).
At518, the queue component148may select, based at least in part on the value(s)150, a configuration of multiple available configurations as a selected configuration. For example, the queue component148may have a choice between hosting the game session136at different frame rates (e.g., 30 FPS, 15 FPS, etc.), and/or at different resolutions (e.g., 1080P, 4K, etc.). Accordingly, the selection at block518may involve selecting a frame rate of multiple available frame rates as a selected frame rate, and/or selecting a resolution of multiple available resolutions as a selected resolution, etc.
At520, the queue component148may host a game session136corresponding to the game session request302on a VM instance126of the selected fleet138, and may host the game session136with the selected configuration (e.g., at the selected frame rate). In order to host the game session136at block520, an available process132spun up on the VM instance126may be assigned to the game session request302, and the assigned process132may be instructed to host the game session136on the VM instance126.
FIG.6illustrates a flow diagram of an example process600for creating a customized session placement algorithm152for a subscriber110of a service provider network102. For discussion purposes, the process600is described with reference to the previous figures.
At602, the game-hosting service106may receive, from a subscriber device108associated with a subscriber110, data for customizing a session placement algorithm152used for placing game sessions136. A schematic diagram showing examples of the data that can be provided at block602is depicted inFIG.4. Accordingly, sub-blocks604-608are directed to example types of data that can be received at block602for customizing a session placement algorithm152.
At604, the game-hosting service106may receive one or more customized session placement rules332. The customized rule(s)332may specify one or more criteria that are to be met, and if the one or more criteria are met, a value(s)150that is to be determined for an associated game session request302. Therefore, the customized rule(s)332may be designed to evaluate the attributes306of an incoming game session request302to determine if the one or more criteria are met. An example rule may specify that a criterion is met if at least one player112has played an above-threshold number of games (e.g., over 1000 games) over a period of time. The example rule may also specify that if the criterion is met, a value150for the game session request302is to be set at a particular value (e.g., a value of 1 on a scale of [0,1].
At606, the game-hosting service106may receive a customized machine learning model(s)334. For example, the subscriber110may select a type of machine learning model(s), or an ensemble of models, that the subscriber110would like the game-hosting service106to utilize during value-based game session placements, as described herein.
At608, the game-hosting service106may receive one or more weights assigned to individual ones of multiple attributes306that can be evaluated by a session placement algorithm152during game session placement. For example, the subscriber110may assign weights to particular player attributes306(1) to indicate which player attributes306(1) they want to influence the session placement algorithm152, and how much they want those attributes306(1) to influence the algorithms152placement determination. The subscriber110may assign weights to particular game attributes306(2) in addition, or in the alternative.
At610, the game-hosting service106may create a customized session placement algorithm152for the subscriber110based at least in part on the data received at block602. For example, the game-hosting service106(e.g., via the queue component148) may implement the customized session placement rules as a customized session placement algorithm152to determine the value(s)150at block512of the process500, and/or the game-hosting service106may train a machine-learning model(s)334chosen by the subscriber110using sample data of the subscriber110(or sample data of another subscriber(s)110of the service provider network102. As yet another example, the game-hosting service106may create a weighted mathematical function (e.g., a weighted summation), or may utilize the weights404to train a machine learning model(s) using attributes306as features of the training data.
FIG.7is a system and network diagram that shows an illustrative operating environment702that includes a service provider network102that can be configured to implement aspects of the functionality described herein. The service provider network102can provide computing resources, like VM instances and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources122provided by the service provider network102may be utilized to implement the various services described above. As also discussed above, the computing resources provided by the service provider network102can include various types of computing resources, such as data processing resources like VM instances, data storage resources, networking resources, data communication resources, network services, and the like.
Each type of computing resource provided by the service provider network102can be general-purpose or can be available in a number of specific configurations. For example, data processing resources can be available as physical computers or VM instances in a number of different configurations. The VM instances can be configured to execute applications, including web servers, application servers, media servers, database servers, gaming applications, some or all of the network services described above, and/or other types of programs. Data storage resources can include file storage devices, block storage devices, and the like. The service provider network102can also be configured to provide other types of computing resources not mentioned specifically herein.
The computing resources provided by the service provider network102may be enabled in one embodiment by one or more data centers704A-704N (which might be referred to herein singularly as “a data center704” or in the plural as “the data centers704”). The data centers704are facilities utilized to house and operate computer systems and associated components. The data centers704typically include redundant and backup power, communications, cooling, and security systems. The data centers704can also be located in geographically disparate locations, or regions706. One illustrative embodiment for a data center704that can be utilized to implement the technologies disclosed herein will be described below with regard toFIG.8.
The clients112and developers110that utilize the service provider network102may access the computing resources provided by the service provider network102over any wired and/or wireless network(s)120, which can be a wide area communication network (“WAN”), such as the Internet, an intranet or an Internet service provider (“ISP”) network or a combination of such networks. For example, and without limitation, a client device114operated by a client112of the service provider network102may be utilized to access the service provider network102by way of the network(s)120. It should be appreciated that a local-area network (“LAN”), the Internet, or any other networking topology known in the art that connects the data centers704to remote clients and other users can be utilized. It should also be appreciated that combinations of such networks can also be utilized.
As illustrated, as game session requests302associated with clients112are received, a queue component148may queue the incoming requests302and process individual requests302to place corresponding game sessions136using a value-based approach. For example, the queue component148may utilize a session placement algorithm152, as described herein with reference to the various embodiments.
FIG.8is a computing system diagram800that illustrates one configuration for a data center704that implements aspects of the technologies disclosed herein. The example data center704shown inFIG.8includes several server computers802A-802F (which might be referred to herein singularly as “a server computer802” or in the plural as “the server computers802”) for providing computing resources804A-804E. In some examples, the resources804and/or server computers802may include, be included in, or correspond to, the computing resource network122described herein.
The server computers802can be standard tower, rack-mount, or blade server computers configured appropriately for providing the computing resources described herein (illustrated inFIG.8as the computing resources804A-804E). As mentioned above, the computing resources provided by the service provider network102can be data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some of the servers802can also be configured to execute a resource manager806capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager806can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer802. Server computers802in the data center704can also be configured to provide network services and other types of services.
In the example data center704shown inFIG.8, an appropriate LAN808is also utilized to interconnect the server computers802A-802F. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between each of the data centers704A-704N, between each of the server computers802A-802F in each data center704, and, potentially, between computing resources in each of the server computers802. It should be appreciated that the configuration of the data center704described with reference toFIG.8is merely illustrative and that other implementations can be utilized.
The data center704shown inFIG.8also includes a server computer802F that can execute some or all of the software components described above. For example, and without limitation, the server computer802F (and the other server computers802) can generally correspond to a server configured to execute components of the game-hosting service106including, without limitation, the queue component148that implements the session placement algorithm152, and/or the other software components described above. The server computer802F can also be configured to execute other components and/or to store data for providing some or all of the functionality described herein. In this regard, it should be appreciated that the services illustrated inFIG.8as executing on the server computer802F can execute on many other physical or virtual servers in the data centers704in various embodiments. Thus, the data center704inFIG.8may also include a plurality of server computers802that execute a fleet138of VM instances126, which are executing processes132to host game sessions136for online games.
FIG.9shows an example computer architecture for a computer900capable of executing program components for implementing the functionality described above. The computer architecture shown inFIG.9illustrates a server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. In some examples, the server computer900may correspond to one or more computing devices that implements the game-hosting service106described inFIG.1.
The computer900includes a baseboard902, or “motherboard,” which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”)904operate in conjunction with a chipset906. The CPUs904can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer900.
The CPUs904perform operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and the like.
The chipset906provides an interface between the CPUs904and the remainder of the components and devices on the baseboard902. The chipset906can provide an interface to a RAM908, used as the main memory in the computer900. The chipset906can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”)910or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer900and to transfer information between the various components and devices. The ROM910or NVRAM can also store other software components necessary for the operation of the computer900in accordance with the configurations described herein.
The computer900can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network908. The chipset906can include functionality for providing network connectivity through a NIC912, such as a gigabit Ethernet adapter. The NIC912is capable of connecting the computer900to other computing devices over the network808(or120). It should be appreciated that multiple NICs912can be present in the computer900, connecting the computer to other types of networks and remote computer systems.
The computer900can be connected to a mass storage device918that provides non-volatile storage for the computer. The mass storage device918can store an operating system, programs (e.g., the game-hosting service106and sub-components thereof, including, without limitation, queue component148that utilizes the session placement algorithm152), and data, which have been described in greater detail herein. The mass storage device918can be connected to the computer900through a storage controller914connected to the chipset906. The mass storage device918can consist of one or more physical storage units. The storage controller914can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.
The computer900can store data on the mass storage device918by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the mass storage device918is characterized as primary or secondary storage, and the like.
For example, the computer900can store information to the mass storage device918by issuing instructions through the storage controller914to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. The computer900can further read information from the mass storage device918by detecting the physical states or characteristics of one or more particular locations within the physical storage units.
In addition to the mass storage device918described above, the computer900can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer900. In some examples, the operations performed by the network-based service platform102, and or any components included therein, may be supported by one or more devices similar to computer900. Stated otherwise, some or all of the operations performed by the service provider network102, and or any components included therein, may be performed by one or more computer devices900operating in a network-based arrangement.
By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM (“EPROM”), electrically-erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technology, compact disc ROM (“CD-ROM”), digital versatile disk (“DVD”), high definition DVD (“HD-DVD”), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.
As mentioned briefly above, the mass storage device918can store an operating system utilized to control the operation of the computer900. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Wash. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The mass storage device918can store other system or application programs and data utilized by the computer900.
In one embodiment, the mass storage device918or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer900, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer900by specifying how the CPUs904transition between states, as described above. According to one embodiment, the computer900has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer900, perform the various processes described above with regard toFIGS.1-6. The computer900can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.
The computer900can also include one or more input/output controllers916for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, an input/output controller916can provide output to a display, such as a computer monitor, a flat-panel display, a digital projector, a printer, or other type of output device. It will be appreciated that the computer900might not include all of the components shown inFIG.9, can include other components that are not explicitly shown inFIG.9, or might utilize an architecture completely different than that shown inFIG.9. As shown inFIG.9, a queue component148may utilize a session placement algorithm152for game session placement, as described herein.
FIG.10illustrates a system-architecture diagram of an example environment1000in which a game-streaming service1006of a service provider network1002can assign VM instances to game streaming requests using a value-based approach. As illustrated, the service provider network1002may be operated and/or managed by the service provider104. The service provider network1002ofFIG.10may be similar to the service provider network102described with reference toFIG.1in that it may provide various services to users to fulfill their computing resource needs, such as cloud-based computing resources. In this sense, the service provider network1002may include some or all of the components and/or functionality of the service provider network102described elsewhere herein. Furthermore, as illustrated inFIG.10, the service provider network1002may also provide a game-streaming service1006that is a scalable, cloud-based runtime environment for streaming games to client devices114of players112. The game-streaming service1006may be implemented as part of, or in conjunction with, the game-hosting service106ofFIG.1in order to deploy, operate, and scale streaming servers and session-based multiplayer game servers in a cloud-based, or network-based, environment. For example, the game-streaming service1006may provide the hardware to stream games to client devices114, to host the game sessions for multiple players involved in a game session, and to manage ongoing activity, security, storage, and performance tracking. Additionally, the game-streaming service106may provide auto-scaling capabilities such that instances supporting game streaming and/or instances supporting game sessions can be spun up or spun down based on player demand.
Once a subscriber/developer110has uploaded their game build118via the developer portal116, the game-streaming service1006may deploy game software (e.g., the game software130shown inFIG.1) for the subscriber's game to one or more game servers124in the computing-resource network122. Reference can be made toFIG.1for an understanding of the one or more game servers124and their operation for hosting game sessions136.
FIG.10also depicts computing-resource networks1022(1)-(V), where “V” is any integer greater than or equal to 2 (referred to herein collectively as “computing-resource networks1022”). These computing-resource networks1022may include data centers that each include one or more computing resources, such as VM instances1026. Although the computing-resource networks1022(1)-(V) are shown separately inFIG.10, it is to be appreciated that the computing-resource networks1022(1)-(V) may represent one or multiple computing-resource networks1022. Computing-resource network1022(1) is shown as including one or more VM instances1026(1)(1) to1026(1)(N), where “N” is any suitable integer, computing-resource network1022(2) is shown as including one or more VM instances1026(2)(1) to1026(2)(P), where “P” is any suitable integer, and computing-resource network1022(V) is shown as including one or more VM instances1026(V)(1) to1026(V)(Q), where “Q” is any suitable integer. The data centers in the computing-resource networks1022(1)-(V) may house game server(s)1024(1)-(V) and may be located across disparate geographical regions such that computing resources are available to support functionality for cloud-based services provided by the service provider network1002. The servers1024may be used for streaming games to client devices114of players112, such as by executing a VM instance(s)1026to render frames and to send the frames to a client device114, as well as for receiving control data from the client device114based on a player(s)112proving user input to the client device114. The computing resources of a computing resource network1022may include various combinations of hardware-based components, such as CPU, GPU, memory, storage, network capacity, security, and/or any other type of hardware-based resource to support cloud-based services, such as the game-streaming service1006. In some examples, a computing resource network1022may further include respective memories that store various firmware-based and/or software-based resources that provide the functionality of the services, such as the instances1026. Similar to the description ofFIG.1, a VM instance1026may execute an agent128, the game software130of a subscriber's110game, and/or one or more processes132to support streaming a game to a client device114. An agent128may be responsible for handling various processes on an instance1026, such as spinning up an instance1026, spinning down an instance1026, handling lifetime processes of the instance1026, retrieving game streaming assignments for processes132executing on the instance1026, executing processes132on the instance1026to stream a game to a client device114, managing resources of the instance1026, installing patches and/or other software on the instance1026and/or various other actions for managing the instance126.
FIG.10also depicts the data store134described inFIG.1. The data store134may, among other things, keep track of the assignment of VM instances1026to game streaming requests. To request to stream a game, players112may utilize their client devices114(e.g., applications, software, or other programs executing thereon) to request (e.g., via an API call) that the game-streaming service1006assign them a VM instance1026for streaming the game to their client devices114. Accordingly, upon receiving a game streaming request, the game-streaming service1006may be tasked with identifying and selecting a VM instance1026to serve as a “streaming instance” for streaming the game to the client device114of the player112associated with the incoming game streaming request. The game-streaming service1006may have already spun up VM instances1026that are allocated for various subscribers110of the service provider network1002, and each of the spun up VM instances1026may have server processes132executing thereon in idle mode until the processes132are assigned to a game streaming request for streaming a game to a client device114until a corresponding game session136ends. Other than loading maps and other data for streaming a particular game, these idle processes132may be ready to start streaming a game as soon as they are assigned to a game streaming request. The game-streaming service1006may be tasked with assigning an available VM instance1026allocated to a subscriber110, and to identify a server process132executing on the selected VM instance1026, which will serve a player112who is streaming a game to his/her client device114.
The assignment of a VM instance1026to a game streaming request may be a first phase of a two-phase process. A second phase of the two-phase process may be placing a corresponding game session136(e.g., for multiple players112including the player112who is streaming the game) on a fleet138of a game server124, as described herein. When a game session136is created, the assigned process132executing on a VM instance126of the selected fleet138may be instructed to host (or support) the created game session136for one or more clients112of the subscriber110that are associated with the game session136, and the game may be streamed to one or more of the client devices114of the clients112involved in the game session136. The client application(s) running on the client device(s)114associated with the game session may receive connection information (e.g., a port of a server1024, an IP address, etc.), and may create a game streaming connection(s)1044by connecting directly, over the network(s)120, to the open game streaming server1024using a player session ID(s). The VM instance1026used for streaming the game may then receive connection information (e.g., a port of a server124, an IP address, etc.), and may create a connection(s) by connecting directly to the open game server124using the player session ID(s). If connected, the player session is set to active and the client(s)112begins playing the game that is being streamed to their client device(s)114and the game streaming connection1044that is established between the game streaming server1024that has the instance1026with the process132executing to stream the game (e.g., render frames, send the frames to the client device114, receive control data, etc.).FIG.10depicts separate game streaming connections1044(1),1044(2), and1044(R) for client devices114(1),114(2), and114(R), respectively, which may connect each client device114to its own, dedicated streaming VM instance1026. Meanwhile, the server process132executing on an instance126of a game server124may host the game session136for multiple players. Once a game session136has ended (e.g., clients112quit, the game ends, time out, etc.), the client application on each of the involved client devices114may disconnect from the process132, and the game-streaming service1006can change the game session136to terminated, upload a game session log to storage, and update a fleet utilization to indicate that the game servers1024and1024have one less process executing132.
The value-based streaming instance assignment techniques described herein may be implemented, at least in part, by the queue component148described herein, and/or possibly by another component of the game-streaming service1006. The queue component148may receive incoming game streaming request associated with a player112who is requesting to stream a game to his/her client device114. This player112may also request to be matched with other players for playing the game in multiplayer mode. The queue component148may place incoming game streaming requests in a queue and may process each game streaming request to identify a VM instance1026to assign to the game streaming request. When a queued game streaming request is processed for assigning a VM instance1026thereto, the queue component148may determine attributes of the game streaming request, which are used to determine (e.g., compute, calculate) one or more values238for streaming instance assignment. The value(s)238is/are sometimes referred to herein as a “instance assignment value(s)238” because the value(s)238dictate(s) from where a game is to be streamed to a client device114. The attributes of the game session request that are used to determine the value(s)238may include, without limitation, player attributes306(1), game attributes306(2), and/or other types of attributes, which are described in detail herein.
The queue component148may also determine available VM instances1026that are allocated to the subscriber110associated with the game streaming request, and may utilize a streaming instance assignment algorithm215to determine (e.g., calculate, compute, etc.) the value(s)238for streaming instance assignment. The available VM instances1026may be located across disparate geographical regions, and each may have different performance characteristics based on the region and/or based on the specific hardware and/or configurations of the VM instances1026. For example, latency may vary across a set of available VM instances1026for game streaming such that a first VM instance1026(1)(1) provides relatively lower latency to a client device114(1) and a second VM instance1026(2)(1) provides relatively higher latency to the client device114(1), or vice versa. This can be based on various factors, as mentioned. In some cases, the available VM instances1026(1)(1) to1026(V)(Q) may vary in terms of available capacity and/or current resource utilization. For example, a first VM instance1026(1)(1) may be running one process, and a second VM instance1026(2)(1) may be running multiple (e.g., four) processes. This can mean that different instances1026can have different capacities, where the VM instance1026running the single process may be able to provide the snappiest response with relatively less jitter during game streaming, and the VM instance1026running the multiple processes concurrently may have less capacity to stream a game to the client device114(1), yet it may be able to provide a lower cost for streaming the game (e.g., at a relatively lower frame rate). It is to be appreciated that the streaming instance assignment algorithm215may be customized by the subscriber110in a similar manner to customization of the session placement algorithm152described with reference toFIGS.4and6herein.
The value(s)238is/are used to select a VM instances1026for streaming a game to a given client device114associated with the game streaming request. In some embodiments, a single value238(e.g., a score, a metric, etc.) determined from the attributes of a game streaming request may represent a value within a range of possible values at which a variable can be set, where a maximum value of the range may be indicative of a high-value game streaming request and/or a strong preference for streaming the game using a particular VM instance1026, and a minimum value of the range may be indicative of a low-value game streaming request and/or a weak preference for streaming the game using a particular VM instances1026. In some embodiments, a single value238determined from the attributes of a game streaming request may represent a dollar value (e.g., $0.50. $1.50, etc.) that may be indicative of a monetary value attributable to an entity (e.g., the game developer) that stands to benefit from streaming the game to a given client device114using a particular VM instance1026.
In some embodiments, the attributes of a game streaming request can be used to determine multiple values238, where each value238of the multiple values238corresponds to an individual VM instance1026of multiple VM instances1026that are available for game streaming. For example, a first value238may be determined for a first VM instance1026(1)(1), the first value238being indicative of a preference for streaming a game to a client device114using the first VM instance1026(1)(1), a second value238may be determined for a second VM instance1026(2)(1), the second value238being indicative of a preference for streaming a game to a client device114using the second VM instance1026(2)(1), and so on and so forth, depending on the number of instances1026that might be available for game streaming. In the case of determining multiple placement values238, the values238can represent any suitable type of value. For example, the multiple values238may comprise multiple Boolean values (e.g., true or false, yes or no) that indicate whether it is preferable to stream a game to a client device114using a given VM instance (VMI)1026or not (e.g., VMI 1: Yes, VMI 2: No, etc.). In other examples, the values238may be numerical values within a defined range of values (e.g., a range of [0,100], a normalized range of [0,1], etc.), where the range may be indicative of a weak-to-strong preference for streaming a game to a client device114using a given VM instance1026to which the value238is assigned.
As mentioned, the assignment of a streaming instance1026may be a first phase of a multi-phase process. In this example, the queue component148, as part of a second phase, may select a fleet138based on a placement value(s)150determined for the available fleets138, and a corresponding game session136may be hosted on a VM instance126of the selected first fleet138(1) by identifying an idle server process132on the VM instance126and instructing the server process132to host the game session136. As game sessions136are placed and as streaming instances1026are assigned to stream games to particular client devices114, the assignments and the placements may be stored in the data store134, at least until the game sessions136are terminated. For example,FIG.10illustrates an example where a first VM instance (VMI)1026(1)(1) has been assigned to a first game streaming request1028(1). As shown by the ellipses in the data store134table ofFIG.10, the data store134may maintain additional streaming instance assignments that have been made. Example details of the streaming instance assignment algorithms215that can be used by the queue component148for value-based game streaming instance assignment are described in further detail with reference to the following figures. In general, the streaming instance assignment algorithm215accounts for the attributes of a game streaming request in determining the value(s)238for streaming instance assignment.
In an illustrative example, an incoming game streaming request1028may be associated with player attributes that indicate a player112associated with the game streaming request1028has played an above-threshold number (e.g., over 1000) of games within a period of time (e.g., within the past 6 months). In this example, the streaming instance assignment algorithm215—using a rule-based approach, a machine-learning model(s), etc.—might determine a relatively-high value238for this game streaming request1028in order to assign, to the game streaming request1028, a VM instance1026that can provide relatively-high performance (e.g., low latency, or an otherwise “snappy” streaming experience) to the client device114of the player112of the game streaming request. In another illustrative example, another incoming game streaming request1028may be associated with game attributes that indicate a game is to be live-streamed to an audience, and the streaming instance assignment algorithm215—using a rule-based approach, a machine-learning model(s), etc.—may determine a relatively-high value238for this game streaming request1028in order to assign, to the game streaming request1028, a VM instance1026that can provide relatively-high performance (e.g., low latency, or an otherwise “snappy” streaming experience) to the client device114of the player112of the game streaming request. By contrast, yet another incoming game streaming request may be associated with a player112who is a non-paying player of a casual, free-to-play game. Given these player attributes and game attributes of the game streaming request1028, the streaming instance assignment algorithm215—using a rule-based approach, a machine-learning model(s), etc.—may determine a relatively-low value238for this game streaming request1028in terms of assigning, to the game streaming request1028, a high-performance1026, and/or the value(s)238may include a relatively-high instance assignment value238for a low-performance VM instance1026that is indicative of a strong preference for assigning, to the game streaming request1028, a VM instance1026that provides relatively-low performance (e.g., higher latency, as compared to other available VM instances1026), perhaps at a lower cost (to the subscriber110) of streaming the game to the given client device114. Assigning, to the game streaming request1028, a low-performance VM instance1026and/or streaming the game with a low-performance configuration (e.g., a relatively low frame rate, a relatively low resolution, etc.) may allow for streaming to more client devices114using a single server process132and/or a single VM instance1026to lower the cost (to the subscribing game developer110) of streaming the game to client devices114of its clients112, thereby providing a cost savings for the developer110.
In some embodiments, the value(s)238may be recalculated during a game session136as attributes306change after a start of the game session136. Based on a recalculated value(s)238, a game may be streamed using a different VM instance1026, such as by transferring the stream from a streaming process132on a first VM instance1026(1)(1) to a different streaming process132on a second VM instance1026(2)(1) where the game streaming is resumed on the second VM instance1026(2)(1). To avoid an interruption in service to the player112, a real-time data migration procedure may be employed to transfer the streaming of the game with little-to-no interruption.
FIG.11illustrates a schematic diagram1100of an example technique, implemented by a game-streaming service1006, for assigning VM instances1026to game streaming requests1028using a value-based approach. Initially, the game-streaming service1006may cause VM instances1026to be spun up and to execute associated processes132, at least some of which execute in idle mode so as to be available to stream a game(s) to a client device114as part of a game session136. Thus, multiple first server processes132may execute on VM instances1026. The VM instances1026may be allocated to a particular subscriber110of the service provider network1002and may be running on computing resources of the service provider network1002.
As a number, R, of incoming game streaming requests1028(1)-(R) are received by the game-streaming service1006, the game-streaming service1006(e.g., via the queue component148) may perform operations to handle the requests1028by queuing1104the requests1028in a queue228. For a given game streaming request1028(1) in the queue228, the queue component148may make a call (e.g., an API call) to get attributes306of the game streaming request1028(1). The attributes306may include, without limitation, player attributes306(1) (e.g., player attributes306(1) based at least in part on prior gameplay of the player112(1)) and game attributes306(2). Since these attributes are described in detail with reference to at leastFIG.3, the attributes306will not be described in further detail here for the sake of brevity. In some embodiments, the game streaming request1028(1) may be associated with a single player112(1), and, in these embodiments, the player attributes306(1) may represent attributes of the single player112(1) associated with a game streaming request1028(1). In some embodiments, the attributes306may be determined prior to the player112(1) being grouped together with one or more other players112in a match.
In addition to the attributes306, the game-streaming service1006(e.g., via the queue component148) may make a call (e.g., an API call) to get available VM instances1026(sometimes referred to as “streaming instances1026”) for streaming a corresponding game to a client device114(1) of the player112(1) associated with the game streaming request1028(1). The available VM instances1026may be allocated to the subscriber110who is associated with the game streaming request1028(1). As shown inFIG.11, streaming instance data236may be maintained in the data store134to determine the available VM instances1026for streaming the game to a client device114. VM instances (VMIs)1026may be identified by an instance ID1108, and each VM instance1026in the set of available VM instances1026(1)(1) to1026(V)(Q) may vary by region322, as well as by performance metrics, such as, without limitation, latency324relative to the client device114, capacity326(e.g., a number of concurrently running processes132, or some other utilization metric), and the like. VM instances1026may also vary by cost327of the instances1026. As shown by the ellipses to the right of the available streaming instances1026table, the streaming instance data236describing properties of the available VM instances1026may include additional properties in addition to the properties specified inFIG.11. In some cases, a VM instance1026can be characterized by way of a tiered ranking system (e.g., low-tier, mid-tier, high-tier). A high-tier VM instance1026may be a VM instance1026with an above-threshold capacity, or one that can provide a user experience at a below-threshold latency to the client device114. VM instances1026may be classified into low-tier, mid-tier, or high-tier based on any suitable property (e.g., performance metric(s)) to indicate which are considered to be higher-performing, or higher-quality (and/or higher cost), VM instances1026and which are considered to be lower-performing, or lower-quality (and/or lower-cost), VM instances1026. As such, the user experience of the players112may vary depending on which VM instance1026is selected for streaming the game to the player's112client device114, and/or depending on the configuration with which the game is streamed (e.g., a frame rate and/or resolution at which the game is streamed, etc.).
With the attributes306and the available VM instances1026determined, the game-streaming service1006(e.g., via the queue component148) may determine one or more values238for the game streaming request1028(1) (e.g., multiple values238, each value corresponding to an individual VM instance1026) based on the attributes306. For example, the attributes306may be provided as input1128to a streaming instance assignment algorithm215, and the output1130of the streaming instance assignment algorithm215may include one or more values238indicative of a value of the game streaming request1028(1) and/or a preference for a preference for streaming the game to a client device114(1) of the player112(1) using a particular VM instance1026. In the example ofFIG.11, a number of values238are determined for an equivalent number of available VM instances1026.
In some embodiments, the streaming instance assignment algorithm215may utilize one or more rules1132to determine instance assignment values238based on the attributes306provided as input to the streaming instance assignment algorithm215. For example, a rule1132may specify that, if the player attributes306(1) indicate the player112(1) associated with the game streaming request1028(1) has played an above-threshold number of games (e.g., 1000 games or more) over a period of time, the instance assignment value238for a high-tier VM instance1026may be set to a maximum value (e.g., a value of 1 on a scale [0,1]). The same rule1132, or a different rule1132, may specify that, if the player attributes306(1) indicate that the player112(1) has played a below-threshold number of games over the period of time, the instance assignment value238for a low-tier VM instance1026may be set to a maximum value (e.g., a value of 1 on a scale of [0,1]), and/or the instance assignment value238for a high-tier VM instance1026may be set to a relatively lower value on the scale. In some embodiments, a rule1132may be expressed as a function(s) (e.g., a mathematical function, such as a linear or non-linear equation) that computes a value(s)238based on quantifiable attributes306that are provided as input to the function(s). Such quantifiable attributes306may include, for example, a number of games played by the player112(1), an amount of money spent by the player112(1), etc. In some embodiments, a different function may be defined for each available VM instance1026in order to compute a value238that is specific to each VM instance1026. For example, a quantifiable attribute306may be provided as input to a first function that computes a first value238for a first VM instance1026(1)(1), the quantifiable attribute306may also be provided as input to a second function that computes a second value238for a second VM instance1026(2)(1), and so on and so forth, depending on the number of available VM instances1026. In this manner, the streaming instance assignment algorithm215may determine one or more values238that dictate which VM instance1026is to stream the game to the client device114(1) of the player112(1). For example, the queue component148may select the VM instance1026(1)(1) with the highest value238of the set of values shown inFIG.11as the VM instance1026(1)(1) that is to stream the game to the player's112(1) client device114(1) as part of a corresponding game session136(1), and an idle server process132executing on the selected VM instance1026(1)(1) may be assigned to stream the game by rendering frames, sending the frames to the client device114(1), and receiving control input data from the client device114(1).
In some embodiments, the streaming instance assignment algorithm215may represent a machine learning model(s)1134that is configured to receive attributes306as input1128and to generate output1130that assigns scores to available VM instances1026. Machine learning is described in detail elsewhere herein and will not be described in further detail here for the sake of brevity. Ultimately, one of the VM instances1026(1)(1) is selected as a selected VM instance1026(1)(1) for streaming the game to the client device114(1) of the player112(1) associated with the game streaming request1028(1). Accordingly, as shown inFIG.11, the selected VM instance1026(1)(1) can be assigned to the game streaming request1028(1) based at least in part on the value(s)238determined using the streaming instance assignment algorithm215.
FIG.12illustrates a flow diagram of an example process1200for using a value-based approach to assign a VM instance1026to game streaming request1028. For discussion purposes, the process1200is described with reference to the previous figures.
At1202, a queue component148of the game-streaming service1006may queue1104a game streaming request1028in a queue228. Said another way, the game streaming request1028may be placed in a queue228. This is depicted schematically inFIG.11. The game streaming request1028may be associated with a subscriber110of a service provider network1002. The subscriber110may represent a game developer of an online, multiplayer video game (or, game). Therefore, the game streaming request1028may correspond to a game of the subscriber110. Furthermore, the game streaming request1028may be associated with at least one player112who may desire to stream the game to his/her client device114, which may be a mobile device connected to a WiFi or cellular network.
At1204, the queue component148may determine one or more attributes306of the game streaming request1208queued at block1202. The queue component148may access attribute data212(e.g., from the data store134) in order to determine the attributes306at block1204. In some embodiments, the queue component148may make a call (e.g., an API call) to get the attributes306at block1204. In some examples, at least some of the attribute data212may have been provided by the subscriber110voluntarily. In some examples, at least some of the attribute data212may have been derived by the game-streaming service1006from hosting past game sessions136on behalf of the subscriber110. As shown by sub-blocks1206and1208, the attributes306may include, without limitation, player attributes306(1) and/or game attributes306(2).
Accordingly, at1206, the queue component148may determine player attributes306(1) of a player112associated with the game streaming request1028. As described herein, player attributes306(1) may be based at least in part on prior gameplay of the player112, and may include, without limitation, a player ID308(e.g., an account name, an account number, a player alias, etc.), a number of games played310over a period of time, whether the player112is a paying player (as opposed to a player that exclusively plays free-to-play games), and, if so, an amount of money spent312by the player112over the period of time, an amount of time spent playing games, a time(s) of day that games were played, other players112that were involved in a common match, whether a player ID is a known player ID (e.g., a famous/professional gamer, a known blogger, a game reviewer, a person with an above-threshold number of social media followers, etc.), whether the player has purchased DLC, and the like.
Additionally, or alternatively, at1208, the queue component148may determine game attributes306(2) of a game corresponding to the game streaming request1208. Game attributes306(2) may be indicative of a game situation, a game context, or the like, and may include, without limitation, a game mode314(e.g., whether a game is to be played in a tournament mode or in casual mode), and if the game is to be played in tournament mode, a phase316of a tournament (e.g., Phase 3 out of a total of 5 Phases), whether the game is to be live-streamed318(i.e., broadcast to one or more viewing users), and if so, a projected number of viewing users in the audience, and the like.
At1210, the queue component148may determine available VM instances1026that are allocated to the subscriber110for streaming the game to a client device114of the player112. The queue component148may access streaming instance data236(e.g., from the data store134) in order to determine the available VM instances1026at block1210. In some embodiments, the queue component148may make a call (e.g., an API call) to get the available streaming instances1026(or streaming instance data236pertaining thereto) at block1210. As described herein, a subscriber110may be allocated multiple VM instances1026that are located across disparate regions as part of a subscription to the game-streaming service1006of the service provider network1002. Accordingly, the operations performed at block1210may include determining at least a first VM instance1026(1)(1) (in a first region) allocated to the subscriber110, and determining a VM instance1026(2)(1) (in a second region) allocated to the subscriber110. In addition, the various VM instances1026identified at block1210may be characterized by different performance metrics, such as latency, capacity, current utilization, etc. For example, a first VM instance1026(1)(1) may provide a first latency to the client device114of the player112associated with the request1028, a second VM instance1026(2)(2) may provide a second latency to the client device114of the player112associated with the request1028, and so on and so forth, depending on the number of available streaming instances1026. As another example, the available VM instances1026determined at block1210may vary in terms of available capacity and/or current resource utilization. For example, a first VM instance1026(1)(1) may be running one process, and a second VM instance1026(2)(1) may be running multiple (e.g., four) processes. This can mean that different instances1026can have different capacities, where the VM instance1026(1)(1) running the single process may be able to provide the snappiest response with relatively less jitter during game streaming, and the VM instance1026(2)(1) running the multiple processes concurrently may have less capacity to stream the game to the client device114, yet it may be able to provide a lower cost for streaming the game as part of a corresponding the game session (e.g., at a relatively lower frame rate, a relatively lower resolution, etc.).
At1212, the queue component148may determine a value(s)238based at least in part on the attributes306of the game streaming request1028determined at block1204. In some embodiments, the value(s)238may be determined at block1212using a streaming instance assignment algorithm215, as described herein. A streaming instance assignment algorithm215may be a rule-based algorithm that evaluates one or more rules1132. For example, a rule-based algorithm215may evaluate whether the player112has played an above-threshold number of games over a period of time via the game-streaming service1006, and/or whether any of the player112has spent an above-threshold amount of money over the period of time via the game-streaming service1006, and similar rules. Thus, one or more rules can be evaluated based on the attributes306at block1212. Additionally, or alternatively, a streaming instance assignment algorithm215may be a machine-learning-based algorithm that provides the attributes306as input1128to a trained machine learning model(s)1134, as described herein. The output1130of the trained machine learning model(s)1134may be one or more values238at block1212. In some embodiments, the value(s)238may be determined, at block1212, based at least in part on properties of the available streaming instances1026specified in the streaming instance data236, such as properties including, without limitation, latencies324of the available VM instances1026relative to the client device114of the player112, capacities326(e.g., a number of concurrently running processes132, or some other utilization metric) of the available VM instances1026, cost327of the available instances1026, and the like.
At1214, the queue component148may determine multiple values238, one value238per available VM instance1026determined at block1210. For example, the queue component148may determine, based on the attributes306, a first value238associated with the first VM instance1026(1)(1), a second value238associated with a second VM instance1026(2)(1), and possibly additional values238for additional VM instances1026. Here, the first value238may be indicative of a first preference for assigning the first VM instance1026(1)(1) to the game streaming request1028, and the second value238may be indicative of a second preference for assigning the second VM instance1026(2)(1) to the game streaming request1028, where the second preference may be a stronger or weaker preference, or the same preference (if the multiple values238are equal), as the first preference.
At1216, the queue component148may select, based at least in part on the value(s)238determined at block1212, a VM instance1026(e.g., the first VM instance1026(1)(1) or the second VM instance1026(2)(1)) as a selected VM instance1026. The selection at block1216may be based at least in part on a comparison between multiple values determined at block1214(e.g., a comparison between a first value238for the first VM instance1026(1)(1) and the second value238for the second VM instance (2)(1)). For example, if the first value238is greater than the second value238, the queue component148may select the VM instance1026associated with the greater, first value238. The selection at block1216may be based on a comparison between fleet properties (e.g., performance metrics) of the available VM instances102(e.g., a comparison between a first latency that the first VM instance1026(1)(1) provides to the client device114of the player112and a second latency that the second VM instance1026(2)(1) provides to the client device114of the player112). Accordingly, at block1216, the queue component148may determine latencies (and/or other fleet/instance properties such as capacity (and/or other performance metrics), cost, etc.) of multiple VM instances1026, such as a first latency that the first VM instance1026(1)(1) provides to the client device114of the player112, a second latency that the second VM instance1026(2)(1) provides to the client device114of the player112, and possibly additional latencies, depending on the number of VM instances1026evaluated. If a first latency is less than a second latency, the queue component148may select the VM instance1026associated with the lower latency (or the higher latency, depending on how the value-based streaming instance assignment algorithm215is configured). In some embodiments, the value(s)238determined at block1212may be based at least in part on streaming instance data236that specifies the instance properties of each available VM instance1026. In this way, the selection of the VM instance1026at block1216can be based on the value(s)238, which, in turn, is/are based on the properties of the available VM instances1026(e.g., latencies, capacities, costs, etc.).
At1218, the queue component148may select, based at least in part on the value(s)238, a configuration of multiple available configurations as a selected configuration. For example, the queue component148may have a choice between streaming the game to the client device114at different frame rates (e.g., 30 FPS, 15 FPS, etc.), and/or at different resolutions (e.g., 1080P, 4K, etc.). Accordingly, the selection at block1218may involve selecting a frame rate of multiple available frame rates as a selected frame rate, and/or selecting a resolution of multiple available resolutions as a selected resolution, etc.
At As shown by the off-page reference “A” inFIGS.5and12, the process1200may continue from block1218to block502of the process500, where an incoming game session request is queued. In other words, blocks1202through1218of the process1200may represent a first phase of a multi-phase process where a streaming instance1026is assigned to a game streaming request1028, and, subsequently, the process500may represent a second phase of the multi-phase process where a game session136involving the player112associated with the game streaming request1028is placed for hosting a multi-player game session with one or more other players112. Once a VM instance of the selected fleet138starts executing to host the game session136, the process500may continue from block520to block1220of the process1200, as indicated by the off-page reference “B” inFIGS.5and12.
At1220, the game-streaming service1006may stream the game to the client device114of the player112as part of the game session136involving the player112and one or more other players112. The streaming at block1220may include executing the selected VM instance1026to render frames, to send the frames to the client device114with the selected configuration (e.g., at the selected frame rate, the selected resolution, etc.), and to receive control input data from the client device114. Meanwhile, the corresponding game session136may be hosted using a VM instance126of the selected fleet138that was selected for game session placement, as described herein.
While the foregoing invention is described with respect to the specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure, and covers all changes and modifications which do not constitute departures from the true spirit and scope of this invention.
Although the application describes embodiments having specific structural features and/or methodological acts, it is to be understood that the claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are merely illustrative some embodiments that fall within the scope of the claims of the application.
Claims
- A method comprising: placing a game session request in a queue, the game session request associated with a subscriber of a service provider network;accessing attribute data to determine player attributes of players associated with the game session request, wherein the player attributes are based at least in part on prior gameplay of the player;accessing fleet data that includes identifiers of available fleets of virtual machine (VM) instances that are allocated to the subscriber;determining, based at least in part on the fleet data, at least a first fleet in a first region and a second fleet in a second region, the first fleet having a first performance characteristic and the second fleet having a second performance characteristic, wherein the first performance characteristic and the second performance characteristic indicate that the second fleet is higher performing than the first fleet;selecting, based at least in part on the player attributes, the first fleet as a selected fleet;and causing a game session corresponding to the game session request to be hosted on a VM instance of the selected fleet.
- The method of claim 1, further comprising: selecting, based at least in part on the player attributes, at least one of: a frame rate of multiple available frame rates as a selected frame rate;or a resolution of multiple available resolutions as a selected resolution, wherein the causing of the game session to be hosted comprises causing the game session to be hosted at the selected frame rate or the selected resolution.
- The method of claim 1, further comprising: receiving, from a subscriber device associated with the subscriber, data for customizing a session placement algorithm used for placing game sessions;and creating a customized session placement algorithm for the subscriber based at least in part on the data, wherein the selecting is based at least in part on the customized session placement algorithm.
- The method of claim 1, further comprising providing the player attributes as input to a first function that computes a first value;and providing the player attributes as input to a second function that computes a second value, wherein the selecting is based at least in part on the first value or the second value.
- A method comprising: determining one or more player attributes of players associated with a game session request, the one or more player attributes based at least in part on prior gameplay of the players, and the game session request associated with a subscriber of a service provider network;accessing fleet data that includes identifiers of available fleets of virtual machine (VM) instances that are allocated to the subscriber: determining, based at least in part on the fleet data: a first fleet of VM instances allocated to the subscriber;and a second fleet of VM instances allocated to the subscriber;selecting, based at least in part on the one or more player attributes value, the first fleet or the second fleet as a selected fleet;and causing a game session corresponding to the game session request to be hosted on a VM instance of the selected fleet.
- The method of claim 5, further comprising determining multiple values based at least in part on the one or more player attributes, the multiple values comprising: a first value associated with the first fleet, the first value indicative of a first preference for placing the game session on the first fleet;and a second value associated with the second fleet, the second value indicative of a second preference for placing the game session on the second fleet, wherein the selecting is based at least in part on a comparison between the first value and the second value.
- The method of claim 5, further comprising: selecting, based at least in part on the one or more player attributes, at least one of: a frame rate of multiple available frame rates as a selected frame rate;or a resolution of multiple available resolutions as a selected resolution, wherein the causing of the game session to be hosted comprises causing the game session to be hosted at the selected frame rate or the selected resolution.
- The method of claim 5, wherein the one or more player attributes include, for individual ones of the players, at least one of: a player identifier (ID);a number of games played over a period of time;whether the player is a paying player;an amount of money spent by the player over the period of time;an amount of time spent playing games;or one or more times of day that games were played.
- The method of claim 5, further comprising determining one or more game attributes of a game corresponding to the game session request, and wherein: the selecting is further based at least in part on the one or more game attributes;and the one or more game attributes include at least one of: whether a game is to be played in a tournament mode or in casual mode;a phase of a tournament, or whether the game is to be live-streamed.
- The method of claim 5, further comprising at least one of: providing the one or more player attributes as input to a function that computes a first value;or providing the one or more player attributes as input to a trained machine learning model that generates a second value as output, wherein the selecting is based at least in part on the first value or the second value.
- The method of claim 5, further comprising: receiving, from a subscriber device associated with the subscriber, data for customizing a session placement algorithm used for placing game sessions;and creating a customized session placement algorithm for the subscriber based at least in part on the data, wherein the selecting is based at least in part on the customized session placement algorithm.
- The method of claim 11, wherein the data comprises at least one of: one or more customized session placement rules;a customized machine learning model;or one or more weights assigned to individual ones of the one or more player attributes.
- The method of claim 5, further comprising: determining a first average latency that the first fleet provides to the players;and determining a second average latency that the second fleet provides to the players, wherein the selecting is based at least in part on a comparison between the first average latency and the second average latency.
- The method of claim 5, further comprising: determining a first capacity of the first fleet;and determining a second capacity of the second fleet, wherein the selecting is based at least in part on a comparison between the first capacity and the second capacity.
- The method of claim 5, further comprising: determining a first cost of the VM instances of the first fleet;and determining a second cost of the VM instances of the second fleet, wherein the selecting is based at least in part on a comparison between the first cost and the second cost.
- A system comprising: one or more processors;and non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the system to: determine one or more player attributes of players associated with a game session request, the one or more player attributes based at least in part on prior gameplay of the players, and the game session request associated with a subscriber of a service provider network;access fleet data that includes identifiers of available fleets of virtual machine (VM) instances that are allocated to the subscriber;determine, based at least in part on the fleet data: a first fleet of VM instances allocated to the subscriber;and a second fleet of VM instances allocated to the subscriber;select, based at least in part on the one or more player attributes, the first fleet or the second fleet as a selected fleet;and cause a game session corresponding to the game session request to be hosted on a VM instance of the selected fleet.
- The system of claim 16, wherein the computer-executable instructions, when executed by the one or more processors, further cause the system to determine multiple values based at least in part on the one or more player attributes, the multiple values comprising: a first value associated with the first fleet, the first value indicative of a first preference for placing the game session on the first fleet;and a second value associated with the second fleet, the second value indicative of a second preference for placing the game session on the second fleet, wherein selecting the first fleet or the second fleet as the selected fleet is based at least in part on a comparison between the first value and the second value.
- The system of claim 16, wherein the one or more player attributes include, for individual ones of the players, at least one of: a player identifier (ID);a number of games played over a period of time;whether the player is a paying player;an amount of money spent by the player over the period of time;an amount of time spent playing games;or one or more times of day that games were played.
- The system of claim 16, wherein the computer-executable instructions, when executed by the one or more processors, further cause the system to: select, based at least in part on the one or more player attributes, a configuration of multiple available configurations as a selected configuration, wherein causing the game session to be hosted comprises causing the game session to be hosted with the selected configuration.
- The system of claim 19, wherein the selected configuration comprises a selected frame rate of multiple available frame rates, and wherein the causing of the game session to be hosted comprises causing the game session to be hosted at the selected frame rate.
Disclaimer: Data collected from the USPTO and may be malformed, incomplete, and/or otherwise inaccurate.