I saw a talk some time ago where the talker was doing AI's by simulating a controller (like a gamepad) so every enemy could be potentially controlled by a human using a gamepad. So the AI just controlls a virtual gamepad, like setting the left joystick left or right based on the state. So each state executor in this case just presses left or right to move, A to attack, etc. This came to mind when I saw the mushroom floating after attacking because I bet that doesn't happen with your actual player because the player is built to work with gamepads, so by building enemies the same way everything acts a bit more in the same way. And you can control the enemies with a gamepad if you wanted for whatever reason haha. You can obviously ignore this but I thought it was a cool way to think about enemies and that's how I'm building my AI's in the future. Talking about gdscript, you can always use compute shaders for performance haha not really practical though
Haha - that particular issue was mostly because I wasn't applying gravity correctly when the state changed, so just another physics problem, heh Controlling enemy input as if they were a playable character with the AI using a controller is actually a really interesting approach though, it does seem like there could be some cool applications for that!
@@InboundShovel Yeah, I figured it was an issue that you would easily fix. I've had my share of unintended floating behaviours so I've been there haha The playable ai is interesting in it's own way and I think a separate topic and approach. I'm building a duel sword thingy so all players use swords the same way, which is why it makes sense that if my animations already read controller input, just have the ai control a virtual controller and have the system work the same way for everything. Since you have different enemies with different animations, compositions, personalities, etc, it may be more complicated to do it that way.
The game looks great and I really look forward to your devlogs. Glad mushroom boy can finally go through the motions of life and death LOL wishing you all the best and thank you for going the extra mile when it comes to editing and etc.
I also quite recently implemented the AI system for my game. The biggest hurdle I faced was to create editor tools that allow for quick iteration as my game is designed around complex multi-stage encounter where multiple AI agents communicate with each other. I would love to see how your editor tools look like, or about a minute of content showing how you work with your system.
That's a great suggestion! I was working on some updates to the AI system right now, I'll show off how I work with the enemies in editor in a video about that rework! Spoiler: my editor tools were kind of over-designed and not what I needed for my use case, so I simplified it /greatly/ heh
How can you have only 128 likes ?!! For me that's mad ! Your videos are soooo good ! I was looking for a way to implement ennemies in my game, and I couldn't find one without any code but just the logic (i want to find how to code it by myself) but I found you ! And believe me, I slapped that suscribe button ! Sorry for my mistakes in English, I'm 15 and french ;) I made the effort of writing this comment by myself because you and your channel deserve it. Hope the best for you and your game !
I would probably pick Behavior Tree to StateMachine, or go with AdamCYounis state machine design. The statemachine state is resonsible for the “how“ (how to run, attack etc) whereas the behaviour tree is responsible for the “what” (when to run, when to attack etc). But Adam shows in his state machine tutorial also how both can be combined, yet remain modular.
@@Anerisian Yeah, I think it has c# support, but I haven't looked into it much. Last I looked into it, I saw it wasn't very stable - so I haven't considered it much. Probably worth another glance. Sounds like that approach is extremely similar to what I've done here - I just called the "behaviour tree" a "state executor" LOL
Liking this format! Also good work on problem solving your mushroom son's behavioural issues 😂 it always comes down to executor function...I mean executive function
More modularity is always good, especially with AI. The code that performs actions should be separate from the code that makes decisions. Someone already mentioned the virtual game pad implementation. Also states should have separate code for determining when they start and when they end so you don't get enemies with no concept of object permanence. You don't forget the spider you saw in your room the moment it skitters away. States should generally decide for themselves if they should be on or off and the state executor just decides between them when multiple states decide to be on. Each state has one block of code for turning the state on, and a completely different block of code for deciding when to turn that state off. Fine tune this for your use case. Also learn about boids. If you're not sure how boids can help you then you don't understand boids well enough.
Maybe you can mix behavior tree with artifical intelligence algorithm for simulating learning. Basically the enemy can literally think and plan and do real time decisions more dynamically.
I know this is 3 monthes old but wouldnt it work if you made the notice range farther than the range of an attack so the enemy is forced to get into range
About GDscript and C#, why dont you use Godot Mono then? If you are better at C# go with that. I say that with actual experience on it, its amazing, I have the heavy work physics of my Ai, etc all under C# and some of the rest of the code like UI or some quick method calls under GDScript.
Oh, this AI has nothing to do with LLMs or shit like that - it's just the general term for the enemy's brain. Don't let it stop you from learning to code! It's still a lot of fun to work on interesting design problems - human ingenuity will still win out in the end, haha!
Hotdog-slapped that subscribe button! Looking forward to your progress.
Thanks so much!
I saw a talk some time ago where the talker was doing AI's by simulating a controller (like a gamepad) so every enemy could be potentially controlled by a human using a gamepad. So the AI just controlls a virtual gamepad, like setting the left joystick left or right based on the state. So each state executor in this case just presses left or right to move, A to attack, etc. This came to mind when I saw the mushroom floating after attacking because I bet that doesn't happen with your actual player because the player is built to work with gamepads, so by building enemies the same way everything acts a bit more in the same way. And you can control the enemies with a gamepad if you wanted for whatever reason haha. You can obviously ignore this but I thought it was a cool way to think about enemies and that's how I'm building my AI's in the future.
Talking about gdscript, you can always use compute shaders for performance haha not really practical though
Haha - that particular issue was mostly because I wasn't applying gravity correctly when the state changed, so just another physics problem, heh
Controlling enemy input as if they were a playable character with the AI using a controller is actually a really interesting approach though, it does seem like there could be some cool applications for that!
@@InboundShovel Yeah, I figured it was an issue that you would easily fix. I've had my share of unintended floating behaviours so I've been there haha
The playable ai is interesting in it's own way and I think a separate topic and approach. I'm building a duel sword thingy so all players use swords the same way, which is why it makes sense that if my animations already read controller input, just have the ai control a virtual controller and have the system work the same way for everything.
Since you have different enemies with different animations, compositions, personalities, etc, it may be more complicated to do it that way.
Unless you actually do sonething with that, that’s just overcomplicating things.
The game looks great and I really look forward to your devlogs. Glad mushroom boy can finally go through the motions of life and death LOL wishing you all the best and thank you for going the extra mile when it comes to editing and etc.
Thank you!
The ironing out phase of the video made me feel a lot better about being confused on how to implement real more complex enemies, appreciate the video
I love your video and your humor. This is what I imagine kinda what my devlog would be. Very inspiring.
Thank you so much! :D
I also quite recently implemented the AI system for my game. The biggest hurdle I faced was to create editor tools that allow for quick iteration as my game is designed around complex multi-stage encounter where multiple AI agents communicate with each other.
I would love to see how your editor tools look like, or about a minute of content showing how you work with your system.
That's a great suggestion!
I was working on some updates to the AI system right now, I'll show off how I work with the enemies in editor in a video about that rework!
Spoiler: my editor tools were kind of over-designed and not what I needed for my use case, so I simplified it /greatly/ heh
A nice video, thanks! I just wish you would actually show us how you're tackling the problems and building your system inside Godot.
How can you have only 128 likes ?!! For me that's mad ! Your videos are soooo good ! I was looking for a way to implement ennemies in my game, and I couldn't find one without any code but just the logic (i want to find how to code it by myself) but I found you ! And believe me, I slapped that suscribe button !
Sorry for my mistakes in English, I'm 15 and french ;) I made the effort of writing this comment by myself because you and your channel deserve it.
Hope the best for you and your game !
Thank you so much! Glad I could be helpful!
Good luck with your enemies! :D
Whenever you say executor my brain hears "exeggcutor" ...
Great video, though, I enjoy hearing about your thought process :)
I would probably pick Behavior Tree to StateMachine, or go with AdamCYounis state machine design. The statemachine state is resonsible for the “how“ (how to run, attack etc) whereas the behaviour tree is responsible for the “what” (when to run, when to attack etc). But Adam shows in his state machine tutorial also how both can be combined, yet remain modular.
also, I thought Godot can do c# by now?
@@Anerisian Yeah, I think it has c# support, but I haven't looked into it much. Last I looked into it, I saw it wasn't very stable - so I haven't considered it much. Probably worth another glance.
Sounds like that approach is extremely similar to what I've done here - I just called the "behaviour tree" a "state executor" LOL
Liking this format! Also good work on problem solving your mushroom son's behavioural issues 😂 it always comes down to executor function...I mean executive function
He's confused sometimes but he got the spirit heh heh heh
"WHUH! IS A DORA!"
-> subscribed.
Hilarious? Check. Amazing game? Check. Needs more attention😔
Thank you for the kind words, I appreciate it! :)
More modularity is always good, especially with AI.
The code that performs actions should be separate from the code that makes decisions. Someone already mentioned the virtual game pad implementation.
Also states should have separate code for determining when they start and when they end so you don't get enemies with no concept of object permanence. You don't forget the spider you saw in your room the moment it skitters away.
States should generally decide for themselves if they should be on or off and the state executor just decides between them when multiple states decide to be on. Each state has one block of code for turning the state on, and a completely different block of code for deciding when to turn that state off. Fine tune this for your use case.
Also learn about boids. If you're not sure how boids can help you then you don't understand boids well enough.
Maybe you can mix behavior tree with artifical intelligence algorithm for simulating learning. Basically the enemy can literally think and plan and do real time decisions more dynamically.
Just casually bring up fir
He's the goat
@@InboundShovel My goat 🙏🙏
I actually thought you had like mil 2 mil subs😮 why do the great chanels not have subs 😔
Right on man
I mean doesn't godot support C#? Cant you just move your project over to the he c# build
Wait never mind there is already a comment about it
you better make one of those mushrooms a companion or pet or something, or else it's hands /j
I know this is 3 monthes old but wouldnt it work if you made the notice range farther than the range of an attack so the enemy is forced to get into range
What about using Behavior Trees instead of states?
Not sure if Godot has Behavior Trees?
I like the update formula :)
🔥🔥🔥
About GDscript and C#, why dont you use Godot Mono then? If you are better at C# go with that.
I say that with actual experience on it, its amazing, I have the heavy work physics of my Ai, etc all under C# and some of the rest of the code like UI or some quick method calls under GDScript.
That's great advice! I don't know why I never really thought about trying out Godot's C# support, but I think I'll take a look into it now!
Thanks! :)
do you have a discord server :0
I don't currently have a community discord server for the game, but that's a good idea - I'll put it on my to-do list!
Looking slick my guy...BUT 😂
BUT
🌭👋🌭👋🌭👋
it really do be like that sometimes fr fr
AI in general depresses me , Ive even stopped learning code and everything , it feels so pointless .. even forgot I had this interest
Oh, this AI has nothing to do with LLMs or shit like that - it's just the general term for the enemy's brain.
Don't let it stop you from learning to code! It's still a lot of fun to work on interesting design problems - human ingenuity will still win out in the end, haha!
🔥🔥🔥