Not a problem but asking about best practises for managing layers.
I used to do collision at the specific layer ( ground, roads, fence, rivers, buildings, trees ) but after watching a video on AutoMap, I think having a separate collision layers sound like a better choice and easier to troubleshoot and change especially for going behind the buildings.
What are other users suggestions or feedback on this topic ?
What are the pro and cons of having an extra layers ??
I sometimes outsource the map designs to multiple map designers so giving them a fixed collision layers could be easier for me to trace or troubleshoot collisions instead of going to layers after layers.
Game engine is Phaser3, RPG style game…
I use a special set of tiles to represent different shapes and types of collision. My current project is a sidescroller with solid ground, one-way platforms that you can jump up through and jump down from, and slopes that you always slide down from and can’t stand on, and I use different collision tiles for these.
Here’s an example with solid and one-way collisions:
Pros:
- There’s just one source of truth for collision, it’s always clear where collision data is coming from. As you said, this makes it easier to troubleshoot problems. My game has at most one collision layer per map, but this method is especially good for games with multiple layers of collision (e.g. top-down games with bridges you can walk under), as you can very clearly see what and where each collision layer is, and don’t need to separate your cosmetic tiles into as many layers just to accommodate auto-collision.
- The collision is schematic, it’s very easy to see exactly where it is and its exact shape, which may differ from the cosmetic tiles.
- You have more control over the visualisation of the collision, since they’re just tiles.
- You can combine collision data with other gameplay data. For example, you could have “toggle collision layer” tiles that have no collision, but which the engine can use to generate zones which change which collision layer is currently being used, as you might need in a game with multiple layers of collision. You can also use Objects for this, but having it as tiles might make it more intuitive to edit and reduce the number of layers required.
- The same cosmetic tile may have different collision in different scenarios, based on what makes sense at that particular location, you don’t have to have a 1:1 correspondence between collision tiles and cosmetic tiles. For example, the same grassy tiles in my example above may be solid ground or one-way platforms, just based on whether there are any other platforms below them. The same gently sloping cosmetic tile may be part of a larger slope and have sloping collision, or it may be used just for a small cosmetic dip in the ground while still having entirely flat collision so that the player doesn’t wiggle when they walk over it.
- Entirely compatible with engines/importers that use Tiled’s built-in collisions since you can just assign collisions to the special collision tiles and nothing else, but also compatible with custom parsers that look for the tiles based on tile ID, so you can choose whether to define the collision data in Tiled or in-engine.
- You don’t have to assign collision data to every tile, just to the special collision tiles. This is especially nice if you’re still adding new tiles to your tileset(s), the artist(s) don’t have to worry about adding collisions or notifying anyone about the collisions, as the level designers decide what collisions they want, where they want them.
Cons:
- It’s one extra layer (per layer of collision) in the layer stack. I haven’t found this a problem. I keep mine above all the other Tile Layers, and hidden when it’s not relevant. It can be an issue if you have a lot of layers though, as it can be annoying to find the layer you were editing after updaying the collision layer.
- It’s another layer you have to edit. It’s not just data attached to each cosmetic tile like the built-in collision tool. If you have a 1:1 correspondence between cosmetic tiles and collisions (see the pro above about a loose correspondence) isn’t needed, you can use Automapping to automatically place collision tiles based on the cosmetic tiles. However, while this is a little more flexible than using per-tile collisions and can be edited after, it largely undoes the advantage of not having to worry about per-tile collisions, and makes it more work to add collision to new tiles, since adding collision tile Automapping rules for new tiles is usually a bit more work than just drawing collision in the collision editor. If you keep your collision tileset simple and small, it should be no problem to edit the collision layer.
- A consequence of the above: it’s possible to end up with de-sync between the cosmetic layers and the collision layer. Keeping the collision layer on top and visible at low opacity can help remember to edit it.
Neutral/extra notes:
- You can use Tiled’s other tools to make editing collision easier. You can save stamps of slopes or other common collision shapes, you can Bucket Fill large solid areas, you can copy+paste chunks, and there are probably other ways that the various tools can be used for collisions, depending on your needs and preferred workflow.
- Highlight Current Layer (default hotkey:
H) makes it easy to see your collision layer even if it has similar colours to the cosmetic tiles. Combined with a lower opacity, it should make it easy to edit the collision layer to match the cosmetic layers.
Lastly, just in case you haven’t considered it: you can also use Objects for collision, instead of tiles. Instead of per-tile collision, you can just draw objects (typically Rectangles or Polygons) spanning each multi-tile collidable area and read those in as collision. Some engines, such as Unity, work with objects like this under the hood anyway. These have their own pros and cons, of course. I prefer tile collisions myself, but it’s good to know all your options.
2 Likes