Is there any reason I shouldn’t have a lot of small non-scene actor components (like a unique one for stamina, health, status effects, etc)? I feel like this is the most practical way for me to make a variety of both playable and NPC characters that don’t end up having a lot of unused code, but I am worried having a lot of these smaller systems may be problematic for performance for reasons I don’t know about. Assuming these do not have tick enabled, is there any reason I couldnt have ~10 actor components on playable characters (would probably be only ~2-3 for NPCs)? I have not seen any performance issues so far but I want to see what the general consensus if before getting to far into the project. I could technically reduce this count by grouping things like health and stamina, however, not all damageable characters need to have a stamina component so ideally, they would be move segmented like they are now.
10 non-scene actor components on a player should be fine unless they’re doing something ridiculous like solving pi to 200 decimal place precision every frame. I’ve seen more in major games that have a dozen+ to track health/mana/stam/buffs and debuffs/combat stats/hunger/inventory/character appearance/quests/faction or clan info/xp/spellbook/etc..
Could probably trim it down some using the Gameplay Ability System and its built-in attributes comp. It isn’t the most blueprint friendly of things, but there are guides to get it up and running.
If tick is turned off on a comp, it’s not that much worse than a function library.
Combine where you can, like stamina and health could be in the same component.
Also look at adding the components at runtime based on proxy (autonomous, authority, simulated). In multiplayer a lot of these components wouldn’t be needed on sims and server proxies.
For example I remove camera components from sim proxies on spawn. There’s literally no reason for them.