Use-case of code-only, handwritten C(++) games possible/supported?

[metaleap]

Hi all & @LordOfDragons,

I'm about to embark in evaluating various Linux-able, open-source, C/++-based 3D engines/frameworks (fit for linking) for a certain scenario I have in mind, by prototyping a simpleton version of that scenario in all of them that so far made my list of "candidates". =) Afterwards, I'll know best which one to stick to, from perf to API to productivity (subjective =).

As such, having seen the mentions of your "IGDE" and .delga constructions, I'm wondering whether I should even include drag[en]gine at all in this endeavour. Note, I'm talking about a fully code-driven scenario here: no assets ever imported. Neither sounds nor textures nor models. Whether it's deep space or flat ground or noise-gen'd terrain, this is still the basic background context here.

(Let's call it "prototyping with raw ugly primitives right until everything-else-but-the-models/texturings/media-aspect is fun and varied and smooth and fast and bugless" — only when it's all that without art, I'll start wondering about that =)

Anyway so question being: is this engine principally, technically (and perhaps process-/philosophy-wise) supportive-enough of the code-first game(ish) devs who want their engine foundation to be simply a linkable C/++ dependency, not ever caring about any editor GUIs, script langs, or redistributable-packager etc? Or is this all too tightly enmeshed such that coding one's project in .cpps and .hs with clang or gcc in say VSCode is already known by you to be bound to fail or severely frustrate?

Cheers =)

[LordOfDragons]

Hi @metaleap,

The answer to this question splits in two parts so please read the entire response to make a decision.

The Drag[en]gine is a file system based game engine. The IGDE is only used to create assets for which other programs do not exist as well as building the distribution file (*.delga). These assets (like world, animator and other resources) are XML based so they can be edited/generated easily. Writing them to the project directory is all it takes to use them. Also generating the distribution *.delga file can be done from command line if desired.

Primary Usage
The Drag[en]gine is used by game projects through scripting modules. This defines the scripting/programming language used for the game project as well as the degree of abstraction. Currently there exists the DragonScript based module with others planned to be included in the future (using other languages). The DragonScript module is code-driven and thus best suited for developers approaching game development from a code point-of-view instead of an artist point-of-view. In particular this means the game project does not link directly to the game engine nor does it use C++. The advantage of this principle is that no compiling of game code is required. In particular prototyping (and productive game development) is just writing script code and running it without compiling the project. Examples of DragonScript code can be found here: https://github.com/LordOfDragons/deexamples/tree/master/exampleApp/data/scripts .

This is the primary usage scenario. If you want to just create a game you would pick the DragonScript module using the DragonScript language.

Advanced Usage
The secondary usage scenario is direct linking for advanced projects and non-game projects integrating the game engine. The IGDE as well as all the launchers are applications doing this. These applications are then written in C++. In this usage scenario you have full control but you also have to take care of all the responsibilities the scripting modules hide from you. In particular this means that you are responsible to set up and run the game engine. This can be simplified using the libdelauncher.so library. You have to add a scripting module class. This is kind of your application as seen by the game engine. This can be as simple as a this example here: https://github.com/LordOfDragons/dragengine/blob/master/src/deigde/deigde/src/engine/igdeScriptModule.cpp . Once you have this up and running you can work with the game engine using C++ .

To Sum It Up

• For fast prototyping and moving over to productive projects easily using the DragonScript module is recommended. This is the fast and easy route.
• For direct access to the game engine using C++ you can link directly to libdragengine.so and libdelauncher.so . This is the more involved route but with the highest flexibility and allowing to integrate the engine into existing applications.

[LordOfDragons]

If you don't mind I'd like to know your decision and if possible the reasoning behind it. This would be helpful to improve the usability of the game engine.

[metaleap]

@LordOfDragons first of all thank you so much for this richly-detailed reply of yours! It has certainly meant to me at the very least that drag[en]gine remains in my list of viable candidates to explore and experiment with from my code-first approach and scenarios, from the "Advanced Usage" paragraph's vantage most likely. However I haven't admittedly jumped in to the active-doing phase just-yet wrt to the drag[en]gine part, the beginning of which is I guess perhaps another 1-3 days away but not sure. As such, no "action items" from me here as-yet, but once in it, I will no doubt pipe up with something or other soon enough =)

[LordOfDragons]

Drag[en]gine has a different workflow than other engines so I'm certain there will be questions on how to get things started. Feel free to ask any time, either here or in discord.