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 · 51 comments

Comments

Projects
None yet
@dacap
Copy link
Member

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. clean unused tiles = clean unused colors, or group tile = group colors, remap of tiles = remap of colors
  • 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 or load/link external tilesets

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Jul 12, 2016

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

@HawkenKing

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member Author

commented Jan 4, 2018

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

@oceanhahn

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

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.

@EyeGem

This comment has been minimized.

Copy link

commented Feb 6, 2019

Another possibility would be a double indirection: E.g. one tilemap tile could be an index that reference the layer tileset which itself is another reference to other tilesets

Thus adding "Export tileset information" operation in addition to "Export tileset images" (as ase or sprite sheet) and "Export tilemap(s) data" (indices only, multi-format desired here: plain binary, xml, TMX, etc.).

@EyeGem

This comment has been minimized.

Copy link

commented Feb 6, 2019

but I think it would preferable to "link" them in some way most of the time

It's really question of induced complexity -- keep it simple and intuitive sprite editor with simple, but powerful tiling features or try to make it complex tilemapper. Instead or complex referencing it's possible to use external tilesets by loading (and maybe ref-file-reloading if parameters still matching) them into Tilemap Layer tileset data on user demand only. Yep, no complex tilesets from several sources while still referencing all of them are possible this way, but... is it really required?

@EyeGem

This comment has been minimized.

Copy link

commented Feb 6, 2019

The details about how to lock/unlock tiles (content and index) weren't implemented yet, so that will need some hard thought

Simpler is better here too, I think. All tiles in tileset should have permanent index by default. The only way to rearrange tiles should be by user actions, not automatically, not even in "Auto" mode --- which should only add new tiles, not trying to automatically delete or move existing ones without explicit "Remove unused tiles" and "Defragment tileset" operations executed by user only.

@EyeGem

This comment has been minimized.

Copy link

commented Feb 6, 2019

Although it may be not really artist-friendly to force them to keep tileset stable... maybe multi-referencing is better from this point of view. But... this way we will definitely need "Export resulting tileset from all sources as multiframe ase / sprite sheet" operation to allow easier final use.

@niedzielski

This comment has been minimized.

Copy link

commented Feb 7, 2019

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

I hope you don't mind me chiming in but this is on my wishlist too! It would be very useful for my purposes to allow tile sizes to be variable within an image as derived from their source Aseprite files. E.g., I may have a tree tile that's 48px x 64px, a water tile that's 8px x 3px, and a player tile that's 12px x 8px.

I'll also comment on the export format. Almost as important as the feature itself is the format it's exported in. I've been using the binary format for spritesheets to interpret the JSON output which I believe is otherwise undocumented. There are many different options for the format so it has ended up quite specific (here's my current interpretation-- I just mash the frames and meta.slices together). I don't mean to overstate the difficulty of the task to parse but the easier it is to conceptualize and consume the output, the better. One of the reasons I love Aseprite is because the output format is sane and infinitely better than the Tiled Map Editor's.

Finally, I hope that the faculty for adding slices and metadata will be improved. This would be an invaluable addition to a tilemap editor where one would immediately want to start adding annotations such as speed, palette, level, collision boxes, etc for later interpretation by a program.

Thank you for making such a nice tool! 👍

@EyeGem

This comment has been minimized.

Copy link

commented Feb 7, 2019

to allow tile sizes to be variable within an image as derived from their source Aseprite files. E.g., I may have a tree tile that's 48px x 64px, a water tile that's 8px x 3px, and a player tile that's 12px x 8px

Generally it's bad idea to turn sprite editor into feature-complete map editor, just because you will need so many more features and will lose its simplicity. While Tilemap Layer could be represented as map of cells internally, it's still better to represent it as pure image and allow image editing tools to modify it. It's always better to make best map editor on your own in your game (just because it will have all features you need) and leave sprite editor with simpler tasks, like image tiling (not necessarily for maps, it could be used for big tiled/partially-animated sprites too) and tagging any image with named per-frame animated rect/circle shapes (and also can use those shapes as animation guides which will be just cool). Anything like map of cells with overlapping tiles, floors or stacked-in-column tiles is just not sprite editor tasks, maybe David can create separate map editor for those =)

@dacap

This comment has been minimized.

Copy link
Member Author

commented Feb 7, 2019

Yesterday I was thinking more about this, and I finally will back to my previous simpler design (more related with what @EyeGem said):

  • One Tilemap Layer => One Tileset

Why? Because it'll make a lot easier the user experience and if we need different tilesets to be used in the same sprite, we can create several tilemap layers anyway (and group them in Layer groups, etc.). So basically we'll have the tool to use several tilesets in the same sprite: using several tilemap layers. So it would be redundant (and a lot harder UX) to use multiple tilesets in the same layer.

About variable tile sizes: It's planned that each tilemap layer (and its tileset) will have its own tiles spec (grid/tile width/height), so basically we will be able to mix different kind of tiles in the same sprite because we will be able to create different tilemap layers with different tile specs.

And finally, about overlapping tiles, I'm experimenting with some interesting stuff, I don't promise nothing, but there might be really big surprises about this one.

@dacap dacap changed the title Tilemap feature Tilemap editor feature Feb 7, 2019

@EyeGem

This comment has been minimized.

Copy link

commented Feb 7, 2019

each pixel in the tilemap is a 32-bit value where it contains a tile index, a tileset index, and some flags (flip/rotation)

There are cases when we need more than 256 tiles, maybe up to 4096, considering animations. Thus 12 bits + 3 bits for flips/rot90 + 1 free bit = 16 bits or aligned happiness ^__^

@EyeGem

This comment has been minimized.

Copy link

commented Feb 7, 2019

Should magic like palette offset (by 8 colors? 256/8=32=5 bits) for each tile be considered excessive?

@awesomez

This comment has been minimized.

Copy link

commented Feb 7, 2019

@dacap

You rock, my friend! -- Thank you!

That said -- please also keep in mind that "metatiles" should be supported early-on too!

For example, many SNES games (almost all of them actually) built large sprites out of small 8x8 "mini tiles" that referenced (linked) to a particular grouping of 8x8 pixels in a particular 8x8 position on a canvas. From there, they were assembled into larger 16x16 regular tiles (which could be highly-detailed and were varied) because the image could be visualized and edited almost procedurally.

See this:

image
image

This is the basic "metatile" approach (for autotiling terrain):
image

About METATILES:

"Metatiles" have nothing to do with terrain or autotiling though.

image

Does THAT look like autotiling to you?

Metatiles are simply a group of references (or "links") to even tinier bits of pixels that may "tile" and help vary larger (usually 16x16) tiles by replacing one or two of the 4 (usually 8x8) corners.
Their ability to "autotile" as terrain is just a convenient use-case for level designers.

For artists, being able to "group" bits of tinier tiles into a larger "metatiles" is an essential function for professional pixel artists due to their ability to quickly (and procedurally) get detailed images by editing only a small part of a larger tile.

Chrono Trigger's backgrounds (above) would never have been possible without the ability to procedurally edit and visualize the whole 16x16 tile (in the context of its scene) AND the tiny bits of each tile, all while being visualizing (and editing!) the 16x16 tile itself while it is being combined with other 16x16 tiles -- all simultaneously!

IMPLEMENTATION:

The important thing is to look at each "tile" as a HIERARCHY of more-detailed parts (usually no more than 2 levels of detail deep, but provide 3 just to be safe).

These details can themselves be edited, depending upon what level of the hierarchy the artist is working at (with an up/down arrow to toggle the current tile subdivision.) Currently, you only have 1 level of hierarchy -- 16x16, but maybe I need an 8x8 and a 4x4 that autopopulated their lower-level tile links when I created my new 16x16 tile. What if I now want to edit some of the smaller 4x4 segments too for better seamlessness in my tileset? These links should be autogenerated and bitmasks should be used to "pick" the links for the two lower-level subdivisions based on the 16x16 tile variation you're currently working on.

TILE ARRANGEMENT LAYER

We should also have a "Tile Arrangement" layer that grabs links from "Tile Layers" and simply arranges them into larger structures (such as the edge of a mountain with varied edges along its footprint and middle -- see the Chrono Trigger tileset and the mountains.)

These "Tile Arrangement" layers should actually be able to create weirdly-shaped tiles based around the base tile size (16x16 in this example) and the "Objects" created from the "Tile Arrangements" just pull in their pixels from the regular "Tile Layer" (which will update its details from the 8x8 and 4x4 subdivisions of the basic 16x16 tile when these subdivisions are edited in the viewport.)

FINAL THOUGHTS:

Just my two-cents as a professional pixel artist. D:

Thank you for finally tackling this aspect -- I just want this tileset editing to be as good as those (unreleased) pixel editors from days of old. :)

@EyeGem

This comment has been minimized.

Copy link

commented Feb 7, 2019

The important thing is to look at each "tile" as a HIERARCHY of more-detailed parts (usually no more than 2 levels of detail deep, but provide 3 just to be safe)

Maybe just Ctrl+click select shape of tiles from tileset and plotting them as whole would suffice? And also be able to Ctrl+click select shape of tiles from tilemap itself and copy/cut/paste them? Or add metatiling level to Tilemap Layer props and also have arrangement palettes for metatiling levels? Hmm...

@awesomez

This comment has been minimized.

Copy link

commented Feb 7, 2019

Maybe just Ctrl+click select shape of tiles from tileset and plotting them as whole would suffice? And also be able to Ctrl+click select shape of tiles from tilemap itself and copy/cut/paste them?

This isn't a bad way to keep it simple UI-wise.
I was thinking in terms of being able to load these into a game or game engine easily too. The concept of tile subdivision levels for a given "Tileset Layer" would make loading these kinds of tiles into game engines (using native Aseprite files) much easier programmatically, since each tile in a single Tileset Layer could be assumed to have a certain number of subdivision levels (3), and these could then be linked data-wise.

To speed up the selection of smaller subdivided tiles, the whole tile selection grid should change size (depending on the current tile subdivision level), perhaps through using left-, middle-, or right-clicks to select the 16x16 (subdivision level 0), 8x8 (subdivision level 1), or 4x4 (subdivision level 2) respectively.

Regarding "Tile Arrangement" layers to create an "Object" of tiles of any shape:

It would definitely be useful to be able to select "Object" arrangements consisting of any weird amalgamation of 8x8 + 4x4 + 16x16 tiles (all in the same "Object" in a "set" of "Objects" made of tiles) so that when the 8x8 pixels get updated, the 16x16 version doesn't change (but instead creates a new variation of the "Object" in the Tile Arrangement layer and the 16x16 "tile" -- That way we could grab various cliff "Objects" like the ones shown above in Chrono Trigger tileset, all without needing to redo the graphics for each tiny variation.

Your UI idea works though -- I just think that, under the hood, it should probably function as I described so that we can get the benefit of having "procedural" tile aspects to our tile art like in the art tools from the days of old.

@EyeGem

This comment has been minimized.

Copy link

commented Feb 8, 2019

The concept of tile subdivision levels for a given "Tileset Layer" would make loading these kinds of tiles into game engines (using native Aseprite files) much easier programmatically, since each tile in a single Tileset Layer could be assumed to have a certain number of subdivision levels (3), and these could then be linked data-wise

I think instead of tile subdivision levels it will be better to have arbitrary number of tile meta levels with separate meta-tileset for each level based on previous level tileset, ability to export any meta-tileset and any meta-level tilemap, work with meta-tileset and meta-tilemap (by selecting current meta-level) and (yes) allow to 1) edit lowest level tiles to affect all meta-tiles, 2) edit meta-tiles by arranging lower level tiles and 3) option to duplicate any level tile with auto duplication of higher levels meta-tiles that was using that tile. And yes, when adding meta-level you can setup its multiplication factors from simplest 1x2, 2x1 or 2x2 tiles to anything like 8x8 and etc. as you need in your project.

Of course this is advanced feature, let's call it METATILES and we can always add it atop of basic functionality.

@dacap

This comment has been minimized.

Copy link
Member Author

commented Feb 8, 2019

@awesomez about the metatiles, how the information is exported? in the 8x8 tiles information? For example, if tiles looks like 16x16 but are just constructions/combinations of smaller 8x8 tiles, and that's the tilemap information consumed by the game (indexes from a 8x8 tiles tileset), I think that the only requirement for "metatiles" is an easy way to group small tiles in a kind of palette/sandbox area were we can arrange 8x8 tiles in 16x16 groups and then we can grab those objects/bigger tiles and put then as a group in the canvas (but the 8x8 tiles information is always the real information kept in the tilemap).

There are plans to offer this kind of grouping of tiles to easily put bigger objects in the canvas, it should not be specific to metatiles, but it should be useful for metatiles.

In anycase, this is not planned for the first version (already the first version will contain so many changes that I would prefer a basic tilemap editor first, and then grow the feature from there).

@awesomez

This comment has been minimized.

Copy link

commented Feb 8, 2019

I think that the only requirement for "metatiles" is an easy way to group small tiles in a kind of palette/sandbox area were we can arrange 8x8 tiles in 16x16 groups and then we can grab those objects/bigger tiles and put then as a group in the canvas (but the 8x8 tiles information is always the real information kept in the tilemap).

This is backwards from fast, iterative, and procedural. :(
-- Think "hierarchical selection tree", rather than "drawing atomic groups of tiny pixel-blobs".

To be clear:

The information stored should be 16x16 (or whatever the largest base "chunk" size is), then 4 bits determine the 8x8 corner of the first 50% subdivision, then the final 4 bits determine the final 4x4 corner from the previous subdivision (the operation occurs on only one of the 8x8 corners).
This operation decides the particular group of pixels to be displayed/edited/replaced.
This is the way Sonic the Hedgehog stored its HUGE level maps + collision in the world (as well as its massive number of variations of sloped tiledata) just by using tiny 8bit variables in a hierarchical and procedural way. This wouldn't have been possible to display (and interact with) on a 16-bit system without this procedural approach -- and wouldn't you know it? -- procedural art is trending too.

Regarding the construction of larger "objects" out of variations of the 16x16, 8x8, 4x4 tiles:

The process to edit/display the tiles would crawl the subdivision levels of the nearest 16x16 tile you've clicked on (in the palette) to select the correct pixels.
This is faster if you have lots of 16x16 tile chunks (which can fill up the screen faster and with less memory overhead than tons of 8x8 or 4x4 tiles).
You could even have a "super-subdivision level" so that you could go up to 32x32 and 64x64 by holding shift + left/middle/right- clicking to select the tiles (rather than down), which would give you a total of 5 different levels of subdivision, saving memory in both realtime games and in Aseprite, while remaining entirely procedural for the artist himself to edit/tweak.

Also -- middle/right clicks could be substituted by Ctrl/Alt or Shift + Ctrl/Alt to quickly display all 8x8 and 4x4 chunks (or, with Shift, display 32x32 and 64x64 chunks to be selected via left-click.)

So to summarize --

-- Have left, middle, right clicks in the palette (by default) select the proper tile -- starting with the main/large pixels (16x16), subdivided pixels lvl1 (8x8), and finally subdivided pixels lvl2 (4x4) of the nearest 16x16 tile or corner, if right-clicking or middle clicking.

This is just a "new" way of doing pixel art (procedurally) that was used by companies like Square/Enix in the SNES days to create beautiful pixel art iteratively and procedurally (to help it look like a painting) in titles like Chrono Trigger, where the tilesets never look "human-readable", since the art tool itself helps the artist iterate procedurally, providing a fast way to throw out tiny edits to tiles (using different sizes), then glob them together in a single canvas, letting artists edit them quickly, updating the whole image (and its constituent tiny tile variations) simultaneously. Then, exporting the "hand-painted" map as a brand-new map in the game environment was just icing on the cake.

@dacap

This comment has been minimized.

Copy link
Member Author

commented Feb 8, 2019

@awesomez the most important question is what information is needed by the game. If the game consume a tilemap + tileset with tiles with 8x8, it could be done. In case that the needed information is some specific interpretation of the bits in the tilemap, then some .aseprite <-> your tilemap conversion will be needed (e.g. with custom scripts). At the moment there are no plans to support all possible scenarios with the tilemap editor.

Anyway I'm not sure that I understood correctly the internals. If you know an article that talks about all this stuff, it will be greatly appreciated. The most important thing is "what data does the game need?", because that will enable different ways to solve this problem. For example, I have some idea to link tilesets between documents which could create hierarchies of tiles, but the information might not be easily "readable" by a game engine.

@dacap

This comment has been minimized.

Copy link
Member Author

commented Feb 8, 2019

Correct me if I'm wrong:

  1. A tilemap is a grid where each tile points to a tileset (let's call it tileset A) with tiles of 16x16
  2. Each 16x16 tile in the tileset A is 4 tiles/indexes to another tileset B with tiles of 8x8
  3. And each tile in tileset B are 4 tiles from a tileset C with tiles of 4x4

If that is correct, a possible way would be that a tilemap layer could have its tileset pointing to another .aseprite file which can contain the composition of the tiles (and the .aseprite file can contain several layers, tilemaps with smaller tiles, etc.). Anyway the hard part would be to edit all the hierarchy (editing the bigger 16x16 tile should touch 3 files at the same time).

@not-surt

This comment has been minimized.

Copy link

commented Feb 8, 2019

My plans for metatile support are:

  • A metatileset is a tileset that uses a tilemap as its data source (rather than an image), plus a metatile size property.
  • A tilemap can source its tiles from either a regular tileset or metatileset.
  • When a tilemap uses a metatileset it draws the relevant region of the metatileset's tilemap in place of the parent tilemap's tile.
  • Metatilesets can use tilemaps based on other metatilesets for multiple levels of metatiling.
  • The metatile-based tilemap would simply be exported as regular tilemap, an array of indices, along with the metatileset which similarly exports as a regular tilemap, plus the metatile size.

I also plan to have tilesets exist in the layer tree as regular layers (though typically hidden from composition) so they can be edited directly with each tilemap layer referencing another layer as its tile source.

@dacap

This comment has been minimized.

Copy link
Member Author

commented Feb 8, 2019

@not-surt if I get it correctly, I think it's the idea I have in mind: a tilemap has a "tileset source", it can be "its own tileset", or an "external tileset" (here we can call this external tileset as "metatileset"). The external tileset can point to another sprite + a grid/slices to extract the tiles in the set. What's the problem? Maybe too much freedom to specify the tileset tiles, I was thinking that the sprite could composite the tileset with any number of layers/etc., but that might be impossible to solve when we must do a reverse matching of layers when we edit pixels in the bigger tilemap (the "metatilemap").

Still need to think more about this use case and how to solve it with a nice UX.

@awesomez

This comment has been minimized.

Copy link

commented Feb 8, 2019

Correct me if I'm wrong:

A tilemap is a grid where each tile points to a tileset (let's call it tileset A) with tiles of 16x16
Each 16x16 tile in the tileset A is 4 tiles/indexes to another tileset B with tiles of 8x8
And each tile in tileset B are 4 tiles from a tileset C with tiles of 4x4

You've got it.

The idea I had in mind was less-complex (to the user/artist) than the implementation suggested by @not-surt in that the tiles would be grabbed from the source image (the canvas image itself essentially is the tile palette's source image, like it shows in your feature preview video), and all tiles are auto-grabbed from that image upon clicking a button. The button executes a function that grabs all pixels that are different from the base grid size, then sorts them from there based on the base size (16x16 in the example), then subdivides to grab all the identical 8x8, 4x4 tiles and then _super_divides to grab any 32x32 and 64x64 tiles that are identical from the base image according to these tile-sizes).

Tile Arrangement Layers

This would automatically genearate you a palette full of metatiles where the pixels that were not identical in the canvas to other groups of pixels (each "group" is iterated over based on every super/sub tile size, based around the base tile size) and can now be considered linked to "tiles/metatiles" in the newly-generated palette. These palette tiles are based on the canvas image layer (which is now converted to a "Tile Arrangement" layer.) This procedure would have been executed to "grab tiles" from the canvas, probably via button-click, and makes that canvas a "Tile Arrangement" layer, which consists of tiles created by a palette (and also is generated from a regular canvas, which creates the palette itself without duplicating any tiles, as you've already done in your demo video.)

This palette could be changed to dynamically display subdivided tiles (8x8/4x4) by holding Ctrl or Alt respectively. To show superdivided tiles, you get (32x32/64x64) by holding SHIFT and then pressing Ctrl or Alt. Upon releasing Ctrl or Alt, the palette returns to showing normal non-subdivided tiles. All tiles can be left-clicked and selected with dragging the mouse (to select multiple tiles at once).

Under the hood, the standard drawing layer's canvas (where you pulled your tiles from) would be transformed into a "Tile Arrangement" layer that would be provided links to the palette indexes of 16x16 tiles as the base palette, which also includes the pixels from the original canvas (which can still be edited with drawing tools on the "Tile Arrangement" layer as if this was still a regular canvas layer). The subdivided and superdivided metatiles also store their pixel data in the tile palettes based on the indexes of their subdivisions/superdivisions. When placing tiles, the "Tile Arrangement" layer notes whether they're subdivided/superdivided, and what level of subdivision/superdivision they're at when placed, and references these pixel blobs from the "Tile Arrangement" layer itself.

This means one can create "Objects" out of the tiles on a "Tile Arrangement" layer by simply selecting those tiles on the "Tile Arrangement" layer. Then, after creating a "Tile Object", it will reference the specific palette of tile images and their subdivisions/superdivisions when you draw on them. You can draw new "Tile Objects" from many palettes on a "Tile Arrangement" layer.

Procedural Palettes:

A "palette" consists of a base size of tile (16x16), that also includes links to a superdivided (32x32 upto 64x64) and subdivided (8x8 downto 4x4) versions of the drawing-canvas image. The image it pulls from the drawing canvas (Tile Arrangement) layer, which includes the metatile's pixels and the metatile subdivision/superdivision data. This image data will always be the same for all subdivisions/superdivisions in the palette (since it all pulls from the source image).
Regarding palette UX:
The palette can be quickly swapped based on the keys you press (and hold) while selecting tiles using left-click and/or drag.
The palette would be mostly dynamic -- i.e. when holding CTRL, 8x8 tiles are displayed, ALT, 4x4 tiles, SHIFT+CTRL, 32x32, and SHIFT+ALT 64x64 (otherwise the palette shows the 16x16 base tile's size and imagery.)
The palette's canvas layer (its "Tile Arrangement" layer) can be changed by pointing a dropdown to another, separate, "Tile Arrangement" layer (i.e. where you draw "snow" on top of your tiles in the scene).
This ensures you can keep a palette and grab its imagery from "Tile Arrangement" layers.
You can duplicate the palette too (and all its subdivision levels) and have many "object palettes" associated with the palette you're working with, including subdivision/superdivision levels, which are pulled from the "Tile Arrangement" layer (and imagery) too. These can be "stamped" on a standard canvas (perhaps with a special tile-placement tool that acts just like the palette, to let you use CTRL or ALT to grab from tiles in a particular palette.)

Palettes could point to external files, but I'd suggest just making them grab from internal pixel layers honestly. Then, when exporting, offer the option to "compress" the tileset by removing the "extra" tiles from the "Tile Arrangement" layer imagery (or giving the user the ability to keep it, assuming they do want to preview what their tileset looks like inside their game engine with the test "Tile Arrangement" image. They can "compress" it later and save image space when they're ready to ship their game.

@dacap -- I know that's a lot to read, but it pretty much describes the whole system from start to finish. Let me know if I've missed something.

@EyeGem

This comment has been minimized.

Copy link

commented Feb 9, 2019

@awesomez

I know that's a lot to read, but it pretty much describes the whole system from start to finish. Let me know if I've missed something.

You should really show brief-but-complete graphical illustration (diagram) of wanted structure (what inside what and how edited). And write short description of it without supplementary details like controls/etc. (those could be read after structure was understood). Because it's really hard to fully understand what you want now.

@EyeGem

This comment has been minimized.

Copy link

commented Feb 9, 2019

@awesomez I think I finally quite understood first part of your descrption. It's a lot of redundant text there, but general idea is that you can edit canvas with parts of tileset images, with palette of those "sub-tiles" automatically reduced to remove duplicates, so it's easier to grab them and place them anywhere you want. Right?

If right that could be implemented vice versa, with smallest 4x4 tiles being basic tile size and 8x8 and 16x16 (and more) being meta-levels in that you can grab/place whole meta-tiles with or without palette of them, but then switch to smaller level and work there too. In essence it's just copying groups of smallest tiles and placing them grouped with some automatic assistance And this approach is compatible with overlapping tiles (at lowest for example 4x4 level, only if you want them to overlap). Of course you'll need export meta-tilemap operation, but it's just operation that automates export of meta-tiles-based tilemap, while Tilemap Layer itself will not contain any meta-levels, just simple tilemap of 4x4 tiles. Cool?

@dacap

This comment has been minimized.

Copy link
Member Author

commented Feb 9, 2019

copying groups of smallest tiles and placing them grouped with some automatic assistance

I think the difference is that tilemaps of 16x16 have indexes to a tileset of 16x16 tiles, no 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).

@EyeGem

This comment has been minimized.

Copy link

commented Feb 9, 2019

@dacap But composition of different sizes could be easily done with several Tilemap Layers, 16x16 as bkg, 8x8 over it and 4x4 over 8x8. The only thing will be images sharing between those layers. But it could be done with right exporter options (export from several layers as meta-tiles). Except for transparency override, yup...

@dacap

This comment has been minimized.

Copy link
Member Author

commented Feb 9, 2019

But composition of different sizes could be easily done with several Tilemap Layers, 16x16 as bkg, 8x8 over it and 4x4 over 8x8. The only thing will be images sharing between those layers.

I'm not sure if an arrangement of three tilemaps in that way could solve the metatiles problem correctly. From what was said, something like this is needed (in this case for only two levels/tilesets):

image

We could provide a completely automatic way to generate the 8x8 (or 4x4) tilemaps from the 16x16 images tilemap using some special export functions (something similar to this script).

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. E.g.

image

@awesomez

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.