Hi Nebula,
Thank you for your reply.
I think the reason I wanted to enemies/friendlies to share a parent is because the way I am thinking of doing enemies is in part similar to frendlies. For example, there about 40-50 variables similar to FireResist (if not more) that I will use solely for combat. Both enemies and friendlies need to have these for the combat to work - but I don’t really want to have to add and configure all these variables and the blueprinting of how the combat is handled separately. Some variables may be different values for a friendly vs an enemy (hence the child classes), but 90% the same structure. I was thinking one “BaseCharacter” blueprint with two childen “BaseEnemy” and "BaseFriendly"with those two children having their own children for each individual enemy/friendly.
“Get all enemies and friendlies” isnt necessarily something I would do (and if I needed to I probably could do that with 2 seperate classes as you say), I am considering it purely to reduce some of the overhead of setting up 2 classes that I think are going to have 90% of the same variables. What are your thoughts on that? Is there something I am missing there?
As far as storing the variables in Player Controller, I am not really planning on switching to different characters with the player, but maybe thats something I want to do to leave the option open.
So would GameInstance hold my logic for combat then? (like if a sword is swung and hits the enemy, do xx damage based on enemy defense)
Or is this something I would have a separate Blueprint handle that I would just place in a level. I am not entirely sure how all the mechanics are supposed to be organized (is it usually a blueprint placed into a level seperate from the objects that are involved, or is the logic contained inside the objects?) Like do my enemies have combat logic in their Pawns, or is combat logic a seperate Actor placed in the level (CombatLogic or similar)?