State in system instead of component

[JamesMcMahon]

I noticed you are keeping your object pool as state in your system instance,
https://github.com/sschmid/Entitas-Shmup/blob/master/Assets/Sources/Features/Input/ProcessShootInputSystem.cs#L12

readonly ObjectPool<GameObject> _bulletsObjectPool;
// snipped code

public ProcessShootInputSystem(Pool corePool, Pool bulletsPool) {
    // more snipped code
    _bulletsObjectPool = new ObjectPool<GameObject>(() => Object.Instantiate(Resources.Load<GameObject>(Res.Bullet)));
}

I've been going back and forth between how much state I store in the systems themselves vs components. Do you think this would be better served as a component?

[sschmid]

I know what you mean, it can definitely be on a component, too. Maybe I change it. Shmup is still a very early version and work in progress. But you're right, you shouldn't really have any state in systems

[JamesMcMahon]

Yeah I go back and forth. Sometimes if state is not shared between any other systems it may be simpler to just store it in the system itself but it feels like the "Right Way" is to keep your state in components. I also cache state occasionally in my systems for performance reasons, for example, keep tracking of a flag OnEntityAdd / Remove instead of querying a pool every frame.

I haven't found a hard fast rule yet, but I am still figuring out best practices for ECS design and Entitas.

[sschmid]

Heads up: the object pool should definitely be on a component ;)
This rule helped me avoid head aches:
Not only data has to be in components, but also dependencies. By storing the ObjectPool in the system itself, I'm hiding it, so I did it wrong. I will fix this in the future