[Feature Request] Inheriting From ScriptBehaviourManager

I don't think this has been mentioned yet, I apologize if it has.

It would be nice to be able to inherit from ScriptBehaviourManager. This is currently not possible due to the internal abstract OnUpdate() method.

My use case is that I have a couple of managers (i.e. Systems that do nothing in OnUpdate) that simply hold application state (much like Entity Manager), and it is very convenient to be able to inject these managers in to other systems or reference them from World.GetExistingManager.

As a workaround, I have my own abstract class inheriting from ComponentSystem that sets Enabled to false and does nothing in the OnUpdate method. This works perfectly for now, but being able to inherit straight from ScriptBehaviourManager would be ideal.

 

I have a similar pattern for generating stuff by tagging entities, which combined with subtractive component and ISystemStateComponentData should be enough info for you to automatically disable OnUpdate(). Here is a quick and dirty example:

Code (CSharp):

1. public class BoardSystem : ComponentSystem
2. {
3.         public struct Group
4.         {
5.             public int Length;
6.             public EntityArray Entities;
7.             public ComponentDataArray<Board> Board;
8.             public SubtractiveComponent<Generated> Generate;
9.         }
10.         [Inject] private Group m_group;
11.  
12.  
13.         protected override void OnUpdate()
14.         {
15.             Debug.Log("Generating Board");
16.  
17.             //Add Generate  ISystemStateComponentData to signal initialized
18.             EntityManager.AddComponentData(entity, new Generated());
19.         }
20. }

Somewhere in your lifecycle you can create an entity with the necessary data to generate stuff, then the system itself adds a tag to stop itself. This system can then hold/cache some data for other systems. Is this enough for what you need? Using this pattern you can see in the editor that no entities match the filter so the component is automatically disabled. You can then watch for SubtractiveComponent<Board> with ComponentDataArray<Generated> to know when the board component has been removed and teardown/cleanup accordingly.

 

I also think it would be cool to be able to inherit from this class, those managers follow a nice pattern that I think some of my game systems should follow, unless of course there is a reason not to do it, but for now it seems more like an oversight.

 

This is so cool. I've tried collecting entities in a NativeHashmap. That hashmap can be accessed in another system by injecting the system that owned the hashmap. Basically, now I know how to prepare data such that some assumptions can be guaranteed like for example, a tile grid where tiles are ordered in an array.

 

Agreed, I also really like the pattern.

My code is littered with `SomethingManager`s, usually implemented as a weird Singleton or attached to a GameObject that I then `FindObjectOfType<SomethingManager>`.

Being able to replace that with `world.GetExistingManager` would be a relief, and it would allow managers to be tied to worlds instead of actually being singletons. Big win.

Is there an argument against inheriting from `ComponentSystem` and using the `OnUpdate` from there? Is there (a lot of) overhead for an "Entityless" ComponentSystem ?