Hi, so I’m used to creating everything in a hierarchy E.G making a generic character class that does everything that pertains to all creatures, like health, movement, mesh, collision, physics, etc, then making a player character that makes use of the movement through inputs, and a different child class that handles AI, so that I only have to do the universal things once.
Well, my current project started out as just an experiment so I didn’t plan the hierarchy out ahead of time, but now it’s evolved a lot from there. Now all the player functionality is in a single class, including things that should be inherited and available to things like NPCs and enemies as well, like how damage is handled, death states, animations, movement, etc, and now I want to do create an enemy class.
At first I thought I’d just create a new character class, move the general stuff in there, put the player relevant code in a new player class that inherits from the character, and have the have the player blueprint reparented. But if I reparent things now, all the work I’ve put into the blueprints is pretty much guaranteed to break, which is a lot of experimental and time consuming tweaking. So I thought why not keep the current class, but break the situational stuff off into components?
So what I could do is keep the current character class, but split of the player controls into a player controller component, then just have all the player relevant variables in blueprint refer to the component instead of the character class. That way I could also define NPC/Enemy/AI controls in a component, and just attach that to the generic character class if I want the AI to take control of a particular pawn. Basically treating control and actions similarily to how you would attach collision components, camera components etc.
What would be the downside of this other than an unconvential way of organizing these kinds classes?