I have a gameplay system that is designed to exist and run only on the owning client, and I want to author a gameplay ability to use that system in a way that correctly implements GAS features (cues, cooldown, tag blocking, cost etc), but allows the client to remain authoritative.
I have used the rough flow implemented in the lyra example for the weapon fire ability.
The flow is as follows:
- Client runs gameplay logic that relies on the local system to establish a target
- Client ability instance sends target data to the server
- Ability is committed on the server
- Ability completes gameplay logic on the server and client (cues/notifies etc.)
- Ability ends on the server
Please take a look at the attached minimal example and help me answer the following questions:
- Is the flow correct for a client authoritative system on owning pawn (does not exist on server) ?
- Is the commiting of the ability happening in the right place? Should I commit both on client & server?
- What is the hook/callback from the server if the ability was not committed successfully?
- Is the use of a local prediction window implemented correctly. I tried to use lyra as an example but it does not explicitly have a scenario where the server rejects the ability, and the client has to cleanup/react.
- Is the cue flow correct (e.g. it won’t double fire on the client)
FYI - The ability has a cost effect, that consumes an certain amount of a given attribute.
[Attachment Removed]