I have been using Tiled to insert “player units” on a map by using a “Player Unit TileSet” and a separate Unit Tile Layer. So far this has worked well, except…
The problem is: I would like to have the same type if unit have different Custom Properties at the instance level, but as far as I can tell, TileSet Custom Properties, when changed, apply to ALL instances of a given Tile, precluding the ability to change individual instance values for the units that I place on the map. For example, I want one infantry unit at full strength but another - otherwise identical - infantry unit have x casualties.
I read a post on this exact topic in the Forum, and the suggestion was to use an Object Layer instead, and then place the units (from that Unit Tileset) on the map via the Object layer “Insert Tile” button. So I am experimenting with that idea.
Here is an example, and I have two questions so far:
Is it possible for the Objects to inherit a name from the original TileSet? I notice when I place them, each instance of the three infantry units placed is assigned no name (red circle). It would be very handy if the default name assigned was related to a property in the TileSet Tile selected. Possible?
Is it possible to have the Object “snap-to” the map grid, so that they are forced to - in this example - land inside one of the hexes? In my experimenting, Objects appear to be entirely free-form, whereas in a game such as this, the units I place must be contained in - and identified with - a specific hex coordinate.
If the answer to this is “yes”, then can the .tmx output explicitly link the object to the map coordinate? Inspecting the .tmx file from this example, it appears they are stored as x,y pixel coordinates rather than x,y map coordinates.
I think ideally you’d need to be able to place tile objects on tile layers, though the support for free positioning, rotation and scaling does not work well in combination with the grid coordinates. Hence for now you’d need to map the pixel coordinates to tile coordinates after loading the map.
There is snapping, but I think it isn’t working nicely to align things on hexagonal maps. That is something I can look at fixing in the short term.
This request is similar to inheriting the type, and of course it makes total sense. The problem is to figure out exactly how to support it. I could just special-purpose “name” and “type” custom properties, but that seems inappropriate, so I’d probably opt to add built-in fields for these. The thing is that I don’t want to make things too complicated before possibly adding support for more advanced object instantiation (though probably it makes sense to add these things and postpone such bigger changes for a later, when it would be fine to break compatibility).
Any thoughts on timing of the changes implied in your post? The game our team is developing has successfully used Tiled to develop maps, but we’re stumbling now on the “unit placement problem”. We are currently using a 2-step process of: (1) build and export the map, then (2) place units using another package. We’d love to combine this back into a single package!
Another way to solve both problems, naturally, would be to allow Tiles (as opposed to Objects) inherit and instantiate at the map level, and then be modifiable at the instance level. In which case, I would go back to my original approach of having units simply be Tiles, because they already snap-to hexes properly and are linked to map coordinates rather than pixel coordinates.
Said another way, if you consider an overhaul of the instantiation system, why not make the Tiles themselves individual instances that can be uniquely modified as needed? They can (and already do in fact) inherit the “default” values defined in the Tilesets, but once instantiated, Custom Properties become modifiable at that level. A thought anyway.
For this week I was still busy with the group layer feature, but I can try to get around to looking at improving the snapping and doing the type/name inheritance next week.
There is definitely a use-case for a layer that combines the aspects of the tile layer with the aspects of the objects layer. I’m not sure yet whether this should be a new layer or an option for one of the existing layers, but in any case I need to be careful not to make things too complicated. I’m hoping that fixing the snapping will resolve most of the issue.
@Remusforte Just a heads up that unfortunately adding support for text objects took way more time than I had anticipated, leaving little time to work on the things requested here.
I had a quick look at the snapping problem, and it’s a little complicated. The problem appears mostly because tile objects have their origin in the bottom-left, whereas the snapping happens to the top-left area of a tile. On a hexagonal map, this means the snap position is never what you’d expect for tile objects (though it’s somewhat useful for rectangle objects). I’ll need to consider some kind of solution to this.
