IMPORTANT: The GDScript project seems to be broken upon first loading. It complains about some classes missing. Until I can figure out why and push up a fix, you can simply do Project -> Reload Current Project and that should fix the issue
To make the upgrade sprites update in the editor on c# version you must mark the upgrade class and the bullet strategies classes as tools, so before the class it is [GlobalClass, Tool], you build the project then reload it and now it will work as Intended
So I'm looking to expand this to also alter player input. For example, I'm using this for a spell system, where I'd like there to be autofiring spells, single click spells, spells you have to charge, etc I can't work out how the referencing should work. I've had to use a resource which holds the bullet (spell) scene and whether it autofires, as I can't reference any of the variables on the packed scene. How should I go about this?
@@tkg__ He is using GDScript so the context is GDSCript. The idea of having half my project in C# another in GDScript and the next time I want a feature from say RUST then another part of the project in RUST or C++. I mean the answer of use C# also isn't really a good one, but it is an answer, I'll give you that.
It's not really godot specific knowledge, it's rather related to programming in generals. There is a book (free in web format) by Robert Nystrom (developer from EA) about design patterns for games. I'm not sure it's allowed to put links here, but you can easily google it.
You can even do with less Boilerplate in C# (also kinda in Godot, but less elegantly, cause the first class functions aren't as strictly typed) In C# you have the Action and Func and with those you can make types that are functions that take in certain types of parameters and return certain types. And with that you don't need the Class + Polymorhpism Boilerplate.
But classes are needed here to store member variables like textures or damage modifiers right? I guess if you don't want to reuse code you can do all that in a function too.
@@AdeelTariq0 You can do that as well with functions, but it can get a bit convoluted. You can make a specialized function that calls the generalized version with it's parameters and the values you want to have by default (thanks to closures). But I have to say, that I ain't sure how you would go about doing it with variables you want to modify in later calls, but maybe I'm just too tired to think correctly right now.
@@AdeelTariq0 there's no reason they are required to be stored together on the same object... and possibly some good reasons for not putting them on the same object. If you need to work with the textures, AND _absolutely nothing else needs that instance of that texture, at all, for anything_, then the class is probably fine. But if multiple modules want to share the same data, then having them fight over some private class data (that's what classes are for; hiding data) is not ideal. There's nothing stopping you from having your data stored on its own, in structs (or Nodes), and passing those bits of data into the functions, at appropriate times. It also means that the code for the functions is just completely portable, if they take arguments, and don't assume anything exists. And there would be no instantiation of them; they're just functions.
Also to note, callables are better than straight up changing the value in more complex games. Also the example is using resources which means if you have multiple things that can take a powerup you will want to create a unique instance of these resources. You could also have a wrapper class which handles storing data and have the resources that handle the strategy though. So for example the apply_update would take 2 arguments (the wrapper and the subject... in this case the bullet) So say the effect is to reduce the cool down time until you can fire the next bullet, but that you want that effect to stack 3 times. this will increase the stack amount from in the resource and adjust the subject as needed with a callable. This then incorporates a mediator pattern which will handle referencing the source of the modifier that way if these modifiers have a duration we can remove its specific effect. The use case for this would be say you have a Ring of Vengeance and a Sword of Vengeance which give an effect Vengeance +3 to attack when you attack. Lets say you want the effect to stack 3 times and refresh when reapplied. You could have the wrapper handle the stacking and duration data, the strategy handle updating that when called and the mediator ensuring the same effect isn't duplicated or throws an exception if you are using a dictionary.
I'm trying to wrap (hah) my head around this but I'm struggling to understand the first sentence, "callables are better than ... changing the value". Wouldn't a value have to be changed at some point?
@@imjust_a Callables store values as pointers, they also come with an object reference. In short you can parse more information for separating out information. Further you have much more flexibility when handling the method of updating the value. For example if when apply_update is called and a stack increases, we can instead of calling the update across the different strategies involved simply update the stack. Assuming the strategy already tracked the wrapper and handled that logic in the original callable we are in turn updating the original value since it is now a pointer. So say you have something like this inside the callable: return _value * stack by increasing the stack the value is updated the next time the previously stored callable is called. This is apart from having to change, remove, add a value again, it also simplifies having multiple sources tracking their various injections to the returned value. Finally you can easily track which object may be throwing bad values from the object id of the callable.
@@imjust_a What if you change the name of the variable of the value that's being called? What if you want the values to be applied the same way? Say every upgrade is multiplicative but you want it to be additive now. If you use Callables, you'd be able to change that in one place, rather than every single instance that was multiplying. Callables are basically a callback function that says "call this function to update some thing when I tell you to". A good way to ensure your code stays more DRY.
@@Dyanosis Oh okay, I see what you're saying! I misunderstood the initial post thinking they meant "don't change a value at all" rather than "passing in a function that handles changing the value results in less work"
this is insanely useful for games whose content is built on modular upgrades. For example, for a card battler game (akin to Slay the Spire) you never know what kind of crazy effect you have to implement at a later date. By making the points of applying the changes more modular (and by use of fitting signals) you can plug in modular effects at any given stage of the game (during draw phase, initiate combat, after combat, on damage taken, on turn end, etc) while the actual base code remain untouched.
I love your Godot videos! I am actually implementing a similar weapon/projectile modifier to a game I'm working on so it's great to see how someone else approaches it.
I was sad that you stopped posting videos for a while because I really like your content on Godot, now I saw this video explaining exactly what I needed for my game, thank you so much, keep uploading pls :)
I'm having problems using stragety patterns atm so this came at the perfect time! I'm right now using c# and Trying to use a Stratgey pattern to make bullet patterns be handeled inside a strategy pattern instead instead of a switch statement, but having trouble firing the bullets when handled using a strategy pattern
Oh wow. I created a whole separate node script that has the class_name Stat, and I have it store a dictionary of modifiers with the keys being a combination of the modifier type with the source name concatenated to the end so that I can remove modifiers via finding them from their source name using .ends_with(source_name). My "supports" and "spirits" as I'm calling them, can also attach modular components to entities (each component of which contains it's own logic for how to integrate with an entity's other components). You gave me some ideas for improving on this, so thanks! If I had to do it over, Stat wouldn't be a node, it would be a resource and each thing that needed to care about a stat, would either have individual Stat resources, or it's own child node containing a specific package of Stat resources designed for use together. I have this all working, btw, and I can't wait to finally iterate enough on the game to make it presentable.
I'd love to see more videos like this as someone just getting into Godot. But even for people not using Godot, these are very helpful in just breaking down common ways of handling problems that we may not have heard of. I hadn't considered nor heard of this way of doing things before.
This is a really great video. Thanks for putting in the effort to lay it out so clearly! I really appreciate the two halves of sample code at the beginning and real world example later on. I have personally found this technique to be an interesting tradeoff. When you have a good idea of the ways your game will be extensible then it's really valuable. Just like in your example, things like weapon upgrades are quite predictable. I've run into issues however when I've incorrectly predicted the ways I'll want to change the code and have wished I hadn't engineered an extra layer of abstraction. Thanks again for the vid, looking forward to more!
may I ask how you make the coding animation ? they looks so clean and beautiful ! 00:50 to 02:16 by the way. your videos are one of the best Godot tutorials !! Thank you!
I use MotionCanvas, by Aarthificial. The animations are made using code and you can find out more at motioncanvas.io/ Thanks for compliment on the visuals by the way!
I'm applying this sort of modifier to a game right now with GRScript and got a little stuck by not being able to make abstract interfaces. This cleared it up for me quickly and even included the confusing GUI part of Godot, so thank you!
@bitlytic I can tell you're talented and a good teacher. Are you gonna make a full tutorial playlist for a game? I feel like that's a really good way to learn a lot and tie it all together. Even if it's a small project. Just a thought, thanks for the great videos!
Great Video! I really like this kind of tutorials and I’ve understood everything, but I have a question: How did you colorcode your folders inside of the Godot editor?
I remembered struggled for a few weeks and came to a solution like this Not sure how I feel now a better solution lays before me lol, keep up the good work
hi, your video tutorial about finite state machines and node composition helped me a lot with my game development, this tutorial is actually also applicable to my game and gave an idea, hope you make a inventory system tutorial
Doesn't the Simple list example make you skip numbers? The elements shift but it continues at the same index. So if you have two elements after each other that should be removed it will only remove the first one.
For Those who are completely new/lost after downloading - you need to setup The input map for "move_up" "move_down" "move_left" and "move_right". AND "primary_fire". I downloaded the project and the could not move my player. Looking in "player_movement" Script - I saw that the input map(s) for moving were not created. Looking in "player_weapon" Script - I saw that "primary_fire" was not in the Input Mappings. Once I mapped all of the above, the project worked normally.
I was thinking about a way to make an upgrade that has other upgrades' functionallity, like a firework that has the particles and an explosion hit. I thought of something like a `CompoundUpgrade` thing that you can just insert multiple upgrades in it and make it use each one of the upgrades.
This is ingenious! I had been trying to figure out how to do something like this but wasn't even able to articulate it in a search. The main thing that I had been getting hung up on was how to dynamically add upgrades instead of checking the Player for every possible upgrade. Using an array is such an elegant approach.
This pattern can be made much simpler by using Callables instead of explicit classes. Instead of writing an entire class just to hold a function, just pass in a Callable and store all of your "common" ones somewhere as variables. This means you don't need new classes for every new type of "strategy", you just make a new function and pass it in.
GDScript has first class functions, so you don't need a whole class with a method to do this. The number filter example can be written like this: ``` func is_odd(x): return x % 2 != 0 # return a new list containing only the elements of the input # for which the filter function returns true func filter_list(list, filter): var out = [] for x in list: if filter.call(x): out.append(x) return out var list = [-4, -2, 0, 4, 5] print(filter_list(list, is_odd)) ``` Similarly with the upgrades, you can make the strategies functions instead of classes, then replace strategy.apply_upgrade(bullet) with strategy.call(bullet). Admittedly you don't get all the cool editor integration though. But it's nice if you want a simple, low boilerplate solution.
It should be stated, that 99% of using this pattern is reliant on FIRST HAVING A STRATEGY. Spend the time to draw out the interactions between your logic and then go ahead and run with this, you'll thank yourself later that week/month.
I think the decorator pattern may be a better fit for this particular use case. Strategy is better for replacing logic where as decorator adds on top of existing logic.
Great video clear and concise. I have a question unrelated to the strategy pattern. I'm a bit confused about the move_toward and lerp functions in Godot. i want to convert the velocity.move_toward(direction * MAX_SPEED, (1.0 / acceleration_time) * delta * MAX_SPEED) function to use lerp instead should it be like this velocity = velocity.lerp(direction * MAX_SPEED, (1.0 / acceleration_time) * delta) ?
I'm new to godot, so have I understood this correctly? What I understand: Basically a resource holds values, in this case a class object, which is appended to an array in the player when it is picked up.
So if i understand this correct you just make 1 base bullet scene with a script and then for each other upgrade you make different scripts that extend the base bullet script? Sorry im a noob but im trying to wrap my head arround it. Awesome video!
No, he makes 1 base bullet scene, then when spawned a reference of that bullet is passed to the resources which changes the parameters of that bullet. It does not extend the bullet class, it changes it.
Great video. I am a software developer, but new to game dev. I have a question: why not use the decorator pattern? It sounds a bit more adequate to this situation since you are adding multiple changes to the object
I've seen a couple recommendations for the decorator pattern and the simple answer is a gap in my knowledge, any resources you'd recommend for learning more about it?
@@Bitlytic there is plenty of resources about it, if you want example without UML diagrams mess search for example "baeldung decorator pattern". Example is in Java (C# predecessor so syntax would be familiar for you). But in short, if your bullet would be immutable (no setter for damage) then you would need to create wrapper over bullet which calls damage getter on wrapped bullet and adds bonus to it. In such case original bullet damage won't be changed but wrapped (outer) bullet will return increased damage. It doesn't make sense in Godot because your bullet is not immutable, you don't have real "private" keyword, and in general immutability is not a thing in game dev industry where you already spawning thousands of bullets and can't afford to double that number. Contrary to IT systems where we don't have a lot of allocations but we have dozens of interconnected components - in such systems immutability is crucial because one component changing some variable can break stuff in other components.
@@Bitlytic I've seen it's explained inside the book "Design Patterns" by the so-called "gang of four". Haven't read it myself (yet), but as far as I know it's quite popular. Even though it's not gamedev oriented, it might be a good resource.
So I'm trying to extend this and I'm running into a problem I can't figure out a way around. I'm using it for a modular spell system. If I use packed scenes, I can't reference their variables as they aren't created yet. For example, different kinds of spells will autofire, some will charge to cast, etc. So instead I tried to store the spell as a resource, and then the resource can hold all the variables as well as the packed scene. But then in the packed scene, the script can't reference the variables as they're in that resource object. Any way around this?
Crazy coincidence for me to be working on exactly this. I see you built piercing into your base bullet class, is there a good way to have an upgrade override a default behavior like hitting a wall or enemy? For instance in my project i made an upgrade where the bullet sticks to an an enemy, which would replace the default on_hit_destroy_self, but piercing would also replace it, but should stack with the sticking ability... I had an idea to split on_hit into two separate events, on_hit and on_hit_final, or something, but I'd love to get some input on how you might structure this, and when to put things in the base class or not.
I'm just watching this randomly browsing on youtube, don't know much about Godot or GDScript, but does it not just have callbacks/first class functions? Rather than all this boilerplate, wouldn't it just be easier to make an array of functions and just call them 1 by 1 or compose them?
So why shouldn't we just use instanced scene nodes for this? One node with funcs to handle all of this in one place without any unnecessary layers of abstraction. Put it under whatever you need the functionality in, then call it from the parent node when needed.
What I keep struggling with is Multishot and having all the bullets properly carry the properties. (What about multiple.multishots?). Or modifiers that also change the bullets trajectory (homing for example). Is there anywhere where I could read about this?
If you want to have modular and custom features like fire damage, special explosions and such, your base classes will just keep growing it size. Look into composition as well
It's not _particularly an object oriented programming pattern._ OOP is not even a necessity here. If anything, strategy pattern uses composition over inheritance.
Personally not a fan of making lots of little classes. Instead, I prefer a data-driven approach, where all the data is in tables/json, and the effect class(es) can handle anything coming at it. Also makes the game inherently moddable, and it's much easier to add new effects later if they're a combination of existing effects.
I got hung up on the filtering of lists. Are you even doing that in the real-world use case? I was distracted by that example and was looking for how that has to do with changing firing actions in the game when it looks like it doesn't in the end.
Why... why does everyone try to make everything OOP? There is zero reason for this. This modular approach can be accomplished without any inheritance, interfaces, or polymorphism, and it will be waaay more readable. Sorry, I'm voting no on this one.
IMPORTANT:
The GDScript project seems to be broken upon first loading. It complains about some classes missing. Until I can figure out why and push up a fix, you can simply do Project -> Reload Current Project and that should fix the issue
To make the upgrade sprites update in the editor on c# version you must mark the upgrade class and the bullet strategies classes as tools, so before the class it is [GlobalClass, Tool], you build the project then reload it and now it will work as Intended
Resave the class that it complains about, this fixed it for me
So I'm looking to expand this to also alter player input. For example, I'm using this for a spell system, where I'd like there to be autofiring spells, single click spells, spells you have to charge, etc
I can't work out how the referencing should work. I've had to use a resource which holds the bullet (spell) scene and whether it autofires, as I can't reference any of the variables on the packed scene.
How should I go about this?
godot really needs more tutorials like this.
I will try my hand at this too, but so happy to see good quality tutorials
And interfaces.
@@dibaterman it has interfaces. You can use C#.
@@tkg__
He is using GDScript so the context is GDSCript. The idea of having half my project in C# another in GDScript and the next time I want a feature from say RUST then another part of the project in RUST or C++.
I mean the answer of use C# also isn't really a good one, but it is an answer, I'll give you that.
It's not really godot specific knowledge, it's rather related to programming in generals. There is a book (free in web format) by Robert Nystrom (developer from EA) about design patterns for games. I'm not sure it's allowed to put links here, but you can easily google it.
I understand barely anything, but i have faith that with practice this is gonna be so helpful
Found your channel in the comments section of Brackies, and am blown away at how good your videos are... Keep it up! 💙
You can even do with less Boilerplate in C# (also kinda in Godot, but less elegantly, cause the first class functions aren't as strictly typed)
In C# you have the Action and Func and with those you can make types that are functions that take in certain types of parameters and return certain types. And with that you don't need the Class + Polymorhpism Boilerplate.
Wait what?
But classes are needed here to store member variables like textures or damage modifiers right? I guess if you don't want to reuse code you can do all that in a function too.
@@AdeelTariq0 You can do that as well with functions, but it can get a bit convoluted. You can make a specialized function that calls the generalized version with it's parameters and the values you want to have by default (thanks to closures). But I have to say, that I ain't sure how you would go about doing it with variables you want to modify in later calls, but maybe I'm just too tired to think correctly right now.
true! but godot 4 has Callables that could be used, too
@@AdeelTariq0 there's no reason they are required to be stored together on the same object... and possibly some good reasons for not putting them on the same object. If you need to work with the textures, AND _absolutely nothing else needs that instance of that texture, at all, for anything_, then the class is probably fine. But if multiple modules want to share the same data, then having them fight over some private class data (that's what classes are for; hiding data) is not ideal. There's nothing stopping you from having your data stored on its own, in structs (or Nodes), and passing those bits of data into the functions, at appropriate times. It also means that the code for the functions is just completely portable, if they take arguments, and don't assume anything exists. And there would be no instantiation of them; they're just functions.
another useful modular coding pattern to add to our toolset
these tutorials are very helpful and well planned out, thank you ^^
Also to note, callables are better than straight up changing the value in more complex games.
Also the example is using resources which means if you have multiple things that can take a powerup you will want to create a unique instance of these resources.
You could also have a wrapper class which handles storing data and have the resources that handle the strategy though.
So for example the apply_update would take 2 arguments (the wrapper and the subject... in this case the bullet)
So say the effect is to reduce the cool down time until you can fire the next bullet, but that you want that effect to stack 3 times.
this will increase the stack amount from in the resource and adjust the subject as needed with a callable.
This then incorporates a mediator pattern which will handle referencing the source of the modifier that way if these modifiers have a duration we can remove its specific effect.
The use case for this would be say you have a Ring of Vengeance and a Sword of Vengeance which give an effect Vengeance +3 to attack when you attack.
Lets say you want the effect to stack 3 times and refresh when reapplied.
You could have the wrapper handle the stacking and duration data, the strategy handle updating that when called and the mediator ensuring the same effect isn't duplicated or throws an exception if you are using a dictionary.
I'm trying to wrap (hah) my head around this but I'm struggling to understand the first sentence, "callables are better than ... changing the value". Wouldn't a value have to be changed at some point?
@@imjust_a
Callables store values as pointers, they also come with an object reference. In short you can parse more information for separating out information. Further you have much more flexibility when handling the method of updating the value.
For example if when apply_update is called and a stack increases, we can instead of calling the update across the different strategies involved simply update the stack.
Assuming the strategy already tracked the wrapper and handled that logic in the original callable we are in turn updating the original value since it is now a pointer.
So say you have something like this inside the callable:
return _value * stack
by increasing the stack the value is updated the next time the previously stored callable is called.
This is apart from having to change, remove, add a value again, it also simplifies having multiple sources tracking their various injections to the returned value.
Finally you can easily track which object may be throwing bad values from the object id of the callable.
@@imjust_a What if you change the name of the variable of the value that's being called? What if you want the values to be applied the same way? Say every upgrade is multiplicative but you want it to be additive now. If you use Callables, you'd be able to change that in one place, rather than every single instance that was multiplying.
Callables are basically a callback function that says "call this function to update some thing when I tell you to". A good way to ensure your code stays more DRY.
@@Dyanosis Oh okay, I see what you're saying! I misunderstood the initial post thinking they meant "don't change a value at all" rather than "passing in a function that handles changing the value results in less work"
this is insanely useful for games whose content is built on modular upgrades.
For example, for a card battler game (akin to Slay the Spire) you never know what kind of crazy effect you have to implement at a later date.
By making the points of applying the changes more modular (and by use of fitting signals) you can plug in modular effects at any given stage of the game (during draw phase, initiate combat, after combat, on damage taken, on turn end, etc) while the actual base code remain untouched.
Very nice exploration of using the pattern. Thank you!
Super informative video, really appreciate it! Thanks!
Awesome i love design patterns in godot
I love your Godot videos! I am actually implementing a similar weapon/projectile modifier to a game I'm working on so it's great to see how someone else approaches it.
I was sad that you stopped posting videos for a while because I really like your content on Godot, now I saw this video explaining exactly what I needed for my game, thank you so much, keep uploading pls :)
Great video! Appreciate the fact that the samples are available to look at to dissect and learn!
Hopefully will wrap my head around it with enough practice
"Sorry cant make it new Bitlytic video just dropped!!"
This is some top-tier genius level content right here and in less than 7 minutes. You explained this so well and succinctly
this is actually so good it's insane
You are literally the best!
I'm having problems using stragety patterns atm so this came at the perfect time!
I'm right now using c# and Trying to use a Stratgey pattern to make bullet patterns be handeled inside a strategy pattern instead instead of a switch statement, but having trouble firing the bullets when handled using a strategy pattern
Oh wow. I created a whole separate node script that has the class_name Stat, and I have it store a dictionary of modifiers with the keys being a combination of the modifier type with the source name concatenated to the end so that I can remove modifiers via finding them from their source name using .ends_with(source_name). My "supports" and "spirits" as I'm calling them, can also attach modular components to entities (each component of which contains it's own logic for how to integrate with an entity's other components).
You gave me some ideas for improving on this, so thanks!
If I had to do it over, Stat wouldn't be a node, it would be a resource and each thing that needed to care about a stat, would either have individual Stat resources, or it's own child node containing a specific package of Stat resources designed for use together. I have this all working, btw, and I can't wait to finally iterate enough on the game to make it presentable.
This is incredibly useful information. Thank you for sharing.
great videos , wish you would post more often, your videos are very easy to understand for a complete beginner like me, i need mooore
I'd love to see more videos like this as someone just getting into Godot. But even for people not using Godot, these are very helpful in just breaking down common ways of handling problems that we may not have heard of. I hadn't considered nor heard of this way of doing things before.
You have the best videos on these coding topics that I have ever come across in my 6+ years of coding. Seriously, thank you.
This is a really great video. Thanks for putting in the effort to lay it out so clearly! I really appreciate the two halves of sample code at the beginning and real world example later on. I have personally found this technique to be an interesting tradeoff. When you have a good idea of the ways your game will be extensible then it's really valuable. Just like in your example, things like weapon upgrades are quite predictable. I've run into issues however when I've incorrectly predicted the ways I'll want to change the code and have wished I hadn't engineered an extra layer of abstraction. Thanks again for the vid, looking forward to more!
You helped me fix a problem I didn't know I had!
amazing video, and thanks for including the source code it makes it so easy for us to experiment on these concepts and learn!
The tutorial that I need, thx man this help me a lot
fantastic explanation! I'll definitely use this for my game, thanks!
may I ask how you make the coding animation ?
they looks so clean and beautiful ! 00:50 to 02:16
by the way. your videos are one of the best Godot tutorials !! Thank you!
I use MotionCanvas, by Aarthificial. The animations are made using code and you can find out more at motioncanvas.io/
Thanks for compliment on the visuals by the way!
@@Bitlytic thanks for your light speed response!!
I'm applying this sort of modifier to a game right now with GRScript and got a little stuck by not being able to make abstract interfaces. This cleared it up for me quickly and even included the confusing GUI part of Godot, so thank you!
I just started learning godot and you have some of the best tutorials out there. thank you so much
Your tutorials are simple, coherent, and extremely helpful! You're a great teacher.
@bitlytic I can tell you're talented and a good teacher. Are you gonna make a full tutorial playlist for a game? I feel like that's a really good way to learn a lot and tie it all together. Even if it's a small project.
Just a thought, thanks for the great videos!
This is cool. Thank you!
Damn, that's a good tut! Would've been really useful when I begun work on roguelike :D
Your videos are so good. I just set my notification on now.
Great Video! I really like this kind of tutorials and I’ve understood everything, but I have a question: How did you colorcode your folders inside of the Godot editor?
I remembered struggled for a few weeks and came to a solution like this
Not sure how I feel now a better solution lays before me lol, keep up the good work
love modular stuff
Thank you! Very useful, nice explanation and presentation! I was wondering for a long time how you would implement upgrades in a game.
you sir are a scholar and a gentleman and a freaking awesome teacher ! thank you !
Thank you for this, I had a clunky and cumbersome implementation of this, now I can go back and upgrade it ! ;)
Man I love your stuff.
Really great, thanks! Even if I had to slow it down to .75 speed :-)
hi, your video tutorial about finite state machines and node composition helped me a lot with my game development, this tutorial is actually also applicable to my game and gave an idea, hope you make a inventory system tutorial
this really helps me a lot, thank you
I can watch this whole day ... :)
Thank you for making this tutorial!
Doesn't the Simple list example make you skip numbers? The elements shift but it continues at the same index. So if you have two elements after each other that should be removed it will only remove the first one.
For Those who are completely new/lost after downloading - you need to setup The input map for
"move_up" "move_down" "move_left" and "move_right". AND "primary_fire".
I downloaded the project and the could not move my player.
Looking in "player_movement" Script - I saw that the input map(s) for moving were not created.
Looking in "player_weapon" Script - I saw that "primary_fire" was not in the Input Mappings.
Once I mapped all of the above, the project worked normally.
I was thinking about a way to make an upgrade that has other upgrades' functionallity, like a firework that has the particles and an explosion hit. I thought of something like a `CompoundUpgrade` thing that you can just insert multiple upgrades in it and make it use each one of the upgrades.
This is essentially the open/closed principle from the SOLID principles (en.wikipedia.org/wiki/SOLID), but it makes so much sense to apply it here.
Great video, thanks. What do you use to edit you videos, the code examples look really neat.
This is ingenious! I had been trying to figure out how to do something like this but wasn't even able to articulate it in a search.
The main thing that I had been getting hung up on was how to dynamically add upgrades instead of checking the Player for every possible upgrade. Using an array is such an elegant approach.
welcome back!
Are you using motion canvas for your video presentation?
Yep, I absolutely love it
Pls continue your tutorials. They are awesome.
This pattern can be made much simpler by using Callables instead of explicit classes. Instead of writing an entire class just to hold a function, just pass in a Callable and store all of your "common" ones somewhere as variables. This means you don't need new classes for every new type of "strategy", you just make a new function and pass it in.
GDScript has first class functions, so you don't need a whole class with a method to do this.
The number filter example can be written like this:
```
func is_odd(x):
return x % 2 != 0
# return a new list containing only the elements of the input
# for which the filter function returns true
func filter_list(list, filter):
var out = []
for x in list:
if filter.call(x):
out.append(x)
return out
var list = [-4, -2, 0, 4, 5]
print(filter_list(list, is_odd))
```
Similarly with the upgrades, you can make the strategies functions instead of classes, then replace strategy.apply_upgrade(bullet) with strategy.call(bullet). Admittedly you don't get all the cool editor integration though. But it's nice if you want a simple, low boilerplate solution.
Pretty interesting stuff
wow, thank you !
at the beginning it truly was a strategy pattern, but in the project example it's decorator )
Please keep up with C# inclusion if possible, a cool guide!
It should be stated, that 99% of using this pattern is reliant on FIRST HAVING A STRATEGY.
Spend the time to draw out the interactions between your logic and then go ahead and run with this, you'll thank yourself later that week/month.
I think the decorator pattern may be a better fit for this particular use case. Strategy is better for replacing logic where as decorator adds on top of existing logic.
Wow, that’s cool
Do you plan on making any Motion Canvas tutorials in the future? I was looking around but couldn't find many tutorials :p
THANK YOU
Thanks mate!
Great video clear and concise.
I have a question unrelated to the strategy pattern. I'm a bit confused about the move_toward and lerp functions in Godot.
i want to convert the velocity.move_toward(direction * MAX_SPEED, (1.0 / acceleration_time) * delta * MAX_SPEED) function to use lerp instead should it be like this velocity = velocity.lerp(direction * MAX_SPEED, (1.0 / acceleration_time) * delta) ?
I love this video presentation, i see you use canvas motion, how you get the style code gdscript?
im here from brackies!!!
honestly, the most important thing I took from this video is that you can COLOR YOUR FOLDERS IN THE FILE SYSTEM!?!?
I'm new to godot, so have I understood this correctly?
What I understand: Basically a resource holds values, in this case a class object, which is appended to an array in the player when it is picked up.
So if i understand this correct you just make 1 base bullet scene with a script and then for each other upgrade you make different scripts that extend the base bullet script? Sorry im a noob but im trying to wrap my head arround it. Awesome video!
No, he makes 1 base bullet scene, then when spawned a reference of that bullet is passed to the resources which changes the parameters of that bullet. It does not extend the bullet class, it changes it.
Great video. I am a software developer, but new to game dev. I have a question: why not use the decorator pattern? It sounds a bit more adequate to this situation since you are adding multiple changes to the object
I've seen a couple recommendations for the decorator pattern and the simple answer is a gap in my knowledge, any resources you'd recommend for learning more about it?
@@Bitlytic there is plenty of resources about it, if you want example without UML diagrams mess search for example "baeldung decorator pattern". Example is in Java (C# predecessor so syntax would be familiar for you).
But in short, if your bullet would be immutable (no setter for damage) then you would need to create wrapper over bullet which calls damage getter on wrapped bullet and adds bonus to it. In such case original bullet damage won't be changed but wrapped (outer) bullet will return increased damage.
It doesn't make sense in Godot because your bullet is not immutable, you don't have real "private" keyword, and in general immutability is not a thing in game dev industry where you already spawning thousands of bullets and can't afford to double that number. Contrary to IT systems where we don't have a lot of allocations but we have dozens of interconnected components - in such systems immutability is crucial because one component changing some variable can break stuff in other components.
@@Bitlytic I've seen it's explained inside the book "Design Patterns" by the so-called "gang of four". Haven't read it myself (yet), but as far as I know it's quite popular. Even though it's not gamedev oriented, it might be a good resource.
Thank you
So I'm trying to extend this and I'm running into a problem I can't figure out a way around.
I'm using it for a modular spell system. If I use packed scenes, I can't reference their variables as they aren't created yet.
For example, different kinds of spells will autofire, some will charge to cast, etc. So instead I tried to store the spell as a resource, and then the resource can hold all the variables as well as the packed scene. But then in the packed scene, the script can't reference the variables as they're in that resource object.
Any way around this?
Crazy coincidence for me to be working on exactly this. I see you built piercing into your base bullet class, is there a good way to have an upgrade override a default behavior like hitting a wall or enemy? For instance in my project i made an upgrade where the bullet sticks to an an enemy, which would replace the default on_hit_destroy_self, but piercing would also replace it, but should stack with the sticking ability...
I had an idea to split on_hit into two separate events, on_hit and on_hit_final, or something, but I'd love to get some input on how you might structure this, and when to put things in the base class or not.
I'm just watching this randomly browsing on youtube, don't know much about Godot or GDScript, but does it not just have callbacks/first class functions?
Rather than all this boilerplate, wouldn't it just be easier to make an array of functions and just call them 1 by 1 or compose them?
So why shouldn't we just use instanced scene nodes for this? One node with funcs to handle all of this in one place without any unnecessary layers of abstraction. Put it under whatever you need the functionality in, then call it from the parent node when needed.
Dude! Can you make a tutorial on using Dice for Dice-Placement purposes?
What I keep struggling with is Multishot and having all the bullets properly carry the properties. (What about multiple.multishots?).
Or modifiers that also change the bullets trajectory (homing for example).
Is there anywhere where I could read about this?
If you want to have modular and custom features like fire damage, special explosions and such, your base classes will just keep growing it size. Look into composition as well
Smooth video. The first half was interesting but then everything after that did not have enough context for me.
Isn't this just polymorphism?
Pretty much, I wanted to explain it in a way that applies to games
Yes, but this is particularly an object oriented programming pattern, which, you guessed it, incorporates oop principles.
@@mpmedia6735 Literally the same thing can be done in functional languages like haskell
It's not _particularly an object oriented programming pattern._ OOP is not even a necessity here. If anything, strategy pattern uses composition over inheritance.
@@ultimaxkom8728 Wait till you learn that composition is, in fact, also part of OOP and that OOP is not only inheritance
Isn't this pretty much like the command pattern? Im not sure I see the difference.
Heya!
Godot needs interfaces, someone can explain why interfaces don't exist in Godot?
Can you make tutorial on pseudo 3d
Neat thx
Personally not a fan of making lots of little classes. Instead, I prefer a data-driven approach, where all the data is in tables/json, and the effect class(es) can handle anything coming at it. Also makes the game inherently moddable, and it's much easier to add new effects later if they're a combination of existing effects.
STOP MAKING VIDEOS THAT MAKE ME RETHINK MY WHOLE PROJECT! 😅😅 Seriously helpful video tho!
Please , tutorial platform2d system building 🙏🙏please
I got hung up on the filtering of lists. Are you even doing that in the real-world use case? I was distracted by that example and was looking for how that has to do with changing firing actions in the game when it looks like it doesn't in the end.
Wait, but C# in godot doesn't support interfaces right?
Why... why does everyone try to make everything OOP? There is zero reason for this. This modular approach can be accomplished without any inheritance, interfaces, or polymorphism, and it will be waaay more readable. Sorry, I'm voting no on this one.
Why do you call these things a "strategy"?
☝️🤓 errm aktuwally this is more of a command pattern than stwategy :3