• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
tom_mai78101

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

25 posts in this topic

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?

0

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

 

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:

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites


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.

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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.

Why would your engine try to use lightmaps that don’t exist? If lightmaps available, use them, if not, render the base colors for objects. I don’t see the problem here.

 

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

Correction: It’s nice to have a modified version of the same renderer. IE if the library is built with the LSE_TOOLS macro defined certain features are added/modified.
You don’t have to waste time rewriting a renderer and the shipped games don’t have any extra cruft that might degrade their performance.

 

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.

Why would the editor be able to display any of the same graphics faster than the game engine?

 

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.

Point displays would simply be the same renderer with an LSE_TOOLS feature for displaying terrain as points.
In fact you don’t even need it to be just a feature of LSE_TOOLS builds; just have the editor set the terrain’s rendering states to draw points.

 

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.

Never use blanket statements such “HAS TO”.
I’ve just provided a very good alternative to the tools having their own renderers.

 

Also why spend time writing code for all the gui widgets you would need for an editor, and then ship them in the game?

Who said anything about making GUI widgets for the editor? The engine renders into a specific window inside QT or some other window-based application that forms your editor.

 

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.

This was implicit from the beginning and everyone does this. The fact that you even mentioned it indicates you don’t really understand what is meant by “use the renderer that already exists in your engine”.
Apparently you think that just because the game engine has a built-in GUI that you are for some reason obligated to use that in your tools.
No, you use the engine renderer to render all kinds of things, from the 3D view to the texture previewer to the shader previewer with all the 3D balls…
Not the GUI. That comes from the operating system.

 

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

Logical error #1: Why would I sell my engine but not the editor?
Logical error #2: I’m not selling the engine either. Guess I shouldn’t put time into that either.
Rebuttal: But you are selling the game which depends on the quality of the engine.
Logical error #3: It also depends on the quality of the tools. In fact tools are really what makes or breaks a studio.

 

so why spend the resources on it if you don't need to.

Unneeded resources, like making a second renderer?


You’ve not made a case in favor of making a second renderer, most likely because you seem not understand what it means to use the engine renderer.
Drawing terrain as points is a simple matter of changing the render state for terrain (and is unrelated to any shipped-product run-time costs because you simply don’t use that render state in the shipped product) and other features that would cause shipped-product run-time overhead (such as fallback code when materials, shaders, or lightmaps are missing) is a simple matter of some kind of tool-only macro you add to the same renderer.

Just because your engine has a GUI doesn’t mean you use it; you use the operating system’s GUI—of coooourse.
But guess what? You will need it when you make another tool for GUI-editing. Do you propose yet a third custom renderer? How many times do you propose we rewrite renderers?

And finally, why spend resources on a separate renderer if you don’t need to?


L. Spiro Edited by L. Spiro
0

Share this post


Link to post
Share on other sites

Who said anything about making GUI widgets for the editor? The engine renders into a specific window inside QT or some other window-based application that forms your editor.

It's good when your game needs in-game gui, for example, unreal engine 4 editor use the in-game GUI system.

Edited by Alundra
0

Share this post


Link to post
Share on other sites

It's good when your game needs in-game gui, for example, unreal engine 4 editor use the in-game GUI system.

Most (all?) games need an in-game GUI.
How extensive it is depends on the amount of money the company has.

For normal people, no widgets are added to the engine just for tool-side purposes. The operating system’s GUI is used.


L. Spiro
0

Share this post


Link to post
Share on other sites

Maybe a system like CEGUI can be used, what do you think of CEGUI L. Spiro ?

CEGUI was used in the game Torchlight and worked good.

0

Share this post


Link to post
Share on other sites


Never use blanket statements such “HAS TO”.
I’ve just provided a very good alternative to the tools having their own renderers.

 

Actually you have proved my point.

 

You have a flag in the renderer for tools mode, so a tools mode renderer is different to the games renderer. Therefore you have two renderers.

-2

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  
Followers 0