Scriptable Objects vs Singletons et al

Hi,

I've watched all the videos on Scriptables, poured through project examples, and I'm yet to see the benefit of Scriptables for a project. I currently use google spreadsheets as a source of data (e.g. for localization, quests etc) and import that into unity, and love controlling numbers from that.

So can someone enlighten me or sell me on why to use scriptables and how this will benefit my project? Just seems like little bits and pieces all over the place in the folders!

I started looking into it as I'm trying to design a quest system at the moment, but not seeing the benefits (nor can I figure out how to attach a scriptable if to a spawned prefab if I were to go that way).

Thanks for any advice.

 

Rewatch the "overthrowing the monobehaviour tyranny" one, it covers the main usages/advantages and has examples of how to use SO with monobehaviours

 

You dont have to use it, if you dont want to. Dont force yourself to do anything, just do what is right for you and your project.

At the end you can evaluate, see which problems you run into, and maybe some can be solved with ScriptableObjects.

 

They are pretty neat data containers with a built in workflow for creating seriallized asset instances. You can do the same with prefabs but not a built in workflow for asset creation plus you are forced to have a gameobject attach to them even if they don't need to.

Just like prefabs if you place them in the Resource folder you can instance them from code using Resources.Load or just like prefabs you can reference them onto seriallized members on both monobehavs and other scriptable object instances.

 

Yeah, this is true. One of the hardest things I've been facing since I'm now ready to look at (and mostly understand) more advanced coding and architecture is the differing opinions on best practices. It sure does get confusing sometimes.

I watched the "overthrowing the monobehaviour tyranny" video, and whilst I can see the benefits, I'm not 100% sure if I'm still a fan of them, purely because the spreadsheet system I have in place (where the sheet is imported and the code populates and sets everything up from this sheet automatically without anyone having to touch anything in the game) seems a lot more reliable and easier. A designer only has to change values in the spreadsheet to change game play and that's it. I still see issues with error occurring using the scriptable objects method.

Anyway, I'll keep pushing through with them and may look at using them for my next project rather than trying to integrate with the current one.

 

I mean really... the only difference between ScriptableObject and your 'spreadsheet' is that with the ScriptableObject Unity takes care of the deserializing of your data (converting text/binary data into usable datatypes in code), where as with the 'spreadsheet' you have the job of doing that.

As for the errors occurring. Well the Unity developers take on the task of dealing with errors in their code when deserializing the data. Where as in the spreadsheet you take on the task of handling the bugs.

I don't know how ScriptableObject is any less reliable, or more error prone, in this regard.

Honestly I'd say it's probably less so since the data is serialized via the engine and validated in that process. You can't insert faulty data with out going out of your way to open the *.asset file in a text editor and manually messing with the yaml. Where as in the spreadsheet if the designer goes and inserts a "Q" where numeric data is expected, you can have errors potentially unless you validate for this 'at runtime'.

There's also the fact that your scripts now reference the spreadsheet. This means each script has to write code that deals with the deserializing of the spreadsheet. You'll probably have helper functions... but each and every script still has to do this. Where as the ScriptableObject you just drag it onto your script in the inspector, unity deserializes it as necessary, and it's all prepared and ready to be used as regular C# data types at runtime. Your script doesn't have to do anything special.

This also means you're going to be repeatedly deserializing the same information for every script that references your spreadsheet. Where as Unity tracks your assets and will deserialize it the first time and you re-reference the same asset over and over (unless you explicitly instantiate a copy).

Also, what stops someone from dragging the run spreadsheet onto the script? All spreadsheets are just TextAssets, so what if they drop the "Enemy" spreadsheet somewhere an "Inventory" spreadsheet is needed.

I mean... form the sounds of it, you use this 'spreadsheet' to get all the benefits that a ScriptableObject gives you. You just don't like the shift in workflow. Which fine... you don't like the shift in workflow. But clearly you understand the benefits of it since you have a similar data container to get effectively the same behaviour. Difference is you may be ignoring these under the hood issues (like the need to repeatedly deserialize).

Though... you also bring up 'Singleton' and I have no idea where this is fitting into anything. Are you suggesting you have a Singleton script that references your spreadsheet? So then this singleton deserializes the data, and all scripts that must access it access the singleton? Because if so... well then you're missing one of the best options for a ScriptableObject, it's not a forced singleton!

 

Hm, ok thanks this is good food for thought. The way I use my spreadsheets at the moment is that on startup, the info from the spreadsheet is 'duplicated' into a list of that class of the spreadsheet (e.g. Quest spreadsheet = Quest Class list) and from there on in all game code references the classes in that list only (not the spreadsheet itself). And yes, I do have data validation in the spreadsheet so that incorrect numbers or names can't be entered by anyway as a failsafe. But I'll take on board everything you've mentioned here. Every game I make, my code is improving and this area is the next step to that - architecture - and rethinking the way I construct everything, so I appreciate this feedback.

 

OK.

So yeah, the benefit of ScriptableObject is that Unity converts the data into a class for you. It does all the validation for you. And all that stuff.

All you need to do is write the 'Quest' class with the appropriate fields and Unity takes care of all the rest for you.

There's your benefit.