You shouldn’t need a subsystem. You can just build your controllers as components, and subscribe them to listen for the PhysicsPreStep (E_PHYSICSPRESTEP) event, which occurs right before the physics update. They can then issue whatever orders they need to their owning object in a self-contained manner, without having an external system handling it all. I recently did a blog post on a third-person rpg camera system I implemented for some of my projects (
gamedev.net/blog/33/entry-22 … on-camera/
) that includes a demo in Lua. The demo implements a very simple RPG-type level with a camera that has a number of options. The demo includes 2 player controllers: 1 that allows point-and-click, Diablo-style movement with pathfinding, and the other (commented out in the object instance section in levelgenerator.lua, but you can uncomment it and comment out the other) that implements WASD-style movement. They are implemented as ScriptObject components that do their work during Update. There is also a random-wander AI controller as well assigned to a handful of AI units. Each controller is a self-contained component that is instanced into a node to provide that node with the desired behavior.
In my opinion, you should try to implement everything within the game as components attached to nodes; subsystems should only be done if something needs to be visible to many different objects globally, rather than being local to the object as a player or AI controller is. My personal preference is to do
everything
as components; and if something requires subsystem-type behavior, do it as a scene-level component similar to PhysicsWorld, Octree, NavigationMesh, etc…