Multi-thread solution for cpu performance demanding games and multiplayer servers

[SlyRebula]

Describe the project you are working on

I am working on a 2d survival game with dozens of new animal species and the player lives as one of these new animals.

Describe the problem or limitation you are having in your project

The game will have a complex and always active ecosystem which means heavy CPU usage(All animals are always active even when a player is not around and there will be dozens of them basically an ecosystem simulation)

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adding the MiniVerse feature, whole processes that are necessary to run the nodes, servers, etc will run in a container(Different threads), separated from each other. I have limited knowledge about the engine and I am new to coding so this is the best explanation I have for now.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The user will create miniverses for each separate world or separate chunks for the same world; for the chunks, there will be a separation point within the game such as cursed land the moment the player enters the land it will get dark and the player data will be transferred to other mini verse when the player exits the cursed land it will get too bright and the game will switch to new mini verse.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I think an extension or direct engine implication would be best but I am not qualified to comment on this.

Is there a reason why this should be core and not an add-on in the asset library?

I think this feature can also be used for massive multiplayer servers that have a lot of players.

[JoNax97]

Please correct me if I'm wrong, but I believe this is commonly known as sharding.

If that's the case, that's more of a server orchestration and database usage issue, and I think it falls outside of the scope of an engine like Godot.

[SlyRebula]

Please correct me if I'm wrong, but I believe this is commonly known as sharding.

If that's the case, that's more of a server orchestration and database usage issue, and I think it falls outside of the scope of an engine like Godot.

what I am saying is not sharding , the miniverses are different think the best and simplest way to explain is; let's say you have 1 map and with so many players it will lag out eventually now you can solve this by divading the map running multiple servers(headless godot game) with different ip addresses on the same machine ,but it will not be unified you are running same gamer server(headless godot game) multiple times on the same machine and there is no way for these servers to communicate what i am talking about is running scene and servers inside a container and then putting this containers inside each thread and creating a way for this conteiners to communicate this way you will divide one map into dozens of regions and distrubute the map and the game to multiple threads and when player moves to other reagon that communication between containers will enable player data to transfer to other region, to be honest i am not sure if i explained it in a understandeble way but here i go this is what i am proposing

[Calinou]

Moving to discussion, as there is no concrete technical implementation provided.

[theraot]

To me, this sounds like this proposal: #6424

[SlyRebula]

its not, in that proposal scenes being multi threaded but in my solution putting scene and servers inside each thread like a container and creating a system in the core side to make two containers communicate with eachother. if you look at this diagram you might understand it better https://docs.godotengine.org/en/latest/contributing/development/core_and_modules/godot_architecture_diagram.html

[JoNax97]

So, in a way, you want to run multiple instances of the godot simulation inside the same process.

That sounds like a more difficult way of achieving the same results you would get by running multiple Godot instances and using an external system for inter-instance communication.

[SlyRebula]

So, in a way, you want to run multiple instances of the godot simulation inside the same process.

That sounds like a more difficult way of achieving the same results you would get by running multiple Godot instances and using an external system for inter-instance communication.

yes it is harder but like this everything can be handled in the same program in a unified way also i think it would be more easy and faster way to communicate between containers , also this might be better as an extension instead of adding to the core