add max-depth parameter

[benjajaja]

When actions and goals get complex, I find it very tricky to give up early. I don't know much about GOAP, but the crate is using astar, so I think it would make sense. I have no idea if my states/actions/goals cause infinite loops, or are just too deep, but they stall sometimes.

I suppose the max-depth option should go into the Agent.

[lixitrixi]

Thanks for your issue! I would imagine it's because of an infinite loop or similar; could you provide a test case?

[benjajaja]

Might be tricky, but I will try.

[benjajaja]

It seems it can be solved easily by tracking depth in state, and returning false in is_applicable of all actions when exceeding some limit.

Example of an infinite search that is being limited by tracking depth in state: benjajaja@15c4728#diff-2ad10836ccce5ac2056d5679cc92449d9ff9094d4ff5c5803f65b5dd1d52ef19R137-R138

The pathfinding crate also doesn't have any max-depth kind of parameters, and in a discussion there it's more or less suggested to do something similar.

[benjajaja]

@lixitrixi for your amusement, here is a video of my usage of this library:

2025-04-24.21-12-55.mp4

The goals are reconnect-land-clusters, revenge(another player), or simply grow. The actions are series of steps. Finally I solved the too-broad search by constraining to only search from two distinct land-clusters, tracking the "starting points" in state and returning false from is_applicable.

[lixitrixi]

This is so cool, thanks for sharing! Really glad to see this library in use :)

I realise the crate is quite small, but I welcome any more suggestions or PRs. I will see if there's a way to specify a max depth, but with the dynamic types it may be difficult.

[benjajaja]

The depth tracking only solved some cases, the overall problem was having too many actions creating an "explosion" of combinations. First, I cut down the possible actions by "combining" some successive steps before planning. Second, I track in the state how many other actions are being applied, and constrain it to just two, as it doesn't make sense for the defined goals.

It feels a bit like a leaky abstraction, doing this via the state and in is_applicable. But on the other hand, this is trivial to do, and I'm not sure if it would make sense to have max-depth or max-concurrent parameters to the agent: there might be many more similar but slightly different cases. Perhaps it could be generalized with some configuration or callback, but for now I wouldn't worry about it.