I’ve been trying out Tiled over the past week or two, just playing around and experimenting with tilesets from a variety of sources – RPGMaker, several free games, that one website all about Wang tiles, OpenGameArt, and even a few I made myself just to try certain configurations. I have a lot to say about the system as a whole. (I also have a few sample maps and tilesets that I could share if anyone is interested, but this post isn’t about those.)
When it works, it’s amazingly good – enough that I’m thinking I might actually use it for my next 2D non-RPGMaker project. (Though it’s still uncertain whether it could have handled the very unusual terrain in my last project that’s sort of an unholy fusion of a blob and a 3-edge set, composed from subtiles in a 3x3 grid rather than the more normal 2x2 grid.)
One of the biggest issues I’ve found is that actually configuring the terrains is incredibly frustrating at times. Finding eishiya’s copy terrains script helped a great deal in some ways, but it’s still really bad.
Ultimately I think the problem can be boiled down to one sentence: there are no tools provided to identify the mistakes you made.
Some common mistakes I’ve made while configuring terrains:
Accidentally missed one corner. Thought I was done, but one of the patterns wasn’t dimmed out. Spent several minutes hunting for the offending pattern.
Accidentally miscoloured one corner (eg, put sand on a water corner). Otherwise, same as above.
Want to make sure you haven’t missed one of the tiles in a blob set? Get ready to stare really, really closely at the pattern list and try to identify if any of the non-dimmed ones are blob tiles.
I think many of these problems could be solved by filtering. Currently, the patterns list is almost useless, unless you’re making a complete edge or corner set (or if your set is incomplete, at least it’s only 2 colours and not a blob). This is mainly because there are just too many items in that list. Being able to filter it to only show the ones you actually care about would greatly speed things up.
Some examples of things I might want to filter by include:
Show only patterns that have been defined (dim patterns) or not defined (bright patterns). With this you could easily tell if you have a complete blob – just count the patterns and note that there are 47. (In fact, Tiled could count them for you and say “showing 47 of 256 patterns” somewhere.)
Show only patterns that contain a specific colour or colours. For example, if you have a 4-corner set, show only the 16 blue-to-green patterns, or only the patterns that involve red in some way.
Show only patterns that have exactly a specific number of colours.
Show only patterns that are rotationally and/or reflectively symmetric to a given pattern.
Show only one of each pattern in the symmetry equivalence class. In other words, if you’re making a 4-edge terrain that allows rotations and reflections, you should only see 55 tiles instead of 256.
Show only the tiles used by the blob. Even just this as a checkbox (without any of the above options) would be a huge help.
Other than filtering, it would be helpful if patterns that have duplicates are marked with small number in the patterns list. If you know your terrain has no duplicates, that would be an immediate red flag! Also, some way to click on a pattern and locate the tiles that are actually marked with that pattern. Then you could instantly locate the one that was erroneously made a duplicate and fix it.
I have lots more to say (I’ve been taking notes the whole time), but I think I’ll stop here for now.
I could probably create actual GitHub issues for much of this, but I decided I’d rather put out all out in one place first, and maybe issues can be created later.
Indeed the Patterns view is almost useless in its current form, and being able to filter the combinations it shows would be a big improvement. I also very much like the idea of adding a number showing how many times a pattern is used and the ability to locate tiles by clicking a used pattern.
You’re welcome to create issues about such features! GitHub now supports subissues which could be a good way to both split up the potential improvements as well as to group them into a more general issue about improving this aspect of the terrain system.
I’ve had some related thoughts that I don’t feel are issue-worthy so I hope OP doesn’t mind if I drop them here:
Include patterns with Empty (Empty+1 Terrain is IME by far the most common scenario where patterns would be useful), BUT
Big +1 to filtering by included colours, and ideally save this filter preference on a per-Terrain Set basis. Some Terrain Sets include terrains that are only used for a few specific tiles and should not be included in patterns. Some Terrain Sets may want to filter out Empty.
Perhaps include an option to show only Empty + 1 Terrain patterns, as that’s a common scenario.
Seconding marking duplicates with a number representing how many tiles use a given pattern. However, I think to make this even better, it would be nice to have a (customisable) threshold above which the number is shown, so that unwanted duplicates stand out visually. If I expect 4 variant tiles for each pattern, then setting the threshold to 5 would make it easier to spot when I’ve made a mistake. Alternatively, always display a number, but allow setting a threshold for when to show the number in red or something.
It would be cool if a selected pattern could be transformed like stamp brushes (I think it would be fine to have no GUI buttons for this and only allow it with hotkeys, since the full set of transformed patterns is also available). Then, it would also make sense to include filters to hide transformed variants of patterns, without it being a problem that the specific variant displayed by Tiled doesn’t match the variant needed by the tileset.
Include patterns with Empty (Empty+1 Terrain is IME by far the most common scenario where patterns would be useful),
I had that thought too. It bugs me that the “isolated tile” (consisting of a blob of one terrain surrounded on all sides by another terrain) cannot be represented in the system – treating transparency like a first-class terrain in the colour would help a lot with that. I think a good way to handle it would be to designate one colour as transparent in the terrain set definition. Maybe you could enforce that transparent is always the first colour, but that seems unnecessary.
I think there could also be a difference between “set to transparent” and “not set”, though I’m not entirely sure what it would be. Maybe “set to transparent” only matches if no other tile is on the adjacent location, and “not set” will match regardless of what’s on that location?
Perhaps include an option to show only Empty + 1 Terrain patterns, as that’s a common scenario.
Does this mean that they have 3 sides marked “blank” and 1 side marked in any other colour? I think that would fit into the “exactly N of colour” scenario I mentioned, assuming transparent is itself a colour (which it’s not right now). In other words, you want tiles that have “exactly 3 transparent edges”.
Then, it would also make sense to include filters to hide transformed variants of patterns
Yes, that’s what I meant when I mentioned the symmetry equivalence class. There’s 8 possible symmetry equivalence classes; I’m not sure if it’d make sense to include all of them in filtering, or just automatically use the one configured on the current tileset. Would you ever want to filter out reflected patterns in a tileset that normally doesn’t allow reflection?
You’re welcome to create issues about such features! GitHub now supports subissues which could be a good way to both split up the potential improvements as well as to group them into a more general issue about improving this aspect of the terrain system.
I’ll consider creating the issues, but I’d prefer to let you deal with subissues or whatever. I barely use GitHub anymore anyway…
Beyond the pattern list, another thing Tiled often struggles with is incomplete terrains of various forms. Some cases I’ve seen include:
Edge sets that only have a centre and stubs[1], but the centre can work perfectly well for all the missing parts (edges[2], corners[3], and narrows[4]). For example, this table set:
(This set, and any others I post of similar proportions, is from Blades of Exile.)
Edge sets that have everything except the stubs[1:1]. For example, this fortress set:
Here the straight walls can work perfectly well as stubs. Without them, Tiled tries to force you to place only loops. Though, admittedly, this is a case where you’d probably want loops 80% of the time.
Edge sets that only work in one direction – either they have the 4 horizontal tiles, or the 4 vertical tiles. In RPGMaker, the horizontal type is encoded directly into the standard A1 tilesheet. It has some of the vertical type too, but they aren’t recognized as autotiles and you need to place them manually (these also omit the isolated tile, meaning they must be at least 2 tiles high). I’ve tried a few ways of representing these with varying success. (No sample image here, as RPGMaker graphics aren’t free. Sorry. But you can probably find some by searching the RPG forums or other similar places for keywords like waterfall, stairs, ladder, rope)
When it comes to these “half-edge” sets, I’ve even wondered if it would be worth encoding them as an entirely separate type of terrain from the normal 4-edge Wang set. You could say that these tiles work like “dominoes”. Many of them expect to be placed only in a single line (ladders, ropes, vines), but there are also quite a few that work more like walls, where you’d expect several rows of them in succession (but, generally, all of the same length). Stairs, bridges, and waterfalls fall into the latter category. Another example I’ve seen in RPGMaker is tilled fields for farms.
This could be conceptually extended to corner sets too, but having special cases for each of the diagonals makes less sense to me. I don’t think I’ve seen anyone do this before. It’s also trivially extendable to multiple terrains – for example, with 3 terrains you have 9 patterns.
For that matter, I’ve also vaguely wondered if there should be a possibility for centre-marked terrain sets. I’m not entirely sure of the utility of this, but it seems I’m not the first person to consider it. With that, you’d add “edge+centre”, “corner+centre”, and “edge+corner+centre” as options. With half-edges, those would also get a +centre variant. But again, I’m not really sure about this. It does sort of solve an ambiguity in corner sets; it seems far less useful in edge or mixed sets.
I still have more to say… I’ll get to the rest later.
I meant patterns that include markings in only Empty and a single other terrain, but that other terrain can be any non-empty terrain, and the pattern may consist entirely of Empty or entirely of a terrain. These are common for e.g. platformer blob terrain sets where there may be many different terrains, but each one only interfaces with Empty. So for example, if a terrain set has Red and Green terrains, this mode would show patterns that consist of all Red, all Green, all Empty, Empty+Red, Empty+Green, but NOT Red+Green or Empty+Red+Green.
I see no benefit to changing the way Empty/Transparent currently works, there’s no point in splitting it up into two different things. Empty/no-terrain already works like a special terrain with ID 0. There’s even a PR to display it as such.
Tiled’s Terrain system cannot treat the same tile as having two meanings (e.g. straight section vs stub). Tilesets like that should instead use Automapping, which works in a different way that can handle ambiguity.
Re: centre-marked squares, that would actually solve two long-standing issues with Terrains, as I wrote in the issue about it :]
I’m not entirely sold on the usefulness of it being two separate things (it was just a thought I had), but showing it as a terrain in its own right would definitely be good.
I understand that it can’t handle that, but I don’t understand why. It just needs to place the tile that’s the best match. If there’s no stub, that tile is a centre tile or a straight tile. How is that so complicated?
I guess it could get a bit confused when the tile already present has multiple interpretations (I think I saw someone, possibly you, mention that in another thread). But is that really unresolvable? I think in the sample I showed the only valid outcome in such a case would be… place the centre tile.
But speaking of automapping… I looked at the documentation and immediately quailed. It sounds awful. Admittedly, I’ve yet to try it so it might be less awful than it sounds, but I think Tiled desperately needs a more user-friendly way to define automapping rules.
It’s not associated with a tileset. It’s defining rules for your tileset, but it’s not associated with the tileset? So, you’ll need to copy those rules over if you want to use them in another project that uses the same tileset. Why?
You have to edit an external text file. It has syntax that you can easily get wrong. Since I haven’t tried it, I have no idea what happens when you get it wrong. I think the rules.txt should be moved into a list-of-strings property on a tileset. It could also be a property on maps, and… do projects have properties? Maybe there’s merit in external lists, but it doesn’t seem great as a default.
Filters by… map name? Is that useful? It doesn’t seem useful at all. Okay, so maybe there could be some case where you use the same tileset in a “forest” and a “town” and you want certain automapping shortcuts to only work in one of the two, but… map filename strikes me as a terrible way to handle this. Do people normally name their maps “Town1.tmx”, “Town2.tmx”? Myself, I’d name them by the actual name of the town (possibly an abbreviated name, or some other mnemonic, but probably never [type][number]). I’d think filtering by map properties would be far more useful. Put a “Map Category” custom property on your maps, and specify that a rule should be used on all maps where it is present and set to “Town”.
Rule maps are map files, which… almost makes sense. I mean, you’re trying to define rules about how some terrain placements are automatically substituted. It’s not very friendly, though. I mean… it’s not really a map. It’s almost a map, but not quite. It requires syntax – the “special automapping” tileset is a set of “reserved words” for this automapping language. So, I think it would make more sense for Tiled to treat it as an entirely separate type of object… though it could still be saved as a tmx file and be identified as a rule map by some property after loading.
Layer names are meaningful. More syntax (the less syntax the better; I think the actual on-map syntax is sadly unavoidable though), and another reason to treat them as an entirely separate type of object. If you’re editing a rule map, instead of “Add tile/object/image/group layer”, you can have “add rule” and “add input for current rule”, and “not” can just be a checkbox (probably beside the visibility eye). (Even if you weren’t treating a rule map as an entirely separate type of object, I really think it should’ve been based on the concept of “each group layer represents one rule”. But, I guess maybe the system predates group layers?)
The special map properties are “magic” that you can only find in the documentation. If a rule map were an entirely separate type of object, they could just all be automatically added to the properties panel for the map, each layer, and any created objects on that map. You could even have properties that are only valid on “inputs”, only on “outputs”, or only on “the entire rule” (internally, a group layer).
Maybe some of that can be solved with a “Create Rule Map” script. Again, this is all just from reading the documentation – I’ve yet to actually try this system. And… possibly, I might not even be able to try it in full, because I just noticed that it’s impossible for me to add a non-integer custom property on MacOS. The dropdown to select a type closes instantly – I think what must be happening is that focus to the text box is lost and that causes the entire widget to vanish, taking the menu with it. I think this was still working in the previous version though.
It’s true that automapping might work better than autotiling (conceptually – ie, even if autotiling were improved to be able to handling it) for the table set I showed earlier. I doubt it would be an improvement for the fortress set though. As for stairs, bridges, and the like, I’m not sure; I’d have to try it. But they feel like they’re more meant for autotiling than automapping. Other places I feel automapping could be used are for 2x2 or 3x3 blocks of tiles that should be placed together (though, you could also select them all and place them as a block… unless they’re not arranged in their proper block on your tilesheet), or for the 2x2 tileable trees that you see in RPGMaker (can’t post an image, sorry; they have a 2x2 tree, and a 2x2 block of the same tree hemmed in by other identical trees on all 4 corners).
The cliffs example in the documentation is also a pretty good one, but… there’s one small problem with it. For an RPGMaker tileset, I’d absolutely want a rule like that, but the problem is, it would need to work with the terrain brush. Place a rooftop terrain, and its matching wall automatically appears below it. (Well, maybe that can actually be handled by autotiling though. It does seem similar to one case I saw mentioned elsewhere; I guess I’ll try it.)
And now that I’ve finished complaining about it, maybe I’ll go and actually try it out a bit.
Oh! That’s actually another thing that was on my mind! It occurs with the bridges and rubble in this set:
The main terrain is a corner set (it actually works really well as a 4-colours set!), but the bridges definitely want to be edge sets, and it’d be great if they could choose the correct shore tile to match the adjacent shores.. You could maybe argue for the rubble and the large town being edge sets too, though the town isn’t very compelling (why would you want a 7-tile-long town?).
My own thought for handling this would be to allow setting tile probabilities separately from the tile, as part of the terrain set definition. But you’re right that marking the centre could also solve this – all the bridge tiles would have their centre marked as “bridge” and two edges as “water”, and I guess their corners (for the end tiles) would be marked with the shore terrains.
The problem in this specific case could also be solved by separating the bridges out into transparent tiles, but… I don’t know that every similar case has that possibility.
The reason is that Tiled pulls the Terrain arrangement around the cell from the tiles already there as well, it needs non-ambiguous definitions to be able to do that in a way that doesn’t make Terrains computationally explosive. Having centres defined wouldn’t solve the problem, centres can be ambiguous too.
Automapping rules aren’t “for your tileset”, they can include tiles from any number of tilesets. That’s also why rules.txt can’t be on a tileset.
I think I was the person who asked for this feature. I find it very useful, mostly for performance reasons because I have thousands of rules. For one Metroidvania game, I used [areaName][number] names and the area names could be used for filtering (though for that game I didn’t do much filtering because there weren’t that many rules). For another, I have [SpecificName]_[type] like BlairHouse_int and BlairHouse_ext, and filter on the type, but the specific names also often include useful keywords I can filter on, like House, Street, River - haven’t needed to yet, but it’s an option.
Filtering by map properties is an interesting option, but it’s a lot more work for the user when working with many maps. Most people already name their maps in some way meaningful to them and can use that for filtering if they need it, but properties would require adding those properties on every single map that needs to be included in some filter.
The main missing feature keeping name-based filtering from being more useful IMO is the lack of multiple filters per group of rules, allowing e.g. [myType*, exception1.tmx, exception2.tmx] filters. This was in the original feature request, but was not added because it’s difficult to make a simple but unambiguous syntax due to file names being very flexible.
The fact that rules maps are maps, possibly but not necessarily using special MatchType tiles, using the same editor as regular maps is a compromise.
Layer Groups are transparent to automaps, which makes them very useful for managing complex rules with many layers (it’s not unusual for certain types of rules to have tens of input layers, for example). It’s also very useful that layers are shared between rules, makes copy+pasting easier, and many related rules often have the same layers.
While I’d love to have a special editor for rules (though I’d be fine with the rules continuing to be stored in maps), I’ve struggled to design one, and I’m someone who uses Automapping a lot. The system is so powerful and flexible that it’s very difficult to improve the workflow in a way that doesn’t detract from some type of rule or other xP There’s a lot of tedium I’d love to see automated (and I have written scripts to that effect), but fundamentally, editing rules as maps has a lot of seemingly minor advantages that add up and any special rule editor would end up duplicating the majority of the Map Editor’s features, so I think mostly I just want more built-in automation for certain tasks (like populating enumerations of tiles), and exploded views (which sounds like it should be a trivial matter of offsetting layer display, but to actually be useful it’s way more complicated than that).
You shouldn’t need to add any custom properties manually to use Automapping. Tiled automatically identifies rules maps when it sees them (create an input_Something and an output_Something layer, that should be enough), and shows placeholders for all the properties. You also don’t need to add the MatchType properties to your own tileset, you can add Tiled’s built-in MatchType tileset to your rules map in the Map menu.
Still, the custom property type selector closing sounds like a nasty bug. Is this with the new properties view (1.12+), or the old one?
Automapping and Terrains can work in tandem. I think the example in the documentation actually was built around that - the cliff-top is added as a Terrain, and Automapping adds the cliff. Automap While Drawing even allows adding the cliff as you draw the cliff-top, though rules that can work While Drawing often need to be more robust since they can’t assume a clean input and may be working with previous Automapping output.
You can have multiple terrain sets in a map, which means you can define some Edge data on the shore tiles to allow Terrains to select the correct bridge-end tile. As long as you never paint with the shore terrains in the Bridge terrain set, you shouldn’t need to mess with the tile probabilities at all.
Still, it does feel a bit hacky, and erasing bridges is still a mess. I think tile centres would help in this case, since they’d allow the corner terrain to include markings on the bridge tiles while still communicating that they’re bridge tiles and not just water/shore tiles.
Well no, that’s not really true in general. Sure… perhaps not all rules could be confined to a single tileset. But I think a lot of rules could be; and carrying such rules along with the tileset seems much more sensible to me.
I wouldn’t say “duplicating”. A rules editor clearly needs to be a special case of the map editor. You’d use the map editor as a basis but add additional bits on top – such as distinguishing input and output layers as entirely different layer types, and encoding the index and layer filter information into a core property of the layer instead of its name (maybe in the properties panel, but also, potentially, exposed directly in the layers list). The automapping tileset could just be added automatically (I don’t even know why you’d want to define your own MatchType tiles instead of using it).
It’s the absolute latest (1.12). I think it was still working several weeks ago (whatever the previous released version was). I opened an issue for it:
Okay, great! There’s one thing that’s not nearly as bad as I thought it was. But that makes me think – it’d be great if you can assign a “description” to custom properties, to give more information on what it’s meant to be used for. For these, the description could be automatically set to the documentation; for other custom properties, it would probably be helpful if you’re in a team where one person creates the properties but other people (usually) set them. Similar to how in Unreal Engine every property has an optional tooltip.
That’s fine; what I was after was RPGMaker-style wall pairs, where both top and side are a terrain. I don’t think automapping supports painting terrains as part of the output.
I did try putting both terrains in the same set, and it sort of worked, but not well. Or… if I recall correctly, it worked okay for the cases where top and side are both edge sets, but not very well when the top is a blob and the side is an edge set. I could’ve just had an error somewhere in the terrain configuration, but…
I think I tried that, making the set an edge set and painting bridges on the edges and everything else on the corners, but I don’t quite remember.
So I did try out automapping a bit, and it’s a bit of a pain to get it initially set up. My general impression of the system is that it does, indeed, work quite well once you get the rules set up properly (though, I have yet to try any more complicated cases). My instinct is to want to “categorize” my rules by the terrain they work with, but there’s no way to do that. I tried to group my rules like this:
And that does not work the way I imagined. Firstly, the rule suffix is a layer name instead of a rule name, like I initially thought. Secondly, those rules cannot all be enabled simultaneously as defined here. If they’re all renamed to target the same layer, they get mashed together. From what I understand, it would work fine if all the input layers and all the output layers were merged into one rule, with the possible exception of the case that has two input layers. I didn’t try this however – I just split each group out into a separate map.
Mashing all the rules together into one pair of layers would mean I have no way to categorize them even remotely like the screenshot. I think the best I’d be able to manage would be to add a layer that’s neither input nor output and put a bunch of rectangle and text objects on them.
The rubble rules didn’t work very well. As seen in my earlier posts, they are basically an edge set that works in only one direction, so using automapping for them seems like a poor fit. I probably just missed some of the rules needed to make them all work, but still, I think it’d be better if the terrain system can handle them.
Oddly enough though, the towns worked just fine? I don’t know why that is, when they’re the same sort of format as the rubble. The tables also worked fine, despite technically also being edge sets. I also tried out two more not shown in the screenshot – automatically adding plates to a table when you put a chair in front of it (those tiles aren’t shown in my earlier posts), and automatically placing a full 2x2 mandala when you place any corner (which is really a better fit for a saved stamp, but still, it works in automapping).
I think requiring every rule to target exactly one layer isn’t right. It might be what you want sometimes, even often, but in the case I was experimenting with, it would’ve been preferable if I could just not care about layer names. There is only one layer. I want to target it. It coincidentally happens to be named “Tile Layer 1”, but I don’t care about that. If I could name the layers input_* and output_* and it would target every layer, that would be perfect. It’s possible that this thinking would change when I work on a proper project, but still. What I ended up doing is calling the rules input_* and output_* and renaming my sole tile layer in the actual map to *.
The rules.txt also doesn’t support wildcards. I can’t say “include every map in this folder” or “include every map nested at any level beneath this folder”. If you list a file that doesn’t exist, everything breaks and no automapping will work. Sure, you can just comment out the offending line, but it’s such a simple error that the system could just ignore the missing file and continue with the ones that do exist. (Why did I do that? I was going to create them one by one and test each one before moving on to the next. Instead I just created them all, then tested them one by one.)
I think most of what I said in my previous post still applies, with the exception of the special properties complaint – it looks like that already works as I’d hoped.
I think I’ve said almost everything I can think of about the terrain system, but here are a few more things that got missed.
Isometric maps
The terrain support for isometric maps is quite nice actually, and I was happy to see that I could paint the edges of a lozenge instead of a square. But I still have one complaint about the patterns list – it still draws the patterns as squares, making it even harder to tell which tile has which pattern on it.
I also had difficulty in putting elevation on my test isometric map. I was using the following tileset from Blades of Avernum (note: it’s probably not okay to use these tiles in anything else – unlike Blades of Exile, BoA has not been released as open source):
The slants in the bottom two rows (and also the two diamond tiles, which are cliffs)) are intended to lead to a higher (or lower) elevation.
In order to make it work, I needed to make a separate layer for each elevation, offset by a certain amount. This absolutely works, but having connected patches of terrain being on different layers makes things difficult, both for me and for the autotiler.
It would be nice if there were some built-in system for elevation on isometric maps. It would need to identify which tiles indicate a change of elevation and automatically adjust tile offsets based on that. I imagine it could get pretty complicated if you don’t properly close up your hilly areas though, so I could understand wanting to just avoid this idea entirely. But I did think it was worth mentioning.
Personally, I like the idea of being able to associate an elevation with each space and have rules automatically place the elevation-switching tiles between spaces of differing elevation. Perhaps this setup could be handled with scripting and/or automapping.
Hexagonal Maps
Terrain support for hexagonal maps is nonexistent. There isn’t even an option in a tileset to set to hexagonal? I think there probably should be.
The terrain markings are still square, so of course you can’t properly mark anything. eishiya mentioned elsewhere that centre marking would break some 64-bit storage – this certainly would too, because now you have 6 corners and edges instead of 4, so if you include the centre, there are up to 13 points of interest on a given tile.
A hexagonal corner or edge case would have 64 possible patterns with 2 terrains, and a mixed set would have 4,096… no-one would ever do that. Apparently, applying the same reduction as the square blob produces 323 tiles, which is still pretty crazy, but it can be reduced to 48 if you allow rotations and reflections. Of course, these rotations would need to be by multiples of 60° instead of 90°.
I think you could just say that hexagonal terrains are actually entirely separate types from square/isometric terrains. Then the tileset maybe wouldn’t need to know that it’s hexagonal?
Come to think of it, the difference in rotations would also affect the stamp tools, since you can select a rotation when placing the stamp. The current UI is extremely bad for this, mind you, mainly because there is absolutely no feedback on what the currently-active transformation is. But anyway, if supporting hex tiles, you’d probably want to replace the “rotate left” and “rotate right” buttons with a “select rotation” dropdown, where you can select from 90°, 60°, 120°, 180°, -90°, -60°, or -120°. I don’t know whether it’s worth filtering out the hex rotations on orthogonal maps or the square rotations on hex maps – maybe there’s a use-case for placing a 60°-rotated tree on your orthogonal map!
As a small aside, it might be interesting to see support for triangular maps too. I think you could actually make triangular maps in Tiled right now (set them as hexagonal and define your tiles in such a way that each placed tile is actually 6 tiles – for example, using the collision editor), but is dedicated support worthwhile? Triangles aren’t very popular, and for good reason – since they’re not bilaterally symmetric, you need two completely separate sets of tiles unless you allow reflection and/or rotation. This means a triangular edge set still needs 16 tiles. Still, a triangular blob only needs 38 tiles instead of 48, so there’s some small savings there, I suppose.
Other
It’s a bit of a pain to make a tileset that uses multiple source images but treats them as tilesheets rather than individual tiles.
So, technically, it’s not like it’s that hard to do – create a map with an embedded tileset, import all the sheets as tiles, and place them in some non-overlapping arrangement on the map. If the sheets are all the same size, you can even make that size the tile size for the map; if they’re not, you can still do this, but it’s probably better to use the same tile size that they’ll eventually be cut into. Then create a tileset referencing that map as its image.
But the problem is, this only works when the sheets do not have margins or spacing. As soon as they do, the process starts to break down. It still works for uniformly-sized tilesheets if you’re careful, but it can easily end up clipping off the margin, making the result unusable for a tileset (since Tiled only supports uniform spacing and margins – you can’t have a 1px margin on the left, 2px margin on the top, and 4px margin on the right and bottom).
The terrain sets are listed in the order they are created. There’s no other way to view them. If you want to see them in alphabetical order? You better make sure you create them in that order.
I think you should be able to drag-and-drop to change the order.
Well… technically, it turns out there is a way to reorder them. Select each one in the order you want them to be, and press Duplicate. Then, delete the old version of each one. And if you have lots, you’d better hope you didn’t miss one. (I guess you could minimize that risk by duplicating and deleting one at a time.)
The same could probably apply to terrain colours. However, not being able to reorder those isn’t as annoying.
It’d be great if we could define stamp templates where you select a tile (or block of tiles) from the palette and it can automatically build up the stamp from a set of offsets relative to that tile. The use-case I see for this is RPGMaker-style compressed tilesets – you could define a stamp that maps the compressed 2x3, 2x2, or 3x4 block into its full blob or edge set, thus rendering eishiya’s expand script (and, perhaps, some of the work I did to improve it recently) largely obsolete. Just activate the stamp, select the block to apply it to, and instantly place the expanded set anywhere on the map.
This could be useful for painting terrain markings as well. Once you’ve plopped down all your blob-expansions of the tileset in the exact same pattern on a map, you can create a tileset using that map as its image, select a terrain stamp, and click once on each blob to configure the entire terrain set in one go. This would be pretty similar to eishiya’s copy terrains script, except that the terrains being “copied” are a saved configuration rather than anything on the current tileset.
The way terrains and tiles are separated in the palette really confuses me. First you select either “terrain sets” or “tilesets”, then you choose the tileset you want to paint from. (If you’re painting a terrain, that means scrolling through a potentially very long list to find the tileset you want.)
But terrain sets are already part of tilesets. I think it would make more sense to be able to select the tileset you want to work with, then choose either “terrain sets” or “tiles” as a subview.
There’s probably some merit in having one view with all the terrain sets from your collected tilesets. However, in my experimentation I’ve built up 20 or more incompatible tilesets (of different sizes and even orientations), so for me it’s been more annoying than useful. Though, it wasn’t quite so bad once I realized that the criteria for a tileset to appear in the palette was for it to be open in another tab. Maybe I just have to get out of the habit of leaving everything open all the time.
That said, I think it could still be useful to add a few filtering options to the tileset list – for example:
List only embedded tilesets in the active map.
List only tilesets with the same tile size as the active map.
List only tilesets in the same folder as the active map.
The first one would be especially useful – if I’m editing a metatileset’s source map, I don’t want to accidentally place tiles from the tileset that references it. Actually, that should probably just be automatic – don’t list tilesets that directly reference the active map as their image. Circular references in tilesets are bad!
Also, aside from filtering, it would probably be good to mark the embedded tilesets somehow, so you can easily distinguish them from external ones. Maybe add a little icon beside the name?
(I didn’t read your entire post, way too long xP Hexagonal terrain support has an issue open about it, FWIW. I think a lot of what you seem to be talking about might be better off in separate threads, and there are existing issues on GitHub or existing threads here for some of it.)
You might work with largely tileset-bound rules, but that doesn’t mean everyone does, or that even the majority do. For example, it’s fairly common to use guide or prototype tiles and have Automapping place the final artwork, and these guide/prototype tiles are often in separate tilesets that are never seen by the game engine, because they’re only used during the early stages of authoring maps.
You would do well to remember that there are probably many ways of working you haven’t encountered, and that when a feature works in a way that isn’t ideal for you, it may be because it’s needs to deal with those additional workflows. It’s good to mention ways in which features don’t serve your needs so that they can be improved, but the way you’ve been wording them is somewhat demanding and ignorant.
Automapping doesn’t “place Terrains”, but neither does the Terrain tool! The Terrain brush looks at the tiles on the layer and the terrains they have assigned to them to determine matches, and places tiles. Tiles placed by Automapping are treated the exact same way (just placed via rule logic instead of Terrain logic), since they’re just tiles in the layer(s). So, the Terrain tools will take them into account exactly the same way as tiles placed in any other way. I quite often use Automapping in tandem with Terrains - Automapping reacts to/modifies tiles placed by Terrains, Terrains build on tiles placed by Automapping, and so on.
I think most of your questions about Automapping are answered in the docs. It may take some careful reading - it is a complex feature with a front-loaded learning curve, and the docs aim for readability, which means things are usually explained only once rather than over and over, and some more complex implications are left between the lines. Once the basics click enough to where you can start experimenting, it gets much easier.
Tiled determines what a separate rule is based on contiguous regions within the map, across all layers. So, if your different rules occupy the same space in the map, they count as a single rule, even if they’re in different groups. Generally, unrelated rules that target different things are best placed in separate rules maps, to avoid any risk of collisions and confusion. So you might gave a bunch of Town rules in one map, a bunch of CaveRubble rules in another, and so on. It is possible to put everything in one since (as of somewhat recently) Tiled ignores input and output layers that are entirely empty for a region/rule, but it makes editing the rules a pain.
I can’t give you specific pointers on why your rules aren’t working without having seen the rules. Due to their context-sensitive nature, debugging someone else’s rules can be quite a pain xP If you need Automapping help, you should make a separate thread and post your rules in detail (and if possible, include the rule maps, working maps, tilesets, and tileset images so that anyone helping can reproduce the issues).
I feel like you’re playing around with Tiled’s various features and posting all of your thoughts - while that can be very useful, I advise you to write those thoughts down offline first, and then come back to them once you’ve had more time with the features. Then, you’ll know what were real problems, what were brainfarts, what were documentation shortcomings, and will be able to organise your thoughts in a way easier for other people to understand. First impressions like these can be very useful, but without some translation from you after you’ve had more time with the program, they’re difficult for people experienced with Tiled to understand.
That’s fine, but I’m saying that for cases where the involved tiles are confined to a single tileset, it’d make sense for the rules to be bundled in with the tileset (or at least, the list of references to rule maps; but I think it’d be great if the map itself could also be bundled in). I think it could sometimes make sense to bundle them in with maps as well (you might have rules that you expect will only be useful on that one map). And even if external rule lists (ie like rules.txt) are absolutely needed in some cases, I’d still really prefer not to edit a text file. Maybe put something in the project system to configure rule lists using a list box. (I still haven’t tried creating a project.)
Sorry if it came off as demanding. It definitely is ignorant to some degree however – I’m only trying these things out for mostly the first time, so I certainly don’t have a huge set of knowledge on how other people use them.
Sure, but my point was that the wanted behaviour is that two terrains are always adjacent even though they have no transitions between them. Probably the correct way to handle it is to make them both part of the same set, rather than using automapping. I wasn’t able to figure out the exact configuration to make that work though.
No worries, I more or less got them all working. The rubble ones weren’t perfect, but I just decided to stop working on those ones.
This is actually what I did. Some of these thoughts are from last week or a few days ago. I filtered out some things I wrote down that I later realized weren’t real, that I later found ways to do, etc. For example, I never mentioned my wish that you could type formulas into the number boxes because that was implemented in the latest release, and I omitted some of my thoughts on RPGMaker-style compressed sets in large part because I discovered your script to expand them (which I also improved quite a bit).
While this makes sense, I think that first impressions are also pretty important. That said, my first impressions are broadly good, so that’s a great. I also limited it mostly to talking about the terrain system specifically, though I ended up getting off topic a few times; there were other things I noted down that aren’t directly related to terrain. I think most of them have either been mentioned in an aside by now or opened as GitHub issue, though. Some of them were semi-resolved by finding your repository of scripts.
I’ll certainly do that if I have trouble with anything complicated that I can’t work out. The examples I’ve posted in this thread are just examples, not things I need help with.
