Why magic strings everywhere?

[FelixSeKett]

Why is there no option to set the value of a BBParam or, alternatively, to reference a blackboard variable by BBParam instead of a magic string? To be honest: Right now, the maintenance of the blackboards in a State Machine that uses BTState is a horrendous effort, because the whole system relies on magic strings. Changing one variable name results in touching every bound variable there is. Not to mention changing simple int values via code. It seems, it won't get much easier than this:

func _decrease_indicator() -> void:
	var indicator_var: BBInt = blackboard.get_var(&"indicator")
	var indicator: int = indicator_var.get_value(agent, blackboard)
	blackboard.set_var(indicator_var.variable, indicator - 1)

The first line is highly error-prone because of the magic string and the forced type cast. So why is everyone so keen about using strings? I don't get it.

[limbonaut]

If you have a constructive technical proposal related to strings considering Godot limitations, we can have a discussion.
I saw you storing BBInt on the blackboard. You don’t need to do that. BBParam types are for flexibility in tasks to either give a value or bind it to a blackboard variable. They should be used as @export parameters in tasks, not stored on the blackboard. Just store/retrieve int directly.

[FelixSeKett]

First of all, I want to express my gratitude and respect for all the work you and so many other developers do for the community by developing such elaborate functionality and sharing it with the world. I admire what you do and, for what it's worth, always act on the assumption that I don't understand as much as others do when I’m complaining.

Still, I get really salty when I feel that people defend weird, counterintuitive approaches that contradict proven paradigms — and then won’t take the time to have a proper discussion about it. So please excuse the furious tone of the following lines. It’s just that after years of reaching out to the creators and community through Discord servers, forums, social media, email, and whatnot, no one seems to be able or willing to address my issues, so I always end up being left behind with my questions unanswered.

So yes, I have a constructive technical proposal: just start using Resources already to encapsulate raw data so we don’t have to remember where we used, for example, strings in code — or worse, in the inspector!

Our studio uses such Resource containers — a simple StringBox, for example — all the time to store and reference certain values. For instance, your events, which are used for transitions and event handlers, could easily use such Resources instead of magic strings. One could simply create the corresponding box or container or whatever, store it in the file system, and reference it on both ends — at (A) dispatching them and (B) registering transitions or event handlers. If you need to change something, you won’t have to click your way through engine and code, always hoping you didn’t miss anything. I honestly don’t understand why the whole game dev world is so obsessed with what is elsewhere considered one of the worst habits programmers can develop.

Concerning the blackboard variables: you are right — I don’t need to get a BBInt out of my blackboard. I export it like it’s written in your docs and assign the proper blackboard variable via the inspector. Nevertheless, when I want to change its value via code, I still have to do the following:

var indicator_var: BBInt # assigned via the inspector

func _decrease_indicator() -> void:
	var indicator: int = indicator_var.get_value(agent, blackboard)
	# at this point I would intuitively want to change the value of the BBInt, but instead I have to:
	blackboard.set_var(indicator_var.variable, indicator - 1)

All of this for a simple indicator += 1. And all of this just for the illusive luxury of doing your string magic everywhere. Please tell me I’m wrong and show me how I misunderstood the whole system.

To be honest, I genuinely don’t understand the plugin architecture in general. Everything seems so cumbersome and counterintuitive. Why is there a whole string validation system on top of an overcomplicated blackboard layer that could simply be replaced by a blackboard Resource storing simple, type-safe data — or by the aforementioned data container Resources that could be accessed from anywhere?

[FelixSeKett]

I should add: I am accessing the Blackboard from a script extending LimboHSM. The idea is to respond to entering states like Walk, Idle, etc. by applying certain values to the blackboard. For example, every time a state transitions to the Idle state, I want to apply the idle animation by changing the corresponding Blackboard variable to true. I did this in the BTStates Behavior Trees before, but figured: I shouldn't apply the animation on every occasion any Behavior Tree evaluates the Blackboard and causes the State Machine to switch back to the Idle State (i,e. from Walk, Attack or Jump State), but instead, the animation should be applied in a centralized manner by simply reacting to entering the Idle State. So I wanted my LimboHSM to react to the corresponding signal and change the idle_animation variable in the Blackboard on Idle State entered to true.

[limbonaut]

Still, I get really salty when I feel that people defend weird, counterintuitive approaches that contradict proven paradigms — and then won’t take the time to have a proper discussion about it. So please excuse the furious tone of the following lines.

Also why do you think I defend anything here? Prove your concept with code or at least some detailed specs. If it's good, it's gonna be hard not to include it. Learn about open-source, and how to contribute, and you'll have less reasons to complain.

[limbonaut]

The blackboard system is completely optional. Feel free to ignore it in its entirety. It's designed to be lightweight in memory and computation. It's dynamic nature is due to a simple reality that AI needs to adapt to other shifting structures. The same BT can participate in different configurations, at one point it's part of a HSM, in a different agent, it's a standalone tree in a BTPlayer. If you have good ideas how to marry complexity of different structures with reusability of behavior trees, great! Consider making a proof-of-concept PR and I can consider it for inclusion in 2.0, seeing that it's most likely a breaking change.

I understand that maybe in your project using Resource for simple value containers is an acceptable tradeoff. Do that! By no means I don't push the blackboard system on users and make it a must-use. Use it, or leave it, it's your choice. You can even roll your own blackboard system, ignoring the existing one. Make a subclass for BTTask and do that.