koobas.hobune.stream
Why would you use a scriptable object versus an empty gameobject?
It seems like these two objects fulfill a similar role in that you can use them for scripts/data that don't require user input or anything physical interaction with the object itself.
Does the difference boil down to that you 'save' resources by choosing scriptable object if your scripts/data doesn't need all of the properties of a GameObject?
I think the economical usage of the resources on a scriptable object vs an empty game object is highly negligible. If you use a GameObject with a script on top of it, then your hierarchy might look a bit organized.
I'm not sure if this is a good answer to your question, but I came across this issue in a recent project. I was attempting to create large tile grids (at least 128x128), and when the those tiles were components attached to game objects I was getting out of memory and heap exceptions when creating grids even as large as 150 x 150. I have since switched to having my tile class inherit from Scriptable object, and can comfortably get grid sizes of 256 x 256, even as high as 1536 x 1536 before I get any crashes or out of memory/heap exceptions. To put this in perspective, I was seeing crashes when creating 16,384 game objects (128 x 128), but I didn't see the same crashes until attempting to create 2,359,296 Scriptable Objects (1536x1536).
To me it seems that the best reason to use Scriptable Object vs an empty game object is when you need to create large quantities of that object, or creating a whole new game object would be too cumbersome. In my case, I've had to write a few extra tools to allow the tile map to be edited by hand, so if I were able to use a game object my whole system would be much simpler. It is also important to point out that ScriptableObjects get serialized by unity, and can be saved as asset files, which allows for easy loading by other objects.
Roughly speaking how did you implement this? I have a tile class which stores information about its neighbouring tiles and whether it is passable or not. Like yourself this is attached to a game object which also has a sprite renderer. There is a grid manager class which instantiates the tile game object and stores the corresponding tile class in a dictionary.
From what I understand of your answer, you switched your tile class (which might not be equivalent to $$anonymous$$e) to inherit from ScriptableObject. I don't quite understand how this gets around having to instantiate a game object.
There are a few different tutorials for scriptable object but they mostly involve tools to edit stuff at runtime which is irrelevant as I'm working with procedural generation. I just want to instantiate a tile object which can store information and be visually represented and your implementation sounds pretty close to that.
