Future expansion of the ECS approach (if used)

[NancokPS2]

• Change system functionality's (or ability to run for that matter) depending if it is a client or the server.
• Allow System to slow down its tick rate when the server is under stress (reduction set per System)
• Allow Component to define which properties should be synchronized using the MultiplayerSynchronizer class.
• Look into alternatives to Timer nodes for System as to reduce node count.
• Downgrade Component and System from Node3D to Node.

[jonathaneeckhout]

Allow System to slow down its tick rate when the server is under stress (reduction set per System) -> I think Godot does this out of the box. If the load is too high, the phyics time will be longer.

[jonathaneeckhout]

Look into alternatives to Timer nodes for System as to reduce node count.

-> I see that you've created your own timer system in code, but are you sure this is more efficient than using the native Timer Nodes? These Native Timer Nodes are well hooked up into the game engine and written in c/c++ making them much faster/efficient than GDscript code.

[jonathaneeckhout]

When testing the game the StatusBarSystem confused me. The statusbar is a scene under the Systems node which is part of the Main scene but the statusbar is part of the player.

Isn't this a bit against the philosophy of a component system?

A component should be placed directly under the parents node to enhance it's parent's behavior?

Also the healthbar is set via code, in my experience it's better to use an export in the the component request a node (progressbar) which is placed under the parent. This was the layout of the parent can always be modified in the Godot editor and it's clear how it will look ingame.

[NancokPS2]

The Sprite3D node is merely a way of displaying the health bar. It is not a component itself. Ideally there wouldn't even be a node being used but idk the RenderingServer well enough to pull it off without nodes.
It is kept under the System to avoid it from affecting the player's scripts, since the only one that needs to touch it is the System.

[NancokPS2]

Allow System to slow down its tick rate when the server is under stress (reduction set per System) -> I think Godot does this out of the box. If the load is too high, the phyics time will be longer.

My idea was to make it a priority system, some systems are less important than others. Just like _process() is less important than _physics_process() and the former is delayed in favor of the later.

I just saw it done that way in Rimworld and it is what keeps the game playable most of the time. It is very important when each system is going to remain independent and they can't tell each other when to run and when to wait.