This is a common issue I've been running into when dealing with enemy types and their AI.

While certain FSM's such as a Health FSM can be templated out and used well, assigning subtemplates/setting variables WITHIN those gets pretty messy :/ (without having already predeclared variables on the parent FSM that you may not use in the child)

Example: Using an Navigation template that controls how an enemy navigates TO the player. But when they get within range you want to do a more customized style attack.

Enemy 1: Goes up to the player, when near, attacks.Enemy 2: Gets within 10 feet of player, teleports behind them and attacks.

Is it best to just try and keep getting clever with Run FSM to do something like this?

Sorry if there's confusion, starts to fry my brain after a bit of thinking

You can something similar with Playmaker too, though it requires a few more steps. Same features, like moving towards an enemy can be the same, and then you have the branching of actions based on the name of the FSM owner.

Something like this

It's even easier then inheriting, you can put a template that will define health, attack mode, movement mode, whatever you want based on the objects name or whatever variable you want to compare.

That's very true, that's kind of the general point I'm currently sitting at

The only issue is that (and maybe this doesn't matter?) it has to cycle through those branching actions EVERY time it has to move/attack etc. And many of those attack patterns require unique variables that would otherwise sit empty on the parent FSM.

Granted now you've got me thinking... maybe most of them DONT need uniquely set variables, but nothing more than a target object... hmm

you could be using gameobjects that you stack up and parent one another, and each fsm would call its child or parent depending on the order you want to execute them.

another way would be to create a data layer for these combos and so you don't hardcode the sequence of things in your code but rather use a text file or xml or json, or csv ( whatever) to tell what has to be executed and in which order. You can then either have a set of templates you are going to run based on that data ( you can save all templates in an hashtable for reference against a key for example)

That's very true, that's kind of the general point I'm currently sitting at

The only issue is that (and maybe this doesn't matter?) it has to cycle through those branching actions EVERY time it has to move/attack etc. And many of those attack patterns require unique variables that would otherwise sit empty on the parent FSM.

Granted now you've got me thinking... maybe most of them DONT need uniquely set variables, but nothing more than a target object... hmm

Thanks for the brainstorming Krmko!

-craigz

It does have to cycle, but that would be done in a few frames at most. The approach itself is basically like inheritance.

@Jean

How exactly would that work in playmaker? How can i create a set of templates based on a data layer?

you would have a state per template and each of these state would have a dedicated Global event "EXECUTE PATTERN / MOVEMENT 1" "EXECUTE PATTERN / ATTACK 3"

when the template has finish running you go back to a main state which responsible for launching the next execution in the sequence. and you use "Send Event By Name" to compose the global event to call base on the next sequence,

so you could even save the sequence in a simple FsmArray like

"MOVEMENT 1", "ATTACK 3"

or in a text file where each line is the pattern to execute.

does that make sense?

I also create a "RunTemplateFSM" custom actions on the ecosystem, but It's not 100% safe, at least you can experiment, it lets you save the template in a FsmVariable Object so you can actually load any template by code this way too ( but I recommand the first solution for safety)

- your ennemy has two fsm, one that holds the pattern, on that can be turned into a template executing the patterns

- patterns are expressed in FsmArray, quite simply.

- each pattern has a dedicated Global event, so that it's simple to call them, yet doesn't require them to be featured where unecessary ( not all your ennemies need to have a pattern they won't use

- event are built as string and sent as string, so the combinations are endless and the sequencer is agnostic to the content of the patterns and the event to set, no hardcoding on the sequencer, which is critical for productivity.

- the ennemy has children, each children is an pattern or attack ( and so they can use templates, or be added at runtime, etc etc). This is not mandatory, one gameobject could hold several patterns, could be template, could be anything.

- the pattern execution is controlled by the ennemy and each pattern is responsible to tell the fsm who initialize the execution that it's done, then the sequencer can execute the next pattern.

Let me know how it works for you. I'll beef this up over the next few days as I think this kind of problematic is interesting to study and understand where the complexity can be reduce for better workflow and productivity ( and avoid duplicates).