Skip to main content
gamedev.net
🔒 Locked

DLL Usage

Started by caldiar 1 reply 750+ views
Original Post
caldiar
caldiar
I'm currently working on a project I'm not going to write too much about since I don't want to get anybody's hopes up in case the project dies heh. Anyways, the basic goal of the project is to rewrite an open-source game engine to a user-friendly development environment for the new modder ready to hop in and grind a new game out of the engine. My current idea is to have my executable read from several DLLs such as Network, Renderer, Client, Server, etc... to determine the behavior of the main executable. The method behind the madness is that modders could rewrite a piece of the code and compile it to the new DLL that the engine would read from. This would prevent a recompiling of the entire engine or a rather large chunk of it. But the more I think on this the more I realize I don't really see many games use a lot of DLLs. I'm starting to think that this wouldn't be the greatest solution to modulate the engine and provide an easy programming environment for the programmer. Would anybody be able to confirm this? I'm starting to think that perhaps I should use a scripting language to let the modders change the game without actually compiling code. The only gripe I have with that is that interpreting and making use of the script is sort of cumbersome for the program itself since I'm also going for a lightweight, speedy game engine that can run decently on 1998-era computers. Thoughts?
ApochPiQ
ApochPiQ
DLLs add complication for virtually no benefit in this case, because you don't need to dynamically swap out large subsystems like the network code or the renderer. They also introduce some subtle difficulties with memory management, because it's extremely dangerous to allocate memory in one DLL and free it in another, and so on. There's also a risk of runtime performance cost because the compiler can't do things like inline function calls across modules, etc. In general, games don't use DLL-centered designs much because they aren't the right solution.

If you have well-designed code it should be modular enough to work with easily inside a single EXE, even if it's hundreds of thousands of lines.


Scripting isn't that huge of a load, and by "1998-era" it was already fairly common in large games (although it sometimes took some magic to get it to perform well). In any case, why the heck are you targetting 9 year old hardware with your engine? You do realize that's like starting a car repair shop that specializes in Model T Fords, right? Just target, say, 2002+ and you should be fine.

I would personally suggest aiming for clean engine-side code to allow programmers to alter that, and support gameplay logic via a scripting engine (Lua is pretty nice). That should take care of your easy-modification requirements without putting undue stress on you as the original developer.
caldiar
caldiar
Thanks for that ApochPiQ. Once again you're the voice of reason :)

I guess I'll focus on writing clean well-designed code then and I'm going to consider using LUA in the engine to provide the ability to conduct minor tweaks without recompiling the code itself.

My reason for targeting 9 year old systems is simple: I want to adhere to the original design of the engine without straying too far from its intended designs.
I'm merely converting the engine from C to C++ which isn't too big of a change. In the transition I'm also cleaning up some known bugs and I'm trying to make it easier on the artists/programmers to develop content for it.

Also, I figure if I target the older systems then they'll run at max settings without any issues on the newer systems. Almost everybody has a computer with 98-era capabilities while not everyone has a computer that can run UT 2007 type engines. (Not to say I'd be able to make such an engine heh)

Again, thanks for the input ApochPiQ

Topic Locked

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

Sign in to reply to this topic.