I still have big concerns about what to choose, scriptable objects or monobehaviours. I know there were already a lot of discussions made in other threads but I didn’t find a proper answer for my development problems.
I found scriptableobjects inconvenient. Every time I want to access data from SO I need to map it to the monobehaviour or other class anyway because I do not want to modify its data.
I decided that every time I will have a script which is associated with a game object I will use monobehaviours. But of course there are some use cases when I have scripts without gameobjects and I struggling a bit how to combine both solutions.
Let me show the example use case.
Prefab structure has a composition like this:
Unit Script (monobehaviour) + game object
- Weapon (monobehaviour) + game object
– SkillAttachedToWeapon (scriptable object)
I see same problems here because if I decide to instantiate a unit prefab I will receive a copy but SkillAttachedToWeapon will be a reference which I can not modify if I do not wan to changed saved data.
I could potentially make scriptable object scripts readonly but I feel it will be very limiting because I would like to change some data in a runtime.
Some time ago when I decided to use only scriptable objects I ended with a lot of boilerplate to copy those classes which makes my code difficult to maintain.
How can I improve my workflow?
If you make your ScirptableObject fields serializable - which they must be in order to show up in the inspector - then you can make a copy of the ScriptableObject with Instantiate. You can then freely modify the copy if you wish.
Your simple gameObject+monobehaviour seems fine for your programming style. SO’s are made for people who factor their data in a more standard way.
Your way I think you make a prefab for each weapon, including clip size and currect # of bullets. If you spawn 20 bam-pistols you’ve got 20 places where it says bam-pistols hold 4 bullets. Not a problem, but seems weird. The other style is to list pistol stats: clip size, damage, model, fire-rate. The script on the prefab has only specific data for a pistol: current bullets, wear&tear … , and a link to the data for that type of gun. That set-up saves some space, but it also makes more sense to many programmers. If you do it that way, your weapon stats could be stored in ScriptableObjects.
True, I alredy used it before but to be honest I always try to avoid approches where forgeting about any extra step will not trigger any proper feedback for you, for eg. I guess you assume that I should call Instantiate for my SO in Awake method of my monobehaviour and replace original instance with new one.
I think it can generate some problems in future when more SO will appear and I can forget to call Instantiate and have no info/validation message. Maybe I’m totally wrong with my understanding of SO but for me it feels a bit like using it not according to the original design.
Sure it make sense. I guess it could be a matter of getting use to it. It just feels a bit non intuitive for me when you load a data and modifications in a run time will be saved. I know that this feature is presented as advantage. Maybe also it promote working with immutable objects. I don’t know, I’m still a bit confused about it 