SHDL#05 Enemy AI

In gamedev, making good AI is less about making complex, smart agents that cover all bases and more about making simple, dumb behaviors that are good enough for the tasks at hand.

This is probably the first project where I devise any semblance of a scalable, modular system for enemy AI. Usually I just give them huge hardcoded spaghetti algorithms that are one-use-only and let them do their thing (usually badly).

For this one I decided to structure it much like I structure my player controllers, and give them dedicated movement and combat scripts.

The movement script does the sole job of handling navmesh and physics methods, while the combat one solely deals with damage. health, death and so on.

Movement has a Radial Target Check to update its Aggro status and a simple state-machine based on Types like Fixed, Pursuer, Fleer, etc, that determine how would the character move in relation to targets.

Combat has a series of booleans that tells the character what they can do (can they attack in close-combat? can they attack from a range? can they attack in an area?) and properly times and executes each available action according to its parameters (are they close enough to melee?) Most of it is trivial but I managed to not only make it modular enough that I can mix all of the available movement and combat actions together to create new enemy archetypes from a small pool of behaviors but also made it so clean and simple that adding new, edge case behaviors (for example for bosses) is literally as easy as ticking a box. The movement system also uses a new implementation I had in mind for some time that enables the navmesh components by task. I made a separate set of methods that turns on and off all of the navmesh agents own methods for movement control according to how Im using it. It only enables the component, and only calls for movement to do specific tasks like approach/retreat a certain distance from a target, turning it all of at the end of each action, so I can turn it off if I want to apply physics to the agent or move it around through any other methods.

I still intend to try making it completely independent from the navmesh agent so that the controller has total control over its movement, using the navmesh's methods only as guide, but that implementation will wait for another day.

The combat uses a set of gameobjects holding colliders that get activated according to timings and cooldowns, called by simple state-machines. The first different thing Im doing in this project is dealing with the actual gameobjects of the colliders instead of the components directly. Normally, in a melee attack you just enable and disable the collider component sitting on a weapon or in front of the character to overlap targets for a split-second, but that lacks any customization apart from timing. If I want to hit everything in an arc, or emit a growing ring, Id need custom meshes and separate objects. Instead, by activating child gamepobjects containing these colliders I can animate them and it will play on activation, doing more complex behaviors even with the standard collider shapes (a front arc attack, for example, can easily be made by expanding a sphere/cube collider while moving it forward).

The second was to completely dettach the activations from the characters animations. Usually, you can simply setup animation events to call for activation and deactivation of colliders on the exact frames you want it, but that ties it to the actual animation asset and is cumbersome to adjust if anything changes.

I decided to just have an exposed vector2 store the activation and deactivation times to be called on button press so that I can quickly time it just by changing values, no matter the animation being used.