AI: the suffering files (now with dog gifs) (Patreon)

okay, no, okay, it's not that bad. it's really not that bad. veterans will remember when we spent months redoing the AI for essentials in e16 only to have to then have it all redone by cass later. it's not that bad, our battle system isn't bloated like that.
not yet.
(one fear)
((nah no shot))

In the course of testing the bones for the prologue chapter, I needed to add in some AI behavior that hadn't been completed for the demo. Unfortunately, this required me to perceive the AI. 

Here's a screenshot of our AI code at the start of this week--

delicious.

uh, where do you even start, right? I knew it was this bad, I tried my best from the outset but we're further along now... We've refactored a lot of systems after the demo, but the AI was not one of them.
Until now.
After seeing the state of it, I really just wanted to take a fork, dig in, and shake the AI like a chew toy.

I wanted this to be a 2 day project, it turned into a 4 day one, that's not terrible but I'm not thrilled about it either. 

Aside from just being better at programming, our codebase has cool new helper features, I've learned new tricks and to prioritize readability, and we have a whole new FSM system going on. 

n-no, that's FSM as in Flying Spaghetti Monster, and while that is representative of the prior state of the AI, I mean FSM as in Finite State Machine. also, that's not even a dog? get it together.
Basically the code now generally knows that only one thing is happening at a time in the game and it is going to behave accordingly rather than checking at all times a battery of conditions to try and figure out what's going on.

So previously, the AI worked like this:

After it becomes the enemy's turn, we call into the AI and tell it to do stuff. The AI looks at the first unit on the docket to move, figures out the best move, and then after that unit moves, the AI calls on itself again to start all over. It's kind of like a relay race; someone has the baton and it keeps getting passed around.

The problem is if, for some reason, the AI falters due to a cat, or because it was interrupted by a cutscene, or some other unforeseen reason reason, we have to call back into it and remind it where the baton is. It was a little bit tedious, especially when navigating between scenes. Usually we could account for that happening, but sometimes we failed to, and then the game would softlock. 

GPU issues notwithstanding, I think this was like, 90% of our softlocks in the demo.

More than that, though, it was a huge pain to work with because code-side it was super unclear what was going on on the back end. Like, I really want to show you a screenshot of how disorganized it was, but in order to really make my point I'd need to include like eight different screenshots and try to illustrate how it all fits together like

I-- I couldn't find a dog version of this. I'm sorry. I've failed you all.
Anyway, it would be useless.

Another issue was timing. Previously if we wanted to [do something, then wait, then do something else], we generally had to use asynchronous code, which I've posted about before how it has ruined my life. It regularly ruins lives, it's just what it does.

^ that dog is asynchronous code.

But, refactor. Now we workin' more like this:

Single file, the AI is handled through the update loop (the queue of events that the script runs through each frame). Each frame, it asks a traffic director what's going on with the AI these days, and that steers the code in the right direction for where it needs to go

i'm gonna be honest i'm finding the internet's collection of dog gifs to be a little lacking... I wanted one on a traffic director like the spaghetti dog but maybe that's not how dogs work

Anyway, the fact that it is now through the update loop means that no matter what happens, we are always prepared to issue a new command. It also helps us pace out those commands in a better way, meaning whenever we need something to happen, we can self-manage the timing without any asynchronous suffering.

Reworking it also gave me the chance to slip in a couple things that I was aware of based on feedback from the demo. At this point, I'll just list the positive changes of the refactor:

• Softlocks are yeeted
• We can now manage timing without asynchronous code, making us more flexible and stable
• It is much clearer to follow, meaning future additions will be much eaiser
• AI now prioritizes attacking units a la Fire Emblem. This was a requested feature after the demo. So, the AI will move all units that will attack first, and then it will start moving units that won't. This will also open the way for some other QoL features later.
• Sped up when multiple enemy units would Do Nothing. Because of async code, they were given the same amount of time to Do Nothing as units that were going to Do Something that were given. Now it is limited to one frame per unit.
• The thing that started this in the first place, we now have code to negotiate what to do when it has a specific target, but the only thing in its immediate attack range are enemies that aren't the target. Previously AI would just go SQUIRREL!! and forget what it was supposed to do.

Now it can stay focused.

Never again though. I would like to be doing these refactors once at the start, future-proofing the framework, and then never again.
That is an unrealistic goal.
But it is the goal.

this post brought to you in part by Flop:

she just flop over and purr.

Quick poll on the way out here, because I am curious about the breakdown of folks reading these posts still. I mentioned Fire Emblem earlier and, given the inspirations for Starlight and Engage being hot off the presses with a hot new batch of QoL for the tRPG genre, I'm likely going to keep doing so. 

So, just to check, how many of you have gotten Fire Emblem Engage, or plan to?

as usual there's like five other things i ought to talk about but no