Making AI not suck

[dire lance]

I finished making my simple AI using an FSM, it patrols, looking for the player, then chases the player into range of weapons, then shoots until dead. This is terrible.
I want to include things like going into cover, suppressive fire, different tactics of combat based on panic, etc. I'm very new to AI though.
Can someone help out?

In general I don't know how the hell it would be possible to make any kind of advanced AI using an FSM. Like say, if you wanted to check for the player being in cover for too long then going around to search for him, there's so many states where that could be from

[runic cypress]

Did you make an HFSM or or an FSM that can only have 1 active state with a flat hierarchy? Proper HFSM implementation can mitigate a lot of issues since it has: infinite nesting of states, can have any amount of states active at the same time, parent states get updates before child states which lets us put important transitions high up in the hierarchy so you don't have to implement the same transitions in many children, also child states can access their parent state and call parents' methods\access data which allows code reuse.

Here is an example of a well designed HFSM library https://hfsm.dev/

[dire lance]

Well, I can easily nest FSMs by having states carry their own FSM

[runic cypress]

If you do it like that, there is no easy hierarchy resolution on state transition request. Meanwhile with my system I can easily transition from any state to any state or its child states because there is an actual hierarchy stored somewhere.

[dire lance]

Right, but you're suggesting an HFSM for my case, how do I use that to describe the behaviour I outlined?

[runic cypress]

So transitioning to a substate and activating all the parent states in its path is super easy with an actual iteratable hierarchy. It also lets me have redirection states that reroute state transitions if I want to handle some part of transition branching in the same place.

[runic cypress]

For checking what the player is doing, you can have some combat parent state high up in the hierarchy checking if target manager considers the target to be hiding for too long. Then you can send an event to the hierarchy and some high level state to which everything combat related is parented can react and request transition to the high level search state.

[dire lance]

I'm just going insane trying to organize the behaviour in my head

[runic cypress]

Also if you repeatedly have to do something and then transition, you can make redirect states that do a thing and immediately transition somewhere else.

[still linden]

IMHO what you need are qualitative AI axioms, which are the basic behaviors which can be triggered by your state machine, such are:

• Look for cover
• Fire from cover
• Look for the player when missing
• Etc.

They need to be very high level, you don't need to dictate everything from your state machine, only the very high level decisions. One behavior, like looking for cover, can in itself be very smart and complex without being split into multiple sub-AI-behaviors.

If your AI behaviors are strong, it simplifies a lot the state machine.

If you start from there, what is "suppressive fire"?

Suppressive fire will decide for itself where to fire and for how long. You'll only look for the condition:

• No ally is already doing suppressive fire
• Having 2 more or allies (so we don't use suppress fire to cover nobody)
• 3 or more enemies are grouped together (so we don't use suppressive fire on a single guy)

Very simple conditions, complexity is in Suppressive Fire (not AI code, just normal code), that needs manage itself.

[dire lance]

Hmm

[dire lance]

Thanks for this