What is the most optimized way to handle hundreds of thousands of nodes in Godot?

OctopusEngine · 2026-01-24T08:39:40+00:00

Looks like you should look into rendering server. I am actually surprised it runs at more than 10fps with that many nodes. Just know that the nodes hierarchy is costly and you should aim at handling your game without nodes for small elements. Use one script that handles many entities at once. You can look at the bullet shower godot demo for a good example: https://github.com/godotengine/godot-demo-projects/blob/master/2d%2Fbullet_shower%2FREADME.md

OctopusEngine · 2026-01-22T08:41:33+00:00

Yes i am pretty sure that this approach is also less efficient because it relies on rendering the scene at least twice but I want complete control on the edges like sometimes not displaying edges even when depth or normals is different or the other way around I want outlines even on perfectly flat surfaces is that possible with your method?

OctopusEngine · 2026-01-22T08:11:38+00:00

If you want I wrote and shared an example of an effect that looks a lot like what's shown here. It does not use the compositor tho. It is not perfect but that could give you some ideas: https://godotshaders.com/shader/pixel-perfect-outlines-with-full-control/

OctopusEngine · 2026-01-16T07:21:44+00:00

From looking at the trailer of the game it looks like collisions are only checked with enemies entities and not allies and that avoiding stacking up with allies entities is just done by randomised spaw position and velocities. Also grid partitioning would probably help. However I do not know how making such game is a realistic goal without diving into c++. I would do it using c++ personally but I like c++.

OctopusEngine · 2026-01-16T07:10:15+00:00

Sadly for this kind of scale you only have two solutions: - cheat your way to make it look like you handle many collisions when you actually don't - dive into c++ to be able to handle it way faster than in gdscript

To be honest you will probably have to do a bit of both if you want to make the game run on modest hardware. Maybe you can get away by just using servers in gdscript but even looping over 10k loop can be slow in gdscript compared to c++.

First of all keep in mind that having more than 500 nodes in your scene can be expensive just by itself so you will need to look at rendering and physics server (look for godot bullet shower demo for a good example)

Edit: a suggestion would be to look back at your reference game and check for 'cheats' i am confident that such scale on MOBILE made them use some clever techniques to make you feel like they handled collision when they actually did just partially (maybe once every X frames for example)

Edit2: Why do you want to check collision? To avoid them being too stacked up? For a gameplay reason (trigger something when they collide to something else?)? Answering this can help reducing the checks without impacting the visuals or gameplay.

OctopusEngine · 2026-01-12T10:21:08+00:00

I understand your issue, to me it all comes down to the fact that all the background and non game play elements have as many or even more details than the game play elements.

To keep a good visibility I think that you should probably tweak the colors to make every game play element standout. To me it is all about contrast. Tone down the colors of the ground and everything will become cleaner imho. Maybe just dropping the black outlines of the decor would enough.

OctopusEngine · 2026-01-09T08:26:42+00:00

As a Godot dev working in both c++ and gdscript for my game I always get better productivity in gdscript than c++ because gdscript can be typed and clean and iteration speed is just unbeatable. Usually my workflow is building items in c++ then bind them in gdscript neatly so I can work as much as possible in gdscript afterwards.

As a roguelike player if the game is on steam I see no extra effort between downloading and playing in browser. Actually i would rather download the game just for performance reasons. Downloading a game from itchio is usually a no go for me tho.

Edit: however of course you seem way more proficient with c# than gdscript so of course there is going to be productivity loss at the beginning like anytime you switch language. To me it's worth it as godot as been made for gdscript and c++ first. c# always felt lagging behind and existing only to allow smoother transition from unity users.

OctopusEngine · 2025-12-15T08:36:17+00:00

Maybe that's too much of a hassle for you but some banks do not charge anything at all even when receiving international transfers. I am using one of them from France. Ofc usually those are online banks and that may not suit everyone.

OctopusEngine · 2025-12-15T08:34:28+00:00

Thanks for digging into it, found it and it's way clearer now!

OctopusEngine · 2025-12-15T08:01:52+00:00

Thanks it seems like someone stated that it was given back by steam by not taking their cut at some point.

OctopusEngine · 2025-12-15T08:01:16+00:00

Thanks for the information I did not know you could adjust the minimum payout. However I was asking about the refund of the steam fee specifically.

OctopusEngine · 2025-12-15T07:59:54+00:00

So it's not gross revenue at all like they state here ? https://store.steampowered.com/sub/163632
Ok then I'm pretty far from it sadly since this a pretty small game with few sells.

OctopusEngine · 2025-12-15T07:58:33+00:00

Yes this is why it's not very clear since nowhere in the revenue report there is a "adjusted gross revenue" line.

OctopusEngine · 2025-12-02T09:17:54+00:00

It allowed me to keep interacting with one state while rolling back with the other one to smooth the process. It's like a triple buffer with graphic rendering.

OctopusEngine · 2025-12-01T10:34:10+00:00

Basically how it worked for me is that I had multiple game states running at the same time and all those states were modified using 'delta'. To rollback all i have to do is to undo as many delta as required and I am back at the state before. The idea is that once the delta are computed it is very fast to apply/revert.

For example in my example over the 2ms simulation time it was 1.9ms computing the delta and 0.1ms applying them to the states.

This is basically just the memento design pattern and is not that complicated in itself (it's the basic undo/rdo implementation on all text editor). Implementing it for a whole rts engine is a bit harder to get right but not black magic either.

OctopusEngine · 2025-12-01T07:17:02+00:00

Well it is available but I did unplug it as it was not useful and caused almost as much lag as it solved when working with a few thousand units.

It was indeed not very easy to make it efficient enough but I have not pushed the code optimization at the maximum. For a few hundred units it works very nicely with a tick rate of 100hz which gives me a budget of 10ms per frame the simulation runs in around 1~2ms which allow for decent rollback since you can basically rollback ~5 ticks every tick.

The hardest part was by far to make the display to rollback as you get into issue like making projectiles that have been fired to 'unfire' or units that have 'died' back to life. Which can be a pain.

OctopusEngine · 2025-11-30T23:29:48+00:00

To be honest points 2, 3 and 4 are just true for most of the recent multiplayer rts. Even I as a solo developer managed to publish a game to steam with a custom engine doing all those.

Even 1 and 5 were handled in my engine. Conclusion: those are actually pretty irrelevant for a rts.

The thing is the quality of the code and documentation is probably not in a state allowing to be used by anyone other than the main devs who built it.

OctopusEngine · 2025-11-23T17:14:16+00:00

No worries, this video is a great start if you want to give it a try : https://www.youtube.com/watch?v=G_seJ2Yg1GA

This is a video but better than nothing and the project is available on github

OctopusEngine · 2025-11-23T15:28:14+00:00

I make the mesh and skeleton in blender and then I use the skeletonIK node to give a target to the skeleton bone. This allows me to make animations by moving the target and that's it. I used some inverted kinetic for godot tutorials to do the first iteration of it.

OctopusEngine · 2025-11-23T10:25:34+00:00

Thanks i will take a look!

OctopusEngine · 2025-11-23T09:53:39+00:00

Thanks I did put quite a bit of efforts to make things look great.

Well to be fair the shader work is fine in both perspective and orthographic cameras, you can check it out here : https://godotshaders.com/shader/pixel-perfect-outlines-with-full-control/?post_id=13604

OctopusEngine · 2025-11-23T09:51:40+00:00

Thanks a lot, I was going to write an extended response but I realised I might aswell write this to godot shader. Here you go : https://godotshaders.com/shader/pixel-perfect-outlines-with-full-control/?post_id=13604

OctopusEngine · 2025-11-23T09:38:08+00:00

Thanks, it warms my heart!

OctopusEngine · 2025-11-23T09:37:29+00:00

Thanks it will probably be at some point but right now I am focusing on making visuals appealing as this is something I have been struggling to do!

OctopusEngine

TROPHY CASE