U.S. Pat. No. 10,950,010

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 displaying of the destruction of game objects in a gameplay session. A gameplay session is an instance of gameplay of an electronic game upon a client device. Users may participate in a gameplay session via the client device. For example, the client device receives input from a user indicating a gameplay action within the gameplay session, such as to destroy a game object. The destruction of game objects may be initiated by 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 and/or interaction. For example, one game object may represent a building, and another game object may represent a tree. Rendered game objects may be rendered by processing polygon meshes.

The game objects may have a property of “destructibility” indicating whether the game object is destructible. Such “destructibility” of a game object may be represented by a binary value (e.g., “0” indicating indestructible, and “1” indicating destructible). A game object with a destructible property is destructed when a destructive action occurs upon the game object within a gameplay session including the game object. A game object with an indestructible property is not destructed when a destructive action occurs upon the game object within a gameplay session including the game object. The destructible game object may alternatively or additionally be associated with one or more levels of destructive detail available for the game object, such that determination of a level of destructive detail for the game object is constrained to the levels of destructible detail indicated by the destructible property. As such, certain game objects may not be rendered below a certain level of destructive detail, or, alternatively, above a certain level of destructive detail. The destructible property may be used to indicate that the game object is to always be rendered at a certain level of destructive detail.

After receiving information on game objects for destruction in a gameplay session, the client device determines a level of destructive detail for the game objects. The level of destructive detail may be based on performance data of the electronic game as run by the client device, and indicates a number and/or configuration of shards for the game objects to destruct into. The performance data may include a frame rate, a number of active shards in the gameplay session, and a total number of shards loaded in memory of the client device.

Shards are bodies representing a portion of a game object, rather than a complete game object. For example, the game object representing a building may be associated with a set of shards that, fitted together, take the shape of the cuboid polygon mesh representing the building. In an embodiment, the full polygon mesh of a game object is a shard, such as at a particular level of destructive detail, e.g., a lowest level of destructive detail.

Different levels of destructive detail correspond to different numbers and/or configurations of shards for game objects. For example, at a first level of destructive detail, a game object is associated with a first set of shards in a first configuration, and at a second level of destructive detail, the game object is associated with a second set of shards in a second configuration. The second level of destructive detail may be more detailed than the first level of destructive detail in that the second set of shards includes more shards than the first set of shards, such that upon a rendering of a destruction of the game object, the game object appears to break into a greater number of pieces. As a specific example, the game object may represent a building the first set of shards includes 1000 shards, and the second set of shards includes 100,000 shards. Upon rendering by the client device in the gameplay session the destruction of the game object, depending upon the level of destructive detail, the building appears to destruct into 1000 shards or 10,000 shards, the latter of which likely appears more visually realistic, but also consumes a greater amount of computing resources.

The electronic game may monitor the performance data and use it to generate a score. The electronic game may use the score to determine a level of destructive detail to use when rendering destruction in a gameplay session. The level of destructive detail may be periodically changed based on periodic generation of new scores, as the performance data changes dynamically as the electronic game is run by the client device. Based on each new score, the electronic game renders destruction of game objects at a particular level of destructive detail, such that the highest level of destructive detail can be employed at each time period that does not degrade performance past a threshold performance.

Among other advantages, dynamic determination of level of destructive detail enables the displaying of higher levels of destructive detail while preventing performance issues, such as low frame rate, lag, or crashing of the electronic game. Thus, dynamic determination of level of destructive detail improves performance of the client device and enhances user experience of the game.

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 client device110in which the techniques described herein may be practiced, according to an embodiment. The client device110is 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 device110includes a processor (CPU)112, a graphics processing unit (GPU)114, a primary memory116, a secondary memory118, a display controller120, a user interface122, a sound controller124, and a bus126. In other embodiments the client device110may include additional or other components. While only a single client device140is illustrated, other embodiments may include any collection of client devices140that individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.

The primary memory116is 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 memory116may store instructions that, when executed by the CPU112, configure the CPU112to perform a process, described below in detail with reference toFIG. 5. Instructions may also reside, partially or completely, within the CPU112and/or GPU114, 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 memory118is a memory separate from the primary memory116. Similar to the primary memory116, the secondary memory118is 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 memory116may be a hard drive of the client device110, and the secondary memory118may be a game disc for an electronic game. As a specific example, the primary memory116may store a game system200that uses data stored on the secondary memory118. Primary memory116and secondary memory118are described in greater detail with reference toFIG. 2below.

The CPU112is processing circuitry configured to carry out the instructions stored in the primary memory116and/or secondary memory118. The CPU112may be a general-purpose or embedded processor using any of a variety of instruction set architectures (ISAs). Although a single CPU is illustrated inFIG. 1, the client device110may include multiple CPUs112. In multiprocessor systems, each of the CPUs112may commonly, but not necessarily, implement the same ISA.

The GPU114is a processing circuit specifically designed for efficient processing of graphical images. The GPU114may 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 CPU112. The GPU114may include one or more graphics processors that may execute graphics software to perform a part or all of the graphics operations.

The display controller120is a circuit that generates a video signal using graphical data from the GPU114. For example, the display controller120drives 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 controller120.

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

The user interface122is hardware, software, firmware, or a combination thereof that enables a user to interact with the client device110. The user interface122can 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 device110. 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 device110executes computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program instructions and/or other logic used to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In some embodiments, program modules formed of executable computer program instructions are loaded into memory and executed by the CPU112or the GPU114. For example, program instructions for the process ofFIG. 5can be loaded into the primary memory116and/or secondary memory118, and executed by the CPU112and GPU114.

FIG. 2is a block diagram of software modules in a memory of the client device110ofFIG. 1, according to an embodiment. In particular,FIG. 2illustrates software modules in the primary memory116and the secondary memory118of the client device110. The primary memory116may store, among other modules, a game system200and an operating system (“OS”)260. The secondary memory118may store, among other modules, a content source270. The primary memory116and secondary memory118may include other modules not illustrated inFIG. 2. Furthermore, in other embodiments, the primary memory116and secondary memory118may each store software modules and data represented herein as stored in the other.

The game system200includes a destruction manager230, a physics system235, a sound module240, a level manager245, an animation system250, and a graphics rendering module255. These modules collectively form a “game engine” of the game system200. The electronic game includes at least the game system200, and may additionally include data stored at the secondary memory118in some embodiments.

The game system200performs operations212A through212N (collectively referred to as “the operations212”) to run gameplay sessions of the electronic game, including the destruction of game objects. Specifically, the game system200performs these operations212to 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 operations212refer 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 operations212are associated with one or more game objects. Examples of operations include a rendering a game object, including animations of movement of the game object, portions of the game object, and/or interactions of the game object with another game object. Particular examples may include a character running, fluid flowing, an arrow flying, a door opening, a sand castle collapsing, and so on. While some operations212have relatively simple responses (e.g., the door opening), other operations may need to be simulated by the physics system235(e.g., the sand castle collapsing). When executing the operations212, the game system200may communicate with the components of the game engine (e.g., physics system235) through application programming interfaces (APIs). At least one of these operations212involves determining a level of destructive detail for a gameplay session.

The level manager245creates and maintains gameplay sessions using game objects it retrieves from the primary memory116and/or secondary memory118. Other modules of the game system200can request one or more game objects from the level manager245, which responds to the requests by sending the game objects to the module of the game system200that sent the request. The level manager245may also receive input from the user interface122, the operations212, and/or other modules of the game system200, which may impact a game session, e.g., instruct the level manager245to destroy a game object.

The destruction manager230dynamically handles the destruction of game objects within a gameplay session. Periodically, the destruction manager230determines a performance score based on performance data of the gameplay session, and selects a level of destructive detail to use for destruction of game objects within the gameplay session based on the score. In an embodiment, the destruction manager230selects the highest level of destructive detail possible based on the performance score. For example, three levels of destructive detail may correspond to a first threshold between a lowest level of destructive detail and a middle level of destructive detail, and a second threshold between the middle level of destructive detail and a high level of destructive detail. For a performance score between the first and second thresholds, the destruction manager230selects the middle level of destructive detail rather than the low level of destructive detail. For a performance score above the second threshold, the destruction manager230uses the high level of destructive detail rather than the middle or low levels of destructive detail. In both cases, the destruction manager230reacts to additional constraints, e.g., a destructible component of a game object indicating that the game object shall only be rendered at the middle level of destructive detail.

The destruction manager230determines the performance score for a gameplay session based on one or more metrics, which are reflected in the “performance data” referenced herein. The performance data may be computed from, among others, (i) a first metric representing a current frame rate of the client device110, (ii) a second metric representing a number of active shards in the gameplay session, and (iii) a third metric representing a total number of shards in memory of the client device110, e.g., in primary memory116. The number of active shards in the gameplay session is the number of shards rendered in the gameplay session at the time the performance data is gathered, and may vary throughout gameplay depending upon how many, if any, game objects are destroyed at that time. In contrast, the total number of shards in memory of the client device110may be set when the gameplay session is launched, and remain static throughout the gameplay session.

The performance score is determined by the destruction manager230by weighing each metric and combining the weighted metrics into a single value. In one embodiment, the performance score is determined by:

w1Frame⁢⁢Rate+w2×(Shard⁢⁢Count)+w3×(Total⁢⁢Shards)Equation⁢⁢(1)

where Frame Rate is the frame rate, Shard Count is the number of active shards in the gameplay session, Total Shards is the total number of shards in memory of the client device110, and w1through w3are the first through third weights, respectively. In other embodiments, other formulas may be used when determining a performance score, and may involve different metrics than those described herein, as well as more or fewer than three metrics.

In an embodiment, the weights are preset values. In another embodiment, one or more of the weights are based on specifications of the client device110, e.g., an amount of primary memory116the client device110has. For example, w3may be inversely proportional to a measurement of the amount of primary memory116, as greater memory capacity reduces the potential impact of a high total number of shards. Alternatively, in some embodiments, one or more thresholds may be based on the specifications of the client device110, such that increased computing resources (e.g., primary memory116or processor speed) correlates with lower thresholds.

After determining a performance score, the destruction manager230compares the performance score to one or more thresholds and selects a level of destructive detail based on the comparison, e.g., which, if any, thresholds are surpassed by the performance score. The destruction manager230selects the highest level of destructive detail allowed based on the performance score. After selection of a level of destructive detail, the destruction manager230instructs the game system200to render the destruction of game objects at the selected level of destructive detail. The game system200does so until the destruction manager230selects a new level of destructive detail and instructs the game system200to change the level of destructive detail it is actively using to the newly selected level of destructive detail. Upon a change from one level of destructive detail to another, the game system200either immediately changes all subsequent destruction renderings from the one level of destructive detail to the other, or uses a gradual switch from the one to the other. If the game system200uses a gradual switch, the destruction manager230may indicate various subsets of game objects in a particular order, such that one subset of game objects at a time is switched from the one level of destructive detail to the other. In this manner, the switch may be less visually jarring, and also require fewer computing resources at any one time, due to fewer game objects switching at the same time.

In an embodiment, the destruction manager230tracks a rate of active shard creation and adjusts the level of destructive detail based on the tracked rate. The rate of active shard creation may be based on a number of active shards added to the gameplay session over a period of time, e.g., each second. The tracked rate may alternatively be a predicted rate of active shard creation, which may be based upon the inclusion of particular game objects in the gameplay session, particular impending game events in the gameplay session, and so on. In one embodiment, if the tracked rate is greater than a threshold rate, the destruction manager230lowers the level of destructive detail by one or more levels. In other embodiments, the tracked rate may be used to alter the weights involved in determining performance scores, such that higher tracked rates cause lower scores, decreasing the likelihood of a high level of destructive detail. By factoring for the rate of active shard creation, the destruction manager230can better account for changes in computing resources used by the game system200and thereby reduce performance issues.

In an embodiment, the destruction manager230maintains a predictive model for estimating performance of the client device110based on recent and/or scheduled game operations212. Using the predictive model, the destruction manager230estimates future performance of the client device110, e.g., at the runtime of the scheduled operations212. The destruction manager230may adjust the performance score based on the estimate produced using the predictive model. For example, based on the estimate, the destruction manager230may change one or more weights, the performance score itself, one or more thresholds, or the level of destructive detail.

The physics system235models and simulates the dynamics of game objects in the gameplay session. After an operation212is initiated in the game system200, the physics system235models how the action affects the game object associated with the operation212. For example, the physics system models a rock as it rolls down a hill. Depending on the action and game object, other game objects and actions may become associated with the action or game object. For example, a thrown rock may knock over another game object. This may trigger a new operation212where the game object is hit by the rock. The physics system235uses the level of destructive detail determined by the destruction manager230when modeling and simulating the dynamics of the destruction of game objects in the gameplay session. For example, the physics system235may determine how to destroy a game object based on the set of shards associated with the game object at the determined level of destructive detail.

The animation system250is a module that performs kinematic animation of game objects in the gameplay session based on the operations212from the game system200. For example, if an operation212specifies that a robotic arm is moving, the animation system animates the kinematics of the arm movement. As a second example, if an operation212specifies that a building is exploding, the animation system animates the physics of the explosion, as determined by the physics system235. The animation system250may include any number of specialized modules which perform specific animation tasks. In an embodiment, the animation system250factors for the level of destructive detail when animating actions in the gameplay session.

The sound module240generates 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 system250or gameplay session information from the level manager245may be sent to the sound module240to enable the sound module240to produce sound. The sound module240sends sound data to the sound controller124.

The graphics rendering module255renders graphics from the animation system250and level manager245to generate an image of the gameplay session. For example, the graphics rendering module255receives a scene file from the animation system250and a game object from the level manager245. The graphics rendering module255sends graphical data to the GPU114to render images on a display, e.g., a display of the client device110or a display connected to the client device110, via the display controller120.

The OS260manages computer hardware and software resources. Specifically, the OS260acts as an intermediary between programs and the computer hardware. For example, the OS260can perform basic tasks, such as recognizing input from the user interface122and sending output to the display controller120.

The content source270in the secondary memory118includes various data, including graphics data272, audio data274, event data276, and object data278. Depending upon the embodiment, some or all of the data in the content source270may instead be in the primary memory116. The content source270sends data to the level manager245upon receiving a request for the data from the level manager245. For example, upon the level manager245receiving a request for information regarding graphics data from the destruction manager230, the level manager245requests the information from the content source270, which sends the information to the level manager245.

The graphics data272includes graphics data, e.g., polygon meshes and one or more sets of shards, for one or more game objects. As described in greater detail below with reference toFIG. 3, each game object is associated with one or more sets of shards, and each set of shards for a game object is associated with a different level of destructive detail.

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

The event data276includes 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 data278includes 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 polygon mesh and one or more sets of shards. In an embodiment, the object data278includes the graphics data272.

FIG. 3is a block diagram of the graphics data272used by the software modules in the memory of the client device ofFIG. 1, according to an embodiment. The graphics data272includes destruction data300, which defines sets of shards for game objects. Each game object is associated with one or more sets of shards, each corresponding to a different level of destructive detail. In an embodiment, there are three levels of destructive detail. A first level of destructive detail (“Level 1”) is the lowest level of detail with the fewest shards, a second level of destructive detail (“Level 2”) is the middle level of detail with a middle amount of shards, and a third level of destructive detail (“Level 3”) is the highest level of detail with the greatest number of shards.

Different game objects may have different sets of shards including different numbers and/or configurations of shards. For example, a first game object (Object 1) and a second game object (Object 2) are each associated with three sets of shards. For each object, Level 1 data is a set of shards corresponding to Level 1, Level 2 data is a set of shards corresponding to Level 2, and Level 3 data is a set of shards corresponding to Level 3. For example, Object 1's Level 1 data may include 100 shards, while Object 2's Level 1 data may include 110 shards. Object 1's Level 2 data and Object 2's Level 2 data may both include 1000 shards, but have different configurations—e.g., if Object 1 represents a building and Object 2 represents a mountain, then Object 1's Level 2 data may fit together into a cuboid, whereas Object 2's Level 2 data may fit together into a pyramidoid. Object 1's Level 3 data may include 10,000 shards and Object 2's Level 3 data may include 10,110 shards. In an embodiment, each shard at a greater level of detail represents a portion of a shard at a lower level of detail—e.g., each shard in Object 1's Level 3 data is a portion of a shard from Object 1's Level 2 data.

The game system200does not dynamically determine the sets of shards, but rather uses premade sets of shards included in the destruction data300. Upon the game system200launching a gameplay session, the game system200determines which game objects are or could be involved in the gameplay session, and loads them into primary memory116, e.g., at the level manager245. In an embodiment, performance data for a gameplay session, specifically the total number of shards kept in memory, is based upon the total number of shards loaded into the primary memory116for the gameplay session.

AlthoughFIG. 3describes using three different levels of destructive detail, this is merely illustrative. More than three levels of destructive detail or only two levels of destructive detail may also be used.

FIGS. 4A through 4Cillustrate shards in different levels of destructive details for the same game object, according to an embodiment.FIG. 4Aillustrates the destruction data300of a game object, Object410, at Level 1. At this level, the destruction data300for the game object—the set of shards for the Object410—includes a single shard420. This shard420may be the polygon mesh representing the undestroyed Object410, and destruction of Object410may involve a removal of Shard420from the gameplay session, e.g., the client device ceases rendering the shard420.

FIG. 4Billustrates the destruction data of Object410at Level 2. At this level, the destruction data300includes three shards430, where each shard430is a portion of the shard420, together representing the full Object410graphically represented by shard420. Destruction of Object410at Level 2 may therefore involve the shards430falling apart. For example, the Object's410destruction within a game session may involve splitting into the three shards430, each landing in a different location.

FIG. 4Cillustrates the destruction data of Object410at Level 3. At this level, the destruction data300includes 21 shards, including shards440A-B. Each shard at this level is a portion of a shard at Level 2. For example, shards440A-B are both portions of shard430A. Destruction of Object410at Level 3 may involve the 21 shards falling apart, in a more detailed and complex manner than the three shards430at Level 2. For example, if the Object410is a window, and its destruction is a rock breaking through the window, at Level 2, the destruction may be the rock breaking the window into three pieces, whereas at Level 3, the destruction may be the rock shattering the window into 21 pieces.

FIG. 5is a flowchart illustrating a process for implementing the techniques described herein, according to an embodiment. The client device110receives502information on game objects for destruction. The information may be a set of game objects or references to game objects that the client device110is to render the destruction of within a gameplay session running upon the client device110.

The client device110determines504a level of destructive detail for the game objects based on performance data. The level of destructive detail corresponds to a number or configuration of shards for the game objects to destruct into. The performance data is one or more metrics tracking computing performance of the client device110. The level of destructive detail may further be based on a predictive model estimating performance of the client device or on a rate of active shard creation, depending upon the embodiment.

The client device110retrieves506graphics data for the game objects based on the determined level of destructive detail. For example, for each game object to be destructed, the client device110retrieves a set of shards corresponding to the level of destructive detail. The set of shards may be stored in primary memory116and/or secondary memory118of the client device110.

The client device110renders508the destruction of the game objects using the retrieved graphics data. For example, the client device110renders508each game object for destruction as breaking into the set of shards retrieved for the game object.

In an embodiment, the level of destructive detail is one of two or more levels of destructive detail, and each level of destructive detail defines a different number or configuration of shards for game objects to destruct into.

In an embodiment, retrieving the graphics data for the game objects based on the determined level of destructive detail involves the client device110determining, for each game object, a set of shards for the game object corresponding to the determined level of destructive detail, and retrieving the graphics data of the determined set of shards. Each game object is associated with two or more sets of shards, where each set of shards for the game object corresponds to a different level of destructive detail and includes a different number or configuration of shards than other sets of shards for the game object.

In an embodiment, the performance data includes at least one of a frame rate, a number of active shards in the gameplay session, and a total number of shards loaded into a memory of the client device.

In an embodiment, determining the level of destructive detail for the game objects based on performance data includes the client device110generating a score derived from the performance data and identifying a level of destructive detail based on the score as compared to one or more thresholds. Each threshold corresponds to a different level of destructive detail. In an embodiment, the one or more thresholds are based on performance capabilities of the client device110.

In an embodiment, the client device110maintains a predictive model for estimating performance of the client device, based on at least one of recent and scheduled game operations. The client device110estimates performance of the client device based on the predictive model and further bases the determination of the level of destructive detail for the game objects on the estimated performance of the client device.

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.