What design pattern should be used when there are a lot of different possible jobs?

Some background information on what I am trying to accomplish. I am creating the game in Unity using C#. Basically, I am trying to create an RPG type of game where it really harps on the idea of a lot of different possible classes/jobs(I will call them jobs so not to confuse anyone). Basically, every job will have its own unique set of skills and can only do certain tasks, not dissimilar to a lot of games out there. However, the way I see most of the advice given down this path is simple inheritance, mostly because the user is only trying to implement 2 or 3 unique jobs. I feel as though this is just the easy answer that ends up causing a lot more headaches in the long run when you have lots of different jobs to implement.

So my main question is, what design patterns would someone use when there are a lot of different jobs that the programmer needs to implement?

This question is hard to answer without knowing exactly what your game system does and does not allows your "jobs" to do.

But usually I would use composition instead of inheritance. There would be just one class Job. Each instance of Job has a List<Skill> skills (or other appropriate data-structure). You are not saying much about what "do certain tasks" actually means in your game. Does each skill represent exactly one task which the player can perform with some input action? Then Skill would have an abstract method perform() or performOn(GameObject target). Or can a skill actually provide more than one task? Maybe even depending on some other factors? Then Skill might need a method which returns a IEnumerable<Task>.

But either way, I would try to use as few classes inheriting from Skill as possible. Skills with similar functionality should use the same class with different values.

For example, let's say you have skills like Woodcutting, Mining, Foraging and Fishing. Having one of those skills allows the player to perform the "extract resource from resource node" task and this task is mechanically identical for each skill. They just differ by the kind of node they work on. I that case I would just have one class ResourceGatheringSkill inheriting from Skill. The different instances of this class would differ by a property which says which resource nodes it works on.

You could even go a step further and move the logic to decide what can and can not be gathered to the resource nodes. In that case the resource gathering skills become even simpler. The script on the resource nodes would just check if the job of the player-character has a skill with a specific name. In that case Skill would just need a property name, nothing more.

• Basically, what you're saying is that I would create a Job instance like, Wizard, and then assign it a List of Skills. However, I should generalize the skills into as few and generic classes as possible. As for the wizard it would have a CastSpellSkill and then pass in a Spell that I would create elsewhere. However, how would I limit it to just this job and not others that are similar to it. For example, a Necromancer and Fire Mage shouldn't have the same CastSpellSkill or should they? – Dtb49 Mar 7 '18 at 16:10
• @Dtb49 Yes, that's about it. The architecture I described allows you to make the same skill available to multiple jobs. But it does not force you to do this if you don't want to. For example, FireMage might have the CastSpellSkill(fireBolt) and Necromancer CastSpellSkill(deathRay) bot both get the same CastSpellSkill(magicMissile). – Philipp Mar 7 '18 at 16:11
• Digging a little bit deeper, going back to the CastSpellSkill example, would it be possible to basically take in the different types of Spells to cast in a List? For example, CastSpellSkill(List<SpellTypes> SpellsAbleToPerform). Or would it be better to handle the different types of spells a user can cast in a different way? – Dtb49 Mar 7 '18 at 16:27
• @Dtb49 Both options would be possible. There is no "best" option, just the option which fits best into your overall software architecture. But one thing you might need to think about is what would be implied by having multiple CastSpellSkills with different (and potentially overlapping) spell lists. – Philipp Mar 7 '18 at 16:46
• Of course, you're right. And I will definitely have to think more on it. But, this at least gave me a good jumping off point. Perhaps, I can think of a Spell more or less like an item instead of a Skill. – Dtb49 Mar 7 '18 at 16:53