I looked over your code and I have a few suggestions / comments.
What purpose does making Manager a singleton? That choice effectively implies your World is a singleton and to me that imposes an unnecessary design restriction that serves no purpose. It's not uncommon to manage different simultaneous simulations, particularly in game editors.
As an editor example, you have a surface where you render your game world simulation where you're editing the level, one where you render the game world in play-mode, and others where you render things like a material editor or some compositor node hierarchy. You might actually have different levels loaded all being rendered separately, all which require their own World instance. In all these situations, you may also have different systems at play and thus each World simulation should be tied to a specific finite list of applicable systems. A generalized class like Manager to me seems like an unnecessary abstraction, one which a World can fill easily.
Also somewhat related, you have several methods on Manager which seem ill-placed like create_entity, add_velocity, and add_position2D. I would probably suggest something like a ComponentFactory and possibly specializations for each component-type that you interact with to create your components. The allocation/destruction of entities would be a function of your World or some associated Scene object that your world has a reference to.
In the end, this notion of Manager goes away and it leaves you with a World where you might actually register the systems with instead. If you truly want to avoid having to register systems with each constructed World, you could use the factory pattern again:
class WorldFactory {
typedef std::vector<System*> SystemVector;
SystemVector systems_;
public:
//! Register a system with the WorldFactory
void registerSystem(System* system);
//! Creates a world, adding each registered system to the World's simulation list.
World* createWorld();
}
I still disagree to a degree because I believe each World should be constructed with its own necessary ticked systems and nothing which is unnecessary, but if you at least want something generalized, this approach at least provides an flexible and useful design pattern instead of the Manager singleton you had. You decide based on your need whether you create and reuse the same WorldFactory or if you create multiple instances as needed.
The main problem now is that although the systems now know what entities they have to operate on (each systems keeps a list of entity IDs) does not mean they know can operate on their components.
Why not?
Lets take a system that renders a sprite at a specific position. Such a system checks the entity when the "OnEntityAdded()" callback is fired and looks to see if that entity has a sprite and transform component. If it does, it adds it to that internal list and if not, it isn't added. It's assumed at this point that entity has both components. Then when the "OnEntityRemoved" callback is fired, the system simply removes that entity from any internal lists it maintains because the entity is being removed from the simulation.
Just remember that a system doesn't necessarily imply a 1-to-1 relationship to a component. There are definitely use cases where different component types (where applicable) are processed by the same system. For example, my RenderSystem knows how to draw 2D sprites and 3D meshes. While the components for these are different, the same system operates on these. So internally, that system maintains multiple lists and just handles updating each list accordingly during that system's update tick.
I am not sure if the user should be able to edit the data in a component directly or if ONLY the systems should have permission to change state in the components.
I personally advocate that your components represent the user interface into the underlying framework. The systems may expose various means for other systems to interact with one another but generally I would say that from a game designer perspective, the component's attributes are their path into influencing behavior.
