Abilitysystem with netcode for entities - How to communicate btw. client and server?

[shadow pawn]

Hello everyone,
Iam currently trying to implement an ability System using entities with netcode for entities.

Because of the GhostLimit of 256, it is a bad idea to use a Ghostcomponent/Entity for every Ability per client.
So Iam trying to have less ability components. Also the bandwidth might become a problem at some point.

I cant decide which method I should use to synchronize the activation of an ability between client and server (and other clients).
Currently Iam using RPCs, because they are "one-shot", reliable and the method I have used in netcode for gameobjects.
Or should I use Ghost snapshots or commands?

Currently it works with RPCs like this:

1. Client presses button for ability
   2.Ability gets executed on client while the RPC (direction, rotation, abilityId,...) for the ability gets send to the server
2. Host/Server receives ability and checks for conditions (is player allowed to execute ability, does the ability exists....)
3. Host/Server than executes ability (spawns non ghost entity) while sending out a broadcast to every client to inform about the executed ability
4. Other clients receive the RPC and also execute it

I also thought about using IInputComponentData, but I feel it might need RPCs and IInputComponentData. Like so:

1. The client presses the ability button, which gathers the input data for the ability.
2. The input data is stored in an instance of IInputComponentData.
3. The client sends the input data to the server using the Command pattern.
4. The server receives the input data and checks the ability conditions.
5. If the conditions are met, the server executes the ability logic and updates the game state.
6. The server sends an RPC to all clients to notify them of the changes in the game state.
7. The clients receive the RPC and update their local game state accordingly.

What would be the correct approach to implement an efficent ability system using netcode for entities?
Thanks for any input.
-Manu

[wintry rampart]

@shadow pawn You can use InputEvent in your IInputComponentData struct to send events. I use this for jumping.

I use RPC mostly for connection commands. Like, your connection is sending an RPC to the server.
I use IInputComponentData when I want the entity I'm predicting to communicate with the authoritative entity on the server. So in this case using IInputComponentData is the proper way in my opinion.

The benefit of using IInputComponentData instead or RPC is that you can predict your abilities on the client.
https://youtu.be/zrIY0eIyqmI?t=1372

[fringe nymph]

Yeah, using RPC for gameplay - is a no no. There is a much harder limit on RPC count, rather than ghost components.

I wouldn't worry too much about ghost component limit. It's likely that many components will be reused anyway.
On top of that - you don't have to sync absolutely everything with client. Some things are fine to be server only.
So even if your abilities will use 100 ghost components total for a whole game - I think it's totally fine.

[shadow pawn]

Thank you for your responses. So I guess RPCs is the wrong way doing this and Iam going with IInputComponentData. But I wonder how to tell the other clients "player3 just activated ability". Would I just implement a system which read the inputs from IInputComponentData and act on that? Or would I just spawn a ghost component on the server which gets replicated to the clients?

[wintry rampart]

I haven't gotten to that point in my code yet where I need to send events to players but I have a general plan in mind.

Instead of broadcasting to clients that a certain ability has happened I instead break up the ability event into the visual representations that have to happen on the client. AudioEvent, SpawnEffect, etc...
So instead of 100 ghost components for each ability I instead have a few.

[fringe nymph]

predicted ghosts sync input struct as well

and in general all other ghost components will be synced

[wintry rampart]

Hmm. Do I get the input from other players too?

[fringe nymph]

client sends his own input to server. Server syncs input with other clients.
But might need to confirm this

[wintry rampart]

It would enable remote player prediction by default, which is kinda cool. If it's true then that's something I didn't know 😄

[shadow pawn]

I guess grouping abilities is a must. I will try implementing it the next few days in my spare time.

Back in the days I asked a unity developer about this topic...
I asked him about using a new Ghostcomponent/Entity for every Ability that this might be a bad idea, because there is a GhostLimit of 256.
"Using one component per ability indeed can be a limiting factor. And it is also a very demanding ones in term of structural changes.Also, that would not work for Ghosts, because the replicated archetype need to be "constant". You can't add replicated component at runtime.Having all the possible abilitiy as IEneablableComponent may save you in that sense, but:
Both component number can be quite high. The size of the Entity increase a lot for nothing.
Splitting the constant ability data / properties in Blob is a first important design decision (because reduce drastically the entity storage cost). Some data duplication can still be beneficial for cache miss reduction and better cache usage.
A more scalable solution would probably to opt for having or few Ability components , that track the number of active abilities (maybe per group or type)."

Just this as additional information