Method and devices for seamless cross-game-engine player migration

Abstract

There is provided methods and devices for migrating a player in a cloud gaming environment from a first game engine instance to a second game engine instance. The method comprises streaming, during a migration window, an audio-video stream from each of the first game engine instance and the second game engine instance, and blending, either in the cloud or at the remote client, both streams into a single output stream. The blending of both streams uses a weighted average with weights changing over time to favour the source engine instance at the beginning of the migration window, and to favour the destination engine at the end of the migration window. Techniques such as blurring may be used to decrease artifacts in the output stream.

Description

METHOD AND DEVICES FOR SEAMLESS CROSS-GAME-ENGINE PLAYER MIGRATION

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present application is the first application for this disclosure.

[0003] FIELD OF THE DISCLOSURE

[0004] The present disclosure relates to cloud gaming. Specifically, the present disclosure relates to methods and devices for seamlessly migrating players between game engines.BACKGROUND

[0005] Cloud gaming is becoming more and more prevalent as it allows to take advantage of scalable and elastic cloud resources. Cloud gaming is also convenient for consumers because they can quickly access the most recent gaming titles, without hardware restrictions and only paying per use. At the same time, cloud providers can achieve high resource utilization by multiplexing cloud resources across multiple players, including sharing the cloud hardware instead of dedicating them to individual consumers for long time periods.

[0006] Traditionally, each player in a single or multiplayer game requires a dedicated game engine instance running on a dedicated computer. On the cloud, multiple players may be hosted on the same game engine instance, allowing for sharing of resources and computations between them. For example, instead of computing the exact same animation for every player, a shared game engine may compute the animation once and reuse it for multiple players.

[0007] To maximize sharing, players requiring similar computations may be assigned to the same game engine. However, players requiring similar computations at an initial time may diverge, making the initial assignment ineffective. Accordingly, there is a need to migrate players between game engines, during gameplay, and without any service interruptions.SUMMARY

[0008] It is an object of the present disclosure to provide an improved method for migrating a player between game engine instances.

[0009] According to a first aspect, there is provided a method implemented on a computing device, the computing device controlling a first game engine instance and a second game engine instance, comprising determining that a remote client hosted by the first game engine instance is to be migrated to the second game engine instance; retrieving from the first game engine instance, a player game state; providing, to the second game engine instance, the player game state; during a migration window, receiving a first audio-video stream from the first game engine instance; receiving a second audio-video stream from the second game engine instance, combining the first audio-video stream and the second audio-video stream thereby creating a combined stream; transmitting, to the remote client, the combined stream; receiving user input signals from the remote client; and providing the user input signals to the first game engine instance and the second game engine instance.

[0010] According to an embodiment of the first aspect, the method further comprises determining that a halfway point of the migration window has been reached, and indicating to the first game engine instance and the second game engine instance that the halfway point of the migration window has been reached.

[0011] According to yet another embodiment of the first aspect, the method further comprises upon determining that the halfway point of the migration window has been reached, switching a network role of the first game engine instance from autonomous to client; and switching a network role of the second game engine instance from client to autonomous.

[0012] According to yet another embodiment of the first aspect, prior to said determining that the halfway point of the migration window has been reached, periodically retrieving the player game state from the first game engine instance and providing the player game state to the second game engine instance.

[0013] According to yet another embodiment of the first aspect, after said determining that the halfway point of the migration window has been reached, periodically retrieving the player game state from the second game engine instance and providing the player game state to the first game engine instance.

[0014] According to yet another embodiment of the first aspect, the combined stream includes the first audio-video stream and the second audio-video stream.

[0015] According to yet another embodiment of the first aspect, the combined stream is computed using where O (t) is the combined stream for time t, Isource (t) , is the first audio-video stream for time t, Idest (t) is the second audio-video stream for time t, S (t) is a blending function, and L is a length of the migration window.

[0016] According to yet another embodiment of the first aspect, S (0) =0, S (0.5) =0.5, S (1) =1, S (t) +S (1-t) =1, S (t) is differentiable for t∈ (0, 1) , and S (t) is monotonically increasing over (0, 1) .

[0017] According to yet another embodiment of the first aspect, S (t) is selected from the group comprising S (t) =4t3-6t2+3t, S (t) =t, and

[0018] According to yet another embodiment of the first aspect, further comprising applying a blur to the combined stream.

[0019] According to yet another embodiment of the first aspect, the blur has a strength that is proportional to a derivative of S (t) .

[0020] According to yet another embodiment of the first aspect, applying the blur comprises applying a 2-dimensional Gaussian blur to a video portion of the combined stream, and applying a 1-dimensional Gaussian blur to an audio portion of the combined stream.

[0021] According to yet another embodiment of the first aspect, the method further comprises applying a fade multiplier to an audio portion of the combined stream.

[0022] According to yet another embodiment of the first aspect, the method further comprises, prior to said determining that the remote client is to be migrated, computing a migration cost function.

[0023] According to yet another embodiment of the first aspect, the migration cost function comprises

[0024] where f is an index for a current frame, Pixels is the set of all pixels for a given frame, PCMf is the audio stream for a given frame, penaltyδ is a penalty associated to an input button δ, pressedδ is 1 when button δ is pressed and 0 when button δ is not pressed, and penaltyapplication is a penalty provided by an application.

[0025] According to yet another embodiment of the first aspect, the method further comprises, during the migration window, increasing a rate of replication for the first game engine instance and the second game engine instance.

[0026] According to a second aspect, there is provided a computing device comprising a processor and a communications subsystem, configured to perform the method of any embodiment of the first aspect.

[0027] According to a third aspect, there is provided a computer readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions for performing the method of any embodiment of the first aspect.

[0028] According to a fourth aspect, there is provided a method implemented on a computing device, comprising receiving, from a streaming provider, a first audio-video stream and a second audio-video stream during a migration window; blending the first audio-video stream and the second audio-video stream together to create an output stream; and displaying the output stream on an output device.

[0029] According to an embodiment of the fourth aspect, the method further comprises receiving an input signal from an input device, and transmitting the input signal to the streaming provider.

[0030] According to another embodiment of the fourth aspect, said blending uses where O (t) is the combined stream for time t, Isource (t) , is the first audio-video stream for time t, Idest (t) is the second audio-video stream for time t, S (t) is a blending function, and L is a length of the migration window.

[0031] According to yet another embodiment of the fourth aspect, S (0) =0, S (0.5) =0.5, S (1) =1, S (t) +S (1-t) =1, S (t) is differentiable for t∈ (0, 1) , and S (t) is monotonically increasing over (0, 1) .

[0032] According to yet another embodiment of the fourth aspect, S (t) is selected from the group comprising S (t) =4t3-6t2+3t, S (t) =t, and

[0033] According to yet another embodiment of the fourth aspect, the method further comprises applying a blur to the output stream.

[0034] According to yet another embodiment of the fourth aspect, the blur has a strength that is proportional to a derivative of S (t) .

[0035] According to yet another embodiment of the fourth aspect, applying the blur comprises applying a 2-dimensional Gaussian blur to a video portion of the output stream, and applying a 1-dimensional Gaussian blur to an audio portion of the output stream.

[0036] According to yet another embodiment of the fourth aspect, the method further comprises applying a fade multiplier to an audio portion of the output stream.

[0037] According to a fifth aspect, there is provided a computing device comprising a processor and a communications subsystem, configured to perform the method of any embodiment of the fourth aspect.

[0038] According to a sixth aspect, there is provided a computer readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions for performing the method of any embodiment of the fourth aspect.BRIEF DESCRIPTION OF THE DRAWINGS

[0039] FIG. 1 illustrates a cloud gaming configuration, according to at least some embodiment of the present disclosure.

[0040] FIG. 2 illustrates a migration from a source engine instance to a destination engine instance, according to at least some embodiments of the present disclosure.

[0041] FIG. 3 illustrates dual streaming during migration according to at least some embodiments of the present disclosure.

[0042] FIG. 4A illustrates a blending function according to at least some embodiments of the present disclosure.

[0043] FIG. 4B illustrates a blending function according to at least some embodiments of the present disclosure.

[0044] FIG. 4C illustrates a blending function according to at least some embodiments of the present disclosure.

[0045] FIG. 5 illustrates an architecture of a cloud gaming environment according to at least some embodiments of the present disclosure.

[0046] FIG. 6 is a flow diagram showing a method for cloud gaming according to at least some embodiments of the present disclosure.

[0047] FIG. 7 is a message flow diagram illustrating a method for performing migration according to at least some embodiments of the present disclosure.

[0048] FIG. 8 is a message flow diagram illustrating a process during the migration window, according to at least some embodiments of the present disclosure.

[0049] FIG. 9 is a block diagram of a computing device according to at least one embodiment of the present disclosure.DETAILED DESCRIPTION

[0050] The present disclosure provides an improved method for migrating a player between game engine instances.

[0051] Throughout the present disclosure, the following terminology will be followed.

[0052] Artifact: In gaming, an artifact is an unintended visual or audio issue, like glitches or distortions, that can occur during rendering or playback.

[0053] Audio Pulse-Code Modulation (PCM) Signal: A method of recording and playing back sound where the audio is converted into a series of digital samples.

[0054] Bandwidth: The amount of data that can be transmitted over a network in a given amount of time, affecting how smoothly online games run.

[0055] Cloud: A system where computing resources, like servers and storage, are provided over the internet rather than locally.

[0056] Cloud Gaming: Playing video games streamed from a remote server in the cloud, rather than running the game on a local device.

[0057] Cloud Resources: Any resource that is provided by the cloud, such as computing power, storage, and other services provided over the internet, which can be used for various applications including gaming.

[0058] Component: A part of a game or software that performs a specific function, for example, a software module responsible for handling player movements.

[0059] Entity: An object or character in a game, like a player or a Non-Player Character (NPC) , that has its own properties and behaviors.

[0060] Frame: A single image in a sequence of images that make up a video or an animation.

[0061] Game Engine: Software that provides the tools and framework for creating and running video games, handling things like graphics, physics, and input.

[0062] Game Engine Instance: A specific running version of a game engine, often used to refer to different games or sessions running on the same engine.

[0063] Game Server: A computer system that hosts and manages a multiplayer game, allowing players to connect and play together online.

[0064] Glitch: An unexpected problem or error in a game that causes it to behave incorrectly or display errors.

[0065] I / O: Stands for input / output, referring to the ways a computer receives data (input) and sends data (output) , such as keyboard presses and screen displays.

[0066] Multiplayer Game: A video game that allows multiple players to participate and interact with each other in the same game environment.

[0067] Multiplayer System: The underlying technology and methods used to enable and manage multiplayer gameplay, including networking and server management.

[0068] Network Role: The function or responsibility of a computer or player in a networked game, such as a server, client, or peer.

[0069] Player Migration: The process of transferring a player’s game data and / or session from one server or game engine instance to another, often for balancing or maintenance purposes.

[0070] Rendering: The process of generating the visual output of a game, like drawing graphics and textures on the screen.

[0071] Replication: The technique of keeping game data synchronized across multiple systems or clients, ensuring that all players see the same game state.

[0072] Script: A set of instructions written in a programming language that tells a game how to behave or respond to player actions.

[0073] Serialization: The process of converting game data into a format that can be easily saved or transmitted, and then reconstructing it later.

[0074] Stream: A method of delivering data continuously over the internet, like watching a video or playing a game without having to download the entire file first.

[0075] Reference is made to FIG. 1, in which a cloud gaming configuration is illustrated. Specifically, remote clients 102a, 102b, and 102c are assigned to game engine instance 101. While each of remote clients 102a, 102b, and 102c may be located in different geographic locations, engine instance 101 provides each of remote clients 102a, 102b, and 102c, with resources needed to produce a traditional gaming experience. For example, remote clients 102a, 102b, and 102c may transmit input data (e.g., button presses, thumbstick movements) to engine instance 101, and engine instance 101 may transmit output data (e.g., audio and video streams) to remote clients 102a, 102b, and 102c.

[0076] During a gaming session, a remote client that was initially assigned to a first game engine instance may be assigned to a different game engine instance. This process, called “migration” , is illustrated in FIG. 2. As seen in FIG. 2, a remote client 202 may be initially assigned to engine instance 201a and then migrated to engine instance 201b, such that after migration remote client 202 is no longer assigned to engine instance 201a and is assigned to engine instance 201b.

[0077] The reasons for migrating a remote client to a different gaming instance are varied, but typically involve seeking to make a more efficient use of cloud resources. For example, migration may be initiated when the other remote clients assigned to a game engine are in a sufficiently distinct game state, that little if any resource sharing can occur.

[0078] The present disclosure seeks to provide solutions to seamlessly migrate players across different game engine instances, during gameplay and without any service interruption. This will provide the following benefits:

[0079] ● Maximizing memory and computation sharing by having the flexibility to quickly migrate players between game engine instances.

[0080] ● Easing cloud system and application maintenance, as resources can be freed by temporarily moving players to different game engine instances.

[0081] ● Dynamically allocating cloud resources when memory and computation requirements of a game change over time.

[0082] ● Providing fault tolerance through quick serialization of game states in the source engine instance and deserialization in the destination engine instance.

[0083] US20240212255 to Chen discloses a solution that maintains a remote session while migrating from one rendering engine to another. Chen discloses the use of a management device to manage data transfers between the engines and oversee migration, while a gateway component decides which rendering engine the remote client should be connected to. To perform migration, the management device transfers a rendering scene to the destination engine. The destination engine begins rendering the scene, and once ready, the source rendering engine is released and the gateway switches the connection to the destination engine.

[0084] Overall, the prior art lacks a solution that allows for seamless player migration such that the remote user does not notice any disruptions in the gameplay experience. In particular, the prior art does not provide a solution for migration at the player level, such that the migration of a player does not disrupt the gameplay experience for other players on the same engine instance.

[0085] To overcome the deficiencies of the prior art, the present disclosure proposes a lightweight representation of the player which is quick to transfer and back up, to support player migration and effective fault tolerance, respectively. Large data transfers involved in prior art migration, comprising more than player-specific data, result in long migration durations and high usage of network bandwidth. This also adversely affects the frequency at which migration can occur.

[0086] With the exception of US20240212255 to Chen, prior art solutions result in a duration of service down-time. This is harmful to the experience of the player and may cause unwanted changes to the game state in multiplayer scenarios.

[0087] The prior art also lacks a solution for smooth and glitch-less transition, and abrupt changes to video and audio are easily noticed by users. Specifically, prior art solutions do not guarantee a quantitative limit to the level of video and audio changes between two consecutive frames.

[0088] The present disclosure, therefore, seeks to provide a solution which provides:

[0089] ● Seamless migration: no service down-time and no sudden changes in the video and audio streams.

[0090] ● On-demand player-level migration without loss of data and disruptions to the game state.

[0091] ● Fault tolerance: the ability to restore a player’s session to a recent point before a crash.

[0092] In general, the present disclosure provides for a method in which a remote client is gradually migrated from a source engine instance to a destination engine instance, while streaming from both engine instances and blending their outputs. This approach produces no disruptions to the remote user’s experience, such as service down-time, and sudden changes in the output video and audio.

[0093] DUAL STREAMING

[0094] Throughout this disclosure, the technique for continuous streaming during player migration will be referred to as “Dual Streaming” . This is achieved by briefly streaming from both the source and destination engine instances to the remote client. The period in which both source and destination engine instances provide streams to the remote client is called the “Migration Window” .

[0095] Reference is made to FIG. 3, which illustrates dual streaming during a migration window. As seen in FIG. 3, a remote client 302 is connected to both source engine instance 301a and destination engine instance 301b. When remote client 302 receives an input from the user, data indicating the input is transmitted to both engine instances 301a and 301b, as illustrated by arrows 303a and 303b. Audio and video streams 304a and 304b, originating from engine instances 301a and 301b respectively, are received by remote client 302. Audio and video streams 304a and 304b are then blended together before being output by remote client 302, as described below.

[0096] According to at least some embodiments of the present disclosure, the remote client comprises an audio and video blending module, responsible for blending the audio and video from both the source engine instance and the destination engine instance. The blending module may use a weighted average to generate an output from the two input streams, where the weights are determined by the Blending Function S (t) , where t is a time variable.

[0097] According to at least some embodiments, the following equation is used to generate an output stream from two different streams:

[0098] where t is the time since the beginning of the migration window, O (t) is an output value for time t, Isource (t) is a value at time t from the source stream, Idest (t) is a value from time t from the destination stream, S (t) is the blending function, and L is the length of the migration window.

[0099] According to at least some embodiments, the blending function may have some of the following characteristics:

[0100] ● S (0) = 0

[0101] ● S (0.5) = 0.5

[0102] ● S (1) = 1

[0103] ● S (t) + S (1-t) = 1

[0104] ● S (t) is differentiable for 0 ≤ t ≤ 1

[0105] ● S (t) is monotonically increasing

[0106] The blending function S (t) controls which proportion of the respective source and destination streams are used for the output. Thus, at time 0, only the source stream is used, and at time L, only the destination stream is used. Between time 0 and time L, a combination of both streams is used, and at the halfway point of the migration window, each stream is used equally. At all times during the migration window, the sum of the weights is 1, and as time increases during the migration window, a greater weight is applied to the destination stream and a lesser weight is applied to the source stream. The derivative of S (t) may be used to minimize artifacts, as described below.

[0107] The blending function S (t) controls how smoothly the video transitions from the source stream to the destination stream. Halfway through the migration window, where the blending function produces equal weights of 0.5, is called the “Switch Point” . This point is most susceptible to visual and auditory artifacts, as the weight of both streams are equal. The rate at which S (t) changes around this point defines the trade-off between the duration and the intensity of artifacts. Specifically, a rapidly changing blending function creates short-lasting but more intense artifacts, whereas a slowly changing blending function creates longer-lasting but less intense artifacts.

[0108] FIGS. 4A, 4B, and 4C illustrate various valid blending functions that may be used according to at least some embodiments of the present disclosure. Specifically, FIG. 4A shows a graph for the following blending function: S (t) =4t3-6t2+3t

[0109] FIG. 4B shows a graph for the following blending function: S (t) =t

[0110] FIG. 4C shows a graph for the following blending function:

[0111] The function illustrated in FIG. 4B balances the trade-off between the length and intensity of artifacts, whereas the function illustrated in FIG. 4A prioritizes smoothness of the artifacts over how long the artifacts are visible, and the function illustrated in FIG. 4C prioritizes shorter but more intense artifacts.

[0112] As minor artifacts are inevitable during blending, the present disclosure provides solutions to manage, hide, or avoid artifacts.

[0113] According to at least some embodiments, artifacts may be managed using a custom blending function generated at migration time to minimize the video and audio changes between consecutive frames. This approach may be combined with an adjustable migration duration. A metric that quantitatively measures this change can be used to define a threshold for smoothness.  A custom blending function can guarantee smoothness based on a threshold, by increasing the duration of migration and decreasing the steepness of S (t) .

[0114] According to at least some embodiments, a blur function is applied to the output of the dual streaming to hide inconsistencies between the input streams. By adjusting the strength of the blur based on the derivative of the blending function, we can avoid unnecessary blurring and only blur when changes are sudden.

[0115] For example, a video frame may be blurred using a 2-Dimensional Gaussian kernel of size 25, a mean of 0, and a standard deviation of Using a maximum value for the standard deviation limits the strength of the blur when approaches infinity. Similarly, a 1-Dimensional Gaussian blur may be applied to audio PCM signals. In some embodiments, a multiplier is applied to the audio output to fade the audio, preventing unpleasant sound signal interferences. According to at least some embodiments, the fade multiplier is which is most effective when the blending function has a high rate of change.

[0116] Blending artifacts are minimized when both engines are properly synchronized, which is achieved when time t from both streams translate to the same global game state. Therefore, the time variable may be decided by an authority that manages all game engines, such as the game server. While streaming, each engine attaches the authority-approved game time to the streaming packets, which is used on the client-side to ensure synchronization during dual streaming blending.

[0117] According to at least some embodiments, artifacts may be avoided or minimized by choosing an optimal time to begin player migration. A Migration Cost Function may be used to determine the cost of migration for a given frame. Multiple dimensions can be considered to compute the cost, including potential audio and video artifacts introduced when migrating at time t. In some embodiments, the Migration Cost Function may be:

[0118] where f is an index for a current frame, f-1 is an index for a previous frame, PCM is an audio signal, penaltyδ is the penalty for having the δ button pressed, pressedδ is 1 when button δ is pressed and 0 when it is not pressed, and penaltyapplication is a penalty value that may be computed by the application (i.e., the video game being played) .

[0119] The above Migration Cost Function is for a single frame, however in some embodiments, the cost function calculates a cost for multiple frames. For example, the cost for migrating at time t could be based on the aggregate cost for frames t to t-N.

[0120] In some embodiments of the present disclosure, combining each stream from the source engine instance and the destination engine instance may be performed at the remote client. In other embodiments, the combination of streams may be performed on the cloud, for example when bandwidth restrictions do not allow for dual streaming.

[0121] PLAYER-LOCAL GAME STATE REPRESENTATION

[0122] According to at least some embodiments of the present disclosure, there is provided a lightweight representation of a player’s local state. Due to its lightweight nature, this player-local game state representation allows for on-demand player migration requests and facilitates frequent backup requests to achieve fault tolerance.

[0123] Simply migrating a player from one engine instance to another without transferring the player’s state disrupts the game state for all players. In order to avoid this problem, a lightweight representation of a player’s game state may be provided to the destination engine instance.

[0124] The player-local game state may be represented by entities, components, logic, I / O, and animations.

[0125] Entities and components related to a player may be serialized for transfer to the destination engine instance. This may include, without limitation, a player’s position, a location and orientation of a player’s camera, the clothes worn by the player, the equipment carried by a player, the equipment equipped by a player, the abilities or special powers a player may have earned or activated, a health level of a player, and a power level of a player, amongst others.

[0126] Moreover, player-specific logical components (such as scripts) may be queried to create a compact key-value representation of the player logic. For example, a walking speed of the player may be stored as playerSpeed on the source engine instance. On the destination engine, the playerSpeed key may be accessed to retrieve the player’s walking speed.

[0127] Relevant I / O information such as held down buttons or open file descriptors may also be transferred to the destination engine.

[0128] According to at least some embodiments, the animation frame of all animations visible to the player may also be transferred to the destination engine. For example, if migration occurs while a player is jumping, the destination engine instance may skip the first few frames of the jumping animation instead of playing the jumping animation from the beginning.

[0129] The above lightweight player-local game state representation may also be used as a checkpoint for fault tolerance. By periodically backing up this state, the session of a player may be restored upon any interruption, such as unexpected game engine failures or network disconnections.

[0130] PLAYER-LOCAL MICRO-STATE SYNCHRONIZATION

[0131] In order to prevent undesired changes to the game state during migration, the following techniques may be used:

[0132] ● Player-local game state synchronization

[0133] ● Hyper replication

[0134] ● Network role switching.

[0135] These techniques prevent loss of data and disruptions to the game state during migration, while minimizing the dual streaming blending artifacts.

[0136] Player-Local Game State Synchronization: According to at least some embodiments of the present disclosure, the player-local game state is migrated between engine instances during migration. For a reliable synchronization of the engine instances, the player state is continuously transferred from the source engine instance to the destination engine instance in the first half of the migration window. In the second half of the migration window, the player state is transferred from the destination engine to the source engine. This scheme ensures that the engine instances that primarily owns the player is responsible to send updates to the other engine.

[0137] Hyper Replication: During the migration window, the rate of replication for the source and destination engines is significantly increased, ensuring the overall game state is consistent between the two engines. This reduces the blending artifacts and improves the overall experience of the migrating player.

[0138] Network Role Switching: In most engines, the multiplayer system tracks ownership of entities through the Network Role. If a player is local to the engine, its network entities will have the Autonomous role. On all other engines, that player’s entities are hollow copies, and will have the Client role. To properly migrate the player from source to destination, the network role of a player’s network entities is switched from autonomous to client on the source engine instance, and from client to autonomous on the destination engine instance, at the migration switch point.

[0139] SYSTEM ARCHITECTURE

[0140] Reference is made to FIG. 5, which displays a cloud gaming environment architecture according to at least some embodiments of the present disclosure. This architecture is provided for illustrative purposes and is not intended to be limiting.

[0141] As seen in FIG. 5, game engine instances 502a, 502b, and 502c are connected to game server 503, creating the traditional client-server architecture of multiplayer games. The addition of remote clients 501a, 501b, 501c, and 501d and of streaming provider 504 converts this architecture to a cloud gaming environment, where streaming provider 504 manages the connection between the game engine instances and the remote clients (solid lines) . Once the initial connection is established, each remote client is directly connected to a game engine (dotted lines) to start streaming. For example, as illustrated in FIG. 5, remote clients 501a and 501b are connected to game engine instance 502a, remote client 501c is connected to game engine instance 502b, and remote client 501d is connected to game engine instance 502c. At any time, player migration can be initiated to move remote clients between game engines (modification of the dotted lines) .

[0142] During the migration window, the migrating client will be connected to two engine instances at the same time, stream blending may be performed on the client or on the cloud, player-local micro-states are synchronized by the source and destination engine instances and the game server, and the streaming provider controls the flow of migration.

[0143] During normal game play, each remote client transfers inputs to its associated game engine instance, and receives, from its associated game engine instance, audio and video streams. According to at least some embodiments, the game engine instance periodically backs up the player-local game state to the streaming provider (or other cloud entity) for fault tolerance.

[0144] MIGRATION MESSAGE FLOWS

[0145] Reference is made to FIG. 6, which illustrates a high-level method for cloud computing according to at least some embodiments of the present disclosure.

[0146] The method starts at block 600, and proceeds to block 610 where the game is launched by a user on the user’s remote client. Once the game is launched on the remote client, the remote client may establish a connection with a streaming provider, as illustrated by block 620.

[0147] The method then proceeds to block 630 where the streaming provider assigns a game engine instance to the user’s remote client, and to block 640 where the remote client establishes a connection with the assigned game engine instance.

[0148] Once a connection is established between the remote client and the game engine instance, game play may begin, as illustrated by block 650. During game play, the remote client may be migrated to a new game engine instance, as illustrated by block 660. During migration, dual streaming according to embodiments of the present disclosure may be performed. After migration, normal game play, in which the remote client is connected to a single game engine instance, may resume. Migration may occur multiple times during a gaming session, or not at all.

[0149] After the user is finished playing the game, the session ends, as illustrated by block 670, and all connections are released.

[0150] Reference is made to FIG. 7, which illustrates message flows between various components for performing migration according to at least some embodiments of the present disclosure.

[0151] The method begins with streaming provider 704 sending a request 710 to destination engine 702b for migrating a remote client to destination engine 702b. This may occur upon the streaming provider 704 or the game server 703 determining that more efficient resource sharing can occur by having the remote client being hosted by destination engine 702b rather than by source engine 702a, however, the present disclosure is not limited in this regard. According to at least some embodiments, a migration cost function may be computed prior to initiating migration, as described above.

[0152] Request 710 may comprise a remote client identifier.

[0153] Upon receiving request 710, destination engine 702b may assign resources for hosting the remote client, as illustrated by block 712. According to at least some embodiments, destination engine 702b may then indicate that request 710 is received and accepted, with message 714.

[0154] Streaming provider 704 may then send a request 716 to source engine 702a to begin the migration process for the remote client. Request 716 may comprise the remote client identifier.

[0155] Upon receiving request 716, source engine 702a sends a request 718 to application 705 for the player game state. Request 718 may comprise a player identifier. In this context, application 705 refers to the portion of the game created by game developers, as opposed to the game engine which may be shared by multiple games. The application is also run on the cloud, and together, the application and the engine form two separate layers of a single process. According to at least some embodiments, communications between application 705 and either one of game engine instances 702a and 702b use a scripting language. According to at least some embodiments, the scripting language is Lua, however the present disclosure is not so limited.

[0156] Upon receiving request 718, application 705 provides the player game state to source engine 702a, as indicated by message 720. The player game state may use the lightweight representation of the player game state described above. Source engine 702a may then provide the player game state to streaming provider 704, as indicated by message 722. Message 722 may also include a client identifier.

[0157] Streaming provider 704 may then start migration by sending message 724 to source engine 702a. Message 724 may include the client identifier. Source engine 702a then sends message 726 to application 705 to indicate that migration has begun. Message 726 may include a player identifier.

[0158] Streaming provider 704 also sends message 728 to destination engine 702b, indicating that migration has begun. Message 728 may include the client identifier and the player game state obtained by streaming provider 704 in message 722.

[0159] Destination engine 702b may then configure application 705 based on the player game state, as indicated by message 730, and then indicate to application 705 that migration has begun, as indicated by message 732. Messages 730 and 732 may comprise the player identifier.

[0160] During the first half of the migration window, both the source engine 702a and the destination engine 702b receive inputs from the remote client, and provide audio and video streams to the remote client. The remote client (or a cloud device) may then combine both streams based on the blending function. Techniques described above to minimize artifacts may be used. For example, blurring techniques may be used. During the first half of the migration window, micro-state synchronization may occur, based on the game state at source engine 702a.

[0161] At the midpoint of the migration window, streaming provider 704 may send messages 734 and 738, to source engine 702a and destination engine 702b, respectively indicating that the midpoint has been reached. Both messages 734 and 738 may include a client identifier.

[0162] Upon receiving message 734, source engine 702a sends message 736 to application 705, indicating that the migration switch point has been reached.

[0163] Upon receiving message 738, destination engine 702b sends message 740 to game server 703 to switch the network roles for source engine 702a and destination engine 702b. Specifically, any network entities on source engine 702a that belong to the player are switched from autonomous to client, and any network entities on destination engine 702b that belong to the player are switched from client to autonomous. Destination 702b further sends message 742 to application 705, to notify application 705 that the switch point has been reached.

[0164] During the second half of the migration window, both the source engine 702a and the destination engine 702b receive inputs from the remote client, and provide audio and video streams to the remote client. The remote client (or a cloud device) may then combine both streams based on the blending function. As during the first half of the migration window, techniques described above to minimize artifacts may be used. During the second half of the migration window, micro-state synchronization may occur, based on the game state at destination engine 702b.

[0165] Once migration is complete and the migration window is over, streaming provider 704 sends messages 744 and 748 to source engine 702a and destination engine 702b, respectively, indicating that migration is complete. Source engine 702a may then send a message 746 to application 705 indicating that migration is complete, and destination engine 702b may do the same with message 750.

[0166] The remote client may then release the connection to source engine 702a, and resume normal game play by providing inputs to only destination engine 702b and receiving audio and video streams from only destination engine 702b.

[0167] Reference is made to FIG. 8, which illustrates message flows between various components during the migration window according to at least some embodiments of the present disclosure.

[0168] The process begins with streaming provider 804 sending messages 810 and 814 to source engine 802a and destination engine 802b, respectively, indicating the start of the migration window. Upon receiving message, 810, source engine 802a may then send message 812 to game server 803, to enable hyper-replication. As discussed above, hyper-replication increases the rate of replication between source engine 802a and destination 802b.

[0169] During the first half of the migration window, source engine 802a may send request 816 to application 805 to obtain the player game state, and application 805 may provide source engine 802a the player game state with message 818. Request 816 may comprise a player identifier. Source engine 802a may then provide the player game state to streaming provider 804 with message 820, and streaming provider 804 may then provide the player game state to destination engine 802b, with message 822. This process of obtaining the player game state and providing it to destination engine 802b is generally repeated multiple times during the first half of the migration window, but for simplicity it is only shown once in FIG. 8.

[0170] Halfway through the migration window, streaming provider sends messages 824 and 826 to source engine 802a and destination engine 802b, respectively, to indicate that the migration switch point has been reached.

[0171] During the second half of the migration window, destination engine 802b may send request 828 to application 805 to obtain the player game state, and application 805 may provide destination engine 802b the player game state with message 830. Request 828 may comprise a player identifier. Destination engine 802b may then provide the player game state to streaming provider 804 with message 832, and streaming provider 802 may then provide the player game state to source engine 802a, with message 834. This process of obtaining the player game state and providing it to source engine 802a is generally repeated multiple times during the second half of the migration window, but for simplicity it is only shown once in FIG. 8.

[0172] Once the migration window is complete, streaming provider 804 sends messages 836 and 840 to source engine 802a and destination engine 802b, respectively, to indicate the end of the migration window. Upon receiving message 840, destination engine 802 may send message 838 to game server 803 to disable hyper-replication.

[0173] The above functionality may be implemented on any one or combination of computing devices. FIG. 9 is a block diagram of a computing device 900 that may be used for implementing the devices and methods disclosed herein. Specific devices may utilize all of the components shown, or only a subset of the components, and levels of integration may vary from device to device.  Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing device 900 may comprise a processor 910, memory 920, a mass storage device 940, and peripherals 930. Peripherals 930 may comprise, amongst others one or more input / output devices, such as a speaker, microphone, mouse, touchscreen, keypad, keyboard, printer, display, network interfaces, and the like. Communications between processor 910, memory 920, mass storage device 940, and peripherals 930 may occur through one or more buses 950.

[0174] The bus 950 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, video bus, or the like. The processor 910 may comprise any type of electronic data processor. The memory 920 may comprise any type of system memory such as static random-access memory (SRAM) , dynamic random-access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , a combination thereof, or the like. In an embodiment, the memory 920 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.

[0175] The mass storage device 940 may comprise any type of storage device configured to store data, programs (e.g. instructions or code) , and other information and to make the data, programs, and other information accessible via the bus. The mass storage device 940 may comprise, for example, one or more of a solid-state drive, hard disk drive, a magnetic disk drive, an optical disk drive, or the like. The memory 920 or mass storage 940 may store instructions, which when executed by a processor or processing unit, cause or configure the computing device 900 to perform any of the methods described herein.

[0176] Computing device 900 may further comprise a communications subsystem 960 for communicating with other computing devices or for connecting computing device 900 to a computer network. Communications subsystem 960 may comprise one or more network interfaces (not shown) , which may comprise wired links, such as an Ethernet cable or the like, and / or wireless links to access nodes or different networks. The network interface allows the processing unit to communicate with remote units via the networks. For example, the network interface may provide wireless communication via one or more transmitters / transmit antennas 970 and one or more receivers / receive antennas 970. In an embodiment, the processing unit is coupled to a local-area network or a wide-area network, for data processing and communications with remote devices, such as other processing units, the Internet, remote storage facilities, or the like.

[0177] Computing device may further comprise a power source 980.

[0178] The present disclosure may be implemented on a computing device such as exemplary computing device 900. Computing device 900 may be a network element of a telecommunications network, such that the network element may be connected to other network elements of the telecommunication network, where all network elements form the telecommunication network. The network element may also receive communications from client devices connected to the telecommunication network and provide services to such client devices.

[0179] Through the descriptions of the preceding embodiments, the teachings of the present disclosure may be implemented by using hardware only or by using a combination of software and hardware. Software or other computer executable instructions for implementing one or more embodiments, or one or more portions thereof, may be stored on any suitable non-transitory computer readable storage medium. The computer readable (or computer-readable) storage medium may be a tangible medium such as optical (e.g., CD, DVD, Blu-Ray, etc. ) , magnetic, hard disk, volatile or non-volatile, solid state, or any other type of storage medium known in the art.

[0180] Additional features and advantages of the present disclosure will be appreciated by those skilled in the art.

[0181] The structure, features, accessories, and alternatives of specific embodiments described herein and shown in the Figures are intended to apply generally to all of the teachings of the present disclosure, including to all of the embodiments described and illustrated herein, insofar as they are compatible. In other words, the structure, features, accessories, and alternatives of a specific embodiment are not intended to be limited to only that specific embodiment unless so indicated.

[0182] Moreover, the previous detailed description is provided to enable any person skilled in the art to make or use one or more embodiments according to the present disclosure. Various modifications to those embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the teachings provided herein. Thus, the present methods, systems, and or devices are not intended to be limited to the embodiments disclosed herein. The scope of the claims should not be limited by these embodiments, but should be given the broadest interpretation consistent with the description as a whole. Reference to an element in the singular, such as by use of the article "a" or "an" is not intended to mean "one and only one" unless specifically so stated, but rather "one or more" . All structural  and functional equivalents to the elements of the various embodiments described throughout the disclosure that are known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the elements of the claims.

[0183] Furthermore, nothing herein is intended as an admission of prior art or of common general knowledge. Furthermore, citation or identification of any document in this application is not an admission that such document is available as prior art, or that any reference forms a part of the common general knowledge in the art. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.

[0184] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above.It is intended that the appended claims cover such modifications and variations.

Claims

1.A method implemented on a computing device, the computing device controlling a first game engine instance and a second game engine instance, comprising:determining that a remote client hosted by the first game engine instance is to be migrated to the second game engine instance;retrieving, from the first game engine instance, a player game state;providing, to the second game engine instance, the player game state; andduring a migration window:receiving a first audio-video stream from the first game engine instance;receiving a second audio-video stream from the second game engine instance;combining the first audio-video stream and the second audio-video stream thereby creating a combined stream;transmitting, to the remote client, the combined stream;receiving user input signals from the remote client; andproviding the user input signals to the first game engine instance and the second game engine instance.2.The method of claim 1, further comprising:determining that a halfway point of the migration window has been reached; andindicating to the first game engine instance and the second game engine instance that the halfway point of the migration window has been reached.3.The method of claim 2, further comprising:upon determining that the halfway point of the migration window has been reached:switching a network role of the first game engine instance from autonomous to client; andswitching a network role of the second game engine instance from client to autonomous.4.The method of claim 2, further comprising:prior to said determining that the halfway point of the migration window has been reached:periodically retrieving the player game state from the first game engine instance and providing the player game state to the second game engine instance.5.The method of claim 4, further comprising:after said determining that the halfway point of the migration window has been reached:periodically retrieving the player game state from the second game engine instance and providing the player game state to the second game engine instance.6.The method of claim 1, wherein the combined stream includes the first audio-video stream and the second audio-video stream.7.The method of claim 1, wherein the combined stream is computed using where O (t) is the combined stream for time t, Isource (t) , is the first audio-video stream for time t, Idest (t) is the second audio-video stream for time t, S (t) is a blending function, and L is a length of the migration window.8.The method of claim 7, wherein S (0) =0, S (0.5) =0.5, S (1) =1, S (t) +S (1-t) =1, S (t) is differentiable for t∈ (0, 1) , and S (t) is monotonically increasing over (0, 1) .9.The method of claim 8, wherein S (t) is selected from the group comprising S (t) =4t3-6t2+3t , S (t) =t , and 10.The method of claim 8, further comprising applying a blur to the combined stream.11.The method of claim 10, wherein the blur has a strength that is proportional to a derivative of S (t) .12.The method of claim 10, wherein applying the blur comprises applying a 2-dimensional Gaussian blur to a video portion of the combined stream, and applying a 1-dimensional Gaussian blur to an audio portion of the combined stream.13.The method of claim 8, further comprising applying a fade multiplier to an audio portion of the combined stream.14.The method of claim 1, further comprising, prior to said determining that the remote client is to be migrated, computing a migration cost function.15.The method of claim 14, wherein the migration cost function comprises: where f is an index for a current frame, Pixels is the set of all pixels for a given frame, PCMf is the audio stream for a given frame, penaltyδ is a penalty associated to an input button δ, pressedδ is 1 when button δ is pressed and 0 when button δ is not pressed, and penaltyapplication is a penalty provided by an application.16.The method of claim 1, further comprising, during the migration window, increasing a rate of replication for the first game engine instance and the second game engine instance.17.A computing device comprising:a processor; anda communications subsystem;wherein the computing device is configured for performing the method of any one of claims 1 to 16.18.A computer-readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions for performing the method of any one of claims 1 to 16.19.A method implemented on a computing device, comprising:receiving, from a streaming provider, a first audio-video stream and a second audio-video stream during a migration window;blending the first audio-video stream and the second audio-video stream together to create an output stream; anddisplaying the output stream on an output device.20.The method of claim 19, further comprising:receiving an input signal from an input device; andtransmitting the input signal to the streaming provider.21.The method of claim 19, wherein said blending uses where O (t) is the output stream for time t, Isource (t) , is the first audio-video stream for time t, Idest (t) is the second audio-video stream for time t, S (t) is a blending function, and L is a length of the migration window.22.The method of claim 21, wherein S (0) =0, S (0.5) =0.5, S (1) =1, S (t) +S (1-t) =1, S (t) is differentiable for t∈ (0, 1) , and S (t) is monotonically increasing over (0, 1) .23.The method of claim 22, wherein S (t) is selected from the group comprising S (t) =4t3-6t2+3t, S (t) =t , and 24.The method of claim 22, further comprising applying a blur to the output stream.25.The method of claim 24, wherein the blur has a strength that is proportional to a derivative of S (t) .26.The method of claim 24, wherein applying the blur comprises applying a 2-dimensional Gaussian blur to a video portion of the output stream, and applying a 1-dimensional Gaussian blur to an audio portion of the output stream.27.The method of claim 22, further comprising applying a fade multiplier to an audio portion of the output stream.28.A computing device comprising:a processor; anda communications subsystem;wherein the computing device is configured for performing the method of any one of claims 19 to 27.29.A computer-readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions for performing the method of any one of claims 19 to 27.

Images