The following are technologies that we have developed at Intrinsic Algorithm and use in our work in our own projects and for our contract customers. They have been used at a variety of companies -- from AAA to indie -- with great success.

Infinite Axis Utility System (IAUS)

Dave Mark is well known in AI circles, particularly at the GDC AI Summit, as being a proponent of 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 5 years, he has continued to improve this method and deployed it to great success in his contract work with a variety of companies. The Infinite Access Utility System was spoken about briefly at the GDC AI Summit in 2013 as his part of a multi-person talk entitled, Architecture Tricks: Managing Behaviors in Time, Space, and Depth. (You can skip to 33:35 for the beginning of my segment.)

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. (See Building a Better Centaur: AI at Massive Scale) This 1 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 7 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 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, "Spatial Knowledge Representation through Modular Scalable Influence Maps". (Note this may be behind a paywall and is only available to people who attended GDC on a full access pass or have purchased and individual or company GDCVault pass.) The following video contains the demonstration examples used with explanations of what is happening.

Robust Tagging System

To support the above technologies -- and for other things -- we have developed a robust tagging system. This allows designers to tag objects and NPCs to provide very useful contextual information that the AI can understand. For example, tagging a campfire as FIRE, HEAT_SOURCE, LIGHT_SOURCE, SOCIAL_AREA may affect how NPCs view it. They may move toward it at night because they know it is providing light or they may move toward it when they are bored and want to chat with other NPCs. It can also be used to trigger specific animations such as holding out hands to warm them. This would only be done when close to an item tagged HEAT_SOURCE and only when facing it. The benefit of this is that simply adding the HEAT_SOURCE tag to another object (such as a fireplace or a stove) would cause the NPCs with that behavior to automatically use that object in the same fashion.

Invisible objects can be placed and tagged as well. For example, dropping waypoints marked PATROL_POINT (at crossroads, walls of a fort, etc.) or VILLAGER_POI (at market stalls, etc.) could then be used to inform a guard or villager respectively where they could wander of their own accord. By simply dropping another point with that tag (or tagging an existing one) the NPC would automatically incorporate it into it's behavior -- no further designer intervention necessary.

Tags can also be passed between NPCs. For example, a leader could point at a target and yell to its subordinates and that behavior may add a LEADER_TARGET tag to the object. If the subordinates have a behavior that prioritieses attacking something with that tag, it would seem like the leader is directing traffic. (For more fun, have the leader place LOOK_AT_ME on itself as it barks the order to get the followers to look at him first and then the target that is pointed out.)

We can also use the tags as part of a dialog system where it helps dictate whose turn it is to speak and what sort of information was just passed. That way the dialog behavior selection can act accordingly ("it's my turn to speak!") and chose an appropriate response to what was said by the person who passed it the tag. The same can be done for other couple or group interactive behaviors. One interesting result is that a group in a conversation or social activity can all look at the one who is speaking or acting by simply adding a tag to a look at behavior.

The tagging system is data-driven as well so that designers can add, change, or remove tags from the system at will. This way, it is also easy to add tags to the decisions crafted by the IAUS -- either for checking for the existance of a tag (e.g. "only if I'm invisible") or applying or removing a tag from a target (e.g. "place LEADER_TARGET on that NPC"). Because these systems are designed to work together and are so powerful, it is recommended that the tagging system simply be included with the IAUS. Thankfully, this is a minor effort.

Text Dialog System

For text based games that do not want repetative 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. For example "Greetings, {0}." can have parameter 0 specified to fill in the other character's name, their race, their class, etc. Each of those would be specified by the designer in the tool. By having different phrases with different parameters to be filled in, a huge amount of variety can appear on the screen rather than the same phrases over and over.

Filters can be applied for situational use. Greetings, combat barks, needing assistance, biographic information, and even game-specific information can all be triggered and then one of the possibly many selections will be used. For example, a character who is being attacked may say any of:

• Help!
• I could use a hand here.
• Aaah!
• Get them off me!

Additionally, these statements can then be filtered by demographics such as race, class, occupation, level, etc. This works not only to select lines based on who is speaking, but can also be applied to who the intended listener is. For example, a woodland elf or a druid or a ranger might say to another elf, druid, or ranger, "Protect the forest [race/class]". However, if speaking to a dwarf, for example, they may say "Do not defile the forest, dwarf!" Moreso, there may be a number of phrase structures available for this exact same speaker/listener combination. Some may be completely different (e.g. "you aren't welcome in the woods." to the dwarf) or they may just be slightly different in phrasing (e.g. "Mountain-dweller... do not defile our forest.").

Another advantage of the filtering system is that different races can have different speach patterns. (Think Yoda, you will.) By simply creating phrases for a different race, they will "sound" completely different when encountered.