Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Hi,

Thanks!

Actually I was not aware of this characteristic of JBT implementation. And so I was not particularly careful about how I implemented my nodes, but strangely I never encountered any issues all along using it for another project and now this one.
If I understand well, multi-threading last only during tick update, so - if I'm right - concurrency problems may arise only between nodes which are children of a parallel node, but still all other parts of the code, including interactions between nodes and engine, are safe. It would explain partly why I didn't experience so much trouble since I don't use much parallel nodes, and if the nodes' execution part contain only condition checks but no writing data, then there is not much to worry (except if there could be concurrency also during node intialization, where most data-writing code occurs, but I'm not sure if this case exists with JBT).

Anyway I guess now I should check all of my nodes again, and be more careful about it in the future. Thank you very much for the tip!

About the reason why I preferred to use JBT over gdx-ai, is simply because I didn't know there were behavior trees in the latter one, so I didn't even compared!
I may check and think about switching to gdx-ai in the future, since a library with much more active development is very valuable, except that I like to have a graphical editor for generating the trees (even if JBT's one is *hum* quite limited), and it seems there isn't already equivalent of this for gdx-ai.

piotr-j, AKA EvilEntity, is working on a graphical editor for gdx-ai behavior trees. It's still a work in progress though, so don't expect too much.

However, I don't think that such an editor is crucial due to the power and simplicity of the DSL. Especially, gdx-ai-1.7.1-SNAPSHOT adds internal subtree references, guards, and dynamic guard selectors that allow you to write complex trees while keeping them pretty human-readable. Here is a sample tree. Unfortunately, the documentation for these new features is still missing, but I'm going to write it soon.

Anyways, if you're happy with JBT there's no real reason to use gdx-ai btrees unless your game has to run on GWT (javascript is single-threaded) or mobile platforms (having a lot of threads might be a serious problem, especially on old devices).

Indeed your DSL is very nice! Even without knowing the syntax yet, it's pretty much readable.

Personnally, I would be ok with writing scripts if I have a text editor with at least some basic static analysis and autocompletion to avoid to struggle with stupid misspellings. With such features, it would be just as good as graphical editor, or at least a good backup method (for example while doing dev work on Android).

Thank you again for all your advises.

There's a Vim Syntax highlighting for gdx-ai behavior tree files on github. I've not tried it though.

Awesome! That's a good start (and it probably can even work on Android with TerminalIDE, which is also a good point for me).

(1 edit)

BTW there's also an open source tool to convert FreeMind files to gdx-ai btree files.
You can find this and other useful links here

(1 edit)

That's good stuff too, thanks! Now I have no excuse to not try gdx-ai :)
Actually I may have a look soon!