- leaders and pawns lane follow (right now I'm just calling the follow.lane method but they could have some AI action description like "lane_unit" that would automatically take care of this behavior)

- all units behavior on collision is to try to dodge the block and resume towards the objective after a while. you might want to allow changing this for some units

Here's the two approaches my buddy suggested. GOAP: https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793 Behavior Tree: https://gdscript.com/solutions/godot-behaviour-tree/ @rafaelcastrocouto got a preference? I know his was Behavior Tree, but I see both as interesting candidates

gonna take a slow look at both and think about how we can take advantage of each approach

between the two aproaches I'm certainlly more prone to GOAP, despite the article kinda mixing it with FSM, which is the common case but kinda blurs those structures together. it's a common mistake on quick articles about code architecture. most FSM articles also mess it with events and stacks, so it's good to read other materials as well.

anyway, as we talked about, I think we can build upon what we have and create some variations of the current behaviors (smart_move, lazy_gathering, enraged_attack, etc) and the AI would be able to use those collections of behaviours to choose the final actions. So for eg. an dummy orc worker could use a move function that don't use pathfind and get stuck while a smart tracker would always find the way out. Each unit would have a list of event functions (godot signals on_hit, on_death, etc) and who's building the AI can code something like:

if (unit.get_stat('intelligence') > 10) unit.ai.move_behavior = 'smart'

and the unit would start to use the 'smarter movement' method

this way whoever is building the AI don't have to worry about the move behavior details

That's an interesting idea, I like that

ok, I'll start doing more reading into GOAP

I think the biggest challenge will be keeping the node counts down from the default implementations, but as I get that far, I'll let you know and get some ideas.

I like the idea of behavior choices being based on data in the unit etc

I think that's fun and gives unit stats some amazing potential

especially if leaders or units level up and it changes how they behave

that's the idea ... on the previous implementation there was a Leader and Creep class with nodes as behavior trees, but the current implementation is simpler ... they are all intances of the Unit class (or scene) and that allows a pawn to be promoted to leader and a bunch of other interesting stuff. I think it's way easier for ppl developping the units actions to be able to get close to what they want by just setting the unit properties (like "smart", "leader", int value, etc) and, in cases where it's required, use pre baked in events and methods (like on_death, on_hit, unit.attack.point, unit.advance.smart) to create custom actions.

then we can have a big table listing the properties for all unit types (like you mentioned you would need for your stuff) and a smaller list of custom functions for those special cases (that can also scale without major issues)

Are you familiar with ECS?

It seems like you organically kinda started stepping closer to that model

which is my preferred

I'm currently trying to figure out GOAP without a bunch of child nodes

Its going to be possible, just gotta figure it out

I might build it with and then refactor to reduce them

but we'll see

The basic idea of GOAP is pretty slick

I might be able to make it work by using strings that point to a dictionary of the different actions

I guess it'd probably be enums actually... but you get the idea

I think i do ... ecs is awesome , combined with mvc, rest, event-driven, pipeline, service-oriented and agent-model and state machines rsrsrssss. what i mean is that all architecture systems are great as long as they are helping us organize stuff both in our heads and in the code.

as an architect and computer engineer i love to make parallels between both theories and how they kinda match one another (most have the same math basis)

despite having learned a lot about complex functional patterns and recursive behaviors, fractal functions etc... I'm still amazed how most of the problems we face while coding can be solved with the combination of simple structures like trees, dictionaries or fsm. that's why I usually start trying to implement things in the most simple way (couple functions and a hashmap) instead of the whole class declaration from traditional programming courses.

Just so everyone knows, I'm making slow progress due to life stuff, but haven't stopped