Game engine + editor + gameplay dependency

Question

I've tried to find my answer here but the other "similar topics" were different or just wasn't able to find the right one.

This is mainly a design (and some c++) question about the dependency between the different projects. Let me describe my problem:

So I've already used Unity and UE4 and I like the approach(es) they're using. They have a (game) engine an editor application and a user-created gameplay code. You can use your own gameplay code in the editor - you can assign scripts to objects, run/pause/step/stop (and debug!) the actual game in the editor.

I've checked the UE4 source code (which is actually pretty big) and the way this works is they're using custom build and preprocess tools (like Unreal Header Tool) and they've implemented everything they're using. As I could see, they're not using any STL class/function, they've implemented their own. This way they can make the "engine project" shareable, so they can build the libraries to dlls and that's it.

I'm using the same component-based approach. Different components can be attached to an object, and an important component base class is the Behavior. The "gameplay components" inherits from the Behavior base class.

So back to the problem: I (will) have 3 different projects:

• Engine
• Gameplay
• Editor

The Engine is the core, that is a static library with every required thing except the game-specific code, of course. The Gameplay depends on the Engine and is built as an executable (*.exe). This contains the actual gameplay code while using the engine.

And here comes the real problem: the Editor depends on both the Engine and the Gameplay projects. Why? The Editor is using the Engine to create the window, draw buttons, log messages, etc. However it would be nice to be able to assign the "scripts" (in the terms of Unity) to objects and that would be the best if I could "play the game" in the editor, like in Unity.

Why is this a problem at all? Because I'm not able to use a shared library for the Engine project. Why? Because I should dll-export a lot of things which is not even possible while using the STL. It's a known "fact" that most of the STL objects cannot be used with dll-export (and I should write a lot of export code now, heheh). Also I don't want to use any bigger library like Boost or Qt.

However if I'm using static library for the Engine project then the Editor and the Gameplay will have its "own copy" of the Engine.

Maybe a half-solution could be the following: I could have a 4th project for the gameplay code exports which would be a dll. This project should only contain some functions which would be used in the Editor - eg. query the list of the available scripts with the visible variables, etc. However the game code is not actually available in the editor, so any "play in the editor" wouldn't be possible.

Answer 1

I think you are overcomplicating and over-engineering your solution, and I think it comes down to some misconceptions you have about what Unreal is doing and why:

The problem with passing objects across DLL boundaries is not a problem with passing STL objects across DLL boundaries. It's passing any C++ type across DLL boundaries; C++ doesn't have a standard ABI, so any two compilers or even the same compiler with different settings can result in binary incompatibilities between DLLs.

Unreal does not solve this problem. It simply expects that you will not be mixing and matching DLLs built with different tools and with different settings. It builds everything on the same tools with the same settings, which means the lack of a standard ABI isn't a problem because they all still end up using the same ABI.

It also does not produce separate executables from separate projects for the game and the editor. The executable is one project, and there are several project configurations that build either an editor executable (which is the game plus the editor stuff) or a standalone executable (which is just the game with all the editor stuff compiled out).

Unreal splits a lot of stuff up into DLLs because of its module paradigm (and there are editor-only module DLLs) which enforces type access and enables hot-reload of C++ code. That's all rather advanced stuff and likely overkill for your project.

---

If you want to implement the Unreal paradigm, this is the direction you should take: one engine library, one executable, using the preprocessor to compile-out editor functionality for the standalone build configurations (look at all the #if WITH_EDITOR... blocks in Unreal).

Strictly speaking, you don't even need to bother with a DLL and the worry of potential ABI mismatching. Since you just have one executable, linking a static library containing the engine code is just fine. In fact you wouldn't have to deal with a library at all (although it can be nice to do so to really force a separation between engine and gameplay code).