Feedback ScriptableObjects with database

Hi together,

I wanna create items for my game and save them, if they are picked up, but i´m not sure on which way. My current idea is, to create the items as ScriptableObjects. If an item is picked up and in the inventory, i will save the id (with slotNo and so on) in a database (i already implemented and using a sqlite db).

My main question is, if it make sense/is ok to mix SOs and db and what is the best/better way for the loading. Does it make sense to set all info of the item in the SO (that i have it in the project folder) and just save the id in the db and if the game will be loaded/started, the SO will be found based on the id and a gameobject will be created from the SO afterwards or would it be better to store the whole item in a item table in the db (becaue i already use a db) and create a gameobject after loading based on the data from the db?

I´m not sure if the question even make sense, please let me know .


Kind regards,
Sphinks

 

If i was you i would save it in an ID and make an simple encryption or do it in an json file. Because if they know the game save data people can just cheat. an json file will block that or you need good knowledge to crack it.

 

Thanks for the hint!

But the other parts are ok? Creating SOs for the items with all info and just save the Id and on load searching for equal SO especially for loading in the inventory ? or would it be better to save all/more info that are needed for the inventory in the db/json (like image), cause info like amount has to be saved anyway ?! or shouldn´t i use SOs and save whole item info in the db/json and create the gameobjects out of them (to not mix it up)?

 

If i was you i would assign and id then an dash then the amount and then make it incrypted like make an script that keeps track of it

 

I don't see how a json file could be more "secure" than scriptableobjects regarding cheaters

 

SO database works fine. Vault Inventory uses SOs, it is index and reference based so you don't need to do string lookups unless you just really feel like being slow.

I think most people are accustomed to SQL databases and other more complex solutions that they don't actually need and resist SOs because the approach is less common. It's a pretty straightforward and viable solution for static data. If you need dynamic data, you might benefit from something else but that comes with complexity.

Links in sig.