AI Product Manuals - User contributions [en]

Input

2024-02-06T17:41:14Z

Davemark: /* Implementation */

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Consideration.png|400px|thumb|right|Consideration as part of the IAUS structure]]
An '''Input''' is a type of data that is passed through a [[Response Curve]] to get a value that is used to help score a [[behavior]]. In a general sense, it is anything that can be accessed or measured -- either directly or through further calculation. Inputs are usually links to something that is in the game engine, a character or object's information and stats, the [[Imap|Influence Map]] system, or anything else that can provide something that is measurable.

== Implementation ==

=== Code ===
Inputs are defined in data and, when exported from the database, are listed in the [[Enums]] file under '''ConsiderationInput'''.

Processing the inputs happens in the consideration code in the method, GetInputValue. This method contains a large case statement with one case for each possible input. The case contains the code for where to retrieve the data specific to that input. Because of this, it is one of the few code changes that has to be made both in initial setup of the IAUS system and during additions and changes. In the former case, the existing inputs will have to be linked to the appropriate objects in the game engine. In the latter case, if a new input is added to the database that is game specific, a corresponding case statement will be necessary in GetInputValue in order for that input to be recognized and its value retrieved. If an input is used that does not have an associated case statement, the default case does not throw a breaking error but the method returns a bad value. (An error statement could easily be placed in the default case.)

Input

2024-02-06T17:35:57Z

Davemark: More info

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Consideration.png|400px|thumb|right|Consideration as part of the IAUS structure]]
An '''Input''' is a type of data that is passed through a [[Response Curve]] to get a value that is used to help score a [[behavior]]. In a general sense, it is anything that can be accessed or measured -- either directly or through further calculation. Inputs are usually links to something that is in the game engine, a character or object's information and stats, the [[Imap|Influence Map]] system, or anything else that can provide something that is measurable.

== Implementation ==

=== Code ===
Inputs are defined in data and, when exported from the database, are listed in the Enums file under ConsiderationInput.

Processing the inputs happens in the consideration code in the method, GetInputValue. This method contains a large case statement with one case for each possible input. The case contains the code for where to retrieve the data specific to that input. Because of this, it is one of the few code changes that has to be made both in initial setup of the IAUS system and during additions and changes. In the former case, the existing inputs will have to be linked to the appropriate objects in the game engine. In the latter case, if a new input is added to the database that is game specific, a corresponding case statement will be necessary in GetInputValue in order for that input to be recognized and its value retrieved. If an input is used that does not have an associated case statement, the default case does not throw a breaking error but the method returns a bad value. (An error statement could easily be placed in the default case.)

Input

2024-02-06T17:35:41Z

Davemark: More info

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Consideration.png|400px|thumb|right|Consideration as part of the IAUS structure]]
An '''Input''' is a type of data that is passed through a [[Response Curve]] to get a value that is used to help score a [[behavior]]. In a general sense, it is anything that can be accessed or measured -- either directly or through further calculation. Inputs are usually links to something that is in the game engine, a character or object's information and stats, the [[Imap|Influence Map]] system, or anything else that can provide something that is measurable.

Inputs are defined in data and, when exported from the database, are listed in the [[Enums]] file under '''ConsiderationInput'''.

Processing the inputs happens in the consideration code in the method, GetInputValue. This method contains a large case statement with one case for each possible input. The case contains the code for where to retrieve the data specific to that input. Because of this, it is one of the few code changes that has to be made both in initial setup of the IAUS system and during additions and changes. In the former case, the existing inputs will have to be linked to the appropriate objects in the game engine. In the latter case, if a new input is added to the database that is game specific, a corresponding case statement will be necessary in GetInputValue in order for that input to be recognized and its value retrieved. If an input is used that does not have an associated case statement, the default case does not throw a breaking error but the method returns a bad value. (An error statement could easily be placed in the default case.)

Input

2024-02-06T17:32:56Z

Davemark: More info

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Consideration.png|400px|thumb|right|Consideration as part of the IAUS structure]]
An '''Input''' is a type of data that is passed through a [[Response Curve]] to get a value that is used to help score a [[behavior]]. In a general sense, it is anything that can be accessed or measured -- either directly or through further calculation. Inputs are usually links to something that is in the game engine, a character or object's information and stats, the [[Imap|Influence Map]] system, or anything else that can provide something that is measurable.

== Implementation ==

=== Code ===
Inputs are defined in data and, when exported from the database, are listed in the Enums file under ConsiderationInput.

Processing the inputs happens in the consideration code in the method, GetInputValue. This method contains a large case statement with one case for each possible input. The case contains the code for where to retrieve the data specific to that input. Because of this, it is one of the few code changes that has to be made both in initial setup of the IAUS system and during additions and changes. In the former case, the existing inputs will have to be linked to the appropriate objects in the game engine. In the latter case, if a new input is added to the database that is game specific, a corresponding case statement will be necessary in GetInputValue in order for that input to be recognized and its value retrieved. If an input is used that does not have an associated case statement, the default case does not throw a breaking error but the method returns a bad value. (An error statement could easily be placed in the default case.)

Input

2024-02-06T17:32:07Z

Davemark: More info

Input

2024-02-06T17:26:10Z

Davemark:

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Consideration.png|400px|thumb|right|Consideration as part of the IAUS structure]]
An '''Input''' is a type of data that is passed through a [[Response Curve]] to get a value that is used to help score a [[behavior]]. In a general sense, it is anything that can be accessed or measured -- either directly or through further calculation. Inputs are usually links to something that is in the game engine, a character or object's information and stats, the [[Imap|Influence Map]] system, or anything else that can provide something that is measurable.

== Implementation ==
=== Code ===
Inputs are defined in data and, when exported from the database, are listed in the [[Enums]] file under '''ConsiderationInput'''.

Processing the inputs happens in the consideration code in the method, GetInputValue. This method contains a large case statement with one case for each possible input. The case contains the code for where to retrieve the data specific to that input. Because of this, it is one of the few code changes that has to be made both in initial setup of the IAUS system and during additions and changes. In the former case, the existing inputs will have to be linked to the appropriate objects in the game engine. In the latter case, if a new input is added to the database that is game specific, a corresponding case statement will be necessary in GetInputValue in order for that input to be recognized and its value retrieved. If an input is used that does not have an associated case statement, the default case does not throw a breaking error but the method returns a bad value. (An error statement could easily be placed in the default case.)

Input

2024-02-06T17:12:48Z

Davemark: Initial creation

AI entity

2023-12-04T23:24:46Z

Davemark: /* Concept */

{{IAUS Header}}
== Concept ==
An '''AI Entity''' is a class designed to hold information that might be relevant to game characters. Any character that would have a [[Brain]] would also have an AI Entity. Also any object in the world that thinking characters would need to acquire information on and reason about would also need one as well.

One important component of and AI Entity is that they hold the [[Entity tag|information tags]] as part of the [[Tag System|tagging system]] that the AI uses to gather information about potential targets. Additionally, AI Entities contain the [[world object type]] of the item or character that it is attached to. That way, agents can know and be able to filter queries about world objects by what they are (through Object Types) or information about them - either permanent or temporary (through Tags).

== Code ==
All of the information about an AI Entity is contained in the AiEntity class.

== Data ==
There is no direct data involved with an AI Entity. However, they use values that are defined in the database such as [[world object type]], [[entity tag]], and [[team]].

IAUS

2023-01-17T14:49:03Z

Davemark: /* Behavior and Ability Packs */

{{IAUS Header}}

The '''Infinite Axis Utility System (IAUS)''' is the primary behavioral decision-making system in Intrinsic Algorithm's library. While it can be supported by information from other systems (such as the [[Imap]] system or [[Tagging]] system), it is the "brains" of the game agents. This can be applied to individual characters, invisible "team leaders", or even to inanimate objects.

The IAUS exists as a stand-alone black box that can be installed into a project codebase with minimal work. We have both C++ and C# versions based on the needs to the client. In theory, minus any specific custom language or library issues, this means that this core AI system can be installed on day 1 and work can begin on hooking it up to world information, existing behaviors and animation code, and behavior logic can be authored in the tool we have developed for that purpose.

== Concept ==
The concept behind utility is that we are putting together a score for a particular [[Behavior]] based on how appropriate it is at the time. That is, what utility does this have for the character? Once these scores are assembled, we can pick the behavior with the highest score under the assumption that it is the most beneficial and, therefore, is the most appropriate action to take.

The IAUS formalizes this into a complete data-driven architecture that acts in a largely self-contained way such that the only hookups needed are the [[#inputs|inputs]] from objects in the game engine and [[#outputs|outputs]] to actions to take in the game engine.

Rather than leveraging the traditional "agro system" that is common in many games (in particular, MMOs), the IAUS is constantly making decisions based on what is going on around it. It may take into account things like distance, health, the environment, temperature, time of day, how much of a particular resource is remaining, and many other situational issues.

Rather than a behavior tree that has a hand prioritized order to process things in, the IAUS is constantly prioritizing things according to all of the inputs on every behavior. This also means that every behavior has the potential to be scored at any time. Obviously, the situation would dictate things that would or would not be available. For example, in the middle of combat an agent probably would not get even remotely close to doing a friendly wave to his ally.

== Components ==
[[File:Diagram-Brain.png|400px|thumb|right|The high level IAUS structure]]
The IAUS system is comprised of a number of high level components. (Each of these contains lower level components that are detailed on their respective pages.)

=== Brain ===
A [[Brain]] is the top level component that is assigned to an agent in the game. From a data standpoint, a brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the [[brain#Code|brain class]] contains most of the data for the agent's thinking and does most of the work of scoring Behaviors and keeping track of the history of the Behavior usage.

=== Behavior ===
A [[Behavior]] is the core atomic component of the AI system. Each Behavior represents an action that an agent might take and contains the information for scoring the Behavior.

Rather than some architectures that decide solely on a type of behavior and then subsequently choose a target, any behavior that can be targeted at more than one object or character, is scored individually for the combination of the behavior on each specific target. This is called a [[Context]]. For example, rather than deciding to "shoot" and then trying to decide ''who'' to shoot, the IAUS scores all of the shooting action and target contexts individually. So "shoot Chuck" and "shoot Ralph" would get their own scores right alongside each other. The reason for this is that shooting Chuck may score higher then another potential action but shooting Ralph may score lower.

=== Behavior Type ===
Each Behavior is linked with a [[Behavior type|Behavior Type]] that it will execute if the behavior is selected. Behavior types are the core actions that an agent can perform whereas behaviors are more "reasons why" a particular behavior type would be executed. For example, different agent types may have different reasons for engaging in a melee attack. These would be differentiated by each behavior having different [[consideration]]s. However, they all ultimately perform the behavior type, "melee attack". Another wide-ranging example would be the behavior type, "move to target". Whether we are moving towards an ally, an enemy, an object on the ground, or the tavern across the street, they would all be executed in the same way -- i.e. moving to the target object (as specified in the [[context]] that was scored).

Another way of thinking of behavior types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action.

=== Consideration ===

Each behavior is comprised of one or more [[Consideration]]s representing a piece of information that the agent is taking into account when scoring that particular behavior. Each consideration maps the value of an input through a response curve to convert it to an output value. The scores from all of the considerations are then multiplied together to generate the score for that behavior.

=== Decision ===
Each scoring of a Behavior in a Context (i.e. "Behavior A against Target X") is referred to as a [[Decision]]. When deciding what to do, Decisions are scored rather than Behaviors. While the Behavior provides all the necessary reasoning for whether or not it is a good idea (through it's Considerations), if it is a targeted behavior, it cannot be scored without understanding who or what is being targeted. For example, a Behavior "shoot enemy" that has a Consideration for the distance to that enemy needs to be able to reference the specific entity's location to calculate the distance. If it is not a targeted behavior, then any Considerations that expect there to be a target in the Context will not return a value.

=== Behavior and Ability Packs ===

Behaviors are contained in [[behavior pack]]s and [[ability pack]]s -- usually by their type of usage. This is largely for the sake of convenience when dealing with many behaviors that are designed to go together. However, by doing this, the are able to be added and removed as a group as necessary. Additionally, if a new behavior is added to a Behavior Pack (because it is designed to go with the other behaviors in that pack), then all the [[Brain]]s that contain that Behavior Pack will get the new behavior.

== Installation ==
=== Software ===

==== Core Code ====

==== Data Tool ====

=== Database ===

=== Connections ===

==== Inputs ====

==== Outputs ====

== Usage ==

{{Manual Footer}}

Imap

2021-10-27T16:48:57Z

Davemark: Initial Entries

{{Imap Header}}
Much like the IAUS, our Imap system has been worked on for over 6 years and has been used in a number of shipped titles. Over that time, this architecture has been extended and optimized. However, it's core beneficial use has remained intact and improved upon. It is a general knowledge representation system that allows for analysis of spatial, tactical, strategic, and ecological situations.

As with the IAUS, the Imap system exists a stand-alone black box that can be installed into a project codebase and calibrated to whatever spatial and coordinate system the existing project runs on. Additionally, many of the queries for commonly used information and code for commonly used movement and targeting locations exist already as part of the install. New Imap queries can be completed usually in only a few lines of code. Often in minutes. As planned future work, the system allows for data-driven implementation of these queries so that designers can mix-and-match their own combinations of influence map data for specific behaviors without programmer involvement.

==Concept==
Using the '''influence map (Imap)''' system, the characters are aware of what is going on around them spatially. This can include the proximity of other agents (friend or foe), the threat radiated by other agents (friend or foe), environmental hazards, the effect of AOE spells, and other things. This means that the agents can space out from each other as necessary, move (or even dodge) out of bad areas to stand, minimize the threat to themselves, target AOE spells at the center of a group of enemies (or allies!), stay in non-melee areas if they are a ranged attacker, etc. This can also apply to things such as light and dark areas. If something wants to creep around in the darkness and avoid the light cast by lamposts, fires, or even magical light spells, they will do so.

Each agent (whether it be an NPC, a player character, or object) radiates one ore more types of "influence" into a grid system that is laid over the game map. The scale of these grids can be tailored to the type of influence that is being tracked and the necessary granularity. This system is universal to the game and/or the map and is accessible to all characters that wish to query the information. By accessing one or more layers of influence and combining them accordingly, information about a particular location can be accessed and used in the decision-making process. Additionally, other queries can be created to ''look for'' areas that would be relevant to ''executing'' decisions. This is used for NPCs to easily query information about the distribution of dozens... or even hundreds... of other agents in the world on the enemy team, their own team, neutral agents or objects, or any combination of the above to get information about a specific location (e.g. "am I crowded?" or "how much threat am I under right here?") or to find locations where something should be performed (e.g. "where is the safest place to stand?" or "where should I use this area of effect spell?")

== Components ==
=== Imap ===

=== Imap Manager ===

=== Layer Map ===

=== Layer Map Collection ===

== Installation ==
=== Software ===

==== Core Code ====

==== Data Tool ====

== Usage ==

{{Manual Footer}}

Template:Imap Header

2021-10-27T16:34:38Z

Davemark: Initial Entries

'''This page is part of the [[Imap|Imap Manual]].'''
♦ [[Imap]] ♦ [[Imap manager|Imap Manager]] ♦ [[Imap entity node|Imap Entity Node]] ♦

Imap

2021-10-27T16:30:49Z

Davemark: Initial Entries

IAUS

2021-10-17T01:20:39Z

Davemark: /* Concept */ Added some description

{{IAUS Header}}

The '''Infinite Axis Utility System (IAUS)''' is the primary behavioral decision-making system in Intrinsic Algorithm's library. While it can be supported by information from other systems (such as the [[Imap]] system or [[Tagging]] system), it is the "brains" of the game agents. This can be applied to individual characters, invisible "team leaders", or even to inanimate objects.

The IAUS exists as a stand-alone black box that can be installed into a project codebase with minimal work. We have both C++ and C# versions based on the needs to the client. In theory, minus any specific custom language or library issues, this means that this core AI system can be installed on day 1 and work can begin on hooking it up to world information, existing behaviors and animation code, and behavior logic can be authored in the tool we have developed for that purpose.

== Concept ==
The concept behind utility is that we are putting together a score for a particular [[Behavior]] based on how appropriate it is at the time. That is, what utility does this have for the character? Once these scores are assembled, we can pick the behavior with the highest score under the assumption that it is the most beneficial and, therefore, is the most appropriate action to take.

The IAUS formalizes this into a complete data-driven architecture that acts in a largely self-contained way such that the only hookups needed are the [[#inputs|inputs]] from objects in the game engine and [[#outputs|outputs]] to actions to take in the game engine.

Rather than leveraging the traditional "agro system" that is common in many games (in particular, MMOs), the IAUS is constantly making decisions based on what is going on around it. It may take into account things like distance, health, the environment, temperature, time of day, how much of a particular resource is remaining, and many other situational issues.

Rather than a behavior tree that has a hand prioritized order to process things in, the IAUS is constantly prioritizing things according to all of the inputs on every behavior. This also means that every behavior has the potential to be scored at any time. Obviously, the situation would dictate things that would or would not be available. For example, in the middle of combat an agent probably would not get even remotely close to doing a friendly wave to his ally.

== Components ==
[[File:Diagram-Brain.png|400px|thumb|right|The high level IAUS structure]]
The IAUS system is comprised of a number of high level components. (Each of these contains lower level components that are detailed on their respective pages.)

=== Brain ===
A [[Brain]] is the top level component that is assigned to an agent in the game. From a data standpoint, a brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the [[brain#Code|brain class]] contains most of the data for the agent's thinking and does most of the work of scoring Behaviors and keeping track of the history of the Behavior usage.

=== Behavior ===
A [[Behavior]] is the core atomic component of the AI system. Each Behavior represents an action that an agent might take and contains the information for scoring the Behavior.

Rather than some architectures that decide solely on a type of behavior and then subsequently choose a target, any behavior that can be targeted at more than one object or character, is scored individually for the combination of the behavior on each specific target. This is called a [[Context]]. For example, rather than deciding to "shoot" and then trying to decide ''who'' to shoot, the IAUS scores all of the shooting action and target contexts individually. So "shoot Chuck" and "shoot Ralph" would get their own scores right alongside each other. The reason for this is that shooting Chuck may score higher then another potential action but shooting Ralph may score lower.

=== Behavior Type ===
Each Behavior is linked with a [[Behavior type|Behavior Type]] that it will execute if the behavior is selected. Behavior types are the core actions that an agent can perform whereas behaviors are more "reasons why" a particular behavior type would be executed. For example, different agent types may have different reasons for engaging in a melee attack. These would be differentiated by each behavior having different [[consideration]]s. However, they all ultimately perform the behavior type, "melee attack". Another wide-ranging example would be the behavior type, "move to target". Whether we are moving towards an ally, an enemy, an object on the ground, or the tavern across the street, they would all be executed in the same way -- i.e. moving to the target object (as specified in the [[context]] that was scored).

Another way of thinking of behavior types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action.

=== Consideration ===

Each behavior is comprised of one or more [[Consideration]]s representing a piece of information that the agent is taking into account when scoring that particular behavior. Each consideration maps the value of an input through a response curve to convert it to an output value. The scores from all of the considerations are then multiplied together to generate the score for that behavior.

=== Decision ===
Each scoring of a Behavior in a Context (i.e. "Behavior A against Target X") is referred to as a [[Decision]]. When deciding what to do, Decisions are scored rather than Behaviors. While the Behavior provides all the necessary reasoning for whether or not it is a good idea (through it's Considerations), if it is a targeted behavior, it cannot be scored without understanding who or what is being targeted. For example, a Behavior "shoot enemy" that has a Consideration for the distance to that enemy needs to be able to reference the specific entity's location to calculate the distance. If it is not a targeted behavior, then any Considerations that expect there to be a target in the Context will not return a value.

=== Behavior and Ability Packs ===

Behaviors are contained in [[behavior pack]]s and [[ability pack]]s -- usually by their type of usage. This is both for the sake of convenience when dealing with many behaviors that are designed to go together. However, by doing this, the are able to be added and removed as a group as necessary. Additionally, if a new behavior is added to a Behavior Pack (because it is designed to go with the other behaviors in that pack), then all the [[Brain]]s that contain that Behavior Pack will get the new behavior.

== Installation ==
=== Software ===

==== Core Code ====

==== Data Tool ====

=== Database ===

=== Connections ===

==== Inputs ====

==== Outputs ====

== Usage ==

{{Manual Footer}}

Consideration

2021-10-09T03:07:47Z

Davemark: Implementation

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Consideration.png|400px|thumb|right|Consideration as part of the IAUS structure]]
A '''Consideration''' is a mapping of an input value through a [[Response Curve]] to get a value that is used to help score a [[behavior]].

== Components ==
Considerations have different components, most of which make them what they are and are required.

=== Input ===
The [[input]] on a Consideration is the data that the consideration needs to retrieve in order to process.

=== Response Curve ===
The [[Response Curve]] of a Consideration is what converts the value of the input into the output value for that Consideration. It is comprised of a [[Response Curve#Curve Type|response curve type]] and [[Response Curve#Variables|consideration variables]] that define what the curve "looks like".

=== Parameters ===
Considerations may have [[Input Parameters]] that add more context specific to processing that consideration. (Note that these are different from [[behavior parameter]]s which apply to the [[behavior]] as a whole.)

== Implementation ==
=== Code ===
All the processing for considerations is contained in <syntaxhighlight lang="C++" inline>Class Consideration</syntaxhighlight>. The only member variables are the name, input, response curve, and parameters. There is one consideration object for each independent consideration in any behavior. Note that these are truly unique ''objects'' that may be the same as other consideration objects elsewhere. So, for example, Behavior A may have a consideration with the same response curve and parameters as a consideration for Behavior B. Those two considerations would be individual objects in the data. This is because the are associated as member objects of those parent behaviors. If the data is changed in the [[data tool]] for one of the considerations, the data held in the created objects would not be different.

The objects themselves hold no state.

The only entry point for use is <syntaxhighlight lang="C++" inline>float Consideration::GetScore(const ContextInfo &thisContext)</syntaxhighlight>. From there it acquires the input value from the specified input using, if necessary, information passed into <syntaxhighlight lang="C++" inline>GetScore</syntaxhighlight> via the [[context info]].

Once it has retrieved and processed the input value, it runs it through the response curve and returns the value of the consideration.

<syntaxhighlight lang="C++" inline>float Consideration::GetInputValue(const ContextInfo &thisContext) const</syntaxhighlight> does all the heavy lifting of the process of calculating considerations for a behavior. Because of that, this is going to be one of your most accessed functions during AI execution. It is essentially a large '''switch''' statement branching on the [[input]] that is specified in this particular consideration. This switch runs the input against all of the enum'd <syntaxhighlight lang="C++" inline>ConsiderationInput</syntaxhighlight> values so that the program knows where to get the value from in the game engine and, if necessary, process it accordingly.

=== Data ===

=== Export ===

Behavior parameter

2021-10-09T02:52:18Z

Davemark: Davemark moved page Behavior Parameter to Behavior parameter without leaving a redirect: Capitalization

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
A '''Behavior Parameter''' is attached to a [[Behavior]] to help define specific things that behavior needs to execute. Some of them are booleans about whether or not something should occur. For example, specifying an arrival distance to a location or target that the character will be moving to, or whether the behavior should reset where the character is looking or facing when it it executes. Others can be used to pass data into the execution of the behavior. If an action is supposed to place a tag onto a target agent, for instance, the specific tag to be applied can be held in the appropriate behavior parameter.

While there are some built-in behavior parameters from the start (with their relevant code), they can be added to—both in data and with the relevant code for how it is executed—in order to support game-specific things.

== Implementation ==
=== Code ===
The list of available Behavior Params is held in the [[enums]] file as BehaviorParameterType.

<syntaxhighlight lang="C++">
enum class BehaviorParamType
{
ThinkDelay = 1, // How long to wait before thinking after performing this action. (Good for completing animations.)
StopMovement = 2, // Should this behavior stop any existing movement? (1 or 0 for boolean equivalent.)
ArrivalDistance = 3, // What is the distance to use for "arrival"?
SetLooking = 4, // Set head looking. (0=No change, 1=target, 2=self orient)
...
}
</syntaxhighlight>

Behavior Parameters are stored in the Behavior themselves in a sparse data construct (Dictionary in C# or unordered_map in C++). For readability, these are defined in a typedef, "BehaviorParamMap".

<syntaxhighlight lang="C++">
typedef std::unordered_map<BehaviorParamType, float> BehaviorParamMap;
</syntaxhighlight>

They are contained in the Behavior class as "behaviorParams". (Note this must exist in both the IBehavior interface as well as the Behavior class itself.)

<syntaxhighlight lang="C++">
BehaviorParamMap behaviorParams;
</syntaxhighlight>

They are accessed by a function that checks to see if it exists in that behavior's parameters and, if not, returns a default.

<syntaxhighlight lang="C++">
virtual float GetParameterOrDefault(BehaviorParamType thisParamType, float thisDefault);
</syntaxhighlight>

These checks are often performed in individual functions for readability and called from the SetupBehavior function at the start of execution of each behavior.

<syntaxhighlight lang="C++">
void Behavior::SetupBehavior(ContextInfo* thisContext)
{
StopMovementIfDesignated(thisContext);
StopAttackIfDesignated(thisContext);
ApplyTagToTargetIfDesignated(thisContext);
ManageBPIfDesignated(thisContext);
...
}
</syntaxhighlight>

Using simply the first one in that example list, this is a simple Boolean check for the parameter to see if the behavior should force the stoppage of moment.

<syntaxhighlight lang="C++">
void Behavior::StopMovementIfDesignated(ContextInfo* thisContext)
{
bool shouldStop = GetParameterOrDefault(&behaviorParams, BehaviorParamType::StopMovement, 0.0);
if (shouldStop)
{
thisContext->MyBrain()->AbortMovement();
}
}
</syntaxhighlight>

Note that the default is ''0.0'' if it doesn't find the parameter. This is a way of making this check return ''false'' if the parameter is not added. Because of this, there is no need to put the parameter into a behavior if is meant to be false.

=== Data ===
New Behavior Parameters are added from the main in the [[Data Tool]]. At that point, the appropriate handler needs to be created in the code for it to work.

Existing Behavior Parameters are added to a Behavior as necessary in the data tool as well on the page for the specific behavior. Remember that because the data is sparse, do not add a parameter to a behavior unless it is needed.

The entry in the tool will specify which parameter type you are using and a value for that parameter. For things that are Boolean-like, you will enter a 1 or a 0. Note that if the code states that, if there is no parameter entry for that parameter type, it should return a default of 0, then you do not need to enter the parameter with a value of 0. The assumption is that if it is not entered, then it is false.

Behavior ability pair

2021-10-09T02:46:52Z

Davemark: Initial Entries

{{IAUS Header}}
== Concept ==
A '''Behavior Ability Pair (BAP)''' is an object representing the combination of a [[behavior]] and an associated [[ability]].

== Implementation ==
=== Code ===
Because it is merely a combination of a [[behavior]] and an associated [[ability]], those are the only member objects in the class. There is an [[ability type]] and a pointer to the static behavior object. The rest of the information is held in the linked [[behavior#Code|behavior object]]. In fact, all of the accessors from the BAP simply route through to the associated behavior as syntactic sugar. In most cases, it is treated the same way as a regular behavior.

=== Data ===

{{Manual Footer}}

Ability pack

2021-10-08T02:55:10Z

Davemark: /* Concept */

{{IAUS Header}}
== Concept ==
An Ability Pack is similar to a [[Behavior pack]] in that it is a collection of [[behavior ability pair]]s that is named and given a description. They are then assigned to one or more [[brain]]s to indicate that the agent has access to the abilities in it. Typically, Ability packs are "conceptual" in that they contain similar behaviors or behaviors that are part of a large idea.

The difference between a behavior pack and an ability pack is that the ability pack is, rather than a simple list of behaviors, it is a combination of a behavior matched with an [[ability]] in a [[behavior ability pair]]. The way to think of this is that the behavior is "why" something would be done and the ability is "what" to do.

In a way, this is similar to how a behavior has a [[behavior type]] as part of its data. In this case, the behavior type for the behavior in question is "Ability". That is because it is meant to be matched up with the ability specified in the pack.

The use case for this is that different character types may have different actions they perform for largely the same reason. For example, the default melee attack for an orc, a warrior, and a dragon would be largely different and would be dealt with by the game logic differently. If we were to do this in the Behavior data alone, we would have to create three different Behavior Types -- one for each of the three agent types. In this way, however, we can create a single "Default Melee" behavior that specifies the relevant reasons (via [[Consideration]]s) we would want to conduct a melee attack. The Ability Pack would match up the "Default Melee" behavior with the ability for that particular agent type and would be saved with a name that specifies that it is meant for that particular type. By doing this, a Brain can be assigned the appropriate Ability Pack depending on the type of character.

An Ability Pack may therefore have multiple [[behavior ability pair]]s in it. The Behaviors (i.e. the "whys") themselves may be the same but the abilities would be different to show that they are being executed in the agent-specific way. For example, the ''behaviors'' in the Ability Pack may be:
* Default Melee
* Special Melee
* Ranged Attack

However, all three of the above character types would have different abilities matched with them. (e.g. "throw rock", "shoot bow", "breathe fireball").

Because of this organization by concept, more than one Ability Pack ''can be'' assigned to a Brain but often there will only be one that specifies the abilities that the Brain is allowed to use and the reasons it would do so.

== Code ==
The implementation for an ability pack is kept in the class, '''AbilityPackage'''. It is merely a name, description and a list of [[behavior ability pair]]s.

In addition to standard accessor functions, there are functions for adding an ability to the package, removing one from the package, and seeing if an selected ability is already in the list.

== Data ==
Ability packages are created in the [[data tool]] and abilities (with their associated behaviors) are assigned to them there. Once they have been created, they can be assigned to a [[brain]] which has the effect of allowing that brain to use all the abilities in the ability pack.

Ability pack

2021-10-08T02:51:47Z

Davemark: Added implementation details

{{IAUS Header}}
== Concept ==
An Ability Pack is similar to a [[Behavior Pack]] in that it is a collection of [[Behavior]]s that is named and given a description. They are then assigned to one or more [[Brain]]s to indicate that the agent has access to the behaviors in it. Typically, Ability Packs are "conceptual" in that they contain similar behaviors or behaviors that are part of a large idea.

The difference between a Behavior Pack and an Ability Pack is that the Ability Pack is, rather than a simple list of Behaviors, it is a combination of a Behavior matched with an [[Ability]]. The way to think of this is that the Behavior is "why" something would be done and the Ability is "what" to do.

In a way, this is similar to how a Behavior has a [[Behavior Type]] as part of its data. In this case, the Behavior Type for the Behavior in question is "Ability". That is because it is meant to be matched up with the Ability in the pack.

The use case for this is that different character types may have different actions they perform for largely the same reason. For example, the default melee attack for an orc, a warrior, and a dragon would be largely different and would be dealt with by the game logic differently. If we were to do this in the Behavior data alone, we would have to create three different Behavior Types -- one for each of the three agent types. In this way, however, we can create a single "Default Melee" behavior that specifies the relevant reasons (via [[Consideration]]s) we would want to conduct a melee attack. The Ability Pack would match up the "Default Melee" behavior with the ability for that particular agent type and would be saved with a name that specifies that it is meant for that particular type. By doing this, a Brain can be assigned the appropriate Ability Pack depending on the type of character.

An Ability Pack may therefore have multiple [[Behavior Ability Pair]]s in it. The Behaviors (i.e. the "whys") themselves may be the same but the abilities would be different to show that they are being executed in the agent-specific way. For example, the ''behaviors'' in the Ability Pack may be:
* Default Melee
* Special Melee
* Ranged Attack

However, all three of the above character types would have different abilities matched with them. (e.g. "throw rock", "shoot bow", "breathe fireball").

Because of this organization by concept, more than one Ability Pack ''can be '' assigned to a Brain but often there will only be one that specifies the abilities that the Brain is allowed to use and the reasons it would do so.

== Code ==
The implementation for an ability pack is kept in the class, '''AbilityPackage'''. It is merely a name, description and a list of [[behavior ability pair]]s.

In addition to standard accessor functions, there are functions for adding an ability to the package, removing one from the package, and seeing if an selected ability is already in the list.

== Data ==
Ability packages are created in the [[data tool]] and abilities (with their associated behaviors) are assigned to them there. Once they have been created, they can be assigned to a [[brain]] which has the effect of allowing that brain to use all the abilities in the ability pack.

IAUS

2021-10-08T02:49:11Z

Davemark: /* Behavior and Ability Packs */

{{IAUS Header}}

The '''Infinite Axis Utility System (IAUS)''' is the primary behavioral decision-making system in Intrinsic Algorithm's library. While it can be supported by information from other systems (such as the [[Imap]] system or [[Tagging]] system), it is the "brains" of the game agents. This can be applied to individual characters, invisible "team leaders", or even to inanimate objects.

The IAUS exists as a stand-alone black box that can be installed into a project codebase with minimal work. We have both C++ and C# versions based on the needs to the client. In theory, minus any specific custom language or library issues, this means that this core AI system can be installed on day 1 and work can begin on hooking it up to world information, existing behaviors and animation code, and behavior logic can be authored in the tool we have developed for that purpose.

== Concept ==
The concept behind utility is that we are putting together a score for a particular [[Behavior]] based on how appropriate it is at the time. That is, what utility does this have for the character? Once these scores are assembled, we can pick the behavior with the highest score under the assumption that it is the most beneficial and, therefore, is the most appropriate action to take.

The IAUS formalizes this into a complete data-driven architecture that acts in a largely self-contained way such that the only hookups needed are the [[#inputs|inputs]] from objects in the game engine and [[#outputs|outputs]] to actions to take in the game engine.

== Components ==
[[File:Diagram-Brain.png|400px|thumb|right|The high level IAUS structure]]
The IAUS system is comprised of a number of high level components. (Each of these contains lower level components that are detailed on their respective pages.)

=== Brain ===
A [[Brain]] is the top level component that is assigned to an agent in the game. From a data standpoint, a brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the [[brain#Code|brain class]] contains most of the data for the agent's thinking and does most of the work of scoring Behaviors and keeping track of the history of the Behavior usage.

=== Behavior ===
A [[Behavior]] is the core atomic component of the AI system. Each Behavior represents an action that an agent might take and contains the information for scoring the Behavior.

Rather than some architectures that decide solely on a type of behavior and then subsequently choose a target, any behavior that can be targeted at more than one object or character, is scored individually for the combination of the behavior on each specific target. This is called a [[Context]]. For example, rather than deciding to "shoot" and then trying to decide ''who'' to shoot, the IAUS scores all of the shooting action and target contexts individually. So "shoot Chuck" and "shoot Ralph" would get their own scores right alongside each other. The reason for this is that shooting Chuck may score higher then another potential action but shooting Ralph may score lower.

=== Behavior Type ===
Each Behavior is linked with a [[Behavior type|Behavior Type]] that it will execute if the behavior is selected. Behavior types are the core actions that an agent can perform whereas behaviors are more "reasons why" a particular behavior type would be executed. For example, different agent types may have different reasons for engaging in a melee attack. These would be differentiated by each behavior having different [[consideration]]s. However, they all ultimately perform the behavior type, "melee attack". Another wide-ranging example would be the behavior type, "move to target". Whether we are moving towards an ally, an enemy, an object on the ground, or the tavern across the street, they would all be executed in the same way -- i.e. moving to the target object (as specified in the [[context]] that was scored).

Another way of thinking of behavior types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action.

=== Consideration ===

Each behavior is comprised of one or more [[Consideration]]s representing a piece of information that the agent is taking into account when scoring that particular behavior. Each consideration maps the value of an input through a response curve to convert it to an output value. The scores from all of the considerations are then multiplied together to generate the score for that behavior.

=== Decision ===
Each scoring of a Behavior in a Context (i.e. "Behavior A against Target X") is referred to as a [[Decision]]. When deciding what to do, Decisions are scored rather than Behaviors. While the Behavior provides all the necessary reasoning for whether or not it is a good idea (through it's Considerations), if it is a targeted behavior, it cannot be scored without understanding who or what is being targeted. For example, a Behavior "shoot enemy" that has a Consideration for the distance to that enemy needs to be able to reference the specific entity's location to calculate the distance. If it is not a targeted behavior, then any Considerations that expect there to be a target in the Context will not return a value.

=== Behavior and Ability Packs ===

Behaviors are contained in [[behavior pack]]s and [[ability pack]]s -- usually by their type of usage. This is both for the sake of convenience when dealing with many behaviors that are designed to go together. However, by doing this, the are able to be added and removed as a group as necessary. Additionally, if a new behavior is added to a Behavior Pack (because it is designed to go with the other behaviors in that pack), then all the [[Brain]]s that contain that Behavior Pack will get the new behavior.

== Installation ==
=== Software ===

==== Core Code ====

==== Data Tool ====

=== Database ===

=== Connections ===

==== Inputs ====

==== Outputs ====

== Usage ==

{{Manual Footer}}

Behavior pack

2021-10-08T02:47:21Z

Davemark: /* Data */

{{IAUS Header}}
== Concept ==
A Behavior Pack is merely a collection of [[Behavior]]s that is named and given a description. They are then assigned to one or more [[Brain]]s to indicate that the agent has access to the behaviors in it. Typically, Behavior Packs are "conceptual" in that they contain similar behaviors or behaviors that are part of a large idea. For example, Behavior Packs may be named (and filled accordingly):
* "Tactical Movement"
* "Ambient Wander"
* "Social Emotes"

Some may be specific to a type of character archetype and would be named and filled accordingly. So instead of simply a "Tactical Movement" Behavior Pack, there may also be a "Tactical Movement - Aggressive" one. Some of the contents may be the same but the latter may have some more aggressive Behaviors such as one that closes to melee range regardless of the character's health. By doing this, a Brain can be assigned the appropriate Behavior Pack depending on the type of character and the desired behavior.

Because of this organization by concept, typically more than one Behavior Pack is assigned to a Brain.

== Code ==
The implementation for a behavior pack is kept in the class, '''BehaviorPackage'''. It is merely a name, description and a list of [[behavior]]s.

In addition to standard accessor functions, there are functions for adding a behavior to the package, removing one from the package, and seeing if an selected behavior is already in the list.

== Data ==
Behavior packages are created in the [[data tool]] and behaviors are assigned to them there. Once they have been created, they can be assigned to a [[brain]] which has the effect of allowing that brain to use all the behaviors in the behavior pack.

Behavior pack

2021-10-08T02:46:08Z

Davemark: /* Code */

IAUS

2021-10-08T02:42:51Z

Davemark: /* Concept */

{{IAUS Header}}

The '''Infinite Axis Utility System (IAUS)''' is the primary behavioral decision-making system in Intrinsic Algorithm's library. While it can be supported by information from other systems (such as the [[Imap]] system or [[Tagging]] system), it is the "brains" of the game agents. This can be applied to individual characters, invisible "team leaders", or even to inanimate objects.

The IAUS exists as a stand-alone black box that can be installed into a project codebase with minimal work. We have both C++ and C# versions based on the needs to the client. In theory, minus any specific custom language or library issues, this means that this core AI system can be installed on day 1 and work can begin on hooking it up to world information, existing behaviors and animation code, and behavior logic can be authored in the tool we have developed for that purpose.

== Concept ==
The concept behind utility is that we are putting together a score for a particular [[Behavior]] based on how appropriate it is at the time. That is, what utility does this have for the character? Once these scores are assembled, we can pick the behavior with the highest score under the assumption that it is the most beneficial and, therefore, is the most appropriate action to take.

The IAUS formalizes this into a complete data-driven architecture that acts in a largely self-contained way such that the only hookups needed are the [[#inputs|inputs]] from objects in the game engine and [[#outputs|outputs]] to actions to take in the game engine.

== Components ==
[[File:Diagram-Brain.png|400px|thumb|right|The high level IAUS structure]]
The IAUS system is comprised of a number of high level components. (Each of these contains lower level components that are detailed on their respective pages.)

=== Brain ===
A [[Brain]] is the top level component that is assigned to an agent in the game. From a data standpoint, a brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the [[brain#Code|brain class]] contains most of the data for the agent's thinking and does most of the work of scoring Behaviors and keeping track of the history of the Behavior usage.

=== Behavior ===
A [[Behavior]] is the core atomic component of the AI system. Each Behavior represents an action that an agent might take and contains the information for scoring the Behavior.

Rather than some architectures that decide solely on a type of behavior and then subsequently choose a target, any behavior that can be targeted at more than one object or character, is scored individually for the combination of the behavior on each specific target. This is called a [[Context]]. For example, rather than deciding to "shoot" and then trying to decide ''who'' to shoot, the IAUS scores all of the shooting action and target contexts individually. So "shoot Chuck" and "shoot Ralph" would get their own scores right alongside each other. The reason for this is that shooting Chuck may score higher then another potential action but shooting Ralph may score lower.

=== Behavior Type ===
Each Behavior is linked with a [[Behavior type|Behavior Type]] that it will execute if the behavior is selected. Behavior types are the core actions that an agent can perform whereas behaviors are more "reasons why" a particular behavior type would be executed. For example, different agent types may have different reasons for engaging in a melee attack. These would be differentiated by each behavior having different [[consideration]]s. However, they all ultimately perform the behavior type, "melee attack". Another wide-ranging example would be the behavior type, "move to target". Whether we are moving towards an ally, an enemy, an object on the ground, or the tavern across the street, they would all be executed in the same way -- i.e. moving to the target object (as specified in the [[context]] that was scored).

Another way of thinking of behavior types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action.

=== Consideration ===

Each behavior is comprised of one or more [[Consideration]]s representing a piece of information that the agent is taking into account when scoring that particular behavior. Each consideration maps the value of an input through a response curve to convert it to an output value. The scores from all of the considerations are then multiplied together to generate the score for that behavior.

=== Decision ===
Each scoring of a Behavior in a Context (i.e. "Behavior A against Target X") is referred to as a [[Decision]]. When deciding what to do, Decisions are scored rather than Behaviors. While the Behavior provides all the necessary reasoning for whether or not it is a good idea (through it's Considerations), if it is a targeted behavior, it cannot be scored without understanding who or what is being targeted. For example, a Behavior "shoot enemy" that has a Consideration for the distance to that enemy needs to be able to reference the specific entity's location to calculate the distance. If it is not a targeted behavior, then any Considerations that expect there to be a target in the Context will not return a value.

=== Behavior and Ability Packs ===

Behaviors are contained in [[Behavior Pack]]s and [[Ability Pack]]s -- usually by their type of usage. This is both for the sake of convenience when dealing with many behaviors that are designed to go together. However, by doing this, the are able to be added and removed as a group as necessary. Additionally, if a new behavior is added to a Behavior Pack (because it is designed to go with the other behaviors in that pack), then all the [[Brain]]s that contain that Behavior Pack will get the new behavior.

== Installation ==
=== Software ===

==== Core Code ====

==== Data Tool ====

=== Database ===

=== Connections ===

==== Inputs ====

==== Outputs ====

== Usage ==

{{Manual Footer}}

Main Page

2021-10-08T02:39:55Z

Davemark: /* Infinite Axis Utility System (IAUS) */

{{Manual Header}}

This is the place to access all the descriptions, information, and usage manuals for all of Intrinsic Algorithm's game development technology. Some of these will be filled out slower than others and they will be updated as technology changes or features are added. You will also find references to lectures and documents about these products as well as game and AI development in general.

== Technologies ==
The following is a list of the technologies that are offered by IA and have information contained in this section.

=== Infinite Axis Utility System (IAUS) ===
Dave Mark is well known in AI circles, particularly at the GDC AI Summit, as being a [http://intrinsicalgorithm.com/IAonAI/2013/02/both-my-gdc-lectures-on-utility-theory-free-on-gdc-vault/ proponent of] [https://en.wikipedia.org/wiki/Utility_system utility-based AI]. While utility can be (and has been) applied to many different types of architectures for decades, he has developed a stand-alone architecture based entirely on utility mechanisms. Over the past 8 years, he has continued to improve this method and deployed it to great success in his contract work with a variety of companies.

The '''[[IAUS|Infinite Access Utility System (IAUS)]]''' was spoken about briefly at the GDC AI Summit in 2013 as his part of a multi-person talk entitled, [https://gdcvault.com/play/1018040/Architecture-Tricks-Managing-Behaviors-in "Architecture Tricks: Managing Behaviors in Time, Space, and Depth"] (You can skip to 33:35 for the beginning of his segment.)

[[File:Fist Bump.PNG|200px|thumb|right|Dave Mark and Mike Lewis, GDC 2015 AI Summit]]
Additionally, he spoke about it at length with Mike Lewis of ArenaNet in the 2015 GDC AI Summit specifically in regard to how it was deployed at ArenaNet for use in the GuildWars 2: Heart of Thorns expansion in their lecture, [https://gdcvault.com/play/1021848/Building-a-Better-Centaur-AI "Building a Better Centaur: AI at Massive Scale"] This one hour lecture also shows how the entire architecture works (at the time) as well as tidbits of some of the other technologies that were included in that game. Importantly, he demonstrates via a time-lapse video how the modular data-driven design of the IAUS enables designers to construct unique AI packages for their NPCs in as little as seven minutes. Additionally, as a result of this modular data-driven system, core behaviors authored by any designer can be added to any character with ease. Because all the behaviors are allowed to "play together" as they are scored, it is simply a matter of the designer selecting which ones the NPC should have at it's disposal.

The IAUS exists as a stand-alone black box that can be installed into a project codebase with minimal work. We have both C++ and C# versions based on the needs to the client. In theory, minus any specific custom language or library issues, this means that this core AI system can be installed on day 1 and work can begin on hooking it up to world information, existing behavior and animation code, and behavior logic can be authored in the tool we have developed for that purpose.

=== Modular Scalable Influence Map System (Imap) ===
Much like the IAUS above, our [[IMAP|Imap system]] has been worked on for over 6 years and has been used in a number of shipped titles. Over that time, this architecture has been extended and optimized. However, it's core beneficial use has remained intact and improved upon. It is a general knowledge representation system that allows for analysis of spatial, tactical, strategic, and ecological situations. This is used for NPCs to easily query information about the distribution of dozens... or even hundreds... of other agents in the world on the enemy team, their own team, neutral agents or objects, or any combination of the above to get information about a specific location (e.g. "am I crowded?" or "how much threat am I under right here?") or to find locations where something should be performed (e.g. "where is the safest place to stand?" or "where should I use this area of effect spell?")

As with the IAUS, the Imap system exists a stand-alone black box that can be installed into a project codebase and calibrated to whatever spatial and coordinate system the existing project runs on. Additionally, many of the queries for commonly used information and code for commonly used movement and targeting locations exist already as part of the install. New Imap queries can be completed usually in only a few lines of code. Often in minutes. As planned future work, the system allows for data-driven implementation of these queries so that designers can mix-and-match their own combinations of influence map data for specific behaviors without programmer involvement.

Dave covered an overview of his Imap system in a lecture in the 2018 GDC AI Summit entitled, [http://www.gdcvault.com/play/1025243/Spatial-Knowledge-Representation-through-Modular "Spatial Knowledge Representation through Modular Scalable Influence Maps"].

=== Robust Tagging System ===
To support the above technologies—and for other things—we have developed a [[Tag System|robust tagging system]]. This allows designers to tag objects and NPCs to provide very useful contextual information that the AI can understand.

=== Text Dialog System ===
For text based games that do not want repetitive text dialog, we have developed a dialog system that is entirely designer-driven. With it, a designer can specify a near infinite number of parameterized text statements that can then be filled out with relevant information from the game and filtered appropriately for use by different types of characters.

== References ==
<references />

{{Manual Footer}}

IAUS

2021-10-08T02:37:55Z

Davemark: /* Behavior Type */

{{IAUS Header}}

The '''Infinite Axis Utility System (IAUS)''' is the primary behavioral decision-making system in Intrinsic Algorithm's library. While it can be supported by information from other systems (such as the [[Imap]] system or [[Tagging]] system), it is the "brains" of the game agents. This can be applied to individual characters, invisible "team leaders", or even to inanimate objects.

The IAUS exists as a stand-alone black box that can be installed into a project codebase with minimal work. We have both C++ and C# versions based on the needs to the client. In theory, minus any specific custom language or library issues, this means that this core AI system can be installed on day 1 and work can begin on hooking it up to world information, existing behaviors and animation code, and behavior logic can be authored in the tool we have developed for that purpose.

== Concept ==
The concept behind utility is that we are putting together a score for a particular [[Behavior]] based on how appropriate it is at the time. That is, what utility does this have for the character? Once these scores are assembled, we can pick the behavior with the highest score under the assumption that it is the most beneficial and, therefore, is the most appropriate action to take.

The IAUS formalizes this into a complete data-driven architecture that acts in a largely self-contained way such that the only hookups needed are the inputs from objects in the game engine and outputs to actions to take in the game engine.

== Components ==
[[File:Diagram-Brain.png|400px|thumb|right|The high level IAUS structure]]
The IAUS system is comprised of a number of high level components. (Each of these contains lower level components that are detailed on their respective pages.)

=== Brain ===
A [[Brain]] is the top level component that is assigned to an agent in the game. From a data standpoint, a brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the [[brain#Code|brain class]] contains most of the data for the agent's thinking and does most of the work of scoring Behaviors and keeping track of the history of the Behavior usage.

=== Behavior ===
A [[Behavior]] is the core atomic component of the AI system. Each Behavior represents an action that an agent might take and contains the information for scoring the Behavior.

Rather than some architectures that decide solely on a type of behavior and then subsequently choose a target, any behavior that can be targeted at more than one object or character, is scored individually for the combination of the behavior on each specific target. This is called a [[Context]]. For example, rather than deciding to "shoot" and then trying to decide ''who'' to shoot, the IAUS scores all of the shooting action and target contexts individually. So "shoot Chuck" and "shoot Ralph" would get their own scores right alongside each other. The reason for this is that shooting Chuck may score higher then another potential action but shooting Ralph may score lower.

=== Behavior Type ===
Each Behavior is linked with a [[Behavior type|Behavior Type]] that it will execute if the behavior is selected. Behavior types are the core actions that an agent can perform whereas behaviors are more "reasons why" a particular behavior type would be executed. For example, different agent types may have different reasons for engaging in a melee attack. These would be differentiated by each behavior having different [[consideration]]s. However, they all ultimately perform the behavior type, "melee attack". Another wide-ranging example would be the behavior type, "move to target". Whether we are moving towards an ally, an enemy, an object on the ground, or the tavern across the street, they would all be executed in the same way -- i.e. moving to the target object (as specified in the [[context]] that was scored).

Another way of thinking of behavior types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action.

=== Consideration ===

Each behavior is comprised of one or more [[Consideration]]s representing a piece of information that the agent is taking into account when scoring that particular behavior. Each consideration maps the value of an input through a response curve to convert it to an output value. The scores from all of the considerations are then multiplied together to generate the score for that behavior.

=== Decision ===
Each scoring of a Behavior in a Context (i.e. "Behavior A against Target X") is referred to as a [[Decision]]. When deciding what to do, Decisions are scored rather than Behaviors. While the Behavior provides all the necessary reasoning for whether or not it is a good idea (through it's Considerations), if it is a targeted behavior, it cannot be scored without understanding who or what is being targeted. For example, a Behavior "shoot enemy" that has a Consideration for the distance to that enemy needs to be able to reference the specific entity's location to calculate the distance. If it is not a targeted behavior, then any Considerations that expect there to be a target in the Context will not return a value.

=== Behavior and Ability Packs ===

Behaviors are contained in [[Behavior Pack]]s and [[Ability Pack]]s -- usually by their type of usage. This is both for the sake of convenience when dealing with many behaviors that are designed to go together. However, by doing this, the are able to be added and removed as a group as necessary. Additionally, if a new behavior is added to a Behavior Pack (because it is designed to go with the other behaviors in that pack), then all the [[Brain]]s that contain that Behavior Pack will get the new behavior.

== Installation ==
=== Software ===

==== Core Code ====

==== Data Tool ====

=== Database ===

=== Connections ===

==== Inputs ====

==== Outputs ====

== Usage ==

{{Manual Footer}}

IAUS

2021-10-08T02:33:53Z

Davemark: /* Brain */

{{IAUS Header}}

The '''Infinite Axis Utility System (IAUS)''' is the primary behavioral decision-making system in Intrinsic Algorithm's library. While it can be supported by information from other systems (such as the [[Imap]] system or [[Tagging]] system), it is the "brains" of the game agents. This can be applied to individual characters, invisible "team leaders", or even to inanimate objects.

The IAUS exists as a stand-alone black box that can be installed into a project codebase with minimal work. We have both C++ and C# versions based on the needs to the client. In theory, minus any specific custom language or library issues, this means that this core AI system can be installed on day 1 and work can begin on hooking it up to world information, existing behaviors and animation code, and behavior logic can be authored in the tool we have developed for that purpose.

== Concept ==
The concept behind utility is that we are putting together a score for a particular [[Behavior]] based on how appropriate it is at the time. That is, what utility does this have for the character? Once these scores are assembled, we can pick the behavior with the highest score under the assumption that it is the most beneficial and, therefore, is the most appropriate action to take.

The IAUS formalizes this into a complete data-driven architecture that acts in a largely self-contained way such that the only hookups needed are the inputs from objects in the game engine and outputs to actions to take in the game engine.

== Components ==
[[File:Diagram-Brain.png|400px|thumb|right|The high level IAUS structure]]
The IAUS system is comprised of a number of high level components. (Each of these contains lower level components that are detailed on their respective pages.)

=== Brain ===
A [[Brain]] is the top level component that is assigned to an agent in the game. From a data standpoint, a brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the [[brain#Code|brain class]] contains most of the data for the agent's thinking and does most of the work of scoring Behaviors and keeping track of the history of the Behavior usage.

=== Behavior ===
A [[Behavior]] is the core atomic component of the AI system. Each Behavior represents an action that an agent might take and contains the information for scoring the Behavior.

Rather than some architectures that decide solely on a type of behavior and then subsequently choose a target, any behavior that can be targeted at more than one object or character, is scored individually for the combination of the behavior on each specific target. This is called a [[Context]]. For example, rather than deciding to "shoot" and then trying to decide ''who'' to shoot, the IAUS scores all of the shooting action and target contexts individually. So "shoot Chuck" and "shoot Ralph" would get their own scores right alongside each other. The reason for this is that shooting Chuck may score higher then another potential action but shooting Ralph may score lower.

=== Behavior Type ===
Each Behavior is linked with a [[Behavior Type|Behavior Type]] that it will execute if the behavior is selected. Behavior Types are the core actions that an agent can perform whereas behaviors are more "reasons why" a particular Behavior Type would be executed. For example, different agent types may have different reasons for engaging in a melee attack. These would be differentiated by each Behavior having different Considerations. However, they all ultimately perform the Behavior Type, "melee attack". Another wide-ranging example would be the Behavior Type, "move to target". Whether we are moving towards an ally, an enemy, an object on the ground, or the tavern across the street, they would all be executed in the same way -- i.e. moving to the target object (as specified in the Context that was scored). Another way of thinking of Behavior Types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action.

=== Consideration ===

Each behavior is comprised of one or more [[Consideration]]s representing a piece of information that the agent is taking into account when scoring that particular behavior. Each consideration maps the value of an input through a response curve to convert it to an output value. The scores from all of the considerations are then multiplied together to generate the score for that behavior.

=== Decision ===
Each scoring of a Behavior in a Context (i.e. "Behavior A against Target X") is referred to as a [[Decision]]. When deciding what to do, Decisions are scored rather than Behaviors. While the Behavior provides all the necessary reasoning for whether or not it is a good idea (through it's Considerations), if it is a targeted behavior, it cannot be scored without understanding who or what is being targeted. For example, a Behavior "shoot enemy" that has a Consideration for the distance to that enemy needs to be able to reference the specific entity's location to calculate the distance. If it is not a targeted behavior, then any Considerations that expect there to be a target in the Context will not return a value.

=== Behavior and Ability Packs ===

Behaviors are contained in [[Behavior Pack]]s and [[Ability Pack]]s -- usually by their type of usage. This is both for the sake of convenience when dealing with many behaviors that are designed to go together. However, by doing this, the are able to be added and removed as a group as necessary. Additionally, if a new behavior is added to a Behavior Pack (because it is designed to go with the other behaviors in that pack), then all the [[Brain]]s that contain that Behavior Pack will get the new behavior.

== Installation ==
=== Software ===

==== Core Code ====

==== Data Tool ====

=== Database ===

=== Connections ===

==== Inputs ====

==== Outputs ====

== Usage ==

{{Manual Footer}}

Context type

2021-10-07T14:13:02Z

Davemark: /* Concept */

{{IAUS Header}}
{{Part of Behavior}}

== Concept ==
The '''Context Type''' for a [[behavior]] specifies how the behavior should apply the scoring and effects of the behavior.

== Implementation ==
=== Code ===
It is stored as a simple enum, "ContextType" in the [[enums]] file.

<syntaxhighlight lang="C++">
enum class ContextType
{
StandAlone = 1, // Works regardless of any specified target
Self = 2, // Uses owner's agent as target
SingleTarget = 3, // Can be used on target agent in the world -- scored per target
LocationTarget = 4, // Is used on a specific, single, pre-determined location in the world
SingleTargetOnSelf = 5, // Scored per target agent in the world but used on self
};
</syntaxhighlight>

==== Stand Alone ====
"StandAlone" can be used for anything that isn't acting ''upon'' an object. This is considered an un-targeted behavior. For example, a random wander behavior that is going to select and move to a nearby world location would be good for "StandAlone."

==== Self ====
The most commonly used items are "Self" and "SingleTarget". Self just means that the Behavior is scored once and the implementation of the BehaviorType is applied to the acting character itself.

==== Single Target ====
SingleTarget, on the other hand, is scored once per potential target (thereby creating individual [[Decision]]s for each combination of the Behavior and a Target) and executed specifically at that Target.

Note that there is often a distinction between these two with an action. An emote of "yawn" is something that is played by the character itself and is un-targeted (and therefore could be "StandAlone". However, an emote of "wave" is necessarily directed at another agent and would, therefore, need to be specified as "SingleTarget". A good way of understand which one to use is to ask the question, "who am I going to do this on/to?" In the above examples, you aren't going to yawn ''at'' anyone. However, you can decide among many potential targets to wave to. ("Should I wave at Chuck or Ralph?")

"SingleTarget" specifically excludes the agent that is considering the behavior. Therefore a "heal" action that the character can perform an allies or on itself would need to have two separate behaviors.

==== Location Target ====
"LocationTarget" specifies that there will be a target location in the future. However, unlike "SingleTarget", it isn't scored more than once. An example would be using an area of effect spell. You have decided you want to cast your fireball because there is a large group of enemies clustered together (see the [[Imap]] system). However, the exact calculation of where the center of those enemies is will be calculated on the execution of the action.

==== Single Target on Self ====
"SingleTargetOnSelf" is scored per agent in the world (like "SingleTarget") but the effect is executed on the agent itself.

Behavior

2021-10-07T14:12:20Z

Davemark: /* Context Type */

{{IAUS Header}}

== Concept ==
[[File:Diagram - Behavior.png|400px|thumb|right|Behavior as part of the IAUS structure]]
A Behavior defines not ''what'' a character will do, but ''why a character may do something.'' As such, a Behavior is the core component of the decision reasoning. As result, much of the work involved with creating and tuning character AI is done by creation and editing of behaviors.

However, it should be noted that a Behavior does not actually define the ''execution'' of the behavior–the actual action that it performs in the game. That is done by the associated [[#Behavior Type|Behavior Type]].

== Components ==

=== Considerations ===
A behavior is comprised of 1 or more [[Consideration]]s. These provide information on the things that the agent would need to take into account when scoring whether or not the action is suitable to do.

=== Behavior Type ===
A behavior is paired with a [[behavior type]] to determine what action is actually taken if this behavior is selected.

Behaviors that can be directed at more than one potential target (as specified by the behavior's [[#Context Type|context type]]) are combined with those targets in a [[context]] which then becomes part of a [[decision]]. If a behavior is ''not'' to be potentially targeted at different agents (i.e. only scored once), it is still added to a context and a decision, but the target may be the agent itself, a location in the world, or none.

=== Context Type ===

A behavior uses a [[context type]] to determine how it should be scored -- e.g. on the agent itself only, on individual targets, etc.

=== Duration ===

A behavior has a [[Duration]] -- usually "Instant" or "Continuous" -- to specify how it should be treated once it begins execution.

=== Behavior Parameters ===

[[Behavior Parameter]]s allow us to specify data that is very specific to the behavior when it is executed.

== Implementation ==

=== Code ===

A Behavior does not have specific code. It is a data construct only. The inputs are retrieved by the individual [[Consideration]]s and the outputs are processed by the related [[Behavior Type]].

Note that this should not be confused with the [[Behavior Class]] which is the parent of all the Behavior Type classes.

=== Data ===

Because of the role they play in defining how characters act, Behaviors are one of the most central data points in the DB. As such, they are one of the most numerous and oft-changing items in the database.

==== Export ====

Behaviors need to be exported from the database into a file or other data structure to be read by the game on startup. This data will be loaded by the [[Behavior Data]] class.

{{Manual Footer}}

Behavior

2021-10-07T14:12:01Z

Davemark: /* Behavior Type */

{{IAUS Header}}

== Concept ==
[[File:Diagram - Behavior.png|400px|thumb|right|Behavior as part of the IAUS structure]]
A Behavior defines not ''what'' a character will do, but ''why a character may do something.'' As such, a Behavior is the core component of the decision reasoning. As result, much of the work involved with creating and tuning character AI is done by creation and editing of behaviors.

However, it should be noted that a Behavior does not actually define the ''execution'' of the behavior–the actual action that it performs in the game. That is done by the associated [[#Behavior Type|Behavior Type]].

== Components ==

=== Considerations ===
A behavior is comprised of 1 or more [[Consideration]]s. These provide information on the things that the agent would need to take into account when scoring whether or not the action is suitable to do.

=== Behavior Type ===
A behavior is paired with a [[behavior type]] to determine what action is actually taken if this behavior is selected.

Behaviors that can be directed at more than one potential target (as specified by the behavior's [[#Context Type|context type]]) are combined with those targets in a [[context]] which then becomes part of a [[decision]]. If a behavior is ''not'' to be potentially targeted at different agents (i.e. only scored once), it is still added to a context and a decision, but the target may be the agent itself, a location in the world, or none.

=== Context Type ===

A behavior uses a [[Context Type]] to determine how it should be scored -- e.g. on the agent itself only, on individual targets, etc.

=== Duration ===

A behavior has a [[Duration]] -- usually "Instant" or "Continuous" -- to specify how it should be treated once it begins execution.

=== Behavior Parameters ===

[[Behavior Parameter]]s allow us to specify data that is very specific to the behavior when it is executed.

== Implementation ==

=== Code ===

A Behavior does not have specific code. It is a data construct only. The inputs are retrieved by the individual [[Consideration]]s and the outputs are processed by the related [[Behavior Type]].

Note that this should not be confused with the [[Behavior Class]] which is the parent of all the Behavior Type classes.

=== Data ===

Because of the role they play in defining how characters act, Behaviors are one of the most central data points in the DB. As such, they are one of the most numerous and oft-changing items in the database.

==== Export ====

Behaviors need to be exported from the database into a file or other data structure to be read by the game on startup. This data will be loaded by the [[Behavior Data]] class.

{{Manual Footer}}

Behavior type

2021-10-07T14:10:45Z

Davemark: /* Code */

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Behavior Type.png|400px|thumb|right|Behavior Type as part of the IAUS structure]]

'''Behavior Types''' are the core actions that an agent can perform.

One way of thinking of Behavior Types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action. Note that this is different from a [[Behavior]] which is merely a data construct that helps the agent calculate the utility of the potential action and decide ''why'' to do it. The Behavior Type expresses ''what'' the action entails.

== Examples ==
Examples of Behavior Types are:
* "Move to Target"
* "Face Target"
* "Play Animation".

Actions that would fall under the "Ability" Behavior Type could be:
* "melee attack"
* "ranged attack"
* "special attack"
* "Orc Mage Fireball"

Again, these would all be specified as "Ability" for their Behavior Type with the matchup to the appropriate action handled elsewhere.

== Implementation ==
=== Code ===
In code, each Behavior Type is given it's own class that is inherited from the [[behavior class]]. The mappings between the enum and the appropriate class are done in the [[behavior data]] class. Therefore, if a new Behavior Type is created in the data tool, the sub-class needs to be written (in Behavior.cpp) and there needs to be a matchup specified in BehaviorData.cpp as well.

Note that there will often be a behavior type called "Ability". This is intentionally generic as it is handled in a different way by a different class.

=== Data ===
Behavior Types are specified in the data tool as simply a list that gets exported to the [[Enums]] file.

{{Manual Footer}}

Decision

2021-10-07T14:09:32Z

Davemark: /* Concept */

{{IAUS Header}}

== Concept ==
A '''Decision''' is a combination of a [[behavior]] and a [[target]]. This target can be self or another agent if the [[context type]] for the behavior is [[Context type#Single Target|Context—Single Target]]. Decisions are what are assembled into a list at the beginning of each [[think cycle]] and scored accordingly.

== Code ==

== Usage ==

Context type

2021-10-07T14:09:10Z

Davemark: Davemark moved page Context Type to Context type without leaving a redirect: Capitalization

{{IAUS Header}}
{{Part of Behavior}}

== Concept ==
The Context Type for a [[Behavior]] specifies how the Behavior should apply the scoring and effects of the Behavior.

== Implementation ==
=== Code ===
It is stored as a simple enum, "ContextType" in the [[enums]] file.

<syntaxhighlight lang="C++">
enum class ContextType
{
StandAlone = 1, // Works regardless of any specified target
Self = 2, // Uses owner's agent as target
SingleTarget = 3, // Can be used on target agent in the world -- scored per target
LocationTarget = 4, // Is used on a specific, single, pre-determined location in the world
SingleTargetOnSelf = 5, // Scored per target agent in the world but used on self
};
</syntaxhighlight>

==== Stand Alone ====
"StandAlone" can be used for anything that isn't acting ''upon'' an object. This is considered an un-targeted behavior. For example, a random wander behavior that is going to select and move to a nearby world location would be good for "StandAlone."

==== Self ====
The most commonly used items are "Self" and "SingleTarget". Self just means that the Behavior is scored once and the implementation of the BehaviorType is applied to the acting character itself.

==== Single Target ====
SingleTarget, on the other hand, is scored once per potential target (thereby creating individual [[Decision]]s for each combination of the Behavior and a Target) and executed specifically at that Target.

Note that there is often a distinction between these two with an action. An emote of "yawn" is something that is played by the character itself and is un-targeted (and therefore could be "StandAlone". However, an emote of "wave" is necessarily directed at another agent and would, therefore, need to be specified as "SingleTarget". A good way of understand which one to use is to ask the question, "who am I going to do this on/to?" In the above examples, you aren't going to yawn ''at'' anyone. However, you can decide among many potential targets to wave to. ("Should I wave at Chuck or Ralph?")

"SingleTarget" specifically excludes the agent that is considering the behavior. Therefore a "heal" action that the character can perform an allies or on itself would need to have two separate behaviors.

==== Location Target ====
"LocationTarget" specifies that there will be a target location in the future. However, unlike "SingleTarget", it isn't scored more than once. An example would be using an area of effect spell. You have decided you want to cast your fireball because there is a large group of enemies clustered together (see the [[Imap]] system). However, the exact calculation of where the center of those enemies is will be calculated on the execution of the action.

==== Single Target on Self ====
"SingleTargetOnSelf" is scored per agent in the world (like "SingleTarget") but the effect is executed on the agent itself.

Duration

2021-10-07T13:51:46Z

Davemark: /* Concept */

{{IAUS Header}}
<hr>
{{Part of Behavior}}

== Concept ==
The '''Duration Type''' for a [[behavior]] specifies how long a behavior should run. If it is set to "'''instant'''", the behavior runs once and doesn't carry over until the next cycle. If it is set to "'''continuous'''", there is a factor added to its score on the next [[think cycle]] that increases its score by 25% (as a default). Known as "decision momentum," this helps prevent "state strobing" where two (or more) similarly scoring behaviors keep switching back and forth between each other. Therefore, there would need to be a significant increase in one of the ''other'' behaviors to overcome that momentum and change the behavior.

Additionally, it changes how [[behavior history|behavior histories]] are processed. An '''instant''' behavior registers that it is has been run when it is executed. A '''continuous''' behavior doesn't register that has been run until a ''new'' behavior is selected and takes its place.

When executing a behavior, all behaviors run both the [[behavior setup]] and [[execute action]] routines contained in the code for the [[behavior type]]. However, a '''continuous''' behavior will only run the Execute routine on subsequent calls while it continues to run.

== Code ==
It is stored as a simple enum, "DurationType" in the [[enums]] file.

<syntaxhighlight lang="C++">
enum class DurationType
{
Instant = 1, // Used once and is over
Continuous = 2 // Can continue over multiple think cycles
};
</syntaxhighlight>

== Data ==
There is no editable data in the [[Data Tool]] for Duration Type. It is exported along with the other enums, however.

Behavior history

2021-10-07T13:51:08Z

Davemark: Davemark moved page Behavior History to Behavior history without leaving a redirect: Capitalization

{{IAUS Header}}
<hr>
{{Part of Brain}}
==Concept==
'''Behavior Histories''' keep track of the last time a [[Behavior]] was executed by an agent. This allows for checking the [[Behavior Runtime|runtime]] of the current behavior and the [[Behavior Cooldown|time since the behavior was run]].

This is also tracked for [[Behavior Type|behavior types]] as well so that one can tell when a ''type'' was done regardless of the specific behavior that called it. For example, "when was the last time I did a MoveToTarget?" can be checked even though there might be dozens of different behaviors that call "MoveToTarget".

Additionally, it keeps track of [[Context]] times so that information can be accessed on when a particular behavior was run with a particular [[target]]. This allows the same behavior to be run without repeating it at a particular target. One example would be waving at a variety of passing villagers but not at the same villager on a repeated basis.

==Code==
For readability of code, the various maps and their components are kept in typedefs.
<nowiki>
typedef std::unordered_map<unsigned int, float> BehaviorHistoryMap;
typedef std::pair<unsigned int, float> BehaviorHistoryIdAndTime;

typedef std::unordered_map<ContextEntry, float> ContextHistoryMap;
typedef std::pair<ContextEntry, float> ContextHistoryIdAndTime;

typedef std::unordered_map<BehaviorType, float> BehaviorTypeHistoryMap;
typedef std::pair<BehaviorType, float> BehaviorTypeIdAndTime;</nowiki>
The actual objects are in the member variables in [[Brain]]:
<nowiki>
//////////////////////////////////////////////////////////////////////////
// History Tracking
BehaviorHistoryMap behaviorHistory; // History of recent behaviors I have performed (no context)
ContextHistoryMap contextHistory; // History of recent decisions I have performed (incl. behavior and context)
BehaviorTypeHistoryMap behaviorTypeHistory; // History of recent behaviors I have performed by type only</nowiki>
Each of the maps has functions for:
* Storing an entry
* Getting the last time from an entry
* Cleaning the history based on an expiry time
Cleaning the histories is called from the iteration of the [[Think Cycle#Processing Histories|think cycle]]

Duration

2021-10-07T13:50:45Z

Davemark: /* Concept */

{{IAUS Header}}
<hr>
{{Part of Behavior}}

== Concept ==
The '''Duration Type''' for a [[behavior]] specifies how long a behavior should run. If it is set to "'''instant'''", the behavior runs once and doesn't carry over until the next cycle. If it is set to "'''continuous'''", there is a factor added to its score on the next [[think cycle]] that increases its score by 25% (as a default). Known as "decision momentum," this helps prevent "state strobing" where two (or more) similarly scoring behaviors keep switching back and forth between each other. Therefore, there would need to be a significant increase in one of the ''other'' behaviors to overcome that momentum and change the behavior.

Additionally, it changes how [[Behavior history|behavior histories]] are processed. An '''instant''' behavior registers that it is has been run when it is executed. A '''continuous''' behavior doesn't register that has been run until a ''new'' behavior is selected and takes its place.

When executing a behavior, all behaviors run both the [[behavior setup]] and [[execute action]] routines contained in the code for the [[behavior type]]. However, a '''continuous''' behavior will only run the Execute routine on subsequent calls while it continues to run.

== Code ==
It is stored as a simple enum, "DurationType" in the [[enums]] file.

<syntaxhighlight lang="C++">
enum class DurationType
{
Instant = 1, // Used once and is over
Continuous = 2 // Can continue over multiple think cycles
};
</syntaxhighlight>

== Data ==
There is no editable data in the [[Data Tool]] for Duration Type. It is exported along with the other enums, however.

Think cycle

2021-10-07T13:48:23Z

Davemark: Davemark moved page Think Cycle to Think cycle without leaving a redirect: Capitalization

{{IAUS Header}}
{{Part of Brain}}
==Concept==
The '''Think Cycle''' is what the [[Brain]] uses to start processing potential decisions and, if necessary select a new [[Behavior]] (and possibly target) to execute. It is what is called by the game engine on a regular basis. The game engine, however, doesn't need to pace the ticking of the think cycle since that timing is already built into and modified as appropriate.

===Checks===

First, the game checks if the Brain ''can'' think. For example, this might be set to false if the agent is incapacitated, unconscious, etc. If the agent ''can'' think, it then checks to see if it is ''time'' to think. If so, the actual Think routine is started.

===Tasks===
The Think Cycle has a pair of tasks that it processes when it is time to be executed.
====Processing Histories====
First, it process the [[Behavior History|behavior histories]] that it is keeping. This discard any of them that are stale and need to be removed. This is important to do prior to behavior selection because many of the [[consideration]]s reference data in these histories.
====Selecting a Decision====
It then goes through the process of [[Select Decision|selecting a decision]]. In short, this involves rebuilding the [[Neighbor List|list of neighbors]] it might want to interact with, rebuilding the [[Decision List]]— a list of [[Decision]]s that are a combination of a [[Behavior]] and a [[Target]] (if necessary), scoring those decisions, and setting a new decision if we are changing what we are doing.

It then sets the new time that the next Think Cycle will be executed.

This entire decision selection process is covered fully in [[Select Decision]].

==Code==
The code for the think cycle is contained in the [[Brain#Code|Brain class]].

There relevant higher level functions are:
* Brain::WantsToThink
* Brain::Think
* Brain::SelectDecision

Brain

2021-10-07T13:47:47Z

Davemark: /* Brain Seed */

{{IAUS Header}}

== Concept ==
[[File:Diagram-Brain.png|400px|thumb|right|IAUS Structure]]
A '''Brain''' is the top level component that is assigned to an agent in the game. From a data standpoint, a Brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the Brain class contains most of the data for the agent's thinking and does most of the work of scoring [[behavior]]s and keeping track of the history of the behavior usage.

It is the Brain class that is ticked on a regular basis by the game code. However, the [[think cycle]] is controlled by the brain itself. That means that while the brain might be ticked every frame of game loop, the brain may only ''think'' perhaps every 250ms.

During this process, the Brain assembles a list of potential neighbors and combines them as necessary with behaviors to arrive at a combined list of [[decision]]s to be scored and selected from. It then proceeds to score all those Decisions to arrive at the one with the greatest utility at the time.

If a new [[Decision]] is selected, the related [[behavior type]] is executed. Additionally, data is adjusted in the brain to make note of what the brain is currently doing, the history of behaviors, etc.

== Implementation ==
=== Code ===
The code for the Brain is held in '''Brain.cpp''' in the class of the same name.

There will be one instance of the Brain object for each character that has a brain. This is because it holds the information about the current state and history of this character's "''thought process''".

==== Typedefs ====
For readability, there are many typedefs at the top of the Brain file. Most of these are lists, sparse data structures, or defined pairs. In the case of the pairs, they are most often used for passing around the key/value combinations of the sparse structures but are also used as the key itself.

<syntaxhighlight lang="C++>
//////////////////////////////////////////////////////////////////////////
// Convenience types
typedef std::unordered_map<unsigned int, BrainSeed*> BrainMap;
typedef std::pair<unsigned int, BrainSeed*> BrainPair;

typedef std::unordered_map<unsigned int, Behavior*> BehaviorMap;
typedef std::unordered_map<unsigned int, BehaviorAbilityPair*> AbilityMap;
typedef std::pair<unsigned int, Behavior*> BehaviorPair;

typedef std::list<Behavior*> BehaviorList;
typedef std::list<Decision> DecisionList;
typedef std::list<BehaviorAbilityPair*> AbilityList;

typedef std::list<BehaviorPackage*> BehaviorPackageList;
typedef std::unordered_map<unsigned int, BehaviorPackage*> BehaviorPackageMap;
typedef std::pair<unsigned int, BehaviorPackage*> BehaviorPackagePair;

typedef std::list<AbilityPackage*> AbilityPackageList;
typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityPackageMap;

typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityToAPMap;
typedef std::pair<unsigned int, AbilityPackage*> AbilityToAPPair;
typedef std::unordered_map<unsigned int, BehaviorPackage*> AbilityToBPMap;
typedef std::pair<unsigned int, BehaviorPackage*> AbilityToBPPair;

typedef std::pair<InputParameter, float> ParameterPair;

typedef std::unordered_map<unsigned int, float> BehaviorHistoryMap;
typedef std::pair<unsigned int, float> BehaviorHistoryIdAndTime;

typedef std::unordered_map<ContextEntry, float> ContextHistoryMap;
typedef std::pair<ContextEntry, float> ContextHistoryIdAndTime;

typedef std::unordered_map<BehaviorType, float> BehaviorTypeHistoryMap;
typedef std::pair<BehaviorType, float> BehaviorTypeIdAndTime;

//////////////////////////////////////////////////////////////////////////
// Entity for keeping track of relevant neighbors while making decisions
// so that they don't need to be reacquired by the engine

typedef AiEntityWP NeighborEntity;
typedef std::list<NeighborEntity> NeighborList;
</syntaxhighlight>

==== Static Members ====
However, there are a number of static members in Brain.cpp that hold all the original versions of brains, [[behavior]]s, [[ability|abilities]], [[behavior pack]]s and [[ability pack]]s, and [[Animation Mapping]]s. These are all held in sparse containers (unordered maps in C++ and dictionaries in C#). Additionally, for readability, these are all typedef'd at the top of the Brain file.

<syntaxhighlight lang="C++">
//////////////////////////////////////////////////////////////////////////
// Brain Data Initialization
// This is not part of individual brains -- only one copy of each is necessary

public:
static BrainMap Brains; // All brain definitions
static BehaviorMap Behaviors; // All behavior definitions
static AbilityMap Abilities; // All ability definitions
static BehaviorPackageMap BehaviorPackages; // All behavior package definitions
static AbilityPackageMap AbilityPackages; // All ability package definitions
static ObjectAnimationMappings ObjectAnimations; // All animation names for objects
</syntaxhighlight>

In the case of the package lists, the ones in the static objects may not match up with the one that is contained in an active Brain itself. This is because packages can be pushed on and off the brain dynamically through events in gameplay. Therefore, the static versions are indicative of what the brain is "born with".

==== Brain Seed ====
Additionally, this file holds the class '''BrainSeed''' which is a way of storing the information for raw brain data that comes from the database. There will be one BrainSeed object for each brain. It merely holds the name, description, a list of the [[behavior pack]]s and a list of the [[ability pack]]s that are associated with this brain. On load, it is unpacked into the [[#Static Members|static members]] of the Brain class.

=== Data ===
From a data standpoint, other than a unique ID, name, and a description, a Brain is simply a collection of Behavior Packs and Ability Packs.

=== Export ===
Exporting a Brain is merely exporting the Brain's ID and the Behavior Packs and Ability Packs it contains. These end up creating [[#Brain Seed|Brain Seed]]s.
{{Manual Footer}}

Brain

2021-10-07T13:47:10Z

Davemark: /* Static Members */

{{IAUS Header}}

== Concept ==
[[File:Diagram-Brain.png|400px|thumb|right|IAUS Structure]]
A '''Brain''' is the top level component that is assigned to an agent in the game. From a data standpoint, a Brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the Brain class contains most of the data for the agent's thinking and does most of the work of scoring [[behavior]]s and keeping track of the history of the behavior usage.

It is the Brain class that is ticked on a regular basis by the game code. However, the [[think cycle]] is controlled by the brain itself. That means that while the brain might be ticked every frame of game loop, the brain may only ''think'' perhaps every 250ms.

During this process, the Brain assembles a list of potential neighbors and combines them as necessary with behaviors to arrive at a combined list of [[decision]]s to be scored and selected from. It then proceeds to score all those Decisions to arrive at the one with the greatest utility at the time.

If a new [[Decision]] is selected, the related [[behavior type]] is executed. Additionally, data is adjusted in the brain to make note of what the brain is currently doing, the history of behaviors, etc.

== Implementation ==
=== Code ===
The code for the Brain is held in '''Brain.cpp''' in the class of the same name.

There will be one instance of the Brain object for each character that has a brain. This is because it holds the information about the current state and history of this character's "''thought process''".

==== Typedefs ====
For readability, there are many typedefs at the top of the Brain file. Most of these are lists, sparse data structures, or defined pairs. In the case of the pairs, they are most often used for passing around the key/value combinations of the sparse structures but are also used as the key itself.

<syntaxhighlight lang="C++>
//////////////////////////////////////////////////////////////////////////
// Convenience types
typedef std::unordered_map<unsigned int, BrainSeed*> BrainMap;
typedef std::pair<unsigned int, BrainSeed*> BrainPair;

typedef std::unordered_map<unsigned int, Behavior*> BehaviorMap;
typedef std::unordered_map<unsigned int, BehaviorAbilityPair*> AbilityMap;
typedef std::pair<unsigned int, Behavior*> BehaviorPair;

typedef std::list<Behavior*> BehaviorList;
typedef std::list<Decision> DecisionList;
typedef std::list<BehaviorAbilityPair*> AbilityList;

typedef std::list<BehaviorPackage*> BehaviorPackageList;
typedef std::unordered_map<unsigned int, BehaviorPackage*> BehaviorPackageMap;
typedef std::pair<unsigned int, BehaviorPackage*> BehaviorPackagePair;

typedef std::list<AbilityPackage*> AbilityPackageList;
typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityPackageMap;

typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityToAPMap;
typedef std::pair<unsigned int, AbilityPackage*> AbilityToAPPair;
typedef std::unordered_map<unsigned int, BehaviorPackage*> AbilityToBPMap;
typedef std::pair<unsigned int, BehaviorPackage*> AbilityToBPPair;

typedef std::pair<InputParameter, float> ParameterPair;

typedef std::unordered_map<unsigned int, float> BehaviorHistoryMap;
typedef std::pair<unsigned int, float> BehaviorHistoryIdAndTime;

typedef std::unordered_map<ContextEntry, float> ContextHistoryMap;
typedef std::pair<ContextEntry, float> ContextHistoryIdAndTime;

typedef std::unordered_map<BehaviorType, float> BehaviorTypeHistoryMap;
typedef std::pair<BehaviorType, float> BehaviorTypeIdAndTime;

//////////////////////////////////////////////////////////////////////////
// Entity for keeping track of relevant neighbors while making decisions
// so that they don't need to be reacquired by the engine

typedef AiEntityWP NeighborEntity;
typedef std::list<NeighborEntity> NeighborList;
</syntaxhighlight>

==== Static Members ====
However, there are a number of static members in Brain.cpp that hold all the original versions of brains, [[behavior]]s, [[ability|abilities]], [[behavior pack]]s and [[ability pack]]s, and [[Animation Mapping]]s. These are all held in sparse containers (unordered maps in C++ and dictionaries in C#). Additionally, for readability, these are all typedef'd at the top of the Brain file.

<syntaxhighlight lang="C++">
//////////////////////////////////////////////////////////////////////////
// Brain Data Initialization
// This is not part of individual brains -- only one copy of each is necessary

public:
static BrainMap Brains; // All brain definitions
static BehaviorMap Behaviors; // All behavior definitions
static AbilityMap Abilities; // All ability definitions
static BehaviorPackageMap BehaviorPackages; // All behavior package definitions
static AbilityPackageMap AbilityPackages; // All ability package definitions
static ObjectAnimationMappings ObjectAnimations; // All animation names for objects
</syntaxhighlight>

In the case of the package lists, the ones in the static objects may not match up with the one that is contained in an active Brain itself. This is because packages can be pushed on and off the brain dynamically through events in gameplay. Therefore, the static versions are indicative of what the brain is "born with".

==== Brain Seed ====
Additionally, this file holds the class '''BrainSeed''' which is a way of storing the information for raw brain data that comes from the database. There will be one BrainSeed object for each brain. It merely holds the name, description, a list of the [[Behavior Pack]]s and a list of the [[Ability Pack]]s that are associated with this brain. On load, it is unpacked into the [[#Static Members|static members]] of the Brain class.

=== Data ===
From a data standpoint, other than a unique ID, name, and a description, a Brain is simply a collection of Behavior Packs and Ability Packs.

=== Export ===
Exporting a Brain is merely exporting the Brain's ID and the Behavior Packs and Ability Packs it contains. These end up creating [[#Brain Seed|Brain Seed]]s.
{{Manual Footer}}

Ability pack

2021-10-07T13:45:49Z

Davemark: Davemark moved page Ability Pack to Ability pack without leaving a redirect: Capitalization

Behavior pack

2021-10-07T13:45:31Z

Davemark: Davemark moved page Behavior Pack to Behavior pack without leaving a redirect: Capitalization

Brain

2021-10-07T13:45:14Z

Davemark: /* Concept */

{{IAUS Header}}

== Concept ==
[[File:Diagram-Brain.png|400px|thumb|right|IAUS Structure]]
A '''Brain''' is the top level component that is assigned to an agent in the game. From a data standpoint, a Brain is simply a collection of [[behavior pack]]s and [[ability pack]]s. However, the Brain class contains most of the data for the agent's thinking and does most of the work of scoring [[behavior]]s and keeping track of the history of the behavior usage.

It is the Brain class that is ticked on a regular basis by the game code. However, the [[think cycle]] is controlled by the brain itself. That means that while the brain might be ticked every frame of game loop, the brain may only ''think'' perhaps every 250ms.

During this process, the Brain assembles a list of potential neighbors and combines them as necessary with behaviors to arrive at a combined list of [[decision]]s to be scored and selected from. It then proceeds to score all those Decisions to arrive at the one with the greatest utility at the time.

If a new [[Decision]] is selected, the related [[behavior type]] is executed. Additionally, data is adjusted in the brain to make note of what the brain is currently doing, the history of behaviors, etc.

== Implementation ==
=== Code ===
The code for the Brain is held in '''Brain.cpp''' in the class of the same name.

There will be one instance of the Brain object for each character that has a brain. This is because it holds the information about the current state and history of this character's "''thought process''".

==== Typedefs ====
For readability, there are many typedefs at the top of the Brain file. Most of these are lists, sparse data structures, or defined pairs. In the case of the pairs, they are most often used for passing around the key/value combinations of the sparse structures but are also used as the key itself.

<syntaxhighlight lang="C++>
//////////////////////////////////////////////////////////////////////////
// Convenience types
typedef std::unordered_map<unsigned int, BrainSeed*> BrainMap;
typedef std::pair<unsigned int, BrainSeed*> BrainPair;

typedef std::unordered_map<unsigned int, Behavior*> BehaviorMap;
typedef std::unordered_map<unsigned int, BehaviorAbilityPair*> AbilityMap;
typedef std::pair<unsigned int, Behavior*> BehaviorPair;

typedef std::list<Behavior*> BehaviorList;
typedef std::list<Decision> DecisionList;
typedef std::list<BehaviorAbilityPair*> AbilityList;

typedef std::list<BehaviorPackage*> BehaviorPackageList;
typedef std::unordered_map<unsigned int, BehaviorPackage*> BehaviorPackageMap;
typedef std::pair<unsigned int, BehaviorPackage*> BehaviorPackagePair;

typedef std::list<AbilityPackage*> AbilityPackageList;
typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityPackageMap;

typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityToAPMap;
typedef std::pair<unsigned int, AbilityPackage*> AbilityToAPPair;
typedef std::unordered_map<unsigned int, BehaviorPackage*> AbilityToBPMap;
typedef std::pair<unsigned int, BehaviorPackage*> AbilityToBPPair;

typedef std::pair<InputParameter, float> ParameterPair;

typedef std::unordered_map<unsigned int, float> BehaviorHistoryMap;
typedef std::pair<unsigned int, float> BehaviorHistoryIdAndTime;

typedef std::unordered_map<ContextEntry, float> ContextHistoryMap;
typedef std::pair<ContextEntry, float> ContextHistoryIdAndTime;

typedef std::unordered_map<BehaviorType, float> BehaviorTypeHistoryMap;
typedef std::pair<BehaviorType, float> BehaviorTypeIdAndTime;

//////////////////////////////////////////////////////////////////////////
// Entity for keeping track of relevant neighbors while making decisions
// so that they don't need to be reacquired by the engine

typedef AiEntityWP NeighborEntity;
typedef std::list<NeighborEntity> NeighborList;
</syntaxhighlight>

==== Static Members ====
However, there are a number of static members in Brain.cpp that hold all the original versions of Brains, [[Behavior]]s, [[Ability|Abilities]], [[Behavior Pack]]s and [[Ability Pack]]s, and [[Animation Mapping]]s. These are all held in sparse containers (unordered maps in C++ and dictionaries in C#). Additionally, for readability, these are all typedef'd at the top of the Brain file.

<syntaxhighlight lang="C++">
//////////////////////////////////////////////////////////////////////////
// Brain Data Initialization
// This is not part of individual brains -- only one copy of each is necessary

public:
static BrainMap Brains; // All brain definitions
static BehaviorMap Behaviors; // All behavior definitions
static AbilityMap Abilities; // All ability definitions
static BehaviorPackageMap BehaviorPackages; // All behavior package definitions
static AbilityPackageMap AbilityPackages; // All ability package definitions
static ObjectAnimationMappings ObjectAnimations; // All animation names for objects
</syntaxhighlight>

In the case of the package lists, the ones in the static objects may not match up with the one that is contained in an active Brain itself. This is because packages can be pushed on and off the brain dynamically through events in gameplay. Therefore, the static versions are indicative of what the brain is "born with".

==== Brain Seed ====
Additionally, this file holds the class '''BrainSeed''' which is a way of storing the information for raw brain data that comes from the database. There will be one BrainSeed object for each brain. It merely holds the name, description, a list of the [[Behavior Pack]]s and a list of the [[Ability Pack]]s that are associated with this brain. On load, it is unpacked into the [[#Static Members|static members]] of the Brain class.

=== Data ===
From a data standpoint, other than a unique ID, name, and a description, a Brain is simply a collection of Behavior Packs and Ability Packs.

=== Export ===
Exporting a Brain is merely exporting the Brain's ID and the Behavior Packs and Ability Packs it contains. These end up creating [[#Brain Seed|Brain Seed]]s.
{{Manual Footer}}

Brain

2021-10-07T13:43:55Z

Davemark: /* Concept */

{{IAUS Header}}

== Concept ==
[[File:Diagram-Brain.png|400px|thumb|right|IAUS Structure]]
A '''Brain''' is the top level component that is assigned to an agent in the game. From a data standpoint, a Brain is simply a collection of [[Behavior Pack]]s and [[Ability Pack]]s. However, the Brain class contains most of the data for the agent's thinking and does most of the work of scoring [[Behavior]]s and keeping track of the history of the Behavior usage.

It is the Brain class that is ticked on a regular basis by the game code. However, the [[Think Cycle]] is controlled by the brain itself. That means that while the Brain might be ticked every frame of game loop, the Brain may only think perhaps every 250ms.

During this process, the Brain assembles a list of potential neighbors and combines them as necessary with Behaviors to arrive at a combined list of [[Decision]]s to be scored and selected from. It then proceeds to score all those Decisions to arrive at the one with the greatest utility at the time.

If a new [[Decision]] is selected, the related [[Behavior Type]] is executed. Additionally, data is adjusted in the Brain to make note of what the Brain is currently doing, the history of behaviors, etc.

== Implementation ==
=== Code ===
The code for the Brain is held in '''Brain.cpp''' in the class of the same name.

There will be one instance of the Brain object for each character that has a brain. This is because it holds the information about the current state and history of this character's "''thought process''".

==== Typedefs ====
For readability, there are many typedefs at the top of the Brain file. Most of these are lists, sparse data structures, or defined pairs. In the case of the pairs, they are most often used for passing around the key/value combinations of the sparse structures but are also used as the key itself.

<syntaxhighlight lang="C++>
//////////////////////////////////////////////////////////////////////////
// Convenience types
typedef std::unordered_map<unsigned int, BrainSeed*> BrainMap;
typedef std::pair<unsigned int, BrainSeed*> BrainPair;

typedef std::unordered_map<unsigned int, Behavior*> BehaviorMap;
typedef std::unordered_map<unsigned int, BehaviorAbilityPair*> AbilityMap;
typedef std::pair<unsigned int, Behavior*> BehaviorPair;

typedef std::list<Behavior*> BehaviorList;
typedef std::list<Decision> DecisionList;
typedef std::list<BehaviorAbilityPair*> AbilityList;

typedef std::list<BehaviorPackage*> BehaviorPackageList;
typedef std::unordered_map<unsigned int, BehaviorPackage*> BehaviorPackageMap;
typedef std::pair<unsigned int, BehaviorPackage*> BehaviorPackagePair;

typedef std::list<AbilityPackage*> AbilityPackageList;
typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityPackageMap;

typedef std::unordered_map<unsigned int, AbilityPackage*> AbilityToAPMap;
typedef std::pair<unsigned int, AbilityPackage*> AbilityToAPPair;
typedef std::unordered_map<unsigned int, BehaviorPackage*> AbilityToBPMap;
typedef std::pair<unsigned int, BehaviorPackage*> AbilityToBPPair;

typedef std::pair<InputParameter, float> ParameterPair;

typedef std::unordered_map<unsigned int, float> BehaviorHistoryMap;
typedef std::pair<unsigned int, float> BehaviorHistoryIdAndTime;

typedef std::unordered_map<ContextEntry, float> ContextHistoryMap;
typedef std::pair<ContextEntry, float> ContextHistoryIdAndTime;

typedef std::unordered_map<BehaviorType, float> BehaviorTypeHistoryMap;
typedef std::pair<BehaviorType, float> BehaviorTypeIdAndTime;

//////////////////////////////////////////////////////////////////////////
// Entity for keeping track of relevant neighbors while making decisions
// so that they don't need to be reacquired by the engine

typedef AiEntityWP NeighborEntity;
typedef std::list<NeighborEntity> NeighborList;
</syntaxhighlight>

==== Static Members ====
However, there are a number of static members in Brain.cpp that hold all the original versions of Brains, [[Behavior]]s, [[Ability|Abilities]], [[Behavior Pack]]s and [[Ability Pack]]s, and [[Animation Mapping]]s. These are all held in sparse containers (unordered maps in C++ and dictionaries in C#). Additionally, for readability, these are all typedef'd at the top of the Brain file.

<syntaxhighlight lang="C++">
//////////////////////////////////////////////////////////////////////////
// Brain Data Initialization
// This is not part of individual brains -- only one copy of each is necessary

public:
static BrainMap Brains; // All brain definitions
static BehaviorMap Behaviors; // All behavior definitions
static AbilityMap Abilities; // All ability definitions
static BehaviorPackageMap BehaviorPackages; // All behavior package definitions
static AbilityPackageMap AbilityPackages; // All ability package definitions
static ObjectAnimationMappings ObjectAnimations; // All animation names for objects
</syntaxhighlight>

In the case of the package lists, the ones in the static objects may not match up with the one that is contained in an active Brain itself. This is because packages can be pushed on and off the brain dynamically through events in gameplay. Therefore, the static versions are indicative of what the brain is "born with".

==== Brain Seed ====
Additionally, this file holds the class '''BrainSeed''' which is a way of storing the information for raw brain data that comes from the database. There will be one BrainSeed object for each brain. It merely holds the name, description, a list of the [[Behavior Pack]]s and a list of the [[Ability Pack]]s that are associated with this brain. On load, it is unpacked into the [[#Static Members|static members]] of the Brain class.

=== Data ===
From a data standpoint, other than a unique ID, name, and a description, a Brain is simply a collection of Behavior Packs and Ability Packs.

=== Export ===
Exporting a Brain is merely exporting the Brain's ID and the Behavior Packs and Ability Packs it contains. These end up creating [[#Brain Seed|Brain Seed]]s.
{{Manual Footer}}

AI entity

2021-10-07T13:43:27Z

Davemark: /* Data */

{{IAUS Header}}
== Concept ==
An '''AI Entity''' is a class designed to hold information that might be relevant 2 game characters. Any character that would have a [[Brain]] would also have an AI Entity. Also any object in the world that thinking characters would need to acquire information on and reason about would also need one as well.

One important component of and AI Entity is that they hold the [[Entity tag|information tags]] as part of the [[Tag System|tagging system]] that the AI uses to gather information about potential targets. Additionally, AI Entities contain the [[world object type]] of the item or character that it is attached to. That way, agents can know and be able to filter queries about world objects by what they are (through Object Types) or information about them - either permanent or temporary (through Tags).

== Code ==
All of the information about an AI Entity is contained in the AiEntity class.

== Data ==
There is no direct data involved with an AI Entity. However, they use values that are defined in the database such as [[world object type]], [[entity tag]], and [[team]].

AI entity

2021-10-07T13:42:57Z

Davemark: /* Concept */

AI entity

2021-10-07T13:42:32Z

Davemark: /* Concept */

{{IAUS Header}}
== Concept ==
An '''AI Entity''' is a class designed to hold information that might be relevant 2 game characters. Any character that would have a [[Brain]] would also have an AI Entity. Also any object in the world that thinking characters would need to acquire information on and reason about would also need one as well.

One important component of and AI Entity is that they hold the [[Entity tag|information tags]] as part of the [[Tag System|tagging system]] that the AI uses to gather information about potential targets. Additionally, AI Entities contain the [[World Object Type]] of the item or character that it is attached to. That way, agents can know and be able to filter queries about world objects by what they are (through Object Types) or information about them - either permanent or temporary (through Tags).

== Code ==
All of the information about an AI Entity is contained in the AiEntity class.

== Data ==
There is no direct data involved with an AI Entity. However, they use values that are defined in the database such as [[World Object Type]], [[Entity Tag]], and [[Team]].

AI entity

2021-10-07T13:42:16Z

Davemark: /* Concept */

{{IAUS Header}}
== Concept ==
An '''AI Entity''' is a class designed to hold information that might be relevant 2 game characters. Any character that would have a [[Brain]] would also have an AI Entity. Also any object in the world that thinking characters would need to acquire information on and reason about would also need one as well.

One important component of and AI Entity is that they hold the [[Entity Tag|information tags]] as part of the [[Tag System|tagging system]] that the AI uses to gather information about potential targets. Additionally, AI Entities contain the [[World Object Type]] of the item or character that it is attached to. That way, agents can know and be able to filter queries about world objects by what they are (through Object Types) or information about them - either permanent or temporary (through Tags).

== Code ==
All of the information about an AI Entity is contained in the AiEntity class.

== Data ==
There is no direct data involved with an AI Entity. However, they use values that are defined in the database such as [[World Object Type]], [[Entity Tag]], and [[Team]].

AI entity

2021-10-07T13:41:44Z

Davemark: Davemark moved page AI Entity to AI entity without leaving a redirect: Capitalization

{{IAUS Header}}
== Concept ==
An AI Entity is a class designed to hold information that might be relevant 2 game characters. Any character that would have a [[Brain]] would also have an AI Entity. Also any object in the world that thinking characters would need to acquire information on and reason about would also need one as well.

One important component of and AI Entity is that they hold the [[Entity Tag|information tags]] as part of the [[Tag System|tagging system]] that the AI uses to gather information about potential targets. Additionally, AI Entities contain the [[World Object Type]] of the item or character that it is attached to. That way, agents can know and be able to filter queries about world objects by what they are (through Object Types) or information about them - either permanent or temporary (through Tags).

== Code ==
All of the information about an AI Entity is contained in the AiEntity class.

== Data ==
There is no direct data involved with an AI Entity. However, they use values that are defined in the database such as [[World Object Type]], [[Entity Tag]], and [[Team]].

Template:IAUS Header

2021-10-07T13:41:25Z

Davemark: capitalization

'''This page is part of the [[IAUS|IAUS Manual]].'''
♦ [[Brain]] ♦ [[Behavior]] ♦ [[Behavior type|Behavior Type]] ♦ [[Decision]] ♦ [[AI entity|AI Entity]] ♦

Behavior type

2021-10-07T13:39:27Z

Davemark: Davemark moved page Behavior Type to Behavior type without leaving a redirect: Capitalization

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
[[File:Diagram - Behavior Type.png|400px|thumb|right|Behavior Type as part of the IAUS structure]]

'''Behavior Types''' are the core actions that an agent can perform.

One way of thinking of Behavior Types is as "button presses". That is, there is often an analog to what the player would do in order to execute an action. Note that this is different from a [[Behavior]] which is merely a data construct that helps the agent calculate the utility of the potential action and decide ''why'' to do it. The Behavior Type expresses ''what'' the action entails.

== Examples ==
Examples of Behavior Types are:
* "Move to Target"
* "Face Target"
* "Play Animation".

Actions that would fall under the "Ability" Behavior Type could be:
* "melee attack"
* "ranged attack"
* "special attack"
* "Orc Mage Fireball"

Again, these would all be specified as "Ability" for their Behavior Type with the matchup to the appropriate action handled elsewhere.

== Implementation ==
=== Code ===
In code, each Behavior Type is given it's own class that is inherited from the [[Behavior class]]. The mappings between the enum and the appropriate class are done in the [[Behavior Data]] class. Therefore, if a new Behavior Type is created in the data tool, the sub-class needs to be written (in Behavior.cpp) and there needs to be a matchup specified in BehaviorData.cpp as well.

Note that there will often be a Behavior Type called "Ability". This is intentionally generic as it is handled in a different way by a different class.

=== Data ===
Behavior Types are specified in the data tool as simply a list that gets exported to the [[Enums]] file.

{{Manual Footer}}

Input Parameters

2021-10-07T13:38:37Z

Davemark: /* Boolean Parameters */

{{IAUS Header}}
{{Part of Behavior}}
== Concept ==
'''Input Parameters''' are items that are specified in individual [[consideration]]s that include more data for them to use when calculating the consideration. The types of input parameters that are available (and useful) depend on the type of input that is selected for the consideration.
=== Value Parameters ===
Some input parameters allow you to set minimum or maximum values that help determine what the normalized x-axis of 0..1 is meant to represent. For example, when calculating the distance to a target, we may only be concerned with ranges under 20m. In that case, by setting the "RangeMax" parameter to 20, the [[Response Curve]] is automatically scaled so that the distance of 20m is equal to ''x = 1.0''.

=== Boolean Parameters ===
Some input parameters are checking to see if something exists in a Boolean fashion. Because the nature of this type of consideration will only be a "true/false" solution, the response curve for these is usually set to either have [0,0] and [1,1] (for true = 1) or [0,1] and [1,0] (for false = 1).

An example is the input, "HasTag". This input is merely checking to see if the owner has a specified [[entity tag]]. The tag is placed in the input parameters on the consideration—for example "Invisible". Therefore, the consideration would be checking to see if the owner has the tag, "invisible". If so, the input returns "1" and, depending on the orientation of the response curve, the consideration can return 1 or 0.

== Implementation ==
=== Code ===
Input Parameters for a consideration are held in a sparse map structure. This is typedef'd in [[Consideration#Code|Consideration.h]] as:
<SyntaxHighlight>
typedef std::unordered_map<InputParameter, float> ParameterMap;
</syntaxhighlight>
This is then declared as a member of the Consideration object as:
<SyntaxHighlight>
ParameterMap parameters; // optional parameters for filtering, adding normalization bookends, etc.
</syntaxhighlight>

The processing of input parameters is done in [[Consideration#Code|Consideration.cpp]] by helper functions. For example, the following block is asking if there is a ''RangeMax'' parameter in the consideration.
<SyntaxHighlight>
float paramMax = GetParameterOrDefault(InputParameter::RangeMax, -1.0f);
</syntaxhighlight>
This accesses the parameter map on the consideration to see if it exists. Otherwise, it returns the default that was passed in.
<SyntaxHighlight>
float Consideration::GetParameterOrDefault(InputParameter thisParam, float thisDefault) const
{
ParameterMap::const_iterator result = parameters.find(thisParam);
if (result == parameters.end()) {
return thisDefault;
}
else {
return result->second;
}
}
</syntaxhighlight>

More information on how these are used in the calculation of the consideration can be found in [[Consideration#Code|Consideration.cpp]].
=== Data ===

{{Manual Footer}}

Entity tag

2021-10-07T13:37:20Z

Davemark: Davemark moved page Entity Tag to Entity tag without leaving a redirect: Capitalization

{{IAUS Header}}

==Concept==
Tags are a way of keeping information about an agent or object. They can be assigned to an object based on its [[world object type]] (i.e. properties that they are “born with”) or they can be added to and removed from an object dynamically in the game. They are largely considered Boolean -- either you have a tag of a particular type or you do not. In a way, they would act in a similar fashion to having maybe Boolean variables on the object, one representing each potential property. However, these are stored in a sparse manner using an unordered map (C++) or dictionary (C#) so that they can be added to and removed as necessary without having hundreds or thousands of placeholder Booleans on an object that may never have that particular property set to true.

The other advantage is that tags are added via the data tool as necessary by designers. Once that happens and the tag data is exported, they can be used on any object and by any behavior without code changes. Because tags are often used for specific scenarios or as part of specific suites of behaviors or level design, this allows enormous flexibility and extensibility from the data side only.

== Code ==
Individual Tags that can be used are listed in the enum EntityTag in the [[enums]] file. They are exported here from the [[Data Tool]].

An [[AI Entity]] contains the currently active tags for that object in an [[EntityTagSet]]. This is where the information about that entity is stored.

== Data ==
Tags are created and stored in the AI database via the [[Data Tool]]. While there, they are available to be assigned to [[World Object Type]]s (via [[Tag Set]]s) and be accessed by [[Behavior]]s that are either checking for them, or adding/removing them as a result of the behavior execution.