Advanced Tileset management

Features
1

I use Aseprite primarily for gamedev, and I’d been looking forward to the tile editing features of 1.3. I’ve been doing my tile work in PyxelEdit and Photoshop, and Aseprite’s tilemap UX improves on a lot of the annoyances in both of those. Unfortunately, it looks like Aseprite has followed in the footsteps of Pyxel Edit when it comes to tileset management - tiles are second-class, tileset management is very basic.

For game development, it is the tileset itself which is the primary deliverable asset, the main canvas is only there for testing things out. Live tile updates are great, but are useful for only a small part of the tileset creation process. Tileset organization is very important, a well-organized tileset can save a level designer hours of time in selecting the tiles they want to place. Tilesets can also be works in progress for a long time, and it’s often beneficial to leave some space for future tiles, so that related tiles are in the same region of the tileset. On the other hand, the future tiles aren’t always known far ahead of time, so sometimes one has to move an entire region of the tileset to make room for a new group of tiles. These kinds of management tasks are technically possible in Aseprite, but they’re very annoying, as there’s no fixed width to the tileset and no way to pan around it, no way to move a bunch of tiles down without shifting other tiles around, etc.

With Aseprite and other software I’ve used, much more practical to make tileset management a separate step, done after testing the tiles - arrange them on a regular document along with other tiles. Layers can be used to group tiles for easy movement and adjustments. The downsides to this method are that there’s no way to ensure all tiles are included in the output and that every tile is only included once, arranging the tiles hours after you’ve drawn them can be difficult if you didn’t previously arrange them in the tileset in a way that makes their purpose clear, and that the testing document doesn’t benefit from this arrangement.

It’s also often helpful to use layers within tiles, while using the composite tile as a simple tile. For example, one may want to try a few styles of grass on top of a rocky sidescroller tileset. Each style of grass would be its own layer, and toggling the visibility of the layers would affect all instances of that tile currently in use. This is not possible in Aseprite, I would have to make separate tiles for all the grass and place them on separate tilemap layers, and toggle those, and then copy+paste the final grass onto the rocks base layer (can’t even Merge Down; since that’s not well-defined for Tilemaps where different tiles can be stacked together).

As you can see from these workflow descriptions, for a powerful tileset editor, the tileset itself needs to have some of the same features as the main document. Layers (internal to the tileset, with only the composite results being used in documents using that tileset), a definable size or at least some way to assign each tile an x,y position on the tileset without necessarily shifting over a bunch of other tiles, creating/leaving empty tiles as needed, some way to define groups of tiles so that they can be selected quickly to be moved (layers are only a stopgap measure for this, as moving the pixel data doesn’t update the tile indices, whereas proper tile arranging should).

An alternative to making tilesets a nearly full-fledged document and adding all of these features would be some tools to automate the management of tiles in a separate document. This would require documents to be able to share tilesets, so that changes propagate. It would also require some way to limit each non-empty tile to being used only once in the document. In such a limited document, Merge Down should become available since it would no longer be ambiguous. Unused tiles in the tileset should be highlighted, to help make sure every tile is included in the document. While this wouldn’t help with making convenient tilesets to use within Aseprite, it would make the exports much easier to arrange and maintain.

I don’t expect Aseprite to get any of these features, but I can dream :] I don’t think I’ve seen any editor that gave tileset management the attention it deserves, tileset creators have been arranging their tilesets manually for decades, wasting the time they could spend on adding more tiles.

2

I do think the tiles work nicely. I specially like the function where you can decide, if changes are applied to all tiles of a certain index or if a new tile is created for all changes etc.

It works quite well with unity in tandeem.

Changes to my tileset get instantly applied to unity, when i update it.
I haven’t yet used layers for my tiles. Because anything i would do there, i actually do in unity with tile rules or code. Like spawning cobwebs, dirt and stuff randomly. Saves alot of time of manually placing them.

I think i saw someone useing a fixed tileset size border or something similar in a pre-alpha/beta version of 1.3 . Haven’t gotten around to fiddling with all of the settings yet. You sure there’s nothing like that in yet?

3

I mentioned layers not for adding details, but iterating permanent changes to the tiles. It is common to use layers while creating new artwork as a sort of branching iteration system.

If there’s a fixed tileset size in Aseprite, I haven’t found it. I think placing the tiles onto a document is the only way to have a fixed tileset arrangement.

4

Ohh.

Okay that’s something which would be neat then.

Atm i iterate them roughly by pasteing my basic tile, then changeing stuff up on them. Then copying that and changeing stuff again. Adding stuff to the tileset.

Which kinda gets out of hand fast. Now i get what you meant.

5

Hi @eishiya,

Actually all tileset management tools were kicked to future versions because the v1.3 would be impossible to release this year in other way. As you can see in issue #977 the feature is huge, and there are still several items to implement. One of them is better tileset management.

The most important missing feature that was planned to implement (and might fix all the issues in your post) is the “tileset reference from an external file”. In this way we could use any sprite as a source of tiles. I didn’t think about the specific details yet, but this will allow to implement using tilemaps/multiple layers to create tilesets (metatiles).

There are some big problems (at the logic and UI level) to solve about this “using an external tileset”:

  1. How tileset indexes are assigned to tiles in the external sprite (e.g. just from top-left → bottom-right scan, and ignoring empty tiles)
  2. We should be able to specify if the tileset is read-only or not, and if it’s not, the modification in one tile (Manual mode only) from the tilemap will produce changes in the external tileset (but we cannot add new tiles from the tilemap, as it happens in Auto or Stack modes).
  3. What happen if we add a new tile in the “tileset document” or move tiles in this document, how can we detect these changes in the external sprites/tilemaps that are referencing this tileset? (it’s equivalent to a “global remap” between all sprites referencing the shared tileset)

So basically, there are plans to implement all this but still a lot of room for thinking about a good UX solution about how to share tilesets between files, and how to solve these changes in the tileset itself and how propagate those changes to all files that reference it.

4 Likes
6

I’m glad to hear that improvements to this are planned! I wouldn’t expect them for 1.3 since it IS huge, but there’s been such a dearth of improvements to tileset creation tools that I was afraid Aseprite would also settle for the basics.

–
As for dealing with external references, could the way Tiled does things perhaps be a good reference? Tilesets and Maps are separate files, but Tilesets can be embedded in Maps in those cases where you don’t need to share a Tileset between Maps. Embedded Tilesets can be exported, which turns them into an external Tileset that can be referenced by other Maps. A Map can reference multiple Tilesets, and tiles from any Tileset can be used together on any layer.

The Map does not store much, if any, data from the Tileset, it instead stores tile IDs (and some flags to track tile flips and rotation), and these are fetched from the Tileset for rendering and other tasks. Tiled watches for modifications to the Tileset document and file (including the image - which in Aseprite would be part of the Tileset), and when there is a change, the Map re-renders with the new data, which is always fetched from the Tileset anyway, rather than stored in the Map.

In Tiled, when you rearrange the tileset image, that’ll “break” your existing maps. Sometimes this is desirable! However, one of the planned features for Tiled is to provide a new way of defining tilesets such that even after being rearranged, tiles retain their IDs (i.e. tilesets would be more like spritesheets). I think that kind of approach would be good for Aseprite. By default when the tileset is first generated from an image, the indices would be assigned from top left to bottom right, but each Tile would actually be defined as a <tile ID, rect>, so if the tile is moved, its rect would change, but its tile ID would not, which means any references to it in Maps would still point to that tile.

1 Like