Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 CC Ricers   Members   -  Reputation: 638

Like
0Likes
Like

Posted 26 February 2013 - 09:32 PM

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, 26 February 2013 - 09:53 PM.

My development blog: Electronic Meteor

Sponsor:

#2 Khatharr   Crossbones+   -  Reputation: 3030

Like
4Likes
Like

Posted 26 February 2013 - 11:09 PM

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, 26 February 2013 - 11:11 PM.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#3 BornToCode   Members   -  Reputation: 935

Like
0Likes
Like

Posted 27 February 2013 - 01:55 AM

I had posted on this. It talks about exactly what you are trying to accomplish.

http://www.gamedev.net/topic/637682-basic-level-editor-question/



#4 Nercury   Crossbones+   -  Reputation: 770

Like
0Likes
Like

Posted 27 February 2013 - 02:00 AM

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, 27 February 2013 - 02:01 AM.


#5 nfactorial   Members   -  Reputation: 730

Like
0Likes
Like

Posted 27 February 2013 - 08:55 AM

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, 27 February 2013 - 08:57 AM.


#6 BCullis   Crossbones+   -  Reputation: 1813

Like
3Likes
Like

Posted 27 February 2013 - 11:40 AM

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.


Hazard Pay :: FPS/RTS in SharpDX
DeviantArt :: Because right-brain needs love too

#7 BGB   Crossbones+   -  Reputation: 1554

Like
1Likes
Like

Posted 01 March 2013 - 01:47 AM

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, 01 March 2013 - 01:48 AM.


#8 mightypigeon   Members   -  Reputation: 511

Like
1Likes
Like

Posted 01 March 2013 - 04:53 PM

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

 

62Vn3xh.jpg




#9 Vincent_M   Members   -  Reputation: 697

Like
1Likes
Like

Posted 01 March 2013 - 08:19 PM

@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, 01 March 2013 - 08:22 PM.


#10 CC Ricers   Members   -  Reputation: 638

Like
0Likes
Like

Posted 01 March 2013 - 08:33 PM

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.


My development blog: Electronic Meteor

#11 Vincent_M   Members   -  Reputation: 697

Like
0Likes
Like

Posted 01 March 2013 - 09:09 PM

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.

I'm sort of stuck there myself. I have this module in my code called HelpObjects, and it's just handles to global vertex and index buffers that are manipulated with Update() and Render() functions for drawing scene help objects such as lights and cameras. It literally took hours to hand-code my camera with the two film reels, frustum box, etc, but it works really nice now. The thing I'm stuck as is view scale. My camera, for example is about 5x5x2.5 units in volume, and that is massive in this game I'm working on where generic units are treated as meters. My player's ship model is like 2 units large long, and the 6 cameras that move with it to render its environment map are so large, you have to zoom the camera far out just to see that it's inside a bunch of camera gizmos.

 

What I'm going try is: setup an orthogonal camera, and do ray picking. If any gizmos are in view, I'll un-project their 3D coordinates to 2D screen-space coordinates and just draw my 3D gizmos in 2D ortho space like I would for sprites, but keep the rotation. The ortho view will always keep my camera the same size just like you'd see in 3DS Max, Maya, Blender, etc.

 

That might work, but the ortho-to-perspective might distort the way the rotation looks...

 

I have no editors for now, but any helper geometry (as you refer to as gizmos) are subclassed from my engine's generic "Object" class, and overrides the RenderHelpers() class to display themselves. So, when I set the RENDER_HELPERS flag to my scene, all helpers render. I also have flags for normals and bones for model instances that only get allocated, updated and rendered when those flags are set. ;)



#12 mightypigeon   Members   -  Reputation: 511

Like
0Likes
Like

Posted 02 March 2013 - 01:05 AM

@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

Back in the day I used C# for the interface with a small helper DLL written in C++ which was used to communicate with the engine using .NET interop.  It was a pain.

 

Lately I've been doing it the other way around, I was playing around with WPF and enjoyed it so now I have written a couple of dialogs for the editor using it and C#.  They export to a COM library.  After a lot of mucking around, the end result I can load up those WPF windows in native C++ using COM - no managed C++ or C++/CLI stuff at all, wanted to keep that away from the engine.  I ended up pulling an all-nighter to get it going, and I'm having nightmares just thinking about it again, but it's one of those things that once you do it the first time, it's there forever.  Definitely a learning experience!

 

 

 


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.

 

Rendering ad-hoc lines and labels and things like that is definitely worth implementing, even if you aren't writing an editor.  It can be a life saver down the track as you can quickly implement debug drawing in your game code (draw an AI's navigation path for example)

 

And speaking of gizmos, here is something I found that I found a while back: https://github.com/CedricGuillemet/LibGizmo

Works great.


Edited by mightypigeon, 02 March 2013 - 01:08 AM.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS