Is your feature request related to a problem? Please describe.A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
There are advantages in Unity to being able to create systems as ScriptableObjects, but there is a lack of parity between POCO objects and systems that cause disadvantages and require workarounds. There are also architectural considerations with using ScriptableObject systems that differ from POCO systems:
Advantages
Dependencies for a system can be easily assigned or injected to a given system through serialized fields in the Inspector.
Systems can easily be configured in the Unity Editor with relation to other systems by capturing them in the relevant list for a given feature. This includes adding, removing, or reordering systems in the collection. This is significant as it gives more ability for non-engineers to modify system behavior directly.
Disadvantages
Systems written as ScriptableObjects don't have a constructor equivalent like a POCO that can be used as a pre-initialization step.
ScriptableObjects require more care in the editor to ensure that any locally initialized fields not intended to be serialized are cleaned up between Editor play sessions, usually by using the `[NonSerialized] attribute.
ScriptableObjects can't be as easily disposed in code as POCO objects can be; depending on how a ScriptableObject is referenced
There is not any native framework support directly for ScriptableObject systems, which results in each developer needing to write their own support for using them.
Describe the solution you'd likeA clear and concise description of what you want to happen.
A developer should be able to write systems as ScriptableObjects using an EntitasRedux-provided base type.
An overridable initialization method should be available that provides a IContexts interface.
A developer should be able to create features in the Unity Editor as a scriptable object and:
Assign a custom name for the feature
Add, Remove, and Reorder systems for that feature.
Assign a default Contexts instance to use, but be able to pass a Contexts in code if desired.
Describe alternatives you've consideredA clear and concise description of any alternative solutions or features you've considered.
One option that might bring POCOs up to parity with ScriptableObjects for being able to manipulate them in the editor would be to provide a base system C# type and use the [SerializeReference] attribute to be able to polymorphic serialize derived system instance types in a list or array. This opens the door to more of the same features, advantages as ScriptableObjects, but not all.
Additional contextAdd any other context or screenshots about the feature request here.
Tasks
[ ] Implementation
[ ] Tests
[ ] Documentation
Checklist:
[ ] My code follows the style guidelines of this project.
[ ] I have performed a self-review of my own code.
[ ] My code is well-commented, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
There are advantages in Unity to being able to create systems as
ScriptableObjects, but there is a lack of parity between POCO objects and systems that cause disadvantages and require workarounds. There are also architectural considerations with usingScriptableObjectsystems that differ from POCO systems:Advantages
injectedto a given system through serialized fields in the Inspector.Disadvantages
ScriptableObjects don't have a constructor equivalent like a POCO that can be used as a pre-initialization step.ScriptableObjectsrequire more care in the editor to ensure that any locally initialized fields not intended to be serialized are cleaned up between Editor play sessions, usually by using the `[NonSerialized] attribute.ScriptableObjectscan't be as easily disposed in code as POCO objects can be; depending on how aScriptableObjectis referencedScriptableObjectsystems, which results in each developer needing to write their own support for using them.Describe the solution you'd like A clear and concise description of what you want to happen.
ScriptableObjectsusing an EntitasRedux-provided base type.IContextsinterface.Contextsinstance to use, but be able to pass aContextsin code if desired.Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
One option that might bring POCOs up to parity with
ScriptableObjects for being able to manipulate them in the editor would be to provide a base system C# type and use the[SerializeReference]attribute to be able to polymorphic serialize derived system instance types in a list or array. This opens the door to more of the same features, advantages asScriptableObjects, but not all.Additional context Add any other context or screenshots about the feature request here.
Tasks
Checklist: