I have been trying to come to come up with a good way to handle editors/tools and
I think I’ve finally found a method that satisfies me.

Some projects use external tools, while others build them directly into the application.

The external tool method bothers me for a few reasons

1) potential problems with tool not being in sync with engine/game
2) some tools will need access to engine code
3) end up duplicating functionality already found in the engine/game
4) won’t be able to really see what it looks like in the game(not easily)

The method of directly embedding(preferably as DLL) it into the game is somewhat
more appealing to me, but this method has one big issue at least…

1) Since your game is likely using DirectX/OpenGL, there really aren’t any great UI
solutions readily available, so you will likely use whatever method your game uses
for in-game UI (scaleform for in game editor? Ugh.. no thanks)
2) Also if the game is slow to load and has no methods to reduce what is loaded,
lots of time can be wasted

Then I heard about methods such as this D3D10 and WPF
and was interested because I thought I might be able to use this to somehow display
WPF with my D3D11 app.
Unfortunately it seems to work the other way, you can display D3D in the WPF app,
but not vice versa(at least not that I’ve been able to discover).
Dropping the D3D into WPF means you are at the mercy of WPF for updating the window,
and if you have multiple tools each one must have the D3D interop code added. BLEH.

My codebase is primary native C++, but supports dynamic loading of .Net assemblies,
and I’ve written a fair amount of interop code to allow these assemblies to communicate
with the rest of the game.

I began to wonder if it was possible to make a WPF assembly, dynamically load it like any
other .net assembly and have it pop up a separate window. Perhaps this isn’t surprising
to people more familiar with managed code/WPF, but for me it as somewhat surprising that
this did indeed work– although I had to overcome a few odd problems.

Steps:
1) Create the WPF project
2) Go to project properies and change output type to class library
3) the project defaults to application, to change this click on app.xaml, go to properties,
and change “Build Action” to “Page”

(may be other/better ways of handling some of this next part)
4) I way I do it is; create an instance of the window(called MainWindow by default )
within my startup class, but I have to do it a special way to avoid .net tossing
exceptions such as this lovely one

“The calling thread must be STA, because many UI components require this.”

_Thread = new Thread(LaunchWindow);
_Thread.SetApartmentState(ApartmentState.STA); //Many WPF UI elements need to be created inside STA
_Thread.Start();

This calls the “LaunchWindow” function on a STA approved thread, the function
just does this currently

_Window = new MainWindow();
_Window.ShowDialog();

This causes a 2nd window to popup, it acts independently of the apps
primary window.

I’ve heard of other methods where the game acts as a server and each tool a
client, and communication is done via networking. Sounds good, but I don’t feel
like spending time to implement that( and I already have a generic event system which
allows for communication between unrelated modules in lua, C++, or .net), also that method
does prevent directly access(which could be seen as good.. or bad…).