Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future expansion of the ECS approach (if used) #2

Open
NancokPS2 opened this issue May 5, 2024 · 5 comments
Open

Future expansion of the ECS approach (if used) #2

NancokPS2 opened this issue May 5, 2024 · 5 comments

Comments

@NancokPS2
Copy link
Collaborator

NancokPS2 commented May 5, 2024

  • 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
Copy link
Owner

jonathaneeckhout commented May 16, 2024

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants