My entity/component system is happily humming along and, despite some performance concerns I initially had, everything is working fine.

However, I've realized that I missed a crucial point when starting this thing: how do you handle different screens?

At the moment, I have a GameManager class which owns a component manager and entity manager. When I create an entity, the entity manager assigns it an ID and makes sure it's tracked.

When I modify the components that are assigned to an entity. an UpdateEntity method is called, which alerts each of the systems that they may need to add or remove the entity from their respective entity lists.

A problem with this is that the collection of entities operated on by each system is determined solely by the individual Systems, typically based on a "required component" filter. (An entity has to have a Renderable component to be rendered, for instance.)

In this situation, I can't just keep collections of entities per screen and only Update/Draw those collections. They'd have to either be added and removed depending on their applicability to the current screen, which would cause their associated components to be removed, or enable/disable entities in a group per screen to hide what's not supposed to be visible.

These approaches seem like really, really crappy kludges.

What's a good way to handle this? A pretty straightforward way that comes to mind is to create a separate GameManager (which in my implementation owns all of the systems, entities, etc.) per screen, which means that everything outside of the device context would be duplicated. That also seems like quite a hack, and not at all appealing.

Several other options come to mind but they all seem less than ideal, and range from adding a "screen" or "channel" component to filter the results, to rebuilding each system's entity cache whenever the screen changes.

I know Sean is probably laughing about now...