koobas.hobune.stream
Spell system using oop and inheritance
An asset I purchased in Unity store uses scriptable objects (created for individual spells) to implement skills. For my application, using scriptable objects is not desired because all of the ability would require a unique scriptable object to derive from, so I just decided to use classes instead.
But my problem is, how would I keep track of/use them?
One solution would be to use a switch system to retrieve them for characters:
List<Skill> skillList = new List<Skill>();
// List<int> skillIndex contains the index for spells
for (int i = 0; i < skillIndex.count; i++){
switch(skillIndex[i]){
case 1 : skillList.Add(new AwesomeFireball());
break;
//...
//... over a hundred of them
}
}
Which I think is inefficient and I'm sure there is a better way.
Is it possible to add them to a dictionary or a list in the derived Spell classes? i.e.
public class AwesomeFireball : Spell{
public AwesomeFireball() //constructor
{ AddDictionary(this); }
// ...
}
where the spell class contains
public abstract class Spell{
//...
public static Dictionary<string, Spell> dictionary;
protected static void AddDictionary(Spell spell)
{
dictionary.Add(spell.name, spell);
}
}
And call them using the dictionary (which I doubt it because the derived spells are never instantiated to begin with)?
Well, if you just want to get one instance for every Spell derived class you can use reflection to create them. Of course it has some limitations. All non-abstract classes that are derived from Spell would get instantiated. So keep that in mind. Also all those spell classes would require to have a default constructor (if there's no explicit constructor at all, there will be an implicit default one).
The basic idea is:
using System.AppDomain.CurrentDomain.GetAssemblies() to get a list of all loaded assemblies which will include your script assemblies where all your classes got compiled to.
Now you can use GetTypes() on each assembly to be able to iterate through all types defined in all those assemblies. Of course you could do some filtering here already to exclude certain assemblies like UnityEngine.dll, mscorlib.dll, ... but it's not necessary. Since we do this only once at the start the runtime doesn't really matter.
You want to use typeof(Spell).IsAssignableFrom(type) to check if a type is actually derived from "Spell". Furthermore you want to check the IsAbstract property to only pick types which are not abstract.
Finally you can use the CreateInstance method of the Activator class to create an instance of that class. Just cast the resulting reference to "Spell" and add it to your list.
This will create an instance of all spell derived classes and gather them in a list. If you need further filtering you may want to implement some kind of tag / category / type / level / ... inside each spell which you would use to filter your spells.
Of course instead of directly creating instances of all spells you can put the System.Type references in a list for later instantiation.
@Bunny83 Thank you! I was able to end up with a dictionary that contains all of the spells. On a side note, are there potential disadvantages or dangers with taking this approach? I feel like having to go through the assembly to retrieve the spells feels a bit gimmicky.
@Bunny83 listed some concerns already.
An additional risk you run is that your system is coupled to each class being one spell and each spell being one class. That's really not a very important concern if you're only coupled that way in one place but, if you let that idea infiltrate your code base, you could be in for some real difficulty should you want to start refactoring to allow graphs of objects that work together to represent a single spell.
Your hands wouldn't be completely tied but things would be a little more difficult.
So encapsulate it or, better yet, encapsulate everything you can. You're unlikely to regret it.
Reflection is VERY costly in terms of performance and you certainly don't need it to keep track of spells in the game.
Create an abstract class called Spell. - Abstract because it's too generic. Then create variations of spells, for example if you have water spells create WaterSpells class that inherits from Spell class, then FireSpells etc. Then you create classes for actual spells like MagmaSpell or FireBallSpell and inherit from FireSpells etc.
To keep track of all of them, regardless of type, you create a list or dictionary depending on your need on the base spell class, so List and then even if you create a new spell of type FireBallSpell, you can add it to the list.
This is inheritance, but you can also use composition and in some cases designs that use composition are more modular and extendable. Composition uses interfaces to create contracts that each class needs, however using this you won't get code inheritance, so composition is good if you have a lot of implementation that needs to behave in different ways.
