4
\$\begingroup\$

I'm just now playing around with Tiled, and I think this is the way I'm going to go to create tilesets for my game maps, but I'm curious about the cost (memory/CPU) difference between setting a collision for a specific tile so that Tiled creates them all individually versus manually drawing collision polys around larger sections by hand. For instance:

By Tile: enter image description here

Manual: enter image description here

There are fewer polygons in the manual draw (4), and it's not terribly difficult to create them, but is there a benefit one way or the other?

Improve this question
\$\endgroup\$
1
  • 4
    \$\begingroup\$ The best way to answer any performance question is to profile it each way. BoxCollider2D are simpler to process, but there will be a point where the sheer number of them makes them slower. Where exactly that point is will depend on your game, hardware, etc. It's also worth considering EdgeCollider2Ds, or spanned BoxCollider2Ds (eg. using one long box along the bottom instead of individuals) as other alternatives. These will also help avoid spurious physics snags at the corners where tiles meet along a flat wall/floor/ceiling. \$\endgroup\$
    – DMGregory ♦
    May 30, 2016 at 15:11

1 Answer 1

Reset to default
4
\$\begingroup\$

Depending on how collision is implemented, the per-tile boxes may actually be more efficient (in case the bodies are in a Quad Tree most of them are easily discarded, but in the second case it may check all the edges). I think the only real way to find out is to do some testing with huge maps (I doubt you'll notice any difference with such a small map).

You may also look into something in between. Merging tiles horizontally but not vertically, you'll still just have just rectangles but there will be less of them. That will definitely be more efficient than using many small boxes, and it will also avoid potential physics simulation issues where the edges meet.

Finally, you should probably look at avoiding all this manual work and try out Tiled2Unity. It can handle complex tile collision shapes and can merge them all together into various meshes as desired.

Improve this answer
\$\endgroup\$
5
  • \$\begingroup\$ I'm using Tiled2Unity - you still need to setup the meshes in the TMX file or T2U has no idea what to import. Really, the manual work amounts to about 30-60 seconds, which isn't really all that much lol \$\endgroup\$
    – Jesse Williams
    May 30, 2016 at 15:11
  • \$\begingroup\$ Ah, but maybe I need to set flags in T2U to merge them as needed. Interesting... \$\endgroup\$
    – Jesse Williams
    May 30, 2016 at 15:11
  • 1
    \$\begingroup\$ Maybe you can use tileset properties to store a 'canWalk' property, then you find which tile the player is by ID and then lookup on the tileset if that is walkable by the property. Btw, Hi Thorbjørn! Really useful program you made, Thanks \$\endgroup\$
    – rlam12
    May 30, 2016 at 21:24
  • \$\begingroup\$ @rlam12 - I had thought about the walkable property, but collision detection in Unity is itself fairly cheap, and Tiled2Unity just pops the collision matrices out with the tiles themselves as it imports, which is handy. \$\endgroup\$
    – Jesse Williams
    May 30, 2016 at 22:39
  • 1
    \$\begingroup\$ @rlam12 Hi, thanks! :-) JesseWilliams: Right, if you're already using Tiled2Unity, you should just experiment with either merging the shapes or keeping them as separate boxes, to see how it affects performance. \$\endgroup\$
    – Thorbjørn Lindeijer
    May 31, 2016 at 20:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .