This is another best practice question.
If I have a single AI that uses multiple behavior trees that do pretty different behavior should I have a different blackboard for each of them?
I currently do and the only con I’ve ran into is caching the key IDs to each blackboard key of those blackboards in my single custom AIController.
It just seems a bit messy.
Keeping your Blackboards as small as possible is one good practice, that’s for sure. Not keeping AI-type specific data in BB asset used by all/most is a good one as well.
In general, having different BTs with different BBs, and running them on one AI is not a problem. And key caching is totally optional.
What would you suggest?
Cheers,
–mieszko
The only “messy part” for me is the key caching. I do it to keep the code specific ties to a data asset in a singular place as I dislike having the string references in code. I’m trying to avoid as much initial setup for new AI for designers so I’m caching all meaningful keys.
I’ll probably stay the course and maybe refactor some shared blackboard keys into a parent blackboard at some point. I haven’t done any blackboard inheritance to this point.
I agree that caching keys is a bit of a hassle, but I don’t have an idea at the top of my head how to solve it differently with the same performance. Any ideas?
Off the top of my head I can’t think of anything that would perform as well nor not require the controller->blackboard data coupling at this point.
If some of derived controllers are treated as specific “script instances/templates” like .uc derived AI than my thought of messyness def changes. Its probably all just working with my own paradigm shift of referencing some non-typed blueprint defined data directly in C++.
If I think of any better use situations I’ll def let you know.
Thanks for the quick responses.