# Creating a level editor alongside the game, how to apply it?

This topic is 1911 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

Edited by CC Ricers

##### Share on other sites

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. Edited by Khatharr

##### Share on other sites

I think an editor has to know about the game, but not vice-versa. Ideally I would make an editor as an optional loadable wrapper around my game:

• Intercept handling input and use it for editor button actions, selecting and manipulating items in world.
• Make all game state related things dependent on single Game object somehow, and be able to use it to start(), pause(), restart() your game in-editor.

For example (some pseudo-code):

void EditorDraw() {

this->game->Draw(); // same as for game
DrawSelectedModels(this->selectedModels); // unique to editor
DrawEditorGUI(); // unique to editor

}

void EditorInput() {

if (!this->HandleEditorGuiInput()) { // if input does not belong to editor GUI
if (this->game->IsRunning()) { // game is "playing"
this->game->HandleInput(); // same as for real game
} else {
HandleWorldEditingInput(); // handle selecting, moving game objects
}
}

}

Edited by Nercury

##### Share on other sites

Caveat: "How close to the game code.." is actually a fairly perspective-dependant question. Many will say it should be very close, or that "the editor is the game!". Many will say not, there is no real 'true' answer only opinion.

Saying that, my own opinion is that "code wise" your editing application doesn't *need* to be that close at all, in fact I would say if it is close then you are significantly hamstringing yourself for no benefit. That doesn't mean it can't work, only that I think it's not the best way.

I would personally state that *data* wise, there should be a strong correlation between editor and game but not code wise. With the simple conclusion that a game is not an editor, and an editor is not a game. There are things both wish to do that are not of interest to the other and trying to get both to work in the same space will cause your final code to be a mash of both and the best of neither. Putting both together in the same code base narrows your options and forces you into design choices that are not based on what is best for your editor or game, but choices that don't break your editor or game.

Take, as a really simple example, a simple float. This represents the maximum 'strength' of something in the game, in the editor you would want associated metadata like an edit range, a display name, an edit type (numeric or slider, for example). The game doesn't need or want this meta-data, but it's there anyway because the editor needs it. You could then argue ways to provide that data that disappear when running the actual game (or even argue you don't want that data at all), but you're then already in the valley of "mash of both, best of none".

The code examples in the previous post (please don't take this personally, I'm just using as an example) ties the game & editor together in all kinds of ways I don't like (even if I were taking a "the editor is the game" approach).

My ultimate point is that you should be thinking much more along data-centric relations than code-centric, you can pile everything together if you like though that's not my personal preference (it can work) but I'd rather have an editor and a game with tight data driven relations. It's actually a big subject I could go on about for a long time unfortunately :s

n!

Edited by nfactorial

##### Share on other sites

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.

##### Share on other sites
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... Edited by cr88192

##### Share on other sites

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...

##### Share on other sites

@mightypigeon: Did you build that using .NET with C# or VB? When I was working in C++ and DirectX, I'd build mine using the winapi C classes, which is gross Win32 stuff from the 90's... Designing .NET applications are a breeze, but getting my C++ engine built on top of OpenGL to interact with .NET hasn't ever worked out for me yet.

EDIT: Woah, I asked before I looked up wxWidgets. You sir, answered by question before I even knew haha

Edited by Vincent_M

##### Share on other sites

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.

• 16
• 9
• 13
• 41
• 15