It's me again! (Richard, Lead Devloper)

Today I want to talk a little about AI improvements (real Games AI, not that Generative AI nonsense), Combat and the fun of pitching!

Combat and AI!

Up until now, the enemies have been on a very simple system. They would have a randomised number of "wandering moves" where they would pick a spot on screen, and then meander around until hit or until they had moved a set number of times, before defaulting to a "chase and attack" mindset.  Not great.  Right now, our enemies all inherit from a basic EnemyBase class that handles getting hit, navigation AI, etc. so it made sense to start there. 

I decided to make a basic State Machine for all the AI movements I could think of, and have that trigger off of an E_EnemyBehaviour enum. (Gods, I love enums!). Below are the (current) AI states that they can choose from! 

So now, we have a list of states. Great. But what do they do?  There's a bunch of movement commands, a bunch of Move-To-Player commands (which will end in Melee attacks for any Melee combatant, more on that later) and some more bespoke commands like Jump/Retaliate.

The AI State Tree. 

So how does the AI work? Well, there's a behaviour tagged as currentEnemyAIBehaviour (there's that idiot-proof naming again!) and when it comes time to execute code, it just jumps into the appropriate function! The functions all contain starting parameters, an update loop, and exit perameters.  Example: AI_MoveToFurthestPlayer. 

Stick with me, I swear this is cool! (I'm cool, right?)

So! It goes into the code, and checks if it's had its Entry Parameters set. Sets them, then says "Yup, these are set." This is important as it essentially flicks a bunch of switches or one-time code executions to make sure everything is working with regards to this particular AI state, then doesn't set them again. This includes the somewhat expensive FindFurthestPlayer() function, which sets our currentlyTargetPlayer variable to whichever player is furthest away. Once we know which one that is, we don't need to check again just yet. 

Then, the loop. Sets our navigation target to that players position, modified by the distance we need to attack, and again modified by if we want to move to the left or the right of them. (Right is always Front, as that's "forwards".) Then, we move!  And when we're there? We check if we need to wait at all (instant transitions are unfair to players, the typical wait is 0.2 to 0.4 seconds) and then smack 'em with a Melee Attack by changing our currentAIBehaviour to AI_MeleeAttack().

Melee Attack will then transition to the next command, which is AI_GetRandomBehaviour(). 

AI_GetRandomBehaviour()?

Well, this is the guts of the system. Not all enemies have access to all AI movements, and instead each have a list of AI Behaviours, selecting from that list.  This means we can very quickly and easily determine different AI behaviours for different enemies, without needing to create custom code. All the code exists on every EnemyMelee, but they only care about what they're told to care about.  

That's a lot of Nerd talk. What's the summary?

The TL;DR is that I am VERY proud of our enemy AI and will be inflicting it on the next demo (along without all the Combat improvements from Dev Log #1) as soon as we've finished our internal tweaking-and-testing phase! Which is, you know, soon.