Sign in to follow this  
Sean_Seanston

Level Editor Interface

Recommended Posts

I want to make a level editor for a 2D scrolling shooter I'm making. I'm pretty sure I understand the concept fairly well but I'm sort of lost as to how to implement the interface. I've seen a lot of tile editors that are seemingly written using the WinAPI or something similar. Since I've never really done anything substantial in WinAPI before I'm hesitant to start learning that halfway through doing my DirectX 2D scroller. So considering the limited requirements I have, would it seem practical to just cobble together a crude UI using rectangle graphics for buttons and implement the interaction with the buttons and whatnot myself from scratch? Of course, I might end up having to start over halfway through because I forgot something and presumably using a "proper" system like WinAPI or whatever would be a lot more straightforward and malleable if I knew how to use it. The kind of interface I was thinking about would be something like the one here: http://photos1.blogger.com/blogger/2754/2691/1600/mapedit.png. Is WinAPI a good choice for something like that or is that possibly using something else? Anyone have a link to some tutorials that focus on interfaces of that style? I just need something that preferably most easily lets me make an editor that can load up tiles, let me click them to select, click to place etc. etc.

Share this post


Link to post
Share on other sites
In general, creating your own UI system is not desirable. There's a whole lot of things you'd need to implement, and they've all been implemented (and tested) already in other UI toolkits. Things like buttons can be simple, but then you start throwing in scroll bars, lists, splitters, tabs, menus....and things get complicated really quickly.

That screenshot you posted appears to be using WinForms, which is part of the .NET Framework. This means it was most likely written in C#. What he has there is MenuStrip (the main menu at the top), a StatusStrip (the status bar at the bottom), vertical and horizontal ScrollBar's, a bunch of RadioButton's, a GroupBox surrounding the RadioButton's, and what is probably a custom Control where the tile map is actually rendered.

WinForms is really nice in that it's pretty easy to use, and Visual Studio has a great visual designer which lets you set up the layout and handle events. The problem is that since it sounds like your rendering code is written in native C++, you would have to handle interfacing native code with managed code. This can sometimes be easy, but usually isn't trivial.

Without WinForms, you could use the raw Windows API but I can guarantee you it won't be a fun experience. If you don't already know how windows and controls work at a low level, you'll have to read up on all of that. Then you'll have to write a whole lot of tedious code for setting up and handling the controls at runtime. You're almost always better off using some sort of toolkit that wraps this stuff for you.

You might want to consider a C++ UI framework like WxWidgets or Qt. I haven't used them myself, but I've heard good things about them. Those would spare you from having to directly work with the WinAPI stuff, but would let you stay with native code.

Share this post


Link to post
Share on other sites
Quote:
Original post by MJP
In general, creating your own UI system is not desirable. There's a whole lot of things you'd need to implement, and they've all been implemented (and tested) already in other UI toolkits. Things like buttons can be simple, but then you start throwing in scroll bars, lists, splitters, tabs, menus....and things get complicated really quickly.


Yeah, I figured something to that effect.

Quote:
Original post by MJPYou might want to consider a C++ UI framework like WxWidgets or Qt. I haven't used them myself, but I've heard good things about them. Those would spare you from having to directly work with the WinAPI stuff, but would let you stay with native code.


Cool... that sounds like probably the best solution.

I've heard of wxWidgets before... it was suggested for us to use for an assignment in college and I was going to use it but didn't in the end. I think I had some trouble in the small amount of time I tried getting it to work but I'll have to give it a proper look now. Thanks.

Share this post


Link to post
Share on other sites
If all you need to do is draw a 1 or 2 layer tile map and place down enemies (that have pre-defined behaviors, no parameters to edit), then I'd probably go with an in-game editor. It's nice to have immediate and interactive results instead of having to work in the editor, save, run the game, close the game, repeat. And the UI controls might come in handy for making menus for the game itself too.

But if you think you'll need text entry with copy/paste/undo, or drop-down boxes and other more complex controls, then it would probably be better to go with a separate editor using a UI framework. I used FLTK on my last editor, but wxWidgets is probably better. Both are a royal pain to get working, since you have to compile them yourself. I kind of like the old C-style WinAPI too. It's easy to get working and straightforward to use, but the documentation isn't great, and it tends to take a lot more code to do something than wx or FLTK.

Share this post


Link to post
Share on other sites
[quote]Original post by DekuTree64
If all you need to do is draw a 1 or 2 layer tile map and place down enemies (that have pre-defined behaviors, no parameters to edit), then I'd probably go with an in-game editor. It's nice to have immediate and interactive results instead of having to work in the editor, save, run the game, close the game, repeat. And the UI controls might come in handy for making menus for the game itself too./quote]

That's probably more or less what I need to do. I'll need to place map tiles and then place enemies and that's basically it, though for saving levels as a certain file I suppose I'd need text entry.

What exactly do you have in mind by an in-game editor? Wouldn't that still require you to create a whole set of GUI elements like buttons and whatnot? A scrollbar too since the level wouldn't be big enough for 1 screen. I was also looking at that program Tiled that I've heard a bit about before... might not be a bad choice just to get the game done more quickly. Has anyone here used it? Just kind of wondering how flexible it is... does it just save the maps in its own way or can you have it save files as xml and be formatted in a certain way?

Share this post


Link to post
Share on other sites
Quote:
Original post by Sean_SeanstonWhat exactly do you have in mind by an in-game editor? Wouldn't that still require you to create a whole set of GUI elements like buttons and whatnot?

Yeah, you'd still need some buttons and things, but buttons are pretty easy to make.

I was imagining moving the player around rather than using a scrollbar. So you can just go into "edit mode" wherever you are in the game, place down some enemies, maybe move the player back a bit, and start back up again. Probably reset all the enemies to their starting positions whenever you go into edit mode, because it could get confusing if you could modify enemies that had moved from their starting positions.

Have some tool buttons to click on, maybe with hotkeys too. Tile edit, sprite move, enemy place. And buttons to show/hide the tileset and enemy selection windows. Those windows might need scrollbars, or you could just have row up/down and page up/down buttons to click.

In sprite move mode, click on the player and drag to scroll around the map quickly, rather than having to "unpause" the game and wait for the normal game-speed movement.

You don't really need any filename entry. Just have a single project file for the game, with a hard-coded filename. Copy and rename the project file from windows explorer to make backups.

You'd also need some way to make new maps though, and edit the dimensions of a map. But text/number entry without undo/redo/cursor isn't too hard (that is, always add or remove characters at the end of the string, no moving the cursor back without backspacing characters).

Hey, maybe you could make a separate text file for map names, dimensions, and level order, that you could edit from notepad. To make a new map, just add an entry in that file, and the game's level select screen could display it. And when you go to load the level in the game, if it doesn't exist in the project data file yet, just make a blank map with the dimensions from the text file.

And when loading a level, check the dimensions from the text file versus the dimensions in the project data file to see if you need to resize the map.

Share this post


Link to post
Share on other sites
What are the issues when using a WinForms project together with native C++? Say you have a static library that is your games "back end", can your Winforms project not use those classes? (Sorry, know nothing about managed C++, wondering whether this is worth investigating.)

An alternative would be to use a game GUI library for both the editor and the game. I don't know of many however, one example is CEGUI: http://www.cegui.org.uk/wiki/index.php/Main_Page

Share this post


Link to post
Share on other sites
I don't know if anyone has already mentioned this, but have you thought of taking someone else's (open source) editor and adapting it to your needs? Or even one that isn't open source and just writing a loader to convert the levels created into a format that is compatible with your game? I can say from experience that you can easily get sucked into going overboard with level editors and forget that, once upon a time, you were making a game. I'm presuming there would be a few level editors out there, and if not, most people who have created one probably wouldn't mind giving you the code for it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Somnia
What are the issues when using a WinForms project together with native C++? Say you have a static library that is your games "back end", can your Winforms project not use those classes? (Sorry, know nothing about managed C++, wondering whether this is worth investigating.)


If you're writing the editor in a purely managed language like C#, then that managed code can't consume or interact with the classes defined in your native C++ library. The only thing you can do with pure managed code is call free functions that are declared as extern "C", and that are exported from a DLL.

C++/CLI is a bit different (Managed C++ is dead by the way, C++/CLI is the replacement) in that it can freely interact with both managed and native code. Many people use it to write managed wrappers around classes in native libraries, rather than writing actual managed applications with it. This is because it can be rather awkward to use, and can have a lot of pitfalls.

Share this post


Link to post
Share on other sites
Quote:
Original post by MJP
Managed C++ is dead by the way, C++/CLI is the replacement

You've also mentioned "pure managed code". Could you please explain the differences between the three? Also, what's a good resource to get started with the last approach you outlined?

Almost off-topic, I'm close to finishing my own editor (I'm calling it the Angel3D Editor) to a usable "or rather showable" state next couple of weeks. It uses a thin library above the win32 API that I put together while working on it. I'll make this library available for public use then, along with an article or two on how to use it to write an editor.. not that I'm expecting you to wait though, just felt like shamelessly pimping it :D

Share this post


Link to post
Share on other sites
Quote:
Original post by DekuTree64
I was imagining moving the player around rather than using a scrollbar. So you can just go into "edit mode" wherever you are in the game, place down some enemies, maybe move the player back a bit, and start back up again. Probably reset all the enemies to their starting positions whenever you go into edit mode, because it could get confusing if you could modify enemies that had moved from their starting positions.


Ya... some ideas there I hadn't thought of. Reminds me of the debug mode in Sonic.

I think I might go with wxWidgets.

I've a question though... when I'm making a level editor and drawing the tile set or whatever, do I use the image-related stuff in the GUI API itself or Direct3D/OpenGL/whatever? I mean, do GUI APIs tend to have all you need for image manipulation like drawing certain sections of an image? Bah, I'm so confused with GUIs -_-

Share this post


Link to post
Share on other sites
Quote:
Original post by Sean_Seanston
I've a question though... when I'm making a level editor and drawing the tile set or whatever, do I use the image-related stuff in the GUI API itself or Direct3D/OpenGL/whatever? I mean, do GUI APIs tend to have all you need for image manipulation like drawing certain sections of an image? Bah, I'm so confused with GUIs -_-


They do, but you'll probably want to draw your actual maps and tiles using the same rendering engine you're using for the game. This ensures things look the same in both your editor and in your game.

Share this post


Link to post
Share on other sites
Quote:
Original post by hikikomori-san
You've also mentioned "pure managed code". Could you please explain the differences between the three? Also, what's a good resource to get started with the last approach you outlined?


By that I mean code written in a language that will only produced managed assemblies (C#, VB.NET, etc.). C++/CLI can produce assemblies that contain a mix of native and managed code, while regular C++ can only produce executables that contain native machine code.

For starters, there's some information on MSDN such as this, this, and this. I'm sure there's much more to be found on Google.

Share this post


Link to post
Share on other sites
Quote:
Original post by MJP
They do, but you'll probably want to draw your actual maps and tiles using the same rendering engine you're using for the game. This ensures things look the same in both your editor and in your game.


I see...

That sounds kind of complicated. Would the actual window then be made using Direct3D, for example, or the GUI API?

How might the 2 APIs be combined? I suppose it's mostly the window creation that I'm worrying about... since DirectX needs so much Windows API stuff and presumably any GUI API you look at is going to have a way to create its own window.

Are there any links you know of about something to this effect? I wouldn't really know where to start TBH.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sean_Seanston
I see...

That sounds kind of complicated. Would the actual window then be made using Direct3D, for example, or the GUI API?

How might the 2 APIs be combined? I suppose it's mostly the window creation that I'm worrying about... since DirectX needs so much Windows API stuff and presumably any GUI API you look at is going to have a way to create its own window.

Are there any links you know of about something to this effect? I wouldn't really know where to start TBH.


It's a lot less complicated than you think it is. [smile]

Remember that Direct3D provides no means of creating a window. When you create a device you say "hey, here's a handle to a window that you should draw to" and then Direct3D draws to its client area. It doesn't care where that window came from or how you made it, as long as you have its window handle. It also won't mess with that window at all as long as you don't go fullscreen.

So typically what you'll do is you'll have your main window, you'll have your stuff like your menu and status bar and maybe a a splitter with a toolbar on the side. Then you'll have a large control (child window) embedded in the main window that you tell D3D to draw to.

Share this post


Link to post
Share on other sites
Quote:
Original post by MJP
Remember that Direct3D provides no means of creating a window. When you create a device you say "hey, here's a handle to a window that you should draw to" and then Direct3D draws to its client area. It doesn't care where that window came from or how you made it, as long as you have its window handle. It also won't mess with that window at all as long as you don't go fullscreen.


Oh yeah... suppose I never really looked too deeply at the connection between Win API and DirectX since Win API wrecked my head enough when I was originally trying to learn it :p

So should it be just as easy with something like wxWidgets as using the actual Win API? Or do most GUI APIs actually just provide a wrapper around the Win API window system anyway? Just curious since you'd obviously need a window handle of the same kind as the Win API one to pass to Direct3D.

Quote:
Original post by MJP
So typically what you'll do is you'll have your main window, you'll have your stuff like your menu and status bar and maybe a a splitter with a toolbar on the side. Then you'll have a large control (child window) embedded in the main window that you tell D3D to draw to.


So you just pass the window handle of the child window to Direct3D... nice.

Should be quite easy then to set up an array of tiles on the side and have it let you paint them onto the Direct3D window once you have a grasp of WinAPI, right?

Sweet, thanks. Though I might go with the in-game editor this time... I was thinking about that today. More complicated things in future will probably need WinAPI or something to be practical though.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sean_Seanston
So should it be just as easy with something like wxWidgets as using the actual Win API? Or do most GUI APIs actually just provide a wrapper around the Win API window system anyway? Just curious since you'd obviously need a window handle of the same kind as the Win API one to pass to Direct3D.

Yes, it should be pretty easy. There are ways to access the window handle in MFC, Qt, wxWidgets, and most likely all of the other native windowing toolkits. If you set up your engine to have an abstract render window interface that only requires a handle to render to, then it becomes trivial to support multiple windowing toolkits since you just create a new render window subclass that knows how to get the handle from the appropriate widget/window control.

Share this post


Link to post
Share on other sites
I use wxWidgets, but I've been looking at win32++ and it looks pretty cool. You'd probably still have to learn a little regular win32, but not the hard parts.

wxWidgets is tricky to setup until you understand its build system, which is designed to allow you to keep multiple build configurations of it around.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this