Why You SHOULD (not) Care About Optimisation - How I Made My Game Run 100x Faster

Рет қаралды 3,602

Күн бұрын

Indie game optimisation is hard to do and in my opinion, isn't worth doing a lot of the time. However, some times we need to optimise our games to run faster as there is no alternative. Here, I talk about my approach to optimising my game from my current devlog series, with the ideas and types of thinking that go into improving it's run speed and frames per second (FPS).
Luckily, I have improved the game's FPS, but it took a lot of messing around with settings and code to get there.
----------------------------------------------------------------------------
Remember to Subscribe!
Follow me on twitter:
/ madbookstudios
Join the madbook discord:
/ discord
Check all my FREE games on itch:
madbookstudios.itch.io/
Website:
Thanks all!

Пікірлер: 31

@GymCritical 3 жыл бұрын

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 👍

@iliqnew 11 ай бұрын

Sounds like a great solution for rendering and logics. Thanks!

@tauheedgamedev2388 3 жыл бұрын

Coding Veteran: “Oooh that codes looking Hot” Me: “WHAT”

@BenBonk 3 жыл бұрын

Me with my spaghetti code, phew.

@Madbook 3 жыл бұрын

Who knew this whole video was just me trying to justify my own terrible coding practices (and life choices) to myself...

@NeatGames 3 жыл бұрын

Worrying about perfection does cause a lot of needless stress haha.

@pirateskeleton7828 11 ай бұрын

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.

@GymCritical 3 жыл бұрын

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! 🙏

@snugpig 3 жыл бұрын

yay new vid!

@algs5483 3 жыл бұрын

"Can't see me" "DISAPPEAR-Y" lol

@nirmeout 3 жыл бұрын

Great video. Bravo on the game improvement as well!

@BandsmenGAMES 3 жыл бұрын

Super useful and inspiring as well! Nice job

@ethangilbert7305 Жыл бұрын

I just stumbled on your videos and they are great. Really good info, not enough views

@baconeta 3 жыл бұрын

The quality of your videos and content is outstanding! After watching your most recent video, I genuinely thought that you were just a huge KZfaqr 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.

@Madbook 3 жыл бұрын

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!

@FuelledByCaffeine 3 жыл бұрын

100% agree, great video :)

@hypnogames3768 3 жыл бұрын

nice video!

@Mysda_ 3 жыл бұрын

Let's take a minute of silence for Noita and the many many years of dev mostly for optimization

@ethangilbert7305 Жыл бұрын

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

@leokm9586 Жыл бұрын

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

@dannycopo42 3 жыл бұрын

4:18 - Code Stucture Analysis :| Nice video tho :DD

@Madbook 3 жыл бұрын

I KNEW there would be something I missed ahaha. Oh well, thanks! 😄

@julkiewicz 3 жыл бұрын

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.

@principleshipcoleoid8095 Жыл бұрын

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

@Thoriumus 3 жыл бұрын

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.

@Thoriumus 3 жыл бұрын

@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.

@Thoriumus 3 жыл бұрын

@Czekot what do you call it then? Its not changing code logic either.

@Skeffles 3 жыл бұрын

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.

@Madbook 3 жыл бұрын

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!

@julkiewicz 3 жыл бұрын

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.