Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Do you have any tips to share on making/creating a level editor?


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
25 replies to this topic

#1 tom_mai78101   Members   -  Reputation: 577

Like
0Likes
Like

Posted 15 April 2014 - 05:54 AM

I'm right now creating my own level editor for a small project I'm working on while I'm on conscription service. I realized mid-development that creating a custom level editor isn't easy as it seems.

 

I thought you just draw tiles and export the map in 2 easy steps. Even though my project is very small, the most I can do is creating GUI for the level editor. I wasn't able to implement the editing features I had in mind.

 

Do you have any tips I can read about for creating a level editor? What methods have you done to overcome obstacles?



Sponsor:

#2 3Ddreamer   Crossbones+   -  Reputation: 3167

Like
0Likes
Like

Posted 15 April 2014 - 04:01 PM

Hi,

 

Nice editors like this typically require a team to work on them. Making editors is probably considered to be in the intermediate to advanced level of coding skill.  The issue with graphics editors of all types is that you will have to learn some low level coding concepts. Even if you are not using C++, getting a very thick book on C++ pipeline creation would be a must to point you in the right direction. Another thick book on your graphics API of your choice would be essential, too. Most other languages would be either very difficult to find the resources or simply not available.

 

This really is not in the area of game programming but game engine or pipeline programming. Why not use the level editor of an open source game engine and customize it to your liking?


Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#3 Satharis   Members   -  Reputation: 1267

Like
4Likes
Like

Posted 15 April 2014 - 09:07 PM

Editors are actually a sneaky kind of tool that most people go "huh" when they get to, or at least I did.

As 3Ddreamer said though the reality is that even something like a 2d tile map editor can be pretty involved, usually you're talking about at the least implementing something like basic OS gui controls(menu bars and such) that might require reading up on, or using a toolkit like QT or something. Once you have the GUI elements you still basically have to create a mini version of your games' full on rendering.

I.e. for a 2d game you'd have to draw all the tiles in your game to a context in the window, just like the regular game, although it might be a significantly stripped down version of course. Then you have to implement the actual editing, that usually means having your same map objects that you would in the normal game and making a bunch of click commands stuff that modify their in memory representation, which then changes how they're drawn onscreen too. After all that you still have to write the code to export it to the file type you want. For a lot of games the tools are literally half the coding project, yet they don't get nearly as much love.

Its one of those things you might want to look into an open source tool to use unless you have a serious need to make one, or want to learn how to make said tool by itself. Frankly for a lot of big games the editor basically becomes its own mini game of sorts, it may have scripting editors and custom entity placement and all kinds of magical tools to export specific data for that engine. It may be one monster tool or suite of tools that all the designers and artists and level designers are working with for a long time.

Edited by Satharis, 15 April 2014 - 09:09 PM.


#4 cardinal   Members   -  Reputation: 904

Like
2Likes
Like

Posted 16 April 2014 - 02:27 AM

I've built a couple level editors.

 

A 2D tile editor (just recently - still in development but it does most of what I need), and a full 3D level editor for my undergraduate project at university.

 

Level editors are a lot more complicated than they initially seem. You need a good chunk of the game's functionality in the editor itself along with a lot of extra functionality on top. Top of the line editors usually are fully integrated into the game and you can jump in and test your level almost seemlessly.

 

At the very least you need:

-GUI/Window code

-Other interface code (picking, multi-select, user friendly features like undo/redo for all of your operations)

-Rendering code (you need to render the textures you load and the tiles you've placed, and any other entities you've added)

-Asset management code (texture/tile/shape/entity loading/saving/adding/deleting/exporting)

-Simple camera code (you need to navigate your map somehow)

 

There are probably a lot of things I forgot to add here. For 2D games I like to be able to drop a character into the editor and move around testing the collision detection and layer transitions (i.e. going up stairs), this requires including more things into the editor.



#5 tom_mai78101   Members   -  Reputation: 577

Like
0Likes
Like

Posted 16 April 2014 - 03:08 AM

Thanks for the feedbacks. I do know that there are some listed above in all of your posts aren't in my custom level editor yet, at least it gives me an idea on what I should be doing, rather than what I could add to enhance the editing experience. I have also heard of games integrated into editors, such as Blizzard's games, so integration seems like a good advanced step.

Does picking a very-high level programming language helps with development of a custom level editor?

#6 DekuTree64   Members   -  Reputation: 986

Like
0Likes
Like

Posted 16 April 2014 - 04:05 AM

This is one of the reasons I like writing my own software rendering code for games, and only use SDL to display the final frame on the screen... I can just use the same rendering code in the editor, and dump it to the screen basically the same way.

 

My main advice is to watch out for feature creep. My editor has gotten a little excessively nice to use, but over 16K lines of code to wade through ohmy.png

 

I'm a big fan of C++ with smart pointers and RAII style programming for this kind of thing. FLTK is my current API of choice, but WxWidgets and Qt are good too.

 

I would recommend NOT to scrimp on undo/redo functionality, because the feeling of safety it provides makes working much more relaxing smile.png At least one level of undo/redo, but preferably multiple. My system is pretty elaborate, but I can describe it if you want.

 

Serialization is another big thing. That is, saving and loading from disk. I like to keep actual disk operations to a minimum, and do all my serializing in memory. For example, I have a Map class with lots of member variables, which is where all the actual editing happens, and a MapSaveData class, which is really just a single block of data, which can be created from a Map, or a Map can be created from it, or it can be written or read from disk with a single fwrite/fread.

 

IMO, the main reason to make your own map editor is the ability to place sprites and enter custom data for them akin to RPG Maker. If all you need is basic tilemap editing and placing of enemies in a side scroller or something, then it may not be wroth the trouble... although it will still be good learning experience if you've never done anything like it.


Edited by DekuTree64, 16 April 2014 - 04:06 AM.


#7 Aardvajk   Crossbones+   -  Reputation: 6239

Like
8Likes
Like

Posted 16 April 2014 - 05:20 AM

My tip is:

 

Bodge any old thing together for now that allows you to make levels for your game. Or even use something prewritten like Mappy. Hell, you can do tile based level editors in Excel with CSV output for all it matters.

 

If, in six months, you are still working on the same game, start to think about making a better level editor.

 

I've "wasted" so much of my life making complicated editors for games that I then lost interest in.

 

If you do decide to write an editor, the tip above about Undo/Redo is a very good one. If you don't plan Undo/Redo from the very beginning, it is almost impossible to go back and implement it later on.


Edited by Aardvajk, 16 April 2014 - 05:39 AM.


#8 jHaskell   Members   -  Reputation: 1109

Like
2Likes
Like

Posted 16 April 2014 - 06:08 AM

Would using an existing third party editor like Tiled be an option?  If your actual end goal is to create your game, then I don't see why not.  If your end goal is the editor itself, then probably not.



#9 Satharis   Members   -  Reputation: 1267

Like
3Likes
Like

Posted 16 April 2014 - 12:24 PM

My tip is:

 

Bodge any old thing together for now that allows you to make levels for your game. Or even use something prewritten like Mappy. Hell, you can do tile based level editors in Excel with CSV output for all it matters.

 

If, in six months, you are still working on the same game, start to think about making a better level editor.

 

I've "wasted" so much of my life making complicated editors for games that I then lost interest in.

 

If you do decide to write an editor, the tip above about Undo/Redo is a very good one. If you don't plan Undo/Redo from the very beginning, it is almost impossible to go back and implement it later on.

This is actually good advice as a generalization, I still fall into this trap myself all the time despite the fact I should know better. Sometimes its actually more efficient to make maps and stuff for your game with something completely stupid like a text editor. Why? Because the alternative takes -much- longer. Investing in a big 3d editing suite makes a lot more sense when you have 50 people working with you on a game for two or three years than it does for a school project.



#10 ferrous   Members   -  Reputation: 2146

Like
0Likes
Like

Posted 16 April 2014 - 12:43 PM

I'm going to echo Aardvajk, just whipping out a simple 2d tile based editor isn't that hard and a good exercise.  It won't be fully featured, but that's probably okay.  And the nice part is that you can keep building on it if you keep making 2d tile based games.  

 

Trying to build the editor into the game can also be a valid tactic.  If your game code already has access to a good gui, it can happen pretty smoothly.  And if it doesn't, well it gives you an excuse to build ui that might come in handy for the game as well.



#11 Norman Barrows   Crossbones+   -  Reputation: 2328

Like
2Likes
Like

Posted 17 April 2014 - 12:33 PM

from your original post, it sounds like your building a game (perhaps as a hobby), and are now working on a level editor.

 

just get something working as quickly and easily as possible. if possible, use third party tools and / or code to save work and time.

if you plan to release and include the editor, then you can worry about polishing it up.

 

a built in editor is nice. a stand alone generic editor in a linkable module is even nicer. you can just plop it into all your games, and they ALL have a built-in editor.

 

editors are basically just glorified paint programs (or 3d modeling programs for 3d level editors). draw the screen, left click = draw with current tool. click on buttons or menu picks or right click to change tools, save, etc.

 

 

 


Does picking a very-high level programming language helps with development of a custom level editor?
 
whatever can do the job, runs fast enough, and takes the least time to learn and implement. that's the language / tool to use. pretty much for all cases, and for all things related to game development. this of course does not factor money (costs) into the equation.

 

 

 


Even though my project is very small, the most I can do is creating GUI for the level editor. I wasn't able to implement the editing features I had in mind.

 

all you need is the ability to clear the screen, draw a tile, and draw text. the only GUI components most games need is a popup menu (doubles as message dialog), and a text entry dialog. everything else is usually some complex game specific custom screen (made simply by clearing the screen, drawing tiles, and drawing text). 

its nice when the gui components of a game have a look and feel custom designed for the game. 

so one of the first things i do is write menu() and getstring() routines for the game. the code is always the same, except for how they are displayed. that gives me ready to go gui components in the game for use with a built-in editor. my stand alone linkable 3d modeler and animation editor module uses generic menu() and getstring() routines from the low level game library used by the modeler and all the games.

 

 

 

 


at least it gives me an idea on what I should be doing, rather than what I could add to enhance the editing experience.

 

are you building games, or editors?  Better a cool game with a rough editor than a rough game with a cool editor.

 

i heard of one guy who spent 3 years building the game engine and world editor, and then used the editor one time, for about 3 days, to build the game world.


Edited by Norman Barrows, 17 April 2014 - 12:37 PM.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

 

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

 

 


#12 tom_mai78101   Members   -  Reputation: 577

Like
0Likes
Like

Posted 17 April 2014 - 04:49 PM

are you building games, or editors?  Better a cool game with a rough editor than a rough game with a cool editor.


A rough editor of a rough game, this is my current situation.

#13 L. Spiro   Crossbones+   -  Reputation: 14310

Like
2Likes
Like

Posted 17 April 2014 - 07:44 PM

Once you have the GUI elements you still basically have to create a mini version of your games' full on rendering.

I.e. for a 2d game you'd have to draw all the tiles in your game to a context in the window, just like the regular game, although it might be a significantly stripped down version of course.

A game engine should compile to a library or DLL. The actual rendering system of the engine should be used in both the game and the editor.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#14 Alundra   Members   -  Reputation: 928

Like
0Likes
Like

Posted 17 April 2014 - 08:46 PM


A game engine should compile to a library or DLL. The actual rendering system of the engine should be used in both the game and the editor.

L. Spiro catches a good one, this is the most important part because you want to factor the most you can.

After that, you have two options : using QT or use your gui system like unreal engine 4.

If you don't have a gui system or just have basic one go for QT, you will win time.

If you go with QT, you will have to link widget with your engine in a reusable way.

A good way to do that is to have a RenderWindow class with the window handle inside it that will be linked on the QT widget.

Why reusable way ? Because for a particle editor or other preview window you will need to use it.

You will always think "reusable" to factor the most you can, that means write widget class.

QT has all you need to make your editor working but you will certainly have to write custom widget to be artist friendly.

Here a screenshot of my WIP editor to give you idea of what you can have with QT : http://uppix.com/f-DreamEditor12535094cf00161a20.png

It's important to note that with QT you don't need a lot of code to have result and cross platform.


Edited by Alundra, 17 April 2014 - 09:24 PM.


#15 tom_mai78101   Members   -  Reputation: 577

Like
0Likes
Like

Posted 17 April 2014 - 11:12 PM

 

Once you have the GUI elements you still basically have to create a mini version of your games' full on rendering.

I.e. for a 2d game you'd have to draw all the tiles in your game to a context in the window, just like the regular game, although it might be a significantly stripped down version of course.

A game engine should compile to a library or DLL. The actual rendering system of the engine should be used in both the game and the editor.


L. Spiro

 

 

Oh no! I wrote two different engines using the same method of graphics rendering for my editor and game. Is it acceptable?    D:



#16 L. Spiro   Crossbones+   -  Reputation: 14310

Like
0Likes
Like

Posted 17 April 2014 - 11:32 PM

Is it acceptable?

Throw away all code you have ever written in your entire life and start again from scratch.

That depends on what the level of acceptable is.  In general, not even a little bit.

But the damage is done.  Never do it again.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#17 Stainless   Members   -  Reputation: 1070

Like
3Likes
Like

Posted 18 April 2014 - 01:08 AM

Rubbish. I can think of hundreds of reasons NOT to use the same renderer in the editor as in the game.

 

For example how can you write a tool to generate light maps if your renderer requires a light map? 

 

You would have a blank screen to work with until the light map is generated.

 

It's nice to be able to use the same renderer, but you have to have another renderer to use when you are working.

 

Load in a million point terrain mesh and try to display it with your game renderer, chunk your machine, get less than 1fps and try to work with it. Display it using a simple point display, let the editor convert it into chunks and build display lists etc. Then render it with the final renderer.

 

The editor has to be able to display whatever elements you need in the final game and generate the elements the final renderer needs to be able to operate quickly, therefore it HAS TO have it's own renderer.

 

Also why spend time writing code for all the gui widgets you would need for an editor, and then ship them in the game? I drop an OpenGL or XNA window into a windows form application and then use all the toys windows gives me for free. Saving me massive amounts of time writing folder browser dialogs, file dialogs, etc.etc.etc.

 

The editor is not a product you are going to sell, so why spend the resources on it if you don't need to.


Edited by Stainless, 18 April 2014 - 01:16 AM.


#18 jbadams   Senior Staff   -  Reputation: 19406

Like
0Likes
Like

Posted 18 April 2014 - 01:13 AM


Oh no! I wrote two different engines using the same method of graphics rendering for my editor and game. Is it acceptable?

It's not ideal, because you've almost certainly spent more time on it than you needed to, and because you now have two sets of code to maintain; any additional features you add will need to be added to both sets of code, and any bug-fixes will need to be applied to both sets of code.  This means it takes more time to add new features, and increases the chance that you'll introduce small errors into one set of code.

 

However, I wouldn't consider this such an extreme problem as L. Spiro seems to be suggesting as long as it works for you, and in some (often simpler) cases it may even be useful to you if you want to display the graphics in the game and editor in different ways.



#19 tom_mai78101   Members   -  Reputation: 577

Like
1Likes
Like

Posted 18 April 2014 - 03:06 AM

Understood. smile.png

 

I got my own custom level editor finished, with the main features, "New", "Save", and "Open", done. Even though I started working on the editor with a different set of rendering pipeline down the road, I used what I learned from here to create it. biggrin.png  It's a wonderful experience, and I'll probably share it on the Developer's Journal.



#20 Hodgman   Moderators   -  Reputation: 31920

Like
1Likes
Like

Posted 18 April 2014 - 04:40 AM

Sony recently open sourced a tonne of code for making editors here: https://github.com/SonyWWS/ATF

As for language, at the last 4 jobs I've had, it's been C++ for the engine and C# (mostly) for the tools because productivity is generally more important than optimization for tools.




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