System and method for dynamic gameplay interaction using recorded state data

Abstract

To provide a multiplayer game system which enables each client to simulate the aspect of a multiplayer game.SOLUTION: To communicate an update between a client and a server. The previously recorded state data is used to control one or more event objects in the multiplayer game. In some examples, a dynamic action may be triggered for an event object when a triggering condition is satisfied.SELECTED DRAWING: Figure 8

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 63 / 667,072, filed July 2, 2024, the entire contents of which are incorporated herein by reference. The contents of U.S. Application No. 18 / 461,092, filed September 5, 2023, and U.S. Application No. 18 / 461,061, filed September 5, 2023, are each incorporated by reference in their entirety.

[0002] Technical overview The technology described herein relates to multiplayer video game systems, and more particularly to multiplayer video game systems that also include computer-controlled objects that are based on previously recorded state data.

[0003] Introduction Massively multiplayer video games that support online multiplayer can be technically difficult to implement. Issues such as network latency, packet loss, and other considerations can result in a different experience for each player participating in the game. In some instances, it can be beneficial for such online multiplayer games to include objects controlled by a computer (e.g., rather than a player participating in the current game). However, implementing such computer-controlled objects within a multiplayer video game can be challenging, especially if it is desired that such computer-controlled objects behave in a manner similar to other player-controlled objects.

[0004] It is therefore recognized that there is a continuing need for new and improved techniques, systems, and processes in these and other technical fields. Summary of the Invention

[0005] overview In one exemplary embodiment, a multiplayer game system is provided that allows each client to simulate aspects of a multiplayer game. Updates are communicated between the clients and a server. In some cases, previously recorded state data may be used to control one or more objects in the multiplayer game. In some examples, dynamic aspects may be added to objects controlled using previously recorded state data.

[0006] This Summary is provided to introduce various concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Rather, this Summary is intended to provide an overview of the subject matter described in this document. Accordingly, it will be appreciated that the features described above are merely examples, and that other features, aspects, and advantages of the subject matter described herein will become apparent from the following Detailed Description, Figures, and Claims.

[0007] BRIEF DESCRIPTION OF THE DRAWINGS These and other features and advantages will be more fully and completely understood by reference to the following detailed description of exemplary, non-limiting illustrative embodiments taken in conjunction with the drawings. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a wireframe diagram of a multiplayer video game according to an example embodiment. [Figure 2] 2 is a sequential wireframe diagram of the multiplayer video game shown in FIG. 1 showing a non-player car dynamically interacting with another car, according to an exemplary embodiment. [Figure 3] 2 is a sequential wireframe diagram of the multiplayer video game shown in FIG. 1 showing a non-player car dynamically interacting with another car, according to an exemplary embodiment. [Figure 4]2 is a sequential wireframe diagram of the multiplayer video game shown in FIG. 1 showing a non-player car dynamically interacting with another car, according to an exemplary embodiment. [Figure 5] 2 is a system diagram illustrating how the multiplayer video game shown in FIG. 1 may be implemented using a client-server architecture, according to an example embodiment. [Figure 6] 1 illustrates an example of data that may be recorded, stored, and subsequently used in a subsequent multiplayer video game, according to an example embodiment. [Figure 7] 2 is a signal diagram illustrating communications between a client and a server during execution of an instance of the multiplayer video game shown in FIG. 1 according to an example embodiment. [Figure 8] 2 is a flowchart of a process that may be executed on a server computer system for the massively multiplayer video game shown in FIG. 1 according to an example embodiment. [Figure 9] 2 is a flowchart of a process that may be executed on a client computer system for the multiplayer video game shown in FIG. 1 according to an example embodiment. [Figure 10] 1 illustrates an exemplary computing device that may be used in some embodiments to implement features described herein. DETAILED DESCRIPTION OF THE INVENTION

[0009] Detailed Description In the following description, for purposes of explanation and not limitation, specific details are set forth, such as of particular nodes, functional elements, techniques, protocols, etc., to provide an understanding of the described technology. It will be apparent to those skilled in the art that other embodiments may be practiced apart from the specific details described below. In other instances, detailed descriptions of well-known methods, devices, techniques, etc. are omitted so as not to obscure the description with unnecessary detail.

[0010] This detailed description uses sections only to orient the reader as to the general subject matter of each section. As will be seen below, the description of many features spans multiple sections, and headings should not be construed as affecting the meaning of the descriptions contained in any section.

[0011] In many places in this document, including but not limited to the description of Figure 5, we describe software modules, software components, software engines, and / or actions performed by such elements. This is done for ease of description, and whenever this document describes a software module or the like as performing an action, it should be understood that the action is actually performed by underlying hardware elements (such as a processor, hardware circuitry, and / or memory devices) pursuant to instructions comprising the software module or the like. Further details in this regard are provided below, particularly in the description of Figure 10.

[0012] Some reference numbers are reused across the figures to refer to the same elements, for example, server system 502 first shown in Figure 5 is also referenced and described in connection with Figure 7.

[0013] Overview In one exemplary embodiment, an online multiplayer racing game is provided. In some examples, dozens or even hundreds of different users may participate in a race. The users compete in a virtual space (e.g., a virtual game space) by controlling their respective player-controlled objects (e.g., which may be referred to elsewhere herein as "vehicles") around a track located within the virtual space. Each user operates their computing device as a client that communicates (e.g., over the Internet or other electronic data network) with a server or other host computer system that provides communication updates to clients participating in the multiplayer game.

[0014] In some exemplary embodiments, event objects (e.g., event vehicles) may be added to a race. The event objects may be based on a set of previously recorded state data (e.g., recordings from a previous instance of the game). The previously recorded state data is used to control the state of the event objects during the multiplayer game. The event objects may be designed so that players can compete against them (e.g., to see if they can get a better race time). While the previously recorded state data is used to control a significant portion of the event objects' behavior during the game, additional dynamic actions may be triggered for the event objects.

[0015] In some cases, the state of an event object may differ between the local simulation running on the client system and the simulation running on the server. In such cases, the client system may use interpolation to derive the current state of the event object on the client to the state of the event object communicated from the server. This also allows the event object to be more dynamic than strictly adhering to previously recorded state data, because the event object may also interact with other objects (e.g., players) participating in the multiplayer game.

[0016] Description of Figure 1: Example Gameplay FIG. 1 is a wireframe diagram 100 illustrating different aspects of an exemplary multiplayer video game. As shown in FIG. 1, a racing game is used as an example of a multiplayer video game that may be implemented in an exemplary embodiment. While the techniques herein are discussed with reference to an exemplary racing game, they may also be applied to other types of games involving multiple players. In some examples, the techniques may also be applied to single-player games (e.g., with one or more computer-controlled opponents).

[0017] In an exemplary embodiment, the exemplary racing game discussed herein allows dozens or even a hundred or more users to participate in and compete within the same virtual space. Figure 1 is a wireframe diagram 100 based on images generated as part of an online multiplayer racing game in which users race each other around a track 104 within a virtual game space. The images (image 100 in Figure 4, image 200 in Figure 2, image 300 in Figure 3, and image 400 in Figure 4) may be generated by a computing device 1000 used by a user to participate in the multiplayer video game. The generated images may be displayed on a display device 1012 coupled to the computing device 1000.

[0018] The multiplayer racing games shown and discussed herein are implemented using a three-dimensional virtual space. However, while certain examples herein are discussed in the context of a three-dimensional virtual space, it is recognized that the techniques may be applied to games outside of a virtual three-dimensional space. In an exemplary embodiment, for example, a two-dimensional (e.g., a side-scroller with little or no z-axis, etc.) multiplayer video game may be implemented.

[0019] Image 100 includes a heads-up display element that is part of or overlaid on a rendered view of a virtual game space, including a track 104, player-controlled virtual objects 102 controlled by players (and users providing input thereto) playing a multiplayer video game on a computing device 1000 on which a local simulation is running, and additional virtual objects.

[0020] The track 104 within the virtual game space may include various obstacles, jump pads, speed-up areas, etc. Generally, a multiplayer game may be played by having players race around a given track multiple times (e.g., as shown in FIG. 1 with "Lap 1 / 4").

[0021] The additional virtual objects may include virtual objects 106 and 108 that may be controlled by other players (as described elsewhere herein), or may be non-player-controlled objects (also referred to herein as non-player characters or "NPCs"). The additional virtual objects may also include event non-player-controlled objects 140 (sometimes referred to herein as "event objects"). Event objects may also be certain NPC objects (e.g., that are not directly controlled by other users).

[0022] In the example shown in FIG. 1 , the vehicles shown in the race may be controlled by other users using their computing devices 1000. Player-controlled objects may be differentiated from NPC objects in that they respond to input from corresponding players. In contrast, the movement, actions, etc. of NPC objects may be controlled using computer programs, scripts, or other data (e.g., programmatic control) without relying on input from users. In some examples, control of such NPC objects may be handled by respective clients and / or via processes running on a server system, which then communicates to respective clients how the NPCs should be controlled.

[0023] In some examples, the vehicles participating in a race may be NPC vehicles. For example, if there are 50 vehicles in a race, 10 may be NPC vehicles. NPC vehicles are sometimes referred to herein as AI players. Indeed, in instances where another player is described in the game, that other player may be an AI player or may be a player controlled by a user of another computing device. From the perspective of each user controlling their respective vehicle 102, it may be indistinguishable whether the other vehicle is ultimately controlled by another user or an AI player. In some examples, NPC vehicles / AI players may be identified as such (e.g., via the names they use or how they are identified in the game).

[0024] Note that for ease of explanation, the term “vehicle” is used interchangeably with object, player-controlled object, and other virtual objects that may be located in the virtual game space discussed in connection with the illustrative examples herein. However, it is recognized that, according to certain examples, different types of objects may be used. For example, a player-controlled object may be a player character or a non-vehicle object (e.g., a horse, a dinosaur, or other type of animal). Generally, a player-controlled object is an object to which a user provides input (e.g., via input device 1014 of FIG. 10 ) to control one or more attributes (e.g., direction, speed, abilities such as special powers, etc.) of the corresponding player-controlled object.

[0025] In one exemplary embodiment, player-controlled objects may include objects that are computer-controlled (eg, by a server), and these players may be referred to as AI players.

[0026] As discussed in more detail herein, another type of object participating in a multiplayer game may be an event object 140. These may be controlled based on a combination of previously recorded state data (e.g., stored in the recorded DB 509) and a dynamic event module 507 that is used to dynamically trigger the event object 140 to take one or more types of actions based on the current state of the race, the virtual space, or other data. Illustrative examples of actions that may be triggered for an event object 140 may be causing the event object to perform a spin move, jump, move laterally (e.g., sidestep), activate a special ability, activate a speed increase, etc. Any or all of these actions may be dynamically triggered based, for example, on the current state of the multiplayer game and / or the objects therein.

[0027] In some examples, the event object may be identified as such within the game. For example, the event object 140 may be visually distinguishable (e.g., because the vehicle is lit, contoured differently, or has a different color). Making the event object 140 visually distinguishable allows participating players (such as users controlling player objects 102) to recognize the event object within a race. This may be advantageous because users may wish to race against the event object in a multiplayer game.

[0028] In some examples, there may be multiple event objects in a race, each of which may be based on or associated with its own respective recorded state data.

[0029] 1, the image may include heads-up display elements that are presented to the user (e.g., to provide additional informational content to the user playing the video game). These heads-up display elements may include, for example, display element 116, power meter 112 (or health meter), charge meter 114 for special abilities, mini-map icon 118, check icon 120, an indicator of the speed at which the player-controlled object 102 is traveling in the race (424 km / h in the example of FIG. 1), etc.

[0030] Display element 116 is used to indicate the player-controlled object's ranking within the race. For example, in Figure 1, the player-controlled object is in 49th place out of 99 places within the race. In some examples, display element 116 may include additional information such as the current race, which of multiple different races is currently active (e.g., as part of a racing circuit competition), etc.

[0031] In some examples, the display element 116 may also include a notification (e.g., "OK") that can be used to indicate whether a player and their vehicle 102 are within a cutoff line used over a series of races (or laps). If the player is within the cutoff line, the player may be positioned to advance to the subsequent race; if the player is outside the cutoff line, the player may not advance to the next race. In some examples, cutoff lines may be used based on the laps of the race (e.g., every lap or every other lap, etc.). In such cases, a player and their vehicle may be eliminated from the race if they are not within the cutoff line. As an example, the cutoff line may be set at 70 (thus, the top 70 players advance). If a top 70 cutoff line is used, an OK notification is displayed. Otherwise, another notification may be displayed indicating that the player is below the cutoff line.

[0032] The power meter 112 shows a graphical representation of the vehicle's health attributes. This is used to give the user an indication of the vehicle's health or durability. In one example, the vehicle's health may decrease if the vehicle collides with another vehicle in a race. In some examples, the health meter may also be used to temporarily increase (e.g., turbo boost) the vehicle's top speed within a race. In some examples, the vehicle's health may gradually decrease while the boost capability is active.

[0033] A charge meter 114 is used to indicate the charge level of a special ability parameter. When the meter is fully charged, the player may activate / trigger the special ability. Further details of the special ability parameters are discussed in U.S. Application No. 18 / 461,061, the entire contents of which are incorporated herein by reference.

[0034] The mini-map 118 shows a miniature version of the track and, in some examples, may separately identify (e.g., by color, shading, icon, etc.) where the player-controlled object is in the race, where any rivals are located, which object is in the lead, where any or all of the event objects are located, where the first-place object is located, etc. Different vehicles (non-player-controlled vehicles, rivals, player-controlled vehicles, other player-controlled vehicles, etc.) may be identified differently by using different colors, shading, or other visual indicators. For example, the icon in the mini-map corresponding to vehicle 102 may be green, non-player objects may be gray, rivals may be red, other player vehicles may be blue, and event objects may be bright red. In some examples, there may be multiple mini-maps displayed (as shown in FIGS. 2-4). For example, one mini-map may be linear, while another mini-map may show a top-down view of the course (e.g., as shown in FIG. 1). In some examples, the user may be able to switch between multiple different types of mini-maps.

[0035] The check icon 120 is used to indicate to the player when other vehicles in the race are behind the vehicle 102. In some examples, the icon may blink or flash as the vehicle "closes in" to the player-controlled object 102. In some examples, different animations or colors may be used to indicate whether the vehicle behind is getting closer or further away. In some examples, the color of the check icon may correspond to (or be the same as) the color of the object as shown on the mini-map.

[0036] In some examples, the heads-up display element may include player icons 110 that identify players associated with other player vehicles in the race. In some instances, the player icons 110 may be, for example, player names associated with users controlling the corresponding vehicles. N0 Cars G0, Zoom Zoom, Fury Bauza, Scale, Dr. Crush, and World's Best are examples of icons that display usernames, player names, or character names of other players controlling vehicles in the race shown in FIG. 1. In some examples, the icons may include flags associated with locations where users are playing a multiplayer video game. In some examples, the virtual objects labeled with the icons may be non-player-controlled objects. For example, World's Best may be an event object, and the name "World's Best" may be the name of the user / account / etc. that originally generated previously recorded state data for that event object. In some examples, the event objects and their associated player icons may be identified differently from other types of icons. In some examples, each object participating in a race may be identified by a corresponding icon. As an example, each vehicle may, in some examples, have a corresponding icon that identifies the player (or type of object) associated with that vehicle. In some examples, a subset of the vehicles in the race may have correspondingly displayed player icons. For example, the object at the front of the race may be displayed with an icon, as may, for example, the five objects closest to the player-controlled object 102's position in the race. Thus, the icons may be dynamically updated as the race progresses. In some examples, the icons for one or more objects may be displayed continuously, while other objects are dynamically adjusted. For example, the World Best icon may be displayed continuously because it is an event object. In contrast, the scale and Fury Bauer icon may be adjusted as the corresponding object moves away from / closer to the player-controlled object 102.

[0037] Description of Figure 2-4: Event Object In an example embodiment, as discussed herein, a multiplayer game may include one or more event objects. When a new race (such as described in connection with U.S. Application No. 18 / 461,061) is started, a determination may be made (e.g., by system 500 and / or server 502) as to whether an event object should be included in the race. An event object may be, for example, one (or more) of 10, 20, or 99 different vehicles that may be included in the race.

[0038] Unlike player-controlled objects and / or other types of NPC objects, control of event objects is based on previously recorded state data (discussed in more detail herein). Such data may be referred to as "ghost data" in some instances. The recorded state data is based on previously recorded performance, in which various attributes (e.g., position, speed, etc.) are recorded for the object as it progresses through the game space (e.g., the race track). Examples of the types of data that may be recorded are shown in FIG. 6.

[0039] In some examples, the recording may have been generated during another instance of a race. For example, in a previous instance of a multiplayer game, player "Fury Bauza" may have competed in a race and recorded it, which is now being used to control (or guide) an event object in the current race. In some examples, such a recording may be generated independently, "offline," or in practice mode (e.g., when there are no other players or vehicles on the track). In some examples, for example, a video game developer or other "expert" may generate recorded state data, allowing a playing user to play "against" the developer's or other expert's recorded data. Once the data is recorded, it can be used in many different races, even in races running simultaneously. For example, a server system may provide different instances of the same multiplayer game to users around the world. For example, 500 different races may be running simultaneously (each race involving approximately 100 different players). Each of the 500 races may use the same event object. However, although the same event data may be used in each race, how the event object progresses through each instance may differ, for example, due to triggering dynamic actions, etc., as discussed herein.

[0040] In some examples, other users may generate recorded state data, which may, for example, allow a user to "compete" with users with whom they would not normally compete (e.g., due to time zone differences, etc.) In any event, the recorded state data may be saved during one instance of a race / game and then loaded for use in subsequent race instances of the game.

[0041] 2-4 are wireframe diagrams illustrating how an event object (eg, event object 140) may be displayed and handled in accordance with an example embodiment.

[0042] 2-4, movement and other control of the event object 140 is based on previously recorded state data. In other words, the state (e.g., placement, speed, etc.) of the event object 140 shown in FIG. 2 in the multiplayer game at time (t) (e.g., from the start of a race) may be the same as or correspond to the state of a corresponding prior object at time (t) from a prior instance of the race. This is because the server controls the event object 140 based on the recorded state data of that prior object. In contrast, the player objects 110 and 102 are controlled based on input from players participating in the race (e.g., without reference to previously recorded state data).

[0043] In some cases, dynamic control of event objects 140 during a race may be performed in combination with control based on previously recorded state data. For example, while a race is in progress, a process may determine whether a triggering condition for an event object has been met. If such a triggering condition is met, it may trigger an action that dynamically controls the event object 140 to behave differently than it did with previously recorded state data.

[0044] An illustrative example of such a triggering condition and corresponding action is shown in FIG. 3. In FIG. 3, the triggering condition is when another object is within a given distance from the event object 140. In this case, the object 110 is determined to be located in virtual space within a threshold distance from where the event object is located in virtual space. When such a determination is made, the event object is caused to perform the corresponding action for that triggering condition. As shown in FIG. 3, the event object 140 performs a spin action. Note that performing the spin action is not based on previously recorded state data. Instead, it is dynamically triggered based on the player object 110 getting too close to the event object 140.

[0045] In some examples, the spinning action may cause any nearby objects (e.g., object 110) to be pushed away from the event object, which can be used, for example, to avoid being attacked by another object (e.g., via collision) or to attack another object (e.g., to reduce the health or other attributes of the other object).

[0046] Various types of triggering conditions may be checked or otherwise monitored throughout the race. The conditions may be based on one or more attributes of the race, other objects in the race, or other aspects. For example, a triggering condition may be that the event object (or another object) has low health, that the event object (or another object) exceeds a certain speed, that the event object (or another object) is in a certain position in the race, that the event object (or another object) is on the last lap (or nth lap) of the race, that an object has entered the last lap of the race, that the race is on the first lap, that the number of objects remaining in the race is less than a threshold, etc.

[0047] As noted above, the type of action that can be triggered can be a spin attack or a spin move. Other types of actions that can be triggered according to an example embodiment can be a jump, braking, sliding, activating a special power or special move, or any other type of action or situation change that can be dynamically triggered for an event object.

[0048] An additional aspect regarding the event object 140 is that it can interact with other objects (102 / 104 / 106, etc.) participating in the race that the event object 140 is participating in. As a result, the behavior of an event object in one race may not always exactly match its behavior in the original race used to generate the state data.

[0049] As an illustrative example, a collision may occur between the event object 140 and other objects in the race. The consequences of such a collision (e.g., changes in the event object's position, speed, direction, etc.) may be handled via collision detection processing that occurs dynamically throughout the race. In such a case, the state of the event object 140 may be changed so that it no longer matches the state of the recorded state data. For example, in screen 400 of FIG. 4, the event object 140 may be further ahead in the race than the corresponding previously recorded state data (at time t). For example, the current position of the event object 140 in the race may be further ahead due to the triggered spin move shown in FIG. 3 or some other action that has occurred dynamically within the current multiplayer game.

[0050] In some examples, interpolation may be used to control the state of an object within a race. In the context of an event object, if recorded state data for the event object indicates that the current position of the event object 140 is "10" (at time t) but that the event object should be at position "9" (at time t), interpolation may be used to move the event object closer to the location indicated by the previously recorded data. For example, over the next 12 frames (or other time), the current location of the event object may be gradually moved toward the previously recorded location. This may be used instead of immediately moving the event object to "9." This approach of using interpolation allows previously recorded state data to affect how the event object performs within a given race, while also allowing for more dynamic interaction with the event object during a given race. In other words, even though the same previously recorded state data for the same event object may be used in, for example, 100 different races, each race may end slightly differently depending on the player's actions in the race and their interactions with the event object. For example, triggering an action that results in an additional move may occur in one race but not in another.

[0051] In one example embodiment, the interpolation algorithm used may be programmed to adjust the current position of the event object so that it completes the current race in the same (or approximately the same) amount of time as it took the previously recorded object to complete the race. Thus, for example, if the event object moves ahead of where the previously recorded data indicates it should be, the event object may be controlled (e.g., via interpolation) to not move any further ahead. Instead, it may be controlled to gradually match the state information in the previously recorded state data.

[0052] In an exemplary embodiment, processing for event objects may be performed differently on the server for each client participating in a given race. More specifically, processing on the server may be performed to simulate the event objects using previously recorded state data, causing the event objects to recreate the original race nearly exactly as it was played. In some examples, the event data processed by the server does not process or handle collisions or other interactions with other objects. However, collision detection processing may be performed for the event objects for each client.

[0053] The state data of the event object 140 may be communicated to all of the clients participating in the race (e.g., each controlling their own object in the race). Each of the clients may receive the event object's state data and use this information to perform a local or client-side simulation of the race. This simulation may differ from the simulation performed on the server in that collision detection processing, etc. may be performed. Such client-side processing may then change the position or other state attributes of the event object 140 from the position or state attributes on the server. In an exemplary embodiment, each of the clients may then attempt to resynchronize the state of the event object on the client with the state of the event object as provided by the server by using interpolation. This allows the "correct" state of the event object on the client to gradually match the state on the server. Additional details about how such synchronization can be handled are discussed in more detail below.

[0054] Description of Figure 5: System Turning now to the computer architecture provided to enable users to play the multiplayer video game, FIG. 5 is a system diagram illustrating how the multiplayer video game shown in FIGS. 1-4 may be implemented in a client-server architecture according to one exemplary embodiment.

[0055] The system 500 includes a server computer system 502 (also referred to herein as a server 502) in communication with a plurality of computing devices 510 (e.g., 510a-510n), each configured to run an instance of a game program 550. The game program 550 may be provided on a disk, cartridge, or downloaded to a corresponding computing device over a network (e.g., the Internet). In some examples, the game program is associated with a user's account. This account may include a player name, etc., which is then displayed within the multiplayer video game. For example, "Scale" may be the account or player name for the vehicle 108 shown in FIG. 1 .

[0056] There may be hundreds or even thousands of such computing devices 510 in communication with the server 502, and there may be, for example, one hundred such computing devices participating in the same instance of a multiplayer video game. Each computing device acts as a client communicating with the server computer system 502.

[0057] As discussed in connection with various signal diagrams herein, computing device 510 communicates with server system 502 via network 560. In some examples, network 560 may be, for example, the Internet, where communication may occur between client 510 and server system 502 using, for example, UDP / IP, to transmit state data for an ongoing game. In other examples, network 560 may be a local area network or a private network (including a virtual private network (VPN)).

[0058] Each client (e.g., Client 1, Client 2, Client 3 through Client n) communicates with server system 502 to send and receive data in connection with the multiplayer video game. The data may include data for participating in the game, state data as the game is being played (e.g., as discussed in connection with FIGS. 6 and 7), and other types of data. Other types of data that may be communicated may include voice data (e.g., VoIP), text data for in-game messaging, etc., and other data that may be used in connection with the multiplayer video game discussed herein.

[0059] In some examples, a client-server technology architecture may be used in which the server 502 is dedicated to receiving and providing updates to clients (e.g., that do not need to be relied upon to render images, etc.). Such a technology architecture may be beneficial depending on the number of clients (e.g., up to 100) that may participate in a given race. With this type of architecture, clients can send and receive data packets to the server 502 without having to communicate directly with other clients. While other types of network architectures may be used in some examples, it is recognized that other such architectures (e.g., peer-to-peer, etc.) may have drawbacks in terms of performance and / or overhead. However, in some example embodiments, such other networking architectures may be used depending on the needs of the application.

[0060] In an exemplary embodiment, updates may be provided to clients in batches. For example, each client may be assigned to one of several different groups. Updates may be provided to clients in each group on a frame-by-frame basis. For example, clients in group 1 may receive updates from server 502 every frame x (and every n frames thereafter). Clients in group 2 may receive updates from server 502 every frame x+1 (and every n frames thereafter). Clients in group 3 may receive updates from server 502 every frame x+2 (and every n frames thereafter). Thus, for example, clients in each group may receive updates every n frames. For example, if there are six groups, each client may receive an update every sixth execution frame. Thus, as an illustrative example, if the server runs a simulation at 60 frames per second, the server may send updates to each client 10 times per second.

[0061] Client 510 Each of the clients 510a-510n (generally referred to herein as clients 510) runs on or corresponds to a different computing device. Illustrative examples of computing devices on which clients may run are discussed in connection with FIG. 10. Some computing devices may be personal computers, others may be mobile devices, and others may be dedicated gaming devices. In some examples, clients may be hosted within virtual machines or virtual instances (e.g., Docker containers, etc.). In such cases, a given computing device may host multiple clients, each running separately. As shown in FIG. 5, each client 510 runs a different instance of a game program 550 on the corresponding computing device. The game program 550 (e.g., an executable file, e.g., an .exe) may be stored in a memory device 1014 (e.g., non-volatile storage) and loaded into RAM / other volatile storage for execution. The game program may be executed by one or more processors of the corresponding computing device in connection with performing the functions of the multiplayer video game described herein.

[0062] Each client 510 processes input provided by a user, for example, via an input device 1014 coupled to a corresponding computing device. In some examples, as discussed in more detail below, the input may be processed by the corresponding client, and the results of that processing (e.g., updates on how an object has been controlled or changed) may then be communicated to the server system 500. In other examples, the input (e.g., that a particular button has been pressed, the state of the button, the state of a joystick, the amount of detection from a sensor, etc.) may be communicated to the server 502, which may then take action based on the input.

[0063] In some examples, each client that is part of system 500 corresponds to a different player in a multiplayer game. However, in some examples, a given client may process input (and other aspects) for multiple players. For example, a given client may allow two users to provide input via different input devices 1014, both coupled to the same computing device, etc. Such an implementation may be similar to split-screen modes in other types of video games. The provided inputs may then be used to update the vehicles associated with those respective players (and / or communicated directly to server 502), and updates to those vehicles may then be communicated to a server system, as discussed elsewhere herein.

[0064] Typically, clients and computing devices are provided in a one-to-one correspondence such that each client is supported by a corresponding computing device. However, in some instances, multiple clients may run on the same computing device. As an illustrative example, a computer may run two instances of game program 550. For example, multiple clients may be provided via a cloud-based streaming service that processes input provided to a thin client located with a user controlling a corresponding vehicle that is being processed by such cloud-based streaming service.

[0065] Server 502 The server system 502 may be comprised of one or more of the computing devices 1000. The server system 502 may be responsible for assigning players to instances of a multiplayer video game, conducting / executing each instance, providing post-race functionality, and other aspects as needed. The server system 502 includes a lobby module 504 and a race module 506 to perform this and other functionality related to the multiplayer video game.

[0066] The lobby module 504 is responsible for handling connection requests from clients, generating lobbies (e.g., determining which clients should participate in a given instance of a race), and matching or otherwise placing clients and their players into instances of a multiplayer video game. Creating new instances of a multiplayer video game is discussed in more detail in connection with U.S. Application No. 18 / 461,061, the entire contents of which are incorporated herein by reference.

[0067] Each new instance of a race in the multiplayer video game may be handled via the race module 506. The race module 506 is responsible for running the race and handling communication with the clients 510 participating in a given race. For example, the race module 506 may be responsible for receiving vehicle position updates from each client and then, for example, determining a winner (e.g., which vehicle crosses the finish line first, etc.). In some examples, the race module 506 may include functionality for controlling NPC vehicles. In some examples, the race module 506 may perform processing including launching a new virtual container instance (e.g., a Docker container, a virtual machine, etc.) to host each running instance of the race module 506. This, for example, allows multiple different races to be run simultaneously, thus enabling thousands or more users to participate across many different races that may be running simultaneously (but separately from one another) on the server 502.

[0068] In some examples, a dynamic module 507 may be provided in connection with providing functionality associated with one or more event objects that may be present in a race. The dynamic module 507 is responsible for testing whether one or more triggering conditions for an event object are met and, if met, then inserting or otherwise communicating to the race module 506 that a corresponding action for that triggering condition can be performed on the event object. In some examples, as discussed herein, triggering an action may be dependent on the action not having a cooldown timer currently in effect. In other words, when an action is triggered via the dynamic module 507 (or others), a cooldown timer may start. While the cooldown timer is running, the race module 506 and / or the dynamic module 507 may suppress or ignore additional enablement for the action, even if the triggering condition is met. Thus, enablement of a corresponding action for an event object may require 1) the enabling of the triggering condition and 2) not having a currently running timer (or triggering condition associated with it) for the action. The cooldown timer allows control over how often an event object can perform its corresponding action.

[0069] In some examples, the cooldown timer may be a set duration (e.g., 10 seconds). In other examples, a randomization factor may be added to the cooldown timer (e.g., any time within 10 seconds + / - 2 seconds). In other examples, a timer duration value between an upper limit (e.g., 20 seconds) and a lower limit (e.g., 5 seconds) may be used for the timer duration.

[0070] In an example embodiment, actions that the server can trigger may also be actions that a user can trigger on their own player-controlled object 102. In other words, the same actions may be performed by the player-controlled object 102 and the event object. In some examples, the user's version of an action may also be associated with or controlled based on a cooldown timer. In some examples, the duration of the cooldown timer for a user may be fixed to the same duration (and the same for all users). In contrast, the duration of the cooldown timer for an event object may be affected by an additional randomization factor (e.g., duration of 30 seconds + / - 5 seconds) (as discussed herein).

[0071] The server system 502 also includes or communicates with a player database (player DB) 508. The player database 508 stores skill ratings for each player and other game outcome data for players participating in the multiplayer game. In some examples, the information in the player database 508 is used to generate rivals for a given player. The stored skill ratings may be calculated using, for example, the Elo, Glicko, or Glicko2 rating systems and may be adjusted based on the results of each race. Additional details regarding the processing performed by the server are provided in connection with FIG. 8.

[0072] Description of Figure 6: Ghost Data Server 502 also includes one or more previously recorded instances of state data that may be stored in recorded database 509. When race module 506 is running a race, state data for controlling event objects is loaded from recorded database 509 and then used to determine how the event objects should be controlled during the race.

[0073] In an exemplary embodiment, state data stored in recorded DB 509 may be generated in a manner similar to other “ghost” data. In some examples, state data may be generated via a practice mode in which a user races around a track in solo mode. When state data is being recorded, the recorded data may be recorded every frame of execution, every other frame of execution, or some other value, such as every sixth frame of execution. State data may be recorded from the start of the race until the object crosses the finish line. In some examples, each instance of state data may consist of a data structure that holds one or more attributes related to the state of the object at a given time. In some examples, state data may be stored based on either an in-game action / event occurring and / or a specific input provided by the player. For example, if an event object activates a special power, state data may be stored in response to such activation. In another example, state data may be stored when a specific button (or any button) is pressed. In some examples, such state data may be stored in addition to storing state data at predetermined intervals (e.g., every sixth frame).

[0074] 6 shows examples of different types of data that may be stored for every instance of recorded state data. Previously recorded state data 600 may include, for example, a timestamp, which may be a number of frames from the start of a race, an incremental index value, or other value.

[0075] Data 600 may include position data, such as the location of an object in the virtual game space, or other position information indicating where the object is on the track. In some examples, this may be an X,Y location. However, in other examples, this may be a single value, or may be a three-dimensional value (e.g., X, Y, Z). Another item included may be height above the plane on which the track is located. This may be used, for example, to record position data when the event object is to make a jump, etc. Data 600 may also include orientation data. This may be, for example, the angle at which the event object is facing.

[0076] Data 600 may also include any status or environmental flags for the event object. This may include health, startup status, or other types of status information. In some examples, this may include information regarding enabling special moves, etc.

[0077] Another item included in data 600 may be the occurrence of a spin attack and / or data regarding such a spin attack (e.g., duration, trigger angle, etc.). In an exemplary embodiment, data about a spin attack (or other action) may be stored as part of recorded state data 600. A spin attack may then be triggered based on that recorded data, which may be used by an event object. As discussed elsewhere herein, a spin attack may also be triggered dynamically (e.g., at 810 in FIG. 8). In an exemplary embodiment, a cooldown timer may be triggered / started when a spin attack is triggered based on previously recorded state data.

[0078] In an exemplary embodiment, if a cool-down timer is already running and previously recorded state data indicates that a spin attack should occur, that instance of the spin attack may be inhibited from occurring because the cool-down timer is still running. In an exemplary embodiment, a dynamically triggered instance of an action (e.g., a spin attack) and a previously recorded instance of that same action may share and / or trigger a cool-down timer. In an exemplary embodiment, a dynamically triggered instance of an action (e.g., a spin attack) and a previously recorded instance of that same action may each have its own cool-down timer and / or trigger its own cool-down timer. In some examples, the timer durations may be different. In some examples, the timer durations may be the same.

[0079] Data 600 may also include data representing vector information about how an object is moving within the virtual game space. This may include, for example, a movement angle. Note that this may be a movement vector and may be different from a "face" angle (which may be the orientation of the object). For example, an event object may be facing at 0 degrees but moving at an angle of 180 degrees. Another item included in data 600 may be the movement speed of the event object. Note that in some cases, recorded data 600 may include both position data and velocity data. While velocity can be calculated from a change in position, additional recording of velocity (in addition to position) according to certain example embodiments can help eliminate floating-point precision errors that may occur, for example, by calculating velocity using only position.

[0080] Another data item included in data 600 may be the status or state of one or more buttons or other switches on a controller. This may include the state of an analog stick (e.g., a joystick). In some examples, this may be the state along the X-axis of that stick, which may be used to record whether the player is moving left or right. In some examples, the state of one or more buttons on the controller may be stored, for example, whether the "A" or "L" button is currently pressed.

[0081] In some examples, other types of data may also be recorded as part of data 600. In an example embodiment, the types of data recorded may be the same and / or similar to the types of data communicated from the client to the server, which may include recording of additional actions taken by the user during gameplay, etc.

[0082] Any or all of the stored state data may then be used subsequently to determine and / or control how the event objects are simulated during subsequent races. In some examples, the server may process the data 600 (as discussed in FIG. 8) and then communicate the results of that processing to the clients. In some examples, the data communicated from the server to the clients participating in the multiplayer game may be the same. In other examples, some (or all) of the data 600 may be communicated to the clients, who may then process the data as discussed herein (as discussed in FIGS. 7 and 9).

[0083] Description of Figure 7: Game Processing FIG. 7 is a signal diagram illustrating communications between client 510 and server 502 during the execution of the multiplayer video game shown in FIG. 1, according to an example embodiment.

[0084] When the multiplayer video game is started, each client 510 runs a copy of the game program 550. The server 502 also runs its own version of the multiplayer game (which may be a different version from the game program 550 and is used to run the server-side simulation). Each running instance on the client and server is a separate simulation of the multiplayer video game. The client and server communicate data messages. Data messages are used to synchronize the state of the client with the state of the server and to indicate what actions a particular user (716) has taken for a given client for the server simulation. For example, messages are used to update each game instance regarding changes in, for example, how a vehicle is being controlled by the user or how other vehicles are controlled by other users.

[0085] As an illustrative example, a given client 510 may communicate to the server 502 information regarding the speed and position of a vehicle being controlled (via input 718) by the user (716). The server receives such messages from all clients and then communicates to each client updates regarding all of the other players (and their respective vehicles) in the game. The various clients receive those messages and then update their local client-side simulations based on the data in those messages (in addition to any input provided by the user of the computing device). However, some processing (or the results of such processing) performed on the client (or the server) may not be communicated. An example of such processing may be the results of collision detection processing performed on the client. For example, collision detection processing may be performed for a given client for its local simulation, but the results of that processing may not be communicated back to the server (or may only be communicated, in some cases). In other words, when two objects are determined to collide on the client, the client determines how those two objects should react (e.g., by moving them based on the force of the collision). However, the results of that movement may not need to be communicated to the server (e.g., if it does not involve a player-controlled object 102 for the user associated with that client). Note that due to differences in the game state in each local simulation 702 (e.g., across 50 or more clients participating in a given game), there may be differences in how collisions are indicated / determined for each respective client. For example, on a first client, a collision between Scale and Fury Bowser may be determined; however, on a second client, such a collision may not be determined at substantially the same point in the game.Alternatively, such a collision may be detected on the second client, but collision processing on the second client may result in moving / updating the scale and / or Furybrowser state data in a manner different from how the collision was handled on the first client.

[0086] Note that the same client-side collision processing / results may not occur for clients processing the event object's data. For example, on one client, an event object may collide with another object, but on a second client may not detect such a collision. Similarly, the outcome of the collision (if detected) may differ. Thus, the exact positioning of a given event object on a client may not be exactly replicated across all clients participating in the same game.

[0087] In some cases, the server may perform a different conflict resolution process or no conflict resolution process at all.

[0088] 7, the server 502 executes a multiplayer game location simulation at 700, and each client 510 also executes a local simulation of the multiplayer game at 702. This may involve each respective computing device (server and client) executing a game application that performs operations related to executing the simulation of the multiplayer video game. Further details of the processing performed in the simulation on the server are discussed in FIG. 8. Further details of the simulation performed on the client are discussed in FIG. 9.

[0089] In some examples, execution of the server process 700 is based on messages received from clients and any local processing performed on the server to control non-player objects. As noted herein, non-player objects may include those that are based on previously recorded state data (e.g., event objects) and those that are not based on such data. As discussed herein, control and processing for event objects may also be based on processing performed by the dynamic module 507. Such control may be performed as part of the server process 700 and / or as part of processing 702 performed on the local client 510.

[0090] In some examples, the execution of the local simulation 702 on each client 510 may be based on messages received from the server (704), input 718 provided by a user 716 (e.g., via one input device 1014), and any local processing performed on the server 502 to control non-player objects (NPCs) in the race.

[0091] Messages (e.g., update messages) communicated (at 704) from the server 502 to the client 510 and / or (at 706) from the client 510 to the server 502 may pertain to periodic updates (e.g., occurring once every X frames the simulation is updated or other period) and / or updates triggered by an event or other triggering action. In some examples, messages are communicated from the client to the server every frame (e.g., each frame the client sends an update). In some examples, the server communicates updates to the client less frequently, e.g., once every other frame, once every sixth frame, etc. In some examples, important event updates may be communicated from the server to the client as they are determined. An example of this may be when a vehicle activates a special ability or moves in a meaningful manner. Such updates may be sent between periodic updates communicated to / from the server.

[0092] Messages communicated between clients and servers may contain different types of data. Data communicated from clients to servers and then from servers to clients may involve any or all of the data shown in FIG. 6. In some examples, each update may include a timestamp (or other, e.g., consecutive values ​​from the start of a race). The timestamp is used to provide the client with an indication of when the data in the update should be reflected in the running local simulation. Some examples may send parameter values, movement and / or position data (e.g., of a vehicle), data regarding user-entered commands (e.g., buttons being pressed or pressed), the status of the race (e.g., player rankings within a race), and other types of data, such as significant events that have occurred. In some instances, data is sent periodically (e.g., every X number of frames, such as every other frame, every tenth frame, or every sixth frame, or at some other rate, such as every 1 ms, every 5 ms, every 10 ms, or every 30 ms). In some instances, data messages are sent on an on-demand basis. For example, when a significant event occurs for the vehicle 102 (e.g., activation of a special power, etc.), a data message regarding such trigger occurrence may be transmitted.

[0093] Returning to Figure 7, processing of each local 702 and server 700 simulation continues until the race is completed at 708. Once the race is completed, the server may update player information for each player who participated in the race. For example, a player's experience or rating may be updated based on the player's performance in the race. This updated data may be stored in the player database 608.

[0094] At 712, the results of the race are communicated to each of the clients 510. These results may then be displayed to the users on their respective computing devices at 714. The results may include the player who finished the race in first place, the user's relative positioning to the event object (e.g., whether the user-controlled object's time is faster than the event object), and / or other information.

[0095] Description of Figure 8: Server Processing Figure 8 is a flowchart of a process that may be executed on a server computer system for the multiplayer video game shown in Figure 1, according to an example embodiment. The process shown in Figure 8 may be performed as part of (or by) the process shown in Figure 7 for execution of server process 700. Once a new game instance is created and a race is started, the process shown in Figure 8 may occur. The process shown in Figure 8 may occur at a rate of 24, 30, 60 ticks per second, or other rate (e.g., the tick rate at which the server operates).

[0096] At 800, updates sent from the client 510 are processed. The updates at 800 may include periodic updates provided by the client 510, including movement information, user input device information, etc. These updates may be communicated by the client periodically to provide the server with an update on how the player-controlled object associated with that client is moving / performing within the game space.

[0097] At 804, optional NPC processing is performed by the server 502. This may include determining whether to spawn an NPC, whether the NPC should be located in a race, what actions to perform on the NPC, etc. NPC processing may also include loading or retrieving previously recorded state data from the recorded state database 509 at 802 and controlling event objects based on the retrieved data. In some examples, NPC processing 804 may include determining how one or more NPCs, etc. should move or act within the game space and then communicating such information to the client (e.g., at 814). In some examples, NPCs may also include computer-controlled or AI (artificial intelligence)-controlled objects (e.g., as opposed to human or player-controlled objects).

[0098] At 806, the simulation of the game maintained by the server computer system 502 is updated. More specifically, the server 502 maintains a game state (as do the clients) that includes position and other state information for each of the vehicles / objects in the race. The processing performed at 806 may update this game state based on data received from the clients (at 800), and updates the NPCs performed at 804.

[0099] In some examples, the processing performed by the server may differ from the processing performed by a client (or each client). In one exemplary embodiment, the difference between the processing performed for clients and the processing performed for the server in a multiplayer game may be, for example, how collisions and other dynamic behavior are handled.

[0100] In one example embodiment, how an event object reacts to a collision is handled on each individual client without communicating the results of such collisions back to the server. Furthermore, collisions may not be determined (and / or collision processing may not be performed) for event objects on the server (or may be handled differently than on the client). Instead, the server may make a determination at 808 (which may be part of the processing performed at 806) as to whether a triggering condition for a dynamic action should be enabled for the event object. Such processing does not have to be performed on the client. In other words, the determination of whether to dynamically trigger an action on the event object may be made by the server. The server may then communicate the results of such a determination, e.g., that an action should be performed on the event object, to the client for processing.

[0101] In some examples, processing at 808 may also include determining whether a cool-down timer is running. If the cool-down timer is running, then such triggering behavior is not enabled, and processing continues at 814. In other words, if the cool-down timer is running, the server-side processing may not need to calculate or determine whether a triggering behavior exists for the event object. If the cool-down timer is not currently running and the triggering condition is enabled, processing moves to 810.

[0102] In some examples, a determination to trigger an action may be made even if the cooldown timer is running. For example, if it is determined that an event object will collide with a first type of object in the game, an action may be triggered even if the cooldown timer is still running. In some examples, the first type of object may be an AI-controlled and / or NPC object (e.g., one that is not controlled based on input from a client). In some examples, the first type of object may be an object that explodes or causes damage when a vehicle collides with it. This type of object may be an NPC object that is controlled throughout the race and may, for example, act as a movement obstacle for the player. For such objects, an additional check may be added to the collision processing so that if the event object is to collide with (or come within a threshold distance of) the first type of object, an action may be triggered even if the cooldown timer is still running. Triggering an action (e.g., as discussed below) may allow the event object to reduce or avoid damage resulting from a collision with this type of object. It is recognized that other object types and / or different types of effects may be provided in the game according to an example embodiment.

[0103] Next, at 810, an action is triggered for the event object. In some examples, the triggered action may be selected based on which triggering condition is activated. In some examples, there may be only one triggering condition in the game. In such cases, there may be only one dynamic action to activate.

[0104] In an example embodiment, the triggered action may be an action that does not substantially change (or does not change) the speed and / or position of the event object within the race. However, it may affect the event object in other ways. For example, the action may cause less damage to the event object, make the event object invulnerable, or cause the event object to undergo some other change in state. An example of such an action is a spin move or spin attack, as discussed herein.

[0105] Based on the activation of the dynamic action, a cool-down timer may be started at 812. In some examples, the cool-down timer is a predetermined amount of time (or a predetermined number of execution frames). In other examples, the cool-down timer may be randomly determined, or may be randomly determined between a set minimum and a set maximum value. In either case, the cool-down timer may be started and kept running until the timer expires. In some examples, if an action is triggered but the cool-down timer is still running, the cool-down timer may be reset (or added to its remaining duration). This may occur, for example, if it is determined that the event object collides (or will collide) with a first type of object.

[0106] In some examples, the enabling of the action at 810 may then be inserted or added to processing occurring on the server-side simulation (e.g., as part of 806). The results of such processing may later be communicated to the client at 814. In other examples, triggering dynamic action may be communicated to the client at 814. For example, an event that enables triggered action for an event object may be communicated at 814 without first processing the action through the server-side simulation. Instead, the processing of the action may be communicated to each individual client and processed there.

[0107] In this way, the above techniques result in using previously recorded state data to control the event object, but also dynamically insert actions for the event object to take that are not based (e.g., solely) on the previously recorded state data. Instead, the state of the event object may be dynamically updated based on the current state of the race and / or the objects in the current race, for example, if another object in the race is within a threshold distance of the event object.

[0108] Note that while the client performs collision processing (e.g., at 912, as discussed below), the server 502 may not similarly perform such collision processing as part of the server-maintained simulation. However, in some examples, the server may perform collision processing (e.g., determine / modify position / movement data of the objects involved). In some examples, collision processing may occur if the object is not involved in an event object. Rather, the server may ignore or not process potential collisions involving event objects.

[0109] In some examples, collision processing may be performed by the server (e.g., at or in conjunction with 806) based solely on a determination of one or more conditions. An illustrative example of such a condition is when a collision is determined to reduce the health of the vehicles involved in the collision to 0. This may be communicated to the server via a significant event update. The server may then determine whether a collision will occur.

[0110] At 814, the server generates and sends to the clients any updates regarding the game state and / or the vehicles in the game. Such updates may include position, movement, and health data for each vehicle in the race. The messages communicated to the clients are then received by each client, which then incorporates them into client-side processing (e.g., as discussed in connection with FIG. 9). In some examples, the updates communicated at 814 may be sent to a subset of the clients involved in the game. For example, if there are 60 participating clients, updates may be communicated to 10 clients during each execution frame of the process shown in FIG. 8. Thus, for example, each client may receive an update once every sixth frame. In some examples, other frequent updates may occur.

[0111] In some examples, the communication of updates to clients at 1008 may be divided into different types of processes for providing updates. Some updates provided to clients may be based on the occurrence of an "event of interest," while other updates may be based on periodic updates. In some examples, only data regarding the event of interest may be communicated (e.g., simply that a particular vehicle has activated a special capability). In some examples, when an event of interest occurs that then triggers such communication (client to server or server to client), the data communicated for the periodic update may be included in such an update.

[0112] Similar to client-side processing (e.g., FIG. 9), the processing shown in FIG. 8 may occur multiple times per second. The rate at which processing occurs on server 502 may be a "tick rate," update rate, or the like. This rate may correspond to the rate at which the server updates its own internal game state for the game being played. In some examples, this tick rate is the same as or similar to the client's tick rate (e.g., 30 times per second), while in other examples the tick rate may be faster (e.g., 100 times per second), and in other examples, it may be slower (e.g., 10 times per second).

[0113] Description of Figure 9: Client Processing FIG. 9 is a flowchart of a process (such as that shown in FIG. 5) that may be executed on a computing device that is a client in the massively multiplayer video game shown in FIG. 1, according to an example embodiment.

[0114] Each client or computing device used by a user to participate in a multiplayer video may operate the process shown in Figure 9. The process shown in Figure 9 may be performed based on the execution of computer instructions that are part of a game program 650 running on the corresponding computing device. And, as discussed in more detail below, the process shown in Figure 9 can (and in some exemplary embodiments does) occur multiple times per second as data is received, processed, and then output. In some examples, the rate at which the looped process shown in Figure 9 occurs is 24, 30, or 60 times per second. In some exemplary embodiments, other rates, whether fixed or variable, may also be implemented.

[0115] Once the race has started, race processing 900 occurs. At 902, user-provided input is received and processed. This may include determining which button or other action was triggered by the user on an input device coupled to the computing device the user is using. For example, if there are five different buttons on the input device, the computing device may store the status of each of these buttons (or simply which button was pressed). As an illustrative example, each button may be represented by a state variable (e.g., the state of the corresponding input) that is used to track whether the button was pressed, how much the button was pressed, etc.

[0116] According to an exemplary embodiment, different types of input may be processed. For example, the input may be a voice command, and thus the processing at 902 may include determining which voice command was provided. In one example, historical data entered by the user is stored in a data structure or input buffer. In other examples, the provided input need not be stored past its use in the current execution frame.

[0117] One type of input that may be provided at 902 is the triggering of a special ability associated with special ability meter 114. Given the input associated with the special ability, the process may determine at 920 whether the tracked value associated with special ability meter 114 meets or exceeds a given threshold. If so, the special ability is enabled (although in some example embodiments, there may be additional conditions for activation). Additionally, details of special ability processing related to transitioning to a second track in a race are described in more detail in FIG. 11.

[0118] In an exemplary embodiment, triggering the second track at 920 may occur automatically once a special ability is met or a threshold is reached. In an exemplary embodiment, the automatic triggering of the special ability may be based on other conditions within the game. For example, if the player crashes out (e.g., health drops to zero) and the special ability meter is filled, the game may automatically trigger the special ability to warp the vehicle to the second track. In an exemplary embodiment, other types of triggering conditions (e.g., speed, location in the race, etc.) may be used to control or automatically trigger the special ability.

[0119] At 904, one or more data messages (e.g., packets) may be received from the server system 602. The data transmitted from the server system 602 may include data regarding parameters or attributes of vehicles other than those controlled by the current client user (e.g., other than the vehicle 102). Such attributes may include the health of the other vehicles (e.g., as represented via the bar 112), movement data of the other vehicles (such as their speeds as represented in km / h shown in FIG. 1), whether a collision between the vehicle 102 and another vehicle has occurred, direction data of the other vehicles, etc.

[0120] In some examples, a collision event is sent only if a collision between vehicle 102 and another vehicle would reduce the health of either vehicle (or simply the health of the current user's vehicle 102) to 0. In some examples, when one vehicle causes a collision that reduces the health of another to 0 (and removes it from the race), the health of the remaining vehicles may be increased.

[0121] At 906, data (e.g., packets) may be sent to the server 602 for processing. Data communicated from a given client to the server may be the same or similar to that received by the server 602. However, in some examples, the data communicated to the server 602 may only relate to attributes or properties of the vehicle 102. In other words, data regarding the state of other player vehicles for a given local simulation may not be sent from the client of the vehicle 102. Rather, such vehicle data may only be received from the server 602. Indeed, in some examples, messages communicated from a given client to the server may only relate to properties of that client's vehicle 102.

[0122] In some examples, state data of the input device used by the user may be sent. This state data may include the current state of the controller / user input device (e.g., which button is being pressed or used, etc.). In some examples, the data may be communicated to the server after the game state is updated frame by frame (after 910). In other words, inputs provided by the user using the user input device may be applied to update or modify any parameters of the vehicle 102 that the user is controlling, and the results of that processing may be communicated to the server 602.

[0123] In some examples, if a vehicle 102 is involved in a collision and that vehicle is the "aggressor," an aggressor priority flag may be included in the message communicated to the server, which may be used by the server 602 to resolve the collision in favor of the "aggressor."

[0124] At 908, processing may occur to control any non-player controlled objects of the video game. As an illustrative example, non-player vehicles may be present on the track and may be designed to periodically drop energy objects. Processing at 906 may control the speed, direction (or presence) of such non-player vehicles. Additionally, as discussed elsewhere herein, generation of energy objects by such non-player vehicles may also be triggered. In some examples, data received from server 602 may be used to control the non-player vehicles at 906. As one illustrative example, a non-player object used to drop an energy object may be triggered by instructions from server 602. However, the movement of that vehicle may be controlled via a local simulation (e.g., server 602 need not provide instructions regarding how to move the non-player vehicle).

[0125] In an example embodiment, the treatment of NPCs may differ among various clients participating in the same multiplayer game. As an example, the “same” NPC may exist in each locally running simulation of a multiplayer game running on each client. The presence of such an NPC in the game may be controlled, for example, based on instructions received from the server 602 to display / create the NPC. Thus, in one example, the location of an NPC may be the same across various clients. However, in other examples, the location of an NPC on each client may be treated independently. An NPC may be designed to drop energy objects onto the race track. However, the rate at which the energy objects are dropped (or how many are dropped) may vary from client to client. In an example embodiment, the distribution of energy objects from such an NPC for each client may be a function of (e.g., based on) the positioning of that client's vehicle 102 within the race. So, for example, if a player-controlled object is in first place, the rate at which that NPC drops energy objects in that client's local simulation may be one every five seconds. In contrast, the same NPC being simulated on another client of another player-controlled object at 50th place may have a drop rate of 1 energy object per second. Thus, the drop rate of energy objects by an NPC in the local simulation occurring (e.g., at 802) may be controlled based on where the corresponding player-controlled object is positioned within the race of the multiplayer game. In one example, the higher the current position of a vehicle, the lower the drop rate of that vehicle in the local simulation.

[0126] In some examples, various other types of NPC control may also be provided. For example, an NPC may be generated within each local simulation and designed to interfere with control of the player-controlled object (e.g., by attempting to collide with the player-controlled object, etc.). The aggressiveness with which the NPC attempts to accomplish this task may be a function of the current rank of the player-controlled object. Other aspects that may be controlled entirely (or largely) within the local simulation are discussed below in connection with 924, 926 and elsewhere herein.

[0127] In some examples, other vehicles participating in the race may be NPC-controlled. How these vehicles are controlled may be provided / determined by the server. In other words, instead of receiving position / status updates from clients and then the server communicating those updates to the clients, the server itself generates position / status data for those NPC-participating vehicles and then communicates such data to the clients.

[0128] 9, once the data regarding input from the player has been processed (at 902), any current updates have been received / processed from the server (at 904), and processing to update any NPC objects has occurred (at 908), the game state of the local simulation is updated at 910. Updating the game state may include updating the position of the player's vehicle 102 and other objects in the virtual game space based on newly received input / messages (from 902 / 904 / 908).

[0129] In some examples, updating the positions of objects may involve calculating where those objects should be by interpolating based on received (or unreceived) data. For example, an object may be at position 2,2, but the latest state data received from the server may indicate that the object is at position 10,10. In such a case, client-side processing may interpolate to adjust the object's position to, for example, position 4,4. While this is not the "true" position reported from the server to the client, using interpolation can result in a smoother gameplay experience for the user of that particular client because the object does not suddenly "warp" from 2,2 to 10,10.

[0130] Note that interpolation may be used to slowly correct an object's position and / or other state data that has changed on the client but has not similarly changed in the server-side simulation. An example of this is collision processing that may be performed on the client for an event object but not on the server. For example, using the interpolation location example above, the server may report that the event object is at 5,5 for one frame, but then at 10,10 for the next frame. However, one or more clients may cause a collision (e.g., another object bumps into / collides with the event object) that changes the event object's position from 5,5 to 2,2. In such a scenario, client-side interpolation may continue to update the event object with other state data (e.g., based on speed, angle of movement, etc.). However, if a new update is received from the server indicating that the event object is now at position 10,10, the client will perform additional interpolation using the newly received data. Note that the client may not simply update the event object's position to 10,10. Instead, client-side interpolation may use state data sent by the server (including, for example, controller inputs, etc.) to correct the current data of the event object over one (or multiple) frames. This may be based on timestamps and other time-related aspects of the newly received data that gradually move the position (and / or other state data) of the event object on the client to match (towards) the state of the event object on the server.

[0131] In some examples, different types of interpolation algorithms may be used depending on the nature of the objects in the game. For example, a first type of interpolation may be used for player objects, a second type of interpolation may be used for AI-controlled objects (e.g., other than event objects), and a third type of interpolation may be used for event objects. In an example embodiment, event objects may use a different interpolation algorithm (or the same algorithm with different values). In some examples, the difference may be that event objects interpolate more slowly than other objects. Thus, for example, if an object's current position and past position indicate a distance of 4, interpolation for a non-event object may move the object three-quarters of the way to its current position. However, interpolation for an event object may only move it halfway to its current position. In some examples, all of the objects in a game (e.g., player objects, NPC objects, event objects, etc.) may use the same interpolation algorithm to handle how a given object's state should be updated.

[0132] In other cases, new data regarding other player vehicles (or other aspects of the game) may not be received from the server for each execution frame (e.g., because the server may send updates for an object only every third frame, every sixth frame, etc.). Thus, interpolation may be used to estimate where other player vehicles will be located for this frame and what actions they may take. Such interpolation may also be beneficial due to the latency of communicating one vehicle's actions from a first computing device to another computing device via the server. The delay may be 100 ms or more between the two computing devices. Thus, in one example, data received from the server may be processed using an interpolation algorithm or the like to provide a better "guess" as to where other object vehicles are located in the virtual game space.

[0133] In either case, the local game state of the locally running instance of game program 550 is updated, for example, to update the positions (and / or other state data) of vehicles and other objects in the virtual game space.

[0134] Once the positions of the objects in the virtual game space have been updated, then at 912, collision detection processing may occur at 914. This may involve determining when two (or more) vehicles (or other objects) have collided with each other in the game world. Such processing may include determining whether some (or all) of the two or more vehicles occupy the same location in the virtual game space.

[0135] An illustrative example of the resulting collision when vehicles 140 and 110 collide with each other is shown in FIG. 3 (the aftermath of the collision is shown in FIG. 4). This collision may be determined by updates (or based on interpolation) received from server 502. Once movement-related data for vehicles 140 and 110 is received from the server (e.g., at a computing device operated by a user controlling vehicle 102) or interpolation is performed, the local simulation of the game state of the video game may be updated from that shown in FIG. 2 to that shown in FIG. 3 (e.g., additional frames may have been displayed in the meantime) in a manner that causes a collision between the two vehicles. Once a collision is detected, additional processing may be triggered. For example, the force of the collision may cause a change in the speed or position of the objects involved.

[0136] In some examples, collision detection processing may also include determining and handling collisions that occur with other objects or elements within the race, for example, if the vehicle hits a barrier or the like.

[0137] In some examples, if a collision between two other player vehicles (including event objects) is detected, the local simulation may handle such a collision internally. However, if the collision involves a player-controlled object 102, the health of the tracked object (such as 112 in FIG. 1) may be reduced by the collision. Additionally, the health of the vehicle 102 may be communicated to the server for handling.

[0138] In contrast, the health of other player vehicles may not be communicated to the server from another client. More specifically, in some examples, collisions occurring between other player vehicles may not affect the health of those vehicles' tracked targets within the simulation. Rather, health values ​​may be updated and controlled based on messages received from the server 502. In other words, health updates for vehicle 102 may be controlled based on a "local" simulation of that vehicle's response, while the health of other vehicles (e.g., 106 / 108 / 110 and / or 140) may be based on vehicle health parameters received at 904 from the server (e.g., that are part of the state data communicated from the server to each client).

[0139] In some examples, a client may handle collision detection processing for an event object. Such collision processing may be performed instead of or in addition to processing performed on the server. As an illustrative example, collision processing may determine whether an event object is to collide (e.g., whether the event object comes within a threshold distance) with a first type of object (e.g., an AI-controlled object). When such a collision occurs, the event object may be caused to dynamically perform an action (which may also be triggered, for example, from 810). Note that once the server processing determines that an action should be triggered for the event object, updated state data for the event object may then be communicated to all clients to perform the action. However, due to variations in how each client simulates a race, performing the action may not be handled exactly the same for each client. In other words, on a first client, a triggered action for the event object may be indicated to occur at location 2,2. And, on a second client, the same triggered action may be indicated to occur at location 2,3. Whether the event object collides with the object or not, it may indicate to any, all, or none of the clients that an action is being taken. In other words, even if the local client-side simulation does not indicate a collision, the triggered action may still be taken on the event object because the server has indicated that such an action should be taken on that event object.

[0140] In another example, collision processing for an event object may occur on the client. For example, if an event object is determined to collide with a first type of object (e.g., that explodes upon collision), client-side processing may automatically cause the event object to take an action (e.g., a spin move) that prevents the event object from being affected (or less affected) by the collision with the first type of object.

[0141] In some examples, state data may be communicated to clients indicating that an event object is to undergo a spin move due to a collision with a first type of object. Each client may then determine (as part of client-side processing) when to render / cause the “spin move” of the event object. For example, one client may determine that the collision occurs at timestamp 50, while another client may determine that it occurs at timestamp 55. The determination may be based, for example, on when the client determines that the collision occurred. Note, however, that a spin move cannot be triggered unless the server communicates to the client that a spin move should occur. In this way, while the server may control dynamically triggering actions, there may be some variability between clients as to when such actions should occur.

[0142] In some examples, the processing performed by the client may be based on the latency from the individual client to the server. If the latency value exceeds a threshold, the local simulation may be used to determine whether a triggering condition exists as reflected in the local game state. This may occur, for example, because an update from the server was received too far “in the past” (e.g., the latency may be 500 ms or more, 1 second or more, or more). The client-side simulation may then take over some or all of the responsibility of determining whether to trigger an action on an event object in response to determining that the network connection to the server is not providing a sufficient level of gameplay for the user. When this occurs, the client-side simulation may take over (e.g., as a backup, etc.) and make the decision. The decision may be the same or similar to that made by the server at 808. If the condition exists in the client-side game state, a dynamic action may be performed on the event object. In one example embodiment, the client simulation may include its own cool-down timer (similar to the cool-down timer maintained by the server). In other examples, such a cool-down timer may not be used as part of the client-side simulation (e.g., unlike the server-side simulation). Because network latency may change, circumstances may change such that the server provides an update (which arrives more quickly). The update may include state data that the event object is to perform a dynamic action. The client may perform this action even if a client-maintained cooldown timer is still running. In other examples, the presence of a client-maintained cooldown timer may inhibit the activation of the dynamic action for that client.

[0143] In some examples, enabling client-side control of an event object may be turned on / off based on measured latency values, and this change may occur more than once over the course of a single race. Thus, different techniques for handling collisions, triggering dynamic actions, and / or determining triggering conditions may be implemented according to various different embodiments.

[0144] In some examples, sending data regarding attributes of the vehicle 102 to the server (eg, 906) may occur after a game state update or after a collision detection process.

[0145] In some examples, transmission of data to server system 502 may not occur in every frame, but instead may occur, for example, every other frame, or every fifth or sixth frame, or other interval.

[0146] Once the game state of the game space has been updated for the current frame (which may include performing collision detection at 914), a view of the game space is rendered at 916. As shown in FIGS. 1-4 , the view generated may be a “third person” perspective that includes the vehicle 102 being controlled by the user. It is appreciated that in an example embodiment, other types of views (e.g., first person, etc.) may be generated. In some examples, the rendering may include generating heads-up display elements and overlaying them on the rendered image.

[0147] Once the image is generated, it is output at 918 to a display device coupled to the computing device for viewing by users playing the multiplayer video game.

[0148] Steps 902 through 918 may be referred to as race processing 900. These steps may be used to process new data, update the game state of a locally running simulated race, and present results to the user (e.g., in the form of images, sounds, etc.). In some examples, each of the elements shown in FIG. 9 may be performed as part of race processing.

[0149] In one example, the process shown in FIG. 9 operates multiple times per second to output images at a sufficient frame rate. Exemplary frame rates may be 24, 30, 60, or more frames (e.g., images) per second. It is recognized that not all elements shown as part of the race process may occur every iteration. For example, new data from the server 502 may not (and likely will not) be received every execution frame. This may be due to latency or the rate at which the server 502 communicates updates to the clients. Similarly, data may not be sent to the server 502 every iteration. If there are no NPCs in the race, there may be no NPC processing.

[0150] Additional Exemplary Embodiments In one example embodiment, the additional action that may be triggered may be a reaction event, which may include an emote, a textual reaction, or an audio reaction by the event object. For example, if the player object 102 (or another object) overtakes the event object 140, the event object may be caused to react with a voice line or an emote. In another example, this may occur if the event object performs a successful spin attack (e.g., in defeating the player), if the player hits the event object with a spin attack, etc. The event object may then be triggered to perform an appropriate reaction event.

[0151] In an example embodiment, another triggering action may be a determination that an event object is likely to hit (or will hit) another object. For example, in some cases, the object may be an AI-controlled object (e.g., not controlled by a player). In such an example, the server may (e.g., as part of server-side processing) cause the event object to try and avoid the object. In other examples, the server may dynamically steer an AI object to avoid where the event object is headed in the game. In other words, the event object may maintain its preset course without any (or substantial) modification to the course dictated by previously recorded event data. However, the server may control any AI object to avoid the event object. On the client side, similar actions may be taken (or at least communicated to the client). Furthermore, if a collision does occur, interpolation techniques may be used to guide the event object back to the server-directed course.

[0152] In one example embodiment, if the event object falls further behind the state of the recorded state data, a turbo speed-up may be applied to the event object as part of the client-side processing, which may be used to allow the event object on the client to "catch up" with the event object on the server (e.g., a similar speed-up would not be performed on the server).

[0153] In an example embodiment, the triggering conditions and / or actions may be based on the selected game type. For example, a first condition may be associated with a first game type, a second and third conditions may be associated with a second game type, and a first and fourth conditions may be associated with a third game type. Each game type may also have its own triggering actions.

[0154] In certain example embodiments, super turbo capabilities and / or secondary track transport capabilities (such as those discussed in US 18 / 461,061, the entire contents of which are incorporated herein by reference) may be dynamically triggered. In such cases, reliance on previously recorded state data may be suspended while the capability is active. When the capability ends, reliance on previously recorded state data may resume. Note that which instance of previously recorded state data is used may be offset based on activation. For example, when the capability stops, the state data with the closest location information to the event object's current location may be used, and a timer offset may be used to appropriately load the next state data instance later. In this way, the event object may "fast forward," etc., and then resume reliance on previously recorded state data (e.g., at the landing or exit point of a previously activated special ability). Thus, in some examples, the server may rely on or use previously recorded state data (e.g., for some portions of a race). During other times of the race, reliance on previously recorded state data may not be necessary, e.g., real-time AI control may be used for the event object.

[0155] In some examples, the playback speed of the event data may be adjusted based on the event object's current position in the race. If the event object is in the lead, the playback speed may be slowed down. If the event object is lagging behind (perhaps in the middle of all players), the event object's replay speed may be increased. In some examples, the playback speed may be adjusted depending on the difficulty level assigned to the event object.

[0156] In some examples, an event object may use or rely on a combination of previous records. For example, the data from such records may be stitched together, for example, based on the overall state of the race. In some examples, the state data from previous records may be based on where the event object started the race. In other words, each object may start from a different location (e.g., if 100 objects are racing, they may be spread out a significant distance).

[0157] In an example embodiment, piecing together different records may be based, for example, on the results of the first lap around the track, then a different record for the second lap. In some examples (e.g., if the race has five laps), five different records may be selected first, and then each record is used for one lap of the race. In some examples, a new record may be selected for each lap, and in other examples, the previously recorded state data used may be based on the results of a given lap (e.g., if the event object is in one of locations 1-4, use record A; if the event object is in position 5-10, use record B; if in the bottom half, use record D, etc.).

[0158] Description of Figure 10 10 is a block diagram of an exemplary computing device 1000 (which may also be referred to as a “computing device,” “computer system,” or “computing system”) according to some embodiments. In some embodiments, computing device 1000 includes one or more processors 1002 (which may be referred to as “hardware processors,” or individually as a “hardware processor”), one or more memory devices 1004, one or more network interface devices 1006, one or more display interfaces 1008, and one or more user input adaptors 1010. Additionally, in some embodiments, computing device 1000 is connected to or includes a display device 1012. As described below, these elements (e.g., processor 1002, memory device 1004, network interface device 1006, display interface 1008, user input adaptor 1010, display device 1012) are hardware devices (e.g., electronic circuits or combinations of circuits) configured to perform various different functions for computing device 1000. In some embodiments, these components of computing device 1000 may collectively be referred to as computing resources (e.g., resources used to perform instruction execution and including processors (one or more processors 1002), storage (one or more memory devices 1004), and I / O (network interface devices 1006, one or more display interfaces 1008, and one or more user input adapters 1010)). In some instances, the term processing resources may be used interchangeably with the term computing resources. In some embodiments, multiple instances of computing device 1000 may be arranged in a distributed computing system.

[0159] In some embodiments, each or any of the processors 1002 is or includes, for example, a single-core or multi-core processor, a microprocessor (e.g., which may be referred to as a central processing unit or CPU), a digital signal processor (DSP), a microprocessor associated with a DSP core, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, or a system-on-a-chip (SOC) (e.g., an integrated circuit that includes a CPU and other hardware components such as memory, networking interfaces, etc.). And / or, in some embodiments, each or any of the processors 1002 uses an instruction set architecture such as x86 or advanced RISC machine (ARM). In some embodiments, each or any of the processors 1002 is or includes, for example, a graphical processing unit (GPU), which may be an electronic circuit designed to generate images, etc. In some examples, one or more of the processors 1002 may be referred to as a processing system.

[0160] In some embodiments, each or any of the memory devices 1004 is or includes random access memory (RAM) (such as dynamic RAM (DRAM) or static RAM (SRAM)), flash memory (e.g., based on NAND or NOR technology), a hard disk, a magneto-optical medium, an optical medium, a cache memory, a register (e.g., that holds instructions), or other types of devices that perform volatile or non-volatile storage of data and / or instructions (e.g., software executed on or by the processor 1002). The memory devices 1004 are examples of non-transitory computer-readable storage devices.

[0161] In some embodiments, each or any of the network interface devices 1006 includes one or more circuits (such as a baseband processor and / or a wired or wireless transceiver) and implements Layer 1, Layer 2, and / or higher layers for one or more wired communication technologies (such as Ethernet (IEEE 802.3)) and / or wireless communication technologies (such as Bluetooth, WiFi (e.g., IEEE 802.11), GSM, CDMA2000, UMTS, LTE, LTE-Advanced (LTE-A), LTE Pro, Fifth Generation New Radio (5G NR), and / or other short-, medium-, and / or long-range wireless communication technologies). A transceiver may include circuitry for a transmitter and a receiver. The transmitter and receiver may share a common housing and may share some or all of the circuitry within the housing for transmission and reception. In some embodiments, the transmitter and receiver of a transceiver may not share any common circuitry and / or may be in the same or separate housings.

[0162] In some embodiments, data is communicated over an electronic data network. An electronic data network includes implementations in which data is communicated from one computer process space to another, and thus may include, for example, inter-process communication, pipes, sockets, and communication occurring over direct cables, cross-connect cables, Fibre Channel, wired and wireless networks, etc. In one example, network interface device 1006 may include ports or other connections that allow such connections to be made and that electronically communicate data between various components of a distributed computing system.

[0163] In some embodiments, each or any of the display interfaces 1008 is or includes one or more circuits that receive data from the processor(s) 1002, generate corresponding image data based on the received data (e.g., via a discrete GPU, an integrated GPU, a CPU that performs graphical processing, etc.), and / or output the generated image data to a display device 1012 that displays the image data (e.g., a high-definition multimedia interface (HDMI), a display port interface, a video graphics array (VGA) interface, a digital video interface (DVI), etc.). Alternatively or additionally, in some embodiments, each or any of the display interfaces 1008 is or includes, for example, a video card, a video adapter, or a graphics processing unit (GPU). In other words, each or any of the display interfaces 1008 may include a processor therein that is used to generate image data. The generation of such images may occur in conjunction with processing performed by one or more of the processors 1002.

[0164] In some embodiments, each or any of the user input adaptors 1010 is or includes one or more circuits that receive and process user input data from one or more user input devices (1014) included in, attached to, or otherwise in communication with the computing device 1000, and output data to the processor 1002 based on the received input data. Alternatively or additionally, in some embodiments, each or any of the user input adaptors 1010 is or includes, for example, a PS / 2 interface, a USB interface, a touch screen controller, etc. and / or the user input adaptor 1010 facilitates input from the user input devices 1014.

[0165] In some embodiments, display device 1012 may be a liquid crystal display (LCD) display, a light emitting diode (LED) display, or other types of display devices. In embodiments in which display device 1012 is a component of computing device 1000 (e.g., the computing device and display device are included in a single housing), display device 1012 may be a touchscreen display or a non-touchscreen display. In embodiments in which display device 1012 is connected to computing device 1000 (e.g., is external to computing device 1000 and communicates with computing device 1000 via wired and / or wireless communication techniques), display device 1012 may be, for example, an external monitor, projector, television, display screen, etc.

[0166] In some embodiments, each or any of the input devices 1014 is or includes mechanical and / or electronic devices that generate a signal that is provided to the user input adapter 1010 in response to a physical phenomenon. Examples of input devices 1014 include, for example, a keyboard, a mouse, a trackpad, a touchscreen, a button, a joystick, and a sensor (e.g., an accelerometer, a gyro sensor, a temperature sensor, etc.). In some examples, one or more of the input devices 1014 generate a signal that is provided in response to a user providing an input, for example, by pressing a button or activating a joystick. In other examples, one or more of the input devices generate a signal based on a sensed physical quantity (e.g., force, temperature, etc.). In some embodiments, each or any of the input devices 1014 is a component of a computing device (e.g., a button provided on a housing that includes the processor 1002, the memory device 1004, the network interface device 1006, the display interface 1008, the user input adapter 1010, etc.).

[0167] In some embodiments, each or any of the external devices 1016 includes additional computing devices (e.g., other instances of computing device 1000) that communicate with computing device 1000. Examples may include server computers, client computer systems, mobile computing devices, cloud-based computer systems, computing nodes, Internet of Things (IoT) devices, etc., all of which may communicate with computing device 1000. In general, external devices 1016 may include devices that communicate (e.g., electronically) with computing device 1000. As an example, computing device 1000 may be a gaming device that communicates over the Internet with a server computer system that is an example of external device 1016. Conversely, computing device 1000 may be a server computer system that communicates with a gaming device that is an example external device 1016.

[0168] In various embodiments, computing device 1000 includes one, two, three, four, or more of each or any of the above-mentioned elements (e.g., processor 1002, memory device 1004, network interface device 1006, display interface 1008, and user input adapter 1010). Alternatively or additionally, in some embodiments, computing device 1000 includes one or more of a processing system including processor 1002, a memory or storage system including memory device 1004, and a network interface system including network interface device 1006. Alternatively or additionally, in some embodiments, computing device 1000 includes a system-on-chip (SoC) or multiple SoCs, with each or any of the above-mentioned elements (or various combinations or subsets thereof) included in a single SoC or distributed across multiple SoCs in various combinations. For example, a single SoC (or multiple SoCs) may include processor 1002 and network interface device 1006. Alternatively, a single SoC (or multiple SoCs) may include the processor 1002, the network interface unit 1006, and the memory device 1004, etc.

[0169] Computing device 1000 may, in some embodiments, be arranged so that processor 1002 includes a multi- or single-core processor, network interface device 1006 includes a first network interface device (e.g., implementing WiFi, Bluetooth, NFC, etc.) and a second network interface device implementing one or more cellular communication technologies (e.g., 3G, 4G LTE, CDMA, etc.), and memory device 1004 includes RAM, flash memory, or a hard disk. As another example, computing device 1000 may be arranged so that processor 1002 includes two, three, four, five, or more multi-core processors, network interface device 1006 includes a first network interface device implementing Ethernet and a second network interface device implementing WiFi and / or Bluetooth, and memory device 1004 includes RAM and flash memory or a hard disk.

[0170] The above-described hardware configuration shown in FIG. 10 is provided as an example, and the subject matter described herein can be utilized with a variety of different hardware architectures and elements. For example, in many of the diagrams in this document, individual function / act blocks are shown. In various embodiments, the functionality of these blocks can be realized (a) using individual hardware circuits, (b) using application-specific integrated circuits (ASICs) specifically configured to perform the described functions / acts, (c) using one or more digital signal processors (DSPs) specifically configured to perform the described functions / acts, (d) using the hardware configuration described above with reference to FIG. 10, or (e) via other hardware arrangements, architectures, and configurations, and / or via a combination of the techniques described in (a)-(e).

[0171] Technical advantages of the described subject matter In one exemplary embodiment, a technique is provided for implementing a multiplayer video game, e.g., having multiple users. The technique involves handling certain types of multiplayer game interactions entirely (or largely) within a given client's local simulation. These separate simulations may be different, even though each client is part of the "same" multiplayer game. This approach advantageously allows for the elimination of the need to perfectly synchronize every aspect of the multiplayer game across dozens or hundreds of different simulations running across various clients participating in the same game. A technical advantage of this approach advantageously provides for not transmitting data regarding certain events, while still providing simultaneous gameplay across various clients of the multiplayer video game.

[0172] In one exemplary embodiment, a technique is provided for enabling dynamic interaction in a multiplayer video game in combination with previously recorded state data. The technique involves controlling the state of event objects on a server, but allowing those same event objects to be processed differently locally on client systems (e.g., based on collisions, etc.). Local processing can enable more dynamic interaction with previously recorded state data. Dynamic interaction is also facilitated by determining when triggering conditions are met and then triggering dynamic actions for the event objects. In one exemplary embodiment, triggering can be additionally controlled based on a cooldown timer maintained by the server.

[0173] In an example embodiment, the same action for a given object (e.g., an event object) may be triggered in multiple different ways. A first occurrence may be whether previously recorded state data causes the action to occur. A second occurrence may be a determination as to whether one or more triggering conditions exist (e.g., based on the dynamic nature of the current state of the virtual game space). The occurrence of the first and second options may additionally depend on a cool-down timer not running. A third occurrence may also trigger the same action. However, the third occurrence may not depend on whether a cool-down timer is running (and may generally occur less frequently than the second action). In other words, in the third option, the action may always be triggered (e.g., may be force-triggered) relative to the other two instances in which the same action may be triggered.

[0174] Selected terms Elements described in this document include acts, features, components, items, attributes, and other terms. Whenever this document describes a given element as being present in "some embodiments," "various embodiments," "an embodiment," "an exemplary embodiment," "some exemplary embodiments," "exemplary embodiments," "an example," "case," "exemplary case," or any other similar language is used, it should be understood that the given element is present in at least one embodiment, but not necessarily in all embodiments. Consistent with the above, whenever this document describes an action as "may," "can," or "could" be performed, it should be understood that a feature, element, or component "may," "can," or "might" be included within or applicable to a given context, that a given item "may," "can," or "might" have a given attribute, or any similar phrase related to the terms "may," "can," or "might," is used, and that a given action, feature, element, component, attribute, etc. is present in at least one embodiment, but not necessarily in all embodiments.

[0175] Terms and phrases used in this document, and variations thereof, should be construed as open-ended rather than limiting, unless expressly stated otherwise. In the above examples, "and / or" includes any and all combinations of one or more of the associated listed items (e.g., a and / or b means a, b, or a and b). The singular forms "a," "an," and "the" should be construed to mean "at least one," "one or more," etc. The term "example" may be used interchangeably with the term embodiment and is used to provide examples of the subject matter under discussion, but not an exhaustive or limiting list thereof. The terms "comprise" and "include" (and other conjugations and other variations) specify the presence of the associated listed elements, but do not exclude the presence or addition of one or more other elements. When elements are described as "optional," such description should not be understood to indicate that other elements are not required unless so recited.

[0176] As used herein, the term "non-transitory computer-readable storage medium" includes registers, cache memory, ROM, semiconductor memory devices (such as D-RAM, S-RAM, or other RAM), magnetic media such as flash memory, hard disks, magneto-optical media, optical media such as CD-ROMs, DVDs, or Blu-ray discs, or other types of volatile or non-volatile storage devices for non-transitory electronic data storage. The term "non-transitory computer-readable storage medium" does not include transitory, propagating electromagnetic signals.

[0177] A claim is not intended to invoke a means-plus-function construction / appraisal unless the claim expressly uses the phrase "means for" or "things for." Claim elements, if any, that are intended to be construed / applied as means-plus-function language will expressly indicate that intention by reciting the phrase "means for" or "things for." The above applies to claim elements in all types of claims (method claims, apparatus claims, or other types of claims) and, for the avoidance of doubt, also applies to claim elements incorporated within method claims. Consistent with the preceding sentence, no claim element (in any claim of any type) should be construed / applied using a means-plus-function construction / appraisal unless the claim element is expressly recited using the phrase "means for" or "things for."

[0178] Whenever a hardware element (e.g., a processor, network interface, display interface, user input adapter, memory device, or other hardware element) or combination of hardware elements is described herein as being "configured" to perform some action, it should be understood that such language identifies the physical state of the configuration of the hardware elements and not merely the intended use or capability of the hardware elements. The physical state of the configuration of the hardware elements fundamentally links the action described after the phrase "configured to" to the physical characteristics of the hardware element described before the phrase "configured to." In some embodiments, the physical state of the configuration of the hardware elements may be realized as an application-specific integrated circuit (ASIC) that includes one or more electronic circuits configured to perform an action, or a field-programmable gate array (FPGA) that includes programmable electronic logic circuits arranged in series or parallel to perform actions according to one or more instructions (e.g., via a configuration file for the FPGA). In some embodiments, the physical state of a configuration of hardware elements may be determined by storing (e.g., in a memory device) program code (e.g., instructions in the form of firmware, software, etc.) that, when executed by a hardware processor, causes the hardware elements to act in accordance with the program code (e.g., by configuration of registers, memory, etc.).

[0179] A hardware element (or multiple hardware elements) can be understood to be configured to perform an action even when the identified hardware element is not currently performing the action or is not operational (e.g., not turned on, not powered, not in use, etc.). Consistent with the above, the phrase "configured to" in the claims should not be construed or construed as a means-plus-function in any claim type (method claim, apparatus claim, or other type of claim). This includes claim elements (such as hardware elements) incorporated into method claims.

[0180] Additional Applications of the Described Subject Matter Although process things, algorithms, and the like, including but not limited to those with reference to Figures 7 through 9, may be described or claimed in a particular order, such processes may be configured to work in different orders. In other words, any sequence or order of things that may be explicitly described or claimed in this document does not necessarily indicate a requirement that things be done in that order. Rather, things of processes described herein may be done in any order possible. Furthermore, even if some things are described or implied as occurring non-concurrently (e.g., because one thing is described after another), they may be done simultaneously (or in parallel). Furthermore, the illustration of a process by its delineation in a drawing does not imply that the illustrated process excludes other variations and modifications, nor does it imply that the illustrated process or any of its things are required, nor does it imply that the illustrated process is preferred.

[0181] Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above description should be construed to imply that any particular element, feature, range, or function is essential. All structural and functional equivalents to the elements of the above-described embodiments known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by the present invention. Furthermore, a device or method need not address each and every problem sought to be solved by the present invention, for it to be encompassed by the invention. No embodiment, feature, element, component, or feature in this document is intended to be made available to the public.

Claims

1. 1. A non-transitory computer-readable storage medium storing computer-executable instructions for use with a computer system including at least one hardware processor, the stored computer-executable instructions comprising instructions configured to cause the computer system to perform operations, the operations including: storing previously recorded state data, the previously recorded state data including a plurality of types of state data for recreating a state of at least one object in another instance of the multiplayer video game, and further comprising: performing a simulation process that includes manipulating a plurality of virtual objects in a virtual game space, the plurality of virtual objects including a plurality of participant-controlled virtual objects and at least one second virtual object; and further comprising: receiving update messages from a plurality of client computing systems, each associated with a respective one of the plurality of participant-controlled virtual objects; as part of performing the simulation process, controlling movement of the second virtual object within the virtual game space based on the stored previously recorded state data; determining, based on a current state of the virtual game space, that a trigger generation condition has been satisfied for the second virtual object; triggering a dynamic action on the at least one second virtual object to be performed based on a determination that a triggering condition is satisfied; and sending, to each of the plurality of client computing systems, an update message based on the dynamic action being triggered.

2. the operations further comprise starting a timer for a duration based on triggering the dynamic action; The non-transitory computer-readable storage medium of claim 1 , wherein determining that the triggering condition has been met is also based on whether the timer is running.

3. the previously recorded state data includes states corresponding to performance of the same action as the dynamic action; 3. The non-transitory computer-readable storage medium of claim 2, wherein the action further comprises triggering the second virtual object to perform the action that is the same as the dynamic action based on the previously recorded state data.

4. 4. The non-transitory computer-readable storage medium of claim 3, wherein the operation further comprises starting the timer for a duration based on triggering the action same as the dynamic action via the previously recorded state data.

5. The previously recorded state data includes a second state corresponding to another performance of the same dynamic action, and the operation further comprises:

3. The non-transitory computer-readable storage medium of claim 2, comprising: determining that the timer is running; and, based on the determination that the timer is running, controlling the second virtual object without triggering another instance of the action that is the same as the dynamic action for the other performance of the action.

6. The operation further comprises: determining, based on a current state of the virtual game space, that another trigger generating condition has been satisfied for the second virtual object, wherein the timer is started when it is determined that the other trigger generating condition has been satisfied; and the operation further includes:

3. The non-transitory computer-readable storage medium of claim 2, comprising triggering the dynamic action for the at least one second virtual object to take place based on a determination that the other triggering condition is met.

7. 10. The non-transitory computer-readable storage medium of claim 1, wherein the triggering condition is based on a determination that the second virtual object has collided or will collide with another one of the plurality of virtual objects.

8. The non-transitory computer-readable storage medium of claim 1 , wherein the update message includes an instruction to perform the dynamic action.

9. The non-transitory computer-readable storage medium of claim 1 , wherein the recorded state data includes a timestamp value, position data, orientation data, movement vector data, and controller status data.

10. The non-transitory computer-readable storage medium of claim 1 , wherein each of the plurality of client computing systems executes a client-side simulation multiplayer video game based on receiving and subsequently processing the update messages.

11. 1. A computing system for executing a multiplayer video game using a plurality of client gaming devices, the computing system comprising: at least one hardware processor coupled to a memory, the at least one hardware processor configured to perform operations, the operations comprising: storing previously recorded state data, including multiple types of state data for recreating the state of the object; executing a simulation process in a virtual game space including a plurality of virtual objects, the plurality of virtual objects including a plurality of participant-controlled virtual objects and at least one second virtual object; and receiving update messages from a plurality of client computing systems, each associated with a respective one of the plurality of participant-controlled virtual objects; as part of performing the simulation process, controlling movement of the second virtual object within the virtual game space based on the stored previously recorded state data; determining, based on a current state of the virtual game space, that a trigger generation condition has been satisfied for the second virtual object; triggering a dynamic action on the at least one second virtual object to be performed based on a determination that a triggering condition is satisfied; and sending an update message to each of the plurality of client computing systems based on the dynamic action being triggered.

12. the operations further comprise starting a timer for a duration based on triggering the dynamic action; 12. The computing system of claim 11, wherein determining that the triggering condition has been met is also based on whether the timer is running.

13. the previously recorded state data includes states corresponding to performance of the same action as the dynamic action; The computing system of claim 12 , wherein the action further comprises triggering the second virtual object to perform the action that is the dynamic action based on the previously recorded state data.

14. 14. The computing system of claim 13, wherein the operation further comprises starting the timer for a duration based on triggering the same action as the dynamic action via the previously recorded state data.

15. The previously recorded state data includes a second state corresponding to another performance of the same dynamic action, and the operation further comprises:

13. The computing system of claim 12, further comprising: determining that the timer is running; and, based on the determination that the timer is running, controlling the second virtual object without triggering another instance of the action that is the same as the dynamic action for the other performance of the action.

16. The operation further comprises: determining, based on a current state of the virtual game space, that another trigger generating condition has been satisfied for the second virtual object, wherein the timer is started when it is determined that the other trigger generating condition has been satisfied; and the operation further includes: The computing system of claim 12 , further comprising triggering the dynamic action on the at least one second virtual object to take place based on a determination that the other triggering condition is satisfied.

17. The computing system of claim 11 , wherein the triggering condition is based on a collision determination that the second virtual object has collided or will collide with another one of the plurality of virtual objects.

18. The computing system of claim 11 , wherein the update message includes an instruction to perform the dynamic action on the at least one second virtual object.

19. 1. A non-transitory computer-readable storage medium storing computer-executable instructions for use with a computer system including at least one hardware processor, the stored computer-executable instructions comprising instructions configured to cause the computer system to perform operations, the operations including: storing object data for a plurality of virtual objects for a multiplayer video game, the plurality of virtual objects including a first participant-controlled virtual object, a plurality of other participant virtual objects, and at least one second virtual object, the operations further comprising: performing a client-side simulation of the multiplayer video game including the plurality of virtual objects in a virtual game space, the client-side simulation using the stored object data, the operation further comprising: processing user input to control the first participant-controlled virtual object; receiving a video game update message from another computer system, the video game update message including data for the plurality of other participant virtual objects and / or the at least one second virtual object; updating the object data of the first participant-controlled virtual object based on the processed user input; updating the object data of the plurality of other participant virtual objects and / or the at least one second virtual object by interpolating position data of the plurality of other participant virtual objects and / or the at least one second virtual object based on the video game update message; performing client-side collision processing for the plurality of virtual objects in a virtual game space as part of the client-side simulation, wherein collisions involving the at least one second virtual object are not included in the video game update message, the operations further comprising: generating and outputting video game images based on the client-side simulation of the multiplayer video game.

20. 20. The non-transitory computer-readable storage medium of claim 19, wherein different objects among the plurality of other participant virtual objects and / or the at least one second virtual object are interpolated differently based on a type of virtual object.

Images