Compile and Run

I never really appreciated level editors, until I realized placing object by hand in Notepad was less than intuitive. So now most of my projects usually start off with a brand new level editor. I’ve written about 5-ish editors now, and it would be really nice if I could make one editor to rule them all, but alas this is not the case.

In writing the editor I had to make a critical decision: a tile-based grid system of levels, or a free arbitrary object position type system. Tile based levels were used all over games in the 90′s and are still used a lot today for handheld games, because they’re incredibly memory efficient and rendering efficient. It’s easy to get only the tiles that are in the screen’s view. But these kinds of games tend to look repetitive, and it takes a lot of work on the part of the artist to get a lot of variation with this system.

The alternative is to allow the artist to place objects wherever he wants, with rotation and scaling, and let the engine sort out how to optimize the memory usage. This works well for hardware accelerated rendering, because OpenGL and DirectX can draw rotated and scaled sprites as easily and quickly as non scaled or rotated ones. But such rendering abilities are not as common on handheld devices like cell phones. Although more and more devices are getting graphics chips with OpenGL, their texture memory is still pretty limited, so sprites need to be either small or repeated frequently for these devices.

Another problem with the arbitrary sprite system is that it is much more difficult to get only the sprites that are in the screen’s view. This can be optimized with a QuadTree, but you can still end up with significant overdraw (drawing more sprites than you need to). It’s a tradeoff that modern computers can deal with, but maybe not so much for small devices.

Fortunately I’m not making a game for small devices, so I don’t have to worry about it. In fact I think if worse comes to worse, my game will take up maybe 100 megabytes of texture memory (if I try REALLY hard to be inefficient), so that’s not a problem. And rendering is fast enough in PyGame, even if it is just a software blit. So I decided to go with the free sprite positioning editor.

Then I decided to make the editor in-engine, rather than writing it in a separate library. All of the rendering,input, etc is handled by Hydrogen (my engine) and PyGame, instead of a GUI library like wxPython, like I have previously tried. In the future this will probably be better, but right now all this means is that I have to write a dinky basic GUI for the editor. Currently it relies on key presses to set the mode (like setting sprites or drawing rectangles) and changing the tool (like rotating, scaling or moving). The most GUI-esque thing I wrote was a text input box that would pop up whenever you needed it, like when it wanted to know where to save or load the file. I may come back to that, but for now the editor is functional enough to get sprite and rectangle data to and from a file, along with an optional script name and properties for each thing (for example, the player starts at the entity whose name is “player”). Works well enough.

Early Editor Screenshot