Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm trying to find useful information on creating game levels in a reasonably efficient way. Additionally, information in setting up a fairly painless way to edit this information would be handy (the closest I've come is some monstrosity in Flash; I would place the parts onto the stage, and run a script reading all the platforms, triggers and what have you, into an XML document).

Google hasn't been to terribly helpful in finding what I need (probably what terms I'm using as I'm not sure exactly how I would refer to this). I'm hoping there may be someone here who knows of a good solid article on handling the data for a level.

I've made a few attempts in previous projects (the latest being in Flash using XML), and I often run into issues with performance (in my case, I narrowed it down to having to many objects loaded, and started culling what was outside my view, was still slow though...).


To clarify a bit. I'm not afraid of investing time in developing tools. I don't have a specific game I am making this for so much as I am wanting to learn about the theory behind a level editor and the files it would generate to be used as a level. I'm looking to understand what goes on in a program and thus far have been un-successful in finding anything to help educate me on what makes such a system tick.

I am particularly interested in knowing how to make one that's 'good' rather than 'works'. I've already gotten something working in XML on my own, however it was poorly structured and excessively slow for relatively small levels. I am sure there are better ways to organize the information for loading and using on the screen, its more a matter of me being unsure what to use. I've heard talk of using binary space trees, quad or oct trees, however I haven't found much related to using them in a tool. (Most of what I have found is academic and more or less to abstract to make use of outside of theory)

share|improve this question
    
What kind of game are you trying to make? Depending on what kind of game it is you could create a class for each different level piece and use arrays to store, load, and edit them. I am not to familiar with XML but I believe it should be similar. Instead on having a script that reads your stage, have a script that reads the xml and then draws it to the stage. –  Sean May 27 '11 at 1:36
    
Well, not so much a specific game. I want to know how to make a good system when I need to. Right now the project I'm working on has all the tools provided, its more just stringing it all together. It just bothers me not knowing WHY or HOW it all works, and I want to get more into that. –  Yandere May 30 '11 at 22:34
add comment

3 Answers

up vote 3 down vote accepted

The Tools

What you use to create levels -- and assets, in general -- for your game will vary wildly depending on the type of game you are making and the technology you are making it with. Sometimes the most efficient thing to do is leverage tools that other people have written, such as the aforementioned mappy. If your levels are simplistic enough you might even be able to do them in something like MS Paint, assigning particular tile values to particular colors and basically just painting the image. You could even do layers like this (with different images) -- it's not elegant, but it works.

Of course this assumes you're building a 2D, tile-oriented game. When you get into the realm of 3D, there are far fewer decent generic level editors -- commercial games tend either build proprietary level construction tools, or use 3D modelling software and heavily massage the output via exporter scripts or build-time processes. So you, too, may need to roll your own.

In doing so its important to select a language and toolchain that is well-suited to the task (and that you know, or can learn reasonably quickly). C++, for example, probably is a poor choice for building a rich GUI experience due to the relative low-level nature of the language and even of the available third-party GUI APIs. Flash probably isn't the best choice because it's designed as a content presentation system first and foremost, and probably won't be ideal at overly complex interactions -- you may need to write a lot of code to make it do the things you want. The cost of this can be amortized a bit if your game is also in Flash and you're tying directly into code or functionality the game needs anyhow, though.

I build most of my tools in C# using Windows Forms or WPF (I'd recommend the former, as the latter has a much more painful relative learning curve and once you get beyond Happy Exampleville in WPF, things tend to get pear shaped real quick). You can usually throw something together in a matter of a few minutes and make it fairly robust within a few hours.

The advantage to choosing a tech platform different than your game is that you can choose one that lets you develop the tools far more quickly. The disadvantage is that the tools are disconnected from the game (for example, they don't share the same renderer so in-game previews aren't possible) unless you also spend the (nontrivial) effort to develop an interop layer for your game framework.

The Data

XML or JSON (I prefer the latter) is actually a reasonably good choice to start out, because they are both text-based, human-parsable data and you can iterate on the format quickly as you develop it. If you're not sure what exactly to put in the format at first, one way to approach the problem is to think of what information you'd like to have when rendering or interacting with the level in your gameplay logic code, and then make that what you store.

share|improve this answer
    
Good Answer :) I remember a certain game company that used Google SketchUp for the level designers to desing the levels, which they exported for the artists to then work upon. I also recommend C# for any tool creation, there is a lot of doc out there to help you get started. –  Jonathan Connell May 30 '11 at 7:49
    
Right. My concern is more about how the information for how a level is structured and stored, how to order it more efficiently. Ready made solutions won't do much to help me get behind the curtain and see how it all goes down. I'm not looking at a particular game genre here as much as theory and general patterns to watch for and relevant solutions. –  Yandere May 30 '11 at 22:28
add comment

For simple tiled games, mappy is quite useful and allows you to create multiple tile layers and export them into many different formats.

A quick Google gives a couple of other editors http://www.mapeditor.org/ and http://tilemapeditor.com/.

I think it's often a good idea to choose an editor that already exists, you can check whether the editor works for you and if the output data is good enough for your game engine.

You can them choose what suits you best before making your own editor, should you need it.

XML will generally produce a larger file format that will also take longer to load but is often used for its flexibility. If you are running into runtime problems though, maybe you should reconsider how your objects are defined.

For example you can create bigger blocks where possible, this will crete fewer objecs. You can also optimize some things at load time to 'cluster' tiles together.

share|improve this answer
    
I'm more interested in coding my own, partly for learning and partly to have any idea for when I need to roll a proper, fast system. Ready mades are convenient but when it comes time to cut loading times down I'd want to have an idea of what makes a map editor, and its levels tick. I found XML to be a poor choice for about the same reasons you stated. Its more or less plain text with markup, and leads to fairly long load times (with my original self made levels stored in XML, they took a good while considering they were relatively small) –  Yandere May 30 '11 at 22:22
1  
Well the good thing about making your own level editor is that you can save your files directly into a binary format, by copying the data from a structure directly from memory, and inversely when you are loading. This has the huge advantage of not being user-editable, has very fast saving and loading times (practically no other intervention is needed). The huge downside is that if your format changes, you will have to either continue supporting older versions at load-time or create a converter; this could be done maybe easily with XML. –  Jonathan Connell May 31 '11 at 7:08
    
I'm thinking perhaps it could be done that, the 'master' copy is kept in XML, and then you just pack it down to binary when its time to include it in a game. –  Yandere Jun 5 '11 at 17:50
1  
Yeah that's a sensible thing to do, I would recomment it, but I thought the main problem you were having was with the XML loading times? :P –  Jonathan Connell Jun 6 '11 at 12:19
    
I've been having issues with XML yes, but here I'm just trying to figure out or find some good info on creating a level editor tool, and things like how a level would be stored and loaded. I'm just trying to get into writing tools. I would find it hard to believe no one has written any articles or blogged their experiences making this kind of thing though! –  Yandere Jun 11 '11 at 5:07
show 1 more comment

Its not really an answer you want to hear but a lot of commercial games companies spend as much time on the tools as they do the game.

In a book I recently read the author stated that the team spent a year and a half on the tool such as level editors and graphic tools before they started the game engine.

Blizzard have a department of 30+ people full time developing tools for the programmers. Its a career choice in itself.

Try looking for "game resource editing tools" and derivatives of that but most of the ones out there that are any good output specific file types.

share|improve this answer
    
I wasn't looking for an easy way out, I was looking to code something that's more stable and efficient than my previous attempts. I'm hoping to find some references or articles useful to developing such a tool. –  Yandere May 30 '11 at 22:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.