I'm planning out a WYSIWYG level editor for my 3D racing game, but will start with some more straightforward features like loading and moving models, before I get into more game specific things like building tracks and checkpoints. Having said that, as I'm also working on the graphics code that the game will use, there will inevitably be some level which it will have to respond to a WYSIWYG editor.

How "close" to the game code should the editor code be? Would you make it part of the game project, or in a different project that is deployed as a standalone program? I've tried using WinForms with XNA, but the combination didn't feel right to me. My plan is to start out with a simple GUI rendered alongside the game's graphics, like a toolbox for basic selection and creation functions. Nothing too big or complex like the editors for popular, commercial engines. I also found this, but I've yet to use it with my game...could be a timesaver if it's easier to fit it within my pipeline than making my own, though.

How "close" to the game code should the editor code be?

Identical. Ideally they'd both use the same dll or else your notion of including the editor in the game is also a good option. Personally I prefer external editors unless I plan to include the editor as a user feature, but that's just me. If you're using the same models in the game and the editor, though, just use the same graphics code. If your implementation is properly abstracted you should be able to pull the graphics code out with minimal fuss and build the editor around it.

Alternatively, if you have found a good editor somewhere that will work for your game then you'd save yourself time by just abandoning the WYSIWYG preference and using the existing editor. It's something you'd have to weigh against the limitations it would impose on you.

Would you make it part of the game project, or in a different project that is deployed as a standalone program?

Just to add a personal anecdote, My game/editor solution is comprised of three Projects:

The "engine" :: all my framework code, definitions of game objects, data structures, central modules like phsyics, rendering, AI, etc

The "game" :: references the engine project, implements the features of the engine in a manner specific to the game I'm making (i.e. instantiates a game camera, loads specific levels and assets). This is a fairly small project in relation to the engine (as far as file count and lines of code).

The "editor" :: references the engine project, has its own set of editor-specific tools and classes to do things like paint-deform terrains, modify properties of objects, package up new resources for use by the engine, and serialize out level files when the map is saved in the editor.

FWIW: I started out more with the editor first, and ended up later making the editor into the game, as previously I had been using a variant of the Quake2 engine (as the game-engine part) and later decided that I wanted to be free of the GPL (in its earlier form, my engine was originally some 3D tools, like a 3D modeler, skeletal animator, and map-making tools), so I discarded the Quake2 engine (and nearly any other code I hadn't written myself) and at the time wrote a functional mock-up on top of my own code (albeit mostly using the maps from Quake 1), then later on ended up moving over to voxels, mostly due to me being not so good at making original maps which didn't suck, and voxel terrain was one of the few options which "wasn't totally lame" (I had also tried modular tile worlds, bus wasn't particularly compelled by the results, ...).


originally (some-odd years ago), my effort was more motivated at trying to make "better" free 3D tools, because most of what exists in free-land kind of sucks, but then I was left to note that my tools weren't really all that good either... and who knows how much work goes into making something like Maya or 3DS Max... interestingly (in a sense), the 3D models for my game were created in the engine itself. for the most part though, no one really seemed to care about 3D tools.


personally, I don't think there is anything particularly wrong with making them all part of the same codebase, at least as far as it goes that if the code is reasonably well abstracted, then it shouldn't really care too much if it is part of the engine or part of the editor.

the drawback: often code doesn't really end up that well abstracted, and in these cases one may end up with cruftiness, but in this case it is more a question of shared code with the cruftiness involved, or dealing with a lot of probably duplicate code, and still probably having ugly code.

not like there aren't a few ugly areas where there is a bit of hair (in my case, the code for handling the camera and user input is high on the list, essentially being implemented as a mess of settings over code that was originally written more for handling user-input for a 3D modeler, ...).

but, it works...

My editor uses the game engine. That way it's more or less WYSIWYG, so what you're working on in the editor will pretty much be what to expect in-game. It's actually part of the main engine project but abstracted enough it could probably be a separate application and just reference the engine DLL. I use wxWidgets for the interface.

The actual 'game code' is not really referenced at all by the editor (it is in its own DLL), just the renderer is used. Everything is data driven so game entity definitions are loaded in from the script system which is actually separate from the game code. (part of the engine).

It does make things a bit more difficult, as normally you would have certain objects in different data structures (static objects vs. dynamic objects for example), and since any model can be moved around you need to be able quickly update these in the background. We also have a fairly complex shadow system so when lights are moved around part of their shadow maps need to be quickly recalculated as well (VSM shadows).

This is easy enough for small scenes but as levels get bigger and more complex you need to be able to do this super quickly so the editing experience is impacted by poor performance or things popping everywhere.

There are lots of other things like being able to hot-reload assets in the engine, which means a little bit of extra work on the resource managers, but this gives the added advantage that you can update a texture or model even when in the game without having to open up the editor.

The editor code isn't the prettiest (I don't think it ever is...) and is bit of work to get going but definitely worth it in the end. It's good being able to open the game up to test things out and having it look exactly as expected.

Bonus screenshot...

Looks like I've started on the right track already, as I already have my engine code compiled into a DLL and the game project uses it. Where I do not know how to add editor features right now is for instance, rendering things like labels on objects or the rotate/scale/move gizmo, and rendering other debug shapes. I suppose they just need to be treated as special cases in the rendering engine, so they do not become affected by the lighting, for example. Sounds like the most popular option is to have the game and editor code as totally separate projects. Guess as a start, I'll keep both in one project but keep the editor code and game code in separate folders.