You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 like A 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 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 as ScriptableObjects, but not all.
Additional context Add 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.
My changes generate no new warnings.
The text was updated successfully, but these errors were encountered:
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 usingScriptableObject
systems that differ from POCO systems:Advantages
injected
to a given system through serialized fields in the Inspector.Disadvantages
ScriptableObject
s 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 aScriptableObject
is referencedScriptableObject
systems, 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.
ScriptableObjects
using an EntitasRedux-provided base type.IContexts
interface.Contexts
instance to use, but be able to pass aContexts
in 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
ScriptableObject
s 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:
The text was updated successfully, but these errors were encountered: