Jump to content
  • Advertisement
Sign in to follow this  
Nicholas Kong

Unity How to create a level editor

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I never created a level editor before. This is an opportunity to branch out and exercise my programmer brain with menu options,newer buttons options, drop down boxes, etc.

 

Games I have done: I have created two games: one is a 2D game that uses double buffering, built with a simple health system displaying hearts and mini inventory system and mini item loot system. I never worked on anything complex: like 2D scrolling or Camera Tracking). I also created my first and only GUI game:Tic-Tac-Toe which is entirely button-based with logic. So from these experiences, I have implemented, simple AI movement, collision detection, basic gameplay and implementing basic animation).

 

I need some ideas about how to made a level editor given my experiences listed above. I can imagine the buttons,menu,radiobuttons and drop down boxes for activating options. 

 

Problem is but I cannot picture and figure out how do I implement the "area" where the user(artist or designer) can add items selected from the editor that can be displayed on screen so they can see the result created(could be a simple small map or a simple small level)?

 

I need advice on what general knowledge I still need to be able to made a simple level or map editor.

 

Edit: I have a few ideas about how to implement the area. It seems it would need to be represented using a 2D dimensional array of Image objects.

 

I looked at code of level editor other people work on the Internet but the ones I have seen have horrible coding style which led me to stray away from other people's code.

Edited by warnexus

Share this post


Link to post
Share on other sites
Advertisement

Having a 2D matrix of picture boxes could work for small levels, but if you're looking to make a huge tile map (like a RPG world map) then you will be dealing with a very large amount of controls and performance could suffer. And of course that method of composing the working area with controls won't work for a 3D game editor.

 

The working area of game editors (of any WYSIWYG editor, really) is usually "painted" in the window instead of being composed by controls. It allows you to draw pretty much anything you want in the client area without having to create a control for everything and managing their states. You didn't say what you're coding with, but if you're using MFC or the Win32 API, look for the WM_PAINT message, and if you're using Windows Forms, it's the OnPaint virtual method and the Paint events. Other libraries have similar "paint" events that you can handle and draw your stuff. If you're using Qt, I think it also has a control layout that helps creating 2D maps which makes the task even easier. I believe the only library where you would be composing the working area with control is WPF, but it's a very different UI library and it is entirely 3D accelerated so it can't really be compared.

Edited by Bearhugger

Share this post


Link to post
Share on other sites

Are you seeking to create a tilemap based level editor or polygonal one? (Also I assume you are aiming at a 2d game)

Both cases usually have different representation of the game world. With a tilemap, a 2D matrix specifying which tile to use at each (X,Y) is the most logical.

A polygonal map representation, at it's most naive form, will store an array of polygons. The representation of the game world greatly affects how you would implement

the level editing area in your editor

Edited by CableGuy

Share this post


Link to post
Share on other sites

Problem is but I cannot picture and figure out how do I implement the "area" where the user(artist or designer) can add items selected from the editor that can be displayed on screen so they can see the result created(could be a simple small map or a simple small level)?

 

Why don't you use the same routine used for displaying the actual level? From my experience, its easiest to just use the same rendering technique you'd draw your level ingame, and just add custom controlls for manipulating the level in the actual editor.

Share this post


Link to post
Share on other sites

Are you seeking to create a tilemap based level editor or polygonal one? (Also I assume you are aiming at a 2d game)

Both cases usually have different representation of the game world. With a tilemap, a 2D matrix specifying which tile to use at each (X,Y) is the most logical.

A polygonal map representation, at it's most naive form, will store an array of polygons. The representation of the game world greatly affects how you would implement

the level editing area in your editor

I am going for a 2D tilemap based level editor.

Share this post


Link to post
Share on other sites

Problem is but I cannot picture and figure out how do I implement the "area" where the user(artist or designer) can add items selected from the editor that can be displayed on screen so they can see the result created(could be a simple small map or a simple small level)?

 

Why don't you use the same routine used for displaying the actual level? From my experience, its easiest to just use the same rendering technique you'd draw your level ingame, and just add custom controlls for manipulating the level in the actual editor.

Yep, this is what I do. Software blitting to a buffer in memory, then copy it to the screen. It's a little slow, but modern computers have no problem with it for simple 2D games, and it minimizes the amount of hardware-specific code.

 

In the game, I use SDL to get access to the framebuffer, and copy my buffer over. In the editor, I use the FLTK library, which I'd highly recommend if you go C++ because it's nice and simple to set up and use, open source, cross-platform, and doesn't bloat your .exe size or require a big .dll in wondows/system32 or whatever. My final software buffer to screen display looks like this:

[source]    fl_draw_image(
        (const u8*)screen->pixels,
        dest.x,
        dest.y,
        destWidth,
        destHeight,
        sizeof(ColorType),
        screen->pitch * sizeof(ColorType));[/source]

Where ColorType is just a typedef for unsigned long (32 bit value). And that's done in a function that's called automatically whenever the map view control needs to be redrawn. That's the general way of coding window apps... you create a bunch of windows/controls, and they have functions that get called when they receive input or need to be drawn or whatever, and you do your stuff in those. They'll usually either be virtual functions inherited from a base window class that you override, or you call a library function and pass yours as a function pointer (basically virtual functions implemented manually in C). Some libraries have separate functions for each event, and some have a single function with an event type argument.

 

Be warned, level editors are often as much work as the actual game. Mine is a little bloated, about 16K lines at the moment, but last week I did a refactoring pass and didn't really find much to be improved on... there's just a lot to be done, editing the actual map data, layers, sprites, collision, the tileset window, where you can have several tilesets loaded per map, and edit the default collision type for each tile of the tileset, and then add undo functions for everything, and serializing data to be saved on disk...

 

Of course, you can make it a whole lot easier if you keep things simple. One layer, or at least a fixed number of layers, one tileset .bmp loaded at a time, single-level undo that only applies to drawing on the map, no messing with collision in the map editor... just make an array in the code somewhere that matches the order of tiles in your tileset and says whether each tile is solid or not.

 

Oh, and it's generally better to use a 1D array of width*height entries for the map, rather than a 2D array. Access tiles like map[y * width + x]

Easier to support variable map dimensions, easier to save to disk, most library functions expect things that way, such as the screen buffer in the code snipped above.

Share this post


Link to post
Share on other sites

Oh, and it's generally better to use a 1D array of width*height entries for the map, rather than a 2D array. Access tiles like map[y * width + x]
Easier to support variable map dimensions, easier to save to disk, most library functions expect things that way, such as the screen buffer in the code snipped above.

 

Interesting. I will try a one dimensional array implementation. 

Share this post


Link to post
Share on other sites

If you do plan on making your own map editor and not use one of the 3rd party map editors available (google "Tiled"), then you should try and write it so you can reuse much of the code in your game as well.  Meaning, have a common set of source files that both the game and the editor will use, and only have your main functionality (game versus editor) be separate source files.  it will save you time in the long run.

Share this post


Link to post
Share on other sites

If you do plan on making your own map editor and not use one of the 3rd party map editors available (google "Tiled"), then you should try and write it so you can reuse much of the code in your game as well.  Meaning, have a common set of source files that both the game and the editor will use, and only have your main functionality (game versus editor) be separate source files.  it will save you time in the long run.

Hi BeerNutts! Great point there! I totally forgot about re-using code! Thanks, it will save me a lot of time.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!