U.S. Pat. No. 11,325,031

DESCRIPTION OF THE EMBODIMENTS

Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views,FIG. 1schematically illustrates the overall system architecture of a video games console. InFIG. 1, the games console corresponds to a Sony® PlayStation 4® entertainment device. A system unit10is provided, with various peripheral devices connectable to the system unit. The system unit10comprises an accelerated processing unit (APU)20being a single chip that in turn comprises a central processing unit (CPU)20A and a graphics processing unit (GPU)20B. The APU20has access to a random-access memory (RAM) unit22. The APU20communicates with a bus40, optionally via an I/O bridge24, which may be a discrete component or part of the APU20. In some examples, the entertainment device may further comprise a tensor processor unit (TPU) (not shown).

Connected to the bus40are data storage components such as a hard disk drive37, and a Blu-ray® drive36operable to access data on compatible optical discs36A. Additionally the RAM unit22may communicate with the bus40. Optionally also connected to the bus40is an auxiliary processor38. The auxiliary processor38may be provided to run or support the operating system.

The system unit10communicates with peripheral devices as appropriate via an audio/visual input port31, an Ethernet® port32, a Bluetooth® wireless link33, a Wi-Fi® wireless link34, or one or more universal serial bus (USB) ports35. Audio and video may be output via an AV output39, such as an HDMI port.

The peripheral devices may include a monoscopic or stereoscopic video camera41such as the PlayStation Eye®; wand-style videogame controllers42such as the PlayStation Move® and conventional handheld videogame controllers43such as the DualShock 4 ®; portable entertainment devices44such as the PlayStation Portable® and PlayStation Vita®; a keyboard45and/or a mouse46; a media controller47, for example in the form of a remote control; and a headset48. Other peripheral devices may similarly be considered such as a printer, or a3D printer (not shown).

The GPU20B, optionally in conjunction with the CPU20A, generates video images and audio15for output via the AV output39. Optionally the audio may be generated in conjunction with or instead by an audio processor (not shown).

The video and optionally the audio may be presented to a television51. Where supported by the television, the video may be stereoscopic. The audio may be presented to a home cinema system52in one of a number of formats such as stereo, 5.1 surround sound or 7.1 surround sound. Video and audio may likewise be presented to a head mounted display unit53worn by a user60.

In operation, the entertainment device defaults to an operating system such as a variant of FreeBSD 9.0. The operating system may run on the CPU20A, the auxiliary processor38, or a mixture of the two. The operating system provides the user with a graphical user interface such as the PlayStation Dynamic Menu. The menu allows the user to access operating system features25and to select games and optionally other content.

The video games console shown inFIG. 1is just one example of a video game playing device at which computer program instructions corresponding to a video game may be executed. It will be appreciated that other types of video game playing device are not excluded. In the present disclosure, any computing device that is capable of receiving player inputs (directly or indirectly) and generating a video signal (corresponding to a video game instance) for output at a display, is considered as a video game playing device. A video game playing device may include, for example, a personal computer (PC), smartphone, laptop, tablet, smart TV, set-top box, portable gaming device, games controller, etc.

In the present disclosure, each video game playing device comprises a CPU and/or GPU for rendering instances of a video game. Here, the term video game instance refers to a respective player's view of a virtual environment that is provided by a video game. As will be appreciated, a player's view of the virtual environment will depend on actions performed by the player, as well as events occurring within the virtual environment and actions performed by other players (real or NPCs). In online multiplayer video games, each player may have a different respective view of the virtual environment.

In the present disclosure, each video game playing device provides a respective participant of a video game session with access to an online multiplayer game. For this reason, each computing device is referred to as a client device. The video game session may correspond to e.g. a sports or combat match, such as a battle-royale mode combat match. Each client device is in communication with a central game server, via a communications network. The game server receives and processes each player's input and generates an authoritative source of events occurring within the video game. The game server transmits data about its internal state to the connected client devices, enabling each client device to maintain their own accurate version of the virtual world for display to a corresponding player. In this way, each player is able to concurrently populate a common virtual environment.

The client devices described herein are also able to access a cloud gaming service that is made available by one or more servers, via a communications network. Video game instances rendered at the client devices are said to be rendered locally, whereas video game instances rendered using the cloud game service are said to have been rendered remotely.

As mentioned previously, for online multiplayer games, rendering video game instances at respective client devices can result in a dropin frame rate and or visual fidelity when there is a high density of players within a given region of a virtual environment. As the density of players within a given region increases, there is a corresponding increase in the number of players and associated events that need to be rendered for a player in that region. In turn, this can result in an excessive load being placed on the CPU and or GPU of the client device for a player operating within that region.

Moreover, as the density of players in a given region increases, network traffic associated with the online video game session may also increase. This may occur as a result of e.g. more in-game events occurring as more players come into interaction with one another. As described previously, excessive network traffic is undesirable since it may lead to a lag in the updating of the virtual environment for a given player.

Client-side prediction is a commonly used technique in multiplayer network games and is used to improve latency of gameplay by predicting movement on the game client, and monitoring this prediction, and adjusting as necessary against server information. Examples of client-side prediction techniques are publicly available, for example, at https://en.wikipedia.org/wiki/Client-side_prediction. However, typically these techniques fail to consider that, as the player density increases, the scope for processing client or server adjustment increases. For example, usually, a client device will predict the motion of other remote players appearing in a local player's view of the environment, based on updates received from the game server. If the updates received from the server correspond with the predicted movement, then no adjustments are made to the display of the other players. However, in some cases, it may be that the display of one or more players needs to be adjusted, based on a discrepancy between what was predicted for those players (at the client) and the updated information received from the server. As the density of remote players within the vicinity of the local player increases, there is a corresponding increase in the amount of prediction and adjustment that needs to be performed at the client device. Any delays caused by this additional prediction and adjustment can result in the other players appearing to jump between animation or locations. Clearly, the display of the other players in this manner is undesirable and results in a less immersive experience for the local player.

FIG. 2shows schematically an example of a map of an open world of an online multiplayer video game. InFIG. 2, the map is shown as comprising a river, trees, buildings and mountains202. The map may correspond to the Fortnite® map and players may be able to control where they enter the map from by skydiving from a vehicle that traverses across the map.FIG. 3shows an example of a plurality of players entering the virtual environment from similar locations.

Allowing players to control their starting position often leads to hot spots of activity, i.e. popular places for players to enter or begin playing from within the virtual environment. An example of these hot spots is shown inFIG. 2by shaded regions204. The hot spot regions may correspond to areas of the map where there is more cover, provided by e.g. buildings, trees, rocky terrain, etc. It may also be that players know that certain desirable in-game items are more likely to be found in certain regions and so players may flock to these regions when starting the video game session. As mentioned above, high densities of players within a given region of the virtual environment can result in excessive load being placed on the GPU and or CPU of the client devices associated with those players.

In some video games, there are game modes that further exacerbate the problem of large numbers of players entering the virtual environment at similar locations. For example, Fortnite® provides ‘Large Team Modes’ where up to 50 players can join a respective team. In such a mode, the players on a given team are typically dropped into the map at similar locations, thus increasing the density of players within that region of the virtual environment. Fortnite® also provides a mode in which the size of the playable map shrinks as time progresses, thus forcing players into closer contact with another. Again, this can result in a high density of players occupying a given region of the virtual environment.

As mentioned previously, the increase in density of multiple concurrent players operating within a given region of a virtual environment can result in a reduction of the framerate and/or visual fidelity of the video that is rendered for those players. An example of how the visual fidelity may be reduced for a given player is shown inFIG. 4. InFIG. 4, it can be seen that the level of detail has been reduced for a region of the virtual environment that a player has zoomed in on with their sniper rifle. This region may correspond to an area that is populated by multiple concurrently playing players. Alternatively or in addition, it may be that the level of detail shown inFIG. 4has been reduced because that region is relatively far from the player, and the player's client device has inadequate information for rendering that part of the environment with more detail.

In any case, it would be desirable if this compromise in visual fidelity and/or frame rate could be avoided, with the video displayed to each player corresponding to an accurate rendering of the virtual environment and other players concurrently populating the virtual environment. A method for obtaining such a video will now be described in relation toFIG. 5.

At a first step S501, player inputs and game state information from a plurality of client devices participating in a video game session is obtained. The player inputs may correspond to e.g. controller inputs received at a controller device that each participant is using to control a respective avatar within a shared virtual environment. The game state information may include player state information such as e.g. the location of a respective player in the shared virtual environment, a game mode associated with a respective player (e.g. team mode), an identity associated with a respective player, the identities of other players on the same team as that player, etc. The game state information may also include information about the state of the virtual environment, such as e.g. a game mode (e.g. map shrinking), physics calculations that are to be performed, etc. The player inputs and game state information may be received at e.g. a game server from the respective client devices, via a communications network.

At a second step S502, it is determined, based on the obtained game state information that at least one of the client devices participating in the video game session is likely to render a video game instance with a quality that is less than a threshold quality. In preferred examples, the obtained game state information provides an indication of a density of players concurrently populating a region of the shared virtual environment. Thus, step S502may involve determining, based on the locations and game modes associated with one or more players, that the quality of the video game instances rendered for those players (at their respective client devices) is likely to drop below a threshold quality. In this way, step S502comprises predicting, based on the obtained game state information, whether at least one of the CPU usage, GPU usage and network traffic associated with one or more players is likely to negatively impact their experience of the video game session. The threshold quality may correspond to e.g. a predetermined frame rate, visual fidelity, etc.

Step S502may be performed at, for example, a central server that the client device is in communication with via a communications network. The central server may correspond to the game server described previously but programmed to perform at least some of the present method.

Alternatively, step S502may be performed at a separate server (e.g. a monitoring server) forming part of the cloud gaming service, that is in communication with the client device and the game server. The monitoring server may be configured to instruct a cloud device to commence rendering of a video game instance, based on the obtained game state information, and to instruct the client device to switch to a second mode, in which video rendered by the cloud device is received and output for display. In some examples, step S502may be performed by both the game server and monitoring server, with the game server instructing the client device as to when to switch to a second mode and the monitoring server ensuring that the video game instance is rendered at a cloud device, as soon as required.

Alternatively or in addition, step S502may be performed at the client device. For example, the client device may receive the game state information from e.g. the game server in the usual manner, and determine, based on the obtained game state information that the quality of video rendered at the client device has or is likely to drop below the threshold quality.

In some examples, step S502may be performed less frequently, in response to an initial determination that a given client device is unable to render its video game instance with a sufficiently high render quality (e.g. following a hysteresis once rendering is switched to the cloud). Again, this checking of the render quality may be performed at one or more of a central server, separate monitoring server, or even the client device.

At a third step S503, the at least one client device that is determined as being likely to render the video game instance at a quality that is less than a threshold quality, is identified. This identification may be performed based on a client identifier. For example, each client device may transmit a client identifier to a game server, in order to establish a video game session between those client devices. At step S503, the at least one client device may be identified based on its associated client identifier. There may be a first step of determining which, if any, of the client devices are likely to render a respective video game instance at a quality that is less than a threshold quality, and then storing a client identifier associated with those client devices, for later use, as will be described below.

Step S503may be performed at e.g. the game server or a monitoring server that is responsible for receiving data from the game server and determining which, if any of the client devices, would benefit from having their respective video game instance rendered by a cloud game client.

Alternatively, or in addition, a client device may be responsible for receiving the obtained game state information and identifying itself as being likely to be unable to render a video game instance with a sufficient render quality. In such examples, the client device may inform e.g. the game server and or a monitoring server that it would benefit from outsourcing at least some of the rendering to a cloud device.

At a fourth step S504, a cloud game client (CGC) is allocated to the identified client device. The cloud game client may correspond to a duplicate of a video game client implemented at the client devices. The cloud game client may comprise a pool of an instance of hardware available on the network (forming part of ‘the cloud’) having more powerful CPU and GPU capabilities than the client device. Hence, allocating the cloud game client may involve identifying one or more cloud devices (forming the cloud gaming service) having greater CPU and or GPU resources available for rendering the video game instance than the client device(s) identified at step S503. The cloud game client may be already installed at the identified cloud devices, which simply wait to receive the synchronization status of a given player, so that a corresponding view of the virtual environment can be rendered for that player.

The cloud game client may be configured to create a gameplay session for those game clients that are about to experience a low frame rate (or visual fidelity) experience. Hence, at a fifth step S505, the method may comprise providing the player inputs from the at least one identified client device and the obtained game state information, to the cloud game client. The player inputs and the obtained game state information may be provided from e.g. the game server to the one or more cloud devices at which the cloud game client is being implemented. In some examples, the obtained game state information may be provided to cloud game client from the game server, and the player inputs provided directly to the cloud game client from the client device.

At step S506, the method comprises rendering, based on the obtained game state information and player inputs provided to the cloud game client, the video game instance for the identified client device. This rendering may involve generating a video stream for outputting at a display associated with the identified client device. The video stream may correspond to a respective view of the virtual environment for the player associated with the identified client device.

At step S507, the method comprises transmitting the video game instance rendered by the cloud game client to the corresponding (identified) client device. The video game instance, in the form a video stream, may be transmitted to the client device via the communications network. The method may further comprise displaying the received video stream at a display associated with the client device. In some examples, the client device may include an integrated display and the received video stream may be displayed at this display. In other examples, the client device may be connected, e.g. via a wired or wireless connection, to a separate display. In such examples, the client device may be operable to cause the video stream received from the cloud game client to be displayed at the display, instead of the corresponding video generated at the client device.

In some examples, the method may comprise ceasing rendering the video game instance rendered at the at least one identified client device, in response to receiving the video game instance rendered by the cloud game client. For example, the cloud game client may be configured to instruct the at least one identified client device to cease generating the video output, for the player. The player inputs received at the least one client device may be provided by the client device to the cloud game client, for processing at the cloud game client instead of at the client device. This may ensure that e.g. the CPU of the client device is freed up for other operations. In some examples, the client device may simply cease rendering the video game instance if any video is received from the cloud game client.

The method may also comprise obtaining, via the communications network, updated game state information. That is, the method may comprise continuously monitoring the game state information and determining which, if any, of the client devices are likely to benefit from having their respective video game instances rendered by a cloud game client. For client devices that were previously identified as needing a cloud game client (and having their respective video game instances rendered at the cloud game client), it may be determined, based on the updated game state information, that the quality of video game instances rendered at those client devices will no longer be below the threshold quality. This may correspond to detecting e.g. that the density of players within a given player's vicinity (or viewing frustum) has dropped below a threshold value, or that a player or game mode associated with a given player is no longer applicable.

Determining that an identified client device is no longer likely to render its video game instance at a quality that is below the threshold quality may be determined by one or more of the game server, monitoring server, or the identified client device. In the latter case, it may be that the identified client device is able to determine this based on game state information obtained from the game server.

In response to such a determination, the corresponding video game instances may no longer be rendered at the cloud game client. This may involve, for example, transmitting an instruction to the identified client devices, instructing them to revert to rendering their own respective video game instances. Alternatively, the client devices may be configured to switch to local rendering if video has not been received from the cloud game client within a pre-determined time interval. In some examples, it may be that client devices continue rendering their own video game instances, but at a lower quality, whilst the video game instances are being rendered at the cloud game client. Whilst this may appear counterintuitive, it has the benefit of updating environment model data, textures and game assets relevant to the current state of play in the client device in a manner that is transparent to the game, as play progresses in the cloud instance, so that there is not any additional rendering delay caused by needing to newly access game assets locally when the switch back to local rendering is made. It also means that in principle a locally rendered image could substitute for a cloud originating image in the event that there is a streaming interruption. Optionally the locally rendering pipeline could be truncated, e.g. before issuing drawing lists to the GPU, or potentially earlier in the process, once the benefits of maintaining current game assets has been achieved. In response to a determination that the cloud game client need no longer render those video game instances, the client devices may revert to rendering the video game instances at a higher quality (e.g. higher resolution).

As mentioned above, in some examples, the client devices may be operable to determine whether or not cloud-based rendering of their video game instances is needed. In such examples, each client device may report their status to the monitoring server, which based thereon, determines whether the video game instance is to be rendered by the cloud game client. In response to receiving an indication that the render quality is no longer likely to be below the threshold quality, the monitoring server may instruct the corresponding cloud game client to cease rendering those video game instances.

In other examples, this determination may be made at e.g. the game server and/or monitoring server, which may then instruct the client device to switch back to a first mode in which the video game instance is rendered locally.

By no longer rendering a video game instance at the cloud game client, the cloud game client may be used to render video game instances for other client devices identified as being likely to render their respective video game instances at an undesirable render quality. In examples where multiple cloud game clients are created, it may be that, in response to determining that a client device no longer needs its respective cloud game client, the cloud game client for a given client is returned to the pool of available cloud game clients for use by another client device.

In some examples, a computer readable medium having computer executable instructions may be adapted to cause a computer system to perform the method steps described above.

In preferred examples, at least some of the method steps are implemented by a monitoring unit that determines whether, and for whom, a cloud game client is to be used for rendering the video game instances of a video game session. The monitoring unit may correspond to software that is installed at a game server or at a separate monitoring server, as described above. In alternative examples, the functionality of the monitoring unit may be located at the client device.

Generally, the functionality of the monitoring unit may be located at any of the game server, monitoring server and client device. In some examples, this functionality may be shared by or split between any two or all three of these. For example, the client devices may be responsible for determining when the render quality is likely to drop below the threshold quality and informing the game server and/or monitoring server accordingly. The game server and/or monitoring server may then control which, if any, of the video game instances are to be rendered by a cloud game client and ensure that these video game instances are transmitted to the corresponding client devices.

An example of a cloud gaming system for implementing the above described method will now be described in relation toFIG. 6.

FIG. 6shows schematically an example of a cloud gaming system600for controlling the rendering of a video game instance. The cloud gaming system600comprises a plurality of client devices (referred to as ‘game clients’)602, each being operable to run a video game client and render a video game instance of a respective video game. Each client device602is associated with a respective participant of an online video game session that is facilitated via the cloud gaming system600shown inFIG. 6. As described previously, the client devices602are operable to generate a video output, corresponding to a player's view of a virtual environment. The client devices602may comprise or be connected to a display (not shown) that is operable to display the video generated by the client device.

The cloud gaming system600also comprises a games unit operable to receive, via a communications network, player inputs and game state information from the client devices602participating in a video game session. InFIG. 6, the games unit corresponds to a game server604. The communications network may correspond to, for example, a wide-area network (WAN) such as the Internet. The games unit keeps track of events occurring within the video game session and maintains an authoritative version of a shared virtual environment. The client devices602are configured to render a respective view of the virtual environment based on information received from the games unit. InFIG. 6, this information is referred to as network traffic and may include e.g. locations of players in the virtual environment, geometry of the virtual environment (e.g. meshes, shader objects, textures), actions and inputs from players, etc.

The system600also comprises a monitoring unit606operable to receive game state information for the video game session and, based thereon, identify one or more client devices602as being likely to render video game instances with a quality that is less than a threshold quality. InFIG. 6, the monitoring unit606is shown as a separate monitoring unit606, however in some examples, the monitoring unit606may comprise a software module installed at the game server604, or optionally as part of a supervisory control unit of the cloud gaming service (not shown), for allocating cloud game clients. The monitoring unit606may correspond to a monitoring server that is in communication with the game server604via the communications network.

As described previously, the game state information provides information indicative of a density of players concurrently occupying or likely to occupy a region of the virtual environment, and includes a status of the players participating in the video game session (e.g. location in virtual environment, team mode) and a status of the virtual environment (e.g. map shrinking) This information enables the monitoring unit606to predict whether the game requirements for a given player are likely to exceed the e.g. GPU and CPU capabilities of that player's client device.

The games unit (e.g. games server604) is configured to receive an input from the monitoring unit606, and in response thereto, provide the game state information received from the identified client devices602to a cloud game client. In some examples, the games unit also provides the player inputs received from the game clients to the cloud game client. However, in other examples, the identified client devices602may be instructed to send the associated player inputs directly to the cloud game client608for processing. This instruction may be sent to the client devices602from the monitoring unit606(optionally, via the games unit).

The games unit may be configured to allocate a cloud game client608to the identified client devices602, or may instruct a supervisory control unit of the cloud game service to do so. As mentioned previously, the cloud game client608corresponds to a duplicate of the video game client implemented at the client devices602. The cloud game client608is operable to receive player inputs and game state information for one or more players, and based thereon, render a view of the virtual environment for those players.

InFIG. 6, the cloud game client608is shown as a separate unit to the game server604and monitoring unit606. The cloud game client608may correspond to code that is implemented at one or more cloud devices such as servers. InFIG. 6, the game server604, monitoring unit606and cloud game client608are shown as being contained within a cloud icon. The cloud icon is intended to represent the game server604, monitoring unit606and cloud game client608as corresponding to a cloud gaming service. The cloud gaming service enables each client device to participate in a video game session, wherein at least some of the rendering of respective video game instances can be performed remotely. However, it will be appreciated that optionally the cloud gaming service may be separate to the game server, and may for example provide rendering assistance to client devices for multiple game titles having their own respective game servers.

InFIG. 6, the game server604is shown as providing an input to the cloud game client608in the form of ‘game client traffic’. The game client traffic may correspond to the game state information for the identified client devices602—i.e. the information needed to render a video game instance for a given player. Thus, the game server604may be configured to route the obtained game state information to the cloud game client, in response to the input received from the monitoring unit606.

InFIG. 6, the player inputs are shown as being routed directly from the game clients602to the cloud game client608. This may be more preferable than sending the player inputs to the cloud game client608via the game server604, since any delay introduced by the processing of the inputs at the game server604will be avoided. In such examples, it may be that the obtained game state information is used to render a view of the virtual environment based on the actions of other players, with the player inputs received from a given client device being used to adjust the view for that player. Once rendered, the view may be sent back to the game client602, via the game server604.

InFIG. 6, the cloud game client608is also shown as receiving an input (‘control CGC instance’) from the monitoring unit606. The input received from the monitoring unit606may be used to control whether or not a video game instance is rendered at the cloud game client. For example, the monitoring unit606may be configured to determine, based on updated game state information, that the quality of the video game instances rendered at the one or more identified client devices602will no longer be less than the threshold quality. In response to this determination, the games unit may be configured to cause the cloud game client608to no longer render the video game instances for the one or more identified client devices602. The input received from the monitoring unit606at the cloud game client608may thus be used to instruct the cloud game client608as to which client devices602are to have their respective video game instances rendered by the cloud game client.

In some examples, it may be that multiple instances of the cloud game client608are installed at one or more cloud devices, with each cloud game client608serving different players or groups of players. The monitoring unit606may be used to control which cloud game client608instances are used by the different players. For example, in response to detecting that the game requirements for a given player has lowered to the point that the local device can or is likely to be able render at the full framerate (e.g. 60 fps), the monitoring unit606may instruct the corresponding cloud game client608instance to cease rendering the video game instance for that player. This may result in the cloud game client608instance being returned to the pool of available cloud game client608instances, for use by another game client, as requested by the monitoring unit606. In some examples, the cloud game client608instance may be re-allocated to a different client device (for which the e.g. GPU requirements are still expected to exceed the capabilities of the local device).

The system600further comprises an output unit (not shown) operable to transmit video game instances rendered by the cloud game client608to corresponding identified client devices602. The output unit may form part of the one or more cloud devices at which the cloud game client608is implemented. The player inputs and game state information received at the cloud game client608may be provided along with a client device identifier (e.g. IP address) that enables to the renderings generated by the cloud game client608to be transmitted to the corresponding respective client devices602. As shown inFIG. 6, the output of the cloud game client608may correspond to video streams for display at (or via) the client devices602identified by the monitoring unit606. InFIG. 6, the cloud game client608is shown as providing an output in the form of a ‘game video stream’. The video streams correspond to respective player's view of the virtual environment.

The client devices602may be operable to control whether the video game instances rendered locally or remotely are output for display at an associated display. In some examples, the client devices602may be configured to cease rendering video game instances locally in response to receiving a video game instance that has been rendered remotely. The client devices602may also be configured to revert to local rendering, in response to an input or lack of input received from the cloud game client.

In additional or alternative examples, the monitoring unit606may be operable to instruct the client devices602to cease or revert back to rendering video game instances locally. For example, the client device602may be configured to operate in a first mode, wherein in the first mode the client device602runs a video game instance and sends client generated game state data and user inputs to a server, and receives updated game state data upon which to base rendering of the video game instance. The client device602may be operable to receive a signal indicating that it is to switch to a second mode without interruption, wherein in the second mode the rendering of the same game instance is performed by a remote cloud server and the resulting image is transmitted to the client device for display. That is, in the second mode, the client device is configured to display or cause to be displayed, video received from the remote cloud server. As described previously, the client device may correspond to an entertainment device, such as e.g. a games console, portable games console, smartphone, tablet, etc. It will be further appreciated that the entertainment device (client device) may operate in any of the manners described previously in relation toFIGS. 5 and 6.

Whilst the above system has been described in relation to client devices operable to connect to one or more servers forming a cloud gaming service, it will be appreciated that in some examples, the cloud gaming service may be formed of a peer-to-peer network of remote client devices connected to one another and a local client device, via a communications network. In such embodiments, the functionality of the monitoring unit and/or the cloud-based rendering may be performed at the remote client devices forming part of the P2P cloud gaming network, with the client device being operable to switch between the first and second modes based on information (and possibly, renders) received from one or remote client devices.

The techniques described above may be implemented in hardware, software or combinations of the two. In the case that a software-controlled data processing apparatus is employed to implement one or more features of the embodiments, it will be appreciated that such software, and a storage or transmission medium such as a non-transitory machine-readable storage medium by which such software is provided, are also considered as embodiments of the disclosure.

The foregoing discussion discloses and describes merely exemplary embodiments of the present invention. As will be understood by those skilled in the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting of the scope of the invention, as well as other claims. The disclosure, including any readily discernible variants of the teachings herein, defines, in part, the scope of the foregoing claim terminology such that no inventive subject matter is dedicated to the public.