7 Optimization Tips to 10X your Game Performance

[@Yogoda127]

For 3D: - Split big geometry objects into large chunks so only visible chunks are drawn, the rest is automatically culled by the engine. - Use level of detail (LOD) for objects with a lot of geometry - Deactivate enemies that are far away from the player with process_mode = Node.PROCESS_MODE_DISABLED

[@African-AmericanGoose]

And 2D ? you have some tips ?

[@Yogoda127]

@@African-AmericanGoose Sorry, I only do 3D 😁

[@mr.hi_vevo414]

Your video is incredibly high quality, with concise and easy to understand content, great examples, no annoying intro or outro, and animations, BUT it's really held back by your mic quality. People often click off of videos immediately after hearing videos with bad mic quality, but thankfully that's one of the easiest things to fix, so long as cost isn't an issue. It's much harder to fix writing quality than mic quality. You deserve far more views, so I hope you can get there soon! Keep up the good work

[@Csf91]

Try to cache objects and enemies that spawn into memory to re-use the memory space instead of creating and destroying objects, too.

[@SSukram_]

How would you do this?

[@hk_asa0pvp]

@@SSukram_ it would be like hiding a node with visible = false and later visible = true. rather than instancing and adding then freeing it i guess correct me if I'm wrong.

[@igorthelight]

@@SSukram_ Google "object pooling in Godot/Unity/Unreal Engine"

[@rremnar]

@@hk_asa0pvp I've heard of doing this for bullet hell games. That you don't want to free and rebuild bullets, but reuse the ones that were made. Though this does cause hitching. So you may need to preload these on scene load.

[@fragileglass9622]

Even as a seasoned developer. Always room to grow. I had no idea about the visibility onscreen notifier. Thank you for unearthing that little gem for me.

[@iLgaming334]

Good work out there, soldier

[@moonstonewarlock]

Great video! Thanks! 😎

[@JackBasciono]

Improve your mic quality and add quiet music in the background. Will make this more watchable, however, in terms of content: Good stuff, very useful

[@VenexSource]

Thanks for the tips!

[@TheEshanDas]

These are very good tips atleast for a beginner like me. Amazing work

[@rremnar]

A few other things that should be optimized is animations and shaders. Animations, if not required to keep runnin for game specific purposes, can be stopped client side, when it is out of view. Shaders shouldn't be calculated when out of view. I think that is why some games cause the GPU to be very hot, because they are all being calculated for the whole scene.

[@DestusG]

I saw our game 😅

[@slavcabbage2619]

Really nice tips I will definitely be using these

[@VenexSource]

Glad you like them!

[@thehansboi]

why is tip #3 so quiet lmao, rest of the video felt like i was listening to someone underwater lol

[@ClokworkGremlin]

You should really be using type hinting whenever possible (that's "always") in Godot. For basically the reasons listed. Static typing is one of the most powerful tools in a programmer's tool belt for preventing runtime bugs.

[@jammjumble9928]

really nice tips!

[@FruitZeus]

I saw there’s also a visibility occluder 3D node. How is this different than regular occlusion culling?

[@HansMilling]

Remember that disabling VSYNC makes your game very power hungry, so it’s a big no no on steamdeck, phones and other battery powered devices.

[@Gnidel]

Just leave it up to user whenever to use it or not.

[@ObsydianX]

Yeah, I have to use VSync when testing my game or it’ll run at 300+ FPS and turn my fans into launch thrusters.

[@eobet]

Visibility notifier? Godot doesn’t have frustrum culling by default?

[@mystiogan5891]

when making a 3d game, Lod or level of detail can help a lot. by making your own low poly models or with an i engine setting i believe, but i'm not sure.

[@Flux0_0-u2d]

You can use godot physics server

[@SamFX]

Very good tips

[@davidkurosaki8457]

Can you help me with this mechanic in a video it's for a farm game One has 4 gardens before planting you must put the fertilizer and then the plant, and to start generating points or grow, you have to put water, for example in 3 hours that plant produces 1000 points but it must be watered every 1 hour, because the soil dries while it is dry it does not generate points the points freeze but the hours continue advancing, then in the end instead of 1000 points you will have less example 300. Please could you make a video please Of course one would buy with those same points the fertilizer the plant, among other things

[@hokokotokokoto7082]

static typing over dynamic typing i see how it could boost perf in editor but does it make a difference once you export the game ?

[@kleinesmaddy]

Static typing does not improve performance in any way because the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution.

[@thisisgod2639]

​@@kleinesmaddy Actually no. Static typing sets the exact bytecode in the binary file to be read by the engine instead of interpreting and producing it during runtime. This can save some, for example, in a for loop like this: for i in range(100): var v := foo(i) The engine won't have to guess v's type every time that line executes because it's already predefined

[@kleinesmaddy]

@@thisisgod2639 While I appreciate your perspective, I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution. To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used. In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process. In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported.

[@kleinesmaddy]

@@thisisgod2639 While I appreciate your perspective, I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution. To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used. In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process. In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported.

[@kleinesmaddy]

I believe there's a misunderstanding regarding the role of static typing in performance optimization. As I mentioned earlier, the primary purpose of static typing is to catch type errors at compile time, not to optimize runtime execution. To elaborate, static typing allows the compiler to know the types of variables at compile time, which can help catch errors early. However, when it comes to the performance of the final exported game, the impact is minimal. Once the game is exported, the code is compiled into bytecode or machine code, where types are already fixed, regardless of whether static or dynamic typing was used. In your example with the for loop, while it's true that the engine doesn't need to determine the type of v at runtime in a statically typed environment, this difference is negligible in the context of an exported game. The performance gains, if any, would be very minimal and are generally overshadowed by the optimizations done during the compilation process. In summary, static typing primarily helps with compile-time error checking, not with runtime performance optimization, especially after the game has been exported. P.S. Just because my comment keeps getting deleted doesn’t make a false statement true. ;-)

[@grimreaper8581]

I didn't watch the video yet but very cool keep going

[@jonpatchmodular]

Ahhahah yes 54fps... I think you dropped the decimal point there... T_T help

[@andrekoscianski]

👍

[@MoiCestVinci]

Now it's a WokeDot engine can we use a fork, maybe Redot game engine.

[@charlieking7600]

So you're retelling official documentation. Nothing new at all.

[@SSukram_]

There is something new, a video with visuals, that explains each point in a clear and concise way. Literally all educational stuff online is based on existing research and documentation etc. Just because you are a godot veteran doesn't mean everybody is, some people out there don't read the docs in their spare time

[@bojaidin]

Who cares? Some people learn better by watching/listening to videos than they do just reading

[@SSukram_]

@@charlieking7600 also some people have vision impairments or things like dyslexia, which may make it hard to read

[@바오-c3p]

?? Then is there anything he can tell if it's not included in documentation?