I'm making a WinForms character generator and manager for a tabletop RPG. I'd like to generate characters randomly, optionally fix choices like species or class, and load definitions from JSON so the game can grow without recompiling for every new option.
I'm stuck on anatomy in particular. A human, a winged creature, and a character with a serpent tail have different parts. Should Character have nullable fields for every possible part, or a collection of generic parts?
Start with what the game actually needs to ask about anatomy. If species completely determines appearance and nothing ever changes it, a species definition may be enough. You don't need a separate object for each eye just to display a description.
Individual parts become useful if a character can lose a wing, gain a tail, equip something on a particular hand, or otherwise differ from the species template. That decision will save you a lot of modeling work either way.
For changeable anatomy, I'd use composition. Give Character a collection of BodyPart instances, and give each part a type identifier plus whatever state the rules need. A part could also have child parts, so a hand can belong to an arm and an eye to a head.
Keep the definitions separate from the instances. JSON might define a human template with two arms and a head, while a generated character gets its own copies of those parts. That way changing one character's anatomy doesn't change the template or other characters.
You can look up part definitions by ID in a dictionary. For the character's parts, a list is often fine, especially if there are only a few. Use unique instance IDs if you need to distinguish the left hand from the right or attach equipment to one specific part.
t603+stapler_9:
Would adding a new part type to JSON be enough, or would that still need a code change?
Kelmby+later:
It can be enough if the new part uses properties and behaviors the program already understands. A genuinely new rule or interaction still needs code, unless you've built a rule system that can express it in data.
Watch out for the other extreme: a completely generic bag of properties can make every rule harder to understand. Give your core objects a stable shape, then put the variable values and relationships in data.
For example, a part definition could have an ID, display name and tags. Rules that only care whether something can fly might check for a known capability rather than a field named Wings. JSON can introduce another part with that capability, but the meaning of flying still has to be implemented somewhere.
Separate generation from the character model too. Load and validate the definitions first, then have a generator accept optional fixed choices and select the remaining values from compatible options. The resulting Character should hold the chosen IDs and its own mutable state, not just a reference to the generator settings.
Validate missing IDs and incompatible choices before generating. That will make a bad JSON definition much easier to diagnose than a null error somewhere in the WinForms interface.
Answers are reviewed before publication.
Fennick.2r:
You could still keep a description in the species data and add individual parts later if the rules start needing them.