U.S. Pat. No. 11,524,237

DETAILED DESCRIPTION OF THE INVENTION

The invention described herein relates to a system and method of simulating gameplay of non-player characters distributed across networked end user devices. The system may identify end user devices that are connected to the system through a network and are available to participate in a simulation in which each participating end user device is provided with one or more NPCs to be executed. An end user device may be available to participate when it has sufficient computing capacity, such as when in an idle or standby state or during “low load” conditions like when a player is waiting in an online lobby or browsing an online marketplace. As such, the system may leverage spare computing capacity of networked end user devices to execute NPCs at networked end user devices during a simulation. In this manner, the behavior of an NPC may be tested using real-world conditions that may affect gameplay, such as a network connection quality, user-to-user game engine coordination and data exchanges, and/or other real-world conditions associated with networked end user devices.

While aspects of the invention may be described herein with reference to various game levels or modes, characters, roles, game items, etc. associated with a First-Person-Shooter (FPS) game, it should be appreciated that any such examples are for illustrative purposes only, and are not intended to be limiting. The system and method described in detail herein may be used in any genre of multiplayer video game, without limitation

Exemplary System Architecture

FIG.1illustrates a system100for simulating gameplay of non-player characters distributed across networked end user devices140, according to one implementation of the invention. In one implementation, system100may include a computer system110, a matchmaking system132, a network topology system134, a debugging system136, one or more end user devices140(illustrated as end user devices140A,140B, . . . ,140N), one or more databases150, and/or other components.

Computer System110

Computer system110may be configured as a server (e.g., having one or more server blades, processors, etc.), a gaming console, a handheld gaming device, a personal computer (e.g., a desktop computer, a laptop computer, etc.), a smartphone, a tablet computing device, and/or other device that can be programmed to host simulated gameplay of NPCs across end user devices140.

Computer system110may include one or more processors112(also interchangeably referred to herein as processors112, processor(s)112, or processor112for convenience), one or more storage devices114(which may store a test game engine116and a NPC gameplay simulator120), and/or other components. Processors112may be programmed by one or more computer program instructions. For example, processors112may be programmed by NPC gameplay simulator120and/or other instructions (such as test game engine116).

Test Game Engine

In an implementation, test game engine116may include a modified version of a production game engine. For example, a first set of functions provided by a test game engine may be different from a second set of functions provided by the production game engine. Such differences can include, without limitation, an added function, a removed function, a updated or modified function, and/or other changes to the functionality of a production game engine. A production game engine may be used to host networked video games played through one or more end user devices140in a production, or non-testing, environment (e.g., Microsoft's Xbox LIVE®, Sony's PlayStation Network®, and PC-based game networks). Generally speaking, the functions provided by a production game engine may include, without limitation, a physics function provided by a physics engine, an AI function provided by an AI engine, an environmental rendering function provided by an environmental engine, an A/V rendering function provided by an A/V rendering engine, a P2P function provided by a P2P communication engine, and/or other functions. It should be noted that a production game engine may be used during one or more simulated NPC gameplay sessions as well.

In one example, test game engine116may include a physics engine, an AI engine, and an environmental engine, while excluding an A/V rendering engine and a P2P communication engine. Other functions may be included or excluded as well. In the foregoing example, test game engine116may include a minimal set of functionality required to simulate gameplay, while excluding other functions not needed in the context of NPC gameplay simulation (such as audio/visual rendering). In other examples, test game engine116may include A/V rendering in order to test the effects of, for example, certain graphical or audio renderings on network latency during gameplay. In still other examples, test game engine116may include all (or substantially all) of the functionality of a production game engine, effectively using a production game engine for NPC gameplay simulation.

NPC Gameplay Simulator

NPC gameplay simulator120may include instructions that program computer system110. In general, NPC gameplay simulator120may cause a simulated NPC gameplay session to occur. A simulated NPC gameplay session (hereinafter also referred to as “simulation” or “test”) is one in which NPCs distributed across (e.g., distributed to and executing at) one or more (typically several) end user devices140are simulated to play a networked video game that uses test game engine116. A simulation may be associated with a discreet goal or time after which the simulation ends (e.g., a capture-the-flag style game between opposing teams of players, conclusion of an in-game sporting event, etc.), continuous gameplay in which no particular terminating goal is provided (e.g., a simulation of a massive multiplayer online game), and/or other types of gameplay that may be simulated. Furthermore, multiple simulations may be run simultaneously, each using different sets of end user devices140.

The instructions of NPC gameplay simulator120may include, without limitation, a simulation parameter module122, a pooling engine124, a gameplay initiator126, a simulation analytics engine128, and/or other instructions that program computer system110to perform various operations, each of which are described in greater detail herein. As used herein, for convenience, the various instructions will be described as performing an operation, when, in fact, the various instructions program the processors112(and therefore computer system110) to perform the operation.

Obtaining a Simulation Specification to Setup a Simulation

In an implementation, simulation parameter module122may obtain a simulation specification used to set up a simulation. The simulation specification may include one or more simulation parameters that describe the simulation. For example, and without limitation, the one or more simulation parameters may specify a game level that should be used in the simulation, a game environment, a game difficulty, a number of NPCs (e.g., a number of NPCs that should run at a given end user device140, a total number of NPCs that should be used, etc.), an NPC characteristic that should be used (e.g., an NPC level of skill, an NPC player role, whether NPCs should be cooperative or adversarial, etc.), a minimum number of end user device140that should be used, a set of end user devices140that should be used (e.g., based on geography, type of network, Internet Service Provider, whether a wireless or wired connection is used, an identification of a game hosting service, end user device version, or type of Network Address Translation (NAT) connection), one or more servers that should be used to host a simulation, a time-based parameter (e.g., that specifies a date/time in which simulation should be run, a periodicity in which to execute simulations, etc.), a network-based parameter (e.g., that specifies a network latency that should be tested), a version-based parameter (e.g., that specifies a particular version of software or hardware of end user devices140that should be tested), and/or other parameters.

The simulation parameter module122may obtain the one or more simulation parameters from one or more parties and/or for different purposes. For instance, simulation parameter module122may obtain the one or more simulation parameters from a simulation designer (e.g., a human user that specifies simulations), a predefined simulation specification, a matchmaking system132, a network testing system134, a debugging system136, and/or other party.

A simulation designer may design a simulation for NPCs distributed across end user devices140. The predefined simulation specification may be used to predefine simulation parameters for testing. For example, a simulation designer or others may specify simulation parameters for a simulation and store the simulation parameters in a predefined template. Different sets of predefined simulation specifications may be used for different purposes (e.g., one simulation specification may be used to test during evening hours while another simulation specification may be used to test during morning hours). The simulation parameters and/or predefined simulation specifications may be stored in a simulation parameter database, such as a database150.

Pooling End User Devices to Participate in Simulated NPC Gameplay

In an implementation, pooling engine124may identify one or more end user devices140that are available to participate in a simulation. To do so, pooling engine124may obtain a listing of end user devices140that are accessible through network102. For example, the listing may include end user devices140that have logged onto a production environment to play networked video games. For instance, upon receiving a log on from an end user device140to play networked video games, a production environment may store device information associated with the end user device140. The device information may include, without limitation, identifying information used to identify the device, a current state of the device, a geographic location of the device, a type of network used by the device, an ISP through which the device is connected to the network, whether a wireless or wired connection is used, an identification of a game hosting service, end user device version, or type of Network Address Translation (NAT) connection, and/or other information that describes the device and/or network used by the device. At least some of the device information may be available from other information sources (e.g., a user or device profile) as well.

Pooling engine124may determine that a given end user device140(among the listing of end user devices) is available to participate in a simulation based on its current state, which may indicate its computing capacity (e.g., processor capacity, memory availability, etc.). An end user device140may be available to participate in a simulation when its available computing capacity exceeds a minimum required capacity for participation in the simulation. This may occur, when, for example, a user is waiting a virtual game lobby, the end user device is in a standby or idle state, or the end user device is otherwise in a state in which computing capacity is above the minimum required capacity. The minimum required capacity may be predefined and/or configurable. For instance, a default minimum required capacity may be specified by a simulation parameter. Alternatively or additionally, pooling engine124may determine the minimum required capacity based on one or more characteristics of the simulation. The one or more characteristics may include, without limitation, a number of NPCs to run on an end user device140, a type of gameplay to be simulated, and/or other characteristics.

In some instances, a given end user device140may participate in a simulated NPC gameplay session (involving one or more NPCs) whether or not the end user device is also involved in a production gameplay session (e.g., one in which a user is playing a game). Furthermore, a given end user device may simultaneously participate in multiple NPC gameplay sessions (each of which may be used to test the same or different changes to the game engine, changes to the game configuration files or game content, etc.). For example, an NPC specification may specify one or more NPCs to be hosted in a single simulated NPC gameplay session at end user device140. In another example, an NPC specification may specify different sets of one or more NPCs to be hosted in multiple simulated NPC gameplay sessions at end user device140. Alternatively or additionally, a given NPC specification may correspond to a single simulated NPC gameplay session such that multiple NPC specifications correspond to multiple simulated NPC gameplay sessions.

In an implementation, pooling engine124may target a particular end user device140(subject to its availability) to participate in a simulation based on one or more simulation parameters. A particular end user device140may be targeted for reasons discussed herein (e.g., to test a network connection used by the device, debug a version of software or hardware executing on the device, to test new content or configurations of the software, etc.).

In an implementation, pooling engine124may invite an available end user device140to participate in the simulation. For example, pooling engine124may transmit, to an available end user device140, a request to join a simulation. Upon receipt of an acceptance of the invitation, pooling engine124may add the available end user device140to a pool of available devices. Alternatively, pooling engine124may simply add an available end user device140to the pool of available devices.

Initiating Simulated NPC Gameplay and Providing NPC Specifications to End User Devices

In an implementation, simulation manager126may initiate a simulation. A simulation may be triggered on-demand (e.g., based on an input from a human user or other input) and/or periodically according to a schedule. Regardless of the manner in which a simulation is triggered, simulation manager126may initiate a simulation when a sufficient number of participating end user devices140has been pooled. An end user device140is a “participating end user device” when it satisfies any relevant simulation parameter (and has been pooled for participation in a simulation).

To initiate a simulation, simulation manager126may identify and provide one or more NPC specifications to participating end user devices140. An NPC specification may include one or more NPC parameters, NPC logic (e.g., AI software instructions), an NPC identifier, and/or other information used by end user device140to instantiate and control (hereinafter, “execute” or “executing” for convenience) one or more NPCs during a simulation. The one or more NPC parameters may specify one or more characteristics of an NPC, which may be used by a participating end user device140to configure an NPC. NPC logic may include predetermined instructions such that end user device140needs only execute the NPC logic (after compiling the NPC logic, if necessary). In some instances, NPC logic may be pre-stored at end user device140, in which case an NPC specification may include an NPC identifier that identifies pre-stored NPC logic that should be used in a simulation.

An NPC specified by an NPC specification may include one or more player characteristics of a human player character or NPC. For instance, a given NPC may have a particular role (e.g., a sniper role) in a game, a particular skill level, a set of in-game items (e.g., an NPC may be configured to possess an in-game rifle and an in-game handgun, etc.), and/or other characteristics that conventional human players may possess.

Regardless of the manner in which an NPC is specified, each NPC specified by an NPC specification may be the same as or different from another NPC (in instances in which multiple NPCs are specified by the NPC specification). Furthermore, an NPC specification may specify that two or more NPCs act in an adversarial or cooperative relationship with respect to one another. Additionally, an NPC specification may specify that a first set of one or more NPCs executed at a first end user device140may act in an adversarial or cooperative relationship with respect to a second set of one or more NPCs executed at a second end user device140. In this manner, an NPC specification may specify that various types of multiplayer interactions may be simulated by the NPCs across one or more end user devices140. In these instances, simulation manager126may provide a first NPC specification to a first end user device140(e.g., one that specifies a first set of one more NPCs) and a second (different) NPC specification to a second end user device140(e.g., one that specifies a second (different) set of one more NPCs).

Managing Participating End User Devices and NPCs During Simulated NPC Gameplay

Upon initiation of a simulation, simulation manager126may cause test game engine116to interact with various NPCs executing at participating end user devices140. For example, during a simulation, each participating end user device140may instantiate its set of NPCs and execute each instance of an NPC against test game engine116. In this manner, gameplay among NPCs executing at participating end user device140may be simulated using test game engine116. In an implementation, simulation manager126may assign an identifier for each instance of an NPC executing at a participating end user device140for a given simulation (as used hereinafter, an “NPC executing at a participating end user device140” and similar language refers to an instance of an NPC that is instantiated by a participating end user device140). Simulation manager116may maintain an NPC registry of NPC instances executing at participating end user devices140so that it may monitor each instance, as well identify a participating end user device140that executes a given NPC instance.

In an implementation, simulation manager126may monitor the participating end user devices140to ensure that the number of participating end user devices140continues to exceed a minimum number during a simulation. This is because a given participating end user device140may become unavailable during a simulation and be kicked out of the simulation so that end users are not impacted by simulations executing on their end user devices140. Either the participating end user device140or simulation manager126may initiate the kick out. A participating end user device140may become unavailable when it changes states such that the minimum required computing capacity is no longer available (e.g., when an end user such as a human operator of a participating end user device140begins playing a game). Similarly, other (non-participating) end user devices140may enter an available state (e.g., when their corresponding end users stop playing a game) and may be pooled. As such, end user devices140may continually be pooled, de-pooled (e.g., removed from a pool), and kicked out from simulations.

In an implementation, simulation manager126may select a pooled end user device140to replace a participating end user device140that was kicked out from the simulation (hereinafter, a “kicked out end user device140”). To do so, simulation manager126may provide a replacement end user device140with an NPC specification that was provided to the kicked out end user device140. In this manner, one or more NPCs that were executing on the kicked out end user device140may be executed on the replacement end user device140. The replacement end user device140may include an end user device140that is already participating and has additional computing capacity to execute the one or more NPCs that were executing on the kicked out end user device and/or may be a newly invited end user device.

In an implementation, simulation manager126may add or remove participating end user devices140for other reasons as well. For instance, simulation manager126may determine that computational requirements of a simulation are higher (or lower) than expected or that the simulation is at a point where more (or less) end user devices are required to execute the simulation. In these instances, simulation manager126may add or remove participating end user devices140from a given simulation, as appropriate.

In an implementation, to preserve a current state of a simulation, simulation manager126may update an NPC specification that was provided to a kicked out end user device140and provide the updated NPC specification to a replacement end user device140. During the course of a simulation, for example, an NPC state may be affected by events of the simulation. For instance, a health of an NPC may be reduced during in-game combat (or increased if the NPC acquired a health power-up) or in-game ammunition carried by the NPC may be exhausted (or increased if the NPC acquired ammunition during the simulation). Other characteristics of the NPC may be changed during simulated gameplay as well.

An end user device140executing the NPC and/or simulation manager126may maintain an NPC state. For instance, before end user device140is kicked out, the latest known NPC state before the kick out may be preserved and used to update a corresponding NPC specification. In a particular example, simulation manager126may periodically update an NPC registry with a current state for each NPC executing at participating end user devices140. As such, after such update, the NPC registry may include an NPC state for NPCs executing at participating end user devices140during a simulation.

Simulation manager126may identify a set of one or more NPCs executing at an end user device140to be kicked out (e.g., based on the NPC registry), obtain an NPC state for each NPC among the set of one or more NPCs (e.g., from the NPC registry), and generate an NPC specification based on the obtained NPC states. As such, the newly generated NPC specification is “updated” with respect to the original NPC specification provided to the end user device140to be kicked out. Simulation manager126may provide the updated NPC specification to the replacement end user device140. In this manner, a given simulation may be unaffected when an end user device140is kicked out.

Other results of the simulation may likewise be carried over from a kicked out end user device140to a replacement end user device140. For instance, if an NPC executing at a kicked out end user device140spawned another NPC such that the kicked out end user device140operated an additional NPC, the NPC specification may be updated to include the newly spawned NPC (which may also be reflected in the NPC registry). Likewise, if an NPC was terminated (e.g., killed during in-game combat) or otherwise should be removed, then the NPC specification may be updated to remove that NPC.

Analyzing Simulated NPC Gameplay

In an implementation, simulation analyzer128may monitor the simulation and obtain one or more simulation metrics associated therewith. The simulation metrics may include, without limitation, an NPC performance metric, a gameplay quality metric, a network performance metric that indicates a quality of a network connection, a fault metric, and/or other metric that may characterize one or more aspects of the simulation.

An NPC performance metric may indicate a performance of an NPC, which may be relative to other NPCs and/or game AI during a simulation. For example, an NPC performance metric may include, without limitation, a number of levels achieved by an NPC, a number of in-game kills, a number of points scored, a number in-game items acquired, a lap time achieved by an NPC driver, and/or other metric by which a player performance (whether a human player or NPC) may be assessed.

A gameplay quality metric may indicate a quality of gameplay during a simulation. The gameplay quality metric may be used as a proxy to determine whether a human player, if playing with/against an NPC, would enjoy the gameplay experience. For instance, a gameplay quality metric may include, without limitation, a length of a simulation (where longer gameplay sessions may indicate a greater quality of gameplay), an indication of whether adversarial gameplay was lopsided (where more evenly matched gameplay may indicate a greater quality of gameplay), and/or other metric that may indicate a quality of gameplay.

A network performance metric may indicate a quality of a network connection used by a participating end user device140during a simulation. For instance, a network performance metric may include, without limitation, a network latency measured during a simulation, a number or rate of network errors that occurred during the simulation, and/or other metric may be used to measure a quality of a network connection used during the simulation. Other performance metrics may be used in the same way as network, such as measurements of CPU or GPU usage, frame rate sustained at various times during simulated gameplay, number of transactions required with a server, etc.

A fault metric may indicate a fault related to software or hardware (other than network errors) that may have occurred during a simulation. For instance, a fault metric may include, without limitation, a number of errors that occurred during a simulation, a type of error that occurred during the simulation, and/or other abnormal execution conditions that may have occurred during the simulation.

Applying the Analysis of Simulated NPC Gameplay

Various parties may use the analysis (e.g., the various types of simulation metrics) from simulation analyzer128in various ways and in various contexts. For example, various systems such as matchmaking system132, network testing system134, debugging system136, and/or other systems may use one or more simulation metrics in various ways. These and other systems may be separate from or integrated with computer system110and may each include one or more processors programmed using one or more computer program instructions. The following examples of uses and contexts of simulation metrics are described by way of illustration and not limitation, as other uses and contexts will be apparent based on the disclosure provided herein.

Matchmaking Contexts

In an implementation, the various simulation metrics may be used to characterize how an NPC will perform during gameplay, which may or may not be affected by a quality of network connections between end user devices140. For example, matchmaking system132may use one or more simulation metrics to characterize an NPC, assess a quality of a match between two or more NPCs, and/or otherwise assess a performance of an NPC during a simulation.

Matchmaking system132may generate or update an NPC specification (e.g., based on input from a game designer or other user) and may assess how an NPC will perform during gameplay. To this end, matchmaking system132may provide the NPC specification to NPC gameplay simulator120as a simulation parameter, along with any other simulation parameters that specify other simulation conditions that should be used to test an NPC. In response, NPC gameplay simulator120may provide the NPC specification to one or more end user devices140during a simulation and then observe a performance of a corresponding NPC. Such performance may be assessed based on, for example, an NPC performance metric, a gameplay quality metric, and/or other simulation metrics.

Alternatively or additionally, matchmaking system132may determine a quality of a match of two or more NPCs. For instance, matchmaking system132may match together two or more NPCs to assess how well they play with one another in a cooperative or an adversarial relationship. In a particular example, matchmaking system132may use the simulation metrics (e.g., an NPC performance metric, a gameplay quality metric, a network performance metric, etc.) to assess how well a matched team of NPCs (which may be composed of identical NPCs or different types of NPCs) cooperatively play together. In another example, matchmaking system132may use the simulation metrics to assess how well a first set of one or more NPCs play against a second set of one or more NPCs. In the foregoing examples, by assessing different permutations of matches, matchmaking system132may be able to discern which NPCs are effective (e.g., based on an NPC performance metric), either individually or as a member of a team. In this manner, matchmaking system132may identify an NPC that should be matched with other NPCs or with human players during production versions of a networked video game. In some instances, matchmaking system132may incorporate a network performance metric to assess whether a given NPC should be provided to an end user device140during a production run of a networked video game. For example, matchmaking system132may determine that a particular NPC (e.g., one that is associated with time-sensitive actions) should not be teamed with a human player operating at an end user device140with known latency problems, as observed from one or more network performance metrics.

Quality of Network Connections Contexts

In an implementation, the various simulation metrics may be used to characterize a quality of network connections used by end user devices140. For example, network testing system134may, over time, obtain network performance metrics (provided by simulation analyzer128) that indicate a quality of network connections across end user devices140that participate in various simulations. As NPC gameplay simulator120initiates more simulations, more network quality data may be collected.

Network testing system134may build a network quality map of the quality of network connections based on the network performance metrics. Such a network quality map may be based on a per node basis (e.g., network quality of a network connection used by an individual end user device140) and/or grouped by a characteristic (e.g., by geography, a particular network used, whether a wireless or wired connection is used, an identification of a game hosting service, end user device version, or type of Network Address Translation (NAT) connection, Internet Service Provider, and/or other grouping). In this manner, network testing system134may obtain information that indicates a quality of a network connection used by an individual end user device140and/or by groups of end user devices140.

Network testing system134may use the network quality map to identify end user devices140for which network quality information is unavailable or sparse. For instance, network testing system134may obtain an identification of all end user devices140that have participated in a networked video game in a production environment and identify those devices in which network quality information is unavailable or sparse. Network testing system134may generate and provide one or more simulation parameters that specify that the identified devices should be targeted for testing during a simulation (subject to their availability). In response, NPC gameplay simulator120may initiate simulations in which the identified devices are invited to participate (e.g., the identified devices may take priority over other devices to participate in a given simulation). In this manner, network testing system134may generate comprehensive network quality maps of end user devices140that participate in networked video games. The network quality maps may be updated as more simulations are initiated over time.

A network quality map may be used by matchmaking system132to create a match (e.g., based on, for example, network latency) of players on two or more end user devices140. In another example, a network quality map may be used by NPC gameplay simulator120to avoid using end user devices140with known poor quality network connections (or purposefully using such end user devices140). Other uses of the network quality map may be used as well.

Debugging Contexts

In an implementation, one or more simulation metrics may be used to debug software and/or hardware in relation to networked video games. For example, debugging system136may use one or more simulation metrics to debug a new or updated component associated with networked video games. new or updated NPC, a new or updated game logic, a new or updated configuration file, a new or updated content package, a new or updated software package (e.g., operating system, application, GPU shader, etc.) at end user device140, server hardware, hardware if end user device140, and/or other component associated with networked video games. For instance, one or more fault metrics may be used to determine whether errors occurred during a simulation, the nature of such errors, and/or other information related to a fault condition. Such errors may be associated with a new or updated component.

For a new or updated NPC, for example, a certain outcome (e.g., an expected NPC performance) or behavior (e.g., perform some action) may be expected by a user, such as a developer of the NPC. A simulation metric (e.g., an NPC performance metric) or a fault metric (e.g., that indicates whether the action was performed) may be used to determine whether the expected outcome or behavior occurred during a simulation in which the NPC was simulated to play. Other examples of using fault metrics in association with a new or updated component may likewise be performed. For example, a new version of software or hardware of an end user device140may be invited to participate in a simulation to observe whether any expected outcomes or behaviors of NPCs executing thereon (or other expected game events) have occurred during the simulation.

End User Devices140

End user device140may be configured as a gaming console, a handheld gaming device, a personal computer (e.g., a desktop computer, a laptop computer, etc.), a smartphone, a tablet computing device, and/or other device that can be programmed to participate in simulated gameplay of NPCs. Although not illustrated inFIG.1, end user devices140may include one or more physical processors programmed by computer program instructions. For example, an agent142(illustrated as Agents142A,142B, . . . ,142N) may program one or more physical processors of end user device140to receive an NPC specification, instantiate one or more NPCs specified by the NPC specification, and execute one or more NPC instances during a simulation.

Although illustrated inFIG.1as a single component, computer system110and end user device140may each include a plurality of individual components (e.g., computer devices) each programmed with at least some of the functions described herein. In this manner, some components of computer system110and/or end user device140may perform some functions while other components may perform other functions, as would be appreciated. The one or more processors112may each include one or more physical processors that are programmed by computer program instructions. The various instructions described herein are exemplary only. Other configurations and numbers of instructions may be used, so long as the processor(s)112are programmed to perform the functions described herein.

Furthermore, it should be appreciated that although the various instructions are illustrated inFIG.1as being co-located within a single processing unit, in implementations in which processor(s)112includes multiple processing units, one or more instructions may be executed remotely from the other instructions.

The description of the functionality provided by the different instructions described herein is for illustrative purposes, and is not intended to be limiting, as any of instructions may provide more or less functionality than is described. For example, one or more of the instructions may be eliminated, and some or all of its functionality may be provided by other ones of the instructions. As another example, processor(s)112may be programmed by one or more additional instructions that may perform some or all of the functionality attributed herein to one of the instructions.

The various instructions described herein may be stored in a storage device114, which may comprise random access memory (RAM), read only memory (ROM), and/or other memory. The storage device may store the computer program instructions (e.g., the aforementioned instructions) to be executed by processor112as well as data that may be manipulated by processor112. The storage device may comprise floppy disks, hard disks, optical disks, tapes, or other storage media for storing computer-executable instructions and/or data.

The various databases150described herein may be, include, or interface to, for example, an Oracle™ relational database sold commercially by Oracle Corporation. Other databases, such as Informix™, DB2 (Database 2) or other data storage, including file-based, or query formats, platforms, or resources such as OLAP (On Line Analytical Processing), SQL (Structured Query Language), a SAN (storage area network), Microsoft Access™ or others may also be used, incorporated, or accessed. The database may comprise one or more such databases that reside in one or more physical devices and in one or more physical locations. The database may store a plurality of types of data and/or files and associated data or file descriptions, administrative information, or any other data.

The various components illustrated inFIG.1may be coupled to at least one other component via a network, which may include any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN (Storage Area Network), a MAN (Metropolitan Area Network), a wireless network, a cellular communications network, a Public Switched Telephone Network, and/or other network. InFIG.1, as well as in other drawing Figures, different numbers of entities than those depicted may be used. Furthermore, according to various implementations, the components described herein may be implemented in hardware and/or software that configure hardware.

FIG.2depicts a process200of simulating gameplay of non-player characters distributed across networked end user devices140, according to an implementation of the invention. The various processing operations and/or data flows depicted inFIG.2(and in the other drawing figures) are described in greater detail herein. The described operations may be accomplished using some or all of the system components described in detail above and, in some implementations, various operations may be performed in different sequences and various operations may be omitted. Additional operations may be performed along with some or all of the operations shown in the depicted flow diagrams. One or more operations may be performed simultaneously. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

In an operation202, process200may include obtaining one or more simulation parameters. The one or more simulation parameters may be predefined (e.g., default), provided by a simulation designer (e.g., a human operator), provided by a matchmaking system132to test matches or assess NPC performance, provided by a network testing system134to test or otherwise determine a quality of network connections, provided by debugging system136to debug new or updated components related to networked video games, and/or other source.

In an operation204, process200may identify an end user device that is available to participate in a simulation. For example, process200or an external process may monitor an end user device that is connected to a production environment and determine when a computing capacity of the end user device exceeds a minimum value. Put another way, process200or an external process may determine that usage of computing capacity of the end user device falls below a maximum value.

In an operation206, process200may request the identified end user device to participate in the simulation. For example, process200may provide an agent142operating at the identified end user device with a request to participate in the simulation.

In an operation208, process200may determine whether the end user device has accepted the invitation. Responsive to a determination that the end user device has declined the invitation, processing may return to operation204, where an end user device that is available is identified. Responsive to a determination that the end user device has accepted the invitation, processing may proceed to an operation210, were the end user device is added to a pool of participating end user devices. In some implementations, process200may simply add an available end user device to the pool of participating end user devices without requesting to do so (thereby skipping operations208and210).

In an operation212, process200may determine whether the number of participating end user devices in the pool meets or exceeds a threshold value. For example, the threshold value may include a number of participating end user devices that should be used for the simulation. The threshold value may predefined, specified by a simulation parameter, dynamically determined by process200based on requirements of the simulation, and/or otherwise obtained by process200.

Responsive to a determination that the number of participating end user devices in the pool does not exceed a threshold value, process200may return to an operation204, where an end user device that is available is identified. Responsive to a determination that the number of participating end user devices in the pool exceeds a threshold value, process200may provide an NPC specification to one or more participating end user devices in an operation214. Process200may provide different participating end user devices with different NPC specifications. For example, a first participating end user device may be provided with a first NPC specification, while a second participating end user device may be provided with a second (different) NPC specification.

In an operation216, process200may initiate a simulation based on the one or more simulation parameters. For example, process200may cause a connection to be established between computer system110, which may host the simulation using test game engine116, and the participating end user devices.

In an operation218, process200may conduct simulation by, for example, receiving in-game input from one or more NPCs executing at one or more participating end user devices and facilitating interaction between the one or more NPCs and the test game engine. An NPC executing at a participating end user device may play: in cooperation with another NPC (either at the same or different participating end user device), in an adversarial relationship with another NPC (either at the same or different participating end user device), against the test game engine (with or without cooperation from other NPCs), and/or other ways that simulate single and multiplayer networked video gameplay.

In an operation220, process200may collect one or more simulation metrics related to the simulation, which may terminate at the conclusion of a session terminating event such as, without limitation, one team of NPCs defeating another team, achievement of an objective, a period of time having elapsed, and/or other terminating event.

It should be noted that process200may be performed at periodic intervals (e.g., simulations run periodically), on-demand (e.g., initiated by a human operator, by an event such as a number of available end user devices becoming available), and/or other simulation triggering event.

FIG.3depicts a process300of replacing an end user device140participating in a simulation that was kicked out of the simulation, according to an implementation of the invention. The various processing operations and/or data flows depicted inFIG.3(and in the other drawing figures) are described in greater detail herein. The described operations may be accomplished using some or all of the system components described in detail above and, in some implementations, various operations may be performed in different sequences and various operations may be omitted. Additional operations may be performed along with some or all of the operations shown in the depicted flow diagrams. One or more operations may be performed simultaneously. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

In an operation302, process300may monitor a simulation.

In an operation304, process300may determine whether a participating end user device140is no longer available (because a network connection to the participating end user device140has been dropped, participating end user device140has removed itself from participation in the simulation, process300determines that the computational requirements for participation are no longer satisfied by the participating end user device, in which case process300removes the participating end user device140from participation, etc.).

Responsive to a determination that all participating end user devices140remain available, process300may continue monitoring the simulation in operation302.

Responsive to a determination that a participating end user device140is no longer available, in an operation306, process300may generate an NPC specification for one or more NPCs that were executing on the end user device140that is no longer available. The NPC specification may reflect the latest known state of the one or more NPCs that were executing on the end user device140that is no longer available.

In an operation308, process300may identify an end user device140to replace the end user device140that was removed. For example, process300may identify an end user device140from among a listing of available devices that are available (e.g., satisfy the computational requirements for participation based on its current computational load) to participate in any simulation. The computational load may include, without limitation, a current processing usage, a physical memory (e.g., RAM) usage, and/or other computational loads that may be imposed on an end user device140.

In an operation310, process300may provide the NPC specification to the replacement end user device140. In this manner, the replacement end user device140may seamlessly execute any NPCs that were executing on the removed end user device140, as well as maintain the state of such NPCs at the time of removal.

FIG.4depicts a process400of an end user device140participating in a simulation by executing an NPC to simulate gameplay of the NPC in association with a test game engine116and NPCs executing at other end user devices over a network102, according to an implementation of the invention. The various processing operations and/or data flows depicted inFIG.4(and in the other drawing figures) are described in greater detail herein. The described operations may be accomplished using some or all of the system components described in detail above and, in some implementations, various operations may be performed in different sequences and various operations may be omitted. Additional operations may be performed along with some or all of the operations shown in the depicted flow diagrams. One or more operations may be performed simultaneously. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

In an operation402, process400may receive a request to participate in a simulation in which gameplay of an NPC is simulated using test game engine116. For example, process400may receive the request from computer system110.

In an operation404, process400may determine whether sufficient computing capacity are available at end user device140to participate (which may be separate from, but similar to, the computational resource determination made by process200). For example, and without limitation, process400may determine whether a processor load is sufficiently low and/or whether a memory (e.g., RAM) usage is sufficiently low. Alternatively or additionally, in an implementation, process400may prompt a user of end user device140to accept or decline the request. If a user has not responded to the prompt within a certain time period, then process400may automatically determine whether to accept the request.

Responsive to a determination that there is not sufficient computing capacity, in an operation406, process400may decline the request to participate. On the other hand, responsive to a determination that there is sufficient computing capacity, in an operation408, process400may accept the request to participate.

In an operation410, process400may obtain an NPC specification. For example, process400may receive the NPC specification from computer system110, which provides the NPC specification responsive to acceptance of the request to participate by process400.

In an operation412, process400may instantiate an NPC based on the NPC specification. For example, process400may obtain NPC parameters from the NPC specification, configure an NPC based on core NPC code locally stored at end user device140, and instantiate the NPC. Alternatively or additionally, process400may obtain NPC code (e.g., source code to be compiled, executable code already compiled, or interpreted code) and configure an NPC based on the NPC code. In whichever manner an NPC is configured and instantiated, process400may control the NPC locally on end user device140based on the NPC specification. In this manner, a behavior of an NPC may be dictated by the NPC specification. A given NPC gameplay simulation may therefore involve different NPCs each having their own unique behaviors.

FIG.5depicts a process500of terminating participation in a simulation, according to an implementation of the invention. The various processing operations and/or data flows depicted inFIG.5(and in the other drawing figures) are described in greater detail herein. The described operations may be accomplished using some or all of the system components described in detail above and, in some implementations, various operations may be performed in different sequences and various operations may be omitted. Additional operations may be performed along with some or all of the operations shown in the depicted flow diagrams. One or more operations may be performed simultaneously. Accordingly, the operations as illustrated (and described in greater detail below) are exemplary by nature and, as such, should not be viewed as limiting.

In an operation502, process500may monitor one or more processes occurring at an end user device140participating in a simulation.

In an operation504, process500may determine whether one or more participation terminating events have occurred based on the monitoring. A participation terminating event may include, without limitation, a minimum computational requirement for participation in the simulation is no longer satisfied, waking up from an idle or standby state, initiation of gameplay in a production environment, explicit input from a user to terminate participation, and/or other events that can cause terminate participation.

Responsive to a determination that one or more participation terminating events have not occurred, process500may return to operation502to continue monitoring the one or more processes.

Responsive to a determination that one or more participation terminating events have occurred, in an operation506, process500may terminate participation in the simulation. For example, process500may logoff or otherwise exit the simulation.

Other implementations, uses and advantages of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification should be considered exemplary only, and the scope of the invention is accordingly intended to be limited only by the following claims.