I’m having a really difficult time mapping out the components I want to implement in this game I’m developing. I find myself trying to write components like Offense, Defense, Movement, Spells, Items, Effects, and such. I feel like these components will be used by just about every unit in the game (or at least the vast majority) which seems like it defeats the purpose of composition.
What components do you typically end up writing for YOUR RPGs?
I’m currently working on an RPG project (my first one and very early stages still), but so far I’m finding that I’m tending towards inheritance over composition for the various systems (quests, work skills, game items), with the odd interface here and there.
I haven’t started work on the combat system yet, so I don’t know yet how that will pan out, but I’m thinking that it might be a better candidate for composition than the other parts…
Offensive and defensive powers (including spells) can all be rolled into one component, “Skill”, that you inherit from. If there are basic skills absolutely everybody has, a component may not be the best choice. I’d make all the basics like strength, toughness, movement speed attributes of the core class.
Every character or NPC would have a component like “Actor” or “Agent”, which has all the basic attributes (strength, toughness, intelligence, health, resistances, whatever). Then any specialised skills or spells they train are just one or more lists of names with attributes (this could be ScriptableObjects too, which have many bonus features). You don’t have to go nuts with components for everything.
@orb suggested a wise direction by thinking on the level of systems rather than components. Your skill system or attribute system or inventory system may comprise several components. If you can design these systems to work as independently of each other as possible, it’ll make it easier to develop, test, and change them without impacting other systems.
However you structure it, I always do my best to separate input from function. If I were to have a Movement component, it would read inputs from an abstract concept of an input controller, not directly from Unity’s Input class. This way PCs can use the Movement component by setting the abstract input controller from Unity’s Input class, and NPCs can use the same Movement component by setting the abstract input controller from AI code. (In practice, I wouldn’t be thinking on the level of a single Movement component, though. I have an “Actor” or “Body” system that comprises multiple related components.)
that’s the way unity’s new input handling is going too, whenever it gets here…