Gradualore wrote:
My level editor has a big uncompressed 2D grid of the smallest type of metatile, which is 2x2 nametable tiles.
But then I fail to see the usefulness of such an editor. If your editor doesn't know the dimensions of your structures, it will be harder to intentionally reuse data, which will cause the final data to expand quite quickly when you put it through the compressor plugin.
I currently use GIMP to draw my level maps, and by redefining the size of the grid I can reuse all types of metatiles as necessary. Then I run the final image through my game-specific level converter. I didn't feel like wasting a lot of time coding something with an user interface (specially considering it wouldn't be a generic tool), so I decided to use an existing image editor with grid-snapping and just code a small console application instead.
IMO, if you're gonna make a level editor, you should make it THE level editor. There are already too many simple grid editors out there, making yet another one would be a waste of time.
Quote:
So, if you tried something like the above, you could focus entirely on making a feature rich editor and not think too much about supporting any type of game engine.
But one of the features I miss the most in level editors is the option to use several levels of metatiles, and for an editor to allow that it has to know how each type of metatile is formed. Or at least allow block copies based on a easily configurable grid size, so it can be used like I use GIMP.
Another problem with the plugin approach is that a lot of people that code for the NES have no experience with other kinds of programming, so they might not like it very much, which means the tool fails at being useful. Actually even people with experience might not like having to code a bunch of stuff before they can do anything useful with a tool.