#[Netcode] What is your strategy for keeping ghost component count at minimum?

1 messages · Page 1 of 1 (latest)

glad smelt
#

Hi everyone,
As you may know Netcode for Entities has a hard limit for component count with ghostfield for performance reasons. (128 by default, can be increased to 256 with define direction).
Without knowing the limitation, you may easily hit that number during production.
Because of that, now i want to reuse components as much as possible (example: i have a Timer component, i combine this with a tag component called Destroy, entity destroys itself with this timer, i also use Timer with Buff, Skill cooldown etc.) Since tag components does not have ghostfield, they won't use quota from 128/256.
For me, the hard part is RPG stats, making Health/HealthRegen/Attack/MoveSpeed ... individual components gives very good context and makes easier to build gameplay on top of it. But these may create snowball effect and you may end up with a lot of different components with ghost field.
Making each stat an Entity would be good solution, you could use same composition logic i mentioned for Timer/Destroy. But this is out of question for Netcode, these entities will be ghost, you will have 10 other networked entities just for one Unit.

My current solution is using dynamic buffer for stats, each stat is an element on a dynamic buffer. I can also use same buffer on different elements (Weapons, Pickable objecs etc.)
Down part is, this creates an abstraction, you need to find a way to build gameplay on top of that, for example you need to index each stat in another component (HealthIndex,MoveSpeedIndex etc.) these components don't have ghost field, they are statically baked in editor. This also worse in terms of memory layout/performance in comparison to direct approach.
If you take this few step further you will end up creating your own visual programming editor 🤣.
I would appreciate any suggestions.

broken shadow
#

In your case of an RPG I would imagine most of the entities that do have stats can have most of the stats. Thus having it in a "StatBuffer" which you imply already seems like a good solution, where you can simply index correct stat by some enum list. If the stats have some unique (Between eachother) constant processing I would consider separating it to some entity and maybe look at using SharedComponents to separate them for to the types. I've not looked into this myself but have you considered using Ghost Groups and compared performance if that would be viable?

glad smelt
#

I am actually using shared component for indexing those stats, this component is on the entity itself rather than a separate Entity. Why would you consider making it a separate Entity?