Ok, here are my personal thoughts on a level/graphics editor for tile-based systems:
So, there is no way for "the ultimate level editor" to be prepared for the designs of every game programmer. I don't see any other way for this to work, other than the editor saving everything using a format that's easy to understand and work with, so that the programmer himself can code converters to the desired format.
Yep, this is exactly how I think it should be done. Do not limit yourself to using a fixed format implemented for a single system. Instead, just handle maps with any possible configuration, and have your program save everything it in an easy understandable text-based format. (XML comes to mind) Then provide well-commented and documented source libraries for reading the files and examplifying conversion programs that will convert the data to binary formats suitable for different systems and/or game engines. No need to put any hardware restrictions in the program itself as the conversions tools can handle those.
The editor itself would have most of tUME's editing features, but be able to handle layers with transparency where each layer can different grid setting. For example, your main editing area (for levels or graphics) might have a room with 16x16 grid setting. To organize your tiles, you would have one with an 8x8 grid setting where you build composite 16x16 tiles from 8x8 tiles. You might also have another kind where you'd build structures of 16x16 similar to Metroid.
If I were to use the editor for making sprite object frames made of small 8x8-sprites, I would simply use a grid setting of 1x1 which would allow me to place my 8x8 tiles at any pixel position. Of course, in this case the editor would need some intuitive scheme for priorities since a tile could overlap another. (even if most NES designers made sure tiles wouldn't overlap, check out Megaman's face for example) A flag to specify if two tiles can occupy the same coordinate might also come in handy, since you might want to place two 8x8 sprites at the same coordinate when making sprite object frames, but probably want a placement to overwrite another when editing grid-based levels.
And if I would like to make some fancy cut-scenes, I might use one grid-based layer with either an 8x8 or a 16x16 grid setting and another one with a 1x1 grid setting. This way I could use BG for the main parts of a full-screen image and then fill in details with sprites. A method very often used in high-quality NES games, which most graphics programs and level editors lack any intuitive support for.
Of course, there should also be good support for animating inside inside the editor. Animation should not be limited to a fixed number of frames per single tile. For example, if I want to animate my sprite objects, I want to be able to specify a sequence of sprite object frames to reference for each animated frame, along with a time length. Nowadays, I use a bitmap program for animating my sprites, but that treats every frame as a pixel image, and for storage and flicker considerations, it'd be nice to be able to arrange a set of 8x8-sprites directly instead.
In the ideal case, animation should also include scrolling different layers. Maybe even scripted with some easily addable script language?
Last of all, it would be neat if there were some typical image editing tools avialable to edit the graphics data itself inside the editor. But that's kind of overkill and shouldn't be bothered with until the more important features are implemented.
I advise everyone to take a look at the tUME demos. (which are actually preferable to watch in DOSbox, since they run awfully slow in Windows for some reason) Especially if you have any plans on rolling your own editor.
).
