I was wondering… is there any point in using them when we have Skookum? I noticed that decorators are not available in Skookum, so I wondered what the Skookum devs think about BTs. Does Skookum make them obsolete?
I no longer use behavior trees since discovering skookum. I think visual trees are much harder to understand than code.
Aren’t decorators just conditionals that determine when a branch should be entered / exited? So in skookum those would just be your conditionals on when coroutines end or start etc.
Behavior trees aren’t visual, they are a mathematical model very much rooted in computer science and often used for robotics and AI. The behavior tree in UE4 just happens to be visual but you could create your own purely code implementation. Would probably do that in C++ though and then maybe just use for the various tasks.
I don’t really see how behavior trees could be replaced with . One is a scripting language, the other is a language-independent programming concept meant to make very complex tasks simpler by breaking them down into lots of smaller tasks.
Of course you may choose to code AI without behavior trees, should be fine for simple stuff and with concurrency it may be cleaner than in other languages. You’ll still run into issues when stuff gets too complex I think. There’s a reason that eventually the world settled on finite state machines and then replaced that with behavior trees which seems to be state of the art for AI today.
I am fully aware visual has nothing to do with it. I have used other behavior trees libraries in code…Having used visual and code behaivior trees I still find skookum superior and have not run into a situation where I would go back. Not saying that day wont come but so far I have AI with many levels of nested coroutines (branches) working great.
Yeah we had this conversation in the UE4 forum once, didn’t we?
I could be completely wrong and just not thinking out of the box enough! Interested to hear what the team has to to say about it, as they often tout what a good fit is for AI.
Ah opps did not realize that was you. I was like haven’t i had this argument before lol.
I believe that is a great tool to implement behavior trees in both an informal and more rigorous sense.
To quote Roy Batty, in big open world games with really sophisticated SkookumScript logic:
I’ve seen things you people wouldn’t believe.
It still takes more effort than we would like so we have plans for several behavior tree like features that will be native to SkookumScript.
We are currently focusing on the core language, core library, IDE and UE4 integration features of SkookumScript.
Once all those are present and stabilized we have a lot more tech in the area of AI planned. Even without those future features, AI behavior should be much easier to develop fully or in tandem with SkookumScript.
I find that things like behaviour trees, state machines, etc., can be challenged with new ideas. Skookum is not merely a scripting language, it implements coroutines in novel ways that allow us to do things with much less complexity. The reason I asked the question is because, behaviour trees seem complex now, compared to Skookum. Much like BTs seemed simple versus state machines, Skookum seems simple vs BTs. Newer abstractions can often make older models of abstraction… less abstract, lol. In other words, I do not really see a point in using Unreal’s BT anymore and in comparison, it seems like Skookum is far more simple(to a programmer). I guess computer science wins when things get simpler
One other thing, I really wonder why the world settles on ideas like FSMs vs coroutines. Example: https://youtu.be/_fu0gx-xseY?t=120 (look at 2:00 if it did not link correctly)
I see things like this all the time in computer science and to a far lesser extent, mathematics. There is a gold mine of good ideas from the past and, oddly enough, the most popular language today is Java. The Java language is a great example of popular ideas that are really not that good. We should never settle on what everyone else is settling on or accept their ideas as the “good ideas”, simply because of popularity.
I think that FSM in particular have a very rich history outside of computer science. For instance in Digital Design where you’re dealing directly with gate logic (AND/OR). You’ve essentially got a number of output states where your signal is either 0 or 1 (technically 3v, 5v or whatever your rails are) and you transition between states based on input values.
This type of design maps directly to a FSM. You might even say that FSMs are the language of digital logic. From a FSM it’s easy to map your state transition logic to a karnaugh map, which then helps minimize the logic so you end up using less physical gates/less chips. I don’t think this application of FSMs will ever be replaced. This is probably closer to the origins of the FSM and it’s easy to see why programmers making computers in the early days ended up using FSMs. I mean, back when you could fully understand a computer from the transistor level through the software stack, programming was more like designing a digital circuit.
In the gaming world, the limitations of FSM for AI are pretty well documented but it doesn’t mean FSMs don’t still have their place as a simple concept for mapping inputs to states. Also I think FSM vs coroutines is like apples vs toilet seats, they aren’t in the same class. You could implement a FSM using coroutines for instance.
Sure, there can be new ideas, but replacing an FSM or behavior tree with a coroutine sounds rather like replacing a design pattern with an if-statement, or a car with a steering wheel. It’s just an altogether strange comparison.
Yes, I agree with all your points.
SkookumScript can make it easier to implement various design paradigms and it may help open up new techniques that haven’t been used yet. In the future we also plan to make implementations of finite state machines and behavior trees easier - maybe even to the level where they are essentially natively supported.
I’m a big believer in mixing tools and techniques. SkookumScript is designed to work with other systems such as C++, UE4 Blueprints and the UE4 editor. It also readily supports mixed design paradigms. There is no need for a one tool or technique to rule them all - it is nice to have all sorts of tools in your virtual tool box.
Quote from Paul Graham:
“This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about “patterns”. I wonder if these patterns are not sometimes evidence of case ©, the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough - often that I’m generating by hand the expansions of some macro that I need to write.”
This discussion came up in google when I was looking for alternatives to BT’s in UE4, so I thought I’d add a comment about BT’s vs. FSMs. I’ve got a simple worker class which sleeps, produces some kind of resource, and stores the resource. As side activities, it will eat, relax, and fight when enemies come into the town. Each of those activities is discrete in that both the animations and the effects of the activity are self-contained. That means a state machine is by far the simplest way to implement the worker’s AI.
The problem I have with BT’s in UE is that transitioning between states and storing the data for a state in the black board was way too complicated. For one thing, info related to the worker’s activity should be stored in the worker’s class, not in the black board. It was also a bit brittle because it is not easy to generalize tasks. I found myself creating separate tasks for each class being used in the worker AI, and that kind of complexity leads to bugs, not to mention spaghetti blueprints.
I’ve been programming for nearly 40 years, and there are 2 things I have learned. 1) trust the metalanguage I have created in my head to design things efficiently and 2) use the pattern which makes the code as simple as possible. Like Graham says above, if you see lots repetition of nearly identical patterns, you haven’t figured out the abstraction which will simplify things. FSM’s work for simple AI. I’m still not convinced that UE4’s BT’s are superior for complex AI, but I am completely certain that they add too much complexity for simple problems. So my take on this discussion is not which is better theoretically but which produces simple solutions, which in turn means it will be faster to code and less prone to bugs arising from nondeterministic usage patterns.
To me, SkookumScript’s ability to add functionality to a class and to create easily portable code containers with coroutines and closures make it superior for doing FSM-based AI vs. UE4’s system.