Видео

Can't wait to debug why my character is running, jumping, falling and being idle at the same time.

@1:39 Make the randomize an optional Boolean passed to BaseTitan that is true by default?

Great video, cool ideas. Beatiful game design. Be well!

0:29 LOL - The three legendary pillars of software development. Good Code is optional.

Behavior trees are NOT state machines. They are decision trees that flows down to leaf nodes based on parameters, mostly booleans and enums, to make a choice at a specific time under specific conditions. It can quite robust. The difference between this and state machines is that a state machine needs enter and exit condition to switch between states. A behavior tree reruns from top to bottom, re-evaluating the it's conditions.

In Unreal Engine, composition is called actor components. This method is kinda the same as composition, where you can add and remove components.

this is why i hate unity and godot. To many tools with zero best practices taught by the dev's. In unreal this is nothing more than u importing the gameplay ability system and writing a spawner ... wasted so much time rewriting the clock because unity and godot dont have a clock they have sun dials

Not to be annoying but just the demo looks pretty fun, when are you releasing more?

Mhh ok i know my question is very dumn, but i started approaching game dev and coding very recently, so let me ask this. Fkr my first game im making a very simple project, theres just a player, different types of trees, and different tools to cut trees. The difference they have is the visuals (all), the health (trees), damage and speed(tools). I was thinking that making something like a base_tree and base_tool to store the variables for those stats and run the basic functions while having a different yet simple and clear scene for each tree inherithing from the base_tree would be the best approach. Would you suggest bot to use inheritance, and switching to this design? So if have a node for healt, one for sprites and animations, one for health, exc..? Im sorry if rhis is dumb but again its the first game im working on by myself so i apologize😅

Why wouldn't you just have different behaviour trees for each situation? I mean you aren't going to be using the idle or run movements when you are in the plane. So just have it all swap out when you get in and out of a vehicle. Land vehicles are going to be very different behaviours to planes or walking.... And if you want to ride a motorbike or a horse, well that's going to be very different too. So just swap in a new behaviour tree and save yourself a bunch of bugs. Then you can go over to your player movement and simply slap in a line of code that checks if they are failing (if not ground for X amount of time and they are moving downwards, falling = true) and gives them some very slight falling movement controls - you could make these speed up over time or with certain items you could move left and right faster. Don't have the plane move towards the player, allow the player to move around so they can decide if they want to move towards the plane as they fall. If you have the plane move towards the player, I can almost guarantee you'll end up with a weird bug where the plane sees it's as falling and trys to move towards the player. Possibly when the player is controlling it or trying to get in/out of it. Better to just give your player agency and allow them to learn to get back into the plane. Also... Wing suits and parachutes.

Bro... in a video that isnt exactly about OOP, it taught me how OOP classes work better than 99% of other things I've seen over the years. Holy crap this was fantastic, and your editing is top notch. Instant sub

0:05 game?

In another video of yours, I noticed your beautiful use of colors! Interesting to hear you explain it's a core feature of your games! Fantastic work!

This is a valid approach in many regards, my issue however is with separating behaviours into nodes. If you want to expand upon a project and have a large scale scene with many behaviours, there will be a significant performance cost with the huge amount of nodes. In conclusion, this is perfect for small scenes with few nodes, but not advisable if you want to craft a large game that is also performant.

Titans

Composition is great sure but I'm not sure this is the best example. I feel the randomize function should never be in the class. This example should probably use a factory instead

But this pattern wasnt called "Finite state machine"?

Message busses are dicey to debug, they turn straightforward bugs ("loop -> npcs -> ai -> lookForEnemy -> stealthSpot -> segfault) into hard to debug asynchronous call chains (loop -> npc -> messageRead -> segFault) that require you to have good observability and look through logs to understand unreliably who wrote what and why things got buggy. If I make a message bus now, what I do is add a "synchronous mode" where each Publication into the bus immediately follows with a function call to wake up each and every subscriber to that call. It keeps the call stack in a single monolith which is great! And it will shine a light on unwanted infinite loops

You didn't need inheritance making BehaviorTree inherit Behavior, just have Behavior and BehaviorTree implement an IBehavior interface and have them be passed as arguments and be composed into things rather than inherited. Inheritance can always be skipped entirely, and it is always a bad idea inherit. Newer OOP languages like Rust skip it entirely. They don't have inheritance. Are their programmers unhappy about it? Nope! It just requires re-learning that side of OOP

youre dumb lol.

The main issue is not inheritance. It's bad design. Titan shouldn't randomize it's own stats. Ideally, that should be a work for some titan factory if you have a lot of types. Im also not saying everything has to be done using inheritence, in case you want to add a special trait like armor, hair, goofy lip.. composition makes sense, it also makes the code more readable and design less complex.

I am also a developer. With 1 title on my belt 😂. Pls, how can we buy your game?

you got a good style of video

Support you bro,i will be always there for you😊😊

I like how you use strings instead of enums xd.

I don't get it....u have godot experience....why cant u make ur own games....what's the point if we all know how to make games

Inheritance is for interfacing. Otherwise one should compose. Change my mind.

Inheritance as well as composition have their place and often a mix is the most useful approach imo. you can have a titan that inherits from a titan base class, if there is commonly shared code between them, lets say they all have eyes and blink with them. that does not mean everything has to be shared and the different titans then even can all have their own components. Just don't overdo it with inheritance, since it becomes very confusing very quickly. Use it, if you expect to save a lot of time when changing something in the future, since you only need to change the base class(for example blink twice as fast or whatever). If you have hundrets of titans, it may save you a lot of time. If you only have 3 titans i would not bother anyway. Also in my opinion i would define the behaviour tree in your example more of a state machine - A component would be for example a damage area, that an enemy can have or not have to do damage, imo. But that beeing said, very nice to watch video, i really liked it! Good and clean presentation 👍

I get everything you said Nesi, nice video. I still need to understand what exactly is the function "set_behaviour" doing. Like how does it actually change the behavior to one of the child nodes listed in the behaviour tree?

I think you err too far when you reduce OOP to just inheritance. The OP mantra has always been to prefer composition of objects over inheritance. Second, inheritance should be used at the point of variance. I don't think you have different titans, they are all the same class of thing. Instead you have titans composed of different properties. If you want titans to look different, you can use the same geometry and slightly vary things like the texture, shader, scaling, etc. Those can just be property changes. If i was to solve the behavior issue in an OO way, I would make behavior an interface, not the titan. That way you could have a behavior that has normal titan behavior, another one that is random, or even one whose behavior is controlled by the player. The variance happens when constructing a titan with a different instance of behavior. In pattern terms, the behavior is the various strategies you want titans to exhibit. Mind, I'm not sure that would be the _best_ approach, its just how i would look at it in an OO way. It could end up just being a callback function once the point of variance is reduced to the essentials. In reality, you might end up punting to a scripting engine, making the titan just composed of the script to run for its behavior. All of that can be done within OO.

Is your behaviour tree ,also what people also call a state machine ?

I was taught OOP as *the* way to program at uni for years, but when I got to my gamedev spec and was given freedom to build my own project any way I see fit - I realized how easier and more maintainable things are when you use composition instead. I wasn't even looking for any alternative paradigm or anything, I was just trying to solve problems and logic always led me to structure my projects with composition.

Waited for 2 years man I quit game making also … welcome back

I found myself cerrin on if my code is clear and well writen more than if it's usefull and working and this stop me from coding too long befor i actually start to make it right

Glad I’m on the right track . I name them “actions” and are basically containerized behaviors. I got priorities setup as well as additive capability which I can either have the next action be the current behaviour or an addition to the current .

I'm an experienced software engineer and what you've created is called an HFSM: Hierarchical Finite State Machine. When you say behavior tree, especially in the context of game dev, it usually refers to a form of AI that's similar to an HFSM but is more specialized and centric around execution over time. There are lots of videos and information on it.

Some of the best advice I've ever heard was "Favor composition over inheritance". In 30+ years of software development there have been very few times when I've found non-trivial inheritance to be of use. But I'm constantly finding composition to be useful.

oop have composition you just didnt knew how.. this whole debate about functional vs oop its really on hating oop because its hard to learn.. guys dont fall for it

Your randomization method is in the wrong place - you should have a spawner class which handles generating random values and instantiating titans. Data inheritance is usually stable, but logic inheritance usually indicates you’re trying to do too much in your class.

Loved this video. I've seen other explanations of behavior trees and state machines for game development that seemed to overcomplicate the communication between nodes. This was a great video!❤

Everyone else: trying to understand the video and point out mistakes Me: mmm.... *Juicy montage*

How do I find my games resolution? I set the resolution to 1920 x 1080 Fullscreen and set the transform values and i set it to 960 and 540 and its not working

Loved the video especially the end product with the attached debugger to see state displays on the entities

Great video, keep up the good work man!

so is every behavior just a node with a script attached to it? Looks great when it all comes together, like the labels showing the behavior

Discord link is invalid and twitter account does not exist. I need more my man!