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)
Answer
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.
No comments:
Post a Comment