Starting from scratch, the typical tile map development process looks like this:
- Create (more) tiles
- (Re)Sort, (re)categorize, and (re)arrange tiles into a usable palette
- Map the old tiles to the new tiles
- Place tiles on the map
- Realize you need more tiles, and start back at 1 again, or realize you are done with your map
5 is a user decision, not constrained by the software. 4 is what Tiled already does. 1 is arguably better done by an independent raster art program. But I think Tiled needs to support 2 and 3 Currently, if you hit 5 and have to go back to 1 and don’t bother with 2, your tiles are in a difficult arrangement to use. Likewise, if you hit 5 and have to go back to 1 and do bother with 2, your tiles will be in a convenient arrangement to use, but the tile associations of your tile map are destroyed, and you need to redo your entire map. These are common circumstances when working with incomplete, unfinished, in-progress tilesets.
When the tile map artist gets tiles from the tile artist, even if it’s himself, they aren’t necessarily usefully sorted, categorized, or arranged. If new tiles have to be added later, they may well be completely unsorted; in this case, the user needs to be able to sort the tile palette after-the-fact without regard to the original art, and without destroying the associations of the tile map with the existing tiles. If the tile artist did re-sort the tiles, the user needs to be able to map the old tileset to the new one. This would also be helpful if the art in most or all of the tiles was substantially changed while that resorting took place; the reassociations would not be computationally probable in many cases.
To do this, there need to be 3 separate art managing files:
- The imported tile file(s)
- The palette file, which keeps the user’s user interface rearrangement of the tiles
- The map’s tile image file, which the tile map references for all the tiles that are being worked with
How this would play out is that the user imports some tile images, and a tile image file is created from those sources. The palette file is created from references to that tile image file, and the palette file can then be rearranged by dragging tiles around, increasing the dimensions and shape of the palette, and so on, independent of the original tile images or the tile image file. Eventually, the end-user may want to rebuild the tile image file and the maps that use it; this should be as simple as rearranging the palette file as preferred, clicking a button, and letting the palette file’s current arrangement determine the tile image file’s tile positions and the tile map’s associations. Mapping from an old set of imported tile images to a revised, rearranged set will be as simple as letting the user make a palette from the old tile images in a way that matches the new tile images, and updating the map’s tile image file with the new images and updating the tile map with the new associations.
The final output is the same; an image file full of tiles, and a tile map that references those tiles in that image. But we get lots of usability in return.