Do I need to worry about instantiating Scriptable Objects/memory in general for 2D games?

I'm new to unity, and I want to instantiate scriptable objects for my item system. This is because many items have variables that are changed in game, such as their current plot-related state or durability, and I don't want to cause permanent changes to the base object.
I have read that instantiating scriptable objects is quite memory intensive though, and seen warnings against it, but I'm curious if that would even be an issue in the case of a turn-based 2D game? The game is an rpg that is all text or click based, and there is no real-time action going on, with maybe 2 classes even having an update function, so I'm doubting optimization in any way will be a long term issue. I do plan to have 100 levels eventually, only the room the player is currently in ever gets rendered, so I'm not sure if that's something that will eat up resources or not.
Any advice from people with more experience with 2d games would be appreciated.

(I hope I posted this in the right forum)

 

You probably don't want to use scriptable object for your instances. Scriptable objects are more for the base properties, not the particular instance's properties.

So for instance, if you have item with say a durability value, you would create the item as a normal object, use the scriptable object to set the item's initial value and that's it. The scriptable object is only referenced if you need to look at base values again.

For instance I have an inventory system too, and it has an itemstack. This item stack references the scriptable object of the item type, and the size of the stack, and it's location in the world. So I never instantiate the scriptable object. I just create new itemstacks that reference the existing scriptable object.

Now, to note, you can certainly instantiate them, and for a while I did when I was first learning how to use the things. Realized after a while that it was a very poor use of the structure so scrapped it, but I didn't notice any huge memory usages, but then again that was a very early version so if you planned lots of items that could become quite the issue.

 

Thanks for your response, Derek. This is basically what I was doing for my rooms, but I set them up beforehand in the editor because they contain items. So could I have Public Class Item to construct an item from the Scriptable Object? As long as I can use the scriptable object to include subclassed with different overrides for my UseItem() function I should be fine. None of these items have any physical representation in the game aside from a sprite when the inventory menu is open, so I dont think I need to make actual game objects for each of them.

 

Even a sprite means you have to have something that says 'item X = sprite Y' so you need some kind of unchanging reference for such. Now, you could just make it a numeric reference, but that means every time you're deep in the code you have to remember the numeric reference. Probably easier to just go with a slim scriptable object that creates that link for you. There may end up with a lot of them, but ultimately you'll need to do it anyway.

So basically, your scriptable object shouldn't be changing, but you'll probably end up wanting them even if they are just a glorified label for a sprite, although sounds like you will also have some behavior tied to it as well so that's even more reason to have them. However, they should be static, so not changing any of their internal values. If you need an internal value to change (like it's location, durability, etc), then you create another wrapper class that can hold those values, but said wrapper class will also reference the scriptable object so you can still get at all its values as well. You don't need the wrapper class, however, if there is no dynamic values within (say instead of storing the item's location on the item, the object storing the item is the one to store such, and then you wouldn't need the wrapper, at least for that).

 

What I meant would I be able to have an Item Scriptable Object (ItemSO), then create an Item subclass Healing Potion (HealingPotionSO), and have an Item class (Item) that gets constructed from those objects during the game. The SOs would hold the static variables + the sprite, while the class has changing variables like durability. So if the player buys a healing potion, I can do Player.Inventory.Add(HealingPotionSO). No Game Objects in the scene are used as items.

 

Yep, that should work fine.