Is your feature request related to a problem? Please describe.
There are many GameObject/MonoBehaviour oriented callbacks that would be useful for interacting with an Entity. This includes callbacks for collision (OnCollisionEnter/2D for example, the IPointer interface methods, triggers, etc...). As of right now, the best way to utilize these would be to create one or more MonoBehaviour derived classes with an EntityLink component (with entity linked) to gain access to the entity for the relevant logic. If limited to one or more components this seems fine, but if there is a lot of complex logic in a single callback class it could become a bit unwieldy and if split up into multiple Monobehavior derived classes there is more overhead for traditional Unity components.
Describe the solution you'd like
Ideally, an Entity could have one or more abstract, mechanics-focused systems local to itself that would all be executed off of a single Monobehaviour component. Due to Unity's GameObject hierarchy and how certain callbacks like collisions and triggers message up the hierarchy, the MonoBehavior component executing these abstract systems should be separate from EntityLink and placeable by a developer so they can customize how their prefab/GameObject is setup.
This would not include FixedUpdate, Update and LateUpdate as those are first-class citizens of Systems already.
Implementation Tasks
[ ] Identify all desired Unity callbacks and define interfaces for them as EntitasRedux abstract systems. These should remain stateless and only have knowledge of the relevant context and entities.
[ ] Design and implement code-generation process for associating Unity callback systems with zero or more contexts and generating components per Unity callback.
[ ] Design and implement editor workflows for using new Unity callback components, particularly how to setup both scene objects/prefabs.
Is your feature request related to a problem? Please describe.
There are many GameObject/MonoBehaviour oriented callbacks that would be useful for interacting with an Entity. This includes callbacks for collision (OnCollisionEnter/2D for example, the IPointer interface methods, triggers, etc...). As of right now, the best way to utilize these would be to create one or more MonoBehaviour derived classes with an EntityLink component (with entity linked) to gain access to the entity for the relevant logic. If limited to one or more components this seems fine, but if there is a lot of complex logic in a single callback class it could become a bit unwieldy and if split up into multiple Monobehavior derived classes there is more overhead for traditional Unity components.
Describe the solution you'd like Ideally, an Entity could have one or more abstract, mechanics-focused systems local to itself that would all be executed off of a single Monobehaviour component. Due to Unity's GameObject hierarchy and how certain callbacks like collisions and triggers message up the hierarchy, the MonoBehavior component executing these abstract systems should be separate from EntityLink and placeable by a developer so they can customize how their prefab/GameObject is setup.
This would not include
FixedUpdate,UpdateandLateUpdateas those are first-class citizens of Systems already.Implementation Tasks