(solved)Will using subclasses too much cause issues down the line?

I've never made a project as big as the one I'm making now, so what I'm really asking is will using layered sub classes cause any performance issues as the computer has to constantly read through multiple files? I wouldn't imagine it would but the question popped into my head and I wanted to make sure.

example:
for sake of ease for myself, I have the parent class
MeleeWeapon. melee weapon actually does everything, but there are a few strings (representing types) that change based on what weapon it actually is. I do this because I will have several weapon types available, along with passives that say, if you're using a knife/sword/whatever get +1 to damage. And I don't want to have to enter all the information for every weapon I put in the game.

So, In MeleeWeapon I have
int weaponHandsUsed;
string WeaponType;
string WeaponDamageType;

then I make a subclass for what type of weapon it is
public class SwordParentClass : MeleeWeapon
{
void Start ()
{
WeaponType = "Sword";
WeaponDamageType = "Slashing";
}
}

then depending on how many hands it uses (1 or 2)
public class OneHandedSword : SwordParentClass
{
void Start ()
{
WeaponHandsUsed = 1;
}

}

so then instead of applying MeleeWeapon as a component and having to put in those fields, I can just apply OneHandedSword or whatever child subclass and it will "autofill" that information. Once I get these setup I will also begin to add weapon type specific animations as well.

but back to my question, will doing things this way, and over lets say 500 items down the road, cause performance issues? Or am I just paranoid/ignorant over how little impact this will actually have?

 

First, USE CODE TAGS:
https://forum.unity.com/threads/using-code-tags-properly.143875/

Code (csharp):

1.  
2. int weaponHandsUsed;
3. string WeaponType;
4. string WeaponDamageType;
5.  
6. public class SwordParentClass : MeleeWeapon
7. {
8.     void Start ()
9.     {
10.         WeaponType = "Sword";
11.         WeaponDamageType = "Slashing";
12.     }
13. }
14.  
15. public class OneHandedSword : SwordParentClass
16. {
17.     void Start ()
18.     {
19.         WeaponHandsUsed = 1;
20.     }
21.  
22. }
23.  

Note, source files are just that, source files. They are not what are actually used when the game is ran.

The source files get compiled into CIL as one main dll file (for desktop unity games, il2cpp games have an extra step). The CIL is what is ran on the user's computer. The classes in the CIL are then compiled into machine code the first time they're touched.

So no, the computer doesn't have to constantly read through multiple files.

With that said, yes, it makes that compiling the first time have a slight bit of overhead. But it is mostly negligible, and isn't something you need to super concern yourself with.

I will say though... there may be a better design to this. Not because of performance, but because of managing that much code. You suggest 500 classes done in this manner. Having an individual class for each weapon that really only differ by the value of that string field/property is probably not the most ideal way of designing this problem.

 

thankyou for the info and sorry I didnt use code tags.

no no, what I meant to convey was I might have like, 13 different one handed swords, 12 different axes, and so on. Right now I would have 9 weapontype subclasses. which will autofill the type information without me having to tell the game "this item is a sword, it uses two hands. it does slashing damage".

again thankyou for the excellent answer to my original question.

 

Well I mean, technically speaking, you are telling the game. You're doing so in these sub classes.

And my point is that there are far better designs than this.

 

If the weapons only differ in certain values, instead of in any other meaningful way, I wouldn't use separate classes. I'd just set these values by loading them via JSON or csv, or just hard code them with a single switch statement.

Code (csharp):

1.  
2. public class Weapon
3. {
4.  
5. int weaponHandsUsed;
6. string WeaponTypeString;
7. string WeaponDamageType;
8.  
9. public enum WeaponType { OneHandedSword, TwoHandedSword, Dagger, Mace };
10.  
11. WeaponType WType;
12.  
13.  
14. public Weapon (WeaponType typeOfWeapon)
15. {
16.     WType = typeOfWeapon;
17.     switch (typeOfWeapon)
18.     {
19.         case WeaponType.OneHandedSword:
20.             weaponHandsUsed = 1;
21.             WeaponTypeString = "One Handed Sword";
22.             WeaponDamageType = "Slash";
23.             break;
24.         case WeaponType.TwoHandedSword:
25.             weaponHandsUsed = 2;
26.             WeaponTypeString = "Two Handed Sword";
27.             WeaponDamageType = "Slash";
28.             break;
29.         case WeaponType.Dagger:
30.             weaponHandsUsed = 1;
31.             WeaponTypeString = "Dagger";
32.             WeaponDamageType = "Stab";
33.             break;
34.         case WeaponType.Mace:
35.             weaponHandsUsed = 2;
36.             WeaponTypeString = "Mace";
37.             WeaponDamageType = "Blunt Force";
38.             break;
39.     }
40. }
41.  

Note that in your example it doesn't look like you're inheriting from Monobehaviour, so you wouldn't use Start in that case. You'd set up your object in its constructor as above. You can still do something similar in a Monobehaviour though.

 

You might also look into scriptable objects for something like this.

 

ScriptableObject is how I'd probably do it as well.

Something like this:

Code (csharp):

1.  
2. public class Weapon : MonoBehaviour
3. {
4.    
5.     public WeaponSettings Settings;
6.    
7. }
8.  
9. [CreateAssetMenu(fileName = "WeaponSettings", menuName = "WeaponSettings")]
10. public class WeaponSettings : ScriptableObject
11. {
12.    
13.     public WeaponType WeaponType;
14.     public WeaponDamageType DamageType;
15.     public WeaponHandedness Handedness;
16.    
17. }
18.  
19. public enum WeaponType
20. {
21.     Sword,
22.     Dagger,
23.     Club,
24.     etc...
25. }
26.  
27. public enum WeaponDamageType
28. {
29.     Slashing,
30.     Bludgeoning,
31.     etc...
32. }
33.  
34. public enum WeaponHandedness
35. {
36.     SingleHanded,
37.     DualHanded
38. }
39.  

Then you'd create the WeaponSettings as assets, configure each one for each weapon type.

Next you'd create your weapon (as a prefab or what not), attach the Weapon component to it, and then drag the appropriate WeaponSettings onto it.