There are many tools that work well in game. Others are hard to get right.

In Unity you can do this while debugging, adjusting values in the inspector and watching how it affects the game.

Many tuning elements are nice to have inside the engine. Exposing values for AI can make it easier to see what characters are thinking, and adjust the values as it runs. Exposing any developer-friendly or testing-friendly values is generally useful. Think about the cheat codes and debug codes you've seen in games over your life, those are all probably features you could consider exposing in game.

What does your 'dialog editor' do? Are you modifying strings? Are you modifying the story tree? Are you modifying the script controlling story flow?

If you're only modifying text strings, that might be fine for a small game. In big games where text gets localized into a bunch of languages and recorded by voice actors, it is best to have a naming convention and use a key, which then gets replaced with the locale-specific string and audio.

If you are modifying more complex parts of dialog, like what happens if the user selects each of the options, then you'll be exposing a lot of your own internal scripting data in the tool. It may be quite a bit of work to build such a system.

I tend to find that you're usually better off making an external tool and then setting your game up to hot-load assets. You don't usually want to wait for your entire game to load before making a spelling fix to a line of dialogue.

By making the tool external to the game, you're more likely to create better structured and more modular code, as things like asset loading and the renderer will probably need to be used by various tools in addition to your game and you don't want to write that code twice. Not to mention you probably don't want to write your tool in Win32/C++ either, so you'll want to be able to wrap it up in something that, say, C# can load.

Not to mention that a tool may want to load additional information that a game won't actually care about - or the tool may be able to load unprocessed assets that would slow the game down to support (like textures in a variety of formats while keeping the game loading DDS files).

For bonus points, have a button in your tools that can push the changes to a running copy of the game to hot load them and position the player wherever the camera is in the tool for quick testing. This also means you could (theoretically) push your content to another platform over the network to see your changes on a variety of platforms your game runs on, be they consoles or mobile phones.

Not to mention you probably don't want to write your tool in Win32/C++ either, so you'll want to be able to wrap it up in something that, say, C# can load.

This seems to be the most common approach, but is actually the worst because you're going to have more individual code bases to maintain. I propose that you write the editor in-engine where you will likely already have the loading and parsing of your datafiles into your engine format done and will be simply be modifying that same data that you're already using. Why have the duplication of it loaded in another tool?

[background=#fafbfc]Not to mention you probably don't want to write your tool in Win32/C++ either, so you'll want to be able to wrap it up in something that, say, C# can load.[/background]

This seems to be the most common approach, but is actually the worst because you're going to have more individual code bases to maintain. I propose that you write the editor in-engine where you will likely already have the loading and parsing of your datafiles into your engine format done and will be simply be modifying that same data that you're already using. Why have the duplication of it loaded in another tool?

... I pointed out exactly why in my post.

You don't duplicate the code. You make the code modular so the game and editor can use a couple of shared libraries for file loading and rendering (but NOT so shared that they are the same application). And then you get all the other bonuses by keeping the editor and game separate as listed above.

Remember - the editor needs to modify the data. The game does not. The editor can require a lot of extra memory to make edits to game data easier and faster. The game wants to use as little memory as possible using immutable data optimized for different kinds of access.

A program that plays MP3 files just needs to play the MP3 file. A program that makes mp3 files will probably want to work in a higher quality audio format than MP3, require a lot more memory to keep the audio in an uncompressed form for the best editing as well as loading multiple audio sources, and generally be much more complex.

Why load up an entire audio editing suite when all you want to do is listen to some music?

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

Doing it all in your engine doesn't prevent you from doing the optimised per-platform stuff.

It depends what your requirements but i have always found maintaining multiple tools and programs too much work.

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

So put the engine in a shared library and build your editor on top of it. ;)

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

So put the engine in a shared library and build your editor on top of it. ;)

I have no problem with this, maybe this is what he meant and i mis interpreted :).

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.

So put the engine in a shared library and build your editor on top of it. ;)

I have no problem with this, maybe this is what he meant and i mis interpreted .

Take a closer look. It's more or less exactly what he said:

You don't duplicate the code. You make the code modular so the game and editor can use a couple of shared libraries for file loading and rendering