for Example if I wanted to implement the IA_Attack1 in my BP_Character derived class (for this example the class is called ARuinsCharacter so the BP_RuinsCharacter)
and ARuinsCharacter.h declares
public:
UPROPERTY(VisibleAnywhere, BlueprintReadWrite)
TObjectPrt<URUNActionQueue> ActionQueue;
//...
UFUNCTION(BlueprintCallable)
EReturnEnum BeforeAction();
UFUNCTION(BlueprintCallable)
void PostAction();
the could also be
BlueprintNativeEventsif you want part of the functionality to be definable in Blueprints but other parts defined in C++, orBlueprintImplementableEventif you wanted the functionality to exist in blueprints, but the promise of the function to be defined in C++.
so then in the blueprint of the character I can do:
so if you would imagine that these BeforeAction and PostAction do something specific on the Character class, and then the ActionQueue->PeekCurrent could be a member function on whatever you have for the container holding your UAbilityComonent objects.
an implementation like this would require your Character class to HaveA container to your UAbilityComonent, but this still allows for re-usability of the UAbilityComponent Container and UAbilityComponent as they do not nessesarily depend on any of the code in the Character Class (they just need to have functions that are exposed enough to be called with appropriate variable types
for a delegate system I mean more of a regular delegate you would still need to define the Delegate Bind point somewhere that makes sense. I tend to not favor Delegates myself (at best they are calling out to something that is rarely needed and hard to get. At worst it is just an obfuscated function call and doing enough of them is coupling in and of itself) I am mentioning them more out of completeness, and not trying to pigeon whole your design.
