SO + Poly vs Class Inheritence

[slate marsh]

I'm probably too hyper-focused on performance. I always told myself when I make something I'd optimize it every step along the way, maybe that's a bit overbearing. What you said makes sense, it'll have to be loaded either way.

I think I'll use the SO approach then. Can I attach extra scripts to certain scriptable objects? Just like another component basically? The scriptable object thing is something I've only really read on at this point.

Basically I still have to make the hierarchy anyways and instead of classes like Stone Axe, it would just be that Stone Axe is a scriptable object with things defined in the inspector. Can I attach code to scriptable objects to give certain ones custom functionality even if they inherit "axe" as a type? That's the biggest thing I'm confused about at this point.

[kindred terrace]

The only way to attach would be defining them in code or another SO. You cannot attach components

If it inherits though, you shouldnt need to attach it, since axe would define what it does

[slate marsh]

Ok that's good to know. So if I wanted most axes to behave the same and then the last 2 or 3 tiers to do certain things like break all of a node on initial swing, or make all ores not count against encumberance while it's in the player's inventory, etc... I'm not sure how I'd do that unless I have those methods loaded in the inherited class that the SO uses. I guess it wouldn't really have a performance impact so I could do it that way.

Does this sound like a decent way to handle these things or am I overcomplicating it? Thanks for taking the time to answer my questions.

Basically how I'm thinking I would do it is have the methods in the script functionally and have them 'enabled' or 'disabled' per SO in the inspector.

[sage sluice]

1. It sounds like you are building something experimental. You can't optimize something if you don't know what it is. First do your experiments and figure out what you're making, then optimize it. Optimizing "at every step" will be a massive waste of time and effort.
2. I think you are making the classic mistake of assuming that whatever you define in the inspector should be the only representation of the thing in your game. Consider the SO to be the 'design-time' representation of an item. "What information do I need to define the behavior that an item has?". That can, and almost inevitably will, end up being a different (but related!) set of information from how you want to actually represent those items at runtime. Use the info in the SO to compose together a functional item at runtime which does only the things it needs to do as specified in the SO. This lets each individual item instance be fairly simple, even as the process of defining an item becomes complex.

[kindred terrace]

If they have the same behaviour, you just create multiple assets of that one scriptable object and change what you can in inspector.

You'll have to define the damage per node somewhere