Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I worked on a personal game project (learning) for about the last year or so off and on in Ogre3D. Now that I am starting a new project, I want to avoid the Class Heirarchy for objects and having all of my libraries stuffed into one project file.

After a massive amount of reading, I am going to start implementing a Object/Components system tomorrow, mostly based off of what I have read on http://gameprogrammingpatterns.com/component.html but I want to have a better understanding before I proceed.

Ogre3D offers a Plugin system, which I understand to basically be the equivalent of a normal .dll library except it has install()/initialise()/uninstall()/etc methods, intended for registering factories.

So my confusion comes down to what would be best kept in a Plugin or DLL?

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.

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.

share|improve this question
add comment

1 Answer

up vote 4 down vote accepted

Ogre3D offers a Plugin system, which I understand to basically be the equivalent of a normal .dll library except it has install()/initialise()/uninstall()/etc methods, intended for registering factories.

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.

share|improve this answer
    
Thank you, great answer! –  Brett Powell Jun 17 '11 at 0:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.