WO2024105579A1 - Emergent narrative system - Google Patents

Abstract

An emergent narrative system for implementing dynamic content for the game world of a computer game. System provides an architecture that allows players to experience a living, breathing, narrative-rich persistent game world where players can experience and change the game world through their interactions, referred to as "acts." Furthermore, gamers are able to experience changes driven by the acts of other players.

Description

EMERGENT NARRATIVE SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This invention claims priority to U.S. Provisional Application No. 63/426,523 filed on November 18, 2022.

BACKGROUND OF THE INVENTION

1. FIELD OF THE INVENTION

[0002] The present invention related to computer gaming system and, more specifically, to dynamic gaming environment that can change in response to player actions.

2. DESCRIPTION OF THE RELATED ART

[0003] Conventional computer games rely on stories that are linear and created in a singular way that can only be experienced once. Players, creators, and observers can only impact the lore, world, and narratives is a singular or limed fashion that can become tiresome or, at the very least, repetitive. As a result, there is a need for a system that can provide for a dynamic and ever-changing world in which players, creators, and observers impact the lore, world, and narratives that can be played over again with refreshingly different experiences.

BRIEF SUMMARY OF THE INVENTION

[0004] The present invention provides an emergent narrative system for implementing dynamic content for the game world of a computer game. The emergent narrative system allows for multiple people to experience and contribute to the story of the game that is persistent and ever-changing. The system allows players to experience a living, breathing, narrative-rich persistent game world in which players, creators, and observers impact the lore, world, and narratives. The present invention provides a system where players can experience a living, breathing, narrative-rich persistent gaming world where they experience and change the world through their interactions. Furthermore, gamers are able to experience changes of other players. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

[0005] The present invention will be more fully understood and appreciated by reading the following Detailed Description in conjunction with the accompanying drawings, in which:

[0006] FIG. l is a schematic of a modular narrative system according to the present invention.

[0007] FIG. 2 is a diagram illustrating an approach for storing actor data according to the present invention.

[0008] FIG. 3 is a diagram of the major subsystems of a character history system according to the present invention.

[0009] FIG. 4 is a flowchart of a process for executing a character history algorithm in a multi-service configuration.

[0010] FIG. 5 is a diagram of data flow during a single timeslice in a character history system according to the present invention.

[0011] FIG. 6 is a diagram of a computation of a single scenario with defined rules for impacting final results.

[0012] FIG. 7 is a first diagram of exemplary data used to represent passions for difference characters.

[0013] FIG. 8 is a second diagram of exemplary data used to represent passions for difference characters.

DETAILED DESCRIPTION OF THE INVENTION

[0014] Referring to the figures, wherein like numerals refer to like parts throughout, there is seen in FIG. 1 an emergent narrative system 10 for implementing dynamic content for the game world of a computer game so that players can experience a living, breathing, narrative-rich persistent game where players can experience and change the game world through their interactions and experience changes driven by other players. System 10 is organized according to several specific elements of an overall narrative. First, system 10 provides tasks 12, which describe the mapping of abstract, high level goals onto concrete steps which, when performed, accomplish those goals. System 10 further provides actors 14 and subjects 16, which describe game world elements, i.e., those things which physically or conceptually exist in the game world, in a tag based system which describes these elements as being composed of many different traits. System 10 additionally provides predicates 18, which describe the conditions under which an event can occur or, conditions under which an NPC can take an action. System 10 provides knowledge 20, which describes subsets of the world state which are accessible to individual NPCs in their decision making process. System 10 also provides an assembly engine 22, which is the process of combining the components of system 10 into a coherent model for decision making about how an actor can achieve its goals. Finally, system 10 includes an execution engine 24, which is the process which takes assembled task elements and picks those to perform now.

[0015] Tasks 12 describe abstract, high level goals of actors. This allows system 10 to create interesting, hand-crafted behaviors traditionally seen in game non-player characters (NPCs), without worrying about the high level structure of the world induced by the knowledge and predicate layer. The specification of a task is abstract, i.e., each task is identified by a globally unique ID. Tasks have more specific meanings in different contents, and in particular, tasks can map to a variety of concrete actions under those different contexts. Tasks have one or more participants, who are actors in the game world. Tasks are modular, so they require as few preconditions on the participants as possible. For example, a “fight” task can behave differently if there are no allies nearby, or if there is a war in the region in which the participants' faction is fighting, or if the participants' home town is being invaded.

[0016] Actors 14 describe world entities which can behave autonomously and perform tasks. Subjects 16 are world entities in which actors can take an interest, interact with, posses or destroy. All actors are also subjects. As seen in FIG. 2, actors 14 and subject 16 within the world state 16 have a plan for tasks 12, which are described as slots 28 which must have some properties (i.e., by predicates), which are roles within the task. Predicates 18 may often require a specific named non-player character (NPC), or might allow any number of NPCs to fulfill that role. This allows actors 14 to examine their environment and dynamically decide what task they will be working on. If an actor 14 abandons a task, perhaps due to some other higher priority task arising, another compatible actor 14 can take up that role. NPCs perform tasks autonomously. Player characters (PCs) perform tasks by user actions. Otherwise, NPCs and PCs are treated identically when fulfilling the role of actor slots.

[0017] The character history forms part of the input given to NPCs at the moment they interact with the player character. Traditional games describe a large variety of world state and character state, but these are typically simple switches (e.g., ‘has the PC explored area X’, ‘has the PC defeated boss Y’) or score meters which can fill or deplete (e.g., reputation). This type of data is collectively referred to as the ‘world state’. The character history system does not preclude such data and, in fact, is designed to accommodate it, as these are useful tools to describe the game world. However, character history of system 10 moves beyond this concept to allow encoding all actions undertaken by a player, in a small data footprint and using minimal network resources (in addition to those already used in an online game). Traditionally encoding of all actions of a character is considered infeasible due to the extreme data size of the resulting history, which makes decision making algorithms based on that history very slow. The character history of system 10 is solves these issues, and encodes some typical (i.e., expected by the player) properties of information propagation as follows.

[0018] First, players do not expect their actions to immediately be known by all of the denizens of the world. It takes some time for knowledge of their deeds to propagate. Therefore, player history is created and re-integrated back into the world asynchronously. Player history event records can sit in the cloud event queue for arbitrarily long times, and nothing ever needs to wait for those messages. In other words, all player history query operations can return some state, which may be stale by a couple of hours or days. When those events are eventually processed, and the player sees their impact in the world, this (potentially large) latency corresponds to the in-universe propagation time of knowledge of the players' actions.

[0019] Second, old player actions have less impact on the world today than do new player actions. As time goes on, actions taken long ago fade out of memory. Storing large amounts of history records requires large and ever-increasing amounts of data storage on the cloud, which would have a negative impact on cost and performance. Also, in-game mechanics which require a character history (for example, NPC dialogue) would have to process large and every-increasing amounts of records to make a decision about a character. In the universe, it would be unexpected if an NPCs knows about every minute detail of a players' actions. Rather, the expectation is that NPCs have a broad impression of the player character based on their actions. The solution is to not store each history record, but an aggregate of history records over time. The history cloud function processes individual records and, based on their importance (for example, defeating a major boss might be considered very important), will keep or discard that record. In either case, the history cloud function integrates the information in each individual record into a single, constant size, history description of the character, which corresponds to the knowledge about this character at the current moment in time. In this aggregation, older records are given less weight and newer records are given larger weight. [0020] Finally, in the past direction, the history is immutable - once a record is added, it cannot be undone.

[0021] Environmental switches, factional reputation, etc., are integrated into the history system, in particular, these are described in the same data format as history records. This allows designers to create queries of the entire world (including histories, switches, world state, etc.) in a uniform language. Since the history record data format is a generalization of such traditional world state data, no expressive power is lost by the use of the history record format. System 10 may include typical switches which affect the world, e.g., a simulated solar system, time of day cycles, lunar cycles, seasonal cycles, weather, natural disasters (e.g., meteors, wildfires, floods, avalanches), possessed items, known locations, etc.

[0022] Despite the complexity and cost of processing massive amounts of user data in this way, the implementation of character history record collection and aggregation will achieve performance and scalability by processing the history data per-player character and later re-integrating small, fixed size history aggregates into the world at large. As seen in FIG. 3, the character history algorithm 30 may be executed on the cloud in a multi-service configuration by using several components. First, a timeslice statistics collection engine 30 that is a data store for statistics, which may come from many different instances/servers, arranges those statistics on a per-character and per-region basis. Timeslice statistics collection engine 30 stores temporary data which is accumulated during each timeslice, and then consumed by the world impact propagation component during the timeslice update. Second, a world impact propagation engine 32 reads accumulated stats from timeslice statistics collection engine 30, handles timeslice updates, applies propagation and decay rules via graph weights (per graph node). The global history summary per each character is written by world impact propagation engine 32 before ending the timeslice, making that data available for future queries. Finally, an instanced encounters engine 34 is responsible for starting encounters, looking up party/character history summaries, and building local (per-instance) content, such as by using area/section type, environmental features, and political area/system control. Instanced encounters engine 34 records impactful actions taken and sends statistics relating to those action to the timeslice statistics collection component. Impactful actions include encountered events, such as non-player characters, loot, and chests. This component handles querying the history summary per character, as well as other character properties such as their owned items, and computing passions based on that data, then using computed values of passions to find available options for local content (for example, selection of dialogue options). The computing of passions may lead to multiple available options and require weighting those options based on passion values.

[0023] FIG. 4 illustrates a process 40 for providing data flow through the character history. First, each record from each player character is collected in a global queue 42. Next, during each timeslice, a fixed number of records are processed 44. System 10 seamlessly breaks up potentially long-running aggregation operations into multiple timeslices by consuming a number of records which is known (through experimentation or by selection of an appropriately sized cloud computation unit) to run to completion within that timeslice, preventing any stalling. Next, each record is originally tied to one in-game region 46, i.e., when it was created, the action was undertaken in a specific geographical region 44.

Although the regions are thought of as tied to world-space geography, nothing in system 10 is necessarily limited in this way. For example, it is possible to have two logical regions which are separated by a large physical distance in the game world, but are close together in the logical sense. The regions are organized into a graph structure, with edges being labelled with a propagation speed. Next, each regions' new records are processed in parallel 48, reflecting that the initial knowledge of the action is isolated to that region. This allows system 10 to achieve unlimited horizontal scaling - if sufficient parallelism is not achievable, it is possible to modify the graph structure to break the world into more granular regions. Next, each regions decay and propagation rules are process in parallel 50, without prior knowledge (i.e. without immediate integration) of the records processed in the previous step. Finally, the world state is updated automically at the end of the timeslice 52 by incrementing the timeslice counter. Update records are placed in a ring queue with a small size so that old records are not immediately overwritten but available for a short time. The choice of timeslice duration allows system 10 to configure the overall cost and responsiveness of the system. In practice, this choice is driven largely by the number of player actions waiting in the queue. FIG. 5 illustrates the flow of data during each timeslice in the character history. [0024] When designing queries involving a characters' history, the query is made from the perspective of an in-game character which has limited knowledge of the world. This means that system 10 can store a character history record per-region, and each character has weighted knowledge of different regions in the world. The typical knowledge structure of a character is they know their current region, but more knowledgeable characters might know of data in different regions. These queries are based on the characters' passions data, which consist of multipliers (scale factors) on a combination of the player state: player character historical/statistical properties, and player character owned items. Predicates on the scaled statistical properties are used to determine which options are available at a point of interaction between an NPC and a PC. FIG. 6 illustrates an example computation of a single scenario with designer-defined rules for impacting final results, with FIGS. 7 and 8 showing exemplary data used to represent passions for different characters.

[0025] Execution engine 24 is accomplished by a generation process that is triggered by a specific NPC, by an event (like the PC entering an area), periodically in a specific area, if a predicate is satisfied, or any combination thereof. The generation process outputs a task container, which contains a list of tasks 12, which can be changed at any time. Tasks containers have a latent identity within the world but are not visible or known by actors. They are not “world elements” but can impact the world. Task containers broadcast signals to nearby actors if those actors can participate in any role within the task 12, which permits actors to co-operate seamlessly on a specific task. This co-operation allows a task container to proceed in parallel by having multiple participants which engage in it and perform individual components at the same time.

[0026] Execution engine 24 handles the updates of task containers and decides how to execute them. The simplest method of executing a task list is to execute each task in sequence. The first task is treated as the ‘current’ task, executed, and when completed, the next task becomes the current task. When the task list changes, the current task is re-selected and, if it is changed, the previous task is interrupted to perform the new current task. In order to execute a current task, the current state of the task participant is retrieved the task is queried in that context to generate a concrete action.

[0027] System 10 supports organization/structure on top of individual modular tasks. For prioritization, scalar priorities are assigned to tasks, which may then be sorted by priority, and the highest-priority task becomes the current one. For grouping, tasks may be grouped by metadata tags, by their participants, etc., and executed or interrupted in groups. Group takes may be prioritized instead of individual tasks, which lets system 10 perform logic like committing to a particular task, even if a higher priority task has arisen, and creating prerequisite tasks within a task list. Tasks and task groups are treated uniformly and within each task group, and the constituent tasks can have their own prioritization and subgrouping. [0028] System 10 may embed this structure in the assembly stage (i.e. the task list assembler already creates a priority/grouping structuring on the last list), or system 10 can output generic tasks from the assembly stage, then compute priority for each task participant. This latter approach allows the decision process of picking which task becomes the current task differ from character to character. Different instances of the same NPCs can co-operate on a shared set of tasks, and can perform different elements of those tasks, by having different prioritization schemes. For example, a factory can have a task list called “make car” which requires retrieving raw steel from a depot, operating steel punch machines, and riveting steel parts. Only some NPCs are skilled enough to operate the machines, and only some are strong enough to lift the raw materials.

[0029] Assembly engine 22 of system 10 combines the elements of emergent narrative into a coherent, large scale model for actors to discover and execute tasks using a general framework for performing the assembly of the modular elements into a large scale structure. Generally, the performing of tasks is decoupled from the generation of task lists. The generation process can be implemented using any number of methods, several of which are described herein. Different generation methods may be applicable to different types of NPCs, different types of tasks, different world locations or events.

[0030] As an example, a tree pruning method may be used by system 10, where the continuum of all actions which a particular character can initiate are simultaneously described as a tree of modular (atomic) and compound tasks. This structure is referred to as a task tree and represents the ‘goals’ of the character. The task tree is built either statically (i.e. by hand by a designer) or it can be partially assembled dynamically based on the traits of a character (for example, a character tagged as “Peaceful” and “Nature Lover” might automatically gain elements in their task planner tree which contain ‘pick flowers’ actions). In this method, leaf nodes correspond to individual modular tasks. When system 10 generates the task list, the tree is pruned dynamically based on the current context - each node has a predicate on the world/ character which, if satisfied, results in system 10 determining that the node has “occurred” in the pruned tree. The resulting task list is composed of all the leaf nodes in the pruned tree. System 10 models progressions (i.e., do A, then B, then C) by ordering tasks, then ensuring that certain types of tree nodes cannot occur more than once, or cannot occur a second time until some condition is met (this structure may be defined in the node predicates). This method is most appropriate when the composite tasks are largely unrelated, or encode a very large scope of different activities which a character can perform or goals they might have (e.g. a carpenter will go to work and build desks, but they will also play golf and swim for leisure, which are largely unrelated activities without rigid relationships between them). This method is also appropriate when there is need to assemble a very large task list generator from other sub -generators of different types (because this method makes minimal assumptions about the types of tasks it outputs). Finally, this method may be used when system 10 needs to assemble a larger tasks list generator from sub -generators which come from many sources (again due to minimal assumptions).

[0031] System 10 may also employ a hierarchical task planner (HTP) method. The HTN method describes modular tasks with additional metadata about how they related to their parent tasks. In particular, this type of generator requires an additional partial order relationship on tasks coming from the designer. This relationship represents causal links between different tasks, so is called the ‘comes before’ relationship. For example, in order to build a table, one must first acquire wood and screws, then operate a screwdriver to fasten the wood with the screws, but it is possible to acquire the screws and metal in any order. This gives a natural prioritization, which is sent to the execute system (i.e., by topological sorting of the resulting task list with respect to the comes before relationship). This method is most appropriate when there are complicated relationships between individual modular tasks which accomplish a larger goal, global coherence is very important (i.e. resulting task output must definitively accomplish the goal according to the rules of the world, and the accomplishment of that goal requires many components), or the resulting task output is permitted to be rigid or repetitive.

[0032] System 10 can also implement an NLP/machine learning method that takes a description of the world state, all available task types, and a goal state, and generates a sequence of tasks to accomplish a goal. Tasks have attached metadata which describe their preconditions and their effects. This method is most appropriate when failure is tolerable, i.e., the query can be re-run if the output is invalid, without caring if the NPC is inactive or being able to fallback to a default behavior, the search space (of action sequences connecting the current world state and the goal state) is very weakly constrained, or global coherence is not important.

[0033] System 10 may also implement a traditional, fixed narrative, with a fixed (branching or linear) quest as found in traditional narrative games that is modelled as a collection of modular tasks with these following properties: the task tree is all-or-nothing (either all tasks in the collection are generated or none are generated), the tasks in the collection are related by a shared grouping tag which identifies them as a part of a single “quest,” each task in the collection has a tag to identify its role in the quest (e.g. “act 1”, “act 2”, “optional side quest”), and the quest structure (branching structure) itself refers abstractly to those tags, and they are slotted into the quest at tree pruning time. This method is most appropriate when there is a need to embed a traditional (fixed) narrative within a larger task generator. [0034] System 10 is configured to perform narrative styling content generation. Presentation to the player is a crucial element of any narrative system. This consists of textual dialogue, speech, character animation, among other things. Based on the context/interaction, system 10 can generate textual dialogue using a natural language processing Al. System 10 thus includes a scheme for deriving data which is most relevant to such a dialogue so that speech and animation may be generated from the dialogue.

[0035] As described above, the rich knowledge base provided to each character during PC and NPC interactions is phrased in a domain specific language which allows evaluation of predicates on that knowledge base. The predicate evaluation process is augmented to optionally record the provenance of each satisfied or unsatisfied predicate. When predicates are used to determine whether an action is permissible or not, this provenance information allows us to associate extra data with a successful action - the reasoning which arrives at the conclusion that it is permitted to take that action.

[0036] The provenance information is a sequence of historical property tags and switch tags, ordered by which sequence is most impactful to the final result. Each element of the overall predicate (which acts on a single input tag value) has a weight which determines the contribution of that tag to the final predicate score. Impactfulness score is determined by the magnitude of the weight as well as the distance of the scored tag value from its “neutral” value, which is the value at which the score just meets its threshold value. By enforcing that the individual scoring elements are simple monotonic functions, it is possible to easily invert those functions to compute the neutral value.

[0037] During predicate evaluation, an observer interface is defined which takes as an argument the evaluated tag, its weight, its final score, and the impactfulness. The observer will typically keep the K-best tags (by impactfulness). By attaching natural -language text to each historical property tag and switch tag, it is then possible to feed contextual information to natural language processing Al about this provenance structure. System 10 may then take the highest impact provenance tags and retrieve their natural language associated text. The impactful actions of the PC are then further examined to inject additional narrative information associated with the impactful actions of the PC. Impactful actions have more context data associated with them, in particular, the narrative descriptions of the relevant actors, factions, locations, etc. to that impactful action.

[0038] System 10 has several input vectors which affect the game world. For example, system 10 provides for a living, breathing world with narrative legos, passions, and acts that can create dynamic, persistent, and modular dialog. Using optimized data types for triggers, system 10 allows players to effect change through character passions, environmental triggers, and active switches. Finally, system 10 can, through scope and decay, create a realistic, multiplayer, global impact for player actions.

[0039] System 10 also provides for virtual areas, such as cities, that have section types, economically driven, citizens, and overall status. User generated content allows players to create acts throughout the game, and can include conventional content type such as levels, stories, dungeons, and items. System 10 further provides for ages, where each age stores player acts on the cloud and ages are cumulative. System 10 includes an ability to provide deep social media, where players can create acts through social media video streams (Twitch, Youtube, Facebook, etc). Players are also given the ability to create unique acts relating to the core narrative structures provided by the developer of the game. System 10 is configured to provide a full environment, including simulated solar system, time of day cycles, lunar cycles, seasonal cycles, and weather. Scenario Elements are also supported by system 10, such as assassination, conquest, onslaught, and relic recovery.

Claims

CLAIMS What is claimed is:

1. A computer gaming system that provide an emergent narrative, comprising: a set of tasks, each of which represents a high level goal requiring a series of steps to achieve; a plurality of subjects, each of which has a set of traits, wherein a portion of the plurality of subjects comprise a plurality of actors, each of which is controlled by a user of the computer gaming system; a set of predicates, each of which defines at least one condition for an occurrence of an event or an action; a set of knowledge describing a world state that is accessible to the plurality of subjects other than the plurality of actors; an assembly engine programmed to generate a plurality of actions that any actor of the plurality of actors is allowed to initiate based on the set of tasks, the set of predicates, and the set of knowledge; and an execution engine programmed to output a task container containing a list of tasks drawn from the set of tasks that is broadcast to any of the plurality of actors that are allowed to execute the list of tasks in the task container, to execute the list of tasks in the task container, and to update the task container based on actions of the plurality of actors that are allowed to execute the list of tasks in the task container.

2. The computer gaming system of claim 1, wherein each task of the set of tasks is assigned a unique identifier.

3. The computer gaming system of claim 2, wherein each task may have a plurality of subjects that can participate.

4. The computer gaming system of claim 3, wherein each subject of the plurality of subjects may be assigned to one or more roles within any one of the set of tasks.

5. The computer gaming system of claim 4, wherein the world state includes a character history for each subject of the plurality of subjects.

6. The computer gaming system of claim 5, wherein the character history comprises an encoding of all actions undertaken by each of the plurality of actors.

7. The computer gaming system of claim 6, wherein each of the actions undertaken by each of the plurality of actors are propagated asynchronously.

8. The computer gaming system of claim 7, wherein each of the actions undertaken by each of the plurality of actors are weighted according to the date on which each action was undertaken.

9. The computer gaming system of claim 8, wherein the character history includes world state switches.

10. The computer gaming system of claim 9, wherein the character history includes a timeslice statistics collection engine that can store temporary data accumulated during each timeslice of a game, a world impact propagation engine that can read accumulated statistics from timeslice statistics collection engine, perform timeslice updates, and apply propagation and decay rules, and an instanced encounters engine that can start encounters, look up character history, and build local content.

11. The computer gaming system of claim 10, wherein the execution engine is programmed to apply scalar priorities to the list of tasks.

12. The computer gaming system of claim 11, wherein the execution engine is programmed to group more than one task.

13. The computer gaming system of claim 12, wherein the assembly engine is programmed to generate the plurality of actions using a tree pruning method.

14. The computer gaming system of claim 12, wherein the assembly engine is programmed to generate the plurality of actions using a hierarchical task planner method.

15. The computer gaming system of claim 12, wherein the assembly engine is programmed to generate the plurality of actions using a machine learning method.

16. The computer gaming system of claim 12, wherein the assembly engine is programmed to generate the plurality of actions using a branching or linear method.