#Ability system with cooldown
1 messages ยท Page 1 of 1 (latest)
@fossil gorge @twilit raptor
The four files I'm working on are these: GFAbility, which is the basis of the ability, and Component, which manages it.
if this is for a technical test are you interested in some feedback for stuff I would suggest that isn't just "how to make a cooldown?"
I would love feedback
first of all you have a ton of needless includes... this is not really important now when you are still messing around with it but you should always forward declare when possible and not always include coreminimal for no reason
include what you ACTUALLY use
also use push model. I do not think it makes sense to not use pushmodel replication in a serious multiplayer project that cares about perf
I really want to be a better developer and I know you're a great developer; you've already helped me a few times!
uint8 AbilityID being uninitialized might not matter for a uobject given how they are allocated but it's confusing to read imo
not using TObjectPtr correctly either but that won't matter if this is ue4
why does FAbilityRepData include an owner actor for the ability? would it ever be different than the thing storing a UGFAbility ? Where do UGFAbilities live?
why does the ability need to be a separate replicated object?
It's UE 5.6.1
It's created by the component, so the component stores him
UGFAbilityComponent includes a replicated array of ability objects... I see
so it's entirely redundant then?
you can cache the owner on a local pointer when you init this object from a replication callback similar to a fastarray
To be honest, i don't know, i want to make a clear and extensible architecture for adding new capabilities.
How i would do that?
one benefit to it being a separate object is that you could add new replicated-per-instance stuff to it easily
but so far I do not see any need for that
honestly I am not 100% sure and I would have to look around a bit for a callback... I am not sure how to find the replicated object's owner in non-iris replication
it should be fairly well exposed assuming it always shows up afterwards but I am not certain about the ordering here
Clear and extensible architecture it's a requirement
so yeah... more objects = more complexity with networking here
this would make more sense if the ability was a separate object in the world like a placed mine or grenade
at least as a replication scheme
Will have a fireball (Who explodes), a swap zone (can't move), dash and damage zone by time
but yes the ability being a separate object will make adding new ones/extending them way more simple
I just personally do not think the extensibility would need to exist on the "shape" of each one as much as the idea of what they do
one way of having sort of both would be making the ability a sort of static object that just overrides behaviour and only modifies data in static functions... where the internal storage is mainly for settings (like an anim notify)
but adding new replicated behaviour there would have to be instanced struct/polymorphic serialization etc
like GAS event payloads
the dash ability is by far the most complicated (if it must be done with server auth/client prediction fully)
in order to do it correctly in a server authorative game it MUST be done in the cmc saved move unfortunately unless you cheese it with root motion etc (or turning off corrections for a second)
there are many resources on this
I can use cmc
yeah, this is for the cmc
I know (well, 99% of us are using that)
Mover might make doing this a bit easier in the future at least but it's not really nice to use yet or working well
also I would say it might be nicer to make TArray<UGFAbility a fast array so you can react to new ones appearing
that would also let you easily tell each new one about its owner etc
Fast array? I never heard about
time to google it then
if you are interested in doing networking in ue5 c++ you should check them out
the long story short is they provide a callback for each new or updated element in a replicated array and also send the data in a way that only sends updated elements
the header for them shows how to set one up fairly easily but it can be a bit of a pain... plenty of engine examples though
