Man I got a lot of info...

What I'm trying to do is stick to c++ and use something like ImGui. Because displaying the game in the actual engine seems to be a ton of unnecessary work, what I'm planning on doing is just have the engine like more of a scene editor and asset generator, and the the actual project run the game.

Thanks!

Using ImGui for an in-game editor works fine. I am using ImGui myself for debug and development UI but a separate UI system for the player-facing UI.

Since people are listing middleware now I am just gonna mention https://www.noesisengine.com/ which I am using myself.

There seems to be some confusion about what the engine is. The project editor or scene editor is not the engine. The engine runs in your game - it's a set of API's.

To have your game run inside an editor - well, you might not even want to do this. It's fine to build your game and also side by side build a world editor. But if you do want to run the game - or even partially run it. You have to consider how your editor works and also how your engine works and just integrate them as makes sense.

I have an engine/framework in UWP, and that makes it easy, because I just have to create a Xaml application with a SwapchainPanel control. My engine can be started using two different application types .. 1) a XamlWindow applicaiton  or 2) a CoreWindow application (no xaml). So to have an editor host the engine output I construct the engine with the XamlWindow's swapchain panel. I start up the engine thread. I setup the scene graph and that's it. I have the game view running inside an editor. I then use UWP Xaml to make the editor.

That all being said, it's a work in progress.

On 5/10/2019 at 4:38 PM, DeadStack said:

The project editor or scene editor is not the engine

Depends in the kind of how this is implemented, some games like DnD Neverwinter Online offer an in-game and so also in-engine editor for content creators to make new qeusts and stories so it is part of the engine the game is running in because it is content and not gameplay.

Trying to redirect back to the topic...

On 5/6/2019 at 8:34 PM, TheRealSmolt said:

In Unity, the engine and the game are the same program, with the game window inside and in a different project. I don't know how to achieve this.

You can start where they did, which is with a plugin architecture.

Conceptually --- and potentially actually done as an implementation --- they follow this model:

The engine provides a bunch of functionality, loads a plugin designated as the primary plugin, then spins in a loop running the main plugin.  When you start the editor you are starting the engine with your editor as the primary plugin.  When you run your game you are starting the engine with your own library as the primary plugin.

The game editor is basically a plugin for the engine that includes editing functionality.  It tells the engine to display the menus, game resources, object inspector, and similar pieces.  The plugin also includes details for how to launch a compiler, how to load a secondary plugin, and how to execute that secondary plugin in addition to itself.  Usually they load several more plugins for additional functionality like profiling or networking tools, whatever they need as part of the editor suite.

Your game is a second plugin.  When it is loaded as the primary plugin it runs as you expect your game to run.

You can also write additional plugins, and many online resources exist as plugins. Some games include many additional plugins. They are compiled and added to the program as secondary plugins, and your code or the editor's code can run them. VR plugins are a great example, they are generally separate modules that register to provide additional functionality for the editor program, and also can be used by your code.  

The implementation details are somewhat different between Unity and Unreal.  With unreal you can see the source, open the editor project and see all the things it is doing.  It can be overwhelming to look at for beginners, and daunting for those with intermediate experience.  In Unity you can't see the source unless you're at a company that pays for it, so the conceptual model will need to be enough.

Some games mentioned above have the editor parts permanently included with the engine parts. There are several ways to implement that, but that's not the model being asked about when referencing Unity and Unreal.