if your skills don’t necessarily need to inherit from UObject if you don’t need to. You could then have plain C++ classes (which would need to be prefixed with the letter F) with regular constructors accepting arguments.
Though, I doubt you want that, because at some point you are going to need UObject functionalities (garbage collection / edition within the editor, etc…)
At some point, you will certainly want to edit your skills in the editor, because some of your pawns will need different skillsets.
What I recommand you to do, is to keep your skills inherit from UObject. You make the properties of URPGSkill editable in the editor. Your array of skills should be editable too.
And now, in the editor, you can add new skills in your array, and edit them on the fly.
You could also create a bunch of different skills in the editor (as blue print), and add them at will to your various classes
ActorComponents have their own Tick functions you can implement.
/** Called every frame */
virtual void TickComponent( float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction ) override;
// Sets default values for this component's properties
// Set this component to be initialized when the game starts, and to be ticked every frame. You can turn these features
// off to improve performance if you don't need them.
bWantsBeginPlay = true;
PrimaryComponentTick.bCanEverTick = true;
// Called every frame
void UYourActorComponent::TickComponent( float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction )
Super::TickComponent( DeltaTime, TickType, ThisTickFunction );
// Your Code
Well that really depends on what you want to include in the skills. If a skill is simply a number that can increase/decrease, you probably don’t need a class for each.
The way I’m doing my skill system is with a single class called “CharacterStats” which contains all of the stats (simple floats) like Speed, Strength etc.
Then I let the Character spawn an instance of this class and apply these numbers accordingly where required, e.g. when the Character jumps he looks up his JumpVelocity in his CharacterStats.
The CharacterStats class also contains handlers for calculated stats which must update based on other stats - here you can use anything from Delegates to simple Get() functions which will recalculate a stat each time it is queried.
In short, there’s no single correct answer, but you’ll need to think about how much functionality these conceptual objects must contain, and based on that you will use a UObject, Actor, Component, Struct, or some “Stats Singleton”.