https://github.com/SonyWWS/ATF

At the risk of teaching grandma to suck eggs, in my meagre experience game editors are often very tied to the specifics of a particular game, or at least game engine, and are often written in the game / engine. Here is an example (slightly old) list of some game editors, most are tied to a particular engine. The editor may even be written in exactly the same way as a game (a level building game with exporting) with an engine (e.g. I believe Godot may do this).

There are some exceptions where something more generic might work, like e.g. 2d tiled games, or in the old days people would sometimes use 3d modelling programs as level editors (although this is usually a poor solution), or you may be able to bandit the level editor for another similar game. What particular game / engine were you thinking of? There are also GUI toolkits such as QT you can leverage if your own game does not have much GUI support.

I think the best start is to look at ImGUI. There is a lot of activity there at the moment. And with Blizzard driving the development as the main sponsor you can expect some interesting development there in the future. 

https://github.com/ocornut/imgui

In particular dock widgets are interesting in this context:

https://github.com/ocornut/imgui/issues/2109

If you browse around the project you can find a bunch of smaller engine projects which use IMGui for their editors. Most notably Lumix here:

https://github.com/nem0/LumixEngine

Here is a good talk about tools in general I stumbled across recently :

https://www.guerrilla-games.com/read/creating-a-tools-pipeline-for-horizon-zero-dawn

Note that I am not arguing here that ImGUI is the new sexy. I am actually not convinced it is any better than more traditional GUI libraries like e.g. Qt. We use Qt at work and my experience with Qt has been excellent most of the time. Unfortunately there is less information publicly available how to write good game tools with Qt which I could point you to (or I am not aware of any).

If you look at ATF I recommend to look at it as an example how not do it. In my opinion this is an example of *massive* over engineering. If you will use ATF for your tools you will end up with something that will be absurdly complicated for the problems you will be going to solve. In particular their comparison with Qt doesn't make sense and shows that the author doesn't know much about Qt in my opinion. 

HTH,

-Dirk

53 minutes ago, Dirk Gregorius said:

If you look at ATF I recommend to look at it as an example how not do it. In my opinion this is an example of *massive* over engineering. If you will use ATF for your tools you will end up with something that will be absurdly complicated for the problems you will be going to solve.

I hadn't seen ATF but after watching a few youtube videos, so much this. In the time that it took to read the manual for ATF you could have written a fully functional editor for your engine, that actually works with your engine, not against it, rather than trying to shoehorn in some 'one size fits all' approach and duplicating all your work.

Writing this stuff in C# and connect it via a bridge assembly to your how-ever written engine might be the best approach in my opinion after working for a couple of years in the industry at the tools side and this will also be cross-platform as long as you don't use any heavy Windows or Linux only features running either .NET or Mono.

The good thing about C# is that you can manage anything using interfaces and some hidden auto-binding-assembly generation in .NET 4.0 and upwards so you define your interface, tagg it's methods with coresponding external bindings and let your runtime code generator do anything else.

If you are driving the C++ side of engine code, then you might also want some kind of RTTI to make working with your bridge assembly more easy.

What I think an editor should have is a simple but also powerfull design while I agree on ATF and want to push other systems like Unreal, Unity or even Godot into race for bad heavy overloaded UI Design. The simplest thing you need for startup is just a window rendering your 3D scene holding a render context from your engine and access to your objectives you want to place in the scene. Anything else will occure when you have need for it

HI @jjd,

Echoing people's comments above, it would depend heavily on the type of game you're writing. My experience is with 2D games, this answer is focussed on them.

Initially I used Tiled - Link. This is a brilliant tool which allows you to define tiles (hence the name) on a 2D grid as well as lay addition items not necessarily based off a grid. To use Tiled with game objects, you add these floating tiles (which can have arbitrary properties). Your resource pipe line can then load in the file definition (Tiled's XML file format is trivial to read) and then process it accordingly.

I subsequent wrote my own (see below) for many reasons:

1. I wanted to 
2. I wanted to have greater control over the properties of the game objects

Point #2 was the most important thing for me as it made the tool more generally usable by non-specialists. It also allows you to edit more complicated items / specify dependencies and have them picked up in the tooling layer rather than the subsequent processing layer etc.

The way I've written it is as a generic tile editor with the ability to add .net game objects (using reflection / plugins) to the levels. This way, I can use it for any future games within the same genre. This genericity added to the development costs of it, but proved to be useful for me with my 2nd game.

Whether it's worth going to this extreme depends on you, your time budgets and your requirements. With hindsight (given it slowed me down in terms of development of the game by about a year if not longer) then I'd say that it wasn't and I would have been better off staying with Tiled for longer. I don't regret having the tooling now as I find it very useful, but... Note that I simplified migration matters somewhat by having the ability to write an importer for TIled files so that was all simple. If you're working as part of a team, do that approach.

Hope this is vaguely helpful

Steve