Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tilemap editor feature #977

Open
dacap opened this issue Feb 24, 2016 · 76 comments
Open

Tilemap editor feature #977

dacap opened this issue Feb 24, 2016 · 76 comments
Assignees
Milestone

Comments

@dacap
Copy link
Member

@dacap dacap commented Feb 24, 2016

UI design and main goals of the tilemap feature:

  • Everything related to tilemaps must be hidden until we create a new tilemap layer using a new Layer > New Tilemap Layer menu option (in this way we avoid bloating the UI with tilemap stuff)
  • As tilemaps will be a kind of layer, we'll be able to have several tilemaps in one sprite
  • One tilemap layer will have its own tileset, a tileset will have its own tile specs (grid size, etc.), but the tileset could be linked from an external file (with possibilities to embed the external tileset content inside the tilemap optionally)
  • Each cel in a tilemap layer will be a new kind of image where each pixels reference a tile:
    • Each pixel in the tilemap image will be a 32-bit value with some bits to reference the tile in the tileset and other bits to specify flip and rotation
  • When we create a new tilemap layer, it should behave almost exactly like a regular layer, and tiles should be handled transparently/automatically by default (so even if an user creates a new tilemap layer by mistake, she/he shouldn't see a different behavior from a default layer)
  • When the active layer is a tilemap layer, a new set of buttons should be displayed in the color bar, those buttons should allow:
    • Changing between the palette view <-> tiles view (keyboard shortcut: Shift+Tab)
    • Changing between the automatic mode of handling tiles
    • Do some special operations to tiles, which should match future operations with the palette too. E.g.
  • When a sprite contains tilemap layers, the sprite properties dialog should show a section of "tilesets":
    • We should be able to reorder tilesets
    • We should be able to add new tilesets
  • Possibility to link external tilesets
    • Persistence (.aseprite information)
    • Auto-sync tileset from external file when the original is modified
    • UI to select external tilesets
    • Special import/external/linked tileset options, e.g. from grids, from frames, from layers, from "Import Sprite Sheet", etc.
  • Drawing tile pixels with three modes: Manual (modify the tiles, don't create new tiles), Auto (create/remove existent tiles automatically), Stack (add new tiles when they are modified, keep the existent tiles unmodified)
  • Drawing tools with tiles
    • Paint with tiles (still buggy)
    • Eyedropper for tiles
    • Selecting tools with tiles
    • Fill, Stroke, and Clear commands for tiles
    • Copy and paste tiles

Special Features

Possible advanced features:

  • Flip/Rotation
  • Overlapped tiles (isometric tiles etc., hexagonal tiles, etc.)
  • Palette shifting (e.g. some bits to shift the colors of a tile in the color palette)
  • Metatiles (hierarchy of tiles, where the tiles of one tileset is another tilemap with smaller tiles)

Persistence

  • Create a new chunk in .aseprite format to save tilesets
  • Each tileset should contain specs (tile width/height, type of tiles, etc.) and source of tiles (e.g. for linked tilesets between files).
  • Save/load layer tilemaps and their cels
  • Save only differences between cels in tilemap layers
  • Save (and load?) TMX files
  • Convert grid settings into tileset specs and save then in the .aseprite file if it's possible (#688), this might enable isometric grids too (#720)

Integration

  • Check the integration with Tiled mode

Ideas, issues to review, and old ideas about the implementation

Review

UI Design

Here I'll be updating this issue to talk about the design of this feature. Some questions to solve:

  • How we create a new tilemap? (File > New > Advanced > a new tab for tilemaps appears? or we start creating the sprite sheet?)
  • Should be the tilemap a switcheable mode like "Tiled Mode"? I don't think so, we could be creating several tilemaps from the same tileset/sprite sheet. So it looks like a tilemap is just a way to say "we are going to create a map feeding tiles from these sprite sheets"

The general idea is this:

  • the color bar should be transformed into a tileset where we can pick tiles
  • the sprite editor is the tilemap editor where we can put/draw/pick(eyedropper) tiles

Internal tasks

Tasks to do (this list is not complete):

  • create a new kind of image that can reference different tiles/doc::Image on each area and with different rotation/flipping. (doc::TiledImage?)
  • create a generic iterator for any kind of image (current doc::Image, and this new tiled image)
  • different parts of code will use the doc::Image iterators (e.g. file format encoders/decoders) and other areas should use this generic iterator (e.g. sprite Editor widget).
  • get tileset from a tilemap (from this thread)

An alternative implementation would be to edit images as a regular image, and after each "tool loop", we update/sync the tilemap/tileset depending on these modifications. Pros: easier to implement (there is no new kind of image), Cons: it will use a lot more memory (and it couldn't be an option for big maps).

@dacap dacap self-assigned this Feb 24, 2016
@not-surt
Copy link

@not-surt not-surt commented Feb 25, 2016

All other image editors with tilemap editing that I know of are limited to non-overlaping rectangular tiles.
This is obviously useless for isometric, other axonometric tiles.
Ideally any solution would allow tiles to overlap on the tilemap canvas and be editable in place.
This should require an full tilemap implementation rather than just a hack on top of a regular image.

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 27, 2016

2not-surt: Full tilesets and tilemaps creation support is far out of animated layered image editing scope. Don't think Aseprite should be jack-of-all-trades here, because wishes will just grow and grow. There are lot of other things possibly required from such support: clipmasks/z-masks, 2D/3D tilemaps, animated voxel/point-cloud sources for isometric tiles/sprites, objects/locations placement with parameters and objects presets archetypes hierarchy, animated scenes timelines for sprites/objects/hints, different lighting/shadows support, advanced grids (hex-grids, walls-and-columns-around-cell grids, etc.). Just too many of them. But simple and clean Super Tiling support will be just OK. Better create another editor or mode for ATnT (Advanced Tiles & Tilemaps) =)

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 27, 2016

2not-surt: And you can create isometric tiles (not tilemaps) in Aseprite using hint guides layer. Frames will be different sprites (or sometimes "frames"). Layers will help create complex tiles with layered layouts. And then use this tileset in tilemap/level editors, not image editor. Simple tiles is special case specifically because they do not overlap.

@KasumiArai
Copy link

@KasumiArai KasumiArai commented Feb 27, 2016

Block tile copy is an absolute must. (That is selecting multiple and pasting multiple tile indices. Pyxel Edit still lacks this, and it's my main problem with its workflow.)

It would be cool if this paired well with issue #974, or at least had a feature found in D-pixel. It allows you to work with tiles in a palettized way. Say you have a range size of say... 4 and draw a tile using indices 4, 5, 6 and 7. You place a duplicate of this tile to the right. You then draw on the left one using color 8. It remaps index 4 to 8, 5 to 9, 6 to 10 and 7 to 11, but only for the left tile. Meanwhile the stroke you made is still made on the identical right tile using color 4. So there's one tile in the tileset, but it can be displayed with two different palettes. Useful for retro stuff. A range equal to the current palette size would end up being "normal" painting behavior.

You can see a gif here, it's probably better than the text explanation:
d-pixel

What D-Pixel lacks that Pyxel Edit has is seeing the stroke you're making across all tiles the stroke has touched. D-Pixel lets you see the stroke, but if you make say... one continuous stroke across two of the same tile, both tiles will look different until you release click and it applies both sets of pixels that overlapped each tile in the map to the actual tile. You can see this above when a line is drawn on the white background. Ideally all of those white tiles would update during the stroke itself so it's never possible for two of the same tile to look different.

This is also a must. The palette stuff would be cool, but is not a must to me.

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 27, 2016

About blocks for Super Tiling I proposed at http://steamcommunity.com/app/431730/discussions/1/405692224243720164/

Copying blocks of tiles could be done by selecting tiles in Tileset window with Ctrl+click (they should be organized there for this, like 2x3 tiles for tree and etc.) or with Tiiling Pen on image layer with Ctrl+Alt+clicks, and then Ctrl+C to copy all selected tiles as image. Yes just an image. Then Ctrl+V to insert it. If current tool is Tiling Pen then Ctrl+V should insert it aligned to grid automatically and then movable with auto-aligning.

Also Ctrl+drag (Tileset window) and Ctrl+Alt+drag (image layer) could select/deselect tiles in rectangular block,yes.

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 27, 2016

2dacap: about "create a new kind of image that can reference different tiles/doc::Image on each area and with different rotation/flipping. (doc::TiledImage?)"

Just to clarify: for Super Tiling you don't need special kind of image. Only special kind of operations. It's perfectly possible to allow select existing files in Tileset window (and layer inside file for .ase files). And make combo list of such files with (+) and (X) buttons somewhere to add new and remove unwanted. And auto-select file and layer from this combo list then switching between layers of main image (restoring lastly selected file/layer for this layer).

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 27, 2016

For any tile WxH it's possible to calculate hash value using, for example, this function:

ub4 one_at_a_time(char *key, ub4 len)
{
ub4 hash, i;
for (hash=0, i=0; i < len; ++i)
{
hash += key[i];
hash += (hash << 10);
hash ^= (hash >> 6);
}
hash += (hash << 3);
hash ^= (hash >> 11);
hash += (hash << 15);
return (hash & mask);
}

From: http://www.burtleburtle.net/bob/hash/doobs.html

It's also possible to calculate hash values for flipped/rotated versions of same tile, because hash function is order-dependent.

These hash values could be used to create hashtable lookup of N lists, N = 2*max_tiles. Simply put tile index (and flip/rotate flags) into list with index = hash_value % N. Then when you need to find matching tile simply calculate hash value for your tile and lookup into same list and compare tile pixels only against those tiles in list (with flipped/rotated flags affecting comparison), not against all tiles of tileset.

max_tiles could be estimated as = ( tileset_width / tile_width + 1 ) * ( tileset_height / tile_height + 1 )

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 27, 2016

One worst case scenario estimation:

  1. image 8192x8192 designed with tiles grid 16x16, thus 512x512 tiles, 256K tiles total
  2. tileset 128x1024 with same tile size 16x16, i.e. 8x64 tiles = 512 tiles
  3. all image tiles same (for example, black), thus same hash value
  4. all tileset tiles same (for example, black), thus same hash value
  5. hash function for 16x16 = 256 bytes ~ max. 3000 processor ticks (for Indexed mode)
  6. let us have CPU 1Ghz
  7. 512 * 3000 * 8 ~ 12M ticks to calculate hash values for tileset (4 rotates with flips) ~ around 10ms
  8. 256K * 3000 = 768M ticks to calculate hash values for whole image ~ less than 1 sec
  9. 512 tiles in list for same hash value, compare every tile 512 times, 256K * 512 * ~1000(memcmp) = ~128G ticks ~ 100 sec ... hmm, slow =)
  10. to optimize don't add to hashtable same tiles, extra 511 comparisons, 511 * ~1000 ~ 512K ~ 0.5ms
  11. thus only 1 tile in list, thus 256K * ~1000 = 256M ~ 200ms

And this 1.5 sec operation is rare operation only for special second click in Tileset window to select all tile instances in main image (including flipped/rotated) and edit them all. All other operations do not operate over full image. And this was really bad case scenario where hashtable failed because of all tiles were the same.

@AkashaRepo
Copy link
Contributor

@AkashaRepo AkashaRepo commented Apr 18, 2016

Right now I have a workflow where I make tiles in Aesprite and arrange them in Tiled. Being able to do all this in Aesprite would be <3

@astraldata
Copy link

@astraldata astraldata commented Jul 12, 2016

+9000 to KasumiArai -- that sort of tilemap feature would be amazing in Asesprite! D:

@HawkenKing
Copy link

@HawkenKing HawkenKing commented Jan 29, 2017

current workflow is aseprite / photoshop, then Tiled or TileTool2D, or NES ScreenTool (for colours)

Would be nice if NES style per 16x16 tile colouring was implemented but that might be asking for too much.

@dacap dacap added this to the v1.6 milestone Jun 9, 2017
@astraldata
Copy link

@astraldata astraldata commented Jan 4, 2018

It's terrible -- this feature is due by 2021 ... and I've needed at least a preliminary version three years ago... :'(

@dacap
Copy link
Member Author

@dacap dacap commented Jan 4, 2018

Actually I'm planning to prioritize this one, it might be available sooner than you expect.

@oceanhahn
Copy link

@oceanhahn oceanhahn commented Jan 4, 2018

Woah, that'd be three years ahead of schedule! ;)

@dacap dacap modified the milestones: v1.6, v1.3 Jan 4, 2018
@astraldata
Copy link

@astraldata astraldata commented Jan 6, 2018

Indeed lol!

I currently don't have PyxelEdit, and, personally, I don't care for its pixel workflow in general, but the one feature it has on Aseprite is one I can't get away from -- and that's a tilemap editor.

I don't care about laying out a level in Aseprite -- I can do that in a game engine (or Tiled. )

Everything else I want to do with tiles needs a great pixel editor alongside it.

For that purpose -- I only want/need a few things:

  1. First, a list of editable tile indexes of a specific size that can be selected from and arranged like the color palette already can (in fact, a simple copy/paste of much of the palette arrangement code would do just fine)
  2. Second, a (potentially disposable) "swathe" space (similar to the "preview" window) where I can draw up a preview swathe of tiles (with chosen repetitions / mirrors / flips / rotations) of individual tile indexes
  3. Next, the swathe would respond, in realtime, to the strokes (and the color changes) you lay out in the main window. The main window itself would display a user-selected number of nearby swathe tiles in the X/Y direction and allow those tiles to be individually and simultaneously edited in the main window, right alongside the currently-selected tile from the swathe.

To clarify #3 and the imagined workflow in general -- just as the "Tiled x" and "Tiled y" settings allow repetitions to be displayed and edited in the main window area -- that's essentially what editing in the main window would do with a tile index selected, except with nearby tiles to the one that the user has chosen in the swathe. The swathe will always have 1 index at least, and if you select an index in the list of tiles, it can replace that index in the swathe automatically -- otherwise, selection would usually be done in the swathe palette window where both placement (and selection!) occurs. You would, of course, have a list of tile indexes that would, essentially, just act like the color picker for the most part. Only the first index is considered the origin tile (or perhaps the origin tile /group/) of course.

I do hope I've described everything here well enough to make it sensible.

From what I can tell from the editor -- the design outlined above will allow much of the code to be copy-pasted from the rest of the editor. -- Not all can be copy/pasted, but enough to have a preliminary display of tiles from a palette in a new preview window at least! -- Which is why this feature is so critical! It's the one thing Graphics Gale doesn't have and the one thing all other -lesser- (imo) pixel editors seem to have -- except with a poor implementation. Aseprite is up there with Gale in terms of user-friendliness, and I just wish it had this one feature to make it a Gale-killer for everything Gale lacks.

@haxpor
Copy link

@haxpor haxpor commented Jan 6, 2018

Interesting feature. Although I'm natural on this but I do any pixel related stuff with aseprite so if this feature is there, it would be a plus.

Just want to chime in here as Tiled just released version 1.1 that included interesting concept of Wang Tiles. Their interesting discussion is here. In short, as from my understanding, it can generate tilesets from a few tiles with pre-defined color for each corner, or used to map a proper and correct tile within tilesets while user's drawing road, or terrain map. Sort of those areas. Might be an idea further. Just FYI guys. Anyway, cheers for tilemap feature.

@astraldata
Copy link

@astraldata astraldata commented Jan 7, 2018

Thanks for sharing that, haxpor. -- In many cases (at least with pixel art), simple transparency overlays can handle the same problem Wang Tiles seeks to solve (using an uncecessarily-specialized algorithm).

@dacap 👍 :

If Aseprite did anything to help with what Wang Tiles tries to help with, it could be solved in a more useful and general-purpose way:

For example, it would be amazing if it would let you auto-merge individual layer-pair combinations sequentially. For example, you could specify that layers 1-4 would be the transparent overlays, and layers 5-22 would be the various combinations that 1-4 would overlay (i.e. 1 overlays 5, then 2 overlays 5, etc.., next 1 overlays 6, then 2 overlays 6... yada yada... you get the point.)

And for a slightly more complex (but infinitely more useful) alternative implementation, it would be nice to specify groups and sort orders of multiple overlays before executing the overlay+merge function. The idea came from when I was more recently playing with and it made me think of Aseprite ... It would be nice if the auto-combine feature I proposed above based on haxpor's suggestion could do more advanced transparent overlay combining. The idea behind Charas is to pull from a ton of layers of heads/hair/body-styles/accessories/etc. and letting a user combine them into a sprite atlas. I could see it being highly useful to do something like this for character animation too instead of a hard-coded thing like Charas has (perhaps by simply leveraging animation frames and layers simultaneously) to make it easier for an artist to generate automatic overlay + merges on a large variety of sprite combinations and animations. Even if we had to do this on a per-file basis, it would still be so much greater than the manual merging that is required in every other tool...

Just my two-cents! -- Maybe I'm onto something here though?

@dacap
Copy link
Member Author

@dacap dacap commented Feb 6, 2019

Just in case I'm already working on this one:

https://twitter.com/aseprite/status/1092884555126763521

The basic idea is that we should be able to:

  1. Create a new "tilemap layer" using a new Layer > Add Tilemap Layer menu option
  2. When the active layer is a "tilemap layer", this will show some extra controls in the color bar ("Tiles" and "Auto" buttons at the moment, but that might change in the future)
  3. Then we can draw as in a regular layer, and tiles will be created automatically (when "Auto" button pressed)
  4. Shift+Tab will switch between color palette <-> tiles
  5. Clicking a tile will enable us to put tiles in the canvas (right-click might pick tiles from the canvas, or just act like the right-click default behavior, just like FG/BG colors, we could have a FG/BG tile, or FG/right-click behavior)
  6. When the "Auto" mode is unpressed, we can edit tiles manually (no new tiles are generated automatically)
  7. We should be able to reference different tilesets from each tilemap layer, anyway each tilemap layer will have one layer-specific tileset to create those automatic tiles when the "Auto" mode is enabled.

In general terms, this new tilemap layer should work as the regular layer by default. And the special modes should start giving us more options (like putting tiles, modifying all instances of the same tiles, etc.).

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 6, 2019

... anyway each tilemap layer will have one layer-specific tileset to create those automatic tiles when the "Auto" mode is enabled

Do you mean old tiles not removed from this layer-specific tileset when they entirely removed from Tilemap Layer itself? And editor will keep order of tileset tiles until moved/edited by user just like colors of palette? Hmm... and we can load tiles to tileset from external tileset file (auto split by tiles size) once and then use them to draw map and later export tilemaps with exact tiles order saved? Sounds interesting. Hope tile width and height are Tilemap Layer properties then and could be any, for example 20x25 --- there're cases where art like this looks best. And image right and bottom not-full-tile-size edges should be ignored maybe. And we could mix different tiled layers, like 8x8 for physics, 16x16 for platforms and 32x32 for backgrounds. Also if add exporting of animated tilemaps (tiles indices) and maybe even with encode-only-changes-different-from-prev-frame mode it will be something like animated cutscene packing and partial image animations used in good old games.

@dacap
Copy link
Member Author

@dacap dacap commented Feb 6, 2019

Hi @EyeGem!

Do you mean old tiles not removed from this layer-specific tileset when they entirely removed from Tilemap Layer itself?

There should be two possibilities: 1) Keep tiles intact and just add new tiles (+ offer a button to clear unused tiles automatically), 2) Clear unused tiles automatically too.

And editor will keep order of tileset tiles until moved/edited by user just like colors of palette?

The user will be able to disable the "Auto" mode for the layer tileset (a tilemap layer will have only one "auto" tileset that can be enabled/disabled, any other referenced tileset will not be automatically handled = be in this "auto" mode).

we can load tiles to tileset from external tileset file (auto split by tiles size) once and then use them to draw map and later export tilemaps with exact tiles order saved?

Yes, the final version of the tilemap editor should give us the chance to reference several tilesets (from external .aseprite files too) and use tiles from those tilesets in one or several layer tilemaps.

Hope tile width and height are Tilemap Layer properties then and could be any

Yes, the only limitation will be that the "tileset specs" (tile width/height) should match with the layer tilemap specs. Anyway you will be able to have several layer tilemaps in the same files with different specs.

About animated tilemaps: each frame in a layer tilemap will be a different tilemaps (so you could reference the same tilesets/tiles on each frame or vary only one tile, etc.). I still have to think about the persistence details and memory usage implications for huge tilemaps, but we should save tilemaps differences only for animations.

If I find something really complicated in the process, I'll try to push things forward for future versions and have a more basic version in the first v1.3-beta.

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 6, 2019

the final version of the tilemap editor should give us the chance to reference several tilesets (from external .aseprite files too) and use tiles from those tilesets in one or several layer tilemaps.

To keep things simple it could be really preferable to just have one single tileset inside each Tilemap Layer data and give user tools to copy images from external tilesets into this single tileset, so that exporting tilemap may produce simple indexes of tiles and those indices not broken even by "Auto clear unused tiles" option or "Now clear unused tiles" button, so tileset should really have used/not used bit flag for each tile and allow free moving of tiles inside tileset, it's often really useful to arrange tiles in tileset in specific manner, so those unused-flagged tiles around arranged tiles will be helpful.

@awesomez
Copy link

@awesomez awesomez commented Feb 10, 2019

I think the difference is that tilemaps of 16x16 have indexes to a tileset of 16x16 tiles, not to 4x4 tiles. So basically metatiles is not only a way to composite bigger tiles with smaller ones (hierarchy of tiles) but it is also a way to compress tilemap data (because tilemaps reference only to their own level of tiles using smaller index numbers).

^^^ This. ^^^

Anyway I'm not sure what level of control over each tileset level is required (I suppose total control), in our example, we should be able to re-arrange the tiles in the 8x8 tileset in any order and the final visible result should be the same without modifying the data of the tilemap A, but the tileset/tilemap B data in the 8x8 level should be completely different.

The way I see it, the underlying (internal) indexing should not be visible/modifiable to the user, but instead, the arrangement of tile indexes on each subdivision level should be.
In other words, index "0" should be whatever tile index the arrangement layer assigns it (internally), but the user-facing index should be whatever the user wants it to be. It could be "brick" or "grass", but Aseprite shouldn't care -- the internal indexes should be treated as just a clear database reference id; the palette arranged entries (on the other hand) should be the user-arrangement id. Since there's always going to be the same number of tile indexes internally as there are specially-arranged tiles by the user, it really doesn't matter what order the user sets. Internally, the reference always needs to be persistent, and the user is not always going to want that same reference. Therefore, the internal (procedural) tile reference index and the visible (user-facing) palette displaying index for that same tile should be stored separately (and simultaneously) in the file. This allows the user to have total control of palette selection and display while also simultaneously letting Aseprite maintain full control too, to maintain proceduralism.

Number of (Useful) Subdivision Levels:

Regarding the number of levels a user would need to manage subdivisions for -- I have never seen any tile-based game, NES all the way to Playstation, require more than 5 different levels of tile sizes. Whether the base tile size is 64x64 (see Megaman X4 on the Playstation) or 8x8 (various Gameboy games), tiles rarely use more than two or three levels of subdivision. It could be neat to hold Ctrl + Alt to do half-sized tiles too (like 8x16 or 16x8, depending upon whether Ctrl was pressed before Alt, or Alt was pressed before Ctrl). This could make it possible to have horizontal and vertical (non-square) sets of tiles -- and be able to pick from them quickly too.

Alternate Control for Custom (Non-Square) Tiles:

Using the Ctrl or Alt keys to cycle (one-way) through superdivision and subdivision levels could work too, as an alternative method to grabbing specially-arranged tiles (such as 64x16 or 8x32), which could be input manually (if the base subdivisions/superdivisions aren't "custom" enough).

@EyeGem
Copy link

@EyeGem EyeGem commented Feb 13, 2019

@dacap Could you comment on options below?

External tileset option A: external image or .ase/.gif file with sprite sheet split to tiles with Tilemap Layer tile width and height (no overlapped tiles, animated tiles possible) <-- overlapped tiles also possible if extra params provided (width and height of tile area and x/y of tile origin)

External tileset option B: external .ase/.gif file with frames used as tiles and optionally tile rect taken from slice (allows overlapped tiles) <-- meta-tiles friendly because of same Tilemap Layer inside external tileset could be used to arrange different patterns, also layered tiles possible (flattened on being imported for render)

External tileset option C: external .ase file with layers used as tiles and optionally tile rect taken from slice (allows animated overlapped tiles in cost of many layers) <- still meta-tiles friendly with many more possibilities (and problems)

External tileset option D: external .ase file with selected Tilemap Layer tileset (how to index layer reliably?) <-- not very good? also no overlapped or animated tiles, better just export it and use options A-C

More options possble? Could all of these be supported? (in Tilemap Layer props by selecting type of tileset: internal / external sheet / external frames / external layers )

Also: animated tiles != animated tilemap, both could be useful

Also: it's really safer to allow to press "Update tileset" manually for external tilesets and maybe provide "Try update dynamically (on open/traced changes)" checkbox than to always reload them dynamically. And this will let us generally keep all imported tileset data inside .ase file both for internal and external tilesets. And provide another checkbox "Don't store external tileset data" for optimized usages (will force dynamic import on open).

@dacap dacap pinned this issue Feb 24, 2019
@hyperionthunder
Copy link

@hyperionthunder hyperionthunder commented Apr 25, 2019

This whole idea sounds very promising, as I am developing a game that require use of tileset (game genre is top-down action RPG 'zelda-like') So I am researching ways to design tileset quickly and by far the idea presented to include it in Aesprite is sounding really good. Since I use Aesprite mainly to develop asset for the game, it made sense to include ability to generate a tileset and export it as part of the design process within Aesprite. It'll be one less hassle and shuffling between different files: copying and pasting from one file into a master tileset to export out, praying everything made sense for be inputted into GMS2.

Currently, the design flow is: edit one file, copy the tile sections into a separate sprite file, export that into GMS2, find out if color works, jump back to the first file, then copy the changes into the tileset sprite, then export it again. It felt so redundant to copy and paste everytime i made a change to the tileset. So seeing the idea of including tileset feature as a layer to edit directly, reducing the need to create a separate sprite file to maintain any changes will be a huge help in speeding up asset generation process.

@skysanc
Copy link

@skysanc skysanc commented Dec 3, 2019

imo I think at a minimum it should have the same functionality as pyxel edit in regards to tilemaps.

@LeonardoCunhaGitHub
Copy link

@LeonardoCunhaGitHub LeonardoCunhaGitHub commented Dec 18, 2019

what is the time expectation to have this done? It has been like 3 years I believe...

@dacap
Copy link
Member Author

@dacap dacap commented Dec 18, 2019

This will be released in 2020. I've started working on the issue in Nov~Dec 2018, but after several problems (health problems of family members, etc.) I kicked the feature for the future. Maybe in Feb 2020 we'll have a first beta for a close group of users, and then after some feedback the first public v1.3-beta1 should be released with this feature.

@awesomez
Copy link

@awesomez awesomez commented Dec 18, 2019

@LeonardoCunhaGitHub
Copy link

@LeonardoCunhaGitHub LeonardoCunhaGitHub commented Dec 19, 2019

This will be released in 2020. I've started working on the issue in Nov~Dec 2018, but after several problems (health problems of family members, etc.) I kicked the feature for the future. Maybe in Feb 2020 we'll have a first beta for a close group of users, and then after some feedback the first public v1.3-beta1 should be released with this feature.

Sorry to hear my friend :(

Incredibly much appreciated that you are working on this.

With this feature Aseprite will be basically a complete tool for pixel art game development.

All the best!

@fabriceci
Copy link

@fabriceci fabriceci commented Jan 4, 2020

Find yesterday this thread, instant buy! That's was I waiting for: a fluid workflow between draw and build.

It would be nice to be able to add space (vertical & horizontal) between tiles when you export the Tilemap, to avoid a common problem when the camera zoom change in a game.

@AlexDavies8
Copy link

@AlexDavies8 AlexDavies8 commented May 28, 2020

Would be great if support for auto-tiling, or at least a script or tool for generating a whole tileset from a smaller set of sprites, like in Tilesetter. Support for both blob and wang tilesets would be nice. From what I can tell, this is probably something that can be done now through scripting, but it would be nice to have it built-in, as it's such a useful feature for anyone creating tilesets.

@ccioanca
Copy link

@ccioanca ccioanca commented Jun 11, 2020

Any update on this @dacap ?
I know you can't rush perfection, but I'm just excited for this.

Last you mentioned, you said perhaps a closed beta in Feb. Any update on that timeline?

@dacap
Copy link
Member Author

@dacap dacap commented Jun 11, 2020

There are no news and no ETA.

@dacap
Copy link
Member Author

@dacap dacap commented Jun 30, 2020

Just in case, we are working on this feature full-time (v1.3-beta1 is the next version to release).

@awesomez
Copy link

@awesomez awesomez commented Jul 2, 2020

Just in case, we are working on this feature full-time (v1.3-beta1 is the next version to release).

You make me want to cry tears of joy, my friend. Tears of absolute joy. <3

@LeonardoCunhaGitHub
Copy link

@LeonardoCunhaGitHub LeonardoCunhaGitHub commented Jul 3, 2020

@dacap Thank you for your efforts and dedication to this project!

@sommerper
Copy link

@sommerper sommerper commented Jul 10, 2020

Absolutely stoked that this coming. Can’t come fast enough.

One thing I would like to see added to this at some point is a collider editor. One could argue that’s the game engines responsibility but if the editor could paint and output a data file with tile collider info I’m sure it would speed up the workflow immensely.

@EyeGem
Copy link

@EyeGem EyeGem commented Jul 10, 2020

Aseprite would really benefit from Simple Vector Layers : 1) vertices with optional radius for circles, 2) n-point-lines between vertices (open/closed/filled), 3) copy/paste/cut vertices between frames (same IDs copied to tie animation operations between frames), 4) operation to apply interpolation of selected vertices along selected frames, 5) SV Layers underneath always rasterized as bitmap layers of finite pixel resolution --- i.e. SV Layers never rendered in real-time --- and THAT'S IMPORTANT!!!

These SV Layers could be used for: 1) complex articulated animation references, 2) smooth animations of complex shapes contours, 3) export collision shapes (lines, ngons and circles), 4) splice bitmap to regions, 5) etc.

Simple custom data for every vertice and n-point-line would be enough to define custom properties for export purposes.

@ccioanca
Copy link

@ccioanca ccioanca commented Jul 12, 2020

@EyeGem I dont think this issue is the right place for that comment. I could be wrong but I don't think that has anything to do with the tilemap feature. You should post a new feature request for that.

@awesomez
Copy link

@awesomez awesomez commented Jul 13, 2020

Aseprite would really benefit from Simple Vector Layers : 1) vertices with optional radius for circles, 2) n-point-lines between vertices (open/closed/filled), 3) copy/paste/cut vertices between frames (same IDs copied to tie animation operations between frames), 4) operation to apply interpolation of selected vertices along selected frames, 5) SV Layers underneath always rasterized as bitmap layers of finite pixel resolution --- i.e. SV Layers never rendered in real-time --- and THAT'S IMPORTANT!!!

These SV Layers could be used for: 1) complex articulated animation references, 2) smooth animations of complex shapes contours, 3) export collision shapes (lines, ngons and circles), 4) splice bitmap to regions, 5) etc.

Simple custom data for every vertice and n-point-line would be enough to define custom properties for export purposes.

It took a good long while to finally understand what the heck you were asking for here.

Just use Spriter or DragonBones (free) or really any simple image-positioning animation software to achieve this. There are all kinds. As neat as it would be to have the ability to use rotsprite to shift around images and output them as .png strips or whatever, losing the vector rotation data, etc. (or trying to support the myriad of various animation formats for vector anims), Aseprite would lose its pixel-level focus -- which I don't think anyone wants.

TL;DR
There are plenty of other dedicated software out to do this -- and do this only -- which means they are great at it, and they don't reinvent the wheel or have to sidestep other features. They also keep vector data (and export it to game engines), so they would be just better overall than Aseprite for animation purposes all-around. More than that, the whole point to using "SV" data is not to export to pixel-level detail, but to save memory at runtime. Unity has a "pixel-perfect" 2d camera that can make the rotations appear pixelated, if the visuals from this is all you want.
Trust me, I've been down this road. Going the route of vector animation just to go back to 2d .png strips is counterproductive in so many ways.

Back on topic though !!! --


@dacap

Some additional thoughts on the approach to tiles/metatiles:

As @sommerper mentions, I can see how making collider "layers" could be useful for programs like Game Maker, but to focus solely on this would be a waste of time for other users, as I can see them as not being useful for something like Unity (since it uses vectors/3d to handle collisions).
That being said -- what I can see the "layer" concept being useful for (and what I see relates better to the Tilemap Feature, @dacap ), is providing alternate "Layers" for each subdivision level of the "metatiles".

Metatile 'Layers' Concept

In other words -- Say you have grass tiles, with corner "transitions" to some other kind of 'terrain'. These all fall in the same place on the tileset each and every time, whether they're grass, snow, or rocky 'terrain'. Let's say that grass tile has a transition to a "water" tile on its edges/corners. Now let's say you have a tileable water animation you want to "Layer" your grass, dirt, or snow on top of, following the exact layout of the tiles. The idea is that the single repeatable water "animation" tile would generate tiles for each kind of terrain (a new version of the tile for each "frame" of the animation, for each type of terrain). The idea is that the snow/grass/rocks/water tile (or metatiles) could be altered at any moment, regenerating the final resulting tile (with the merged "Layers" together in the 'scene' workspace where you arrange the tiles), letting it automatically to reflect the tile/metatile update.

To do this, you'd have two concepts:

  1. a selection of tiles from an "overlay" tile_set_ (one or more tiles w/transitions to other 'layer' -- i.e. grass, desert, rocks, snow tiles)
  2. a repeatable "underlay" tile (usually one tile or tile animation, but possibly more -- i.e. tileable water animation / sand / dirt)

The first concept, the "underlay" tile, which is just a repeating tile or animation of a specific subdivision size (i.e. 16x16 water tile animation).
The "overlay" tileset would be the grassy, rocky, snowy tiles that are all laid out in the same way (whatever way you like), with each "overlay" tile in the tileset being a specific size, and transitioning to transparency (each bit of transparency would represent where the "underlay" [repeating] tile or animation would be shown through.) When merging the "overlay" with the "underlay" tiles, you have the appearance of a "layered" tileset that is simple to update, and generates the proper animations/transition tiles automatically via secondary tilesets for the additional animation frames when exporting. These also keeping the tile count down and memory usage (while editing them) down, while working with the "metatiles" concept all at the same time!

Implementation Considerations

You could use multiple tilesets (of the same number, positions, and sizes of tiles) to handle multiple "overlays" at once in your tile palette, combining them each with whatever repeatable "underlay" tile (or tiles) you wish.

The nonstandard "tile" indexes in your tileset that are likely to vary -- i.e. a desert might have a skull at a particular (single) tile index, but a grassland might have a decorative swathe of grass across two tile indexes, one index of which uses the desert's "skull" tile index -- would simply be ignored in the "Layer" data, since neither these particular tiles (or their metatiles -- i.e. 8x8 subdivisions of the 16x16 water tile "underlay" animation) really needs a "subdivision" directly. Their origin data would handle any needs for subdivisions/metatiles -- this is just extra "dumb" data to support "Layer" tiles.

I would say the only restriction would be that the tiles would all need to support the same "level" of subdivision (i.e. 16x16 is the base subdivision "level" -- letting the necessary "underlay" tilesize be automatically determined by which subdivision level you're currently on with the selected tile/metatile).

Lastly -- I keep saying "underlay" for the water tile portion, but I think a checkbox to allow it to "overlay" all "overlay" tiles from the provided tilesets instead, should be an option at some point, just in case. Perhaps this option could be used for "blending" in partially transparent textures onto all tiles, letting you instantly "texture" an entire tileset at once, for example, ignoring the fully or partly transparent areas). Maybe it could be called "invert underlay" or something.
Just a pixel-art "trick" -- and food for thought for why something like this could be useful.

Let me know if this helps any, @dacap !

@EyeGem
Copy link

@EyeGem EyeGem commented Jul 14, 2020

@awesomez

It took a good long while to finally understand what the heck you were asking for here.

And... you didn't. Well, not quite. I meant SIMPLE vector layers. Vertices-circles and n-lines/n-gons only. No curves, no anything else. No vector animation. No external vector formats support required (maybe only access from scripts). It's goal is FULL pixel-perfect control over vector-to-bitmap raster in FINITE exact resolution with fixed-point math. And also to provide user-triggered smooth transitions of vertices (along EXISTING frames). It's pixel graphics feature to help in planning of pixel art and animations. And those layers will still be PIXEL layers, but their content will be re-generated from vector data under full user control.

Also Spriter and DragonBones are painful to use for such purposes. Both.

P.S. I think I'll create animation clip to illustrate the SVL feature.

@ALL Sorry for off-topic. No more ^^

@dacap
Copy link
Member Author

@dacap dacap commented Jul 14, 2020

Hi there 👋 @EyeGem actually there are plans for vector layers (first guides would be nice #272, and then some kind of rasterization in real-time would be the final objective, to create "Another World"-like animations). Never thought about the possibility to have both kind of layers (vector and raster, and rasterize on-demand). Anyway it's off topic and I would prefer to continue this in #272

@nights321
Copy link

@nights321 nights321 commented Jul 15, 2020

@EyeGem and everyone, for the love of god, let @dacap focus on the tilemap editor for now - it's already a huge undertaking and it seems like he's almost done, let's give the man a break so he can finish it! As a programmer I know how constantly switching context can slow you down to a crawl. Cheers!

@dacap
Copy link
Member Author

@dacap dacap commented Aug 28, 2020

I know that there are some expectation about this feature... 👀👀👀 ... We're working full-time for v1.3. The main problem with the tilemap editor is creating something that "feels right", there will be some internal betas to get some feedback about the UI and try to improve from that. This week we've solved some big issues related to drawing tiles and selecting tiles, we still need to fix the selection handling/cut/copy/paste of tiles, but after that we'll be closer to the beta.

Just that for now. Have a nice day!

@cjke
Copy link

@cjke cjke commented Sep 5, 2020

The one good thing to come out of 2020

@awesomez
Copy link

@awesomez awesomez commented Sep 6, 2020

there will be some internal betas to get some feedback about the UI and try to improve from that. This week we've solved some big issues related to drawing tiles and selecting tiles, we still need to fix the selection handling/cut/copy/paste of tiles, but after that we'll be closer to the beta.

@dacap -- Just FYI about some possible UX approaches:

#1722 (comment)

I happen to be a pretty good UX guy, and also quite interested in this feature. I might be able to assist in the beta if you wish. I definitely have some ideas on some of the more "advanced" topics you mention above. It might be useful to plan for some of those now, rather than later, in regards to UI and UX approaches, otherwise the "feel" might become too unwieldy if these aren't at least thought through a little in these early days (since they do require some architectural considerations in terms of data).

Just food for thought. Let me know if you want me for the beta! :)

@LeonardoCunhaGitHub
Copy link

@LeonardoCunhaGitHub LeonardoCunhaGitHub commented Sep 30, 2020

@dacap Thank you for your hard work towards this feature! Much appreciated!

@awesomez
Copy link

@awesomez awesomez commented Oct 1, 2020

https://www.youtube.com/watch?v=ZWQ0591PAxM

@dacap -- This is an interesting video to look at for the meta-tiles concept I explained above! D:

@darthdeus
Copy link

@darthdeus darthdeus commented Oct 11, 2020

I assume this is not being built on the github repo? Looking at the tweet showing the tilemap from almost two years ago (https://twitter.com/aseprite/status/1092884555126763521) it already seems better than what PyxelEdit has? I'd be totally up for beta testing it as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.