I edited my above posts after your reply to describe why my system is set up as it is and why i can’t rely on SO’s as you made your posts.
Apologies for the confusion
That said, enums ARE janky, and there isn’t a simple solution.
And I do research from time to time (admittedly not as much as I should), in the above post from Mike W on twitter he discusses why SO’s aren’t a perfect solution either.
Edit: To be honest it’s kind of ridiculous to me how much negging happens in this community. After all these posts I’m still convinced there isn’t a reliable means of data storage in this engine and that’s a gross oversight.
Too often in gamedevs people act condescending or like everyone else is just a total moron and that their issues can be totally discarded because they’re not on the same level with C# or whatever.
Isn’t the entire point of a game engine to handle these problems? Isn’t this why Unity exists to make gamedev easier?
This seems like a BIG PROBLEM. ANd it’s only the tip of the iceberg, I lose data in a myriad of ways when I find a better naming convention and other situations.
I mean it doesn’t work currently because your project architecture looks like a mess. You’ve hard coded your bonuses (bad) and are trying to directly reference these hard coded bonuses, which is as you’re experiencing proving to be rather difficult.
Whereas were they scriptable objects, you can simply introduce a means to compose what type a bonus is (meaning a bonus can have more than one type); perhaps with more scriptable objects. Then anything that wants to look for a particular type of bonus can reference these ‘type objects’ and simply check if a bonus is of a specific type.
And if you need per-instance data (due to data changes persisting between play mode sessions for assets), then these scriptable objects can be factories for plain C# bonus instances instead.
Unity can’t help when you write bad code and follow bad practices. This issue here isn’t Unity.
Basically you’ve coded yourself into a corner with numerous anti-patterns and are trying to hack your way out of this. This is why this particular problem seems so difficult: it’s a dead end.
I’m actually really happy with my system, it’s just this enum thing throwing it off. I solved the problem with the above janky solutions, and even in this state i’m happy with how it works and how easy it is for me to create and reference bonus values because it populates a dynamic list.
If there were a more reliable means of getting an index from a list of strings that I could add to and reorder over time, this wouldn’t be an issue.
One man’s “Anti pattern” is another man’s innovation.
If everyone always just did an overly complex and stringent method of accomplishing tasks we would never have any innovation in this industry.
I stand by my initial assertion that accessing and storing data has a long way to go in Unity (and apparently C# in general in regards to reserialization). I’m not even 100% sure about all this, i’m just trying to make a darn game without having my data constantly erased and garbled.
And the majority of us don’t have these issues as we learnt that enums are bad in year one of learning Unity and moved on from using them long ago.
It’s not even 'complex and stringent". It’s just using fundamental aspects of both Unity (scriptable objects) and C# (object oriented). It’s beginner stuff.
Anyway, up to you whether you listen to the people who’ve solved these issues already.
I’ve tried to explain to you that I can’t rely on SO’s as it’s a dynamic list that’s generated and I’m already using a SO hybrid solution.
Forget it.
I learned a bit from this thread, wasn’t a waste of time, but also didn’t find any answers other than, “Yeah it’s broken, do what us wise coders do and deal with it” and that just sounds counter to what Unity is all about IMO.
Now I understand your problem better, and I double down on the good’ol non-serialized Dictionary, and I’ll risk hijacking your thread to derail it into an anti-ScriptableObject war… because:
Imagine you have 1000 bonuses, how are you going to maintain all those objects in the editor? Imagine you rename a property and how many fields will be reset.
A non-serialized Dictionary is initialized in code. Code isn’t reset when you rename stuff, and you can actually refactor names. You can easily inspect the whole dictionary in code. Code is code. ScriptableObjects are visual.
Exactly, these enums reordering is only a facet of an overarching problem, which is data existing in their invisible cloud that can easily be zapped from existance.
Excel does a fantastic job of giving data a tangible bit of real estate as just an example of an alternative data housing system where unless you click a cell and delete that data it’s going to persist, even if you rename the colums to the side of them.
And if you do make a change that loses data, this is where you use your version control software to revert those changes and do it properly the next time.
Also note the data does not actually get changed until those assets are reserialised. If you change the name of a field, there is still data under the old field name serialised into all those assets. You can most of the time change that name back and your data will still be there, given you haven’t changed and saved any of those assets.
Unity’s handling of data follows very consistent rules, and so long as you understand them, you should seldom if ever lose any data. I certainly haven’t for years now.
Well they have Odin, so they can make an OdinMenuEditorWindow which would make navigating and editing them enmass pretty trivial.
I mean, I like ScriptableObjects because these are more compact that GameObjects with components, and visual editing is more appealing. But I’d recommend them in small quantities, like settings. I’ve been recently using an asset heavy on SOs and maintaining 40 of those got me tired of clicking.
It might have happened to me in an older version, but an Editor crash and restart did reset the previous values of a renamed property, so there could be accidents.
Well after going off the rocker in this thread, I had this nagging feeling that maybe I did set this all up in a stupid way, and I couldn’t quite remember why I set up my bonuses in such a weird way years back when I was first starting code, so I went ahead and bit the bullet and started revamping it, and figured if for whatever reason I need to revert it I could undo the changes.
Took a bit but I revamped my systems and I was able to ditch all the BS list nonsense and now it’s way more manageable. I’m using the names of the SO’s themselves to call the enum index so i’ll never have to worry about them ever getting garbled again.
I think i’ve finally conquered the Enum menace. And it wasn’t some great source of knowledge that came from this thread. Sometimes we just need to be told we’re a dumb*ss.
TLDR: You were right and I was just being stubborn, sunk cost and all that
That said, Enums still suck and there could be a better solution.
