This is a really good deep dive into Behavior Trees and its limitations. Could you please do the 3 alternative options. It would be greatly appreciated. Thank you!
One option I like is Utility AI (also called utility system) it’s super simple to understand and implement, which lets you quickly prototype with it and to see if it fits your needs. Lots of articles online about it, and plenty of CZcams videos.
As a solo dev I'm always really hard on myself about the jank in my games, your last segment made me so happy to hear. I'll try to be nicer to myself about the jank going forward. Thanks for the video!
Pro AI Dev here. It's also worth looking into "Utility Theory". It's a numerical method rather than a decision based method. The general idea is that you give all your options (attack, take cover, run away etc.) a numerical score based on information that the AI has about its environment, and you choose the action with the highest score. For example, the attack score may be based on a few things like line of sight, distance, to the player, and enemy health. As health goes down, the run away score increases (and maybe attack decreases), eventually overtaking the attack score. I think it's a technique with potential and we could even see it combined with behavior trees to make them more versatile.
I wrote a game based on utility theory back in the days of DOS, and it worked very well. The AI tended to do the optimal thing, according to weights I provided. I think that when I do it again, I'll add the option of keeping the current goal, as a weighted option. Depending on the character, ignoring new stimuli would give the AI more realistic behavior. Perhaps including it in emotional weights, that would change weights based on moods.
isnt this sort of implemented with the um fairly new EQS(environmental queue system)? Prettty sure it makes the AI take decisions based on 'scores' edit: not to take anything away from the OP, i think a score system is a very solid way of handling ai, just thought id mention EQS
@Rundra No utility is for decision making, not doing actions. I have AI boars with utility AI that uses curves. Here are possible actions based on "needs of the animal". Order matters as if 2 needs get same score first in list is priority. - Drink - Eat - Sleep - Flee - Attack - Idle
The light "stutter" between each action is to me a classic Behavior tree thing. It doesn't always happen, but it happens often enough for me to recognise it... Okay, let's watch therest of the video now XD
Keep in mind that a behavior tree can nest other trees, you're not limited to the 3 actions you use as an example that can be needed in a totally different tree that runs it as a sub behavior. I think with behavior tree your milage will go as far as how well you understand custom decorators and events, and how well you understand selector/sequence.
It's intriguingly ironic how we strive to program artificial intelligence to act and make decisions in an ideal manner, yet we, as humans, often falter in our own decision-making. Take, for instance, my current predicament: here I am, composing this CZcams comment, when the more sensible action would be preparing a cup of coffee.
Hi, nice video! I also like the GDC talk called "AI Arborist: Proper Cultivation and Care for Your Behavior Trees", which make some strong points on when and why use BTs.
I got it right first time because the animation transition for the BT was very sudden and the character snapped in place. Which is what happens when you play an anim montage directly from the BT, since there's no blend in and out in that case.
I use Unreal and I'm a programmer and I gave behavior tree a chance, but I really didnt like it. It quickly becomes way too rigid for a complex AI, like just manageing all the things that needs to be canceled, because something like getting hit happened or there's a special even or something and the AI shouldnt mess with the player while it happens etc. Oh this needs to be checked ? Ok I need to add that thing everywhere in my graph. Personally I don't see anything that can't be done with just statemachines, it really depends on the game I'm making, but I generally end up with some kind of hierarchical statemachine, where I would swap larger "behaviors" for like "I'm fighting the player" and in there there's another statemachine and then I'm pushing "actions" like "move there" and those action can be canceled or completed. I do that in C++ tho, generally custom stuff I'm creating depending of my needs. My understanding on the real reason behavior tress are a thing is to empower non programmers to be able to do something about AI, which I guess CAN happen, but I rarely (read never, but there must be someone out there) seen a non-programmer have both the will to tweak AI and the capacity to do so. AI is one of the weird element of a "real time software", where you don't necessarily do things sequentially of "I'm opening a menu, clicking a button, this thing is executed", no it's ALWAYS changing, stuff need to be interruptible at any time, but also not feel weird like it changes every frame, so it's a very different way of thinking, things are always changing, things are not certain, you need to always evaluate what is going on and what should be done about it. So AI logic would be more like "I need to be in range of this object to interact with it, I'm not in range, so right now I'll move toward the object and check back next frame.". It's a very different way of thinking about "logic" that needs some getting used to, so you either have a very technical designer who's passionate about that or... a programmer and imo the hard part of game AI is not figuring out what the AI should feel like, but how it should be done so it feels like that. Woh, sorry for the wall of text haha
First paragraph hits hard. As a non-coder that understands the basics beyond most yt tutorial content I really struggled as the BT I was working on got large and the constant checking that was being done on the character needing to be fed back to the BT. It made everything so much simpler.
@@blackshinobi956 Absolutely useful to think about as a way for "non-programmers" to work on AI - but those "non-programmers" are often still programmer... (hear me out) While working on NPCs in a team, someone says "NPC's need to surrender" or whatever, instead of programming in that whole feature, I can ask "What do you need?" and program in an action node to drop the currently held item. Now some other developer can use the BT to trigger the surrender, play a surrendering animation, check if they're armed and drop the weapon then put their hands up. That "feature" needs conditions like checking if they're armed and playing different animations, but I avoid hard-coding in any assumptions about what's needed to "surrender" into the codebase. And that "drop item" node is probably useful in a lot of other areas, too. So I can do a small piece of work, an hour later I've tested and I'm finished - I don't have to test the NPC behaviours, get the timing and check animations look right. Someone else can then "implement the feature" as a separate task to mine. Helps us collaborate, helps us do larger tasks as a series of small tasks, helps us avoid needing to plan ahead too far. ... and then the project manager sees the feature and says "Wait, that's not what I was thinking" because communication is always a larger issue than the actual programming. They want the NPC to do something else, say, raise their hands with the weapon above the head and only drop the weapon when instructed. That's fine, we don't have to change code, it's very quick to draw a few different connections in our BT and give them that. Even better, it lets us _implement the feature_ without going back to the project manager with a thousand questions. "How should they hold the weapon? When should they release it? How quickly?" because... we can just build it, wave them over to the computer, show them, then get that feedback and make the changes on the spot. So it's often still programmers using the BT, but it's still valuable for them to have that separation between "programming" tasks, and "I shouldn't need to program to do these things" tasks.
Hey I have experience with the state tree plugin. I can tell you right now it's super flexible, easier to use than BTs, and very performant. You can use several state tree components on one actor. Tbh they're like suped up regular components lol.
One thing that you may be missing out on is the existence of 'Planners' for actualisation (and can feed back into decision making), it's a whole area in of itself but there's various approaches (Hierarchical/Temporal/Classic) and various implementations of these things into systems like STRIPS. STRIPS was famously used for the AI in the FEAR games. Roughly, they work out the plan of actions to perform after an intention is known and are basically a form of logical interaction pathfinding.
A common problem is thinking that a behavior tree can do two different types of things, like in your example move and shoot. Another common problem is not knowing which priority is higher and placing them in any way. When you leave that way of thinking behind, everything goes better.
I explicitly use GOAP with a machine learning framework, even on the simplest game. But for real, behavior trees are great when your game aligns with them. I made a space flight shooter and used only BP AI because it was pretty simple, but a god game simulation needs way more power, and tools like behavior trees and GOAP are good for those.
since you asked... I noticed the npc on the right do a look at enemy as it identified its target. The sliding feet where what called my attention to the fact that the right was behavior tree. 7:40 great words to live by. I've got a question I hope could get an answer from you or a fellow viewer... Which tutorial series would you recommend to learn how to build a "complex" AI system? Also do you have a fav tut series for using behavior trees and maybe one for just using blueprints or something of a hybrid? I only scratched the surface of AI and am still trying to figure out the dos and don'ts. I've talked with a few pros and the answer I get is "just program it yourself" or "just use blueprint". I fear learning AI system will be like everything else in game dev where you figure out the best approach only after having gone down all the wrong roads first. Thanks for your help ahead of time and happy deving everyone!
Just came across your channel. As an Unreal environment artist, with an interest in adding loads of functionality through BP, I appreciate your content and especially the research undertaken in this particular video. Keep it up!
Have you seen logic driver plugin? Its like behavior trees but for everything and you can code straight inside of the states. No need to create blueprint assets
I really liked the point about how Behavior Trees being a good tool for reactive AI. This wasn't a framing I'd heard yet, and it's really kicked off some thoughts in my head. Great video!
Please do a video on state trees. I'm trying to learn that myself at the moment. Looking into using either state trees or behavior trees for a in depth dialog system.
I wish I could find the link to a GDC talk by one of the Gears of War devs, where they showed part of their AI behaviour. It was insane, Blueprint Hell level of insane. I look at it like this, you do the easiest solution that you can at the time and move up the ladder of complexity as you need to. Having BP driven behaviour is fine for simple AI, same as using BTs is fine. Being savvy about your code is the key and if you can't get it done with those tools, you may need to delve into cpp and do it there which is [or at least used to be] recommended for AI things especially EQS.
Maybe I’m missing something, but the “special regroup” is the exact scenario behavior trees make trivial? The goal of behavior trees is to allow you to set the priority of actions. I do not use Unreal so, maybe their implementation is flawed, but it seems unlikely.
Fair critique, I may have explained that part poorly. Section 3.3 in Bobby's report explains it much better than I could have >> takinginitiative.files.wordpress.com/2020/01/behaviortrees_breaking-the-cycle-of-misuse.pdf
@@blackshinobi956 I took some time to read it. The paper discusses several BT implementations with that section referencing maybe the Unreal implementation (not sure how there’s work)? You also mention Unreal at some point, so if your critique is on Unreal’s BT, then I think it’s valid but it is not a downfall of BTs as a whole.
There's one thing I've learned from game development is iteration. You should make the thing work, and then iterate over time if you add more stuff to it. For example, if you need to make a weapon system, attach it to the player arm. However, further down the line, you need to have more weapons, iterate on the weapon so your designers can add as much weapons as they need. Also, game design document.
Thanks for this video, I've been working with both Blueprints and Behavior trees for the last couple weeks and was constanly wondering If I chose the correct way of doing stuff since I've ran into priority issues like you described in this video. Videos like these really help me understand the ins and outs of what i'm working with, really happy your vid showed up in my feed, will subscribe and checkout your other videos.
I haven't touched them in a while but the one time i've tried using behavior trees on a project (for FPS enemies) they quickly became very awkward to use. It's been a while so i cant remember the exact issues i had with it. It was enemies that could shoot the player or take cover similarly to the ones you mentioned in the video. As soon as their actions started interacting with eachother it quickly became a mess, stuff like having one action instantly interrupt another became very complicated and had me reach for weird workarounds every time. Blackboards and decorators/whatever the tree uses for decisions didnt make much sense to me neither because its all stuff you can do easier/more intuitively in blueprints. Idk, maybe i just didnt spend enough time on it but it seems weird that you'd need to learn this obtuse and unintuitive system, especially when once i remade that same AI with blueprints it started actually making sense and working how it's supposed to.
I've been about people that trees are the "right way to do it" but why? Something something finite states but what advantage does that give? What if i want the ai to take more than one action at once? What if i want it to decide movement and aiming/actions differently? Anyway rant's over, this really reminded me of the frustration i felt trying to learn this system (with tutorials from a series that was great overall so im assuming its not because i was taught wrong)
Great video. I personally hate the behavior tree system, because it feels like it doesn't belong with the rest of the UE5 tools. It has always felt overly complex to me, and I prefer to just write the AI in the BP Event graph. You brought some new perspectives I hadn't previously considered.
Thanks for this video! I wasn't always sure how and why I could or should use behavior trees, and though I need to learn all the functionality more and use them when necessary in my games, it's good to know they aren't the only option. I will probably come back to this down the road to reference!
my game revolves around an AI partner that follows you and you solve puzzles together. So far I've been able to implement everything I want with just blueprints, using basic stuff like functions, timer by events, branches, bools, and looping gates
Dude this is an interesting subject. Yesterday night I've made a prototype for an AI companion that has no behaviour tree but reacts to the world and goes around through its sensing abilities and that drives the player controller like a player would do. It's been way easier for giving it a simple behaviour rather than messing with the behaviour tree
Hey, fellow indie dev here. In the intro, I could tell which was the behavior tree because of the immediate turn toward the target upon detection. While the blueprint can do that, it would take a little more effort than it's worth just to add in that small detail.
I don't dev, but I like watching explanations of the technical stuff like this. AI fascinates me, beyond point-shoot or the recent 'lets insert a chatbot into the kitchen sink' trend. It's good to have some level of knowledge of how these things work. I can't wait until we finally get the materials breakthrough to allow a new leap in processor power - I imagine there's a tonne of stuff that devs would love to try to code but is just not all that feasible given the current resources.
I'm a big fan of GOAP and FSMs, but I also code & don't rely on prebuilt node based stuff because I prefer having full control and knowing exactly what's going on "under the hood" at all times.
Very insightful! There definitely will never be a best way, but only arguably better ways to handle complex systems like this. Have you had a chance to dabble in the state trees system? I would love to hear if it has influenced your preference.
Im not someone who has watched you before, but i wanted to let you know, i liked this video a lot. I dont see much gamedev content in this fashion, discussing the implementation methodologies on a relatively deep level, however, not going so granular that im lost in the specifics of what your talking about. I liked this format a lot, would love to see more like this :) Imma subscribe, loved the video!
In UE and probably many other coding / blueprint software, there’s so many ways to do a specific thing. I’m a solo dev hobbyist who is more comfortable with plain and basic blueprints. I’m personally more comfortable with doing something like creating some sort of tracing or collision to detect the player then having the enemybp move the enemy towards the player when detected, then playing one of few attack animations if the player is close enough. I don’t think there’s a right or wrong way, just an effective or not so effective way, and with time your methods could evolve into more effective ways but as long as you can make your imagination come to life in the engine I think that’s what matters most.
Any chance you can elaborate on “Decision Tree” when you were listing down the alternatives? Is that just hardcoded Blueprints decisions? What do you mean by that?
Spotting the Behaviour Tree is EASY! The Blueprint one stops when it sees the enemy, then turns and moves towards the enemy at the same time. The Behaviour Tree one uses what appears to be the built-in task for turning toward the enemy, and it looks janky as crap. Much like everything in Unreal Engine, it's divisive because some people don't understand how customizable it is, and think it should just do exactly what they want out of the box. Then when it doesn't, thinks that doing all the ground work themselves makes more sense.
very nice video, i had been thinking about diving into behaviour trees but BP seems functional enough for the level of enemy intelligence my games need. thanks for sharing, subbed :D
Behavior trees are great because they are flexible and easily repurposed, the sequence of events is easily tweaked and altered in the BT editor. It's super useful imo
The BT version showed that the AI found the player using AI perception (Sight erception) and turned toward the player as soon as the sight trace hit the player. The BP one has the AI walk to a point, then move to player and attack when in range.
@blackshinobi956 😁🤓😅 hehe, been using UE for +6 years now. But I don't code or make logic my self. I only know enough about it do understand it. To lazy to work with it my self hahaha
What you mean not combining those 3 layers?! The AI need to have all 3 to be a good AI. The sense using AI perception for instance. Then Decide what to do based on the information they sense or get from EQS and other variables they have been given like for instance amount of ammo they have left, weapon type, health amount, healing options/possibility, environment they are in, amount of cover available/ or if cover is possible, and also by that AI actor's class (For instance, f that AI is a scout, then it might run back to "base" or other close by AI to report your position and presence.) If that AI is scav, it might try and avoid you as best as possible, or attack you if it decides that it has good enough stats and gear to kill you, and grab your loot. If that AI is a guard, then it will first try and alert the other AI's by yelling out to them/report on radio or sound the alarm. Then move to cover and attack you. But if those options can't be done because it's to far from the "alarm button" or if it can't report on the radio because you are shooting at it. It will first return fire, take cover and then try to report. Perhaps also move to closest AI then join up.. Actuation is then kind of described in all the above by the actions it it taking based on making those decisions from the sensing variables you give it. Here EQS also playes a important role...
Nice video! What do you think about using BTs for actuation and other kind of AI for decision, like a state machine? I've heard this is what StateTree does, but I haven't tried it myself yet
One thing that bothers me about behavior trees, even though they are my go to, is that they seem to have a mind of their own "In a bad way." What I find is that selectors and sequences seem to behave exactly the same way sometimes, and what makes it even more annoying (please tell me if there's something that I've been missing) is that the behavior tree hates waiting. Any time I add a wait behavior because I don't want everything to execute within milliseconds (I want everything to flow nicely and somewhat realistically) the BT will avoid waiting like it's the plague, regardless of priority and will not execute the waiting OR anything after waiting even if it's parent BT node is a sequence not a selector. This causes me to extend my delays to every task right before finish execute. (I already add delays before finish execute to simple tasks that only take milliseconds to execute so the BT flows well and is easier to debug since the task doesn't flicker for one second and move to the next.) I usually blend both AI BPs and BT's with a bunch of decorators to force execution
Very good video. I tend to code in c++ I make my complex AI hard coding it and use behaviour trees in blueprint for simple AI like pawns or basic enemy. Works better for me this way.
Great video! I have used behavior trees, but never found them intuitive and I've seen a lot of my students struggle with them as well. I believe the problem is that if you're new to making games with Unreal and AI and start to research on how to implement AI behavior, it makes you think that behavior trees are the 'right' way of doing it, since it's a built in system with Unreal. So even if I have a student that just wants a simple zombie that follows and attacks a player, instead of doing it in blueprints and having it done in 5 minutes they go on a whole week long side tangent trying to learn behavior trees and then end up with a janky thing they don't really understand that just kind of works. I created whole boss encounters only making AI in blueprints and found that much more intuitive (even if it's less performant). Definitely want to give State Trees a try though.
@@blackshinobi956 Hey! I think C++ should always be something to keep in mind and strive for eventually, but I don't think it's the end all be all, some people make it out to be. If your goal is to work at a game company and not just make indie games then you'll probably have to bite the bullet and get really good with it, but I've made many small games using BP only that run just fine. If you look at Unreal Engine dev interviews there are also many commercially released games that were 100% done with Blueprints. Optimization is of course great and something to keep in mind, but practically speaking if the game hits a solid 60 FPS, the end user isn't gonna care and especially with Unreal you'll be GPU bottlenecked most of the time anyway. I just packaged an Unreal 2D game the other day where GPU usage was 100% and even though the logic was BP only CPU usage was hovering around 20%. Ran at 370 FPS on steam deck. C++ is great for when you start to see performance issues and want to encapsulate a certain function that is called frequently and I actually really like it for the approach of creating things you often use as plugins and reusing them throughout all of your projects :D All of this is just my opinion though at the end of the day :)
I dont understand, you list as a pro of the behaviour trees that they are event driven, but what if i make my blueprint ai also event driven like you should do anyways for almost anything?
You also have HTN and EQS that makes this way of doing it even better :) The special condition you talk about where it prioritize based on distance from player, or number of other enemy AI nearby to decide if fleeing, attacking, taking cover and attack or move to cover closer to other enemy AI++++ Even number of that AI's enemies, or even what is the closest cover is where EQS comes in... Check out EQS and HTN for Unreal Engine 5. But also, not every AI need to use BT or HTN with EQS. Some simple AI that is just doing scripted actions like if they are almost background fillers can use BP. Walk somewere when triggered, or something like look out a window and close it/close curtains when you get close or to a point. Only the AI that is in need if inteligent complex behavior should use BT or HTN and EQS.... Not NPC's that might just be in a shop when you enter. They can spawn in when you get close and before you enter. Then just use a pre scripted behavior based on where they spawn. Like if one spawn at the counter, then it might just be paying for something and leave. Then despawn after walking outside, and around a corner. Or when at a certain distance from the player and out of sight... Or someone that is looking at something, picking it up and walking to the counter to pay. One could mop the floors, or stock shelves etc etc
I haven't set up anything with EQS yet, but when I read the documentation it seemed like a super powerful tool. Do I have to worry about performance with it?
@blackshinobi956 it depends. But I don't think it will impact performance that much at all.. it's better then relaying on kine traces for sensing. EQS gives a value from 0 to 1 that AI use to make decisions from. Like for instance what cover is closest, or where it can see player best, or can't be seen by player and so on... You should look more into EQS and even the HTN plugin. *(Hierarchical Task Network Planning AI)*
after pain and suffering to watch and try hard on behavior tree Now Just throw that shit away and go blueprint.... and turn out it is not that bad it kind off just difference interface and you can make ton of Macro to decorate it instead
Every behavior tree tutorial I’ve found is always just a “patrol, see enemy, attack, and return to patrol if you lose sight of enemy” id really like to see a tutorial for creating an AI that feels a lot more intelligent than that
This is an amazing tutorial on Enemy AI and if I remember correctly he does a lot of it with Behavior Trees >> czcams.com/play/PLNwKK6OwH7eW1n49TW6-FmiZhqRn97cRy.html
Just seen your channel and checked out revent vids and subscribing! I have a suggestion if your open to video ideas? I can't find an efficient workflow anywhere on CZcams. Basically the best, most time efficient way from blocking a level to replacing it with actual meshes created in blender and making it final. I can't find anything online with how to do it. Its most often just blocking out turorials, or how to add a statue or some decoration into the level
@blackshinobi956 Fair enough lol. I figured out a fairly efficient way for tweaking animations (which used to take me forever) but been putting off level design for now
Seriously, I wondered what Last of Us did, because I remember sneaking behind an enemy and he just beamed into a state where the play character grabbing the enemy from behind. TLoU is a good game but this liked janky to me. I was used to fluent animations and movements, like in Metal Gear Solid 3, there isn't jank like this, the CQC just works at intended. After playing TLOU decades later, I wondered what mastery they did to achieve the movements in MGS3 and even MGS4 and MGS5.
I prefer blueprints. Better for making stricter AI. Honestly use whatever works. But I prefer using blueprints. A lot of granular control. But in my experience, most AI in video games are "simple". So you can pick one and just let it rock. Although I still think blueprints are better. :D
Maybe I'm missing something, I am a bit new to behaviour trees. In the case of the special situation wouldn't that just be prioritized highest and have a variable to check when to ignore that branch? I'm not sure I understand the rigidity of behaviour trees.
I may have explained that part poorly. Section 3.3 in Bobby's report explains it much better than I could have >> takinginitiative.files.wordpress.com/2020/01/behaviortrees_breaking-the-cycle-of-misuse.pdf
@@blackshinobi956 Finally got around to reading the chapter. It's really well written and interesting and I totally see why you would want to break these things up. So if I understand the paper correctly, the behaviour tree should be just that, a tree of various behaviours, but the high level selection of which tree to use and go into should be separated out so you don't start breaking the flow of the tree with exceptions and stat machine like logic. And on top of that you benefit by having much smaller trees allowing for more iteration on the code without rewriting a huge complex system. I'd love to learn more on this topic. Some ways to expand on these ideas in Unreal code. Thanks for bringing this forward it's a real gem!
Behavior trees are pretty much the same as every computer program, so it's a bit funny there's a specific term for it, but then again I guess one does need a term for "the first thing one reaches out for." Also a bit funny to call decision trees "AI" because that implies every computer program is an AI... well, under a very broad sense, maybe that's true.
mfs who have never completed more than a game jam project before love discussing why they think systems they've barely scratched the surface on aren't good enough
I don't like BTs because they bloat my functionality with enormous amounts of separate files that are hard to handle and they add a ton of additional headache even in simplest things like get/set variable. I can build BT alternative inside BP which will be easy to work with and debug.
honestly hate Behavioral trees. so much time and set up for basically the same functions lol i tend to build combat games so the player and AI will share the same BP With an AI check to run trimmers for his actions. With Ai trees it just adds more unneeded BPs when i can just Tell the AI to use the same actions as the player. loved this video though a bunch of useful info might go back and play with them tonight lol
Behavior trees are more costly *technically*, but it's not straightforward. If you're making a game which has simple AI requirements and you use BTs, they will cost more than BPs, but since the AI you need is simple, the extra overhead won't matter. Conversely, if you need complex AI and you use BPs instead of BTs, it will likely run a tiny bit slower. That being said, the things which actually affect performance are large loops, and in both BTs and BPs, you would move those to C++ during the optimization stage, or earlier if you're making a heavy AI game (like an RTS or sim).
I love AI, Behaviour trees are a great more modren version of FSM systems, behaviour trees or FSMs are great for more simplistic AI. even though, if you look at Alien isolation, it uses behaviour trees, and its well done. now, BTs and FSMs are both a horrible method, to use with complex AI, such as Sims ai, then your better off using a utility AI system, fed into a GOAP AI system, then executed by a simple FSM system.
overall, in the end, there are dozens of AI alyogrythms, and all have their uses. it really depends on what AI you want. the more complex a AI is, the heavier the process cost is.
This is a really good deep dive into Behavior Trees and its limitations. Could you please do the 3 alternative options. It would be greatly appreciated. Thank you!
This 🔝
One option I like is Utility AI (also called utility system) it’s super simple to understand and implement, which lets you quickly prototype with it and to see if it fits your needs. Lots of articles online about it, and plenty of CZcams videos.
this please
As a solo dev I'm always really hard on myself about the jank in my games, your last segment made me so happy to hear. I'll try to be nicer to myself about the jank going forward. Thanks for the video!
Hey, glad it helped you. I tend to have the same issue, but being nicer in my self talk definitely helps. Keep working hard!
Pro AI Dev here. It's also worth looking into "Utility Theory".
It's a numerical method rather than a decision based method. The general idea is that you give all your options (attack, take cover, run away etc.) a numerical score based on information that the AI has about its environment, and you choose the action with the highest score.
For example, the attack score may be based on a few things like line of sight, distance, to the player, and enemy health. As health goes down, the run away score increases (and maybe attack decreases), eventually overtaking the attack score.
I think it's a technique with potential and we could even see it combined with behavior trees to make them more versatile.
Thanks for bringing this up. I hadn't heard of utility theory yet, but its already giving me some interesting ideas!
AI and Games did a really good video covering the basics. Would highly recommend
I wrote a game based on utility theory back in the days of DOS, and it worked very well.
The AI tended to do the optimal thing, according to weights I provided.
I think that when I do it again, I'll add the option of keeping the current goal, as a weighted option.
Depending on the character, ignoring new stimuli would give the AI more realistic behavior.
Perhaps including it in emotional weights, that would change weights based on moods.
isnt this sort of implemented with the um fairly new EQS(environmental queue system)? Prettty sure it makes the AI take decisions based on 'scores'
edit: not to take anything away from the OP, i think a score system is a very solid way of handling ai, just thought id mention EQS
@Rundra No utility is for decision making, not doing actions. I have AI boars with utility AI that uses curves. Here are possible actions based on "needs of the animal". Order matters as if 2 needs get same score first in list is priority.
- Drink
- Eat
- Sleep
- Flee
- Attack
- Idle
The light "stutter" between each action is to me a classic Behavior tree thing. It doesn't always happen, but it happens often enough for me to recognise it... Okay, let's watch therest of the video now XD
I think it can be fixed with better animation blending.
Keep in mind that a behavior tree can nest other trees, you're not limited to the 3 actions you use as an example that can be needed in a totally different tree that runs it as a sub behavior. I think with behavior tree your milage will go as far as how well you understand custom decorators and events, and how well you understand selector/sequence.
It's intriguingly ironic how we strive to program artificial intelligence to act and make decisions in an ideal manner, yet we, as humans, often falter in our own decision-making. Take, for instance, my current predicament: here I am, composing this CZcams comment, when the more sensible action would be preparing a cup of coffee.
All programs are coded with the faults of their coder.
As the saying my dad tells: Input shit and it gives you shit.
I think you made the right choice to leave this comment. I'm glad you made this choice.
Hi, nice video! I also like the GDC talk called "AI Arborist: Proper Cultivation and Care for Your Behavior Trees", which make some strong points on when and why use BTs.
Thanks for sharing! I'll check out these GDC talks!
I got it right first time because the animation transition for the BT was very sudden and the character snapped in place. Which is what happens when you play an anim montage directly from the BT, since there's no blend in and out in that case.
I use Unreal and I'm a programmer and I gave behavior tree a chance, but I really didnt like it. It quickly becomes way too rigid for a complex AI, like just manageing all the things that needs to be canceled, because something like getting hit happened or there's a special even or something and the AI shouldnt mess with the player while it happens etc. Oh this needs to be checked ? Ok I need to add that thing everywhere in my graph.
Personally I don't see anything that can't be done with just statemachines, it really depends on the game I'm making, but I generally end up with some kind of hierarchical statemachine, where I would swap larger "behaviors" for like "I'm fighting the player" and in there there's another statemachine and then I'm pushing "actions" like "move there" and those action can be canceled or completed. I do that in C++ tho, generally custom stuff I'm creating depending of my needs.
My understanding on the real reason behavior tress are a thing is to empower non programmers to be able to do something about AI, which I guess CAN happen, but I rarely (read never, but there must be someone out there) seen a non-programmer have both the will to tweak AI and the capacity to do so. AI is one of the weird element of a "real time software", where you don't necessarily do things sequentially of "I'm opening a menu, clicking a button, this thing is executed", no it's ALWAYS changing, stuff need to be interruptible at any time, but also not feel weird like it changes every frame, so it's a very different way of thinking, things are always changing, things are not certain, you need to always evaluate what is going on and what should be done about it. So AI logic would be more like "I need to be in range of this object to interact with it, I'm not in range, so right now I'll move toward the object and check back next frame.". It's a very different way of thinking about "logic" that needs some getting used to, so you either have a very technical designer who's passionate about that or... a programmer and imo the hard part of game AI is not figuring out what the AI should feel like, but how it should be done so it feels like that.
Woh, sorry for the wall of text haha
I've never thought about BTs being a way for non programmers to work on AI. Thanks for adding that context!
First paragraph hits hard. As a non-coder that understands the basics beyond most yt tutorial content I really struggled as the BT I was working on got large and the constant checking that was being done on the character needing to be fed back to the BT. It made everything so much simpler.
@@blackshinobi956 Absolutely useful to think about as a way for "non-programmers" to work on AI - but those "non-programmers" are often still programmer... (hear me out)
While working on NPCs in a team, someone says "NPC's need to surrender" or whatever, instead of programming in that whole feature, I can ask "What do you need?" and program in an action node to drop the currently held item.
Now some other developer can use the BT to trigger the surrender, play a surrendering animation, check if they're armed and drop the weapon then put their hands up.
That "feature" needs conditions like checking if they're armed and playing different animations, but I avoid hard-coding in any assumptions about what's needed to "surrender" into the codebase. And that "drop item" node is probably useful in a lot of other areas, too.
So I can do a small piece of work, an hour later I've tested and I'm finished - I don't have to test the NPC behaviours, get the timing and check animations look right. Someone else can then "implement the feature" as a separate task to mine.
Helps us collaborate, helps us do larger tasks as a series of small tasks, helps us avoid needing to plan ahead too far.
... and then the project manager sees the feature and says "Wait, that's not what I was thinking" because communication is always a larger issue than the actual programming. They want the NPC to do something else, say, raise their hands with the weapon above the head and only drop the weapon when instructed. That's fine, we don't have to change code, it's very quick to draw a few different connections in our BT and give them that.
Even better, it lets us _implement the feature_ without going back to the project manager with a thousand questions. "How should they hold the weapon? When should they release it? How quickly?" because... we can just build it, wave them over to the computer, show them, then get that feedback and make the changes on the spot.
So it's often still programmers using the BT, but it's still valuable for them to have that separation between "programming" tasks, and "I shouldn't need to program to do these things" tasks.
Been doing research daily on unreal for about 9 months... first time I've heard there were other AI behavior options. Very nice.
I was in the same boat, for whatever reason all my googles lead me to BTs haha
Hey I have experience with the state tree plugin. I can tell you right now it's super flexible, easier to use than BTs, and very performant. You can use several state tree components on one actor. Tbh they're like suped up regular components lol.
I just started using one last night and I'm loving it already lol
Thanks for outlining and weighing the different options we have with AI in UE. Exactly hits the spot
One thing that you may be missing out on is the existence of 'Planners' for actualisation (and can feed back into decision making), it's a whole area in of itself but there's various approaches (Hierarchical/Temporal/Classic) and various implementations of these things into systems like STRIPS. STRIPS was famously used for the AI in the FEAR games. Roughly, they work out the plan of actions to perform after an intention is known and are basically a form of logical interaction pathfinding.
This is the first time I've heard of STRIPS, thanks for bringing it up! I'll definitely check it out!
A common problem is thinking that a behavior tree can do two different types of things, like in your example move and shoot.
Another common problem is not knowing which priority is higher and placing them in any way.
When you leave that way of thinking behind, everything goes better.
I explicitly use GOAP with a machine learning framework, even on the simplest game. But for real, behavior trees are great when your game aligns with them. I made a space flight shooter and used only BP AI because it was pretty simple, but a god game simulation needs way more power, and tools like behavior trees and GOAP are good for those.
since you asked... I noticed the npc on the right do a look at enemy as it identified its target. The sliding feet where what called my attention to the fact that the right was behavior tree.
7:40 great words to live by. I've got a question I hope could get an answer from you or a fellow viewer... Which tutorial series would you recommend to learn how to build a "complex" AI system? Also do you have a fav tut series for using behavior trees and maybe one for just using blueprints or something of a hybrid? I only scratched the surface of AI and am still trying to figure out the dos and don'ts. I've talked with a few pros and the answer I get is "just program it yourself" or "just use blueprint". I fear learning AI system will be like everything else in game dev where you figure out the best approach only after having gone down all the wrong roads first. Thanks for your help ahead of time and happy deving everyone!
Just came across your channel. As an Unreal environment artist, with an interest in adding loads of functionality through BP, I appreciate your content and especially the research undertaken in this particular video. Keep it up!
Thank you! Glad you enjoyed this video!
Have you seen logic driver plugin? Its like behavior trees but for everything and you can code straight inside of the states. No need to create blueprint assets
7:40 Hearing about how jank Arcanum is under the hood made me feel a lot better about some of my solutions.
That is an awesome video talking about one of the greatest points of conflict in AI Game dev. Thank you!
I really liked the point about how Behavior Trees being a good tool for reactive AI. This wasn't a framing I'd heard yet, and it's really kicked off some thoughts in my head. Great video!
Please do a video on state trees. I'm trying to learn that myself at the moment. Looking into using either state trees or behavior trees for a in depth dialog system.
I wish I could find the link to a GDC talk by one of the Gears of War devs, where they showed part of their AI behaviour. It was insane, Blueprint Hell level of insane. I look at it like this, you do the easiest solution that you can at the time and move up the ladder of complexity as you need to. Having BP driven behaviour is fine for simple AI, same as using BTs is fine. Being savvy about your code is the key and if you can't get it done with those tools, you may need to delve into cpp and do it there which is [or at least used to be] recommended for AI things especially EQS.
I did see that GDC talk! It was insane lol
I have tried to find it in the past, pretty sure its been taken down.. probably because of comments like this lol
Maybe I’m missing something, but the “special regroup” is the exact scenario behavior trees make trivial? The goal of behavior trees is to allow you to set the priority of actions. I do not use Unreal so, maybe their implementation is flawed, but it seems unlikely.
Fair critique, I may have explained that part poorly. Section 3.3 in Bobby's report explains it much better than I could have >> takinginitiative.files.wordpress.com/2020/01/behaviortrees_breaking-the-cycle-of-misuse.pdf
@@blackshinobi956 I took some time to read it. The paper discusses several BT implementations with that section referencing maybe the Unreal implementation (not sure how there’s work)? You also mention Unreal at some point, so if your critique is on Unreal’s BT, then I think it’s valid but it is not a downfall of BTs as a whole.
The quote from Thor, from pirate software, relating to video games is one the best ever! :)
I'm pretty sure I got it right. The stutter in the behaviour tree looks like the stutter I sometimes face when working with BT 😅
Well said, it gives me alot to think about. Good points in that there is not right way to make games -- just do the best we can.
You can do pretty much everything in BP what you can do in BT other than EQS. Biggest potential problem in BP is spaghetti and structuring.
I got this right. I don't know if the glitch I saw was real but I feel like that's the example reason. By the way, I love your channel.
havn´t heard about state trees yet. Gotta take a look into it. Thanks for this good video. Great Thumbnail :D
Thanks for watching!
There's one thing I've learned from game development is iteration.
You should make the thing work, and then iterate over time if you add more stuff to it.
For example, if you need to make a weapon system, attach it to the player arm. However, further down the line, you need to have more weapons, iterate on the weapon so your designers can add as much weapons as they need.
Also, game design document.
Definitely agree!
Thanks for this video, I've been working with both Blueprints and Behavior trees for the last couple weeks and was constanly wondering If I chose the correct way of doing stuff since I've ran into priority issues like you described in this video. Videos like these really help me understand the ins and outs of what i'm working with, really happy your vid showed up in my feed, will subscribe and checkout your other videos.
I haven't touched them in a while but the one time i've tried using behavior trees on a project (for FPS enemies) they quickly became very awkward to use. It's been a while so i cant remember the exact issues i had with it. It was enemies that could shoot the player or take cover similarly to the ones you mentioned in the video. As soon as their actions started interacting with eachother it quickly became a mess, stuff like having one action instantly interrupt another became very complicated and had me reach for weird workarounds every time. Blackboards and decorators/whatever the tree uses for decisions didnt make much sense to me neither because its all stuff you can do easier/more intuitively in blueprints. Idk, maybe i just didnt spend enough time on it but it seems weird that you'd need to learn this obtuse and unintuitive system, especially when once i remade that same AI with blueprints it started actually making sense and working how it's supposed to.
I've been about people that trees are the "right way to do it" but why? Something something finite states but what advantage does that give? What if i want the ai to take more than one action at once? What if i want it to decide movement and aiming/actions differently? Anyway rant's over, this really reminded me of the frustration i felt trying to learn this system (with tutorials from a series that was great overall so im assuming its not because i was taught wrong)
I do agree that BTs can become a mess and the way files are stored aren't as intuitive as it could be
@@blackhole1376 Parallel can help with simultaneous actions.
Great video. I personally hate the behavior tree system, because it feels like it doesn't belong with the rest of the UE5 tools. It has always felt overly complex to me, and I prefer to just write the AI in the BP Event graph. You brought some new perspectives I hadn't previously considered.
Thanks for this video! I wasn't always sure how and why I could or should use behavior trees, and though I need to learn all the functionality more and use them when necessary in my games, it's good to know they aren't the only option. I will probably come back to this down the road to reference!
my game revolves around an AI partner that follows you and you solve puzzles together. So far I've been able to implement everything I want with just blueprints, using basic stuff like functions, timer by events, branches, bools, and looping gates
Yes please for the deeper dive into the 3 options you mentioned
This is an awesome breakdown man. Super helpful, thanks for this. Studying up on state trees now because of this.
Dude this is an interesting subject. Yesterday night I've made a prototype for an AI companion that has no behaviour tree but reacts to the world and goes around through its sensing abilities and that drives the player controller like a player would do. It's been way easier for giving it a simple behaviour rather than messing with the behaviour tree
Hey, fellow indie dev here. In the intro, I could tell which was the behavior tree because of the immediate turn toward the target upon detection. While the blueprint can do that, it would take a little more effort than it's worth just to add in that small detail.
I don't dev, but I like watching explanations of the technical stuff like this. AI fascinates me, beyond point-shoot or the recent 'lets insert a chatbot into the kitchen sink' trend. It's good to have some level of knowledge of how these things work. I can't wait until we finally get the materials breakthrough to allow a new leap in processor power - I imagine there's a tonne of stuff that devs would love to try to code but is just not all that feasible given the current resources.
I'm a big fan of GOAP and FSMs, but I also code & don't rely on prebuilt node based stuff because I prefer having full control and knowing exactly what's going on "under the hood" at all times.
I got it right because I saw your thumbnail before I played the video.
Very insightful! There definitely will never be a best way, but only arguably better ways to handle complex systems like this. Have you had a chance to dabble in the state trees system? I would love to hear if it has influenced your preference.
I prefer StateTree's!
You don't need behavior trees. You can do everything you need in BP. I've been doing AI in BP for several years now.
Im not someone who has watched you before, but i wanted to let you know, i liked this video a lot. I dont see much gamedev content in this fashion, discussing the implementation methodologies on a relatively deep level, however, not going so granular that im lost in the specifics of what your talking about. I liked this format a lot, would love to see more like this :)
Imma subscribe, loved the video!
In UE and probably many other coding / blueprint software, there’s so many ways to do a specific thing. I’m a solo dev hobbyist who is more comfortable with plain and basic blueprints. I’m personally more comfortable with doing something like creating some sort of tracing or collision to detect the player then having the enemybp move the enemy towards the player when detected, then playing one of few attack animations if the player is close enough. I don’t think there’s a right or wrong way, just an effective or not so effective way, and with time your methods could evolve into more effective ways but as long as you can make your imagination come to life in the engine I think that’s what matters most.
You're spot on, it's all about learning by doing for me
I'm just wondering that too, and this video came out, I want to hear more.
Any chance you can elaborate on “Decision Tree” when you were listing down the alternatives? Is that just hardcoded Blueprints decisions? What do you mean by that?
Spotting the Behaviour Tree is EASY! The Blueprint one stops when it sees the enemy, then turns and moves towards the enemy at the same time. The Behaviour Tree one uses what appears to be the built-in task for turning toward the enemy, and it looks janky as crap.
Much like everything in Unreal Engine, it's divisive because some people don't understand how customizable it is, and think it should just do exactly what they want out of the box. Then when it doesn't, thinks that doing all the ground work themselves makes more sense.
very nice video, i had been thinking about diving into behaviour trees but BP seems functional enough for the level of enemy intelligence my games need. thanks for sharing, subbed :D
Behavior trees are great because they are flexible and easily repurposed, the sequence of events is easily tweaked and altered in the BT editor. It's super useful imo
The BT version showed that the AI found the player using AI perception (Sight erception) and turned toward the player as soon as the sight trace hit the player.
The BP one has the AI walk to a point, then move to player and attack when in range.
Nice, this is exactly how I set it up
@blackshinobi956 😁🤓😅 hehe, been using UE for +6 years now. But I don't code or make logic my self. I only know enough about it do understand it. To lazy to work with it my self hahaha
What you mean not combining those 3 layers?!
The AI need to have all 3 to be a good AI. The sense using AI perception for instance. Then Decide what to do based on the information they sense or get from EQS and other variables they have been given like for instance amount of ammo they have left, weapon type, health amount, healing options/possibility, environment they are in, amount of cover available/ or if cover is possible, and also by that AI actor's class (For instance, f that AI is a scout, then it might run back to "base" or other close by AI to report your position and presence.)
If that AI is scav, it might try and avoid you as best as possible, or attack you if it decides that it has good enough stats and gear to kill you, and grab your loot.
If that AI is a guard, then it will first try and alert the other AI's by yelling out to them/report on radio or sound the alarm. Then move to cover and attack you. But if those options can't be done because it's to far from the "alarm button" or if it can't report on the radio because you are shooting at it. It will first return fire, take cover and then try to report. Perhaps also move to closest AI then join up..
Actuation is then kind of described in all the above by the actions it it taking based on making those decisions from the sensing variables you give it. Here EQS also playes a important role...
Please do State Tree explanation like this
Nice video! What do you think about using BTs for actuation and other kind of AI for decision, like a state machine? I've heard this is what StateTree does, but I haven't tried it myself yet
IMO: It's all of the above, character, controller, behavior tree and associated data assets, with a sprinkle of nested sub-behavior trees.
are you still making a stealth game?
What’s a good method for an AI that picks a random option from a weighted set of options and the circumstances affect the weights?
One thing that bothers me about behavior trees, even though they are my go to, is that they seem to have a mind of their own "In a bad way." What I find is that selectors and sequences seem to behave exactly the same way sometimes, and what makes it even more annoying (please tell me if there's something that I've been missing) is that the behavior tree hates waiting. Any time I add a wait behavior because I don't want everything to execute within milliseconds (I want everything to flow nicely and somewhat realistically) the BT will avoid waiting like it's the plague, regardless of priority and will not execute the waiting OR anything after waiting even if it's parent BT node is a sequence not a selector. This causes me to extend my delays to every task right before finish execute. (I already add delays before finish execute to simple tasks that only take milliseconds to execute so the BT flows well and is easier to debug since the task doesn't flicker for one second and move to the next.) I usually blend both AI BPs and BT's with a bunch of decorators to force execution
I noticed the same thing with BTs and waiting, its super annoying!
On the right, I seen a small stutter between action changing which made it seem like a behavior tree
Very good video. I tend to code in c++ I make my complex AI hard coding it and use behaviour trees in blueprint for simple AI like pawns or basic enemy. Works better for me this way.
Great video!
I have used behavior trees, but never found them intuitive and I've seen a lot of my students struggle with them as well.
I believe the problem is that if you're new to making games with Unreal and AI and start to research on how to implement AI behavior, it makes you think that behavior trees are the 'right' way of doing it, since it's a built in system with Unreal.
So even if I have a student that just wants a simple zombie that follows and attacks a player, instead of doing it in blueprints and having it done in 5 minutes they go on a whole week long side tangent trying to learn behavior trees and then end up with a janky thing they don't really understand that just kind of works.
I created whole boss encounters only making AI in blueprints and found that much more intuitive (even if it's less performant).
Definitely want to give State Trees a try though.
I've never gotten to talk to a game dev teacher! Do you generally recommend sticking to BPs? Do you think its work building some things in C++?
@@blackshinobi956
Hey!
I think C++ should always be something to keep in mind and strive for eventually, but I don't think it's the end all be all, some people make it out to be.
If your goal is to work at a game company and not just make indie games then you'll probably have to bite the bullet and get really good with it, but I've made many small games using BP only that run just fine.
If you look at Unreal Engine dev interviews there are also many commercially released games that were 100% done with Blueprints.
Optimization is of course great and something to keep in mind, but practically speaking if the game hits a solid 60 FPS, the end user isn't gonna care and especially with Unreal you'll be GPU bottlenecked most of the time anyway.
I just packaged an Unreal 2D game the other day where GPU usage was 100% and even though the logic was BP only CPU usage was hovering around 20%.
Ran at 370 FPS on steam deck.
C++ is great for when you start to see performance issues and want to encapsulate a certain function that is called frequently and I actually really like it for the approach of creating things you often use as plugins and reusing them throughout all of your projects :D
All of this is just my opinion though at the end of the day :)
Great thoughts. Thanks!
The behavior tree was a giveaway because you could tell it was trying to make a decision on which behavior to use.
Yeah, you're right you can see it evaluating branches
You’re doing great work man! Keep it up!
I dont understand, you list as a pro of the behaviour trees that they are event driven, but what if i make my blueprint ai also event driven like you should do anyways for almost anything?
You also have HTN and EQS that makes this way of doing it even better :)
The special condition you talk about where it prioritize based on distance from player, or number of other enemy AI nearby to decide if fleeing, attacking, taking cover and attack or move to cover closer to other enemy AI++++ Even number of that AI's enemies, or even what is the closest cover is where EQS comes in... Check out EQS and HTN for Unreal Engine 5.
But also, not every AI need to use BT or HTN with EQS. Some simple AI that is just doing scripted actions like if they are almost background fillers can use BP.
Walk somewere when triggered, or something like look out a window and close it/close curtains when you get close or to a point. Only the AI that is in need if inteligent complex behavior should use BT or HTN and EQS.... Not NPC's that might just be in a shop when you enter. They can spawn in when you get close and before you enter. Then just use a pre scripted behavior based on where they spawn. Like if one spawn at the counter, then it might just be paying for something and leave. Then despawn after walking outside, and around a corner. Or when at a certain distance from the player and out of sight...
Or someone that is looking at something, picking it up and walking to the counter to pay. One could mop the floors, or stock shelves etc etc
I haven't set up anything with EQS yet, but when I read the documentation it seemed like a super powerful tool. Do I have to worry about performance with it?
@blackshinobi956 it depends. But I don't think it will impact performance that much at all.. it's better then relaying on kine traces for sensing. EQS gives a value from 0 to 1 that AI use to make decisions from. Like for instance what cover is closest, or where it can see player best, or can't be seen by player and so on... You should look more into EQS and even the HTN plugin. *(Hierarchical Task Network Planning AI)*
after pain and suffering to watch and try hard on behavior tree
Now Just throw that shit away and go blueprint....
and turn out it is not that bad
it kind off just difference interface
and you can make ton of Macro to decorate it instead
Excellent video. I know more now than I did before I watched it!
Means a lot coming from you man!
Every behavior tree tutorial I’ve found is always just a “patrol, see enemy, attack, and return to patrol if you lose sight of enemy” id really like to see a tutorial for creating an AI that feels a lot more intelligent than that
This is an amazing tutorial on Enemy AI and if I remember correctly he does a lot of it with Behavior Trees >> czcams.com/play/PLNwKK6OwH7eW1n49TW6-FmiZhqRn97cRy.html
I am using behavior tree but writing each task in C++
Just seen your channel and checked out revent vids and subscribing!
I have a suggestion if your open to video ideas? I can't find an efficient workflow anywhere on CZcams.
Basically the best, most time efficient way from blocking a level to replacing it with actual meshes created in blender and making it final. I can't find anything online with how to do it. Its most often just blocking out turorials, or how to add a statue or some decoration into the level
Thanks for the idea! I haven't found a good workflow for that either 😅
@blackshinobi956 Fair enough lol. I figured out a fairly efficient way for tweaking animations (which used to take me forever) but been putting off level design for now
Very nice informative video! Great, underrated channel
Seriously, I wondered what Last of Us did, because I remember sneaking behind an enemy and he just beamed into a state where the play character grabbing the enemy from behind. TLoU is a good game but this liked janky to me. I was used to fluent animations and movements, like in Metal Gear Solid 3, there isn't jank like this, the CQC just works at intended. After playing TLOU decades later, I wondered what mastery they did to achieve the movements in MGS3 and even MGS4 and MGS5.
Some games are just like lightning in a bottle. You're right about it being true mastery
And here I thought Blueprints vs C++ (or scripting vs visual scripting) was the only controversial aspect of game development
🤣🤣🤣
super cool! 🥳
This was a really informative video man. Thanks
I prefer blueprints. Better for making stricter AI. Honestly use whatever works. But I prefer using blueprints. A lot of granular control. But in my experience, most AI in video games are "simple". So you can pick one and just let it rock. Although I still think blueprints are better. :D
Yup, as long it works rock with it!
Maybe I'm missing something, I am a bit new to behaviour trees. In the case of the special situation wouldn't that just be prioritized highest and have a variable to check when to ignore that branch? I'm not sure I understand the rigidity of behaviour trees.
I may have explained that part poorly. Section 3.3 in Bobby's report explains it much better than I could have >> takinginitiative.files.wordpress.com/2020/01/behaviortrees_breaking-the-cycle-of-misuse.pdf
@@blackshinobi956 Finally got around to reading the chapter. It's really well written and interesting and I totally see why you would want to break these things up. So if I understand the paper correctly, the behaviour tree should be just that, a tree of various behaviours, but the high level selection of which tree to use and go into should be separated out so you don't start breaking the flow of the tree with exceptions and stat machine like logic. And on top of that you benefit by having much smaller trees allowing for more iteration on the code without rewriting a huge complex system.
I'd love to learn more on this topic. Some ways to expand on these ideas in Unreal code. Thanks for bringing this forward it's a real gem!
Behavior trees are pretty much the same as every computer program, so it's a bit funny there's a specific term for it, but then again I guess one does need a term for "the first thing one reaches out for." Also a bit funny to call decision trees "AI" because that implies every computer program is an AI... well, under a very broad sense, maybe that's true.
This was a great overview thank you
Glad you found it useful. Thank you!
If you need to make a complex behavior for an AI agent, look into utility AI.
Great video
Damn, this was a great video
Very Informative ahaha defs subbing 🤝
Thanks for the sub!
As a solo dev I just care if it works. I felt that.
behavior wisetree
mfs who have never completed more than a game jam project before love discussing why they think systems they've barely scratched the surface on aren't good enough
Sorry this video wasn't what you were looking for. Hope you have a great day!
I don't know what a behaviour tree is. 🌲🌴 🤔
Great vid thanks
The behavior tree is needed to simplify development. The behavior tree is just a tool.
very interresting, thanks for sharing
I don't like BTs because they bloat my functionality with enormous amounts of separate files that are hard to handle and they add a ton of additional headache even in simplest things like get/set variable. I can build BT alternative inside BP which will be easy to work with and debug.
Yeah, it's nice to have everything in one place with Blueprints
honestly hate Behavioral trees. so much time and set up for basically the same functions lol i tend to build combat games so the player and AI will share the same BP With an AI check to run trimmers for his actions. With Ai trees it just adds more unneeded BPs when i can just Tell the AI to use the same actions as the player. loved this video though a bunch of useful info might go back and play with them tonight lol
Was there a difference between the 2 in how much they make the computer think?
I didn't measure performance on the prototypes, but I think it depends on how the blueprints are set up. Good question!
Behavior trees are more costly *technically*, but it's not straightforward. If you're making a game which has simple AI requirements and you use BTs, they will cost more than BPs, but since the AI you need is simple, the extra overhead won't matter. Conversely, if you need complex AI and you use BPs instead of BTs, it will likely run a tiny bit slower.
That being said, the things which actually affect performance are large loops, and in both BTs and BPs, you would move those to C++ during the optimization stage, or earlier if you're making a heavy AI game (like an RTS or sim).
@@PretendCoding thanks for explaining this! Large loops costly makes sense
Behavior tree one is more smoth❤
Pure luck?
Nah brah, behaviour tree is keen to glitching like that.
I love AI, Behaviour trees are a great more modren version of FSM systems, behaviour trees or FSMs are great for more simplistic AI. even though, if you look at Alien isolation, it uses behaviour trees, and its well done. now, BTs and FSMs are both a horrible method, to use with complex AI, such as Sims ai, then your better off using a utility AI system, fed into a GOAP AI system, then executed by a simple FSM system.
overall, in the end, there are dozens of AI alyogrythms, and all have their uses. it really depends on what AI you want. the more complex a AI is, the heavier the process cost is.
Definitely! I've got to study GOAP systems. I've never got to use one
Behavior trees are only poor if you have 100s of entities as they have extra garbage, otherwise they do the same as blueprints or crap c++ code.
*and if you're not sharing information between black boards