Question about the enum solution for stats

[Fitz0Fury]

@Brian_Trotter this is something i have been struggling with in my own project as a solution, and maybe i was under the wrong assumptions. I thought using enums was a bit suboptimal. i thought i remember seeing/hearing they were more bug prone as you expand your game. My idea had been to have scriptable objects implement an interface then maybe even have the SO hold other Scriptable objects and required methods.

in the case of this game maybe it would be something like…

empty game object acting as a container called player container
the container stores PlayableCharacterSO, implementing iCharacter.
PlayableCharacterSO stores …

1. Character Prefab
2. ClassSO ( which would handle health gained per level)
3. a method managing XP calculation, so instead of a table of levels it might be something that says _XPTNL = 100 *_characterLevel ( that isnt a perfect example just something to get the point across)

Is this viable, or does it introduce more problems than the enum solution? i have not played around with it enough yet to understand the problems it might cause using " nested SOs" like this. Im sure a mistake in there could cause problems where base stats get modified permanently at run time.

im wondering if, for the sake of simplicity, i should use the enum method now…it seems less " professional" but after all im not exactly a pro.

p.s. not expecting you to come up with a flawless solution with the vague stuff above i just gave you, just want to know if my method is viable. if so is it going to be a bigger headache than just using enums, or is it worth it for me to just keep at it, and as i get more proficient, it will be worth it. (my project has a bit more complexity and takes in racial bonuses, elemental typing etc)

[bixarrio]

TL:DR; I have done this in a past project and it can become quite a nightmare

---

I have used SOs for ‘modular’ config in a past project. While it makes it pretty easy to add new content, it can be quite a nightmare when the content starts to grow. But I guess anything will. It’s probably at that point where you want to do the Editor Scripting course or buy Odin Inspector to try and make it easier to manage your stuff.

Just as an example, I had a ‘Spell SO’ that held

• Title
• Sprite
• Description
• School of Magic
• Spell Level
• Spell Cost
• A Spell Strategy
  Everything is standard except the Spell Strategy which was another SO that held
• Target Selector
• Target Affector
• Some more config like ‘can use in melee range’, etc.
  Here, Target Selector and Target Affector are, once again, more SOs. Selector to ‘select’ a target/targets, and Affector to ‘affect’ the target(s)

With all this it is simple to add a spell that can do virtually anything. Except that I need to create new versions of each SO if I don’t have it, for example if I want a spell that affects the first 5 enemies in melee range I have to create a Target Selector that will select 5 enemies in melee range. Now I have it, so in the future I could select 5 enemies in melee range by just reusing the SO. It’s easy to put the 5 in the inspector, but SOs are ‘instances’ of classes, so if I want to rather select 10 enemies in melee range, I still need a new SO asset with the value set to 10. Eventually, you have a lot of SO assets to rummage through. You end up with this monstrosity

This has been filtered to show only the SO assets. I have them in a folder structure that helps organise and find what I need

[Brian_Trotter]

@bixarrio

TL:DR; I have done this in a past project and it can become quite a nightmare

I’ve also attempted this. Created more nightmares than it solved.

[Fitz0Fury]

i actually purchased odin during the charismas asset sale. i have not messed with it yet though. have you tried it? if so…did it help manage in a meaningful way? i feel like a lot of assets i get i just end up looking at for examples of solutions rather than using them out of the box.

thanks for popping in with really awesome and detailed answers on a few of my questions now. its really cool.

[Fitz0Fury]

maybe im going about it the wrong way then. ill keep on through this course series and then play with odin some. if i dont think its manageable ill stick with enums and live with it. I spend a huge amount of time in my real job focused on scalability, i might be carrying that mentality over TOO much. i have seen the shortcomings of not having a scalable solution too many times to not be worried about it. but i guess that could be a bit too much “cart before the horse” in this case.

[bixarrio]

I bought Odin a while back, but I hardly use it. Mostly because I often work with other people that don’t have it and then it becomes a bit iffy, license-wise, so I resort to Naughty Attributes mostly, which is free but not nearly as comprehensive as Odin.

My example was a case where I tried to make everything easily configurable in the inspector and while it is, it can still be quite a nightmare to manage. Just purely replacing enums with scriptable objects is far less of a nightmare. If you just want to replace the enum values with SOs it’s not so bad. It’s when you start attaching data to those SOs where things can get hairy.

[Brian_Trotter]

I picked up Odin sometime last year and experimented with it. First of all, it is very cool, and takes a lot of the heavy lifting out of custom inspectors. There are a few features that aren’t fast and easy to replicate writing inspector code from scratch. There is the seat issue (which makes including it in tutorials a non-starter). I’ve also played with Naughty Attributes, which as @bixarrio said is a bit “Odin Light”.

Myself, I tend to write my own inspectors for everything. Ok, I don’t write property drawers for simple strings and such, but most of my custom classes, unless very basic, tend to get an inspector, which often provides feedback like giving you formula values at different levels, etc. My inspectors tend to clash with both Odin and Naughty, so they both sit in the “interesting assets I possess” pile.

One script I have used before, and I can’t remember where I picked it up from, CREATES an Enum out of the lines in a ScriptableObject… This means that the designer can add an Enum without having to go into the code and create a new enum. If I can dig up the script, I’ll drop it in herel

[Fitz0Fury]

id be interested in trying out anything that helps Brian , but if you don’t find it or don’t have time its no biggy. Ill figure out Odin after this just too not waste the product completely. I had thought about doing the course on making my own editor tools, and i probably should/will. but so far anything like that has just bored me to death, so i have been kind of dodging it.

[Brian_Trotter]

Don’t get me wrong, I’m NOT saying don’t use Odin. Its’ a good tool!