Hello everyone! I am bascially asking if this approach is not only fine, but also one that will not lead to headache down the road.
I am have an animal that has a physical and non-physical representation. The non-physical representation, UObject, would be found for sale in stores, and viewable (in UI) at the player’s “Warehouse”. The player can then make changes to the animal’s properties (which I am proposing are FGameplayAttributeData stored in a UAttributeSet) via interacting with this UObject representation of the animal.
But where it gets tricky, is that the physical (world) representation of the animal does not have its own UAttributeSet. Instead, it keeps a reference (pointer) to the UObject representation of the itself (animal), and queries it for the attributes when needed. So, if the state machine wanted to view the max health of the animal, it would do something like:
animalCharacter->getUObjectRepresentation()->getAttributeSet()->GetMaxHealth();
I do it likes this because if the animal is in the “Warehouse” (no physical representation), logic can still run like “wool” growing, and so the attributes still need to be viewed, or manipulated.
I have heard (but not sure how true) that the Gameplay Ability System (GAS) is designed to run in a live game environment where there is an UAbilitySystemComponent (ASC) attached to a spawned Actor. The ASC and AttributeSets are not just data containers; they are part of a running simulation. They listen for GameplayEffects, recalculate attributes, and handle replication and prediction.
The key being “attached to a spawned Actor”. I understand the ASC being on Actors only, but why does the UAttributeSet have to be as well? Would manipulating/changing the UAttributeSet not operate correctly if the ASC is not present?