Tyler Parker
Nom__XD, 飲ん,诺穆 (They/Them)🐈⬛#ai #chatgpt #claude #gemini #grok #deepseek #alexa #copilot #vibecoding #LLMs #behaviortrees #cnns #transfomers #dnns #supervisedlearning #unsupervisedlearning #reinforcedlearning #aiart #ArtificialInteligence #nlp 🖕🐾
Tearcell GamesThe first ranged enemy is coming along nicely in this #godotengine project! #limboai and #behaviortrees are powerful, but definitely take some learning to get good at.
I think I'm happy with the turning and firing of this monster, and the movement logic seems okay now.
The idle is a bit of a problem. I need seeing the player to break that, and right now it always waits 3 seconds.
StephanAI – Alien: Isolation
Alien: Isolation ist ein Survival-Horror-Game aus dem Jahre 2014. Von einem Entwicklerstudio, das eigentlich vor allem für seine grandiosen Strategietitel, nämlich der Total War-Serie bekannt ist: Creative Assembly. Es ist außerdem ein Spiel, das mit einer ganz besonderen Mechanik im Bereich Künstliche Intelligenz aufwartet, um die Spieler*in ins Schwitzen zu […]
https://blog.stephan-unter.de/ai-alien-isolation/
Limbo of Wonders Meet the marvelous, the mismatched, the perpetually confused. Presenting to you the full cast of the upcoming LimboAI Demo project!
It's time for the... TRAINING MONTAGE! 🎶🤘
LimboAI: Open-source C++ plugin for Godot 4, providing behavior trees and state machines for crafting game AI 🤖💡
https://github.com/limbonaut/limboai
#godotengine #gdextension #gamedev #gameai #limboai #behaviortrees
Revised the Blackboard system in #LimboAI, especially with behavior trees in mind.
Version 1.0-dev3 is out on GitHub and in the Asset Library:
https://github.com/limbonaut/limboai/releases/tag/v1.0-dev3
LimboAI v1.0-dev2 is out now, bringing hot-fixes and improvements. Work towards the 1.0 release is in full swing! 
🔧
It's already on the GitHub and coming soon to Asset Library:
https://github.com/limbonaut/limboai/releases/tag/v1.0-dev2
LimboAI is an open-source C++ plugin for Godot 4 that offers a combination of behavior trees and state machines for crafting your game's AI 🤖💡
https://github.com/limbonaut/limboai
#godotengine #godot4 #gdextension #gameai #behaviortrees #limboai
Made some usability improvements for #LimboAI. It will be much easier to bind behavior parameters to blackboard variables. 🔧
LimboAI is an open-source C++ behavior tree module for Godot Engine 4:
https://github.com/limbonaut/limboai
Tero Keski-ValkamaHow to use #BehaviorTrees to structure complex #LLM #chatbot interactions?
I started writing a small demonstration example here:
https://github.com/keskival/behavior-trees-for-llm-chatbots
In short, event-driven Behavior Trees are very nice when the complexity of the goal-driven interaction process increases. They are modular and self-documenting. They are a very natural way to structure processes which don't follow a clean state machine or a flow diagram.
You might be able to somehow explain this structure to the bot, give it a purpose-built memory to use to keep track of the status of the event and so on, but that becomes an absolute nightmare to maintain, you don't get a clean diagram out of it, and you can't easily make statistics of how the interactions generally go when deployed to production.
It's also questionable whether the chatbot would be able to keep track of it all, or whether it would start aggregating mistakes as the interaction progresses. It's better to use normal software for things it is good at, that is, keeping track of things, and let chatbots focus on things they are good at.
Behavior Trees mitigate and solve those scalability and maintainability challenges.
If you start coding this sort of a system organically, you would end up with a class hierarchy very analogous to a behavior tree anyhow, but it would be custom-built and you wouldn't get nice automatic diagrams out of it to document it.
GitHub - keskival/behavior-trees-for-llm-chatbots: Example: Using Behavior Trees for structuring goal-driven LLM chatbot processes
Example: Using Behavior Trees for structuring goal-driven LLM chatbot processes - GitHub - keskival/behavior-trees-for-llm-chatbots: Example: Using Behavior Trees for structuring goal-driven LLM ch...
Relating to my last post, what is the best way to encode chatbot discourse processes?
In the past, with IBM Watson and similar, the process was pretty strictly defined like this:
1. Interrogate the user to find out which procedure they need.
2. Select procedure, the procedure is a web form which requires a set of inputs from the user. Name, date of reservation, number of people eating, special preferences, those sorts of things.
3. Interrogate the input fields from the user to fill up the form.
4. When the form is done, confirm from the user that it it fine, and then submit it.
Ok, nowadays the chatbots are way more versatile, but for some cases the above workflow is still fine. For more complex use cases we can take inspiration from role-playing games and robotics:
Behavior Trees!
https://shorturl.at/bKWY1
With behavior trees you can compose pretty complex discourse processes without the complexity becoming unmagageable. You can easily isolate the specific process parts while having many simultaneous options open for the chatbot.
It's a very powerful architectural pattern which is very relevant in this context. It's a generalization of the old Watson scheme and can easily encode those types of processes as well.
Note also that while the chatbot processes in the past were designed to constrain and guide the user, as the user was the intelligent element making choices and evaluations, now the chatbot is also an intelligent element and makes choices and evaluations as well. So the process gets conditions and triggers from both the user/client and the chatbot, and also from your runner module and your backend systems.
To be clear, the behavior trees are not running on the user or on the bot, they are run on the runner process. They herd both the user and the bot to conclusions of specific procedures.
Why are behavior trees needed, why not just give the bot the information about what is needed and let it run the process?
First of all the prompt size limits. If you describe your process to the bot, it eats your context limits very quickly. Also, the bot tends to improvise, which further makes you add stuff to the prompts to reduce that.
It is much better to feed the process to the bot in pieces only when needed.
Also, when you need for example something machine readable to produce some complex item, and also something human-readable to describe the same, it often makes sense to first tell the bot to describe in human-readable prose what its evaluation or conclusion is, and then separately tell it to produce the same in a machine-readable form. Then you get the two outputs separately which your runner process combines into a conclusion.
That would be a sequential node in a behavior tree executing through the human-readable output first and then the machine-readable output.
All the #AutoGPT style agents and other processes can also be described as behavior trees. Just feed the chatbot think-command step prompts in sequence while separately managing the backend as per commands.
Plug-ins become pluggable #BehaviorTrees, which might be as simple as describing the end point and handling the related commands.
