Componentizing Games

If this is something that the people themselves will be able to create objects for, probably the large chance that it gives for people to cheat. As well as the fact that it will be difficult for people to create objects unless they know at least something about the inner workings of your objects.

If this is something that people won't be able to create for themselves, ignore this post.

Yann L suggests a effect/shader implementation that makes use of dlls

Shader Implementation


In my engine I componentize like this

Engine executeable
Client DLL
Server DLL

shader DLLs

the shader DLLs define which effects they can render and are choose by a priority, possible hardware support and user quality/performance settings

it allows the easy update of visual quality on the fly

Its very similar to the system Yann L explained in detail in the thread above


As for componentizing game objects in dlls, I would rather for for a Client Server DLL approach to avoid cheating issues.

Also think about the potential security problems when downloading dlls from a random server on the net.

I think a scripting solution would be a better choice in this case
I think there are some scripting engines for lua that you can plug into you project

here s the link to their page
Lua homepage

Cheating concerns are not a threat since the written DLLs will act as to be read from. The server would be responsible for validating the output. You may imagine the DLL as a player + the ability to construct objects from other PREDEFINED OBJECTS.
So the concern would be whether or not these Dlls pose general security issues? Is there a way to limit the DLL abilities to call only functions defined by the Server?
Using a scripting language is out of my reach right now. I'll check that Lua language anyway...

I can't think of any other way to design a game engine without imagining a large stinking pile of badly encapsulated crap code in front of me ;)

But I wouldn't limit the plugin concept to just the game logic (that would be your 'definition' component). I had great success with a microkernel-like game engine which did not link to any libraries besides Boost itself. The image formats it could load were dynamically supplied by plugins. The rendering APIs it could handle were dynamically supplied by plugins. The archives (like .zip, .rar) that it could read from were dynamically supplied by plugins. You get the idea.

Speaking of components, I've broken it apart like this:
- engine (networking, plugin management and other shared code)
- simulation (game logic, physics and other typically server-side stuff)
- visualization (graphics, sounds and other typically client-side stuff)

But a finer granularity also makes sense, I guess. Just make sure you keep the game logic seperate if you're going for multiplayer support.

-Markus-