Method of updating a game state, client terminal system, and server

Abstract

A client terminal system configured to update a game state in a multiplayer game, wherein said game state changes in dependence on player states of the multiplayer game, the client terminal system bei

Description

Technical field The present invention relates to a method of updating a game state in a multiplayer game and a gaming system for performing the same. The invention further relates to a client terminal system and a server for performing respective parts of the method and computer program products carrying instructions for causing the client terminal system and server to perform the same. Background In multiplayer games, each player transmits its state to each of the other players through an intermediary (host) server. Typically, this player state update is performed periodically, for example, at around 30-60 Hz. Considerable bandwidth is consumed in this process. An improved approach, with reduced bandwidth overheads and which is capable of supporting a larger number of players (e.g., > 30), is desirable. Summary of the Invention According to a first aspect of the invention, there is provided a client terminal system configured to update a game state in a multiplayer game, wherein said game state changes in dependence on player states of the multiplayer game, the client terminal system being configured to: perform a loop; and update the game state based at least on an output of the loop, wherein, the loop comprises: predicting, using a primary state model, a player state according to a control input predicted to be made by an operator of the client terminal system and a player state for each of one or more other players in the multiplayer game according to their respective predicted control inputs; and outputting the predicted player states. The system may further be configured to render, and optionally display, video content according to the updated game state. The system may further be configured to: determine a present player state according to a control input made by the operator of the client terminal system; and conditional upon a difference between said present player state and the predicted player state for the same player being greater than a predetermined threshold: update the game state according to the predicted player states for each of the other players and said present player state. The system may further be configured to: transmit the present player state to a server. The loop may further comprise: predicting, for each player in the multiplayer game, one or more further player states according to control inputs respectively predicted to be made by one or more auxiliary state models; and outputting the one or more further player states for each player for each player. The system may further be configured to: determine a present player state according to a control input made by the operator of the client terminal system; conditional upon a difference, between said present player state and the state for the same player predicted by the primary state model, being greater than a predetermined threshold: select, from the one or more further player states for said player, any player state which differs from said present player state by less than the predetermined threshold; determine the auxiliary state model that predicted the selected player state; and transmit a notification to a server, the notification being unique to and indicative of the determined auxiliary state model. From the one or more further player states, the selected player state may differ the least from said present player state . The loop may be modified to replace the primary state model with the determined auxiliary model. The client system may further be configured to, upon receiving a notification from the server, the notification relating to one of the other players in the multiplayer game and being unique to, and indicative of one of the auxiliary state models: update the game state based on a player state for said one of the other players predicted by said auxiliary state model. The or each state model may be deterministic. The or each state model may include a sub-model for each player in the multiplayer game. According to a second aspect of the invention, there is provided a server configured to update a game state in a multiplayer game, wherein said game state changes in dependence on player states of the multiplayer game, the server being configured to: perform a loop; and update the game state depending at least on an output of the loop, wherein, the loop comprises: predicting, using a primary state model, player states according to respective control inputs predicted to be made by operators of client terminal systems participating in the multiplayer game, wherein the player states includes a first player state for a first player and a second player state for a second player state and the client terminal systems include a corresponding first client terminal system and second client terminal system; and outputting the predicted player states. The server may further be configured to, responsive to receiving, from the first client terminal system, a present player state for the first player: transmit said present player state to at least the second client terminal system. The loop may further comprise: predicting one or more further player states for each player in the multiplayer game according to control inputs respectively predicted to be made by one or more auxiliary state models; and outputting the one or more further player states for each player. The server may further be configured to, upon receiving a notification, from the first client terminal system, the notification being unique to and indicative of one of the auxiliary state models: update the game state based on a player state for the first player predicted by said auxiliary state model. The server may further be configured to: modify the loop to replace the primary state model with the auxiliary model to which the notification relates. The or each state model may be deterministic. The or each state model may include a sub-model for each player in the multiplayer game. According to a third aspect, there is provided a gaming system comprising a plurality of client terminal systems according to the first aspect and a server according to the second aspect. According to a fourth aspect, there is provided a method of updating a game state in a multiplayer game, wherein said game state changes in dependence on player states of the multiplayer game, the method being performed by a gaming system comprising a plurality of client terminal systems and a server to which the client terminal systems are operatively connected, wherein the method comprises: respectively predicting, using one or more state models at each of the client terminal systems, one or more player states for each player in the multiplayer game according to control inputs predicted to be made by operators of those players, wherein the player states includes a first player state for a first player and a second player state for a second player state and the client terminal systems include a corresponding first client terminal system and second client terminal system; and updating the game state based on the predicted player states. The method may further comprise: forwarding or receiving a present player state for the first player, wherein a difference between said present player state and the predicted player state is greater than a predetermined threshold; and updating the game state based on said present player state. The method may further comprise forwarding or receiving a notification, the notification relating to a player in the multiplayer game and being unique to and indicative of one of the one or more state models; and updating the game state based on a player state predicted by said state model for said player. The method may further comprise, at each client terminal system: rendering, and optionally displaying, video content according to the updated game state. According to a fifth aspect, there is provided a computer program product comprising instructions which, when the program is executed by a client terminal system, cause the client terminal system to perform the method according to the fourth aspect. Brief Description of the Invention Some embodiments of the invention will now be described by way of example only and with reference to the accompany drawings, in which: Figure 1 is a schematic illustration of a computer system; Figure 2 is a signal diagram; Figure 3 is a signal diagram; Figure 4 is a method flow diagram; Figure 5 is a method flow diagram; and Figure 6 is a method flow diagram. Detailed Description of the Invention Proposed herein is a method and system for updating a game state in a multiplayer game. The gaming system comprises a plurality of client terminal systems and a server to which the client terminal systems are operatively connected. At least one player is associated with each client terminal system. For illustrative purposes, specific examples described herein refer to two players being in the multiplayer game - player A and player B. It will, however, be understood that the multiplayer game can include any number of players (i.e., greater than two players) and there may, in fact, be more than one player associated with each client terminal system. In the proposed approach, the client terminal systems for player A and player B each run the same state model for predicting the player states for player A and B. Unlike existing approaches, where each client terminal system transmits state updates to the server on a periodic basis, the proposed approach transmits updates to the server only if its predictions require correction. While the client terminal system for player A can directly determine the actual or present player state for player A, it cannot directly determine the actual player state for other players (e.g., player B). If any given client terminal system determines that its prediction needs correction, it sends an update to the server for distributing in the gaming network. The use of such an update means that client terminal systems can indirectly determine that their predictions are correct by way of determining that they do not receive an update to the contrary. The game state, which changes in dependence on the player states, can be determined according to these predicted player states made by the state model and any received updates from the server. Advantageously, bandwidth consumption is considerably reduced compared to existing methods, especially if the state model is able to accurately predict player states. Digital content, such as a video, can then be rendered and output at each client terminal system according to the updated game state. There are two variants in the proposed approach. In a first variant, a single state model is run at each of the client terminal systems and incorrectly predicted player states are corrected for by distributing their corresponding present player states in the gaming system. Client terminal systems can then update the game state according to these present player states (as opposed to the incorrectly predicted ones). In the second variant, a plurality of state models is run at each of the client terminal systems: one for updating the game state by default (denoted a primary state model) and the others serving as a backup in the event that the prediction made by the primary state model requires correction (denoted auxiliary state models). The use of more than one state model increases the chance that one of the models will accurately predict the player state for any given player. The sent update can then be an indication of an auxiliary model which does output an accurate prediction, or the most accurate prediction, for example by indicating an index of one of the models. This saves bandwidth even further because an indication of a state model requires much less data than a present player state itself. As each client terminal system runs the same set of state models, the gaming state at each client terminal system can be updated according to the prediction of the (more accurate) auxiliary state model. Figure 1 is a schematic illustration of a computer system 100, also referred to herein as a gaming system 100. The computer system comprises a plurality of client terminal systems 104 and a server 102. The client terminal system 104 includes a client terminal device 106 operatively connected to server 102 over a suitable network or combination of networks. Example networks include Wi-Fi, broadband fibre, the Internet etc. Each client terminal device 106 in Figure 1 is configured to run a multiplayer game. In an example, the client terminal devices 106 are game consoles onto which the multiplayer game is installed and can be run. Example game consoles include: an Xbox®, a PlayStation® or a desktop computer. The server 102 hosts and mediates the multiplayer game. A game, in the context of this disclosure, is a structured form of play. Games include video games as well as virtual gatherings, virtual meet-ups and other forms of virtual interaction amongst multiple players. It will be understood that, although Figure 1 shows three client terminal systems 104, there may be any number of such systems. In a specific example, the number of client terminal devices and systems corresponds to the number of players participating in the multiplayer game. The client terminal system 104 includes a client terminal device and optionally a controller 108 for each client terminal device 106. In some examples, each client terminal device is associated with a plurality of controllers (not shown). An operator (e.g., a human) is able to control the player of the game through the controller. Controllers are known to the skilled reader, as such. Alternatively or additionally, the client terminal system 104 comprises sensory equipment, also denoted as 108, for measuring physical actions performed by the operator(s). For example, the game may include a human avatar which emulates the movements and actions carried out by the operator. The human player is then able to play the game according to these sensed actions. Sensory equipment for this purpose is known to the skilled reader, as such. Referring now to Figure 2, a signal diagram, showing the interaction between two client terminal systems 104a, 104b and a server 102 during a method of updating a game state for a multiplayer game, is shown. The operator of client terminal system 104a controls player A, whereas the operator of client terminal system 104b controls player B. The computer system 100 of Figure 1 is configured to perform the method set out in Figure 2. In step 202, a first client terminal system 104a predicts a player state for player A, which is the player of the first client terminal system. The player state is predicted using a state model and according to a control input predicted to be made by the operator for player A. It is noted that more than one operator may use the same client terminal system for playing the multiplayer game. Optionally, the details of the operators such as account username can be used to ensure accurate prediction in step 206. In step 204, a player state for player B, which is the player corresponding to the second client terminal system 104b, is predicted according to control inputs predicted to be made by the operator of the second client terminal system 104b. Steps 202 to 204 are repeated periodically and the predicted player states for player A and B are output in step 206. Steps 202 to 206 therefore constitute a loop, because the player state for player B is determined depending on the player state of player A, and subsequently a new player state of player A is determined depending on the new player state for player B. The loop may be running at a frequency of 10 to 60Hz, more preferably 15 to 30Hz. In step 208, the game state is updated based on the player state(s) output in step 206. In step 210, the first client terminal system determines a present player state for player A according to control inputs made by the operator of the first client terminal system. The first client terminal system then determines if the difference between the present player state for player A and the predicted player state for player A is greater than a predetermined threshold. If so, the first client terminal system may proceed to send the present player state to the server. The server can then forward the present player state for player A to the client terminal system 104b such that it can update its game state based on the present player state for player B. Steps 202 to 210 are also performed at client terminal system 104b, although all these steps are not shown for clarity. In step 212, the second client terminal system 104b transmits the present player state for player B to the server 102. Step 212 is performed because the difference between the present player state for player B and the predicted player state for player B is greater than the predetermined threshold. It will be understood that Figure 2 represents a specific example where the difference between present and predicted player states for player A is below the predetermined threshold, whereas the difference for player B is above it. Upon receiving the present player state for player B, the server 102 transmits the present player state for player B to the first client terminal system 104a in step 214. In step 216, the first client terminal system 104a updates its game state based on the present player state for player B received from the server 102. Any inaccuracies caused by updating the game state in step 208 or 210, which made use of the predicted player state for player B can therefore be corrected. Similarly, step 216 may also be performed by the server 102 in step 216c. Inaccuracies in the game state update in step 404 in Figure 4 can, therefore, also be corrected. Figure 3 shows a signal diagram showing the interaction between two client terminal systems 104a, 104b and a server 102 during another method of updating a game state for a multiplayer game is shown. The operator of client terminal system 104a controls player A, whereas the operator of client terminal system 104b controls player B. The computer gaming system 100 of Figure 1 is configured to perform the method set out in Figure 3. In step 302, a first client terminal system 104a predicts a plurality of player states for player A, which is the player of the first client terminal system. The player states are respectively predicted using a plurality of state models, according to a control input predicted by each state model to be made by the operator for player A. The plurality of state models includes a primary state model and one or more auxiliary state models. In step 304, player states for player B, which is the player corresponding to the second client terminal system 104b are predicted. The player states are also respectively predicted using the plurality of state models and according to control inputs predicted to be made by the operator for player B. Steps 302 to 304 are repeated and the predicted player states for each player are output in step 306. Steps 302 to 306 therefore constitute a loop, in the same way as steps 202 to 206. The loop may be run at a frequency of 10 to 60Hz, more preferably 15 to 30Hz. In step 308, the game state is updated based on the player states predicted by the primary state model and which were output in step 306. In step 310, the first client terminal system determines a present player state for player A according to control inputs made by the operator of the first client terminal system 104a. Next, the first client terminal system determines if the difference between the present player state for player A and the predicted player state for player A made by the primary state model is greater than the predetermined threshold. The predetermined threshold may be the same threshold as referred to in Figure 2. If the difference is greater than the threshold, the first client terminal system proceeds to select, from the predicted player states for player A made by the auxiliary state models, a predicted player state which differs from the present player state for player A by less than the predetermined threshold. In some examples, the predicted player state selected is the one having the smallest difference with the present player, although this is not essential. The first client terminal system then determines which auxiliary state model made the selected prediction and proceeds to transmit a notification to the server, which is unique to and indicative of that auxiliary state model. In a specific example, the notification includes a unique identifier of the auxiliary state model. Optionally, the first client terminal system modifies the loop (steps 302 to 306) to replace the primary state model with the determined auxiliary state model (making the previous primary state model an auxiliary one). This is expected to make future iterations more accurate. The skilled reader will understand that, while each client terminal system runs the same, plurality of state models (e.g., state models 1 to 5), each can take any one of these state models as the primary state model for their game state predictions. Steps 302 to 310 are also performed at client terminal system 104b, although all these steps are not shown for clarity. In step 312, the second client terminal system 104b selects an auxiliary state model from the plurality of state models, whose prediction for player state B differs from the present player state for player B by less than the predetermined threshold. In some examples, all the state model predictions for player B may differ from the present player state B determined in step 310b. In that case, the method proceeds to step 212 in Figure 2. In step 314, the second client terminal system 104b transmits a notification to the server 102, which is unique to and indicative of the auxiliary state model selected in step 312. The notification may include a unique identifier for the auxiliary state model. Upon receiving the notification, the server 102 transmits the notification to the first client terminal system 104a in step 316. In step 318, the first client terminal system 104a updates its game state based on the predicted player state for player B made by the auxiliary model corresponding to the notification, as already determined in step 304. It will be appreciated that Figure 3 illustrates an example where the present player state for player A is correctly predicted by the primary state model, whereas the present player state for player B is not. This can be seen by the fact that the first client terminal system 104a does not transmit a notification to the server, whereas the second client terminal system 104b does. A combination of the embodiments illustrated in Figures 2 and 3 may also be used. The method of Figure 3 is followed, but if at some point none of the state models correctly predicts the player state and the predetermined threshold is not met, then an update is made by distributing the present player state. After the present player state has been distributed, as illustrated in Fig. 2, the model returns to the Fig. 3 method of selecting state models. It will be appreciated that the multiplayer game will, in general, involve more than two players. That is, further client terminal systems, in addition to the first and second client terminal systems 104a, 104b, will interact with one another, in an analogous way to that shown in Figures 2 and 3. More specifically, a plurality of client terminal systems will transmit their present player states and / or notifications to the server and the server will, in turn, transmit a plurality of present player states and notifications to the other client terminal systems, but excluding those which transmitted the notification / present player state in the first instance. The game state will be updated according to the plurality of predicted player states and / or received present player states and notifications. The ordering of the steps presented in Figure 2 and 3 is not intended to limit the order in which those steps are performed. Any working order is possible. It will further be understood by the skilled reader that Figure 2 and 3 illustrate specific cases where the player state for player A evolves as expected, whereas the player states for player B does not. In some examples, the player states for player A and / or B may be predicted correctly for each iteration of the loop. In those cases, steps 212 to 216 or 314 to 318 will not take place, thereby reducing bandwidth consumption. It is also emphasised that steps 202 to 208 and 302 to 308 represent a single iteration of a loop for updating the game state. In practice, the game state is updated several times a second, e.g., at a frequency of 15 to 30Hz. Over the course of many iterations, the behaviour of the players will be correctly predicted and hence bandwidth consumption will be reduced. The state models described in Figure 2 and 3 may be generated using a machine learning algorithm. The state models are preferably deterministic, although this is not essential. Previous control inputs made by the operators for the players in the multiplayer game can be used as training / test data for the state model(s). Each state model takes as an input a set of input parameters and outputs a player state, according to the model parameters of the state model. The training and testing of machine learning models is known to the skilled reader, as such. Example machine learning algorithms include reinforcement-based learning approaches, such as neural networks. In some examples, each of the state model includes a sub-model for predicting the control inputs made by each player operator in the multiplayer game. Each sub-model may be generated using the machine learning algorithm referred to above and trained on previous control inputs made by that corresponding player operator. The control input in steps 210 and 310 may be the selection of a button, a combination of buttons or sequence of buttons made to controller 108. The control inputs cause a change in the player’s state. Alternatively, the control input predicted to be made may be the absence of an input. In that case, the prediction is for the player’s state to remain unchanged. The control input may also be a particular sensed action made by that operator, such as by eye, head and / or body movement. Similarly, the control input predicted to be made may be the absence of any sensed action, if the operator remains stationary. In the context of this disclosure, the difference between a present and predicted player state is the magnitude of the residual between them. In a specific example, the magnitude of the residual is calculated as an L2-norm. The player state may be composed of a plurality of different parameters, each defining an aspect of the player’s state. These parameters are also referred to herein as “input parameters” because they are inputs for the state model. In general, these parameters can be delimited into two sets: binary and non-binary. Example binary parameters include configurational states of the player, for example whether they are crouching, standing or prone. In those cases, the player is either crouching or not crouching, standing or not standing, prone or not prone. These configurational states may correspond to particular control inputs, combination of inputs, or sequences of control inputs made by the operators of the players. Example non-binary parameters include the position of the player, the speed of travel of the player, the orientation of the player and the like. In some examples, the predetermined threshold is a maximum number of binary parameters that the model is allowed to predict incorrectly. That is, a predetermined threshold equal to “1” is met if the model incorrectly predicts the player is in the binary state “prone”, they are, in fact, “not prone”. The value for the predetermined threshold can be set according to the operational requirements of the multiplayer game. Figure 4 shows a method diagram, showing how the server 102 updates the game state in a multiplayer game, comprising players A and player B. The steps of Figure 4 are performed by the server 102 in the signal diagram shown in Figure 2 and Figure 3. They were not shown in those Figures for clarity purposes. In step 402, the server 102 predicts one or more player states for player A and one or more player states for player B. As above, the player states for player A and B may be predicted using one or more state models according to control inputs predicted to be made by the operator for player A and player B, respectively. In general, the server 102 predicts the player states for all players participating in the multiplayer game. In step 404, the server 102 updates the game state according to the predicted player states from step 302. If a plurality of state models is run at the server, the game state is updated according to the predictions made by the primary state model. The loops executed at the client terminal systems and server may be synchronized within a maximum acceptable time delay. The maximum time delay depends on the operational requirements of the multiplayer game and system. Generally speaking, the maximum time delay can range from 10ms to 500ms. In some examples, the server 102 may receive a present player state for a player in the multiplayer game in step 212 or a notification in step 314, before step 404 is performed. For example, the server may receive the present player state for player B, as shown in Figure 2, before step 404 is carried out. In such cases, the server 102 proceeds to update the game state analogously described in relation to steps 216 and 318. The same applies vis-a-vis each of the client terminal systems 104a, 104b. Referring now to Figure 5, a method of updating a state model is shown. The model can be updated periodically. For example, the model can be updated immediately after the multiplayer game ends or after it is determined that the model has made a predefined number of incorrect predictions. The model can be updated for all players or for a subset of those players. Changes in player behaviours can, therefore, be accounted for. The method of Figure 5 can be performed by any of the client terminal systems 104 and the server 102. Preferably, this is carried out on all client terminal systems 104 as well as the server 102 to ensure the outputs of the state models remain the same, across the computer network. In step 502, model parameters of the model are adjusted according to those player states, which have been found to differ from their predicted player states. In particular, that differ by an unacceptable level, such as by an amount greater than a predetermined threshold. Figure 6 is a method flow diagram, showing how digital content is presented to the operator of a client terminal system based on the updated game state. The method of Figure 6 is generally carried out at each client terminal system, unless locally hosted. In step 602, digital content is rendered according to the latest game state. The latest game state may either be that determined in step 208, 216 or in step 308, 318. In some examples, the latest game state is the same as the previous game state. In such cases, the method of Figure 6 is not performed and the digital content previously presented to the operator remains unchanged. In step 604, digital content is presented at the client terminal system. In a specific example, the digital content comprises video content, which is displayed on a display screen of the client terminal system. In some examples, the digital content further comprises audio content, which is output from the client terminal system, such as speakers or a headphone jack. During a game, steps 602 and 604 are performed repeatedly in a loop, such that up-to-date digital content for the game is presented to the operator of the client terminal system. The frequency of this loop is equal to or higher than the frequency of the loop from Figure 2, but is may also be lower. Although the invention has been described in terms of preferred embodiments, as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Various modifications are possible within the scope of the invention, as will be clear to the skilled reader. For example, features from different examples may be combined as appropriate to form other working examples. It is envisaged that the method could have broader application in other technical fields, such as video conferencing. In particular, the same inventive concept could be used to reduce bandwidth traffic in video conferencing by, instead of continuously streaming 5 video data from each participant in the conference, only sending encoded video data conditional upon the image data captured at each client device being different to that expected by the state model.

Claims

1. A client terminal system configured to update a game state in a multiplayer game, wherein said game state changes in dependence on player states of the multiplayer 5 game, the client terminal system being configured to:perform a loop; andupdate the game state based at least on an output of the loop, wherein, the loop comprises:predicting, using a primary state model, a player state according10                   to a control input predicted to be made by an operator of the clientterminal system and a player state for each of one or more other players in the multiplayer game according to their respective predicted control inputs;predicting, for each player in the multiplayer game, one or more15                    further player states according to control inputs respectively predicted tobe made by one or more auxiliary state models; andoutputting the predicted player states and the one or more further player states for each player, wherein the client terminal system is further configured to:20            determine a present player state according to a control input made by theoperator of the client terminal system;conditional upon a difference, between said present player state and the state for the same player predicted by the primary state model, being greater than a predetermined threshold:25                    select, from the one or more further player states for said player, anyplayer state which differs from said present player state by less than the predetermined threshold;determine the auxiliary state model that predicted the selected player state; and30                    transmit a notification to a server, the notification being unique to andindicative of the determined auxiliary state model.

2. The client terminal system according to claim 1, further configured to render, and optionally display, video content according to the updated game state.

3. The client terminal system according to claims 1 or 2, further configured to: determine a present player state according to a control input made by the operator of the client terminal system; and conditional upon a difference between said present player state and the5            predicted player state for the same player being greater than a predeterminedthreshold:update the game state according to the predicted player states for each of the other players and said present player state.10     4. The client terminal system according to claim 3, further configured to:transmit the present player state to a server.20255. The client terminal system according to claim 1, wherein, from the one or more further player states, the selected player state differs the least from said present player state.

6. The client terminal system according to claim 5, further configured to:modify the loop to replace the primary state model with the determined auxiliary model.

7. The client terminal system according to any one of claims 5 to 6, wherein the client system is further configured to, upon receiving a notification from the server, the notification relating to one of the other players in the multiplayer game and being unique to, and indicative of one of the auxiliary state models:update the game state based on a player state for said one of the other players predicted by said auxiliary state model.

8. The client terminal system according to any one of the preceding claims, wherein the or each state model is deterministic.

309. The client terminal system according to claim 8, wherein the or each state model includes a sub-model for each player in the multiplayer game.

10. A server configured to update a game state in a multiplayer game, wherein said game state changes in dependence on player states of the multiplayer game, the server being configured to:perform a loop; and5                    update the game state depending at least on an output of the loop,wherein, the loop comprises:predicting, using a primary state model, player states according to respective control inputs predicted to be made by operators of client terminal systems participating in the multiplayer game, wherein the10                     player states includes a first player state for a first player and a secondplayer state for a second player state and the client terminal systems include a corresponding first client terminal system and second client terminal system;predicting one or more further player states for each player in the15                    multiplayer game according to control inputs respectively predicted to bemade by one or more auxiliary state models; andoutputting the predicted player states and the one or more further player states for each player, wherein the server is further configured to:20             upon receiving a notification, from the first client terminal system, thenotification being unique to and indicative of one of the auxiliary state models: andupdate the game state further based on a player state for the first player predicted by said auxiliary state model.25      11. The server according to claim 10, further configured to, responsive to receiving,from the first client terminal system, a present player state for the first player:transmit said present player state to at least the second client terminal system.

12. The server according to claim 10, further configured to:30            modify the loop to replace the primary state model with the auxiliary model towhich the notification relates.

13. The server according to any one of claims 10 to 12, wherein the or each state model is deterministic.

14. The server according to claim 13, wherein the or each state model includes a submodel for each player in the multiplayer game.

15. A gaming system comprising a plurality of client terminal systems according to any 5 one of claims 1 to 9 and a server of any one of claims 10 to 14.102016. A method of updating a game state in a multiplayer game, wherein said game state changes in dependence on player states of the multiplayer game, the method being performed by a gaming system comprising a plurality of client terminal systems and a server to which the client terminal systems are operatively connected, wherein the method comprises:respectively predicting, using one or more state models at each of the client terminal systems, one or more player states for each player in the multiplayer game according to control inputs predicted to be made by operators of those players, wherein the player states includes a first player state for a first player and a second player state for a second player state and the client terminal systems include a corresponding first client terminal system and second client terminal system;forwarding or receiving a notification, the notification relating to a player in the multiplayer game and being unique to and indicative of one of the one or more state models;andupdating the game state based on the predicted player states and based on a player state predicted by said state model for said player corresponding to the notification.2517. The method according to claim 16, further comprising:forwarding or receiving a present player state for the first player, wherein a difference between said present player state and the predicted player state is greater than a predetermined threshold; and30            updating the game state based on said present player state.

18. The method according to any one of claims 16 to 17, further comprising, at each client terminal system:rendering, and optionally displaying, video content according to the updated game state.

519. A computer program product comprising instructions which, when the program is executed by a client terminal system, cause the client terminal system to perform the method steps of any one of claims 16 to 18.10

Images