Jump to content
  • Advertisement
Sign in to follow this  
Alundra

DLL as game module

This topic is 1025 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

Nowadays, people use script but is it bad to stay with the old way which is to use DLL as game module ?

Just one Game.exe compiled once which load Game.dll.

Or one simple Main.cpp template to set the dll name and have the build process which replace by the good name.

Or load the dll based on the project name on the ini file : ProjectName-Win32.dll / ProjectName-Win64.dll

Of course, have the ini file packed on the final build for security.

Edited by Alundra

Share this post


Link to post
Share on other sites
Advertisement

Here is my opinion - if you know how to use both (and I do not) use whichever you are more comfortable using.  I really learned how to program using QBasic (despite the computer classes taken in college) so I feel more comfortable around MS's Visual Basic then I am working with C# and C++ so when I get around to coding my game I will do it in Visual Basic.using as many ideas I can steal.... er, "borrow" from other people. No reinventing the wheel around me people!

 

Just to show my ignorence - how would you you a DLL as a game module? I know the basics of how to create a DLL in VB but I am not certain how it would apply in this case.

Share this post


Link to post
Share on other sites

is it bad to stay with the old way which is to use DLL as game module ?

There's nothing inherently bad about it. If it works for you, it's fine.

 

Of course, you should remember that exporting C++ interfaces might be tricky sometimes. I'd suggest avoiding the DLL entirely, if you can, and use a static engine library which you link to the game code.

 


Or one simple Main.cpp template to set the dll name and have the build process which replace by the good name.
Or load the dll based on the project name on the ini file : ProjectName-Win32.dll / ProjectName-Win64.dll
Of course, have the ini file packed on the final build for security.

No need to overdesign the thing though. None of this is really necessary.

Edited by snake5

Share this post


Link to post
Share on other sites
Make a game.

DLL, scripts, whatever, doesn't matter as long as it's fun and runs with acceptable performance.

Scripts consume more processing power and memory then equivalent native code, but are much faster to iterate on and can (pretty easily) be hot-loaded while the game is running.

DLLs have most of the speed of native code, but sacrifice some speed due to disabling some optimizations the compiler could otherwise perform. They also have some potentially unexpected behavior in relation to memory management. They can improve iteration time by not requiring you to re-link the engine when you change game logic. You can even theoretically hot-load DLLs at runtime, but this requires a lot of careful architecting.

Putting everything in one exe is always going to be the fastest option, as the compiler can perform the best and widest-ranging optimizations across the whole code base, as well as potentially reduce the size of the executable. The downside is the usually pretty terrible iteration time.

Share this post


Link to post
Share on other sites

I use a factory which contains all actors and the game module add / remove actor in the factory.

The editor has a window with all actors and the game designer only drag and drop in the scene the actor.

The initial goal was to use Runtime Compile to hot reload the Game Module DLL to update the editor based on that.

It's an independent editor, you create a project and you make the game like unity and unreal.

I have experience on both (made games on both) : script for unity and blueprint for unreal.

I never was in a fan club of the scripting, it's fast to prototype and make little games.

Unreal uses the option to give the two possible : blueprint and c++ compiling a DLL.

The cost of the visual script is surely not good, only for little games.

Edited by Alundra

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!