As an AI designer and programmer, I don’t know what to say. You’ve basically contradicted 50 years of research and development in artificial intelligence. The main purpose of using Behavior Trees, State Machines, etc., is their versatility and reusability. You create an action or decision and can reuse it in another AI without additional programming. In your solution, creating a new AI involves creating a new enum and duplicating all the code, which we consider an antipattern. I skipped some parts of your video, so sorry if I misunderstood anything.
Reusability is nice when creating large AAA games, but for indies we really don't reuse stuff that much. Usually you would have few different types of enemies and thats it. If some things need to be reused, you have function/macro libraries and components. The point of behavior trees and state trees(at least in unreal) are constraining you to a framework that i think does not scale well and I would say is not even more modular, since in blueprints i can set them up however i want, with the level of reusability i want.
@@polysiens I agree. state machine is simpler for mose use cases. there are excellent plugins on the marketplace doing similar stuff. for complex behaviors and large games, behavior trees, state trees might be more suitable or maybe just mix.
@@lolaswift111Creating a fitting system for your AIs is really important, so big studios will usually have their custom solution or sometimes heavily modify behavior trees. I would say they are mostly used in small and medium sized teams, where you either don't have enough people to create and maintain a custom system in c++, or you don't know any better and you latch onto the first thing unreal gives you.
Man this is such a gold channel for ue information. I appreciate it a lot of things i also found out and to hear you also confirm them makes me more confident in my learning skills
I have never used them, but they seem better to me than behavior trees. On second thought i did briefly tried something similar, and it was ok, but i still liked state transitions a bit more. Some issues i can see with Utility AI is performance, since you have to evaluate all possible actions and rank them. A solution is to either create subsets or smaller groups of behaviors and only evaluate that, or move the logic to c++ and probably get magnitude better performance. Even with that, not sure how many AIs you can have in the scene. One thing i like about state machines is that i can have more intentionality injected into the ai character, since utility ai relies on weights and randomness. Other than that, the system seems good and maybe if i tried it more i would prefer it over other things.
If you want "emergent" behaviour I think Utility AI is the best, the new State Tree system in UE now has Scoring built into it so can be used as the basis for Utility AI.
So this is a little misleading for a few reasons. It can be done, yes, but adding more than a few AI actors would be a nightmare. The sheer amount of debugging that you have to do for every single AI actor vs. 1 task, whether a state or behavior tree, would be horrible. I've seen you also stating you dont reuse code for other AI's, which is counterproductive 2 fold. Firstly, I dont know a single programmer who does not create a library of tools. This idea of recreating everything from scratch constantly is kinda confusing, not going to lie. Production and future production are slowed by this. Secondly, you're giving way to, as I mentioned before, a debugging nightmare. Behavior trees are the simplest, and most indie devs will be able to utilize these to a great degree. Personally, more complex AI needs to be handled with a state tree. Doing what you're doing is like using a screwdriver vs. impact. Sure, you can get it done, but you will be far outpaced by your peers' hands down.
I got a lot of doubt and comments saying that it gets crazy complicated and impossible to do X, so I asked the client I worked for permission to showcase the AI and if they are okay with it, I will create another video 👍 The reason I was talking I did not reuse the code is because on that specific project, the AI enemies were so different that there was not much to reuse. One enemy was walking and attacking with weapons, circling the player, another one was hovering above with dive and fake dive attacks and the third one I mentioned in the video was flying around the characters, doing different type of dive, shooting projectiles and some other stuff. I do have some of my utilities that I bring from project to project(I talk about some of them in my other videos) but they are more abstract. For example, my own way of error handling and asserts. Blueprints and unreal already have so many tools that I never felt like specific stuff I need to create utilities for. The purpose of debug is not code coverage or some number that shows me a comforting number, but to help me understand what is happening with a specific feature or blueprint. With Behavior trees you are forced to use generalized debug tools, regardless if it goes well with the AI you are creating or not. While when I use blueprints, I can add simple debug features that work exactly how I want them to for that feature. This can be visual debuggers, debug widgets, prints, logs or anything else. There is a reason why most(if not all) big studios use custom solutions or heavily modified Behavior Tree. Behavior Tree is a generalized 5/10 solution and it is ok at best. But when you need real shit done you go custom to make the system fit your game not your game fit the system.
Hi, It was more of a casual talk going over my experiences with custom AI solutions vs Behavior Trees(BT). BTs are the standard so i understand why saying i use custom solution and preferring it is a bit spicy 😊 To be fair to me I am not a hobbyist dev making youtube tutorials on the side, I work as an Unreal dev first and make youtube videos sometimes. Would not expect people to be convicted right away from this video ofc, since i did not go practical and in detail. I might at some point, just creating a video where i create the same moderately complex ai in both BTs and custom blueprints is a lot of work.
Honestly I breezed through the video but got the gist pretty quick. I think the problem you assert with behavior trees and state machines are exactly the same issue you are introducing in that you lock yourself into a set methodology of processing information to come out with a specific output. The real truth is that those systems and yours are really the same at their core which is to "latch" into the flow somewhere to produce an output you need to manage "actors". It's just the complexity of these flows, that honestly, you're overthinking it. It really doesn't matter on your projects as long as you get the output you desire in a method you can manage. For more complex projects, it can be behavior trees - for others, state trees, or in your example, a custom built solution. When I was learning programming in general, I got too hung up on "the proper way" instead of learning to just get something done and enjoy it. That's what I like about Unreal in general is that you can get something running really quick with the tools out of box.
What state and behavior trees introduce is a framework to work within and because each ai has a unique ideal structure, there is a lot of bloat and workarounds you have to go through to create the ai. What i have noticed after switching from behavior trees to other custom methods in production is that i have way less code to manage, managing it is easier and more intuitive, because the structure is more fitting to the ai i am making and the scale is way more manageable because of these things. The nuance i would say is that they both don't "latch", custom solution creates appropriate flow for the ai you are making, while using pre designed framework forces the structure of your ai into the existing framework. I think every time i heard a big studio working with unreal talk about their ai solution it is either heavily modified version of behavior trees with c++, or more likely their custom solution that is fitting to their AI needs.
I think this comes back to my comment on unreal trying to be an out of box solution to many which leads to the bloat you mention and your own is a custom lean method which works for you. I personally find using their behavior trees simple and effective without the bloat but rather just some preplanning to effectively use. Regardless of what system you use you’re always going to have some sort of learning curve to use it and code behind it you just need to manage whether it’s theirs or yours. That’s what I like about how the unreal framework is structured is that you can do whatever you want. You’re not forced into anything as it’s all window dressing to get down to the real core functions you need to make things happen.
I think you have all this completely backwards. Patterns like state machines have largely fallen out of favor specifically because they're not more scalable. Every state you add scales the complexity exponentially (mathematically speaking, not me exaggerating). Two states have 2 theoretical transitions between them, 3 states have 6 transitions, 4 states have 12 etc. By transition I mean the logic you need to create somewhere to decide when one state starts and ends. Every state you add increases the complexity and the amount of work by a factor of 2. It's the opposite of being scalable. Even for smaller indie games like you mention, 4 to 6 states is not a high number and yet you're managing tons of rules already. You're just not using behavior trees and other frameworks in an efficient way. The benefit of those is that you can re-use code, and quickly make changes that apply to broad groups of AI. I think you'll quickly start to see how this gets out of hand and new devs following this advice will have a really hard time.
Hi, The reality is that this is not what happens when developing. For example, i don't have a unique transition for each state to another state, i have 1 function for state switch and each state has 1 initialization. Each state then needs to have at least one branch somewhere to go to another state. In the video i mention a griffin boss and that AI was decently complex, so i had about 10 distinct states. I had 1 state change function and that function was called at least 10 times(at least once for each state). So in your calculations this would be 10 states, 10-15 transitions. For them going out of favor, i mean one of their main new ai tools is literally state tree, trying to get the best of behavior trees and state machines. If we now have take a peek at the behavior trees, each branch is kind of like a state, for more complex stuff you need more sub branches, selectors and sequences which become hard to work with really quick.
I don't entirely agree with this. State machines hold favor for more complex AI. Behavior trees are nice, but they are a little more limited and can only handle basic AI implementation.
@polysiens It sounds like you've made up your mind and you're going to defend it any way possible no matter what you hear. If you want to ignore the work done over the last 25 years by actual AI programmers that have completed and shipped games, that's on you. Sometimes things are the way they are for a reason, and that can't be argued or explained fully in a TH-cam comment. Not everything today has to be reinvented but the Internet has conditioned all of us that "everything you know is wrong!" because engagement matters more than nuance and actual research to see why behavior trees, Utility AI and GOAP are more scalable than state machines. For anyone that's actually interested in the theory behind this, look up Game AI Pro, it's a free series of books from game developers that explains the benefits of each approach.
As an AI designer and programmer, I don’t know what to say. You’ve basically contradicted 50 years of research and development in artificial intelligence. The main purpose of using Behavior Trees, State Machines, etc., is their versatility and reusability. You create an action or decision and can reuse it in another AI without additional programming.
In your solution, creating a new AI involves creating a new enum and duplicating all the code, which we consider an antipattern.
I skipped some parts of your video, so sorry if I misunderstood anything.
Reusability is nice when creating large AAA games, but for indies we really don't reuse stuff that much. Usually you would have few different types of enemies and thats it. If some things need to be reused, you have function/macro libraries and components. The point of behavior trees and state trees(at least in unreal) are constraining you to a framework that i think does not scale well and I would say is not even more modular, since in blueprints i can set them up however i want, with the level of reusability i want.
@@polysiens I agree. state machine is simpler for mose use cases. there are excellent plugins on the marketplace doing similar stuff. for complex behaviors and large games, behavior trees, state trees might be more suitable or maybe just mix.
@@lolaswift111Creating a fitting system for your AIs is really important, so big studios will usually have their custom solution or sometimes heavily modify behavior trees. I would say they are mostly used in small and medium sized teams, where you either don't have enough people to create and maintain a custom system in c++, or you don't know any better and you latch onto the first thing unreal gives you.
Man this is such a gold channel for ue information. I appreciate it a lot of things i also found out and to hear you also confirm them makes me more confident in my learning skills
Great, glad that you found it helpful 👍
knew this would be controversal lol
What do you think of Utility AI? I think it's great for implementing very good AI
I have never used them, but they seem better to me than behavior trees. On second thought i did briefly tried something similar, and it was ok, but i still liked state transitions a bit more. Some issues i can see with Utility AI is performance, since you have to evaluate all possible actions and rank them. A solution is to either create subsets or smaller groups of behaviors and only evaluate that, or move the logic to c++ and probably get magnitude better performance. Even with that, not sure how many AIs you can have in the scene. One thing i like about state machines is that i can have more intentionality injected into the ai character, since utility ai relies on weights and randomness. Other than that, the system seems good and maybe if i tried it more i would prefer it over other things.
If you want "emergent" behaviour I think Utility AI is the best, the new State Tree system in UE now has Scoring built into it so can be used as the basis for Utility AI.
@@shannenmr im using it for last few months
So this is a little misleading for a few reasons. It can be done, yes, but adding more than a few AI actors would be a nightmare. The sheer amount of debugging that you have to do for every single AI actor vs. 1 task, whether a state or behavior tree, would be horrible. I've seen you also stating you dont reuse code for other AI's, which is counterproductive 2 fold. Firstly, I dont know a single programmer who does not create a library of tools. This idea of recreating everything from scratch constantly is kinda confusing, not going to lie. Production and future production are slowed by this. Secondly, you're giving way to, as I mentioned before, a debugging nightmare. Behavior trees are the simplest, and most indie devs will be able to utilize these to a great degree. Personally, more complex AI needs to be handled with a state tree. Doing what you're doing is like using a screwdriver vs. impact. Sure, you can get it done, but you will be far outpaced by your peers' hands down.
I got a lot of doubt and comments saying that it gets crazy complicated and impossible to do X, so I asked the client I worked for permission to showcase the AI and if they are okay with it, I will create another video 👍
The reason I was talking I did not reuse the code is because on that specific project, the AI enemies were so different that there was not much to reuse. One enemy was walking and attacking with weapons, circling the player, another one was hovering above with dive and fake dive attacks and the third one I mentioned in the video was flying around the characters, doing different type of dive, shooting projectiles and some other stuff.
I do have some of my utilities that I bring from project to project(I talk about some of them in my other videos) but they are more abstract. For example, my own way of error handling and asserts.
Blueprints and unreal already have so many tools that I never felt like specific stuff I need to create utilities for.
The purpose of debug is not code coverage or some number that shows me a comforting number, but to help me understand what is happening with a specific feature or blueprint. With Behavior trees you are forced to use generalized debug tools, regardless if it goes well with the AI you are creating or not. While when I use blueprints, I can add simple debug features that work exactly how I want them to for that feature. This can be visual debuggers, debug widgets, prints, logs or anything else.
There is a reason why most(if not all) big studios use custom solutions or heavily modified Behavior Tree. Behavior Tree is a generalized 5/10 solution and it is ok at best. But when you need real shit done you go custom to make the system fit your game not your game fit the system.
yeah i dont know if im sold here...... where the proof of performance or anything i trust Unreal Programers more than random youtube video.
Hi, It was more of a casual talk going over my experiences with custom AI solutions vs Behavior Trees(BT). BTs are the standard so i understand why saying i use custom solution and preferring it is a bit spicy 😊
To be fair to me I am not a hobbyist dev making youtube tutorials on the side, I work as an Unreal dev first and make youtube videos sometimes. Would not expect people to be convicted right away from this video ofc, since i did not go practical and in detail. I might at some point, just creating a video where i create the same moderately complex ai in both BTs and custom blueprints is a lot of work.
Honestly I breezed through the video but got the gist pretty quick. I think the problem you assert with behavior trees and state machines are exactly the same issue you are introducing in that you lock yourself into a set methodology of processing information to come out with a specific output. The real truth is that those systems and yours are really the same at their core which is to "latch" into the flow somewhere to produce an output you need to manage "actors". It's just the complexity of these flows, that honestly, you're overthinking it. It really doesn't matter on your projects as long as you get the output you desire in a method you can manage. For more complex projects, it can be behavior trees - for others, state trees, or in your example, a custom built solution. When I was learning programming in general, I got too hung up on "the proper way" instead of learning to just get something done and enjoy it. That's what I like about Unreal in general is that you can get something running really quick with the tools out of box.
What state and behavior trees introduce is a framework to work within and because each ai has a unique ideal structure, there is a lot of bloat and workarounds you have to go through to create the ai. What i have noticed after switching from behavior trees to other custom methods in production is that i have way less code to manage, managing it is easier and more intuitive, because the structure is more fitting to the ai i am making and the scale is way more manageable because of these things. The nuance i would say is that they both don't "latch", custom solution creates appropriate flow for the ai you are making, while using pre designed framework forces the structure of your ai into the existing framework. I think every time i heard a big studio working with unreal talk about their ai solution it is either heavily modified version of behavior trees with c++, or more likely their custom solution that is fitting to their AI needs.
I think this comes back to my comment on unreal trying to be an out of box solution to many which leads to the bloat you mention and your own is a custom lean method which works for you.
I personally find using their behavior trees simple and effective without the bloat but rather just some preplanning to effectively use.
Regardless of what system you use you’re always going to have some sort of learning curve to use it and code behind it you just need to manage whether it’s theirs or yours. That’s what I like about how the unreal framework is structured is that you can do whatever you want. You’re not forced into anything as it’s all window dressing to get down to the real core functions you need to make things happen.
I think you have all this completely backwards. Patterns like state machines have largely fallen out of favor specifically because they're not more scalable. Every state you add scales the complexity exponentially (mathematically speaking, not me exaggerating). Two states have 2 theoretical transitions between them, 3 states have 6 transitions, 4 states have 12 etc. By transition I mean the logic you need to create somewhere to decide when one state starts and ends. Every state you add increases the complexity and the amount of work by a factor of 2. It's the opposite of being scalable. Even for smaller indie games like you mention, 4 to 6 states is not a high number and yet you're managing tons of rules already. You're just not using behavior trees and other frameworks in an efficient way. The benefit of those is that you can re-use code, and quickly make changes that apply to broad groups of AI. I think you'll quickly start to see how this gets out of hand and new devs following this advice will have a really hard time.
Hi, The reality is that this is not what happens when developing. For example, i don't have a unique transition for each state to another state, i have 1 function for state switch and each state has 1 initialization. Each state then needs to have at least one branch somewhere to go to another state. In the video i mention a griffin boss and that AI was decently complex, so i had about 10 distinct states. I had 1 state change function and that function was called at least 10 times(at least once for each state). So in your calculations this would be 10 states, 10-15 transitions. For them going out of favor, i mean one of their main new ai tools is literally state tree, trying to get the best of behavior trees and state machines. If we now have take a peek at the behavior trees, each branch is kind of like a state, for more complex stuff you need more sub branches, selectors and sequences which become hard to work with really quick.
I don't entirely agree with this. State machines hold favor for more complex AI. Behavior trees are nice, but they are a little more limited and can only handle basic AI implementation.
@polysiens It sounds like you've made up your mind and you're going to defend it any way possible no matter what you hear. If you want to ignore the work done over the last 25 years by actual AI programmers that have completed and shipped games, that's on you. Sometimes things are the way they are for a reason, and that can't be argued or explained fully in a TH-cam comment. Not everything today has to be reinvented but the Internet has conditioned all of us that "everything you know is wrong!" because engagement matters more than nuance and actual research to see why behavior trees, Utility AI and GOAP are more scalable than state machines. For anyone that's actually interested in the theory behind this, look up Game AI Pro, it's a free series of books from game developers that explains the benefits of each approach.