If you're interested, here's where you can wishlist Isadora's Edge on Steam! store.steampowered.com/app/3125320/Isadoras_Edge/ And you can follow the Kickstarter here: www.kickstarter.com/projects/inboundshovel/isadoras-edge Thank you!
what if you made 1 projectile that gets destroyed on impact, and its destruction runs a script that can spawn a new projectile or attach a sprite to the object it hit? Then projectiles could bounce or stick or change type or spawn multiple projectiles or cause status effects or whatever you want on contact, but the update loop for each projectile doesn't have to branch on so many status questions, it just has a projectile type integer and animation frame integer to keep track of, and when it hits, you go through a switch case based on type to select an action. A projectile that isn't moving, is a waste of velocity and acceleration data, it should be converted to a sprite, and removed from the projectile list. all projectiles can be updated in a simple loop that just applies each velocity to each position, Then a different loop checks for the collisions of all the positions, then another loop runs all the scripts that were triggered by collisions, then another loop spawns all the objects cued up to spawn by the collision scripts.
Actually not at all a problem if you are using the engine's built-in physics. Also not at all hard to solve anyway as long as you know a little trigonometry.
My scripts usually turn out generics accidentally. Like I also had to make a projectile, then I needed another projectile... But rather than writing the code for it again, I sort of thought "wait, I already wrote a similar thing, let me just build on that"
The deep dive wasnt boring at all, actually I think it really helpful. Not only was showing the process really interesting to watch, it added to your point in a pretty obvious and easy to understand way. Great video, well done!
Some of the most difficult parts about initially learning how to code are questions like these. "What is the end result of what I'm trying supposed to look like?" "Am I doing something in a complex way that should be simple?" "Is this process even necessary or on the right track to what I need?" This kind of video answers a LOT of that, but in a way that's helpful. By getting to see the full process, with everything from you talking about how quick prototyping is helpful to how/when/why you shifted into using a more universal system, and everything between, it gives a great perspective on what to aim for, how to work, and what to work towards. Especially those sections where you talk about about implementing features into the node... You explained what each function is for, why you put them there, and importantly you showed what it LOOKS like when it's fully put together. That's the part less-good coders than you can have a really hard time with. Without seeing an end-result of what a really good system ultimately would look like, it's hard to know where to go. And on top of that, you showed examples of what it looks like in-game giving a 'why' for it all, applying it directly to a project. Even the part where you talked about implementing a signal for 'if/when something might come up' and don't have a use for it yet. That's the thing about being new to coding... EVERYTHING is an 'if/when something might come up.' And it's hard to know where to go or how to implement 'if/when' chunks of code, and what the CODE ITSELF should LOOK like when something IS implemented. You showed that, and it clears up SO MUCH. That's the kind of stuff that helps the most for people trying to learn how to do any number of things too, even for things completely unrelated to projectiles, or even if they're not using Godot, it's brilliantly conveying the process AND end goal of what it's all for, what it looks like when done well, and why you'd do it that way. There are countless tutorials. "This is how to make a projectile do X." Followed by showing the coding process for how to make that happen, how to iterate upon it, what else it can be used for. But there are SO FEW informative resources for how to iterate on something like the CODE itself, a node, a system, anything. It's easy to imagine what the projectile looks like when it's doing 'X' and so it's easy to know when the code is working. But it's hard to imagine what a system/node/code/signal/etc FOR that code actually should LOOK like when it's fully applied. What you did here is the kind of thing actually gives something STRIVE for, whether for a new-coder or someone more experienced. Like, I legitimately know for sure that if I manage to code something that LOOKS like what you've built here, with all the options and the layout you've made for yourself, and if I make it FUNCTION with even part of what you've implemented, that I'll not only have DONE something useful and helpful in terms of a good result, but I'll ALSO know how to code better, I'll BE BETTER at making good-quality systems/nodes/anything and everything else that I'll need to learn how to do. I can't say that after learning from most tutorials because they lack the entire context of what the full code of some big system (like a projectile node) looks like and blends with the rest of an entire game. I can say that after watching your video here and trying to replicate it. I might need to watch tutorials for how to do some of it, but getting to see what yours LOOKS like and trying to make something that looks and functions like it... that's way better. You talking about the whole thing and showing what the node looks like (in-engine) along with what it looks like in play (in-game) is better than a tutorial. I could stay up all night trying to figure out how to do what you did here. I won't because sleep is good. haha But I could easily dedicate this entire month to this. "How do I make a Node that looks and functions like Kenneth's?" Because you did it for yourself, I know it's a good thing to try doing, it's a good target and practice and worth doing, AND most importantly I got a glimpse as to what it SHOULD look like when done because you showed the tangible Node itself and how it works in-engine and in-game at once. So now I actually have something clear to aim for, I can know when something isn't working, I can keep trying things because if there are parts you've made here that I haven't figured out or implemented to my own Node attempts yet then I know I have more work to do and it will BE FOR something I KNOW I'll benefit from. There are only a handful of S-tier videos in every context. In the context that this video falls into, in a landscape of tutorials about how to do things in-game and showing the process of coding how to do it, but a lack of showing what a well-built, easily-usable, polished and extremely useful type of system with all sorts of unique applications looks like... you showing what that kind of finished system of code looks like and how to put it together that way and why... This is S-tier, Kenneth. Good stuff.
I might make "Generic Projectile Physics Controller" my first ever big project with learning coding. I don't have anything 'specific' that I need it for at the moment, but this video alone is just that good in terms of giving a tangible target. It presented a high-enough level in-engine system for making features work in-game in complex ways, requires skills that will most definitely translate to making more things like it long-term, and I got to see the end-game of the code matched with the end-game of the game-play it's built for, all at once. Woop Time to get to work/playing! Also... *improvised-dance high-five from across the world
Love it. Just wanted to tell you that your content genuinely help me a ton as I'm building mu own game. Please, keep going, this is actually priceless. Your charisma and pacing are top notch!
That's why you should always start thinking about your game code architecture from start. Use c#, make interfaces, abstract classes...etc. It seems tedious for a beginners, but it just saves your monthes/years of work in the long run.
I’m an object orientated software engineer by trade and C# is not necessary for Godot to have a clean architecture. You don’t need all those interfaces/abstractions as long as you using GDScript’s static typing and properly follow node composition.
Interfaces have also been a godsend lately for handling simple behaviours that can vary depending on the object/entity. Like having an IDamageable or IKnockbackable or others and having the objects that use those interfaces override the abstract functions of the interface. Instead of testing for each kind of enemy or projectile when doing an attack, just checking if the entity/projectile implements the interface and then calling the function. That has saved me so much time lately when solo developing in Unity. Also love to see the progress! As always very fascinated and inspired by your videos.
Very helpful. I am very new to game dev and for some reason couldn’t get my head around how you could use premade projectile node and have be then specialized for each instance without screwing with the other spots it’s used. But seeing how you have @export all the variables made me realize that the exporting allows you to alter values without altering the script.
I would love to see a video on how you implement attacks for the enemies, if it's not just straight "Let's just hardcode it into the enemy class", since I'm currently trying to wrap my head around that. The problematic part is that I wanna make my attacks modular, so in theory any enemy could use any attack...
I'm working on a frame data system so that I can easily and generically add frame data to the enemy's attacks! It's still somewhat hard-coded (since I'm adding the frame data directly into the enemy attack animations), but I'll see what I can cook up on that front video-wise!
when i built my first game i made everything with a damage hitbox use the same code, or rather, my player character had both a gun and a sword, the enemies projectiles used the same code as the players projectiles, exept their hitbox was flipped in a way that they hurt the player and are not capable of friendly fire with the same enemy type, and funnier thing was the players sword, which only had 2 animation frames for the character swinging! one for anticipation, and the other for the swing itself! the heavy lifting of that animation was the smear of the sword, which was a projectile with 0 velocity! yeah, it allowed me to do some great stuff, like having 2 different types of animations, one when you swing into thin air, the another when you hit something!
Hello! I am new to your channel. I really like it because you talk about really specific challenges in a comprehensive manner. I am a total beginner in godot but I understand what you are talking about. Showing it in the editor is the cherry on top. Super cool and not boring at all! I love that deeper dive. It scratches my brain the right way :D
New hobby dev starting on godot stuff and I am absolutely loving vids like this! Sub time for sure. I love seeing your process and it is really making me think about how I am doing things! Thanks!
something learned the hard way too, if you have at least 2 pieces of code with some similarities, no matter how small you better encapsulate it in a single system or function, saves a lot of time in the long run
The rule of three feelse relevant here. If you do it once just get it done. If you do it twice take note. If you do in three times you need a proper solution.
while working on my own game, to keep the files smaller and scrollable. I started needing to maintain a separate document to make me remember how everything works lol. Great video makes me remember i also need to make my own generic movement handler lol.
My system for avoiding this is to create two test areas when I start my project (though I haven't truly finished any, so this might not be as great as it seems right now). The first one is where I test ideas to see if they work. That area winds up being 99% jank by the end of the project. The second one is where I implement the idea in a "production-ready" form. Any code/design/whatever that I use there is implemented in the same way as the rest of the game. That gives me a baseline to test things against. So if I notice a weird behavior with an object (like a projectile), I can find out if it's in the base class or the subclass I made for that implementation. I've also had a couple cases where I realized the only way to implement a feature was pure jank (due to engine limitations, other constraints, etc). So I had to decide if I really wanted that feature or not, knowing that would be the case. A famous example of this is in a finished game the Fast Inverse Square Root, which was brilliant, but very janky from a programming perspective (and definitely worth learning about if you don't already know the story).
Nice refactor 💪 Suggestion to make it even more solid: Make the definitions for shared behavior values into a Resource type - e.g. ProjectileBehaviorResource. Then you can have a single access point (for each projectile type) for all your properties which every instance will reference (e.g. your speed float exists on the resource and the ProjectileController node just reads the value from its Resource), rather than the properties existing on the instances. Then you can change values at runtime and all projectiles sharing that Resource will update. Also technically more efficient since they’re all pointing to the same spot in memory. Now that your architecture is the way it is, taking this extra step would be a quick refactor. Hope that helps!
This looks like a fun game and the video was pretty informative. Got my attention even though I know nothing about making games or programming. Very cool.
Great video! Very helpful on the parameters, I have a similar system in my game but this video made me realise it's really lacking in the parameter department haha, now to add all of this...
I always start the other way around. Make the generic system before the specifics, but i usually go the inheritance way instead of the configuration way
funny seeing someone else just stumble into something 90% like the projectile controller I've used for years now, with all the same booleans and behaviors. once you start reusing and expanding these systems from earlier projects you never get the urge to put together quick hacks anymore. the PTSD of fixing them stays with you lmao
okay i'll say this once and i'll say it again. your game is absolutely GORGEOUS dude. like actually jaw dropping. and i usually don't really like pixel art that much becuz i think too many game devs use it and it's just kinda hypersaturated if you know what i mean, but GODDAM. like... i want to eat it so much. om nom nom. mm chezburger
4:20 this is why it's important to code general behaviour scripts. (This is basically forced onto you if you use Unity). You could create a script that makes projectile explosion animations follow the motion of the object they collide with, and then just add that behaviour to all the bullets that you want to use that. Aim for modularity! It will save you lots of time in the long run. Edit: you covered this later in the video, sorry!
A projectile that has like a 5 degree angle that bounces off the ceiling and floor getting more speed with every bounce and has a bounce limit creates a projectile that starts slow but exponentially gets faster until it poofs out of existence
This was incredible, thank you for sharing! I am beginning to build my own metroidvania in Godot and the ballistics code in particular is brilliant. Could I use that?😅 Even better, would you ever consider open sourcing your generic projectiles controller? I feel like that is something that would get really good use if it was on the Godot asset library.😊
This problem kind of reminds me of the particle system I was making for my engine. I started with a scatter behavior, but then I extended it to have different particle behavior styles that would alter what they do during update() of the game loop. But I'm also a masochist who refuses to use a pre-fab engine like Godot, Unity or Unreal. It's way more fun to do the low level stuff myself.
When I prototype, I make the second item of a type by isolating common behaviour I want from the first one and change both to inherit the original. This way, I can have fast prototyping with generic types.
As someone just starting their first game in Godot, this has been very helpful to watch. And if you ever leave your door unlocked, I WILL steal every bit of code from your projectile controller. =v
Years ago I worked on a horizontal shooter in Game Maker and made every type of projectile run different damage and collision code. I didn't understand how parenting worked then so I had to add it ad hoc later when I needed to make changes. I have since made a movement system for all projectiles though it may end up in another game project.
on every single project i make there comes this point near the end when i promise myself i'll do more efficient cleaner code next time. then i start a new project and immediately ignore my past self and do stuff quick and dirty.
Can confirm, i'am making my game with Javascript and ThreeJS, but i made projectiles by hand as mostly stuff on my game. Luckly i made a generic action cicle that runs on any entity, and even luckly i made a generic physics that handle most of my projectiles, also in that generic function i put flags like, bouncy/througenemy/deathoncolision and those are really neat to easily add, soo, when i did my 3 firsts projectile tiens, bow, with arrows that pirce enemies soo i configured through enemy, chakram that bounces as Xena Princess Warrior, and Hammer that is totally another level of projectile, but i made it with deathOnColision because of arrows, but not used for that, and eventually made my nexts projectiles as fireballs that used it LOL
Isadora's movement looks so good and satisfying. Has a similar feel to what I'm trying to accomplish in my game. Would you ever share the code to her physics handling or make a video on the topic?
Your sword reflection idea made me think of some metroidvanias with parry mechanics that are usually part of the gameplay (restore energy and stuff). Would you plan on adding something like that ? If so would it be a starting mechanic that you use from the beginning and has interactions with other unlockable skills or would it be an unlockable feature ?
I'm actually prototyping a parry mechanic right now! If it ends up in the final game, I think I'd probably have it available from pretty much the very beginning of the game, but gotta make sure it feels right, haha!
I love hollow knight. I feel like this game shows a ton of promise for being just as fun... I might have just stumbled upon it, but I'm honestly hyped for the release.
I am getting back into game design / development after not doing for 13 years (my first college degree is in game design but I never persued it). I make these dumb mistakes to. For instance, to learn I am building a shoot em up, asteroids and geometry wars style game and wanted the enemy sprites to follow the player. I tried writing out a bunch of script until I realized I read a built in function of GM2 wrong and instead of using a script, it works with a single line of code haha.
When developing a project, it's perfectly fine to go "screw it it's tomorrow me's problem" when doing early prototyping. It's not like your future self can go back in time to kill you.
I really love programming small games, but I don't have much motivation. I have like a volcano that just builds up with motivation, and then just erupts, and I REALLY want to program. Though, I know how to program in Scratch. And, that's it. I know almost most things, and can think basic code, but I don't know how to code it. Is there, to your, or any other people here's, knowledge a programming engine that uses blocks, like Scratch? BTW, would love is there is a Discord. Maybe it is? But I couldn't find it (I'm extremely bad at searching)
If you can code in scratch, then coding in a traditional programming language is well within your abilities! You just need to translate your concepts that you've learned from scratch into the language's syntax. I believe in you!
I haven't used Scratch or Construct personally - but from what I've vaguely heard, it seems like Construct might be a good place to check! But I agree with @ricenami, I think you could jump into Godot and pick up GDScript fairly easily! I believe in you as well! (Also, I'm working on getting a Discord up and running, I'll post an announcement or mention it in a video or something once it's ready, haha!)
@@InboundShovel I am excited for the Discord!! I'm not an expert at creating servers, but if you need help, you can ask me. Hopefully I can do something to help.
Two questions: 1. Do you plan on adding 1st party mod support? I think something that really helps add longevity and replay-ability is mods and 1st party mod support makes that process much more accessible. 2. I’m not sure if this is something you’d be interested in doing, but seeing you mess around in the editor I think it would be a lot of fun if you had a level editor or something built in(I have no idea how much extra time that would take or if that’s feasible)
Rather than "Run on Spawn" why not wait to add the node until you need it? I might be generalizing incorrectly from my knowledge of ECS and Unity onto Godot. Could be an "Is Active" flag instead. But this made me think about the potential for projectiles that turn into non-projectiles at some point. Like Lakitu throwing Spinies.
Just a random idea, I don't know if you've got anything like this in the game already, but perhaps there could be some projectile that is able to stick to walls, maybe like a temporary 'mine' that the player has to avoid? Just food for thought
4:30 so its not even necessarily the fact you didnt use the build in systems, but rather the fact you didnt set up a system yourself but treated each projectile independently. The lesson being, use inherence as much as possible. 7:40 and lesson 2 as much of a pain as it is, you can always go back and just *do that.*
Hi, thanks for your videos it's quite interesting seeing how indie games are really made. Throuout the video I had some thoughts that may or may no be helpfull, here they go: 1) I suppose you tested projectiles perfomance on your pc. That may be not quite accurate way of doing this, as the tech requirments on steam page are very low. Hope you can test it on the exact potato-pc for convinience 2) That's cool that all of the logic handled in one place, but it seems for me as an antipattern known as God Object. You don't really need all this exhaustive features on every single type of projectiles so it'll be just waste of engine resources. If I'd had to think about it I'd go to some sort of composition for different features of projectiles, that can be easily dropped to only ones that need this. They all clearly stand out in your controller. Don't know about is it'll be really easier to apply this in Godot - never really developed a game myself, I programm in different area.
Tim cain(who nade fallout 1 and 2 and bunch of other games) has this good advice to make the tulrs part oft he game code and only use scripts for exceptions.
Frankly, that is a very neat and robust little system-lite you have built. I LOVE system-lites for solo projects. They don't have all the bells and whistles of stand-alone quality asset type deals but it's much easier to set up and realistically, won't hurt you in the long run if you plan to stay solo or small group.
Do you control the movement of the projectile root by `.get_parent()` or is it calling a movement function in the physics process of the root? It's a component or an aggregation or how do you actually manage that?
So, you basically should’ve made a projectile ‘parent’ and have the actual projectiles be ‘children’ of that. Now, I’m not experienced in Godot. But surely it has this functionality?
If you're interested, here's where you can wishlist Isadora's Edge on Steam! store.steampowered.com/app/3125320/Isadoras_Edge/
And you can follow the Kickstarter here: www.kickstarter.com/projects/inboundshovel/isadoras-edge
Thank you!
what if you made 1 projectile that gets destroyed on impact, and its destruction runs a script that can spawn a new projectile or attach a sprite to the object it hit? Then projectiles could bounce or stick or change type or spawn multiple projectiles or cause status effects or whatever you want on contact, but the update loop for each projectile doesn't have to branch on so many status questions, it just has a projectile type integer and animation frame integer to keep track of, and when it hits, you go through a switch case based on type to select an action. A projectile that isn't moving, is a waste of velocity and acceleration data, it should be converted to a sprite, and removed from the projectile list. all projectiles can be updated in a simple loop that just applies each velocity to each position, Then a different loop checks for the collisions of all the positions, then another loop runs all the scripts that were triggered by collisions, then another loop spawns all the objects cued up to spawn by the collision scripts.
Now, I think you can add another point as to why slopes in games are not recommendet: Bouncing projectiles off of a slope xD
...that just makes me _want_ to find a way to specifically make certain projectiles bounce
Can’t you just add force in the direction facing off the slope??
Actually not at all a problem if you are using the engine's built-in physics.
Also not at all hard to solve anyway as long as you know a little trigonometry.
@@deedoubs and as long as the game engine actually gives the correct collision normal: Godot's KinematicCollision2D result is super inconsistent
I'm more inclined to think that's an issue with the collision meshes involved than the engine, but I haven't checked it out in detail, so... Maybe.
My scripts usually turn out generics accidentally. Like I also had to make a projectile, then I needed another projectile... But rather than writing the code for it again, I sort of thought "wait, I already wrote a similar thing, let me just build on that"
Yeah in my project I have one object that just uses it's sprite value to represent what tool it is and runs the code.
Yeah, I’ve done some work modding Skyrim and I 100% do exactly that.
“Excuse me, sir, is that a unique bullet class?”
…actually, it’s a super class now
The deep dive wasnt boring at all, actually I think it really helpful. Not only was showing the process really interesting to watch, it added to your point in a pretty obvious and easy to understand way. Great video, well done!
thank you so much for including the projectile controller in the video i really needed that haha
You're welcome, glad I could help! :D
Some of the most difficult parts about initially learning how to code are questions like these.
"What is the end result of what I'm trying supposed to look like?"
"Am I doing something in a complex way that should be simple?"
"Is this process even necessary or on the right track to what I need?"
This kind of video answers a LOT of that, but in a way that's helpful.
By getting to see the full process, with everything from you talking about how quick prototyping is helpful to how/when/why you shifted into using a more universal system, and everything between, it gives a great perspective on what to aim for, how to work, and what to work towards.
Especially those sections where you talk about about implementing features into the node...
You explained what each function is for, why you put them there, and importantly you showed what it LOOKS like when it's fully put together. That's the part less-good coders than you can have a really hard time with. Without seeing an end-result of what a really good system ultimately would look like, it's hard to know where to go.
And on top of that, you showed examples of what it looks like in-game giving a 'why' for it all, applying it directly to a project.
Even the part where you talked about implementing a signal for 'if/when something might come up' and don't have a use for it yet.
That's the thing about being new to coding... EVERYTHING is an 'if/when something might come up.' And it's hard to know where to go or how to implement 'if/when' chunks of code, and what the CODE ITSELF should LOOK like when something IS implemented. You showed that, and it clears up SO MUCH.
That's the kind of stuff that helps the most for people trying to learn how to do any number of things too, even for things completely unrelated to projectiles, or even if they're not using Godot, it's brilliantly conveying the process AND end goal of what it's all for, what it looks like when done well, and why you'd do it that way.
There are countless tutorials. "This is how to make a projectile do X." Followed by showing the coding process for how to make that happen, how to iterate upon it, what else it can be used for.
But there are SO FEW informative resources for how to iterate on something like the CODE itself, a node, a system, anything.
It's easy to imagine what the projectile looks like when it's doing 'X' and so it's easy to know when the code is working.
But it's hard to imagine what a system/node/code/signal/etc FOR that code actually should LOOK like when it's fully applied.
What you did here is the kind of thing actually gives something STRIVE for, whether for a new-coder or someone more experienced.
Like, I legitimately know for sure that if I manage to code something that LOOKS like what you've built here, with all the options and the layout you've made for yourself, and if I make it FUNCTION with even part of what you've implemented, that I'll not only have DONE something useful and helpful in terms of a good result, but I'll ALSO know how to code better, I'll BE BETTER at making good-quality systems/nodes/anything and everything else that I'll need to learn how to do.
I can't say that after learning from most tutorials because they lack the entire context of what the full code of some big system (like a projectile node) looks like and blends with the rest of an entire game.
I can say that after watching your video here and trying to replicate it. I might need to watch tutorials for how to do some of it, but getting to see what yours LOOKS like and trying to make something that looks and functions like it... that's way better.
You talking about the whole thing and showing what the node looks like (in-engine) along with what it looks like in play (in-game) is better than a tutorial.
I could stay up all night trying to figure out how to do what you did here. I won't because sleep is good. haha
But I could easily dedicate this entire month to this. "How do I make a Node that looks and functions like Kenneth's?"
Because you did it for yourself, I know it's a good thing to try doing, it's a good target and practice and worth doing, AND most importantly I got a glimpse as to what it SHOULD look like when done because you showed the tangible Node itself and how it works in-engine and in-game at once. So now I actually have something clear to aim for, I can know when something isn't working, I can keep trying things because if there are parts you've made here that I haven't figured out or implemented to my own Node attempts yet then I know I have more work to do and it will BE FOR something I KNOW I'll benefit from.
There are only a handful of S-tier videos in every context.
In the context that this video falls into, in a landscape of tutorials about how to do things in-game and showing the process of coding how to do it, but a lack of showing what a well-built, easily-usable, polished and extremely useful type of system with all sorts of unique applications looks like... you showing what that kind of finished system of code looks like and how to put it together that way and why...
This is S-tier, Kenneth.
Good stuff.
I might make "Generic Projectile Physics Controller" my first ever big project with learning coding.
I don't have anything 'specific' that I need it for at the moment, but this video alone is just that good in terms of giving a tangible target. It presented a high-enough level in-engine system for making features work in-game in complex ways, requires skills that will most definitely translate to making more things like it long-term, and I got to see the end-game of the code matched with the end-game of the game-play it's built for, all at once.
Woop
Time to get to work/playing!
Also...
*improvised-dance high-five from across the world
Love it. Just wanted to tell you that your content genuinely help me a ton as I'm building mu own game. Please, keep going, this is actually priceless. Your charisma and pacing are top notch!
Thank you so much! :D
Love to see all of it coming together!
Thank you! :D
The explanation of how this system works is actually really interesting, hopefully you will upload more of these kind of explanations!
You can tell he put on a shirt just for the video with the heatwave going on.
CAUGHT
That's why you should always start thinking about your game code architecture from start. Use c#, make interfaces, abstract classes...etc. It seems tedious for a beginners, but it just saves your monthes/years of work in the long run.
I’m an object orientated software engineer by trade and C# is not necessary for Godot to have a clean architecture. You don’t need all those interfaces/abstractions as long as you using GDScript’s static typing and properly follow node composition.
NGL, this was a better ad for GODOT than anything I've ever seen. Seeing people actually use tools seems pretty convincing.
Interfaces have also been a godsend lately for handling simple behaviours that can vary depending on the object/entity. Like having an IDamageable or IKnockbackable or others and having the objects that use those interfaces override the abstract functions of the interface. Instead of testing for each kind of enemy or projectile when doing an attack, just checking if the entity/projectile implements the interface and then calling the function. That has saved me so much time lately when solo developing in Unity.
Also love to see the progress! As always very fascinated and inspired by your videos.
You explain things very well and clearly, it's definitely not boring! Thanks for showing us more under the hood 🙏🙏
Loved you talking about all the specifics. Helps me understand possible solutions and thought processes to problems i don't even have yet :)
Very helpful. I am very new to game dev and for some reason couldn’t get my head around how you could use premade projectile node and have be then specialized for each instance without screwing with the other spots it’s used. But seeing how you have @export all the variables made me realize that the exporting allows you to alter values without altering the script.
I would love to see a video on how you implement attacks for the enemies, if it's not just straight "Let's just hardcode it into the enemy class", since I'm currently trying to wrap my head around that. The problematic part is that I wanna make my attacks modular, so in theory any enemy could use any attack...
I'm working on a frame data system so that I can easily and generically add frame data to the enemy's attacks! It's still somewhat hard-coded (since I'm adding the frame data directly into the enemy attack animations), but I'll see what I can cook up on that front video-wise!
I appreciate this look into game development. hope you have a good day or night.
Thank you, you too!
when i built my first game i made everything with a damage hitbox use the same code, or rather, my player character had both a gun and a sword, the enemies projectiles used the same code as the players projectiles, exept their hitbox was flipped in a way that they hurt the player and are not capable of friendly fire with the same enemy type, and funnier thing was the players sword, which only had 2 animation frames for the character swinging! one for anticipation, and the other for the swing itself! the heavy lifting of that animation was the smear of the sword, which was a projectile with 0 velocity! yeah, it allowed me to do some great stuff, like having 2 different types of animations, one when you swing into thin air, the another when you hit something!
Hello! I am new to your channel. I really like it because you talk about really specific challenges in a comprehensive manner. I am a total beginner in godot but I understand what you are talking about.
Showing it in the editor is the cherry on top. Super cool and not boring at all! I love that deeper dive. It scratches my brain the right way :D
New hobby dev starting on godot stuff and I am absolutely loving vids like this! Sub time for sure. I love seeing your process and it is really making me think about how I am doing things! Thanks!
something learned the hard way too, if you have at least 2 pieces of code with some similarities, no matter how small you better encapsulate it in a single system or function, saves a lot of time in the long run
The rule of three feelse relevant here. If you do it once just get it done. If you do it twice take note. If you do in three times you need a proper solution.
I'm so glad you made this video before I made the same mistake 😅
I did not know about the Projectile Physics Controller.
Very helpful man . The less mistakes I make on my game the better you have mentioned things that I would otherwise not have done myself so ya thanks
I enjoyed seeing the controller and what the options did
This really did feel very dirty
Another gem, I absolutely love your videos.
Your content is amazing, there's always something to learn and you explain everything so clearly.
Cheers
I really enjoyed this episode and that ballistic part is so cool. Also make sure to add this to the playlist
while working on my own game, to keep the files smaller and scrollable. I started needing to maintain a separate document to make me remember how everything works lol. Great video makes me remember i also need to make my own generic movement handler lol.
Awesome in-depth look man! I had to subscribe!
My system for avoiding this is to create two test areas when I start my project (though I haven't truly finished any, so this might not be as great as it seems right now). The first one is where I test ideas to see if they work. That area winds up being 99% jank by the end of the project. The second one is where I implement the idea in a "production-ready" form. Any code/design/whatever that I use there is implemented in the same way as the rest of the game.
That gives me a baseline to test things against. So if I notice a weird behavior with an object (like a projectile), I can find out if it's in the base class or the subclass I made for that implementation. I've also had a couple cases where I realized the only way to implement a feature was pure jank (due to engine limitations, other constraints, etc). So I had to decide if I really wanted that feature or not, knowing that would be the case. A famous example of this is in a finished game the Fast Inverse Square Root, which was brilliant, but very janky from a programming perspective (and definitely worth learning about if you don't already know the story).
Much respect to developers who have the passion and motivation to go the extra mile to achieve their vision! 😄
Trying to teach myself Godot to reach your level and these videos of issues you've come across are incredibly helpful
Nice video. The projectile stress test was very satisfying to watch haha.
It’s great that the engine can handle that many projectiles, cause that means Isadora’s Funky Little Ball Pit can be even funkier!
Great video! As a game dev beginner, I always appreciate the behind-the-scene snippets
Nice refactor 💪 Suggestion to make it even more solid: Make the definitions for shared behavior values into a Resource type - e.g. ProjectileBehaviorResource. Then you can have a single access point (for each projectile type) for all your properties which every instance will reference (e.g. your speed float exists on the resource and the ProjectileController node just reads the value from its Resource), rather than the properties existing on the instances. Then you can change values at runtime and all projectiles sharing that Resource will update. Also technically more efficient since they’re all pointing to the same spot in memory. Now that your architecture is the way it is, taking this extra step would be a quick refactor. Hope that helps!
This looks like a fun game and the video was pretty informative. Got my attention even though I know nothing about making games or programming. Very cool.
Great video! Very helpful on the parameters, I have a similar system in my game but this video made me realise it's really lacking in the parameter department haha, now to add all of this...
Nice case study in how to properly manage technical debt!
The dev power is expressed in how many times touches its glasses per minute.
I always start the other way around. Make the generic system before the specifics, but i usually go the inheritance way instead of the configuration way
I love seeing this "nerdy stuff", especially since I'm trying to learn game design myself.
funny seeing someone else just stumble into something 90% like the projectile controller I've used for years now, with all the same booleans and behaviors.
once you start reusing and expanding these systems from earlier projects you never get the urge to put together quick hacks anymore. the PTSD of fixing them stays with you lmao
okay i'll say this once and i'll say it again. your game is absolutely GORGEOUS dude. like actually jaw dropping. and i usually don't really like pixel art that much becuz i think too many game devs use it and it's just kinda hypersaturated if you know what i mean, but GODDAM. like... i want to eat it so much. om nom nom. mm chezburger
Absolutely NOT boring at all keep it up (fellow gamedev)
great video and nice work!
Ever heard of inheritance? XD
Even when prototyping, it's faster to develop this way.
There are just no excuses.
4:20 this is why it's important to code general behaviour scripts. (This is basically forced onto you if you use Unity). You could create a script that makes projectile explosion animations follow the motion of the object they collide with, and then just add that behaviour to all the bullets that you want to use that.
Aim for modularity! It will save you lots of time in the long run.
Edit: you covered this later in the video, sorry!
A projectile that has like a 5 degree angle that bounces off the ceiling and floor getting more speed with every bounce and has a bounce limit creates a projectile that starts slow but exponentially gets faster until it poofs out of existence
This was incredible, thank you for sharing! I am beginning to build my own metroidvania in Godot and the ballistics code in particular is brilliant. Could I use that?😅
Even better, would you ever consider open sourcing your generic projectiles controller? I feel like that is something that would get really good use if it was on the Godot asset library.😊
This problem kind of reminds me of the particle system I was making for my engine. I started with a scatter behavior, but then I extended it to have different particle behavior styles that would alter what they do during update() of the game loop.
But I'm also a masochist who refuses to use a pre-fab engine like Godot, Unity or Unreal. It's way more fun to do the low level stuff myself.
When I prototype, I make the second item of a type by isolating common behaviour I want from the first one and change both to inherit the original.
This way, I can have fast prototyping with generic types.
As someone just starting their first game in Godot, this has been very helpful to watch. And if you ever leave your door unlocked, I WILL steal every bit of code from your projectile controller. =v
Very useful explaination.
i'm 1000% gonna steal that ballistics function
Awesome video man!
Thank you! :D
Years ago I worked on a horizontal shooter in Game Maker and made every type of projectile run different damage and collision code. I didn't understand how parenting worked then so I had to add it ad hoc later when I needed to make changes. I have since made a movement system for all projectiles though it may end up in another game project.
on every single project i make there comes this point near the end when i promise myself i'll do more efficient cleaner code next time. then i start a new project and immediately ignore my past self and do stuff quick and dirty.
That Keroppi shirt is fire
Amazing.
Awesome!
Can confirm, i'am making my game with Javascript and ThreeJS, but i made projectiles by hand as mostly stuff on my game. Luckly i made a generic action cicle that runs on any entity, and even luckly i made a generic physics that handle most of my projectiles, also in that generic function i put flags like, bouncy/througenemy/deathoncolision and those are really neat to easily add, soo, when i did my 3 firsts projectile tiens, bow, with arrows that pirce enemies soo i configured through enemy, chakram that bounces as Xena Princess Warrior, and Hammer that is totally another level of projectile, but i made it with deathOnColision because of arrows, but not used for that, and eventually made my nexts projectiles as fireballs that used it LOL
A.K.A. How I solved Projectile Dysfunction
and with godot's physics interpolation in 4.3 we can get even better visual performance with slower physics tick rates (as far as I understand)
fact, something heavy falls at the same speed as something light, but yeah, floaty 👍
that little intro to "bonnie" is quite tragic. when i look at the model, i kinda dont want to kill it. lol.
lol you will probably feel this way to lots of enemies XD
Isadora's movement looks so good and satisfying. Has a similar feel to what I'm trying to accomplish in my game.
Would you ever share the code to her physics handling or make a video on the topic?
19:58 "See you next time, dorks"? Phil Fish in disguise?
1.5 bounce floor space when you are trapped in 4 walls :D
Your sword reflection idea made me think of some metroidvanias with parry mechanics that are usually part of the gameplay (restore energy and stuff). Would you plan on adding something like that ? If so would it be a starting mechanic that you use from the beginning and has interactions with other unlockable skills or would it be an unlockable feature ?
I'm actually prototyping a parry mechanic right now! If it ends up in the final game, I think I'd probably have it available from pretty much the very beginning of the game, but gotta make sure it feels right, haha!
This video show that even a talented dev make mistakes heehe nice video but overall super nice solution
I love hollow knight. I feel like this game shows a ton of promise for being just as fun... I might have just stumbled upon it, but I'm honestly hyped for the release.
I am getting back into game design / development after not doing for 13 years (my first college degree is in game design but I never persued it). I make these dumb mistakes to. For instance, to learn I am building a shoot em up, asteroids and geometry wars style game and wanted the enemy sprites to follow the player. I tried writing out a bunch of script until I realized I read a built in function of GM2 wrong and instead of using a script, it works with a single line of code haha.
I wonder if using the Jolt add-on would change or improve the physics in any interesting ways? 🤔
When developing a project, it's perfectly fine to go "screw it it's tomorrow me's problem" when doing early prototyping.
It's not like your future self can go back in time to kill you.
Damn. I had to check my playback speed.
I really love programming small games, but I don't have much motivation. I have like a volcano that just builds up with motivation, and then just erupts, and I REALLY want to program. Though, I know how to program in Scratch. And, that's it. I know almost most things, and can think basic code, but I don't know how to code it. Is there, to your, or any other people here's, knowledge a programming engine that uses blocks, like Scratch?
BTW, would love is there is a Discord. Maybe it is? But I couldn't find it (I'm extremely bad at searching)
If you can code in scratch, then coding in a traditional programming language is well within your abilities! You just need to translate your concepts that you've learned from scratch into the language's syntax. I believe in you!
I haven't used Scratch or Construct personally - but from what I've vaguely heard, it seems like Construct might be a good place to check!
But I agree with @ricenami, I think you could jump into Godot and pick up GDScript fairly easily! I believe in you as well!
(Also, I'm working on getting a Discord up and running, I'll post an announcement or mention it in a video or something once it's ready, haha!)
@@InboundShovel I am excited for the Discord!! I'm not an expert at creating servers, but if you need help, you can ask me. Hopefully I can do something to help.
Two questions: 1. Do you plan on adding 1st party mod support? I think something that really helps add longevity and replay-ability is mods and 1st party mod support makes that process much more accessible.
2. I’m not sure if this is something you’d be interested in doing, but seeing you mess around in the editor I think it would be a lot of fun if you had a level editor or something built in(I have no idea how much extra time that would take or if that’s feasible)
The game looks quite pretty ^ω^
loved the episode!
"Lets end this off with an interpretive dance about projectiles" *dances with two empty soda bottles*
Me: "Weird." *Subs*
Rather than "Run on Spawn" why not wait to add the node until you need it? I might be generalizing incorrectly from my knowledge of ECS and Unity onto Godot. Could be an "Is Active" flag instead.
But this made me think about the potential for projectiles that turn into non-projectiles at some point. Like Lakitu throwing Spinies.
wow, bonnie seems a lot like me
And what if you wanted a specific projectile NOT to collide with other objects, then? (Objects, not walls/floor)
Just a random idea, I don't know if you've got anything like this in the game already, but perhaps there could be some projectile that is able to stick to walls, maybe like a temporary 'mine' that the player has to avoid?
Just food for thought
4:30 so its not even necessarily the fact you didnt use the build in systems, but rather the fact you didnt set up a system yourself but treated each projectile independently.
The lesson being, use inherence as much as possible.
7:40 and lesson 2 as much of a pain as it is, you can always go back and just *do that.*
Hi, thanks for your videos it's quite interesting seeing how indie games are really made. Throuout the video I had some thoughts that may or may no be helpfull, here they go:
1) I suppose you tested projectiles perfomance on your pc. That may be not quite accurate way of doing this, as the tech requirments on steam page are very low. Hope you can test it on the exact potato-pc for convinience
2) That's cool that all of the logic handled in one place, but it seems for me as an antipattern known as God Object. You don't really need all this exhaustive features on every single type of projectiles so it'll be just waste of engine resources. If I'd had to think about it I'd go to some sort of composition for different features of projectiles, that can be easily dropped to only ones that need this. They all clearly stand out in your controller. Don't know about is it'll be really easier to apply this in Godot - never really developed a game myself, I programm in different area.
This is NOT a projectile system. This has moved to the next level and has become a particle system.
This we called technical dept, I try to avoid it, and then I make too complicated things
Tim cain(who nade fallout 1 and 2 and bunch of other games) has this good advice to make the tulrs part oft he game code and only use scripts for exceptions.
back to school😔😔
I vaguely remember seeing a game jam game and devlog similar to this one. I could be misremembering, but is this it?
So... In essence... You created a Base Projectile Class?
Frankly, that is a very neat and robust little system-lite you have built. I LOVE system-lites for solo projects. They don't have all the bells and whistles of stand-alone quality asset type deals but it's much easier to set up and realistically, won't hurt you in the long run if you plan to stay solo or small group.
144 ticks per second is not divisible by 60. Will it run smoothly at 60 FPS?
Does Godot have a built in slope system?
Do you control the movement of the projectile root by `.get_parent()` or is it calling a movement function in the physics process of the root? It's a component or an aggregation or how do you actually manage that?
So, what the point of using pools for projectiles if you can have 400 projectiles and still instantiate 8 of them ?
Wouldn't this universal tool also fix your issues with slopes if you made one for movement?
Can you do a pixel art video
The character pixel art in this game is done by an artist friend - Fer
@@lyraisnapping aha tnx
So, you basically should’ve made a projectile ‘parent’ and have the actual projectiles be ‘children’ of that.
Now, I’m not experienced in Godot. But surely it has this functionality?