Godot Version
4.2
Question
I want to create a game where the player entities need to have thousands of nodes on the same screen without lagging, ideally tens of thousands. The nodes should bounce off the walls when they hit them. However, when I generate hundreds of nodes, it already causes lag. I’m using the CharacterBody2D node.
The statement velocity = player_direction * speed * delta takes up the most frame time because hundreds of nodes are running this statement simultaneously, causing lag.
If Godot doesn’t have a technology similar to Unity’s DOTS, is there any way to solve my problem? I hope an expert can help me with this. Thank you.
Why are you using CharacterBody2D out of interest? I would only use that if I needed to as its very heavy on physics simulation.
1 Like
grulps
April 22, 2024, 1:09pm
3
There’s a feature proposal for this kind of functionality, but it hasn’t been implemented yet.
opened 05:16PM - 28 Feb 21 UTC
topic:core
performance
### Describe the project you are working on
Godot
### Describe the problem… or limitation you are having in your project
Godot is designed to be easy to use as first priority. The Scene system in Godot (Scene and Nodes) are designed for maximum flexibility as well as simplicity. This works great in most cases.
In some situations, however, this can be too much when dealing with very large amount of objects (passing the thousands, or dozens of thousands). While in most cases this is not a common case, some situations require large amounts of elements to be processed, such as:
* Projectiles (bullet hells as an example)
* Units (certain types of games, such some type of strategy, or city builders) require large amount of units moving around.
* Flocks /Swarms/ Mobs
* Debris
* More complex CPU particles than what supported by the CPUParticles.
* Etc.
These situations have different requirements than what you often find in most games, as they consist of large amounts of simple entities, rather than smaller amounts of complex ones. Again, Godot scene system is designed for moderate amounts of complex entities (as this is what is required in most games), but proves to be overkill for large amounts of simple ones, as lack of cache efficiency and the complexities of the tree-based structure slow things down.
The only way to do this in Godot right now is to talk to servers directly or go via GDNative, but this is not accessible for most Godot users. Other game engines rely on ECS to solve this (Unity is working on it), but this is also an approach geared to more experienced programmers, whereas Godot aims to be a very easy to use tool where someone without high technical education or lots of experience can still solve the complex problems inherent to game development (then Again, for those more experienced, or more complex problems, [GodEx](https://github.com/GodotECS/godex) can be the solution).
### Describe the feature / enhancement and how it helps to overcome the problem or limitation
What I propose is creating an alternate way to deal with large amounts of simple entities. It could be called "The Swarm System". A system would be created in a Resource and edited in the editor. You would visually configure how you want your swarm to be basically ticking boxes such as:
* 2D or 3D
* Has collision shapes
* Is a rigid body, kinematic or a character body (in case it has collisionshapes)
* Will draw to the screen
* If draws, it does using individual canvas item (2D)/visual instance(3D) or as par of a MultiMesh
* For 3D, whether it has skeletal animation, for which it will contain a very simplified/more optimized skeletal animation data.
* For 2D, most likely animation frame data
* Is a navigation agent (will use navigation)
* Whether it will want to query access to nearby objects and what will be the maximum distance checked (for flocks).
* Script
The script (at least GDScript and and C#) will probably need to support something extra internally, as its data will need to stored contigous in memory in order to be processed. C++/GDNative will expose this also so other languages can support it.
### Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
There will be a SwarmFormat resource, which can be edited and configured, saved to disk or similar. Probably with a bit more advanced options whether you want this to be processed in threads (more entities at the cost of being more careful with threads).
Additionally, there will be a Swarm node that will allow setting swarms and control their spawning and execution via API.
A common question to this may be, what if you want to have slightly different objects in a swarm? For this, you can either create multiple ones, or just do whatever you need by code in every swarm entity at the cost of performance/flexibility.
Again, if more flexibility is required, users can use an ECS system or simply write their own low level code and interact with the servers directly, but the idea of swarms is to cover the vast majority of cases where you need this performance optimization and still keep it easy to use and well integrated to Godot.
Swarms will be able to interact easily with nodes and vice versa, for greater ease of use.
### If this enhancement will not be used often, can it be worked around with a few lines of script?
### Is there a reason why this should be core and not an add-on in the asset library?
No, this is definitely core, needs to interact with everything that is there easily.
---
The idea of this proposals is for community to discuss and give feedback on this idea!
1 Like
mrcdk
April 22, 2024, 5:11pm
4
2 Likes
Because the player collides with the wall, it needs to bounce back.
I am currently working on a single-player game, but thank you for your response nonetheless.
@ysypnbh
A few points of clarity:
CharacterBody2D is a very performance intensive physics node that is intended for cases where you want complex physics behaviour. As the name implies it is intended to be used with your main player character, rather than for thousands of other entities. You should consider not using CharacterBody2D.
Godot uses a “server” architecture for Physics and Rendering. The link that mrcdk linked to is not about networking with servers, it is about optimizing games like yours by using the Physics server directly instead of using nodes. By using the Physics server directly you can improve performance significantly.
2 Likes
Thank you. It was my misunderstanding. Thank you for your advice. I may need to study further on how to use it.