U.S. Pat. No. 11,426,664

The figures depict various embodiments of the present disclosure for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles, or benefits touted, of the disclosure described herein.

DETAILED DESCRIPTION

In the following description of embodiments, numerous specific details are set forth in order to provide more thorough understanding. However, note that the embodiments may be practiced without one or more of these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

Embodiments relate to providing dynamic destruction of game objects in a gameplay session. A gameplay session is an instance of gameplay of an electronic game. The gameplay session may be played upon a client device. For example, the electronic game may be a video game that is run on a client device, such as a computer or a game console. Users may participate in the gameplay session via the client device. The client device may receive input from a user indicating a gameplay actions within the gameplay session, which may cause destruction (e.g., damage) to a game object. In other embodiments, the destruction of a game object may be initiated by other factors other than received user input. For example, a game object may be destroyed based on actions by a non-player character (NPC) controlled by the electronic game, or based on scripted events included in the electronic game.

Game objects are data objects included in a gameplay session for display or interaction. For example, a game object may represent a building, and another game object may represent a character (e.g., an enemy, a comrade, etc.), and yet another game object may represent a collectable item (e.g., a helmet, a piece of armor, a weapon, a potion, a power up, etc.).

The game objects may experience damage within the gameplay session. For example, a game object experiences damage when a destructive action (e.g., being shot, blown up, hit, etc.) occurs upon the game object within a gameplay session including the game object. As such, one or more destruction objects may be instantiated to represent the damage to the game object. The destruction objects may replace the game object or be instantiated in addition to the original game object. A destruction object may represent debris caused by the damage to the game object. For example, a helmet (a game object) struck with a sword (damage) breaks in half, resulting in the helmet being replaced by two destruction objects representing the two halves of the damaged helmet. As another example, a robot (a game object) may be shot (damage) resulting in a component (e.g., a mechanical arm) being blown off. A destruction object may be instantiated for the removed component while the original game object representing the robot remains (possibly with its appearance altered to reflect the missing component).

After determining the game object has been damaged (e.g., shot, blown up, etc.) in a gameplay session, a level of destructive detail is determined. The determined level of destructive detail may be based on one or more properties of the game object, one or more properties of a client device displaying the gameplay session, one or more properties of the gameplay session, or one or more settings provided by the user of the client device. One or more properties of the game object may include an indication of whether the destruction object should include a mesh assignment or a gravity assignment. One or more properties of the client device may include a type of client device, a type of operating system, a type of processor, a current processor usage percentage, a type of memory, an amount of currently available memory, and an amount of memory currently being used. One or more properties of the gameplay session may include a type of game, a type of scene, a number of game objects in the scene, and a frame rate of the scene.

The level of destructive detail affects the creation and rendering of the one or more destruction objects resulting from the damage to the game object. In one embodiment, each of the destruction objects is created with either a first or second level of destructive detail. Objects with the first level of destructive detail are physics objects that interact with other objects in the environment with simulated physics. For example, using the first level of destructive detail for a destruction object, a graphical indication of the damage of the game object is rendered as a rigid body. Objects with the second level of destructive detail are effects objects that are rendered within the environment but generally do not interact with other objects. For example, with the second level of destructive detail, a destruction object is rendered and behaves in a predetermined manner (e.g., follows a predetermined path) in the game environment, regardless of what other objects are present. With the first level of destructive detail, the damage of the game object may act and appear more visually realistic to the user, but it also consumes a greater amount of computing resources. Depending on an amount of physics objects currently being rendered in the scene, the level of destructive detail for a destruction object may be updated.

Among other advantages, dynamic destruction of a game object in a gameplay session, enables real-time decision making as to what level of destructive detail a damaged game object (and its corresponding destruction objects) are created and rendered (e.g., with a physics-based configuration or an effects-based configuration) while preventing performance issues, such as low frame rate, lag, or crashing of the electronic game. Thus, dynamic destruction of the game object improves performance of the client device.

Embodiments are described herein with reference to the figures where like reference numbers indicate identical or functionally similar elements. Also, in the figures, the left most digit or digits of each reference number corresponds to the figure in which the reference number is first used.

FIG. 1is a block diagram of a computer game system100in which the techniques described herein may be practiced, according to an embodiment. The system100includes, among other components, a content creator110, a server120, client devices130, and a network140. In other embodiments, the system100may include additional content creators110or servers120, or may include a singular client device130.

The content creator110, the server120, and the client devices130are configured to communicate via the network140. The network140includes any combination of local area or wide area networks, using both wired or wireless communication systems. In one embodiment, the network140uses standard communications technologies or protocols. For example, the network140includes communication links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, code division multiple access (CDESTRUCTION MANAGER320A), digital subscriber line (DSL), etc. Examples of networking protocols used for communicating via the network140include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over the network140may be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML). In some embodiments, all or some of the communication links of the network140may be encrypted using any suitable technique or techniques.

The content creator110is a computing device, such as a personal computer, a mobile phone, a tablet, or so on, which enables a game developer to create content items (e.g., characters and environment information) for a computer game. For this purpose, the content creator110includes a processor and a memory (not shown) that stores various software modules for creating content items. The created content items are sent to the server120for storing on its memory122.

The server120is a computing device that includes a processor126and a memory122connected by a bus128. The memory122includes various executable code modules or non-executable content items124. The server120may receive and route messages between the content creator110and the client devices130. Content items124may be sent to the client devices130via the network140.

The processor126is capable of executing instructions, sequential or otherwise, that specify operations to be taken, such as performance of some or all of the techniques described herein. The bus128connects the processor126to the memory122, enabling data transfer from the one to the other and vice versa. Depending upon the embodiments, the server120may include additional elements conventional to computing devices.

Each client device130is a computing device that includes a game or other software. The client device130receives data objects from the server120and uses the data objects to render graphical representations of characters and environment in which the characters take actions in the game. Different client devices130can request different data objects from the server120.

Although the embodiment ofFIG. 1is described as operating in a networked environment, in other embodiments, the client devices130are not connected via a network and the computer game is executed without exchanging messages or content items over any network. In such cases, any content items associated with the compute game may be received and installed on the client devices130using a non-transitory computer readable medium such as DVD ROM, CD ROM, or flash drive.

FIG. 2is a block diagram of a client device130in which the techniques described herein may be practiced, according to an embodiment. The client device130is any machine capable of executing instructions, and may be a standalone device or a connected (e.g., networked) set of devices, and may be a computing device such as a gaming system, a personal computer, a mobile phone, a tablet, or so on. The client device130includes a processor (CPU)212, a graphics processing unit (GPU)214, a primary memory216, a secondary memory218, a display controller220, a user interface222, a sound controller224, and a bus226. In other embodiments the client device130may include additional or other components. While only a single client device130is illustrated, other embodiments may include any collection of client devices130that individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.

The primary memory216is a machine-readable medium that stores instructions (e.g., software) embodying any one or more of the methodologies or functions described herein. For example, the primary memory216may store instructions that, when executed by the CPU212, configure the CPU212to perform a process, described below in detail with reference toFIG. 4. Instructions may also reside, partially or completely, within the CPU212or GPU214, e.g., within cache memory, during execution of the instructions.

The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing instructions for execution by the device and that cause the device to perform any one or more of the methodologies disclosed herein. The term “machine-readable medium” includes, but is not limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.

The secondary memory218is a memory separate from the primary memory216. Similar to the primary memory216, the secondary memory218is a machine-readable medium that stores instructions (e.g., software) embodying any one or more of the methodologies or functions described herein. For example, the primary memory216may be a hard drive of the client device130, and the secondary memory218may be a game disc for an electronic game. As a specific example, the primary memory216may store a game system300that uses data stored on the secondary memory218. Primary memory216and secondary memory218are described in greater detail with reference toFIG. 3below.

The CPU212is processing circuitry configured to carry out the instructions stored in the primary memory216or secondary memory218. The CPU212may be a general-purpose or embedded processor using any of a variety of instruction set architectures (ISAs). Although a single CPU is illustrated inFIG. 2, the client device130may include multiple CPUs212. In multiprocessor systems, each of the CPUs212may commonly, but not necessarily, implement the same ISA.

The GPU214is a processing circuit specifically designed for efficient processing of graphical images. The GPU214may render objects to be displayed into a frame buffer (e.g., one that includes pixel data for an entire frame) based on instructions from the CPU212. The GPU214may include one or more graphics processors that may execute graphics software to perform a part or all of the graphics operations.

The display controller220is a circuit that generates a video signal using graphical data from the GPU214. For example, the display controller220drives a display device (e.g., a liquid crystal display (LCD) and a projector). As such, an electronic game can be displayed as images or a video sequence through the display controller220.

The sound controller224is a circuit that provides input and output of audio signals to and from the client device1130. For purposes of the destruction of game objects, the sound controller224can provide audio signals that align with the destruction.

The user interface222is hardware, software, firmware, or a combination thereof that enables a user to interact with the client device130. The user interface222can include an alphanumeric input device (e.g., a keyboard) and a cursor control device (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument). For example, a user uses a keyboard and mouse to control a character's action within a gameplay session that includes game objects rendered by the client device130. The gameplay session includes a simulation and rendering of game objects, within which the user's game character operates. For example, the user's game character may destroy game objects during the gameplay session.

The client device130executes computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program instructions or other logic used to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, or software. In some embodiments, program modules formed of executable computer program instructions are loaded into memory and executed by the CPU212or the GPU214. For example, program instructions for the process ofFIG. 4can be loaded into the primary memory216or secondary memory218, and executed by the CPU212and GPU214.

FIG. 3is a block diagram of software modules in memory of the client device130ofFIG. 1, according to an embodiment. In particular,FIG. 3illustrates software modules in the primary memory216and the secondary memory218of the client device130. The primary memory216may store, among other modules, a game system300and an operating system (“OS”)360. The secondary memory218may store, among other modules, a content source370. The primary memory216and secondary memory218may include other modules not illustrated inFIG. 3. Furthermore, in other embodiments, the primary memory216and secondary memory218may each store software modules and data represented herein as stored in the other.

The game system300includes a destruction manager320, a physics system325, an effects system330, a level manager340, a sound module345, an animation system350, and a graphics rendering module355. These modules collectively form a “game engine” of the game system300. The electronic game includes at least the game system300and may additionally include data stored at the secondary memory218in some embodiments.

The game system300performs operations310A through310N (collectively referred to as “the operations310”) to run gameplay sessions of the electronic game, including the destruction of game objects. Specifically, the game system300performs these operations310to instantiate game objects in the gameplay session, render various instantiated game objects within the gameplay session (e.g., the user's game character and game objects in a particular direction or field of view from the game character), and simulate interactions between the game objects. The operations310refer to computing operations that result in changes in various parameters (e.g., states of game objects and user status) based upon certain events (e.g., user interactions, expirations of time, and triggers occurring in the gameplay session).

Some operations310are associated with the destruction of one or more game objects. Examples of operations associated with the destruction of a game object may include animations of movement of the game object or interactions of the game object with another game object. A particular example of movement of the game object may include a piece of armor falling to the ground. A particular example of an interaction of the game object with another game object may include the piece of fallen armor being kicked by another character along the ground. The operations310may be simulated by the game engine. When executing the operations310, the game system300may communicate with the components of the game engine (e.g., the destruction manager320, the physics system325, the effects system330, etc.) through application programming interfaces (APIs). At least one of the operations310associated with the destruction of a game object involves determining a level of destructive detail.

The level manager340creates and maintains gameplay sessions using game objects it retrieves from the primary memory216or secondary memory218. For example, upon the game system300launching a gameplay session, the game system300determines which game objects are or could be involved in the gameplay session, and loads them into primary memory216, e.g., at the level manager340. Other modules of the game system300can request one or more game objects from the level manager340, which responds to the requests by sending the game objects to the module of the game system300that sent the request. The level manager340may also receive input from the user interface222, the operations310, or other modules of the game system300, which may impact a game session, e.g., instruct the level manager340to destroy a game object.

The destruction manager320dynamically handles the destruction of game objects within a gameplay session. For example, during gameplay, a game object may experience damage when a destructive action (e.g., being shot, blown up, hit, etc.) occurs upon the game object. As such, the destruction manager320may instantiate one or more destruction objects, with a destruction object representing debris caused by the damage to the game object. For example, a suit of armor (a game object) struck with a spear (damage) breaks into multiple pieces of armor (one or more destruction objects). The destruction manager320may determine that the game object has been damaged based on one or more operations310.

Responsive to the determination that a game object has been damaged, the destruction manager320determines a level of destructive detail for the resulting destruction object (or objects). The level of destructive detail for a destruction object defines how the destruction object is to be rendered by the game engine after the game object is damaged. In some embodiments, the destruction manager320determines either a first level of destructive detail or a second level of destructive detail for the game object. With the first level of destructive detail, a destruction object is to be created utilizing a physics-based configuration (e.g., by the physics system325). With the second level of destructive detail, the destruction object is to be created utilizing an effects-based configuration (e.g., by the effects system330).

In one embodiment, the destruction manager320determines the level of destructive detail based on one or more properties of the game object that is damaged. In some embodiments, the destruction manager320may determine the one or more properties of the game object based on graphics data372received from the content source370via the level manager340. The one or more properties of the game object may specify properties of destruction objects that may be created when the game object is damaged, such as a mesh assignment or a gravity assignment for destruction objects. For example, a game designer may have used content creator110to assign various destruction objects that may be created when various game objects are damaged. If a destruction object has a mesh defining the destruction object's geometric properties assigned, the destruction manager320may determine the level of destructive detail to be the first level of destructive detail and that the destruction object is to be created as a physics object where the mesh is used to determine interactions with other objects in the environment. Alternatively, if the destruction object does not have a mesh assigned, the destruction manager320may determine the level of destructive detail to be the second level of destructive detail and that the destruction object is to be created as an effects object because, without a mesh, the physics system325may not have a mechanism for determining interactions between the destruction object and other objects in the environment.

In another example, a destruction object has a gravity assigned defining the destruction object's interactivity with gravity, When the destruction object is created due to damage to a game object, the destruction manager320may determine the level of destructive detail to be the first level of destructive detail and that the destruction object is to be created as a physics object where the gravity assignment is used to model how the destruction object falls, bounces, etc. in the environment. Alternatively, if the destruction object does not have a gravity assigned, the destruction manager320may determine the level of destructive detail to be the second level of destructive detail and that the destruction object is to be created as an effects object because, without a gravity, the physics system325may not have a mechanism for determining interactions between the destruction object and gravity in the environment.

The destruction manager320may determine the level of destructive detail based on one or more properties of the client device130. The one or more properties of the client device130correspond to specifications of the client device130and current operating characteristics of the client device130. The one or more properties of the client device130may include a type of client device130(e.g., system or platform of the client device130), a type of OS360(e.g., Windows 10, Windows 8, macOS, Linux, etc.), a type of processor212(e.g., Intel Core i5, Intel Core i7, AMD Ryzen 5, AMD Ryzen 7, etc.), a current processor usage percentage (e.g., high CPU usage, low CPU usage, 80% CPU usage, 40% CPU usage, etc.), a type of memory (e.g., storage capacity of primary memory216), an amount of currently available memory (e.g., available storage capacity in primary memory216), an amount of memory currently being used (e.g., unavailable storage capacity in primary memory216). In one example, if the type of OS360is Windows 10, the destruction manager320may determine the level of destructive detail to be the first level of destructive detail. In some embodiments, the destruction manager320may compare any or all of the one or more properties of the client device130to a threshold to determine the level of destructive detail. For example, if the current processor usage percentage is above a first threshold and the amount of currently available memory is below a second threshold, the destruction manager320may determine the level of destructive detail to be the second level of destructive detail.

The destruction manager320may determine the level of destructive detail based on one or more properties of the gameplay session. The one or more properties of the gameplay session correspond to characteristics of the game. The one or more properties of the gameplay session may include a type of game (e.g., genre of game), a type of scene (e.g., action intense scene, non-action intense scene), a number of game objects in the scene, and a frame rate of the scene. In an example, if the type of scene is an action-intense scene, the destruction manager320may determine the level of destructive detail to be the second level of destructive detail. In some embodiments, the destruction manager320may compare any or all of the one or more properties of the gameplay session to a threshold to determine the level of destructive detail. In an example, if the frame rate of the scene is below a threshold, the destruction manager320may determine the level of destructive detail to be the first level of destructive detail.

The destruction manager320may determine the level of destructive detail based on one or more settings provided by the user of the client device130. The one or more settings may be provided by the user via the user interface222. The one or more settings may include a preferred level of destructive detail. In some embodiments, the one or more settings may include a setting that specifies the client device130is to determine the appropriate level destructive detail in real-time. In an example, if the user selected a preferred level of destructive detail to be the second level of destructive detail, the destruction manager320may determine the level of destructive detail to be the second level of destructive detail.

The destruction manager320may determine the level of destructive detail based on a combination of the one or more properties of the game object, one or more properties of the client device130, one or more properties of the gameplay session, or one or more settings provided by the user. For example, if a destruction object resulting from damage to the game object is assigned a mesh and the OS360is a Windows 10, the destruction manager320may determine the level of destructive detail to be the first level of destructive detail. In another example, the destruction manager320may determine the level of destructive detail by determining a metric that indicates an available amount of computing resources available at a time the game object is damaged. The metric is based on one or more properties of the client device130and one or more properties of the gameplay session. For example, the metric is based on at least one of a current processor usage percentage, an amount of currently available memory, or a current frame rate. A metric is higher when the current processor usage percentage is low, the amount of currently available memory is high, or a current frame rate is low. The destruction manager320may compare the metric to a threshold metric. Based on the metric being greater than the threshold metric, the destruction manager320may select the first level of destructive detail.

Additionally, or alternatively, in some embodiments, the destruction manager320may determine an amount of other game objects being rendered with a physics-based configuration during the gameplay session. The destruction manager320may compare the amount of other game objects to a threshold amount. The threshold amount may be based on one or more properties of the client device130. For example, a high CPU usage amount of the processor212correlates with a lower threshold amount. Based on the amount of other game objects (that are renders with a physics-based configuration) being greater than the threshold amount, the destruction manager320may determine to update the level of destructive detail for the game object to the second level of destructive detail. By tracking the amount of other game objects being rendered with a physics-based configuration during the gameplay session, the destruction manager320can better account for changes in computing resources used by the game system300and thereby reduce performance issues.

After the destruction manager320determines the level of destructive detail for the game object, the destruction manager320provides instructions to the physics system325or to the effects system330to create the destruction object(s) based on the determined level of destructive detail. For the first level of destructive detail, instructions are provided to the physics system325. For the second level of destructive detail, instructions are provided to the effects system330.

The physics system325creates one or more destruction object(s) and simulates the dynamics of the destruction object(s) in the gameplay session. For example, the physics system325models how a piece of armor (a destruction object) falls to the ground after the suit of armor (the game object) is damaged. The physics system325may model the destruction object as a rigid body. During the gameplay session, one or more other game objects may be rendered by the graphics rendering module355. The physics system325may model interactions between destruction object(s) and other game objects. For example, the piece of armor may be kicked along the ground by another character (another game object). The physics system325may model the dynamics necessary to simulate this interaction.

The effects system330creates one or more destruction object(s) and determines predetermined behavior of the destruction object(s) in the gameplay session. In the same piece of armor example described above, the effects system330models the piece of armor falling to the ground via a parabolic path and then sticking to the ground or disappearing completely at ground level. In some embodiments, the effects system330may model the destruction object as a conventional sprite or non-solid 3D object. The effects system330ignores other game objects potentially rendered by the graphics rendering module355. For example, if a character bumps into the piece of armor when modelled as an effect, the character passes through the piece of armor.

The sound module345generates sounds corresponding to actions occurring in the gameplay session. For example, the destruction of a “building” game object may correspond to an “explosion” sound. Animation data from the animation system350or gameplay session information from the level manager340may be sent to the sound module345to enable the sound module345to produce sound. The sound module345sends sound data to the sound controller224.

The animation system350is a module that performs kinematic animation of game objects in the gameplay session based on the operations310from the game system300. For example, if an operation310specifies that a robotic arm is moving, the animation system350animates the kinematics of the arm movement. As a second example, if an operation310specifies that the robotic arm breaks away from a game character, the animation system350provides kinematic information (e.g., position, orientation, velocity, angular velocity, etc.) corresponding to the robotic arm to the physics system325. In this second example, the physics system325has a starting point with which to begin its simulations of the robotic arm. The animation system350may include any number of specialized modules which perform specific animation tasks.

The graphics rendering module355renders graphics from the animation system350and level manager340to generate an image of the gameplay session. For example, the graphics rendering module355receives data from the animation system350and a game object from the level manager340. In another example, the graphics rendering module355receives data from the physics system325. The graphics rendering module355sends graphical data to the GPU214to render images on a display, e.g., a display of the client device130or a display connected to the client device130, via the display controller220.

The OS360manages computer hardware and software resources. Specifically, the OS360acts as an intermediary between programs and the computer hardware. For example, the OS360can perform basic tasks, such as recognizing input from the user interface222and sending output to the display controller220.

The content source370in the secondary memory218includes various data, including graphics data372, audio data374, event data376, and object data378. Depending upon the embodiment, some or all of the data in the content source370may instead be in the primary memory216. The content source370sends data to the level manager340upon receiving a request for the data from the level manager340. For example, upon the level manager340receiving a request for information regarding graphics data from the destruction manager320, the level manager340requests the information from the content source370, which sends the information to the level manager340.

The graphics data372includes graphics data, e.g., mesh assignments and gravity assignments, for one or more game objects or destruction objects.

The audio data374includes data relating to sound, e.g., clips of sound. Each portion of audio data374may be associated with one or more game objects. The sound module345may retrieve audio data374and use it to generate sounds corresponding to actions occurring in the gameplay session, such as the destruction of a game object.

The event data376includes game events, which occur during the gameplay session. Each game event may be associated with a destruction operation for one or more game objects. A destruction operation may be triggered by the occurrence of an associated game event in the gameplay session.

The object data378includes game objects. Each game object may include a variety of information depending upon the embodiment. This may include an identifier used to associate a game object with a mesh assignment or a gravity assignment. In an embodiment, the object data378includes the graphics data372.

FIG. 4is a flowchart illustrating a process400for providing dynamic destruction of a game object, according to an embodiment. During a gameplay session, the client device130determines410that the game object has been damaged. For example, the client device130may determine a game object has been damaged based in part on information received from the level manager340.

Responsive to the client device130determining the game object has been damaged, the client device130determines420a level of destructive detail. In some embodiments, the client device130determines the level of destructive detail based on one or more properties of the game object, one or more properties of the client device130, one or more properties of the gameplay session, or one or more settings provided by a user of the client device130. The properties of the game object may include a mesh assignment or a gravity assignment. The properties of the client device130may include a type of client device130, a type of operating system360, a type of processor, a current processor usage percentage, a type of memory, an amount of currently available memory, and an amount of memory currently being used. The properties of the gameplay session may include a type of game, a type of scene, a number of game objects in the scene, and a frame rate of the scene. The settings provided by the user of the client device130may include a user-preferred level of destructive detail. In some embodiments, the client device130may determine the level of destructive detail based on comparisons of some of the properties with threshold values. For example, the amount of memory currently being used may be compared with a threshold and based on the comparison the client device130may determine the level of destructive detail.

The client device130creates430a destruction object having the determined level of destructive detail. In some embodiments, the determined level of destructive detail may be one of two possible levels. A first level of destructive detail defines a physics-based configuration of the destruction object and the second level of destructive detail defines an effects-based configuration of the destruction object.

The client device130renders440a graphical indication of the damage of the game object using the destruction object.

Additional Considerations

Some portions of above description describe the embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs comprising instructions for execution by a processor or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of functional operations as modules, without loss of generality.

As used herein, any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. Similarly, use of “a” or “an” preceding an element or component is done merely for convenience. This description should be understood to mean that one or more of the elements or components are present unless it is obvious that it is meant otherwise.

Where values are described as “approximate” or “substantially” (or their derivatives), such values should be construed as accurate +/−10% unless another meaning is apparent from the context. From example, “approximately ten” should be understood to mean “in a range from nine to eleven.”

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

Although embodiments described above are explained primarily in reference to a game system, the embodiments may be applied to other applications such as engineering software, navigational software, and educational software, such as a map application or a ride hailing application. Additionally, embodiments can be applied to research applications.

While particular embodiments and applications have been illustrated and described, it is to be understood that the invention is not limited to the precise construction and components disclosed herein and that various modifications, changes and variations which will be apparent to those skilled in the art may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope of the present disclosure.