Skip to main content
gamedev.net
🔒 Locked

A completely modular engine

Started by cmp 0 replies 850+ views
Original Post
cmp
cmp
As I was thinking about how to integrate scripting into an engine, it occured to me, that maybe a completly modular engine, basicly only consisting of some enviroment vars and a pluginloader, could do the work. I thought something like some baisc enviroment vars wich must be set at compile time (only ENVIROMENT_USE_FILE and ENVIROMENT_FILE or DEFAULT_ENVIROMENT) and then let the plugin loader do all the work. As I am currently looking to integerate guile (a scheme implementation) into my current project, I thought about using the guile plugin as the root plugin and then let it load all other plugins. Every plugin would then just inherit IPlugin and be accompanied by an IPluginHandler class, wich would provide baisc infos as the plugin name, a description, the versions available, the plugin group (graphics, sound, scripting, etc) and function to load und unload the plugin. Currently I am searching for pro and cons against this approach. So please let me know about your opinion.
Grizwald
Grizwald
A pro would be the extensibility.
A con would be the speed issues of having all these DLLs glued together with guile.

Why do you need EVERYTHING to be modular? What are you design goals? Break your engine into subsystems, and create plugins from there.

Game Engine*** Graphics****** Texture****** Shaders****** Models*** Sound****** Effects*** Physics?*** AI?*** Misc


Have graphics plugins (commonly called "render paths"), and shader plugins and etc etc. A generic plugin system is hardly suited for something as complex as a game engine, but if you create several DIFFERENT kinds of plugins, and let the game engine glue them together, you could be on to something.
I love me and you love you.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.