How could I handle non-rectangular tile collision in Tiled maps?

Question

BrowserQuest map in question.

From what I understand, with tiled, there are two main ways to specify collision:

1. Create an object layer, and interpret the shapes in the engine as collision objects.
2. Create a tiled layer, and make all tiles in the layer have a collision property, and interpret all tiles in the layer as collision objects.

I'm using BrowserQuest as a big source of inspiration for my project, and I want to know how they handled collision on the level editing side.

I've checked through all their layers, expecting an object layer to be handling cliff collision like:

But there are no such object layers to be found. Furthermore, the tile layers containing the tiles for such cliffs have no properties at all, meaning that they didn't just specify "collision" for such tile layers.

I especially need to know how they handled less rectangular shapes like:

I could imagine that they are not using explicit collision layers, but instead determining collision in the actual engine, based off the presence of specific tile layer sprites. Only because BrowserQuest has whole-tile movement, and it wouldn't look too odd if a small apple, taking up only a fraction of the tile size, prevents movement over that entire tile.

But I'm creating a game with more precise movement, so collision has to be tight to the apple, and I really want to know how BrowserQuest approached collision defining.

If anyone knowledgeable with Tiled could take a quick look at the map, I'd appreciate it! I'm tearing my hair out here :). Thanks

Answer 1

I would assume BrowserQuest uses the tile indices (GIDs) to determine collisions. You're probably correct that this is handled in the engine internally and not editable in Tiled.

Though your assumptions about how this can be done is correct, too. And some games actually need both GID-based and object-based collisions.

The platformer I'm working (more here and here) on uses this strategy, and purposefully makes these properties editable both in Tiled and in a configuration file (Lua script with a table). After all I'm working with a non-programming game/level designer. ;)

• Only tiles on the "gameplay" layer are considered when it comes to collision detection & resolve.
• All tiles in a tileset are considered blocking by default. This is because far more tiles on the "gameplay" tile layer are blocking than those that are not.
• Tiles in a tileset can have a collisionBits property with the bit-value (and to help my designer, soon this will support string-based bits like so: "one-sided+damage". With value 0 you can make a tile non-blocking if need be. Other bits define slopes, death on contact, one-sided, etc.
• Tiled objects can be used to mark larger areas of a map to change their collision behavior, ie applying collision bits, overriding those set on each individual tile. On load this object-based collision information is baked together with the tile (GID) collision bits into the collision map used by game code (the TMX structure doesn't lend itself well to fast collision checks).
• Finally Tiled rectangle objects can be put in a "colliding objects" category. This makes these objects behave like regular blocking tiles - since they can be on non-grid boundaries and their bounding box can be of any size, they require special handling and are more costly to resolve collisions with - on the other hand these become moving platforms without which no platformer would truly be a "platformer".

Answer 2

In the tilesheet, right click on a tile and then open its Tile Properties. If you see a property named "c", it means that that tile is "closed", and the player cannot enter that tile. If the tile lacks "c", then the player can enter it.

Source: https://github.com/particlequest/ParticleQuest/wiki/How-to-create-a-map-using-tiled-map-editor