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.

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.

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.

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.

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.

Every game I've worked on used scripting. It allowed us to let designers and non-coders define how levels behaved or "special case" certain kinds of interactions, or even script how quests operate. Heck, we've even used it to fast-prototype massive gameplay systems which were then later partially (or fully) moved into code.

If we didn't use scripting, then we would be rather severely limiting our game and who could design content for it. (Though that starts getting into the definition of "what is scripting" and where it interacts with game data)

So it's certainly not "just for little games"