Idea for everyone!: I’ve set up an enemyManager class that keeps track of enemies and their states, and basically, whenever an enemy gets out of render distance from the player, the code for the enemy will stop playing. When it is back in render distance, I will start running that code again. And this distance checker is ran every 5 frames for optimization. This way, we have less hot code running 👍
I was implementing a new feature and ended up having to do my optimized fix right then and there. I am making a game that looks similar to your drifting game, except mine has a slow moving tank and massive aliens. I was creating a Line of Sight fog of war system. The proof of concept was to make individual collision objects to overlay over the world map tiles, and have a raycast from the controlled units enable the masking on each object. The concept worked and looked cool, but having literally thousands of new colliders on the map destroyed my frames. I then achieved the same desired effect by using raycast data to paint pixels on large mask images that took the place of chunks of area that were once covered by hundreds of the mask tile colliders. The result was mathematically more difficult but thanks to async processing, the performance impact was not even noticeable.
Someone talking about time complexity in optimizations I see. I just wanna say thank you. I have never seen a game dev optimization video talking about this. I’ll see triple nested for loops in some people’s runtime code and say, hey that has a super high time complexity of O(n^3), that won’t scale well at all, especially every frame. This is an intermediate CS topic taught in college and I’m super happy someone is showing this to others! Quick edit: instead of saying “because it only goes two layers deep”, I believe it’s my be easier for some to understand it by noting that only the degree is kept. Thanks again! 🙏
The quality of your videos and content is outstanding! After watching your most recent video, I genuinely thought that you were just a huge TH-camr the algorithm had never introduced me to. I was wrong. You DESERVE to be huge though. Subscribed and supported! I love your content, and I've already binged at least 10 of your videos.
Thank you so much, I try to put a lot of effort into each one, and it's comments like this that really give me tons of motivation! Really glad you're enjoying the videos!
Optimize as needed but ALWAYS think about making your code * optimizable *. If you are not making your code optimizable and your project is anything more than toy size, you will eventually reach a point when you * have to * optimize but cannot without pretty much rewriting your project from scratch in the proper manner. This is the simplest way to kill a project. It's okay to use a slow naive algo if you know a much better one exists. Okay to cause an allocation if you know how to get rid of it without affecting the rest of the code. Okay to cause 1000 draw calls if you know you can replace that with instancing and have one draw call instead and you are making sure to not break the necessary assumptions going forward. However, if you don't think about optimizations at all and start with 100 fps and lose 1 ms with each small feature you add and you want to add 30 of them then by the time you drop below 60 fps you will have a very complicated project with lots of assumptions and major changes in its architecture will be very hard. The development will then get harder and harder instead of easier and easier.
Good video, some great discussion points here. Really well explained for beginners however I fundamentally disagree with your opening argument. You should care about the performance and quality of your code, especially in early development, because it can save you a lot of headaches later in development. Many coders tend to mash out any of crap and justify it with "Well, it works". Later down the line that entire set of work has to be redone because it's just impractical with other systems or cannot be maintained. I've seen this first hand at my job in which we had to rewrite about 80% of the codebase because it had just been bashed out. So if you are a beginner, don't worry about performance. Learn how to code and pick up performance tuning later. When you're working on your next system utilise that performance early so you don't end up in a mess later on.
Ay Skeffles, thanks (and I do love a good discussion)! I do partially agree with you, performance and quality of your code is important. However, weighing up HOW important performance is at any given stage in a game’s development is really critical to factor in. I agree that mashing out bad code and saying "It works" is a poor excuse, but I don’t think that’s what I advocate for. I think an emphasis should be placed on quickly implementing (quality) human readable code (that doesn’t necessarily need to be performance optimised). I think re-visiting code and trying to understand spaghetti is the WORST when its function is hard to understand. If its easy to understand - but not written optimally, then it’s a much easier job to sort out (if you even end up needing to, which often times isn’t needed). The best programmers and developers I personally know are brilliant when it comes to best practises and design, but also know that when it comes to 'getting things done', they need to sacrifice some ideals in order to save working hours and get the product out the door. I too have seen codebases that have required huge re-writes and think that in an ongoing, updatable product, long-term design is especially important. However, with a large amount of indie games in particular, we are aiming for that goal of a finished product. It reminds me of when Terry Cavanagh open sourced VVVVVV and everyone on twitter was making fun of how ‘badly’ written certain parts of it were. While I agree that huge parts of the code were weirdly implemented and odd, ultimately he managed to ship a successful game (and who knows how much longer that would have taken to make if he was overly careful at every stage of writing it). And yeah, while you're a beginner, you'll fall into making these mistakes. But the faster you make mistakes and learn from them, the faster you'll eventually be able to quickly implement performant solutions without thinking about them too much (because you've done it before). I guess I'm just a pretty big fan of a sort of 'fail-fast-esque' mentality. So yeah, sorry for the wall of text but I think it’s really interesting to talk about and discuss!
Your comment is exactly on point. Not caring about optimization at all is like taking a loan from a bank at high interest. You might be happy for a while with the time you borrowed from the future, but then the time comes to pay back that debt. And that's when projects usually get killed, not at their early stages, when the morale is usually high anyway.
forgot to add about loops. It only takes one loop and a minor lapse in judgment to make your computer attempt to run an infinite number of calculations at once
The compiler can do structural changes to your code. But its actually not smart at all. It can only make your logic more efficient for the architecture of the CPU however it does not know what the intend of the code is, so it cant come up with a smarter implementation.
@Czekot No they dont. It depends what you understand about structure. But loop unrolling, reordering of instructions to break dependencies, loop combining. That all pretty much changes the code structure but does not change the actual logic of the code.
Well I think there is a non pessimising philosophy. It's when you do not copy items when passing by refference would be fine, as an example. Full on optimisation is not done 100% of the time
Idea for everyone!: I’ve set up an enemyManager class that keeps track of enemies and their states, and basically, whenever an enemy gets out of render distance from the player, the code for the enemy will stop playing. When it is back in render distance, I will start running that code again. And this distance checker is ran every 5 frames for optimization. This way, we have less hot code running 👍
Sounds like a great solution for rendering and logics. Thanks!
Me with my spaghetti code, phew.
Who knew this whole video was just me trying to justify my own terrible coding practices (and life choices) to myself...
Coding Veteran: “Oooh that codes looking Hot” Me: “WHAT”
Worrying about perfection does cause a lot of needless stress haha.
I was implementing a new feature and ended up having to do my optimized fix right then and there. I am making a game that looks similar to your drifting game, except mine has a slow moving tank and massive aliens. I was creating a Line of Sight fog of war system. The proof of concept was to make individual collision objects to overlay over the world map tiles, and have a raycast from the controlled units enable the masking on each object. The concept worked and looked cool, but having literally thousands of new colliders on the map destroyed my frames. I then achieved the same desired effect by using raycast data to paint pixels on large mask images that took the place of chunks of area that were once covered by hundreds of the mask tile colliders. The result was mathematically more difficult but thanks to async processing, the performance impact was not even noticeable.
Let's take a minute of silence for Noita and the many many years of dev mostly for optimization
Someone talking about time complexity in optimizations I see. I just wanna say thank you. I have never seen a game dev optimization video talking about this. I’ll see triple nested for loops in some people’s runtime code and say, hey that has a super high time complexity of O(n^3), that won’t scale well at all, especially every frame. This is an intermediate CS topic taught in college and I’m super happy someone is showing this to others!
Quick edit: instead of saying “because it only goes two layers deep”, I believe it’s my be easier for some to understand it by noting that only the degree is kept. Thanks again! 🙏
100% agree, great video :)
The quality of your videos and content is outstanding! After watching your most recent video, I genuinely thought that you were just a huge TH-camr the algorithm had never introduced me to.
I was wrong. You DESERVE to be huge though. Subscribed and supported! I love your content, and I've already binged at least 10 of your videos.
Thank you so much, I try to put a lot of effort into each one, and it's comments like this that really give me tons of motivation! Really glad you're enjoying the videos!
Optimize as needed but ALWAYS think about making your code * optimizable *. If you are not making your code optimizable and your project is anything more than toy size, you will eventually reach a point when you * have to * optimize but cannot without pretty much rewriting your project from scratch in the proper manner. This is the simplest way to kill a project.
It's okay to use a slow naive algo if you know a much better one exists. Okay to cause an allocation if you know how to get rid of it without affecting the rest of the code. Okay to cause 1000 draw calls if you know you can replace that with instancing and have one draw call instead and you are making sure to not break the necessary assumptions going forward.
However, if you don't think about optimizations at all and start with 100 fps and lose 1 ms with each small feature you add and you want to add 30 of them then by the time you drop below 60 fps you will have a very complicated project with lots of assumptions and major changes in its architecture will be very hard. The development will then get harder and harder instead of easier and easier.
Great video. Bravo on the game improvement as well!
yay new vid!
I just stumbled on your videos and they are great. Really good info, not enough views
Super useful and inspiring as well! Nice job
Good video, some great discussion points here. Really well explained for beginners however I fundamentally disagree with your opening argument. You should care about the performance and quality of your code, especially in early development, because it can save you a lot of headaches later in development.
Many coders tend to mash out any of crap and justify it with "Well, it works". Later down the line that entire set of work has to be redone because it's just impractical with other systems or cannot be maintained. I've seen this first hand at my job in which we had to rewrite about 80% of the codebase because it had just been bashed out.
So if you are a beginner, don't worry about performance. Learn how to code and pick up performance tuning later. When you're working on your next system utilise that performance early so you don't end up in a mess later on.
Ay Skeffles, thanks (and I do love a good discussion)!
I do partially agree with you, performance and quality of your code is important. However, weighing up HOW important performance is at any given stage in a game’s development is really critical to factor in. I agree that mashing out bad code and saying "It works" is a poor excuse, but I don’t think that’s what I advocate for. I think an emphasis should be placed on quickly implementing (quality) human readable code (that doesn’t necessarily need to be performance optimised). I think re-visiting code and trying to understand spaghetti is the WORST when its function is hard to understand. If its easy to understand - but not written optimally, then it’s a much easier job to sort out (if you even end up needing to, which often times isn’t needed).
The best programmers and developers I personally know are brilliant when it comes to best practises and design, but also know that when it comes to 'getting things done', they need to sacrifice some ideals in order to save working hours and get the product out the door.
I too have seen codebases that have required huge re-writes and think that in an ongoing, updatable product, long-term design is especially important. However, with a large amount of indie games in particular, we are aiming for that goal of a finished product. It reminds me of when Terry Cavanagh open sourced VVVVVV and everyone on twitter was making fun of how ‘badly’ written certain parts of it were. While I agree that huge parts of the code were weirdly implemented and odd, ultimately he managed to ship a successful game (and who knows how much longer that would have taken to make if he was overly careful at every stage of writing it).
And yeah, while you're a beginner, you'll fall into making these mistakes. But the faster you make mistakes and learn from them, the faster you'll eventually be able to quickly implement performant solutions without thinking about them too much (because you've done it before). I guess I'm just a pretty big fan of a sort of 'fail-fast-esque' mentality.
So yeah, sorry for the wall of text but I think it’s really interesting to talk about and discuss!
Your comment is exactly on point. Not caring about optimization at all is like taking a loan from a bank at high interest. You might be happy for a while with the time you borrowed from the future, but then the time comes to pay back that debt. And that's when projects usually get killed, not at their early stages, when the morale is usually high anyway.
"Can't see me" "DISAPPEAR-Y" lol
forgot to add about loops. It only takes one loop and a minor lapse in judgment to make your computer attempt to run an infinite number of calculations at once
These videos are really helpful! I'm just now starting to make my own game in Unity and it feels like climbing a mountain with 0 experience
The compiler can do structural changes to your code. But its actually not smart at all. It can only make your logic more efficient for the architecture of the CPU however it does not know what the intend of the code is, so it cant come up with a smarter implementation.
@Czekot No they dont. It depends what you understand about structure. But loop unrolling, reordering of instructions to break dependencies, loop combining. That all pretty much changes the code structure but does not change the actual logic of the code.
@Czekot what do you call it then? Its not changing code logic either.
nice video!
4:18 - Code Stucture Analysis
:| Nice video tho :DD
I KNEW there would be something I missed ahaha. Oh well, thanks! 😄
Well I think there is a non pessimising philosophy. It's when you do not copy items when passing by refference would be fine, as an example. Full on optimisation is not done 100% of the time
Well computers are faster nowadays but beginners are taking longer to reach the point where they give up.