Ogre3D offers a Plugin system, which I
understand to basically be the
equivalent of a normal .dll library
except it has
methods, intended for registering
So my confusion comes down to what
would be best kept in a Plugin or DLL?
Plugins are generally used to extend or build upon the behavior of some existing service or library -- in this case, Ogre. If you aren't intending to directly extend or modify the behavior of Ogre, you don't need to be writing Ogre plugins.
Plugins (and DLLs) are an entirely orthogonal concept to that of component-based game object systems. Generally if you don't know what parts of your game should be in a plugin or DLL, you don't need to put anything in a plugin or DLL -- you'll just create extra work for yourself, to no real advantage.
Most of what I read, people recommend
putting wrappers for third party
libraries into Plugins/DLLs so I am
assuming I would want to have one for
my Physics (Bullet) System, Audio
(OpenAL) System, Input (OIS) System,
and so on.
Some people certainly do organize different subsytems, such as physics and rendering, into distinct DLLs. There's no reason you have to do this, though, and as above it just creates extra complexity. You don't have a reason to be doing so at this point in your project, it sounds like, so I wouldn't worry about it. Generally you want to factor subsystems out into DLLs when you expect them to be versioned independant, shared by multiple projects, or swapped out for alternative implementations. All of those are the domain of very moderately complex projects.
In that case, should I basically just
strip the Managers out of my project,
and move them to a Plugin/DLL? I am
still quite confused on how I will
actually go about implementing them
into Components once they are moved,
but I guess that will come with time.
Just because "other people" do it doesn't mean it's a good idea. If you don't have a reason to factor things out into DLLs, don't.
As for components, I don't think you've fully understand the concept if you are thinking your are going to turn your "manager" objects into "component" objects. Components -- in this context -- are generally very small, reusable packages of data and/or functionality that can be aggregated together (implicitly or explicitly) to form a logical "game object." A component may serve as a connection point between a game object and an unrelated subsystem, such as the renderer, but the renderer itself is not a component and doesn't usually know about components.
Be wary of falling into the trap of assuming that everything is a component or in some way is a direct participant in the component object system in such an approach -- that's not a good way to do it.