System and method for processing player's conversation in multiplayer virtual game space

Abstract

To provide a computer system for allowing a player to play an on-line multiplayer game.SOLUTION: When collision is detected during a game, energy objects are created. The objects are acquired by a player during a game and may increase a special capability meter. By validation of the special capability meter, a player is served by at least one reward during a multiplayer video game. In several examples, the rewards can include movement of a player object to a second track within a multiplayer racing game.SELECTED DRAWING: Figure 9

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is one of two related applications, all of which are filed on the same day as this application. This application incorporates by reference the entire contents of the other application. The two related applications are U.S. Application No. 18 / 461,061 (Attorney Docket No. 723-5096) and U.S. Application No. 18 / 461,092 (Attorney Docket No. 723-5097). Technical overview

[0002] The technology described herein relates to multiplayer video game systems in which players interact with each other in a virtual space. More particularly, the technology described herein relates to tracking interactions within the virtual space of a multiplayer video game, including collisions between players. Introduction

[0003] Massively multiplayer video games that support online multiplayer can be difficult to implement due to issues such as network latency, packet loss, and other considerations that can result in different experiences for each player. These technical considerations can be further complicated depending on the various features included in the multiplayer game where players on each computing device interact during the game.

[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 an aspect of a multiplayer game, and updates are communicated between the clients and a server.

[0006] In an exemplary embodiment, energy objects are generated and positioned within the multiplayer game. Players of the multiplayer game may acquire these objects to increase the value of parameters of special abilities. In some examples, energy objects are generated based on determining collisions between player-controlled objects. These objects may be acquired by players during the game to increase a special ability meter. Activation of the special ability provides the player with one or more benefits during the multiplayer video game. In some examples, the rewards may include moving the player-controlled object to a second track within the multiplayer racing game. The track and / or the player-controlled object may then be awarded the reward in the racing game for a period of time. In some examples, the period of time the ability is active is based on the positioning of the player-controlled object within the race. In some examples, the higher the positioning, the shorter the period.

[0007] In some examples, the creation and / or acquisition of energy objects is handled by each client without being synchronized to a server or host computer system. In some examples, the generation of energy objects on various clients participating in a multiplayer game may differ. This may be due to variations in how each client simulation is handled and / or the creation of such objects is not communicated / synchronized to the host.

[0008] In an exemplary embodiment, each time a player participates in a multiplayer game, each player is assigned a smaller subset of players in the larger multiplayer game as rivals. Each player's rivals are tracked and displayed to each player in different ways during the multiplayer video game. A player's skill rating is tracked based on the results of comparisons with the selected rivals.

[0009] 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. As such, 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] These and other features and advantages will be more fully and completely understood by reference to the following detailed description of exemplary and non-limiting illustrative embodiments taken in conjunction with the drawings. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a wireframe diagram of a multiplayer video game according to an example embodiment.

[0012] [Diagram 2] 2 is a wireframe diagram of the multiplayer video game of FIG. 1 illustrating a determination that two player vehicles collide with each other, according to an illustrative embodiment.

[0013] [Diagram 3] 3 is a wireframe diagram of the multiplayer video game of FIG. 1 illustrating the generation of energy objects based on the collision determination shown in FIG. 2 according to an exemplary embodiment.

[0014] [Figure 4] 2 is a wireframe diagram of the multiplayer video game of FIG. 1 showing a player-controlled vehicle using a second track, according to an exemplary embodiment.

[0015] [Diagram 5]2 is a wireframe diagram of the multiplayer video game of FIG. 1 illustrating graphical elements for dynamic assignment of other players as rivals in accordance with an example embodiment.

[0016] [Figure 6] 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.

[0017] [Figure 7] FIG. 2 is a signal diagram illustrating the setup of an exemplary instance of the multiplayer video game shown in FIG. 1 and how communication may occur between a client and a server in connection with such a setup, according to an exemplary embodiment.

[0018] [Figure 8] 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.

[0019] [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.

[0020] [Figure 10] 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.

[0021] [Figure 11] 2 is a flow chart illustrating the processing that occurs for the multiplayer video game shown in FIG. 1 when a player-controlled object uses a second track in a race, according to an exemplary embodiment.

[0022] [Figure 12] 2 is a flow chart illustrating the processing that occurs for the multiplayer video game shown in FIG. 1 regarding how rivals are selected and how player information is updated based on the results of a race, according to an example embodiment.

[0023] [Figure 13] 1 illustrates an exemplary computing device that may be used in some embodiments to implement features described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] Detailed Description In the following description, for purposes of explanation and non-limiting, specific details are set forth, such as particular nodes, functional elements, techniques, protocols, etc., to provide an understanding of the described technology. It will be apparent to one of ordinary skill 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, apparatus, techniques, etc. are omitted so as not to obscure the description with unnecessary detail.

[0025] 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 the headings should not be construed as affecting the meaning of the descriptions contained in any section.

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

[0027] Some reference numbers are reused across the figures to refer to the same elements. For example, the server system 602 first shown in Figure 6 is also referenced and described in connection with Figures 7, 8, and so on. Overview

[0028] In an exemplary embodiment, an online multiplayer racing game is provided. In one example, 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) 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 his or her 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. In one example, each player in a race is assigned a smaller subset (e.g., 4 out of 100 different competitors) as Rivals.

[0029] In some examples, energy objects are generated and positioned on the track when a collision between vehicles is determined. In some examples, vehicles in a race can acquire these energy objects to charge or increase a special ability meter. When the special ability meter is charged, a player can activate a special ability.

[0030] In some exemplary embodiments, a race may include two or more different tracks between which a player can move their vehicle during a race. The different tracks may be designed differently and may include different features. For example, a first track may be more difficult (e.g., including more obstacles, curves, etc.), while a second track may be straighter, easier to maneuver, etc. In some examples, a special ability may be enabled (e.g., by a player) that allows his or her vehicle to move to another track.

[0031] In many places in this document, we describe software (e.g., modules, software engines, services, applications, etc.) and actions (e.g., functions) performed by the software. This is done for ease of description, and whenever this document describes software as performing an action, it should be understood that the action is actually performed by the underlying hardware elements (such as processors and memory devices) in accordance with the software and instructions contained therein. In some examples, functions provided in software may be provided in the form of firmware and / or hardware implementations in some embodiments. Further details in this regard are provided below, particularly in the description of FIG. 13. Description of Figures 1-5: Illustrative Examples

[0032] 1-5 are wireframe diagrams (100, 200, 300, 400, and 500) illustrating different aspects of an exemplary multiplayer video game. As shown in these figures, a racing game is used as an example of a multiplayer video game that may be implemented in an exemplary embodiment. Although the techniques herein are discussed in connection with 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.

[0033] In an exemplary embodiment, the exemplary racing game discussed herein allows dozens or even a hundred or more users to participate and compete within the same virtual space. Figure 1 is a wireframe illustration 100 of images generated as part of an online multiplayer racing game in which users race each other around a track 104 located within a virtual game space. The images (including image 100) may be generated by a computing device 1300 that users use to participate in the multiplayer video game. The generated images may be displayed on a display device 1312 coupled to the computing device 1300.

[0034] The diagram 100 includes heads-up display elements (discussed below) that are part of or overlaid on a rendered view of a virtual game space, which includes a track 104, player-controlled virtual objects 102 that are controlled by players (and users providing input thereto) playing a multiplayer video game on a computing device 1300 on which a local simulation is running, and additional virtual objects.

[0035] A runway in the virtual game space may include various obstacles, jump pads, speed-up areas (e.g., 410 in FIG. 4), etc. Generally, a multiplayer game may be played by having players run around a given runway multiple times.

[0036] 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 "NPCs").

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

[0038] In some examples, the vehicles participating in the race may be NPC vehicles. For example, if there are 50 vehicles in the race, 10 may be NPC vehicles. NPC vehicles may be 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 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). As discussed below, in certain examples and in some cases, one or more rivals in a multiplayer game may be NPC vehicles.

[0039] It should be noted that for ease of explanation, the term "vehicle" is used interchangeably with object, player-controlled object, and other virtual objects that may be placed 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). In general, a player-controlled object is an object to which a user provides input (e.g., via input device 1314 of FIG. 13 ) to control one or more attributes (e.g., direction, speed, abilities such as special powers, etc.) of the corresponding player-controlled object. In certain illustrative embodiments, as discussed elsewhere herein, player-controlled objects may include objects that are computer-controlled (e.g., by a server), and these players may be referred to as AI players.

[0040] Another type of virtual object that may be included in the virtual game space includes spark objects 150. A number of spark objects 150 are shown in FIG. 1. These objects may be acquired by players during the game or may be generated based on collisions between vehicles, special NPC objects, and other sources. Additional details regarding spark objects are provided below.

[0041] 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 that are outside of a virtual three-dimensional space. For example, in certain exemplary embodiments, two-dimensional multiplayer video games (e.g., side scrollers with little or no z-axis) may be implemented.

[0042] Returning to image 100 shown in Figure 1, the image may include heads-up display elements that are presented to a user (e.g., to provide additional informational content to a user playing a 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 a player-controlled object is traveling in a race (424 km / h in the example of Figure 1), etc.

[0043] The display element 116 is used to indicate the ranking of the player-controlled object 102 within the race (i.e., position 49 out of 99 positions within the race). In some examples, the display element 116 may include additional information indicating the current race if there are multiple different races (e.g., as part of a racing circuit competition).

[0044] In some examples, the display elements 116 may also include a notification (e.g., "OK") that may be used to indicate whether the player and his / her 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, and if the player is outside the cutoff line, the player may not advance to the next race. In some examples, the cutoff line may be used on a lap-by-lap basis (e.g., every lap or every other lap, etc.) of the race. In such cases, the player and his / her vehicle may be removed from the race if they are not within the cutoff line. As an example, the cutoff line may be set at 70 (so the top 70 players advance). If a top 70 cutoff line is used, an OK notification is displayed. If not, another notification may be displayed indicating that the player is below the cutoff line.

[0045] The power meter 112 shows a graphical display 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 when 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 deplete while the increase capability is active.

[0046] The 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. This is discussed in more detail in connection with Figures 9 and 11.

[0047] The mini-map 118 shows a miniature version of the race course and in some examples may separately identify (e.g., by color, shading, icon, etc.) where the player-controlled objects are in the race, where any rivals are located, which objects are in the lead, 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, and other player vehicles may be blue. In some examples, there may be multiple mini-maps displayed, as shown and discussed in more detail in connection with FIG. 5.

[0048] 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 flash or blink as the vehicle gets "closer" to the player-controlled object 102. In some examples, different animations or colors may be used to indicate whether the vehicle behind is closer or further away. In some examples, the check icon 120 may be displayed differently to the current player for vehicles that are rivals.

[0049] In some examples, the heads-up display elements 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 the usernames or player 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. In some examples, each object participating in the race may be identified by a corresponding icon. As an example, each of the vehicles may have a corresponding icon that, in some examples, 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 leading the race (e.g., "Nifty Fan" in FIG. 5) may be displayed, as well as the five objects closest to the player-controlled object 102's position in the race. In one example, as discussed in more detail in connection with FIG. 5 and other figures, each of the current player's rivals may be automatically displayed to identify where their vehicles are located in the race. Such functionality may allow a user to more easily recognize where their rivals are in the race.

[0050] 2 is a wireframe diagram 200 of the multiplayer video game of FIG. 1 showing two different player-controlled objects (controlled by different users using different clients) colliding with each other, according to an example embodiment. In an example, as discussed in more detail in connection with FIG. 9, the determination of a collision between two (or more) vehicles (or other objects in the virtual space) (e.g., collision detection processing) may be performed locally by each game program executing on a corresponding client. However, in some examples, such a collision may be determined by the server system 602, or by both one or more clients and the server system 602. Once such a collision is determined, a virtual object may be generated and dynamically positioned in the virtual space (e.g., on a track at the location of the detected collision).

[0051] 3 is a wireframe diagram 300 of a multiplayer video game illustrating a frame of the game that occurs after a collision is detected as shown in FIG. 2. When such a collision occurs, an energy object 300 is generated. The energy object 300 is another instance of the energy object 150 shown in FIG. 1. Once the energy object 300 is generated, it is then positioned at, near, or otherwise based on the location of the detected collision in virtual space. Additional details regarding the generation and processing of energy objects are discussed, for example, in connection with FIG. 9.

[0052] In an exemplary embodiment, a player can control his / her vehicle 102 to collect energy objects located on the track. Each time one of these energy objects is collected, the value of a tracked parameter of the player (or the player's vehicle) may increase. A special ability meter 114 is used to graphically represent the current value of the tracked parameter of the player-controlled object 102. When the value of the tracked parameter reaches a threshold, the player can activate a special ability of the player-controlled object. According to an exemplary embodiment, different types of special abilities may be implemented. The different types of special abilities may include 1) increasing the speed of the vehicle, 2) allowing the vehicle to fly (e.g., without strictly following the path of the track), 3) transitioning to another track (e.g., track 404), 4) making the vehicle invincible, and other options that may affect the vehicle, other vehicles, or the race.

[0053] Activation of special abilities may be done to give players in a race a way to catch up to the front of the race (e.g., coming from the back to win the race). This ability may give players lower in the race an advantage over higher ranked players, since vehicles at the top may have fewer opportunities to capture energy objects (because they are the result of collisions). In some examples, NPC objects may be designed to not show up or drop energy objects for those at the front of the race.

[0054] FIG. 4 is a wireframe diagram 400 of the multiplayer video game of FIG. 1 showing a player-controlled object activating a special ability and using a second track 404 that is different from the first track 104. As noted above, an illustrative example of an implementation of a special ability is to move the player-controlled object to the second track. While on the second track 404, the player may be provided with a view of other vehicles still on the first track. The second track 404 may generally follow the path of the first track, but may be less complicated and / or may take a more advantageous route for racing. For example, as shown in FIG. 4, the second track does not include the curve that the first place vehicle, labeled "Mavis," is about to take on the first track 104. Rather, the track 404 includes a long straight track that crosses the corner of the included curve that is part of the track 104.

[0055] There may be one or more advantages provided to the vehicle 102 while the vehicle 102 is on the second runway. In an exemplary embodiment, a parameter or attribute of the vehicle 102, or how that parameter or attribute is controlled, may be altered based on the vehicle being on the second runway. For example, the vehicle's maximum speed (or other speed / movement attribute) may be increased or altered as compared to when the vehicle was on the first runway 104. As shown in FIG. 4, the vehicle 102 has a maximum speed of 630 kph, an increase from the maximum speed of 424 kph in FIG. 3. In an example, the increase may be a percentage increase from the maximum speed allowed on the first runway (also referred to herein as the "main" or "primary" runway), or may be a maximum speed associated with the particular second runway. In an exemplary embodiment, different runs may have different maximum speeds associated with corresponding runs or types of corresponding runs.

[0056] In an exemplary embodiment, the use of the second track may provide alternative or additional benefits to the player and / or his / her vehicle. As another example, control of the vehicle may be easier for the user, e.g., in the form of steering assistance for controlling the vehicle. For example, inputs provided by the user to control the vehicle may be more responsive. In some examples, the movement of the vehicle may be biased toward the centerline of the second track. The centerline of the second track may be predefined (e.g., in the world space in which the track is located) and may provide a bias of control of the vehicle moving on the second track toward the center. As an illustrative and non-limiting example, when the game state is updated based on inputs provided by the user (e.g., as discussed in FIG. 9), an additional force vector may be applied toward the centerline of the second track. In contrast, no such bias may be present (or may be less) on the main track. Such processing may allow the user to have greater "control" over his / her vehicle as it travels along the second track. In some examples, the vehicle may not sustain damage from the collision while on the second runway. In some examples, the setup or shape of the second runway may be different from the first runway (e.g., not including as many curves, shorter (e.g., a shortcut), has more speed increases 410, is straighter, etc.).

[0057] Another advantage of using the second track in an example is that the health of the vehicle (e.g., 112) may be fixed and no further damage may be done to the vehicle while it is on the second track. In an example, when the vehicle is on the second track, it may be prevented from being taken out of the race due to a crash (e.g., losing all health or durability). In an exemplary embodiment, the health of the vehicle (e.g., 112) may gradually increase as long as the vehicle remains on the second track. Another advantage of the second track may be that there are no (or fewer) other vehicles using the second track compared to the first track. In an example, when a vehicle activates the second track, the second track may be dedicated to that client. In other words, even if multiple other vehicles are using the second track simultaneously during the race (even if they are in the same or similar position in the race), they may not encounter each other. Other vehicles on the second track may not be rendered by the client and collision processing with those other vehicles may not be performed. This approach may allow a player to more easily control his or her vehicle on the second track (e.g., because the vehicle does not have to drive around other vehicles.) Note that, as shown in Figure 4, vehicles on the second track may be visible to vehicles on the first track, and vice versa.

[0058] Additional details regarding the use of the second runway and associated processing are discussed below in conjunction with FIG.

[0059] FIG. 5 is a wireframe illustration 500 of the multiplayer video game of FIG. 1 showing graphical elements for how rivals are displayed to players according to an example embodiment.

[0060] Specifically, as noted elsewhere herein, there may be dozens or even a hundred or more different players in the same multiplayer game (e.g., racing around the same track), each with their own vehicle. In one example, the number of players that may participate in the same multiplayer game may be 99. As used herein, the term "extended multiplayer game" is used for situations in which at least 20 players are playing in the same multiplayer game. The term extended multiplayer game is a subset of multiplayer games involving at least two players. An extended multiplayer game may have 25, 50, 99, 100, or more players participating in the same multiplayer game. In one example, each player participating in an extended multiplayer game may have their own computing device.

[0061] With so many different players participating in the same game, it may be difficult for some players to feel motivated in the game unless the player is near the top of the leaderboard. Thus, in an exemplary embodiment, one or more rivals may be dynamically selected at the start of a race for each player. The selection of rivals may allow a given player to compete against a smaller subset of players (referred to herein as rivals) during a larger race. In one example, four rivals are selected for each player at the start of a race. This feature allows players to enjoy the game even if they are not near or competing for first place. Rather, players may focus on competing (e.g., racing) against a dynamically selected group of other players who are rivals. The selection of players as rivals is discussed in more detail in connection with FIG. 7.

[0062] As shown in Figure 5, a list 510 may be displayed that includes the player's four rivals (and "Player"). This may be shown to give the player a relative position of the player to the player's four rivals. As shown in Figure 5, "Liberias" (ranked 4th overall in the race) is the highest ranked player of the four rivals of vehicle 102, followed by Player (ranked 7th overall), "Paul" (ranked 10th overall), "Benet" (ranked 11th overall), and "Stuart" (ranked 16th overall).

[0063] In some examples, the rivals of the player-controlled object 102 may be displayed differently to the player during a race. For example, as shown in Figure 5, a "rival" icon 502 is displayed above the vehicle operated by Liberius.

[0064] In some examples, a second or alternative mini-map 520 may be displayed as part of a heads-up display element. The mini-map 520 may display the positioning of objects in the race in a relatively linear manner (e.g., without displaying the outline of the track). In other words, it may show the relative positions of all (or some) of the vehicles (which may include NPCs) in the race, and the shape of the track may not be shown on the mini-map 520 (e.g., because it is linear and track 104 is not).

[0065] In some examples, both mini-map 520 and mini-map 118 are displayed to the user simultaneously. In other examples, one or the other (but not both) may be displayed. In some examples, the user can select how the mini-maps are displayed (e.g., by providing an input to select which mini-map to display). For example, the user may choose to display neither, only one (and be able to toggle between showing which), and / or both. As discussed herein, different graphical representations of icons on the mini-map may be used to differentiate between the player, other player-controlled objects, non-player-controlled objects, rivals, and other objects in the race. Description of Figure 6: System

[0066] Turning now to the computer architecture provided to enable users to play the multiplayer video game, FIG. 6 is a system diagram illustrating how the multiplayer video game shown in FIG. 1 may be implemented in a system using a client-server architecture according to an exemplary embodiment.

[0067] The system 600 includes a server computer system 602 (also referred to herein as a server 602) in communication with a number of computing devices 610 (610a-610n), each configured to execute an instance of a game program 650. The game program 650 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.

[0068] There may be hundreds or even thousands of such computing devices 610 in communication with the server 602, and there may be, for example, a hundred such computing devices participating in the same instance of a multiplayer video game. Each of the computing devices acts as a client that communicates with the server computer system 602.

[0069] As discussed in connection with various signal diagrams herein, the computing devices 610 communicate with the server system 602 via a network 660. In some examples, the network 660 may be, for example, the Internet, where communication may occur between the clients 610 and the server system 602 using UDP / IP to transmit state data of the ongoing game. In other examples, the network 660 may be a local area network or a private network (including a virtual private network (VPN)).

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

[0071] In an example, the server 602 may use a client-server technology architecture that is dedicated to receiving and providing updates to clients (e.g., not necessarily dependent on rendering 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 may send and receive data packets to and from the server 602 without having to communicate directly with other clients. While other types of network architectures may be used in an example, 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 an exemplary embodiment, such other networking architectures may be used depending on the needs of the application. Client 610

[0072] Each of the clients 610a-610n (generally referred to herein as clients 610) 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. 13. 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. 6, each client 610 runs a different instance of a game program 650 on a corresponding computing device. The game program 650 (e.g., an executable file, e.g., .exe) may be stored in a memory device 1314 (e.g., a non-volatile storage device) 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.

[0073] Each client 610 processes input provided by a user, for example, via an input device 1314 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 of how an object has been controlled or modified) may then be communicated to the server system 600. In other examples, the input may be communicated to the server 602, which may then take action based on the input.

[0074] In some examples, each client that is part of the system 600 corresponds to a different player in a multiplayer game. In some examples, however, 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 1314, 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 are then used to update the vehicles associated with those respective players, and the updates to those vehicles may then be communicated to a server system, as discussed elsewhere herein.

[0075] 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 be executed on the same computing device. As an illustrative example, a computer may execute two instances of the game program 650. 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 that controls a corresponding vehicle that is being processed by such cloud-based streaming service. Server 602

[0076] The server system 602 may be comprised of one or more of the computing devices 1300. The server system 602 may be responsible for assigning players to instances of a multiplayer video game, running / executing each instance, providing post-race functionality, and other aspects as needed. The server system 602 includes a lobby module 604 and a race module 606 for performing this and other functionality related to the multiplayer video game.

[0077] The lobby module 604 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 further detail in connection with FIG.

[0078] Each new instance of a race in the multiplayer video game may be handled via the race module 606. The race module 606 is responsible for running the races and handling communication with the clients 610 participating in a given race. For example, the race module 606 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 606 may include functionality for controlling NPC vehicles. In some examples, the race module 606 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 606. This may, for example, allow multiple different races to be run simultaneously, thus allowing thousands or more users to participate across many different races that may be running simultaneously (but separately from each other) on the server 602.

[0079] The server system 602 also includes or communicates with a player database (PLAYER DB) 608. The player database 608 stores skill ratings for each player and other game result data for players participating in the multiplayer game. In some examples, the information in the player database 608 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 (at 1212) based on the results of each race. This is discussed in connection with FIG. 7 and FIG. 12. Additional details regarding the processing performed by the server are provided in connection with FIG. 10. Description of Figure 7: Setup process

[0080] FIG. 7 is a signal diagram illustrating the setup of an exemplary instance of the multiplayer video game shown in FIG. 1 and how communications occur between a client 610 and a server 602 in connection with such a setup, according to an exemplary embodiment.

[0081] At 700, the server 602 generates a lobby that allows the server 602 to accept connection or join requests from the clients 610. This may include, for example, generating a specific lobby identifier (e.g., a GUID), etc. In some examples, each instance of a lobby may maintain or store a data structure of players added to that lobby. For example, a list of player IDs may be associated with each generated lobby identifier. In some examples, IP addresses or other connection information may also be stored in association with each player located in the lobby. In some examples, different lobbies may be created for different geographic locations. For example, one lobby is for users connecting from North America and another lobby is for users connecting from Europe. In some examples, there may be different lobbies generated for different game types. For example, one lobby is for a Grand Prix and another is for single races.

[0082] At 702, the client processes a command from a user to join or to search for an instance of a multiplayer game that the user can participate in. The processing at 702 may be performed after launching a game program, or may be performed by a dedicated game search process or the like.

[0083] At 704, the client communicates a data message including a join request message to the server 602. The join request message may include information about the client, player, or computing device associated with the join request. For example, the join request message may include a player ID, etc.

[0084] Once the join request message from 704 is received by the server 602, the server then processes the message and assigns the request (or a player associated therewith, etc.) to a lobby at 706. In some examples, if a lobby is not available, a new lobby may be created (e.g., via 700). In some examples, the received requests may be separated based on, for example, geographic location, etc. As noted above, there may be different geographically specific lobbies. In such cases, requests may be assigned to the associated geographic location. In other examples, all requests or lobbies are treated regardless of geographic location.

[0085] Once a player has been assigned to a lobby, a notification message is sent back to the client 610 with information about the lobby, which may include the total number of players in the lobby and the expected wait time.

[0086] The process of allocating received requests continues at 708 as new requests are received and the new requests are assigned to the corresponding lobbies. Note that during this time, clients assigned to the lobby may wait for the game to start and may receive updates from the server 602 regarding the status of the lobby. During this process, animations or videos may be displayed to the user. In some examples, the process of filling the lobby may also provide the user with a warm-up option (e.g., to practice controlling their vehicle or selecting a vehicle to play).

[0087] Once it is determined at 708 that the lobby is full (e.g., the number of players reaches a given threshold, e.g., 100, or the lobby has been waiting for more than a threshold amount of time, e.g., 1 or 5 minutes), the server spawns a new game instance at 710. Spawning a new game instance may include tasking a virtual machine or the like to start a new multiplayer game. In some examples, this may include sending a command to a compute node of the server 602 to start the new game instance. This command may include a list of players (and their connection data) who will be joining the new game instance.

[0088] In an exemplary embodiment, the lobby process may include the additional processing of adding server-controlled vehicles (e.g., artificial intelligence (AI) or NPC vehicles) to the lobby. This may be accomplished to help fill up lobbies more quickly.

[0089] In some examples, there may be multiple different types of AI vehicles that can be added. These different types may correspond to different difficulty levels, etc. For example, a first type of AI vehicle may perform extremely well in a race (e.g., run the race with high efficiency and without many or any mistakes), while another type may be designed to perform less well in a race. In some examples, the AI ​​vehicles added to a lobby may be distributed into different difficulty levels (e.g., three, four, or five different difficulty levels). In some examples, as more space in the lobby is filled with AI vehicles, the average difficulty level of the AI ​​increases (e.g., a higher percentage of AI vehicles may be the most difficult).

[0090] In some examples, when an AI vehicle is added to a lobby, it is assigned a skill parameter, the value of which may be based on the AI's difficulty level (e.g., 1-5) and a randomized value within a range tied to that selected difficulty level.

[0091] At 712, the server communicates with (or establishes a connection with) the client to establish a connection from the server's computing node or other processing resource handling the game processing to the client. This may include, for example, communicating to each of the clients the IP address of the node hosting the server and any other connection or game initialization properties. It is appreciated that the communication occurring at 712 may include multiple data messages communicated from the client 610 to the server 602 and / or from the server 602 to the client 610.

[0092] Once the connection information is provided to the client at 712, the client 610 starts or loads into an instance of the multiplayer game at 716 (e.g., based on execution of instructions that are part of the game program 650). For example, graphical assets for the race (e.g., textures for the race track, vehicles in the race, etc.) may be loaded. In some examples, this may include starting a new computer process or thread separate from the lobby or joining process. In some examples, the client 610 may continue to communicate with the server 602 once the game load occurs. For example, information of other players may be communicated once the game is loaded.

[0093] An example of another piece of information that may be communicated during loading may be communication of a selected rival. At 714, a rival for each player in the game is selected or otherwise generated. This aspect is discussed in more detail in connection with FIG. 12. In some examples, the selection of a rival may occur as part of the lobby phase (e.g., once the lobby is filled at 708), while in other examples, the selection of a rival may occur when the game instance is created (e.g., at 710).

[0094] Once the game process is loaded on a given client, the client then communicates a ready message to the server at 718. The ready messages from the various clients that are part of the game may be collected by the server 602. In some examples, a timeout may be used, such that if a ready message is not received from a client by, for example, 15 seconds (or other threshold amount) after communication to the client at 712 (or other time a timer may start against the threshold), the corresponding client is automatically removed from the race. In such an event, a disconnect message or the like may be communicated from the server to that client.

[0095] At 720, the server 602 determines that the game should begin. At 722, the server 602 communicates a game start message to each client 610 in the game.

[0096] At 724, each client 610 receives the game start message and then begins the game (e.g., by executing instructions of the game program 650). In some examples, the "start" message may trigger the beginning of a countdown (e.g., 3-2-1, etc.) that is displayed to the user on a display coupled to the computing device. Each user may then control their own vehicle in the race. Further details of the race process are discussed, for example, in Figures 8-10 and elsewhere herein. Description of Figure 8: Game Processing

[0097] FIG. 8 is a signal diagram illustrating communications between a client 610 and a server 602 during the execution of the multiplayer video game shown in FIG. 1, according to an example embodiment.

[0098] When the multiplayer video game is started, each client 610 runs a copy of the game program 650. The server 602 also runs its own version of the multiplayer game. Each running instance is a simulation of the multiplayer video game. During the game, messages are communicated from each client to the server and from the server to each client. These messages are used to update each game instance regarding changes, for example, in how a vehicle is being controlled by the user or how other vehicles have been controlled by other users. As an illustrative example, a given client 610 may communicate information regarding the speed and position of a vehicle being controlled by the user to the server 602. 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 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 this is the creation of an energy object or the acquisition of such an object.

[0099] 8, the server 602 executes a multiplayer game location simulation at 800, and each client 610 also executes a local simulation of the multiplayer game at 802. 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. 10, and further details of the simulation performed on the clients are discussed in FIG. 9.

[0100] In some examples, execution of server processing is based on messages received from clients and any local processing performed on the server to control non-player objects (including determining how to control an AI player).

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

[0102] Messages communicated (at 804) from the server 602 to the client 610 and / or (at 806) from the client 610 to the server 602 may involve periodic updates (e.g., occurring once every X frames the simulation is updated or other time period) and / or updates triggered by events or other triggering actions. Thus, different actions or triggers (time, actions within a race, input from a user, etc.) may be used to cause messages to be communicated between the server 602 and the client 610. In some examples, messages are communicated from the client to the server every frame (e.g., each frame the client transmits and updates). 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, significant 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 transfers to a second track. Such updates may be sent between periodic updates communicated from the server.

[0103] Messages communicated between the client and the server may include different types of data. As non-limiting examples, they may transmit values ​​of parameters, may transmit movement and / or position data (e.g., of a vehicle), may transmit data regarding commands entered by a user (e.g., a button is being pressed or has been pressed), the status of a race (e.g., a player's ranking in a race), and other types of data such as important events that have occurred (e.g., when a vehicle transitions between tracks in a game). In some cases, data is transmitted periodically (e.g., every X frames, such as every other frame, every tenth frame, or every sixth frame, or at other rates such as every ms, every 5ms, every 10ms, or every 30ms). In some cases, data messages are transmitted on an on-demand basis. For example, when an important event occurs for the vehicle 102 (e.g., activation of a special power, etc.), a data message regarding such trigger occurrence may be transmitted. As another example, when the vehicle 102 collides with another object (e.g., another player-controlled object or a non-player-controlled object) in a multiplayer game, a data message regarding the collision may be sent to a server computer system for processing.

[0104] Returning to FIG. 8, and more specifically, processing of each local and server simulation continues until the race is completed at 808. Once the race is completed, the server may update player information for each player who participated in the race (e.g., as discussed in FIG. 12). 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.

[0105] At 812, the results of the race are communicated to each of the clients 610. These results may then be displayed to the users on their respective computing devices at 814. The results may include the player who finished the race in first place, the relative positioning of the client's current user's rivals, and any updates to the players' rankings (e.g., based on the user's positioning relative to the user's rivals). Data on the users' new or updated rankings may also be included. Description of Figure 9: Client Processing

[0106] FIG. 9 is a flowchart of a process (such as that shown at 802 in FIG. 8) that may be executed on a computing device that is a client in the multiplayer video game shown in FIG. 1, according to an example embodiment.

[0107] Each client or each computing device that a user is using to participate in a multiplayer video may operate the process shown in FIG. 9. The process shown in FIG. 9 may be performed based on the execution of computer instructions that are part of a game program 650 that is executing on the corresponding computing device. And, as discussed in more detail below, the process shown in FIG. 9 can (and does in some exemplary embodiments) 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 FIG. 9 occurs is 24, 30, or 60 times per second. In some exemplary embodiments, other rates, whether fixed or variable, may also be implemented.

[0108] Once a race has begun, race processing 900 occurs.

[0109] 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.

[0110] According to an example embodiment, different types of inputs 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 another example, the input provided does not need to be stored past its use in the current execution frame.

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

[0112] In an exemplary embodiment, triggering the second track at 920 may occur automatically once a special ability is satisfied 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 trigger conditions (e.g., speed, location in the race, etc.) may be used to control or automatically trigger the special ability.

[0113] 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 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.

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

[0115] At 906, the data (e.g., packets) may be sent to the server 602 for processing. The 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.

[0116] 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.

[0117] 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."

[0118] 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, generation of energy objects by such non-player vehicles may also be triggered, as discussed elsewhere herein. In some examples, data received from the 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 the server 602. However, the movement of that vehicle may be controlled via a local simulation (e.g., server 602 may not provide instructions on how to move the non-player vehicle).

[0119] In an exemplary embodiment, the treatment of an NPC may differ among various clients participating in the same multiplayer game. As an example, the "same" NPC may be present 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 the NPC may be the same across various clients. However, in other examples, the location of the NPC on each client may be treated independently. The 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 exemplary 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 (e.g., based on) where that client's vehicle 102 is in 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 player-controlled object's client's local simulation may be one every five seconds. In contrast, the same NPC being simulated on another client of 50th place player-controlled object may have a drop rate of 1 energy object per second. Thus, the drop rate of the energy object by the 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 the vehicle, the lower the drop rate of that vehicle in the local simulation.

[0120] In some examples, various other kinds 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 entirely (or largely) controlled within the local simulation are discussed below in connection with 924, 926 and elsewhere herein.

[0121] In some instances, 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 the client and then the server communicating those updates to the client, the server itself generates position / status data for those NPC participating vehicles and then communicates such data to the client.

[0122] 9 more specifically, 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 has occurred (at 908) to update any NPC objects, 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).

[0123] In some examples, updating the positions of the objects may include calculating the positions where those objects should be located by performing interpolation based on the received data. In particular, 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 only every third frame, every sixth frame, etc.). Thus, interpolation may be used to infer 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 the actions of one vehicle from a first computing device through the server to another computing device. The delay may be 100 ms or more between the two computing devices. Thus, in one example, the data received from the server may be processed using an interpolation algorithm or the like to provide a better "guess" as to where the vehicles of other objects will be located in the virtual game space.

[0124] In any event, the local game state of the locally executing instance of game program 650 is updated, for example, to update the positions of vehicles and other objects in the virtual game space.

[0125] Once the positions of the objects in the virtual game space have been updated, collision detection processing may then occur at 912. This may involve determining when two (or more) vehicles (or other objects) have collided with one another within 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.

[0126] An illustrative example of a resulting collision when vehicles 106 and 108 collide with one another is shown in Figure 2. The collision may be determined by updates (or based on interpolation) received from server 602. Once movement-related data for vehicles 106 and 108 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 Figure 1 to that shown in Figure 2 (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.

[0127] 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 collides with a barrier or the like.

[0128] If a collision between two other player vehicles is detected, the local simulation may handle such collision internally. However, if the collision involves a player-controlled object 102, the health of the tracked object (as shown at 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. In contrast, the health of the 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 tracked health of those vehicles within the simulation. Rather, health values ​​may be updated and controlled based on messages received from the server 602. In other words, the health updates of the vehicle 102 may be controlled based on the corresponding "local" simulation of that vehicle, while the health of the other vehicles (e.g., 106 / 108) may be based on vehicle health parameters received at 904 from the server.

[0129] In some examples, the transmission of 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.

[0130] In some examples, transmission of data to the server system 602 may not occur every frame, but instead, for example, every other frame, or every fifth or sixth frame, or other intervals.

[0131] Once the game state of the game space has been updated for the current frame (which may include performing collision detection at 912), a view of the game space is rendered at 914. As shown in FIGS. 1-5 , 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.

[0132] Once the images have been generated, at 916 they are output to a display device coupled to the computing device for viewing by users playing the multiplayer video game.

[0133] Steps 902 through 916 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 a 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.

[0134] 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 602 may not (and likely will not) be received every execution frame. This may be due to latency or the rate at which the server 602 communicates updates to the clients. Similarly, data may not be sent to the server 602 every iteration. If there are no NPCs in the race, there may be no NPC processing. Generating Energy Objects926

[0135] In an example embodiment, energy objects may be generated and positioned or placed on the race track during the course of a race. The generation of energy objects is another example of additional processing that may occur based on or in response to the detection of a collision. More specifically, when a collision is detected between two (or more) vehicles (including vehicle 102), an energy object may be created and placed on the track of the current race. This is shown in FIG. 3, where an energy object 300 is generated based on the detection of a collision between 106 and 108.

[0136] It is recognized that while 106 and 108 may be determined to collide on some clients, not all clients may determine such a collision. This may be due to latency or other factors that may cause the positions of 106 and 108 to differ slightly between different simulations across various clients of a multiplayer game. Thus, differences in detected collisions may be another factor that causes the generation of energy objects to differ between different clients.

[0137] In some examples, energy objects may be associated with a timer that causes the energy object to expire (e.g., be removed from the race) if it is not picked up by the expiration time. For example, a timer may be set for each energy object that is 6 seconds, 30 seconds, or 1 minute, or some other time value.

[0138] In some examples, each local simulation may limit the number of energy objects that may be placed on the track at any one time. In one example, a queue (or other data structure, such as a circular or ring buffer) stored in the memory device 1304) may be used to store details of valid energy objects in a race. Thus, as a new energy object is created, it is added to the data structure. If the data structure becomes full, then the oldest energy object is removed (or overwritten) from the data structure and then correspondingly deleted from the race track (e.g., even if the energy object's timer has not expired). In an exemplary embodiment, each local simulation may limit the number of energy objects that may be placed within a radius (or other distance) of the vehicle 102. This may be used in place of a global limit as discussed above.

[0139] In one example, while energy objects are positioned on tracks and parts of a multiplayer game, their presence is not communicated to the server. For example, if vehicles 106 and 108 collide on one client, the collision is not communicated to the server (which does not then communicate the collision to all other clients). Similarly, the generation of the energy object created from the collision is not communicated to the server (which does not then communicate the presence of the energy object at that location to other clients). Instead, each client may be independently responsible for 1) determining collisions between vehicles and 2) generating energy objects from such collisions. An exception to the determination of a collision is when a collision between vehicle 102 and another vehicle reduces the health of one of the vehicles below zero. In this case, the server may act as an arbitrator to determine whether a collision has occurred or not.

[0140] In one exemplary embodiment, the energy objects are stationary and do not move when positioned on the track, hi one exemplary embodiment, some (or all) of the energy objects may move (e.g., similar to how a ball may roll).

[0141] In an example embodiment (and as discussed above), the energy object may be generated via other techniques. As noted above, an NPC may periodically create an energy object. Thus, in an example, the energy object may be generated without first determining that a collision has occurred. In an example embodiment, the energy object may be generated at the location where the vehicle warps or moves to / from the second track. In other words, as the vehicle moves from the first track to the second track, the energy object may be positioned at that location.

[0142] In some examples, when a vehicle crashes out (e.g., the vehicle's health goes to 0), an energy object is positioned at (or based on) the location of the crash in the game. In some examples, collisions with NPC controlled objects may generate energy objects. As one example, an NPC object that periodically drops energy objects may also drop such objects based on a determination of a collision between the vehicle and the NPC object.

[0143] As discussed below, in some examples, the process for the generation of energy objects may also occur in a server-run simulation. In some examples, the same conditions may be used for the generation of energy objects on the server versus the client. In other examples, different conditions may be used to determine how / when the energy objects should be generated. Acquiring Energy Objects924

[0144] As energy objects 150 are created and positioned on tracks within the multiplayer video game, vehicles may also pick up those energy objects and use them to charge or increase special ability meters 114. As with the creation of energy objects, the acquisition of energy objects may be an entirely client simulation process that is not controlled or managed by a server. In other words, each client may be responsible for determining which objects within its simulation will acquire the energy objects created for that simulation.

[0145] At 924, as part of or in conjunction with updating the game state at 910, a determination may occur of when the vehicle can / has picked up the energy object.

[0146] In one example embodiment, each vehicle in the race is assigned a collection threshold parameter that corresponds to how far from the vehicle (or its center of gravity) an energy object in the virtual game space can be captured or otherwise picked up by that vehicle. In one example, this value may be expressed as a radius from the center of gravity of the vehicle, or may be provided as a bounding box, or the like. If the energy object is within this threshold, processing at 924 collects the energy object and adds a value to a special ability meter.

[0147] In some examples, the value may be fixed, dynamic, or a combination of both. In some examples, the value given to an energy object when it is picked up by a vehicle may vary based on one or more factors. The following are illustrative examples of such variations: By default, an energy object may have a value of 10. However, the value may be modified based on a decay rate based on how recently that vehicle's energy object was picked up. So, for example, a new energy object may only be worth 75% of the value of the previous energy object. In some examples, a decrease in the value of the picked up energy object may occur if multiple energy objects are picked up by the vehicle 102 in quick succession.

[0148] In one example embodiment, the value of the energy object may be based on the amount of health lost by the vehicles involved in the crash that created the energy object - in other words, the more severe or violent the crash (and the greater the corresponding loss of vehicle health), the greater the value of the energy object created from that crash.

[0149] In some instances, energy objects created by collisions may have a different default value (or values) than those dropped by NPC vehicles. For example, an energy object created by an NPC may have a default value of 5 compared to a default value of 10 for an energy object created based on 926.

[0150] In some examples, the value of the energy object may be modified based on the current positioning of the vehicle 102 in the race. For example, a first place vehicle may only get 50% of the default value, a 50th place vehicle may get 100%, a 90th place vehicle may get 150%, and so on.

[0151] As part of each client simulation during a game state update, it is determined whether any of the vehicles are within capture range to capture the energy object. This determination may be made for all player vehicles in a race. However, for other player vehicles in a given running location simulation, the capture of the energy object merely removes the object from the course and does not modify that vehicle's special ability meter. Rather, the special ability meter only increases if the local vehicle (vehicle 102) captures the energy object. In this approach, the energy object is removed from the local simulation as updates are provided to control other player vehicles on the track.

[0152] By using the techniques described herein, it is recognized that the individual simulations (e.g., each instance of the process shown in FIG. 9) running across various clients may be different, even though each client is part of the "same" multiplayer game. Thus, in one example, a goal of a technique herein may be to not completely synchronize every aspect of a multiplayer game across dozens or hundreds of different simulations running across various clients participating in the same game. As an example, an NPC may generate 100 energy objects in one simulation for one client, but only 10 energy objects for another simulation for another client (e.g., because the first place player controlled object is positioned higher). Similarly, the distribution of energy objects in different simulations may differ due to other player vehicles "capturing" the energy objects during the simulation (e.g., not available when the vehicles approach the location of the collision). Thus, the acquisition of such objects may differ (perhaps significantly) across different simulations running as part of a multiplayer game.

[0153] This type of approach advantageously provides for not transmitting data regarding certain events (such as the generation / acquisition of energy objects, etc.) over the network. Instead, the handling of such events can be self-contained within each locale simulation, without the need to transmit data regarding such events between various clients. Furthermore, this approach advantageously allows different gameplay (such as different drop rates of energy objects) to be generated between various clients participating in the same multiplayer video game.

[0154] In an exemplary embodiment, the acquisition of an energy object may increase the health of the vehicle. In an example, if the meter is full and / or the parameter cannot be increased any further, any additional energy object acquired may be used to increase the health parameter of the vehicle. In an exemplary embodiment, the acquisition of an energy object may increase the speed of the vehicle. In an example, if the meter is full and / or the parameter cannot be increased any further, any additional energy object acquired may be used to increase the maximum speed or provide a temporary speed increase. For example, each energy object acquired may temporarily increase the speed of the vehicle by 10 kph, which may be above the maximum speed otherwise set for the vehicle.

[0155] In an example embodiment, as a parameter increases, the vehicle's top speed may be correspondingly increased incrementally. As an illustrative example, when the parameter is zero, the top speed may be 500 kph. However, increasing the parameter may only increase the top speed by 10 kph (e.g., once the meter is "full"). This increase may be gradual and tied to how the parameter is increased. This causes the top speed to increase linearly, exponentially, logarithmically, or via other calculations. Thus, in an example, rewards and the like may be achieved by acquiring energy objects separate from special abilities and the like that are triggered or enabled.

[0156] In an example embodiment, when a special ability is activated, the game process may provide one or more additional ways to extend the time that the ability is active. In some examples, a collision with a vehicle (whether another race participant or a non-race NPC) may add additional time to a timer associated with the ability. Super Turbo - Rear-ending another adds extra time, while over time the meter empties.

[0157] In an example embodiment, the special ability meter and the parameters / values ​​tracked for that meter may be used as separate boosts or turbos. As noted herein, the meter 112 may be used in conjunction with a turbo boost or list provided. This may be the first turbo boost that the player may enable. The charge meter 114 may be used to enable another type of turbo only when the meter 114 is fully charged. The use or enablement of the second type of turbo may be tied to the length of a timer. Description of Figure 10: Server process

[0158] Figure 10 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 10 may be executed as part of (or by) the process shown in Figure 8, for execution of server process 800.

[0159] Once a new game instance has been created and a race is started, the process shown in FIG. 10 may take place.

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

[0161] Updates, referred to as significant event updates, may also be received from one or more clients 610. These updates relate to events occurring on the clients that are significant and are communicated outside of normal periodic updates. Examples of significant events may include 1) the activation of a special power (e.g., the vehicle has traveled or is traveling on a second track) and 2) a collision by a player-controlled object against another player object that destroys at least one of the objects involved in the collision (e.g., because the vehicle's health drops below zero).

[0162] At 1004, any NPC processing is performed by the server 602. This may include determining whether to spawn an NPC and where the NPC should be placed within the race. This information (e.g., the creation of the NPC and its location) may then be communicated to each client. The client may then handle the movement or otherwise control of the NPC without relying on updates for such control from the server. In some examples, NPC processing 1004 may include determining when to remove an NPC from the game world (and later communicating such to the client). In some examples, NPC processing 1004 may include determining how one or more NPCs, etc. should move or behave within the game space and then communicating such information to the client.

[0163] If there are AI players / vehicles in the race, NPC processing may include determining how to control the movement of the AI ​​players in the game. As noted herein, there may be different processing done for different types of difficulty levels associated with the AI. The generated commands for the AI ​​players may control how their vehicles move in a simulation maintained by the server and may also be communicated to each client.

[0164] At 1006, the simulation of the game maintained by the server computer system 602 is updated. More specifically, the server 602 maintains a game state (as do the clients) that includes position and other attribute information for each of the vehicles in the race. The processing performed at 1006 may update this game state based on data received from the clients and any other processing (e.g., regarding NPCs or other aspects in the race).

[0165] As discussed herein, the processing performed by the server may differ from the processing performed by a client (or each client). In an exemplary embodiment, the difference between the processing performed for the multiplayer game and the processing performed for the server may be the generation of energy objects. In an exemplary embodiment, the generation of energy objects is not synchronized between the client and the server. Thus, in a server-maintained simulation of the game, the server may determine collisions and generate energy objects in the same or modified manner as is done on the client. However, it is recognized that each client may still exclusively handle its own energy objects, such that the server does not "know" where such energy objects may be placed (or generated) on the track (or in the game space) for a given client. Similarly, in an exemplary embodiment, the acquisition of energy objects is exclusively handled by each respective client and is not synchronized to the server. This approach may conserve bandwidth since the server does not need to update the clients or receive information about the energy objects from the clients. Rather, according to an exemplary embodiment, the processing for these features may be pushed to or otherwise offloaded to each client.

[0166] It is recognized that the acquisition of energy objects by an AI player may be modified from those handled on the client. This may be because, if the energy objects are generated on the client, there may only be one vehicle attempting to acquire those energy objects, i.e., the vehicle controlled by the user playing the game. In contrast, if there are multiple AI vehicles, they may all be competing for the same energy objects on a simulation maintained by the server. Because of this, in one example, the value received from the acquisition of energy objects by an AI player may be increased relative to the value given to the vehicle on the client.

[0167] In one example, if an AI player is a rival of a player, the AI ​​player may automatically gain energy from an energy object if it is too far back. This may be done to make races between rival players (including the AI ​​player) closer. Conversely, if the AI ​​player is ahead of its rival, the tracking parameters may be automatically decreased for that AI player.

[0168] Another aspect that may not be tracked on the server is the state of the tracking parameters for each client (as shown on the meter 114). Rather, this value may be maintained and stored on each client. In one example, the value of the tracking parameters may be provided to the server during periodic updates. In another example, events related to the acquisition of an energy object (and / or an increase in the value of the tracking parameters) may be communicated to the server (e.g., as a significant event).

[0169] Note that while collision processing is performed by the client (e.g., at 912), such collision processing may not be performed by the server 602 as well. However, in some examples, collision processing may also be performed by the server (e.g., determining / modifying position / movement data of the vehicles involved). Such collision processing may also be used to generate energy objects, as discussed in connection with client processing. For example, the server may determine when a collision occurs and generate energy objects that may be acquired by an AI player that the server is controlling.

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

[0171] As an example, a first vehicle client may determine that the first vehicle collides with a second vehicle. However, the second vehicle client may not determine that the first vehicle collides with the second vehicle. This difference may be due to latency or other factors related to communication such as location updates. Thus, the location of the second vehicle tracked in its client may differ (and is likely to differ) from the location of the second vehicle in the first vehicle client at the same "time". In such a case, the server 602 may handle / resolve this conflict. More specifically, when the first vehicle client determines that a collision will occur that reduces the health of the second vehicle to zero, the first vehicle client may communicate a significant event regarding the collision to the server. The server 602 may then determine (e.g., at 1006) whether the location of the second vehicle is determined to be at a location in the game space where the first vehicle actually collided with the second vehicle (as determined by the server). If a collision is determined, a message may be communicated to the client of the second vehicle (and to other clients) such as that the second vehicle has been destroyed. However, if the server determines that no collision has occurred, a message may be sent back to the client of the first vehicle that no collision has occurred, and that the health of the second vehicle has not been reduced because no collision has occurred. This message may also include any updates to movement, location, or other data regarding the second vehicle. As one example of why a collision may not have occurred, the user controlling the second vehicle may have enabled a special ability (a significant event) that transports the second vehicle to the second track.

[0172] At 1008, 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 into client-side processing (e.g., as discussed in connection with FIG. 9).

[0173] In some examples, the communication of updates to the client at 1008 may be split into different types of processes for providing updates. One update provided to the client may be based on the occurrence of an "event of interest" and another update may be based on periodic updates. In some examples, data regarding the event of interest (e.g., simply that a particular vehicle has had a special ability activated) may be communicated. In some examples, data communicated for a periodic update may be included in such updates once an event of interest occurs (whether from client to server or from server to client) triggering such communication.

[0174] As with the client-side processing (e.g., at 802 and / or FIG. 9), the processing shown in FIG. 10 may occur multiple times per second. The rate at which processing occurs on the server 602 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 of the game being played. In some examples, this tick rate is the same or similar to the client's tick rate (e.g., 30 times per second), 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). Description of Figure 11: Second track processing

[0175] Figure 11 is a flow chart illustrating the processing that occurs when a player activates or moves his vehicle to a second track in a race for the multiplayer video game shown in Figure 1 and in conjunction with Figure 9, according to an exemplary embodiment. The processing shown in Figure 11 occurs in response to receiving a trigger command at 920 in Figure 9.

[0176] If the conditions for activation of the special ability are met (e.g., a special ability meter threshold is met and the player gives an activation command), processing passes via "A" in Figure 9 and the elements shown in Figure 11 are performed. At 1102, the player's vehicle 102 is transported or otherwise moved from the first track 104 to a second (e.g., different) track 404. As part of this process, a location is determined as to where on the second track to position the vehicle.

[0177] In an exemplary embodiment, the second track may be associated with or include pre-defined locations on the second track where a vehicle entering the track may be located. Once one of these locations is selected, the vehicle is placed at the corresponding location on the second track. The selection of one of these locations may be based, for example, on the vehicle's world space distance to that point when the vehicle is on the first track. In other words, the location on the second track that is closest to the vehicle's location on the first track where the special ability is enabled.

[0178] In another example, the first and second tracks may have a percentage completion stored for how far into a given track the vehicle is located. When a special ability is activated, the vehicle may be positioned at the same percentage location on the second track. So, for example, if the first and second tracks are different lengths (e.g., because the second track has fewer curves), then if the vehicle is 40% through the first track, the location may be at the 40% mark.

[0179] In one exemplary embodiment, the client makes the decision of where to place the vehicle. However, in other examples, the server 602 makes the decision of where to place the vehicle on the second track. In one exemplary embodiment, the client may first communicate that a special ability has been activated. The server receives this message and then makes the decision of where the vehicle should be positioned on the second track. The server then communicates the location to the client.

[0180] In addition to adjusting the location of the vehicle, movement-related data of the vehicle may be adjusted. As an example, the "directions" of the first and second tracks may not be parallel or overlapping. Thus, the direction of the vehicle's movement may be adjusted to center the vehicle along the centerline of the second track when the transition occurs. Note that this difference may be significant in some cases and not others. For example, if the vehicle 102 is heading toward a wall on the track in FIG. 1 and activates a special ability, the movement data of the vehicle 102 may be adjusted to avoid running into the wall on the second track. Instead, the movement parameters of the vehicle may be adjusted to match (for example) the direction shown in FIG. 4 for the vehicle 102.

[0181] At 1104, a position of the vehicle 102 in the race may be determined in conjunction with moving the vehicle 102 to the second track (e.g., warping the vehicle). For example, the position of the vehicle 102 may be 49 of 99 race positions in FIG. 1 and 7 of 99 in FIG.

[0182] At 1106, a timer is set or started using the position of the vehicle 102 in the race using the determined position of the vehicle 102 in the race. More specifically, the amount of time the vehicle is allowed to remain on the second track may be determined or otherwise calculated based on the position of the vehicle 102 in the race. As a non-limiting illustrative example, the time may be set between 2 and 15 seconds, and if there are 100 players in the race, the timer may be set as 2+13*((race position-1) / 100). Thus, the first place player's timer would be 2 seconds, the second place player's timer would be 2.13 seconds, and the 100th place player's timer would be 15 seconds. Thus, the length of the timer for how long the special ability may be valid may be a function of or otherwise based on the positioning or ranking of the player-controlled object in the race. In one example, the distance between the player-controlled object and the first place vehicle may be used to determine the length of time the special ability timer may be valid. Generally, the length of the timer value may be increased as the validating vehicle moves further down in the race.

[0183] In an exemplary embodiment, the vehicle's position (or timer length determination) may be or may be based on any or all of the following: 1) the vehicle's absolute position in the race; 2) the vehicle's relative position in the race; 3) the position in the race; 4) the distance (e.g., in the virtual game space) from where the first or leading vehicle in the race is located; 5) the vehicle's position on the track (e.g., 25% completion rate vs. 50% completion rate); 6) the vehicle's absolute position on the track (e.g., in an area of ​​the track); 7) the vehicle's finishing position in a previous race; 7) the vehicle's relative positioning to rivals in the race. In an exemplary embodiment, a combination of factors may be used to determine the position (or timer value based on position). For example, the current vehicle's rank position (e.g., 4th place) combined with the distance from the leading car or any other vehicle in the race.

[0184] In some examples, the relative positioning of the vehicle 102 with respect to rivals may be used to affect the timer length. For example, if the vehicle 102 is ahead of all four rivals, the timer may be less than if the vehicle is behind all four rivals. In some examples, the relative rival positioning (or distance to the rivals) may be used in combination with the overall positioning of the vehicle 102 in the race.

[0185] The calculated timers may be reflected in the special ability meter 114 by draining the meter from its initial full state until the meter is empty, so that the meter 114 drains more quickly for shorter timers and over a longer period for longer timers.

[0186] In some examples, the timer is set once the vehicle enters the second track. Alternatively, in some examples, the timer may be adjusted while the vehicle is on the second track. For example, if the vehicle manages to overtake all other vehicles and take first place (for example), the timer may decrement more quickly. Thus, the timer value may be adjusted based on the vehicle's updated race position data as it moves through the second track.

[0187] Once the vehicle is positioned on the second track and the timer is enabled, the race process 900 occurs (e.g., at a rate of 30 frames per second, or at other rate as designed). More specifically, updates are sent and received, game data is updated, and images are displayed, as described in connection with FIG.

[0188] As noted herein, one or more attributes of the second track may differ from the first track and / or vehicle parameters may be adjusted. The second track may have more speed-up features 410 (which increase the upper limit of the vehicle's speed, such as on a straight track) than are present on the first track. The second track may allow the vehicle to travel at a higher speed. In some examples, the vehicle may not be damaged (e.g., become invincible) or receive a health resurrection on the second track. In some examples, energy objects may not be generated or acquired on the second track and / or collisions may not occur.

[0189] Once the race process 900 is performed, the process continually checks whether the timer for the second track, started at 1106, has expired at 1108. If the timer continues, the race process on the second track may continue.

[0190] When the timer is about to expire (or has expired), a graphical notification may be displayed on the client, which may include blinking or changing color of the second runway, etc.

[0191] However, if the timer expires, the process determines whether the vehicle is in a location that allows for a valid return to the first run. More specifically, like the second run, the first run may have one or more predefined entry locations. If the vehicle is in an invalid location (e.g., on the second run or on the first run) such that the location of the vehicle on the second run is not close enough (e.g., not within a threshold) to the entry location of the first run, the vehicle may remain on the second run until the location is reached. In some examples, a valid transition point back to the first run may be when the second run overlaps with the first run. In other words, a transition back to the first run may only occur if the first run is "under" the second run (e.g., in the game space).

[0192] Thus, there may be two (or more) conditions for triggering the exit of the vehicle from the second lane: 1) expiration of a timer; 2) the location of the vehicle on the second lane; and / or 3) a predicted entry location onto the first lane (e.g., the existence of a valid location on the first lane).

[0193] If there is a valid exit location back to the first leg, the process determines 1112 where to return (e.g., warp) the vehicle to the first leg, and then transitions 1114 the vehicle back to the first leg.

[0194] The positioning of the vehicle on the first track may take into account any vehicles already on the track. For example, the location to which the vehicle is moved is not the same as the location of another vehicle (e.g., to avoid the two colliding). The location on the first track that is selected may be adjusted / calculated to avoid crashing the vehicle immediately after returning to the first track.

[0195] 11 relates to traveling between a first and a second runway, but may also be applied to traveling between more than two runs. For example, a user may select which of two alternative runs to use, of which the second runway may be one.

[0196] In other examples, activation of a special ability may enable the vehicle to fly over a first track, and thus the "second" track may instead enable the vehicle to fly around the first track.

[0197] In an exemplary embodiment, the techniques herein may be used in games and virtual spaces that do not include tracks (or paths, courses, etc.). As an illustrative example, a racing game may include a start location and an end location, with no tracks or the like between the two. Such a racing game may allow players to find their own path between the two without necessarily following a path from start to finish. An illustrative example may be a game that models a race between New York (start) and Los Angeles (finish). This type of gameplay may allow more free-form movement of vehicles between the start and finish. In one game instance, most game players may take the southern path; in another, the northern path; and in another, they may split into various routes to reach Los Angeles. In this type of gameplay, the use of a "second" track herein may still be provided. The second track may still have a prescribed path that vehicles must follow, similar to track 404. In other examples, the second track may similarly allow free-form movement of vehicles and still provide the rewards herein. Description of Figure 12: Rival processing

[0198] 12 is a flow chart illustrating the process that occurs for the multiplayer video game shown in FIG 1 regarding how rivals are selected and how player information is updated based on the results of a race, according to an exemplary embodiment. The process shown in FIG 12 may be performed by server 602 in an exemplary embodiment.

[0199] At 1202 (which may correspond to 714 in FIG. 7), a rival is determined for each player participating in the race. Selection for each player may occur once the lobby is filled (708) and a game instance is created for that lobby (710). Selection of rivals for the race may depend on or be based on rank or skill parameters stored in the player DB 608.

[0200] In an illustrative embodiment, four rivals may be selected for each player participating in a race. The selection of the four rivals may include selecting two rivals with a higher ranking than the player (e.g., the users with the two rankings immediately above) and two rivals with a lower ranking than the player (e.g., the users with the two rankings immediately below). If there are no or insufficient lower / higher ranked players (e.g., because the player for whom the rivals are selected is the highest / lowest ranked player in the race), additional lower / higher ranked players may be selected. As an illustrative example, the highest ranked player in a race may have rivals who are the players ranked 2nd, 3rd, 4th, and 5th in the race. Similarly, a player ranked 100th (out of 100 players in a race) may have players ranked 96th, 97th, 98th, and 99th as rivals.

[0201] Determining the rivals may include sorting the players into a sorted list based on each player's skill rating before the start of the race. For example, if 100 players are participating in a race, the players may be sorted based on skill ratings obtained from the player DB 608. Once sorted, the rivals are selected. In some examples, a sliding window approach may be used to select rivals for each player. The window may include five different players in the sorted list (the middle player is the player for whom a rival is selected). This approach ensures that most players have a different group of rivals to compete with than the other players (excluding players 1-3 and the bottom three ranked players if four rivals per player are selected).

[0202] In an example embodiment, AI players and their respective vehicles may be included in the rival selection process. In such cases, the assigned values ​​of the AI ​​players' skill parameters may be used in connection with sorting the AI ​​players into a list. Thus, in an example, a player's rivals may include server-controlled AI players. In an example embodiment, an AI player may be excluded or deprioritized in connection with the selection of a player's rivals.

[0203] Although the above example describes selecting four rivals per player, other amounts of rivals may be used. In an exemplary embodiment, one rival is selected per player. In an exemplary embodiment, different numbers of rivals may be selected for different players. For example, the highest ranked player may have five rivals selected for that player, while the lowest ranked player in the race may have two (or one).

[0204] In an example embodiment, the rival information may change during the course of a race. For example, if a race around a track includes four laps around the track, new rivals may be generated for each lap (or every other lap). As an example, when a player completes a lap, the process may select four new rivals that are selected based on the player's current position in the race.

[0205] In one example, if a first player drops out of a race (e.g., disconnects or is otherwise removed from the race), a replacement rival may be automatically selected for any players who had the first player as a rival. This selection may be based on the skill ratings of the remaining players, the current player's position in the race, or a combination thereof. In one example, if a rival is removed mid-race, no replacement is selected. Instead, if player A disconnects, player A may finish last in any rival group for any other player.

[0206] In some examples, a multiplayer video game may involve a racing circuit (e.g., a Grand Prix) that occurs over the course of multiple consecutive races. For example, four different races may take place in one circuit competition. In this mode, rivals may be selected based on skill evaluation in a first race, but then based on their current position on the circuit (e.g., overall ranking within that circuit) and / or their position in a previous race for that circuit.

[0207] As an illustrative example, a player (called "Player A" in this example) who is in first place and rated 25th (by skill rating) may have rivals as rivals to the first place, who are skill-rated players rated 23rd, 24th, 26th, and 27th. Player A then finishes 10th in the first race of a four-race circuit. In the second race, Player A's rivals are set as the players who finished 8th, 9th, 11th, and 12th in the first race. Thus, the player's skill rating is used to select rivals in the first race, but the results of the first race are used to select rivals for the second race. Player A then finishes 15th in the second race and is rated 8th overall for the four-race circuit (e.g., this may be based on cumulative times for races 1 and 2). For the third race, rivals are selected similarly to the second race. Then, for the third race, Player A finishes in eighth place, this time rated fourth overall in the circuit. For the fourth and final race of the circuit, rivals may be selected based on overall circuit ranking (rather than simply the results of the third race). Thus, in some instances, different options for selecting rivals for a given race may be used. In some instances, the same technique for selecting rivals (e.g., skill rating, previous positioning, overall positioning, etc.) may be used in all races.

[0208] In one example embodiment, the group including the player and his / her rivals may be unique within the race (excluding the highest and lowest ranked users).

[0209] Once a player's rivals have been selected, at 1204, information regarding the player's selected rivals is communicated to each client associated with that player.

[0210] At 1206, race processing occurs, which may correspond to the processing discussed in connection with Figure 10 (at the server 602) and / or in Figure 9 (at the client 610). As shown in Figure 5, information about rivals may be displayed to the player in different ways. This includes having different icons identifying the rivals' vehicles, having a mini-scoreboard 510 that includes the current player's rivals, and showing the rivals on the mini-map in different ways.

[0211] Once the race is completed, the results of the race are obtained at 1208.

[0212] At 1210, the server calculates a skill rating adjustment based on each player's relative positioning to the selected rival. At 1212, the calculated skill adjustment is used to update the player's skill rating, which is then stored in the player DB 608. In some cases, the calculation may result in an increase in the player's skill rating. In some cases, the calculation may result in a decrease in the player's skill rating. And in other cases, the calculation may result in no change to the player's skill rating (e.g., the update to the player's skill rating may be 0 and / or no change).

[0213] In an example embodiment, the calculation of the skill rating adjustment may use a skill algorithm such as Elo, Glicko, or Glicko2 (or modifications thereof). The rating adjustment may be designed to increase a player's skill rating when the player finishes a race ahead of at least one of his rivals, with the skill rating further increased based on how many rivals the player finishes ahead of. If the player does not finish a race ahead of any of his rivals, the corresponding skill rating may be decreased.

[0214] At 1214, the results of the skill assessment adjustment may be communicated to the client, which may include the new skill assessment and the amount of the adjustment (whether increased or decreased).

[0215] In an example embodiment, an experience value may also be calculated for each user. The experience gained from a race may be based on the player's overall placement in the race, their placement relative to their rivals, or both. Experience parameters may also be stored as part of the player DB 608.

[0216] This technique for selecting rivals allows a player to compete against a smaller subset of competitors in a race (which may in some cases include one or more NPC-controlled vehicles), and thus may provide an increased experience for a player in a race, as opposed to simply competing against dozens or hundreds of different competitors. Description of FIG. 13: An exemplary computing device

[0217] FIG. 13 is a block diagram of an exemplary computing device 1300 (which may also be referred to as, e.g., a “computing device,” “computer system,” or “computing system”) according to some embodiments. In some embodiments, the computing device 1300 includes one or more processors 1302 (which may be referred to as “hardware processors,” or individually as a “hardware processor”), one or more memory devices 1304, one or more network interface devices 1306, one or more display interfaces 1308, and one or more user input adaptors 1310. Additionally, in some embodiments, the computing device 1300 is connected to or includes a display device 1312. As described below, these elements (e.g., the processor 1302, the memory device 1304, the network interface device 1306, the display interface 1308, the user input adaptor 1310, the display device 1312) are hardware devices (e.g., electronic circuits or combinations of circuits) configured to perform various different functions for the computing device 1300. In some embodiments, these components of computing device 1300 may collectively be referred to as computing resources (e.g., resources used to perform instruction execution and including processors (one or more processors 1302), storage (one or more memory devices 1304), and I / O (resources including network interface devices 1306, one or more display interfaces 1308, and one or more user input adapters 1310)). In some instances, the term processing resources may be used interchangeably with the term computing resources. In some embodiments, multiple instances of computing device 1300 may be disposed in a distributed computing system.

[0218] In some embodiments, each or any of the processors 1302 is or includes, for example, a single-core or multi-core processor, a microprocessor (e.g., sometimes 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 including a CPU and other hardware components such as memory, networking interfaces, etc.). And / or, in some embodiments, each or any of the processors 1302 uses an instruction set architecture such as x86 or advanced RISC machine (ARM). In some embodiments, each or any of the processors 1302 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 1302 may be referred to as a processing system.

[0219] In some embodiments, each or any of the memory devices 1304 is or includes a 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 type of device that performs volatile or non-volatile storage of data and / or instructions (e.g., software executed on or by the processor 1302). The memory devices 1304 are examples of non-transitory computer-readable storage devices.

[0220] In some embodiments, each or any of the network interface devices 1306 includes one or more circuits (such as a baseband processor and / or a wired or wireless transceiver) to implement 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-range, medium-range, and / or long-range wireless communication technologies). The 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 to transmit and receive. 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.

[0221] 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, the network interface device 1306 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.

[0222] In some embodiments, each or any of the display interfaces 1308 is or includes one or more circuits that receive data from the processors 1302, generate corresponding image data based on the received data (e.g., via a discrete GPU, an integrated GPU, a CPU performing graphical processing, etc.), and / or output the generated image data to a display device 1312 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 1308 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 1308 may include a processor therein that is used to generate image data. The generation or such images may be performed in conjunction with processing performed by one or more of the processors 1302.

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

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

[0225] In some embodiments, each or any of the input devices 1314 is or includes a mechanical and / or electronic device that generates a signal provided to the user input adaptor 1310 in response to a physical phenomenon. Examples of input devices 1314 include, for example, a keyboard, a mouse, a trackpad, a touch screen, a button, a joystick, a sensor (e.g., an acceleration sensor, a gyro sensor, a temperature sensor, etc.). In some examples, one or more of the input devices 1314 generate a signal 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 1314 is a component of a computing device (e.g., a button provided on a housing that includes the processor 1302, the memory device 1304, the network interface device 1306, the display interface 1308, the user input adaptor 1310, etc.).

[0226] In some embodiments, each or any of the external devices 1316 includes additional computing devices (e.g., other instances of computing device 1300) that communicate with computing device 1300. 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 1300. In general, external devices 1316 may include devices that communicate (e.g., electronically) with computing device 1300. As an example, computing device 1300 may be a gaming device that communicates with a server computer system, which is an example of external device 1316, over the Internet. Conversely, computing device 1300 may be a server computer system that communicates with a gaming device, which is an example external device 1316.

[0227] In various embodiments, the computing device 1300 includes one, or two, or three, four, or more of each or any of the above-mentioned elements (e.g., the processor 1302, the memory device 1304, the network interface device 1306, the display interface 1308, and the user input adapter 1310). Alternatively or additionally, in some embodiments, the computing device 1300 includes one or more of a processing system including the processor 1302, a memory or storage system including the memory device 1304, and a network interface system including the network interface device 1306. Alternatively or additionally, in some embodiments, the computing device 1300 includes a system-on-chip (SoC) or multiple SoCs, where each or any of the above-mentioned elements (or various combinations or subsets thereof) are included in a single SoC or distributed across multiple SoCs in various combinations. For example, a single SoC (or multiple SoCs) may include the processor 1302 and the network interface device 1306. Alternatively, a single SoC (or multiple SoCs) may include the processor 1302, the network interface unit 1306, and the memory device 1304, etc.

[0228] The computing device 1300 may, in some embodiments, be arranged such that the processor 1302 includes a multi- or single-core processor, the network interface device 1306 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 the memory device 1304 includes RAM, flash memory, or a hard disk. As another example, the computing device 1300 may be arranged such that the processor 1302 includes two, three, four, five, or more multi-core processors, the network interface device 1306 includes a first network interface device implementing Ethernet and a second network interface device implementing WiFi and / or Bluetooth, and the memory device 1304 includes RAM and flash memory or a hard disk.

[0229] As previously noted, whenever a software module or process is described herein as performing any action, the action is actually performed by the underlying hardware elements according to instructions provided by the software module. Consistent with the above, in various embodiments, each or any combination of the clients 610 (610a-610n), server system 602, game program 650, lobby module 604, race module 606, etc., are implemented using the example computing device 1300 of FIG. 13, although for clarity, the remainder of this paragraph will refer to each individually as a "component." In such an embodiment, the following applies to each component: (a) the elements of the computing device 1300 shown in FIG. 13 (i.e., one or more processors 1302, one or more memory devices 1304, one or more network interface devices 1306, one or more display interfaces 1308, and one or more user input adapters 1310), or a suitable combination or subset of the above, with or without one or more display devices 1312, one or more input devices 1314, and / or external devices 1316, are configured, adapted, and / or programmed to implement each or any combination of the features described herein as acts, actions, or performed by and / or by any software modules described herein as included within the component;(b) Alternatively or in addition, to the extent one or more software modules are described herein as being present within a component, in some embodiments, such software modules (as well as any data described herein as being handled and / or used by the software modules) may be stored in memory device(s) 1304 (e.g., in various embodiments, in a volatile memory device such as RAM or instruction registers and / or in a non-volatile memory device such as flash memory or a hard disk), and all acts described herein as being performed by the software modules may be performed by other elements in and / or connected to computing device 1300, as appropriate (e.g., network interface unit(s) 1306, display interface(s) 1308, user input adapter(s) 1310, display device(s) 1312, display device(s) 1314, display device(s) 1316, display device(s) 1318, display device(s) 1320, display device(s) 1322, display device(s) 1324, display device(s) 1326, display device(s) 1328, display device(s) 1329, display device(s) 1330, display device(s) 1332, display device(s) 1334, display device(s) 1336, display device(s) 1338, display device(s) 1339, display device(s) 1340, display device(s) 1342, display device(s) 1344, display device(s) 1346, display device(s) 1348, display device(s) 1349, display device(s) 1350, display device(s) 1352, display device(s) 1354, display device(s) 1356, display device(s) 1358, display device(s) 1359, display device(s) 1360, display device(s) 13 (c) alternatively or in addition, to the extent a component is described herein as processing and / or otherwise handling data, in some embodiments such data is stored in memory device 1304 (e.g., in some embodiments, in a volatile memory device such as RAM and / or in a non-volatile memory device such as flash memory or a hard disk) and / or processed / handled by processor 1302 in conjunction with other elements in and / or connected to computing device 1300 (e.g., network interface device 1306, display interface 1308, user input adapter 1310, display device 512, input device 1314, and / or external device 1316), as appropriate;(d) alternatively or in addition, in some embodiments, the memory device 1302 stores instructions that, when executed by the processor 1302, cause the processor 1302, together with other elements in and / or connected to the computing device 1300, as appropriate (e.g., the memory device 1304, the network interface device 1306, the display interface 1308, the user input adapter 1310, the display device 512, the input device 1314, and / or the external device 1316), to perform each or any combination of the acts described herein as being performed by any software modules described herein as being included within and / or included in the components;

[0230] The above-described hardware configuration shown in FIG. 13 is provided as an example, and the subject matter described herein may be utilized with a variety of different hardware architectures and elements. For example, in many of the figures in this document, individual function / act blocks are shown. In various embodiments, the functionality of these blocks may 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. 13, (e) via other hardware arrangements, architectures, and configurations, and / or via a combination of the techniques described in (a)-(e). Technical advantages of the described subject matter

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

[0232] In one exemplary embodiment, collisions between player objects in a multiplayer game are used to generate items that can be picked up in the game. These items can be used to enable special abilities. In some examples, the decisions about when to generate these items and the handling of when to pick up such items are not communicated as events from the client to the server as part of the multiplayer game. However, local results of such processes are stored and used to control aspects of the multiplayer game.

[0233] In one exemplary embodiment, the racing game includes a secondary track that the player can switch to during the racing game, and the amount of time the player is allowed to remain on this track is based on the positioning of the player's objects within the race.

[0234] In one exemplary embodiment, a select group of players is dynamically selected for competing players in a larger race, different graphical displays are used for players in this group during the race, and skill evaluations of players are based on race results compared to the select group relative to results in the larger race. Selected terms

[0235] 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," "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 it is described in this document that an action "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.

[0236] Terms and phrases used in this document and variations thereof should be construed as open-ended rather than limiting unless specifically 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 "examples" may be used interchangeably with the term embodiment and is used to provide examples of the subject matter under discussion, but is not an exhaustive or limiting list thereof. The terms "comprise" and "include" (as well as other conjugations and other variations) specify the presence of the associated listed elements, but do not preclude the presence or addition of one or more other elements. When an element is described as an "option," such description should not be understood to indicate that other elements are not required unless so described.

[0237] 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-ROM, DVD, or Blu-ray disks, 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.

[0238] The claims are not intended to envisage a means-plus-function interpretation unless the claim explicitly uses the phrase "means for" or "steps for." Any claim element that is intended to be interpreted as a means-plus-function statement, if any, will expressly indicate that intention by reciting the phrase "means for" or "steps for." The above applies to claim elements in any type of claim (method claim, apparatus claim, or other type of claim) and, for the avoidance of doubt, also applies to claim elements incorporated within a method claim. Consistent with the preceding sentence, no claim element (in any claim of any type) should be interpreted as a means-plus-function interpretation unless the claim element is explicitly recited using the phrase "means for" or "steps for."

[0239] Whenever a hardware element (e.g., a processor, a network interface, a display interface, a user input adapter, a memory device, or other hardware element) or a combination of hardware elements is described herein as being "configured" to perform some action, it should be understood that such language specifies 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 essentially links the action described after the phrase "configured to" to the physical characteristics of the hardware elements 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 that are configured to perform an action, or a field programmable gate array (FPGA) that includes programmable electronic logic circuits that are arranged in series or parallel to perform an action 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., through the configuration of registers, memory, etc.).

[0240] Thus, 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 being used, etc.). Consistent with the above, the phrase "configured to" in the claims should not be construed / considered to be 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) that are incorporated in a method claim. Additional Applications of the Described Subject Matter

[0241] Although process steps, algorithms, and the like, including but not limited to those referring to Figures 7 through 12, 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 steps that may be explicitly described or claimed in this document does not necessarily indicate a requirement that the steps be performed in that order. Rather, steps of processes described herein may be performed in any order possible. Furthermore, even if some steps are described or implied as occurring non-concurrently (e.g., because one step is described after another step), they may be performed simultaneously (or in parallel). Furthermore, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications, does not imply that the illustrated process or any of its steps are required, or that the illustrated process is preferred.

[0242] 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, step, 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 intended to be expressly incorporated herein by reference and encompassed. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the present invention, for it to be encompassed by the invention. Any embodiment, feature, element, component, or step in this document is not intended to be provided to the public.

Claims

1. 1. A computing device for playing a multiplayer video game, the computing device comprising: at least one hardware processor configured to perform operations, said operations including: processing input provided by a user of said computing device; generating a virtual game space including a first track and a plurality of controllable virtual objects, the plurality of controllable virtual objects including 1) a plurality of controllable virtual objects controlled by other players participating in the multiplayer video game using other computing devices, and 2) a player-controlled virtual object controlled by the user, the operation comprising: generating a second object based on a determination that a collision has occurred between two or more of the plurality of control-target virtual objects, and placing the second object on the first track in the virtual game space; acquiring the second object for the player-controlled virtual object based on controlling the player-controlled virtual object with the input; and updating parameters based on the acquisition of the second object; and controlling enabling of a timer based on the parameter reaching a threshold amount, wherein when the timer is enabled, the timer is set to a length of time based on a position of the player-controlled virtual object in the multiplayer video game.

2. 2. The computing device of claim 1, wherein the action further comprises enabling a capability of the player-controlled virtual object, an amount of time for which the capability is enabled being based on the length of time of the timer.

3. The computing device of claim 2 , wherein the capability provides a reward to the player-controlled virtual object in the multiplayer video game.

4. 4. The computing device of claim 3, wherein the operations further comprise setting a maximum speed of movement of the player-controlled virtual object higher than the first track, for at least the amount of time that the timer is valid.

5. The operation includes: the first mode limits control of the player-controlled virtual object to within the first path, and the second mode allows control of the player-controlled virtual object to fly outside the first path; The computing device of claim 3 , wherein enabling the capability switches from the first mode to the second mode.

6. The operation includes: moving the player-controlled virtual object to a second path different from the first path based on an instruction given by the user; The computing device of claim 1 , further comprising: moving the player-controlled virtual object from the second path back to the first path based on expiration of the timer.

7. the player-controlled virtual object remains on the second path after the timer expires; 7. The computing device of claim 6, wherein the operations further comprise determining a valid location on the first track to place the player-controlled virtual object when the player-controlled virtual object is returned to the first track.

8. the operations further comprise determining that there is no current valid location on the first track for placing the player-controlled virtual object; The computing device of claim 7 , wherein the returning of the player-controlled virtual object from the second path to the first path occurs further based on determining the location being valid.

9. The computing device of claim 1 , wherein the multiplayer video game is a racing game, and the length of time that the timer is valid is further based on a racing position of the player-controlled virtual object in the racing game.

10. The computing device of claim 9 , wherein the amount of time is increased based on the player-controlled virtual object's lower racing position.

11. 2. The computing device of claim 1, wherein the operations further comprise communicating with a server computer system hosting the multiplayer video game, the communication including receiving the updates controlled by other players and sending updates to the server computer system regarding the player-controlled virtual objects.

12. The computing device of claim 11 , wherein a determination that the collision has occurred between the two or more of the plurality of controlled virtual objects is not communicated to the server computer system.

13. The computing device of claim 11 , wherein the generation of the second object is not communicated to the server computer system.

14. The computing device of claim 11 , wherein the acquisition of the second object by the player-controlled virtual object is not communicated to the server computer system.

15. the multiplayer video game is a racing game; The operation includes: Displaying a non-player object; and generating additional objects from the non-player objects that are the same type as the second object, wherein a rate at which the additional objects are generated is based on a racing position of the player-controlled virtual object in the racing game.

16. The computing device of claim 1 , wherein the amount added to the parameter based on the acquisition of the second object is variable.

17. 2. The computing device of claim 1 , wherein the length of time is further based on a position of the player-controlled object in the virtual game space relative to a position of at least one other virtual object of the plurality of controllable virtual objects in the virtual game space.

18. 1. A computer program product stored on a non-transitory computer-readable storage medium, the computer program product comprising instructions configured to cause at least one hardware processor of a computing device to perform operations, the operations including: processing input provided by a user of said computing device participating in a multiplayer video game; generating a virtual game space including a first track and a plurality of controllable virtual objects, the plurality of controllable virtual objects including 1) a plurality of controllable virtual objects controlled by other players participating in the multiplayer video game using other computing devices, and 2) a player-controlled virtual object controlled by the user, the operation comprising: generating a second object based on a determination that a collision has occurred between two or more of the plurality of control-target virtual objects, and placing the second object on the first track in the virtual game space; acquiring the second object for the player-controlled virtual object based on controlling the player-controlled virtual object with the input; and updating parameters based on the acquisition of the second object; and controlling enabling of a timer based on the parameter reaching a threshold amount, wherein when the timer is enabled, the timer is set to a length of time based on a position of the player-controlled virtual object in the multiplayer video game.

19. the multiplayer video game is a racing game, and the amount of time that the timer is valid is further based on a racing position of the player-controlled virtual object in the racing game; The operation includes: moving the player-controlled virtual object to a second path different from the first path based on an instruction given by the user; 20. The computer program product of claim 18, further comprising: moving the player-controlled virtual object from the second path back to the first path based on expiration of the timer.

20. 1. A method performed on a computing device in communication with a server computer system, the method comprising: processing input provided by a user of said computing device participating in a multiplayer video game; generating a virtual game space including a first track and a plurality of controllable virtual objects, the plurality of controllable virtual objects including 1) a plurality of controllable virtual objects controlled by other players participating in the multiplayer video game using other computing devices, and 2) player-controlled virtual objects controlled by the user, the method comprising: generating a second object based on a determination that a collision has occurred between two or more of the plurality of control-target virtual objects, and placing the second object on the first track in the virtual game space; acquiring the second object for the player-controlled virtual object based on controlling the player-controlled virtual object with the input; and updating parameters based on the acquisition of the second object; and controlling enabling of a timer based on the parameter reaching a threshold amount, wherein when the timer is enabled, the timer is set to a length of time based on a position of the player-controlled virtual object in the multiplayer video game.

Images