Can Godot Handle 10,000 Bullets?!

can godo handle 10 000 bullets of course it can even many more this demo by samuel is running in godot with 20 000 bullets on screen at 60 frames per second this uses c plus plus but what if we use gudu's simpler scripting language gdscript using the powerful physics server you'll easily get thousands on screen that's not as fast as c plus plus but still more than enough for the vast majority of us let's look at the naive and slow way first and then how you make your code run faster in godot if you use the most basic approach you may only get 1000 bullets at 60 frames per second in this example we're using an area 2d node with a collision shape and a sprite when shooting we instantiate bullets and when they travel past their maximum range we delete them using the q3 function the result can be a bit disappointing however with a really simple change we can instantly double our performance by default all our bullets try to detect others every frame because of the default collision layer and mask settings uncheck the collision layer and turn off the area's monitorable property and you instantly double your max bullet count figuring out the next step was a little harder i tried to use pulling a technique with which you pre-instantiate thousands and thousands of bullets and just reuse them i showcased it in the gd script pro tips video with the pull when removing the notes from the scene tree after using them the performance was not better even without that using so many area2d nodes limited performance when it comes to performance you always want to test and measure what is slowing you down one change at a time you shouldn't make assumptions because you'll often be wrong and waste time see the free guides in the description to learn more in the next demo i did two things instead of using three notes for the bullets i just used one sprite then i tapped into gudo's physics server to check for collisions it's a little more code but generally faster too i also stopped removing nodes from the scene tree it turned out adding all the nodes as children of the gun and just turning off processing and hiding them improved performance greatly in this demo when a bullet hit something it just turns itself off the note is still there but it's invisible and not doing anything the result you get up to seven thousand to eight thousand bullets on screen which isn't too bad this experiment shows that by making a couple changes and using a little more code you can often multiply the performance of some critical piece of your game if you need to you can even go further like samuel lee did and write that critical piece in a much faster language like c plus plus then you can squeeze every ounce of speed out of the computer and the engine there's a big misconception that godot is slow i won't deny that some parts could use performance improvements but well those are coming with every new release however good is already much faster than many think with its fast data driven call by default gudo gives you those convenient nodes that save you a lot of code you get that convenience at the cost of some speed in most cases using lots of nodes is not a problem at all so you don't have to worry about it when it is though goto provides the servers to maximize performance the engine is very flexible you are never stuck with the nodes right now we're on kickstarter to find a complete course and app for absolute beginners to learn to code from xero with godot the app will be free and open source to help everyone get on board much more easily if you struggle to learn to code in the past or would like to help a loved one get into game development this might well be the course for you click the link in the description to get all the details be creative have fun and i hope to see you in the next one tomorrow

Channel: GDQuest

Views: 16,943

Keywords:

Id: _z7Z7PrTD_M

Length: 3min 51sec (231 seconds)

Published: Fri Oct 22 2021

Reddit Comments

[u/chillermane]

Great advice about measuring performance.

I wouldnt recommend not deleting the bullet nodes, though. Each of those nodes costs a little bit of memory. If a user keeps playing the game, they will eventually run out of memory if nodes are never deleted

[u/Epsilon_balls]

Can you expound upon why you think pooling did not improve performance in any meaningful way? That was a surprising result to hear.

[u/AutoModerator]

This post appears to be a direct link to a video.

As a reminder, please note that posting footage of a game in a standalone thread to request feedback or show off your work is against the rules of /r/gamedev. That content would be more appropriate as a comment in the next Screenshot Saturday (or a more fitting weekly thread), where you'll have the opportunity to share 2-way feedback with others.

/r/gamedev puts an emphasis on knowledge sharing. If you want to make a standalone post about your game, make sure it's informative and geared specifically towards other developers.

Please check out the following resources for more information:

Weekly Threads 101: Making Good Use of /r/gamedev

Posting about your projects on /r/gamedev (Guide)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ClassicCroissant]

Performance is a very interesting subject.

It is nice to know about certain paths in the design mode of Godot that can give you better results.

[u/JustGameDevThings]

So I tried this in C# in my own project (which admittedly muddies the waters) and noticed a few things.

At 1:55, the code sample creates two objects every frame: the query itself, and the result. At the 1000-1400 active bullets mark, I noticed sharp framerate drops (active meaning in tree, but not updating or visible). When I instead made the query object in the ready function, while the number of objects was still large (which should be obvious why), the framerate kept a stable 60fps at the same number of bullets, upwards to about 2k (where the framerate seems to drop again). I took this further by passing the same query object and changing the parameters during process instead, but this had no further influence (the object count did drop significantly, but since there was no removing and creating of objects it didn't seem problematic).

While I can accept that the things I'm doing could account for a 5x difference (I have yet to see 10k stable), I do wonder why my C# has problems with doing things in the process while the shown GDscript snippet seems to be doing fine. Obviously I'd need to actually write a GDscript version as well to compare the two on my own end, but it stuck out as something odd.

As an aside, I can attest deactivating nodes rather than removing them significantly improved the performance.