Hi,
Though I have never used Unity I feel that the ScriptableObject is quite valuable. Being able to design a data object and save it with various values so scripts can share instances can really improve design time support in editor.
cheers,
dfkeenan
I support this idea
for me is a long no-go for xenko.
game data asset is crucial
Just wanted to show support for this feature. I think a scriptable data asset would be a great addition to the engine. At the moment it is sort of possible in a hacky kind of way by using a prefab with an empty entity and single script, but I think a dedicated asset would be excellent. Many games need to store read only data that doesn't need to be in an external file for things like item configurations, level data etc. It makes sense to use the powerful editor and serialization that is already available.
Here's how I imagine it could be added:
1: Create a new base class 'DataScript' or similar that users would inherit from along with adding all the asset serializers and processors etc.
2: Add a way to create an asset from these scripts. 'Add Asset/Scripts/Data Script'? or something like that or maybe there is a better way.
3: Allow the content system to return instances of these scripts from the load methods. For example:
'MyDataScript a = Content.Load
4: Enjoy better data support for your games.
I'm no expert, but those are my thoughts on the idea and think it would be a useful addition for many users.
I'm of the opinion the c# environment is powerful enough that scriptableobject isn't really needed. Yes, what you end up doing in Xenko is creating an entity with priority -1, and add a script to it. The script will be a class with a static reference to itself (Singleton), which holds whatever game data you need. That is how I'm currently handling it. I don't think we need a special entity to represent these easy steps.
Yes, that is fair enough. But what if the data should be accessible in multiple scenes? Then you would either have to load the data scene first and keep it alive, or clone the data which comes with its own issues, namley keeping the data in sync between scenes. This is why I use a prefab to store data but it just seems clumbsy and hacky. I come from a Unity background and when they added a scriptable object asset i didn't really see the point either. However, once you use it and see the flexibility and endless number of uses, it really does become a great feature to have.
Just for my understanding, the main feature is that you can edit the values in the editor, right? Otherwise, there are many ways to achieve that with common programming patterns, like singleton, services, and so on...
Yes that is one of the main benefits, but also the fact that they are not coupled to a scene instance or entity in any way. It's a bit like reading in a file and deserializing it as a class instance, except that you get all the editor and serialization features of xenko instead of having to do that manually.
As far as I understand a similar functionality can be achieved by creating a custom Configuration and adding it to the GameSettings asset. But if we wanted to get a bit closer to the ScriptableObject we need to be able to create potentially many instances of the asset in the editor (same type but different contents).
The asset management system already does reference counting for Content.Load<>, so it would have a singleton behaviour.
A good next question is: should the data in the asset be mutable? If so, it might be necessary to create a new game system that would manage these objects, otherwise when the reference count goes to 0 and later the asset gets reloaded it would lose the modified state.
An easy way to add custom asset types might be enough. That's the main thing I am missing about scriptable objects. Raw assets can be used for this at the moment but it lacks the advantage of type safety that a proper solution would yield.
You can already create custom data assets, quite easily. I've prepared a small demo project:
https://github.com/manio143/StrideCustomAsset
The only downside right now is that you have to reference design time assemblies in your game project.
Oh nice 馃憤