SCOTT DAGEN - Blog

AI Architecture in "The Exaggerated Epoch of Edward O'Hare"

Mon, 12 Jul 2021 07:00:00 GMT

All enemies in The Exaggerated Epoch of Edward O’Hare contain an AI Brain script, a health script, a movement component, a perception component that tracks the player, and a state machine that holds multiple behaviors. Every frame, the AI Brain checks whether it's currently in a stunned or knockback state, and, if it is in neither of those states, tells the movement component, perception component, and state machine to update.

UML diagram of AI Brain and all required components. A Particle System and Audio Controller are optional.

Initial State Machine Setup

When I joined the team, the AI State Machine component supported three states at a time: an Idle state, a Chase state, and one of two Attack states. This was sufficient for the enemies that existed at the time, but if any additional complexity was desired, the architecture needed an overhaul:

This initialization function requires all of the idle and chase variables to be stored within the AI Brain instead of the state itself, and the variable name attackDist is ambiguously used as both the distance before switching into the attack state (as used in State_Chase) and the range from which damage can be dealt (as used in State_Attack).
This setup also has some additional limitations. In the above implementation, an AI can't have any states that aren't derived from Idle, Chase, or Attack, nor can it have more than one state derived from a given state type. An enemy wouldn't be able to have a chase state and two attack states, for example. New state types could be added along with new variables to hold them, but this is a bad solution. This would require every enemy to have every kind of state to guarantee that an enemy couldn't be told to transition to a state it doesn't have.

The New State Machine

One of the first planned additions to the game was a boss fight against an immobile dragon with multiple attacks. Even before any of its attacks were determined, I recognized that the then-current setup would be insufficient. We needed an implementation that wouldn't need periodic rewrites to account for new state types being added and could handle both single- and multi-attack enemies. To keep track of the machine's states, I settled on using a Dictionary mapping a StateName onto a List of States with that StateName:

This new system both allows for more flexibility when assigning states and moves all data relevant to a state into that script instead of being passed down through a series of functions. Additionally, the designer can specify which state the enemy enters first.

State Example: Hunt

The Hunt state was developed after the game initially released, when we received feedback from players that the Shield Rat enemy was too easy to run past. Its original attack calculated a trajectory towards the player's position at the time the state was entered and moved the enemy towards and through it, but if the player had moved from that point there was little to no risk of being hit if they weren't actively fighting the Shield Rat already.

A Shield Rat in its natural habitat.

The new Hunt state takes a very different approach, continuously seeking the player at a speed moderately above the player's speed. It also takes the player's velocity into account and attempts to intercept, encouraging the player to adopt a wait-and-dodge pattern until the attack ends, before retaliating with attacks of their own.
The math behind the intercept algorithm has two parts: finding the interception point and path smoothing. To calculate where the Shield Rat could intercept the player's movement, I followed the steps provided in a 2017 GDC talk by Chris Stark of Robot Entertainment (slides). This algorithm finds up to two overlap points between a circle representing all of the AI agent's possible positions at time t and a vector from the player's position representing their new position at time t moving at their current velocity.

The target velocity was given a weight modifier so the Shield Rat's accuracy could be tweaked. A lower value (less than one) would make it seek closer to the player's current position, and a higher value (above one) would make the rat more prone to overshooting.
However, this algorithm wasn't sufficient for calculating the rat's movement destination, as the rat's target could jump wildly if the player reversed direction. I needed to interpolate between the rat's current target at a given frame and the interception point, allowing it to smoothly shift to the new location over a few frames. This led to an interesting problem though: a linear interpolation between points a and b by a changing value u requires a and b to be static, known points. Because a (the enemy's position) and b (the interception point) change every frame, a different approach needed to be taken. The easy approach was to reassign a's value each frame:

\[ oldPos = lerpPos \\ lerpPos = Lerp(oldPos, goalPos, u) \]

This presented another question: what value should u have? This is no longer a proper linear interpolation, so it's hard to estimate how long the interpolation would take to reach a desirable threshold given a value for u. 0.5 would halve the distance each time, for example, and 0.3 would shorten the distance by a lower amount, but I couldn't reasonably ask what value to pick if I wanted the interpolation to take 1 second. To try to find a solution, I started writing out the results of iterative linear interpolation:

$$ \begin{aligned} Lerp(a,b,u) & = a(1-u)+b*u \\ Lerp(a,b,u) & = a-au+bu \\ Lerp(Lerp(a,b,u),b,u) & = Lerp(a-au+bu,b,u) \\ Lerp(a-au+bu,b,u) & = au^2 - 2au + a - bu^2 + 2bu \end{aligned} $$

Future iterations will be denoted as $ Lerp^n(a,b,u) $.

I continued out to $ Lerp^3 $ and $Lerp^4 $, looking for a pattern:

$$ \begin{aligned} Lerp^3(a,b,u) & = -au^3+3au^2-3au+a+bu^3-3bu^2+3bu \\ & = a(-u^3+3u^2-3u+1)-b(-u^3+3u^2-3u) \\ \\ Lerp^4(a,b,u) & = au^4-4au^3+6au^2-4au+a-bu^4+4bu^3-6bu^2+4bu \\ & = a(u^4-4u^3+6u^2-4u+1)-b(u^4-4u^3+6u^2-4u) \end{aligned} $$

At this point, I realized that this looked very close to being two binomial expansions added to each other. After a little rearranging, I reached this set of equations:

$$ \begin{aligned} Lerp^3(a,b,u) & = a(-u^3+3u^2-3u+1)-b(-u^3+3u^2-3u) +b(+1-1) \\ & = a(1-u)^3 - b(1-u)^3+b \\ \\ Lerp^4(a,b,u) & = a(u^4-4u^3+6u^2-4u+1)-b(u^4-4u^3+6u^2-4u) +b(+1-1) \\ & = a(1-u)^4 - b(1-u)^4+b \\ \\ \end{aligned} $$ \[ Lerp^n(a,b,u) = a(1-u)^n - b(1-u)^n+b \]

I now had an equation that would give me the output of an interpolation between $a$ and $b$ with an interpolation value of $u$, iterated $n$ times. From there, I wanted to create an equation that would yield a value of u that will give me a specified output for $Lerp^n$. $n$ was easily calculable, as it's equal to the framerate, rounded up, times the desired duration (in this case, $1$/Time.fixedDeltaTime for the framerate and 1 second for the duration yields $n = 50$). The $u$ equation is as follows:

$$ \begin{eqnarray} g = a(1-u)^n - b(1-u)^n + b \\ g = (a-b)(1-u)^n + b \\ g - b = (a-b)(1-u)^n \\ \frac{(g - b)}{(a-b)} = (1-u)^n \end{eqnarray} $$

$$ \begin{eqnarray} \sqrt[n]{\frac{(g - b)}{(a-b)}}=1-u \\ -\sqrt[n]{\frac{(g - b)}{(a-b)}}=u-1 \\ 1 - \sqrt[n]{\frac{(g - b)}{(a-b)}} = u \end{eqnarray} $$

From there, it's pretty simple to plug in values. $n$ is defined above, $a$ is our current location, $b$ is the intercept location, and $g$ is 95% of the way between $a$ and $b$. In practice, $g$ is calculated using the value $0.95$ for a float-based iterated interpolation between $0$ and $1$. Additionally, g is always between $a$ and $b$, so if $a-b$ is negative, $g-b$ is also negative, and the same holds for if $a-b$ is positive. This means that the value under the root is always positive, guaranteeing that even values of $n$ yield a real result.
These two functions are repeatedly used in sequence to ensure that the rat is always moving towards where it thinks the player will be can't immediately react to player actions.
The Hunt state is one of over twenty AI-related scripts that I either overhauled and optimized or implemented from scratch. Each one posed its own challenges, including managing audio cues, changing material variables to animate a projectile, and knocking back both enemies and the player, and they all required me to either expand my knowledge or apply it in ways I hadn't before.

GPR-450: Advanced Animation Programming

Fri, 01 Jan 2021 05:00:00 GMT

After taking Intermediate Graphics & Animation Programming, the logical next step was Advanced Animation Programming, which I took the following semester. Unlike the previous class, we were given the option to work in animal3D (C), Unity (C#), Unreal (C++), or any other framework that would allow us to complete our assignments. Cameron Schneider and I decided to continue to use animal3D, as we were already familiar with its quirks.

The class covered many areas of animation programming including pose-to-pose animation, forward and inverse kinematics (FK and IK), blend trees, and having animations respond to user input. There wasn't much range for us to customize our work until the final project, where we were tasked with creating something that incorporated each of the main topics of the course. Cameron and I decided to implement character control for a wolf walking up a slope.

We started by obtaining a skeleton and animation clips for a wolf, the latter of which we converted into an HTR file and loaded into animal3D. From there, Cameron implemented raycasting so we could detect whether the wolf was on a slope, and I revamped our blend tree so it would be easier to construct and modify. I also set up the code that would actually run the raycasts, which we used to determine the positions of the IK constraints.

Wolf Skeleton Walking Up a Slope

The large orange spheres are positioned one unit below the sources of the raycasts, and the cyan dots contacting the floor are the positions that the raycasts are hitting. These raycasts are bidirectional which allows us to determine whether a paw is above or below the floor. If the raycast source is below the floor, we move the IK constraint for that leg upwards until it's touching the floor, at which point we apply the IK solver.

The wolf bobs up and down as it goes up the ramp because its height is currently determined by a comparison between the distance from the shoulder to the paw in the wolf's idle pose (a stored constant) and the current distance between the shoulder and the floor. If the shoulder-to-floor distance is greater than the expected length, the wolf moves down to compensate, and if the shoulder-to-floor distance is less than 85% of the constant, the opposite occurs. This implementation was necessary because animal3D, being a graphics framework, lacks a built-in collision resolution system.

The code shown above demonstrates the various blend tree construction functions I implemented. When a blend tree is created, the user can choose to pre-allocate blend nodes or handle their allocation elsewhere and store it at a later point. Once the tree is constructed, each node is created by passing in the address of the node and an enum indicating its purpose. The following functions assign whatever data is necessary for that blend node to work properly, whether those are clip controllers or pointers to interpolation values.

The next function sets up parent-child relationships between nodes. In this situation, the nodes at index 0, 1, and 2 are all being set as children of the node at index 3, and the index 3 node is set as the root. Finally, there's a check to ensure that the tree was assembled correctly and the inputs and outputs of each blend node are configured.

I implemented the blend tree in this manner so that a GUI could hypothetically be constructed to edit trees at runtime. A node could easily be added, deleted or edited using other utility functions, and the tree could then be rebuilt with a3hierarchyBlendTreeBindStates() without needing to restart the program.

GPR-300: Intermediate Graphics & Animation

Mon, 01 Jun 2020 04:00:00 GMT

From January to May 2020, I took GPR-300: Intermediate Graphics & Animation Programming, which was a deep dive into both the CPU and GPU sides of graphics programming utilizing animal3D, a graphics framework created by Professor Daniel Buckstein. Throughout the course's duration, I and my teammate Cameron Schneider learned how to implement various shading algorithms and expanded upon the rendering pipeline provided by animal3D.

In addition to shading algorithms (such as Phong, Lambert, Cel, and Gooch), post-processing effects (Bloom), and pipeline techniques (framebuffers and deferred lighting), we were also asked to create projects exploring some area of graphics that we were interested in. For our midterm, Cameron and I decided to implement both screen-space ambient occlusion and a crosshatch/pencil shader.

Midterm Presentation

I was responsible for the majority of the C code for the crosshatch pipeline as well as the actual crosshatch shader. I also created the additional framebuffers that were required for the multiple SSAO passes and added onto the text-based UI so it was easier to tell what was going on. Cameron implemented the SSAO shader and the C code for its rendering pipeline, including generating any uniform variables that were required. He also found a way to pack the six crosshatch textures into only two images, which saves a lot of space both on the disk and in RAM as fewer images need to be passed to the GPU.