Game Concept – Resource Management AI & Behavior Trees

Introduction:

This is an overview of the concept for the second game I develop as part of the Games and AI module which includes a discussion of behavior trees and resource management AI which I plan to use as blueprints for the development of two distinct player opponent system in Unity 2019.3.

Class PresentationDownload

Game Concept:

The concept of the game is a top-down shooter where each stage is represented through a building which the player navigates through to locate a keycard and use it to open the exit, located at a fixed position, and escape which completes the level. The keycard spawns randomly between multiple predefined locations each playthrough. The player can encounter two different archetypes of opponents, a scout and a grunt (mobility vs resilience), which are designed to coordinate their moves in teams of various sizes in an attempt to eliminate the player. The enemies are spawned and instructed by a director AI which uses limited resources in a given time frame to influence the game using data collected from each enemy encounter.

AI Concept:

The director AI has limited pool of resources per level for the duration of a specific time interval which it uses to spawn new agents and issue instructions to existing ones in real-time. It’s ultimate goal is to use its resources as efficiently as possible in an effort to construct optimal strategies of eliminating the player character based on its collected data.

Each agent has a different behavior tree designed around one of two identified enemy archetypes. It’s goal may change dynamically based on the outcome of its encounters with the player. When wounded a grunt would attempt to find and take cover if any is available nearby, while a scout would attempt to retreat to a set distance from where it encountered the player and inform multiple nearby agents of the player’s last known location. This facilitates a framework for setting up particular strategies to be evaluated and set in motion by the director AI which if balanced appropriately towards a certain difficulty can present unique challenges for players of different skill levels.

Resource Management AI:

The resource management AI would collect data from each agent encounter with the player which will allow it to store the player’s last known position, the success rate of combat with each agent based on the number of shots hit and received during the encounter and the distance between an agent and the player during the encounter.

The resource management AI would be restricted to spawning enemies only outside of the player view with a specific cooldown on each enemy archetype spawned to balance the game in favor of the player.

The resource management AI would be able to issue instructions to agents in specific circumstances where it cannot spawn agents or has identified a higher success chance following a different strategy. These instructions can range from updating the agent’s last known player location in an attempt to encourage a combat encounter or flank the player, instructing it to coordinate an attack with other agents or retreating prematurely to utilize a combat encounter in a location with a higher success chance.

Behavior Tree:

The behavior trees would be implemented with two distinct archetypes in mind, a scout and a grunt, designed around complementing each other’s strengths and weaknesses and improving their odds of success when used appropriately by the resource management AI.

The behavior tree will follow a sequence-based design approach where multiple actions are undertaken when a criteria is met for a specific sequence.

The Scout:

The scout archetype would be designed to gather continuous data for the resource management AI and assist other nearby agents in combat by being implemented with movement speed matching the player’s but lacking in health points and the damage dealing. An agent with this behavior tree starts out by actively patrolling an area by travelling between four waypoints assigned by the resource management AI and experience transitions in behavior when encountering the player at different distances or being instructed by the resource management AI based on specific circumstances.

The grunt:

The grunt archetype would be designed primarily for combat encounters as it’s characteristics improve the odds of eliminating the player when used effectively with a scout. The grunt features a health pool matching the player’s and is able to deal more damage per second but is lacking in movement speed and can easily be kited by the player which leaves it vulnerable on its own in combat. An agent with this behavior tree starts out stationary, guarding a specific area in a radius of its location and experiences transitions in behavior when the player is within this radius, it has direct line of sight of the player or when it is instructed by the resource management AI or a nearby scout agent.

Credits:

References:

Final Zombie Game

Introduction:

The outcome of this project is a basic third-person zombie game which is extended past the provided tutorial material to feature a stats system for the player and agents and an enhanced FSM model designed for multiple variants of agents represented through different models and animations obtained from Adobe Mixamo’s platform. The waypoint navigation behavior for wandering agents has been updated to compute and target the closest available waypoint position when close enough to the current target instead of following a linear progression of the waypoint game objects array.

YouTube Link

GitHub Repository

Finite-State Machine:

The AI model adapted to this project is based on the concept of a finite-state machine. This is a mathematical model of computation which is defined by a list of predefined states, its initial state and the variables that trigger each transition to a different state. This model is not restricted to the field of AI but can also be found in objects we encounter and interact with on a regular basis and even be used to model common patterns within our own behavior.

Turnstile Finite-State Machine Logic (https://en.wikipedia.org/wiki/Finite-state_machine)
Common routine example (https://medium.com/@brianray_7981/tutorial-write-a-finite-state-machine-to-parse-a-custom-language-in-pure-python-1c11ade9bd43)

The memory of a finite-state machine is limited by the number of states it has which indicates that other models, like the Turing machine, have more computational power. The finite-state model is used to represent and control execution flow which is suitable for implementing AI logic in games without using too many resources and complex code while allowing agents to exhibit smart behavior through dynamic transitions at runtime based on changing circumstances within the virtual space they inhabit. Finite-state machines can be designed around two types of behavior, deterministic and non-deterministic. A deterministic finite-state machine can be constructed equivalent to any non-deterministic one.

Implementation:

The FSM model describing the AI logic in the project is defined by 6 states, “Wandering”, “Chasing”, “Searching”, “Attacking”, “Retreating” and “Dead”. The logic for each state is implemented through Unity coroutines. Each coroutine is managed in the update method through a bool which is checked to determine if the coroutine associated with the current state is started or not and a WaitForSeconds variable available through the Unity CoreModule API which is used to specify the refresh rate of every coroutine’s logic block. This alleviates challenges with correctly starting, stopping and timing the execution of each individual coroutine for every transition which the AI logic can flow through. Coroutines accept custom view angles during startup which are used to balance and control the behavior within each state in accordance to tracking a dynamic target, which in this project is only the player character. During certain states, when an agent successfully sees the player, it will alert nearby agents of its presence at which point they will switch to the “Chasing” state and immediately transition to the “Searching” state if they do not have sight of the player. This method reinforces basic crowd AI behavior by providing the means of multiple agents to cooperate in an attempt to reach the same goal.

Implemented Finite-State Machine Model
Wandering State:

The initial state which every agent begins set to is “Wandering”. In start of this state the agent computes the distance to every available waypoint which has not been reached and targets the nearest one based on its current position. When a waypoint is targeted, the agent will traverse the created environment using the generated navigation surface for it until it is within a specific distance of its target. Upon meeting the criteria for the distance to its target, it will determine the next nearest waypoint using the same method and continue to do this until every waypoint has been reached, then it will reset the visited status of the waypoints and start over. During this state, the agent is set a custom viewing angle which is used to determine if the player is within its view. When this criteria is met, a raycast technique is used to determine if the view is obstructed by any geometry based on a custom variable used to indicate visibility distance of the agent. If the conditions for successfully seeing the player are satisfied, one last check is performed to determine if the agent is within range to attack the player, the outcome of this check determines if the agent will transition to the “Chasing” or the “Attacking” state.

Chasing State:

The agent’s target position will update to the player’s current position while the player is successfully being seen by the agent using the previously described techniques. When the agent reaches within a specified distance of the player’s position it will transition to the “Attacking” state, indicating an attack is available to execute. If the agent cannot see the player due to obstructing geometry or the player moving beyond its current visibility range, the agent will transition to the “Searching” state.

Searching State:

This state features an internal counter used to determine when an unreachable target position is set. This scenario is possible when the player escapes an agent’s view through the help of dynamic geometry, like closing doors which agents cannot operate, moving up an elevator or escaping the bounds of the navigation surface which the agent’s internal pathfinding mechanism is operating on. During this state the agent will attempt to reach the last seen position of the target while attempting to find the current position for it. If it reaches within a specified distance of the last seen position or the internal counter for attempting to meets a set threshold, the agent will transition to the “Wandering” state, indicating that the target (player) has been lost. When the agent is able to successfully see the target (player) during this state, it will transition to the “Chasing” or “Attacking” state based on the current distance to the updater position, indicating if an attack can be performed or not.

Attacking State:

During the attacking state, the agent’s forward rotation is influenced by the target (player) transform to turn it towards in an attempt to successfully hit the object. The animator component which is referenced in the script is used to transition the current animation to the one representing an attack. The agent’s the target destination is temporarily set to it’s current position which halts it in place and the refresh rate for the current state is used to allow the attack animation to play out. After the specified time passes the target switches back to the last player transform and a distance check is performed between the agent and target position to determine if the player is close enough to be sensed by the agent. When this check passes, the agent will turn towards the player again and a raycast check will be performed to determine if the player has hidden from the view of the agent. When the agent cannot see the player after completing its attack it will transition to the “Searching” state. If the player is successfully seen by an agent in this state, nearby agents will be alerted of the location of the player and attempt to assist the signalling agent. The agent will remain in the current state until its current health is less or equal to a custom health threshold specified for indicating when the agent will transition to the “Retreating” state. If this threshold is not reached the agent will only transition to the “Chasing” state when the distance to the player is further than the attack range. At the end of the logic block, if the agent’s state has been changed from the “Attacking” state the animator will stop playing the attack animation.

Retreating State:

The retreating state begins with the agent computing the furthest waypoint based on its distance to the position of the threat (player). While in this state, the agent will attempt to signal to nearby agents of the player’s last seen position in an attempt to call for help. When the agent is within the specified distance of the waypoint to be considered reached, it will update its current health to the maximum value it started with and transition to the “Wandering” state after a short time indicated by the associated state refresh rate value. While the agent is navigating towards the waypoint used for retreating, if the player is successfully seen using the previously described techniques a new waypoint will be computed and set as the retreat destination unless the player appears in attack range, at which point the agent will attempt to defend itself and quickly transition into the “Attacking” state before returning back to the “Retreating” state.

Dead State:

The dead state is reached when the agent’s current health reaches 0 or lower. Its behavior remains unchanged from the provided academic material and simply invokes the kill method which is used to toggle the rigidbody properties of the 3D model it is associated with.

FSM AI Variants:

The FSM model described above has been designed to allow multiple configurations of the underlying AI logic based on stats configurable through exposed variables that control the viewing angle for each state, the visibility distance used in raycasting, the maximum health of an agent and the refresh rate of individual states. Further configurations are applied to differentiate the variants using the functionality exposed in the Unity’s internal NavMesh Agent component where the speed has been adjusted according to the enemy archetype which is being represented ingame through the associated 3D model.

Classic Zombie:

The behavior of this unit is configured around an enemy with a large health pool (200.0f), slow attack rate (2 seconds), narrow viewing angles, limited visibility distance (20.0f) and a slow rate of movement (1.0f). This variant is stripped of the retreat phase and regenerates health periodically during the “Wandering” state.

Agile Zombie:

The behavior of this unit is configured around an enemy with a small health pool (60.0f), fast attack rate (1 second), standard viewing angles, standard visibility distance (40.0f) and a fast rate of movement (3.0f).

Grunt Unit:

The behavior of this unit is configured around an enemy with an average health pool (100.0f), medium attack rate (1.5 seconds), large viewing angles, large visibility distance (100.0f) and a medium rate of movement (2.0f).

References:

Zombie Game – Extended AI Behavior Pt.2

Introduction:

I’ve extended the zombie game’s codebase further by implementing two new additional enemy types in the form of an agile zombie, which moves and attacks faster but has less hit points and a grunt marine unit with a large health pool and prolonged attack animation. These two new enemies introduce an additional state to the FSM model I had previously developed for the original zombie enemy and is exclusive to their AI behavior. Additional features include a performance boost, new models & animations and an updated stats system with health regen.

Summary:

Retreat State: When the agent’s health drops below a specified custom threshold, the AI will compute the furthest waypoint from the last known position where the threat (player) was encountered and use it as a target to move towards. Upon reaching close enough to the retreat waypoint, the agent will restore its current health to the maximum value which it spawned with. If the agent encounters the player along its path while retreating, it will compute a new furthest waypoint to travel to based on the updated player position it encountered.

Health Regen: The original slower zombie’s health system has been updated due to its simpler FSM model and it now regenerates health over time during the wandering phase if it’s current health is lower than the maximum value which it spawned with.

New Model & Animations: The agile zombie enemy has been implemented with a new model obtain from Adobe Mixamo and features different animations to distinguish it from the original. The grunt enemy unit uses the same model which the player character has but with a darker shade material to be easily distinguishable. It also features different animations which are used to reinforce the distinction of its AI behavior.

Performance Updates: Performance has been improved across throughout the project due to how coroutines were previously used for the FSM model. Now they are timed and managed correctly using a dedicated set of variables that ensure the correct coroutine is called at right time for its associated state.

Artificial General Intelligence and General Game-Playing Agents

Introduction:

Throughout the years, advancements in technology have pushed the limits of what can be achieved with AI. As computational power grew the overhead of developing advanced behavior for achieving complex tasks has decreased but an open challenge is still present in the task of developing an artificial general intelligence (AGI). The main concept behind it is the inception of lifelike AI which has the ability to understand and learn any intellectual task by itself and can influence its cognitive abilities and discern its own and others’ behavior.

General Video Game AI:

Games are a popular testbed for AI benchmarks. Research in the field has enabled some interesting advances in algorithmic AI, such as the use of parallelized Alpha-Beta pruning and Monte Carlo Tree Search in traditional board games like Chess and Go. Designing the behavior of these agents through the controllers which implement these algorithms involve training them under highly specialized conditions which inherently prevents them from being efficiently transferable to a generalized space. General Video Game Playing (GVGP) is a sub-domain of Game AI which aims to provide a framework defined in Video Game Description Language (VGDL) for creating generic enough agents that are capable of playing any given game without pre-computed game-specific heuristics, in possibly unknown environments.

An agent implemented in such environments must be able to select moves in real-time, providing a valid action in no more than 40 ms at each time step. The controller it uses receives information about the game state and it is its responsibility to discover the game mechanics without being aware of the victory conditions. The agent is provided with a tool, in the form of a forward model, which allows it to simulate its actions and roll the game forward to one of the next possible states which allows it to reason about the environment. The forward model is very fast and almost all successful agents simulate hundreds or thousands of game states for each decision taken.

Automatic Game Design:

The GVGAI framework is expanded into multiple tracks and can be implemented as a toolkit for game, level and rule generation and use the player experience to influence its behavior. This concept became an active research topic in the late 2000’s where development work was first done in the area.

  • Game Generation: Provide AI controllers which automatically generate new games or game instances by tuning game parameters. Work has been done on this concept by providing a particular theme, a database of game objects, or searching spaces of game rules, with which the participants can generate new games. Automatic tuning is achieved using search-based and population-based methods that have been applied to game parameter optimization aiming at maximizing the depth of game variants or finding more playable games.
  • Multi-Player GVGAI: The multi-agent game domain is a popular development field with competitions being held since 2011. The interface for the two-player planning track was initially developed for two or more players, so it has the potential to be expanded to a multi-player planning track in which an agent is allowed to control more than one player or each of the players are controlled by a separate agent. This future track can be expanded as a multi-agent learning framework, providing a two-or-more-player learning track.
  • Turing Test GVGAI: Determining if an agent that is playing a game is a human or a bot is a challenge that has been subject of study for many years, and the idea of applying it to a general video game setting is not new. This concept offers an interesting opportunity to extend the framework to having a Turing Test Track where participants create AI agents that play like humans for any game that is given and an audience discerns whether an agent or human is playing the game and what differentiating factors exist.
Further Development:

The GVGAI framework offers the most comprehensive system to date for evaluating the performance of general video game playing agents, and for testing general purpose algorithms for creating new games or new content for novel games. The framework has been used in multiple international competitions, and has been used to evaluate the performance of hundreds of general video game agents.

There are several improvements and additions to the framework that can be done and would potentially affect all existent and future competition tracks. One of these continuous modifications is the constant enlargement of the games library. More games are added with each subsequent competition while improvements in the GVGAI functionality are made which has the potential to create infinite number of games that can be integrated into the framework.

Adding more games can also be complemented with compatibility with other systems. Other general frameworks like OpenAI Gym, Arcade Learning Environment (ALE) or Microsoft Malmö count on a great number of single or multi-player, model-free or model-based tasks. Intefacing with these systems would greatly increase the number of available games which all GVGAI agents could play via a common API. This would also open the framework to 3D games, an important section of the environments the current benchmark does not cover.

With regards to the agents, another possibility is to provide them with a wider range of available actions which they can carry out simultaneously or be used to form a continuous action space. This would enhance the number of legal combinations for the agent to choose from at each decision step.

The agent tracks cater for planning agents able to exploit a fast forward model, and learning agents that must learn to react sensibly without the benefits of a forward model. The planning track already comes in single- and two-player versions, while the learning track is currently single-player only, but with two-player version envisaged. Long term learning may also be used within the planning track as successes in Go indicate what can be achieved by combining learning and planning.

Challenges and Opportunities:

AGI and GVGAI are plausible now more than ever before due to the exponentially higher amount of compute resources and data being available but they still remain largely the topic of continued research and development with the help of giants like Google and other major investors pushing the frontier through smaller companies like DeepMind. Major scientific and technological breakthroughs are necessary to overcome the current widespread adoption of “narrow-AI”, which performs reliably in a single domain, and transition to a more general model that can be adopted across multiple sectors. If researchers one day succeed in building a human-level AGI, it will probably include expert systems, natural language processing and machine vision as well as mimicking cognitive functions that we today associate with a human mind like learning, reasoning, problem solving, and self-correction. However, the underlying mechanisms may differ considerably from those happening in the human brain just as the workings of today’s airplanes differ from those of birds.

Credits:

References:

Unity Navigation & Pathfinding

Unity Navigation & Pathfiding:

Unity’s navigation system provides agents the ability to intelligently move around the game world using navigation meshes. Dynamic obstacles can alter the navigation of agents at runtime, while off-mesh links can be used to implement custom behavior associated unique actions performed under specific criteria.

Creating a navigation mesh can happen prior to initialization or at runtime. The creation method can be customized through by attaching a NavMesh modifier component to objects. This modifier can alter how the object it is attached to will affect the NavMesh creation process. There are three area types available through the component which include “Walkable”, “Not Walkable” and “Jump” type. Selecting each of them modifies the properties associated with the generation of a navigation surface. Volume modifiers can also be used at runtime to alter the type of area of a navigation surface where their associated game objects are located based on their properties.

NavMesh Obstacle components can be attached to game objects and influence the pathfinding of agents at runtime in two ways. The first is by interfacing with the obstacle avoidance properties of their associated NavMesh Agent components and configuring them to steer away when in certain proximity of the obstacle. The second is by carving the generated layout of the navigation surface, dynamically updating the pathfinding of every active agent as the obstacle positions change.

The pathfinding algorithm works by adapting the A* search algorithm to traverse a graph of nodes that represent each polygon tile of the walkable areas of a navigation surface generated by the NavMesh system for the associated terrain. Unity is using reciprocal velocity obstacles (RVO) to predict and prevent collisions for the AI.

Performance & Challenges:

The performance factors are associated with the size and inner complexity of vertices that are used for the navigation surface generation process and the number of dynamic obstacles that are present and change the layout data at runtime. If a large surface is composed of many nodes the speed of traversing through the graph will increase by O(n), n being the number of nodes, the more movement that is detected by obstacles the higher the performance cost will be to compute local navigation at runtime and process the global pathfinding for the NavMesh surface by carving it for each available agent. Performance will also decrease with the number of active agents based on the complexity of their pathfinding. Carving the layout of a navigation surface at runtime is a very costly process and will incur heavy performance impacts if unaccounted for in large scenes with lots of complex geometry.

The AI in this type of system will struggle when navigation surfaces are being regenerated often at runtime and with changes to geometry which the agents cannot account for and compute their global pathfinding efficiently. The AI can face problems with local navigation when presented with multiple objects dynamically surrounding and obstructing any available path of the agent to its target. Other issues include overlapping positions of off-mesh links which prevent agents from accurately interacting with them at runtime. When multiple agents attempting to reach a target simultaneously with the same distance of travel required for each of them to reach it, they can get stuck walking towards each other when they get close enough to the target, unable to accurately reach it.

Credits:

References:

Zombie Game – Extended AI Behavior Pt.1

Introduction:

I’ve extended the zombie game codebase by implementing two additional states to the AI Agent which include “Searching” and “Attacking”, bringing the total number of states for the Finite State Machine model to 5 and enhancing the functionality associated with the “Wandering” state to favor the closest available waypoint rather than follow a linear progression of the data in the waypoint game objects array. The functionality associated with every state presented from the tutorial has been overhauled in favor of extending the complexity of the FSM model and improving the player-to-agent interactions.

Summary:

Coroutines: Unity coroutines are adopted throughout every state to customize the functionality available to the AI Agent in each state.

Animations: New animations are added from Mixamo for the additional functionality that has been integrated into the updated FSM model.

Stats: Player & Agent stats system have been implemented for tracking each entity’s health and agent’s view angle and visibility distance.

Crowd AI: Functionality to alert nearby agent when the player is spotted is implemented allowing for simplistic crowd AI behavior.

States:
  • Wandering – The agent travels to the nearest waypoint computed at startup and finds the next closest one each time the current is reached. When the player is in view of the agent, determined by checking the angle between the agent’s forward direction and the direction to the player against a custom view angle, a raycast check is issued to locate if there is any object obstructing the ray before it reaches the player. When the ray reaches the player with no obstructions, the player’s transform data and a direction towards this transform’s position are saved and issued to nearby agents which transition into the “Chasing” state and attempt to catch help catch the player together.
  • Chasing – The agent’s target is set on the player’s transform and is updated every time the coroutine restarts by checking the custom view angle and raycasting for any obstructing geometry. When the agent reaches a specific distance close enough to the player’s transform, it will transition into the “Attack” phase. The player can outmaneuver the agent if moving out of range where the agent’s visibility distance extends to or moving behind geometry where the agent is unable to successfully track movement. When the agent loses sight of the player, it will transition into the “Searching” phase.
  • Searching – The agent travels to the last seen transform position of the player and checks whether the player is visible using the custom view angle and raycasting for any obstructing geometry. If the goal is obstructed, whilst looking for the player’s current transform position, a counter will increment and upon reaching a specific value, the agent will switch to the “Wandering” phase.
  • Attacking – The agent stops in its current position to play the attack animation and resumes back to tracking the player through the last seen transform position. A view angle and raycast check is performed to instruct the agent if a transition to the “Chasing” or “Searching” state should occur.
  • Dead – The agent’s interactive components are disabled and the ragdoll mechanics are enabled. The object representing the agent is destroyed in a specified timeout.

Zombie Game – Tutorial Tasks

Introduction:

This is a brief overview of my results and conclusions from completing the weekly tasks of the Zombie Shooter Game tutorial from the Games and AI module at Coventry University.

Week 1:

The tasks in Week 1 assist in the setup of a Unity project & scene, explains some basic methods of managing 3D assets and provides a solution to a simple “Point & Click”-style AI agent movement using transform targetting, handled through a custom Unity script attached to the agent’s game object. Pathfinding of the AI agent is handled through Unity’s internal Navmesh system which bakes a map that the agents can use to navigate at runtime.

Week 2:

The tasks in week 2 assist in the implementation of a basic Finite State Machine AI model composed of three states, provides a solution to integrating existing 3D models and animations in the Unity engine through the Adobe Mixamo platform and assists in customizing the player and AI agent character in the Unity engine using the imported models and animations.

Week 3:

The tasks in week 3 expand the functionality of each individual AI agent state from the three previously implemented which also set up player & AI interactions, assists in setting up dynamic ragdoll behavior for 3D models with the Unity engine and provides basic instructions to texturing the environment using custom textures.

Week 4:

The tasks in week 4 extend the features of the game project by assisting in the development of a respawning methods which tracks the number of active AI agents and instantiates new ones to meet a specific count when destroyed under certain conditions using an existing transform in the scene and suggests further development ideas.

Conclusion:

Completing every weekly tasks in the tutorial provides me with a basic Finite State Machine AI model composed of three states which manages individual animations for the 3D model it is represented by. The FSM AI model uses Unity’s AI Navmesh system to handle a its pathfinding mechanism. The Navmesh system computes data associated to 3D terrain offline and produces a map which the agents can use to navigate that terrain at runtime.

Hierarchical FSM – The “Combat Chess” of Doom (2016)

Introduction:

For the first week of the Games and AI module at Coventry University, my task involved to choose a game and analyze the AI techniques implemented in it. I chose Doom (2016) because of its player-focused engaging action-oriented gameplay loop, defined as “Push Forward Combat” by the developers. This type of combat is designed with an emphasis on encouraging the player to actively seek out and pursue enemies until an area is cleared out which in turn provokes different type of AI behavior in the enemies who posses unique individual traits that they rely on to plan and execute their strategies in an effort of holding their ground, ensuring their survival and defeating the player.

Doom 2016:

The 2016 release of Doom is a resurgence of one of the most important classical franchises in gaming history. The original Doom, created in 1993, was considered a game design marvel for its time which has influenced and shaped the FPS game genre from its infant state to where we find it today. Doom (2016) is a modern adaptation of the original game formula, focused primarily on delivering an engaging fast-paced action-oriented gameplay experience by guiding the player through multiple types of battle arenas where crowds of different types of enemies are designed to spawn and present unique challenges as monster count is a pillar of the franchise.

AI Design:

AI Archetypes: The game features 16 distinct AI archetypes designed around the characteristics of each demon which the player engages in combat. Each archetype is outfitted to carry out a specific role efficiently in a fighting scenario rather than attempt to do many different things at the same time which reinforces the AI consistently predictable while allowing the player to instinctively plan the order of enemy engagement in combat. This method of design complements dynamic crowd AI behavior and is referred to by the developers at id Software as “AI Chess” (The “Swiss Army Knives vs Chess Pieces” ideology). While the original inception of AI design in the 2016 version provided a more complex solution to individual enemy behavior, during playtesting results showed that a large degree of that complexity was lost due to the pace of combat in the game so the resources related to it were moved to other systems.

AI Encounters: Combat encounters are designed to complement crowd AI behavior and can be separated into two distinct types based on the pacing options which they introduce: Wave fights and Arena fights. Wave fights consist of incidental combat encounters where crowds of enemies would engage the player in transitional spaces and would serve as pace breakers. Arena fights are the backbone of the game and feature a steady stream of AI reinforcements that engage the player in a “lockdown” style arena environment. The stream of spawning AI reinforcements is tied directly to the health of the last “heavy” minion which must be eliminated to lift the “lockdown” state and prevent other minions from spawning to assist it.

Hierarchical Finite State Machines:

Doom (2016) uses a Hierarchical Finite State Machine model for its AI behavior. The concept of HFSM can be described by a programmable hierarchy representing behavior inheritance between multiple individual Finite State Machines which are grouped together into clusters based on their classifications. As class inheritances allow subclasses to adapt to new environments, behavioral inheritance allows substates to mutate by adding a new behavior or by overriding existing behavior. HSFM is not prevalent in modern shooters due to being more mentally straining to develop for many different contexts and involve a tedious process of manually editing state transitions during iteration, whereas Behavior Trees and Hierarchical Task Network planning are more popular.

Crowd Combat System: Enemy AI attacks require a token to execute. If an enemy wants to execute an attack they must first request a token from a token pool. If a token is not available they must do something else and if it is then they acquire it. Enemy AI can hold onto the token or use it for the duration of the attack. When used, that token is on cooldown and can’t be reacquired by any enemy AI. Token pool count is regulated by game difficulty. Tokens can be stolen by select enemies based on their proximity and visibility to the player.

Faction System: Enemy infighting is core to demon characterization. AI archetypes represent factions that can accidentally or intentionally cause damage to other factions in combat which in turn leads to infighting. Infighting is managed by the number of colliding attacks in a fixed amount of time. Factions are defined as diverging groups of enemy archetypes and based on their inherent connection to each faction invoke different responses from attacks caused by AI behavior observed from other factions.

Doom (2016) uses two additional systems with HFSM to seamlessly manage AI behavior in different scenarios: Animweb Animation System and an expanded RAGE Cover System.

Animweb Animation System:

AI in Doom (2016) has direct control over their character animations and as such rely on a full-body animation system. This type of system minimizes limitations to the animation workflow as pose matching, breaking up or shortening animations and animation layer restrictions are no longer relevant issues. The AI can improve the utility of full-body animations by dynamically modifying origin translations and rotations, animation pose, playback rate, and position and blend weights. The result is AI behavior which feels more alive and engaging, facilitating sophistication and responsiveness to its surrounding environment.

AI Damage Response (Hit Reactions):

  • Twitch (Light/Heavy) – react, but don’t stop current animation
  • Falter – stop current animation, but continue fighting
  • Pushback/Knockdown – stop current animation, temporarily immobilized, can’t be glory killed
  • Stagger – stop current animation, temporarily immobilized, can be glory killed
RAGE Cover System:

Doom (2016)’s engine, idTech 6, is built on the advancements implemented in RAGE, another FPS developed by id Software, contains an AI cover system which suggests where enemies can take cover from the player. Due to the inherent design of the combat pace in Doom, the developers use reverse values to suggest firing position for ranged units which remain at a distance but are exposed to the player’s visibility (this system is referred to as “Exposed Cover” by the developers). Exposed cover positions are used by the developers as tether points and while tethered the enemy AI is free to make local direction and positional changes as they see fit. AI behavior in Doom (2016) evaluates the effectiveness of tether points using a runtime algorithm (“Bunch O’ Traces”) which generates a grid of sample points within each tether area and then traces the visibility of each sample point to the target to determine an average of which sample points can see the player converted into approximate percentage value.

Conclusion:

The AI in Doom (2016) is designed to showcase how dominating the player’s actions are. It is not designed to do whatever it can to kill the player but used to deliver a great player experience through its added value to the underlying gameplay loop which is the ultimate goal of the AI developer in a game development studio.

Credits:

References:

Design a site like this with WordPress.com
Get started