Sign in to follow this  
krautrock

Extensible Architecture and Pluggable Factories

Recommended Posts

Hi all! :) I'm a new user and I hope to get along with you :P I've recently finished to code a little cross - platform game engine which presents some basic functions and I'm going to start a new ( i hope ) more advanced engine project now. The impossibility to add new extensions is one of the things I don't like of my current engine: it works quite well but, for example, it doesn't provide a method to add new resource without editing the renderer device code ( renderer works as a factory ). I've recently read some tutorials about pluggable factories and some articles such as "Self - Registering Plug-ins : an architecture for extensible software" which seem quite interesting. They provide a way to add new extensions to a factory class by letting classes auto - registering themselves. In this way I could add new classes/modules ( for example a new particle system or a new feature ) without editing anything. I think nebula device provides a similar system, but this engine is quite complex to understand.. I'm not talking about dynamic link libraries and dlls ! Have you implemented a similar feature in your engine .. ? How did you designed the extensible system .. ? Do you think it could be useful .. ? Where would you put a similar system ( resources, window classes, shaders ) .. ? Please give me some suggestions and help me find a solution to this architectural problems =) I think lots of coders would like to read some ideas to provide an extensible design in their engine architecture =) Thank you!! Bye!!

Share this post


Link to post
Share on other sites
I think the architecture your referring to is indeed quite useful in some cases. (Although I'm a bit baffled why this can be published as a research article in 2005, but hey...).

Indeed, cases like image loaders can benefit from this architecture, since there is never a class that depends on all types of image loaders.
Likewise, I can image it working well for things like unit types, so instead of:
Unit *Network::createUnitMessage(NetMsg const &msg) {
switch(msg.unitType) {
case UNIT_ARCHER: return new Archer(msg);
case UNIT_CANNON: return new Cannon(msg);
case UNIT_KNIGHT: return new Knight(msg);
}
}
you could use those pluggable factories.
For things like shaders, or window classes I think beter alternatives exist.

Also, when you would implement this, take care of the problems associated with DLLs. In the article, a small paragraph says that it works with DLLs, since <code>registerThis</code> will be instantiated, but you also have to make sure you register your class with the EXE, not some static map in the DLL.

Share this post


Link to post
Share on other sites
Thanks I understand but I've read about people who have programmed completely extensible engines ( no fixed factories etc )..
Has someone done a similar work ? How would you code this ? I've read part of nebula device code and I've seen it uses declareclass, registerclass and implementclass functions. Can you please tell me what are they supposed to do ?

[Edited by - krautrock on July 27, 2008 12:27:23 PM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this