Scriptable objects seem to be a great asset for saving data?

Unity Courses Ask
,
#1

Please let me know what you think…

I am going to try to learn a lot more about scriptable objects because that seems to be a very solid approach…

By definition “a data container that you can use to save large amounts of data, independent of class instances”

I wonder if making a scriptable Object (SO) would be a good idea for saving data in the scene?

Here again I could make use of that basic list of common things for RPG and quest… in terms of what data should be tracked.

Am I wrong in thinking that a SO could be used for saving data?
What I am thinking is dragging and dropping my savable entities into 1 SO.

Thanks for any thoughts

PS: One more question, Why wouldn’t we put the default weapon un-Armed on our Character Prefab?
After all it has a fighter script on it… and can be over written in the Hierarchy right?

#2

I’ll start with the PS:
Yes, as long as your characters are all humanoid, this will work fine. Just remember if you eventually add the Rodent of Unusual Size to the mix, you’ll definitely need to replace that animator.

Now to the second:
It is actually very possible to make a saving system entirely using ScriptableObjects. In fact, I attempted just that once before the RPG Course was written. One of the biggest obstacles I faced was the same obstacle I faced when trying to write a robust saving system for Unreal, it’s harder to make a dynamic system with the ScriptableObjects. Harder, but not impossible. One of the biggest challenges is that Dictionaries don’t automatically serialize in a SO. You can convert those to a List<KeyValuePair> in the Serialization routines, though.
Personally, once I hit the saving system we’re using now, I never really looked back. It is much more scaleable than a ScriptableObject approach, and will be even more so once my Conversion from BinaryFormatter to JSon/BSon tutorial is completed.

#3
#4

Update on this subject:

I remember now why SOs do NOT make a great saving system (It’s been so long since I tried now, I forgot all about it). Scriptable Objects behave differently in the Editor than they do in the built game…

In the Editor

Any change made to a Scriptable Object during game play is serialized back to the Scriptable Object, and gives the illusion that Scriptable Objects maintain their state between sessions. As long as you’re within the Editor, they do, in fact, maintain their state between sessions…

In the Built Game

Scriptable Objects are serialized by the compiler and included in the packaged build, where their state is read when the game begins. They are not reserialized when changes are made, so while state persists between scenes, once the game ends, the state is reset to where it was when the game was packaged.

While this may make them suitable for saving between scene changes, this makes them unsuitable for saving between sessions.

2 Likes
#5

Thanks for the feed back…
The PS first, I thought when I start using different characters (monsters or animals or aliens(without human form)) I would be making a Prefab for each type Keeping each in a class of there own.

The second:
I agree that the saving system Sam presented is very scalable and easy to adapt to. I am trying to wrap my head around centralizing that data. I am getting a better feel for (what data to I want to track?) during RPG/Quest. At the same time I have handled Massive amounts of data and I feel having it centralized and easier to access is possible. For example for myself I am trying to limit the number of ‘Resources’ folders I have. I understand that folder is a KeyWord for unity… right? I also understand you are not allowed to have folders under it; so what I am doing right now is thinking of a way to have all my scriptable objects in one folder(currently foreach dataType all over the file structure).

(I plan on using Hungraytion naming Convention for my SO’s)
like for weapons:
equipWeapon_Bow1
…equipWeapon_Bow7
equipWEapon_FireBall1
…equipWEapon_FireBall7
core_Progression
core…DefaultEnemyDrops
etc…
using Hungarytion notation I feel better about knowing All my data is in one folder.

What do you think?

Thanks

PS: I wonder if you looked at the code I wrote in that progression Excel workbook.
Alt + F11 should open the code window

Thanks again for the help

#6

Actually, you CAN have subfolders under Resources, but loading them can be a bit trickier…

For example, I have a Resources folder for all of my inventory items, and they contain folders for each equip location…

Loading them by name becomes a bit trickier then, but after the Inventory course, we generally won’t be loading resources by name, but by their ItemId (using InventoryItem.GetFromID). With this, we’re using Resources.LoadAll<InventoryItem>("") under the hood, which eliminates the need to know the exact subfolder the item resides in.

I tend to use prefixes for the type of inventory item as well, though I’m a bit tighter since I don’t want the meaningful data to be lost in the inspector when it’s not wide enough…
Literally
H_LeatherHelm
H_SimpleCap
H_PlatedHelm
G_LeatherGloves
G_SteelGreaves
F_Sabotons
F_WornLeatherShoes
W_BasicSword
W_SwordOfConvenientPlotDevice
Q_McGuffin

#7
#8

Privacy & Terms