06-10-2019, 11:28 PM
Don’t Miss: A look at the data-driven AI framework behind Destroy All Humans 2
<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/dont-miss-a-look-at-the-data-driven-ai-framework-behind-destroy-all-humans-2.jpg" width="300" height="210" title="" alt="" /></div><div>
<p> Populating an entire game world with characters that give an impression of life is a challenging task, and it’s certainly no simpler in an open world, where gameplay is less restricted and players are free to roam and experience the world however they choose. The game engine has to be flexible enough to react and create interesting scenarios wherever the player goes. In particular, the demands on the AI are different from a linear game, requiring an approach that, while using established game AI techniques, emphasizes a different aspect of the architecture. </p>
<p> This article discusses the data-driven AI architecture constructed for Pandemic Studios’ open world title <em>Destroy All Humans 2</em>. It describes the framework that holds the data-defined behaviors that characters perform, and how those behaviors are created, pieced together, and customized. </p>
<p> <img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/dont-miss-a-look-at-the-data-driven-ai-framework-behind-destroy-all-humans-2.jpg" border="1" alt hspace="10" vspace="10" width="300" height="210" align="left"> The premise of an open world game with sandbox gameplay is to give players the freedom to do what they want, the freedom to create their own game within the world the developers provide. Their play is not linear, which is fantastic for a sense of immersion, but reduces the ability of the game developer to control, limit, and pre-script scenarios that the players encounter. </p>
<p> The AI code needs to be built on a foundation that is flexible enough to respond to any eventuality. It needs to handle a domain of gameplay that is broader in scope than a linear title and react to situations that might not have been anticipated. In effect, the AI needs to have a strong emphasis on breadth of behavior over depth. That is, the architecture must promote the ability to create large numbers of behaviors and make applying them to characters as easy as possible. </p>
<p> One solution to this challenge is to make the behaviors data-driven. They should be created without requiring changes to code, pieced together and reused as shared components, and substituted out for specialized versions. Ideally, the developer should be able to tweak not only the settings of a behavior, such as how long a timer lasts or how aggressive an enemy is, but also the very structure of the behavior itself. For example, what steps are needed to complete a given task or define how those steps are performed? By allowing our behaviors to fit into multiple situations, be reusable, and be quick to create and customize, we can more effectively create all the actions that the characters will need to give the game life. </p>
<p> The basis for the behavior system in <em>Destroy All Humans 2</em> is a hierarchical finite state machine (HFSM), in which the current state of an actor is defined on multiple levels of abstraction. At each level in the hierarchy, the states will potentially use sub-level states to break their tasks into smaller problems (for example, <em>attackenemies</em> is at a high level of abstraction and uses the less-abstract <em>fireweapon</em> below it to perform part of its function). This HFSM structure is a common method used in game AI to frame a character’s behaviors. It has several immediate benefits over a flat FSM. (For current information about HFSMs, see Resources) </p>
<p> In our implementation, each state in the HFSM is called a behavior and makes up the basic architectural unit of the system. Everything that characters can do in the game is constructed by piecing together behaviors in different ways that are allowed by the HFSM. A behavior can start more behaviors beneath it that will run as children, each performing a smaller (and more concrete) part of the task of the parent. Breaking each task into smaller pieces allows us to reap a lot of mileage out of the behavior unit-reusing it in other behaviors, overriding it in special cases, dynamically changing the structure, and so forth-and spend more time making the system intuitive and easy to modify. </p>
<p> <strong>Starting children. </strong>There are many ways to break a task into smaller pieces, and the correct choice ultimately depends on the type of task. Does the task require maintaining certain requirements, performing consecutive steps, randomly performing an action from a list, or something else? In our implementation, we allow several methods of breaking down a behavior into smaller pieces by allowing different ways to start children behaviors. </p>
<p> <strong>Prioritized children. </strong>The first and most common way to start children is as a list of prioritized behaviors. Behaviors that are started as prioritized will all be constructed at once (memory is allocated for them and they are added as children of the parent) and set into a special pending mode. (See Figure 1.) </p>
<div>
<img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/dont-miss-a-look-at-the-data-driven-ai-framework-behind-destroy-all-humans-2-1.jpg" border="1" alt hspace="5" vspace="5" width="400" height="387"></div>
<p> <em>FIGURE 1 A </em>combat<em> behavior starts prioritized children, which in turn starts more prioritized children. Pending behaviors are orange and active ones are blue. </em> </p>
<p> When a behavior is in pending mode, it is not updated; instead, it waits until the behavior itself decides it can activate, based on its own settings. When activated, the behavior will in turn start any children it has. Only active behaviors can have children, so a pending behavior will wait before starting its children. </p>
<p> As a rule, only one active behavior can run beneath a given parent, which creates a problem: what to do when multiple behaviors are able to run. We need to set a priority to determine which sub-task is more important. When starting children as prioritized, we define their priority implicitly based on the order the behaviors are added to the parent. The earlier a behavior is listed, the higher its priority (see Isla in Resources). </p>
<p> This solution avoids the problem that would have resulted had we determined priority strictly by number, such as priority-creep, in which priorities become larger and larger, trying to trump the rest. Here we localize the priority definition, so it’s only relative to the small subset of behaviors that are started as siblings. </p>
<p> In the example above, we see a hierarchy of behaviors and the children available under each, with <em>fire active</em> as a child of <em>attack</em>, which in turn is active as a child of <em>combat</em>. If the currently pending behavior (<em>dodge</em>) were to determine that it needs to start (when the NPC detects it is being fired upon), it will interrupt its active sibling (<em>attack</em>) and revert it to pending, which in turn will delete all children of <em>attack</em>. Once no other active sibling behaviors are running, <em>dodge</em> may begin. </p>
<p> This method of applying priority implicitly works well in most cases, but sometimes the importance of the tasks cannot be described with a simple linear ordering. To handle cases in which a behavior is doing something important and should not be interrupted by non-critical tasks (even if they’re higher priority), we can implement a feature called “can interrupt.” Essentially, an active behavior may receive a boost in priority, preventing interruption during specific parts of its execution. </p>
<p> With this boost, priorities can be specified in ways more complex than simple linear ordering. For example, while melee is listed at a higher priority than <em>dodge</em> in Figure 1, it should still be allowed to finish its animation even if <em>dodge</em> decides to start-by giving it a boost in priority while running, we prevent <em>dodge</em> from cutting it off mid-animation. </p>
<p> <strong>Sequential and random children. </strong>Other ways to start child behaviors are known as sequential and random. Behaviors that are started sequentially are run in the order that they are listed. If the first can run, it will do so until it completes on its own, followed by the second, and so on. When the last behavior in the sequence finishes, the parent finishes as well. For a group of child behaviors started randomly, only one will be chosen to run, and the parent will complete once its child finishes. </p>
<p> <strong>Non-blocking children.</strong> Behaviors can also be started as non-blocking, in which case they may activate even if there are already other active behaviors running beneath the parent. They exist outside the prioritized list. These behaviors are useful for performing tasks that work simultaneously with others, such as firing while moving, or playing a voice over on a specific condition, or activating and deactivating effects. Generally, anything performed by a non-blocking behavior must not interfere with any other sibling behaviors that might be running, since a non-blocking behavior will only be interrupted when its parent is deactivated (and never by a sibling behavior). </p>
<p> By using various combinations of these methods up and down the tree, we can form decisions and task handling over multiple levels that would be difficult to define in a single behavior. </p>
</div>
<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/dont-miss-a-look-at-the-data-driven-ai-framework-behind-destroy-all-humans-2.jpg" width="300" height="210" title="" alt="" /></div><div>
<p> Populating an entire game world with characters that give an impression of life is a challenging task, and it’s certainly no simpler in an open world, where gameplay is less restricted and players are free to roam and experience the world however they choose. The game engine has to be flexible enough to react and create interesting scenarios wherever the player goes. In particular, the demands on the AI are different from a linear game, requiring an approach that, while using established game AI techniques, emphasizes a different aspect of the architecture. </p>
<p> This article discusses the data-driven AI architecture constructed for Pandemic Studios’ open world title <em>Destroy All Humans 2</em>. It describes the framework that holds the data-defined behaviors that characters perform, and how those behaviors are created, pieced together, and customized. </p>
<p> <img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/dont-miss-a-look-at-the-data-driven-ai-framework-behind-destroy-all-humans-2.jpg" border="1" alt hspace="10" vspace="10" width="300" height="210" align="left"> The premise of an open world game with sandbox gameplay is to give players the freedom to do what they want, the freedom to create their own game within the world the developers provide. Their play is not linear, which is fantastic for a sense of immersion, but reduces the ability of the game developer to control, limit, and pre-script scenarios that the players encounter. </p>
<p> The AI code needs to be built on a foundation that is flexible enough to respond to any eventuality. It needs to handle a domain of gameplay that is broader in scope than a linear title and react to situations that might not have been anticipated. In effect, the AI needs to have a strong emphasis on breadth of behavior over depth. That is, the architecture must promote the ability to create large numbers of behaviors and make applying them to characters as easy as possible. </p>
<p> One solution to this challenge is to make the behaviors data-driven. They should be created without requiring changes to code, pieced together and reused as shared components, and substituted out for specialized versions. Ideally, the developer should be able to tweak not only the settings of a behavior, such as how long a timer lasts or how aggressive an enemy is, but also the very structure of the behavior itself. For example, what steps are needed to complete a given task or define how those steps are performed? By allowing our behaviors to fit into multiple situations, be reusable, and be quick to create and customize, we can more effectively create all the actions that the characters will need to give the game life. </p>
<p> The basis for the behavior system in <em>Destroy All Humans 2</em> is a hierarchical finite state machine (HFSM), in which the current state of an actor is defined on multiple levels of abstraction. At each level in the hierarchy, the states will potentially use sub-level states to break their tasks into smaller problems (for example, <em>attackenemies</em> is at a high level of abstraction and uses the less-abstract <em>fireweapon</em> below it to perform part of its function). This HFSM structure is a common method used in game AI to frame a character’s behaviors. It has several immediate benefits over a flat FSM. (For current information about HFSMs, see Resources) </p>
<p> In our implementation, each state in the HFSM is called a behavior and makes up the basic architectural unit of the system. Everything that characters can do in the game is constructed by piecing together behaviors in different ways that are allowed by the HFSM. A behavior can start more behaviors beneath it that will run as children, each performing a smaller (and more concrete) part of the task of the parent. Breaking each task into smaller pieces allows us to reap a lot of mileage out of the behavior unit-reusing it in other behaviors, overriding it in special cases, dynamically changing the structure, and so forth-and spend more time making the system intuitive and easy to modify. </p>
<p> <strong>Starting children. </strong>There are many ways to break a task into smaller pieces, and the correct choice ultimately depends on the type of task. Does the task require maintaining certain requirements, performing consecutive steps, randomly performing an action from a list, or something else? In our implementation, we allow several methods of breaking down a behavior into smaller pieces by allowing different ways to start children behaviors. </p>
<p> <strong>Prioritized children. </strong>The first and most common way to start children is as a list of prioritized behaviors. Behaviors that are started as prioritized will all be constructed at once (memory is allocated for them and they are added as children of the parent) and set into a special pending mode. (See Figure 1.) </p>
<div>
<img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/06/dont-miss-a-look-at-the-data-driven-ai-framework-behind-destroy-all-humans-2-1.jpg" border="1" alt hspace="5" vspace="5" width="400" height="387"></div>
<p> <em>FIGURE 1 A </em>combat<em> behavior starts prioritized children, which in turn starts more prioritized children. Pending behaviors are orange and active ones are blue. </em> </p>
<p> When a behavior is in pending mode, it is not updated; instead, it waits until the behavior itself decides it can activate, based on its own settings. When activated, the behavior will in turn start any children it has. Only active behaviors can have children, so a pending behavior will wait before starting its children. </p>
<p> As a rule, only one active behavior can run beneath a given parent, which creates a problem: what to do when multiple behaviors are able to run. We need to set a priority to determine which sub-task is more important. When starting children as prioritized, we define their priority implicitly based on the order the behaviors are added to the parent. The earlier a behavior is listed, the higher its priority (see Isla in Resources). </p>
<p> This solution avoids the problem that would have resulted had we determined priority strictly by number, such as priority-creep, in which priorities become larger and larger, trying to trump the rest. Here we localize the priority definition, so it’s only relative to the small subset of behaviors that are started as siblings. </p>
<p> In the example above, we see a hierarchy of behaviors and the children available under each, with <em>fire active</em> as a child of <em>attack</em>, which in turn is active as a child of <em>combat</em>. If the currently pending behavior (<em>dodge</em>) were to determine that it needs to start (when the NPC detects it is being fired upon), it will interrupt its active sibling (<em>attack</em>) and revert it to pending, which in turn will delete all children of <em>attack</em>. Once no other active sibling behaviors are running, <em>dodge</em> may begin. </p>
<p> This method of applying priority implicitly works well in most cases, but sometimes the importance of the tasks cannot be described with a simple linear ordering. To handle cases in which a behavior is doing something important and should not be interrupted by non-critical tasks (even if they’re higher priority), we can implement a feature called “can interrupt.” Essentially, an active behavior may receive a boost in priority, preventing interruption during specific parts of its execution. </p>
<p> With this boost, priorities can be specified in ways more complex than simple linear ordering. For example, while melee is listed at a higher priority than <em>dodge</em> in Figure 1, it should still be allowed to finish its animation even if <em>dodge</em> decides to start-by giving it a boost in priority while running, we prevent <em>dodge</em> from cutting it off mid-animation. </p>
<p> <strong>Sequential and random children. </strong>Other ways to start child behaviors are known as sequential and random. Behaviors that are started sequentially are run in the order that they are listed. If the first can run, it will do so until it completes on its own, followed by the second, and so on. When the last behavior in the sequence finishes, the parent finishes as well. For a group of child behaviors started randomly, only one will be chosen to run, and the parent will complete once its child finishes. </p>
<p> <strong>Non-blocking children.</strong> Behaviors can also be started as non-blocking, in which case they may activate even if there are already other active behaviors running beneath the parent. They exist outside the prioritized list. These behaviors are useful for performing tasks that work simultaneously with others, such as firing while moving, or playing a voice over on a specific condition, or activating and deactivating effects. Generally, anything performed by a non-blocking behavior must not interfere with any other sibling behaviors that might be running, since a non-blocking behavior will only be interrupted when its parent is deactivated (and never by a sibling behavior). </p>
<p> By using various combinations of these methods up and down the tree, we can form decisions and task handling over multiple levels that would be difficult to define in a single behavior. </p>
</div>