What is the best way to set up collisions in static sprite based 2D games with a top-down view?

[slotet]

For top-down 2D games based on static sprite (i.e. not utilising regular squares as made by pixel art, or not resolving by setting collision on objects. I don’t even know how to describe it!), what is the correct way to set collision for the map?

The following screenshot is from a previous project of mine. At that time, I solved the problem by manually arranging the box shapes.

The problem with this method is that,

• The more complex the map shape, the more box shapes there are, which increases performance concerns
• It is time-consuming.

So I decided to try Convex hull shape (Physics Body Editor was deprecated, so I used Defold Polygon Editor web version).
Below is the results of the experiment.

The left side is the approach that arranges box shapes, while the right side relies on .convexshape.
As you can see in the video, the collision behaviour is unstable and the shape is often wrong when exporting. Besides, there seems to be a limit to the number of vertices that can be set. Apparently, .convexshape with the Defold Polygon Editor is probably not intended for use cases like mine.

At the moment, the only solution seems to be to manually align the box shape in detail, but if anyone knows of a better solution to this problem, please let me know.

[iotaHum]

If you change the value of game.project-physics-scale, does it make a difference to the jitter?

[ross.grams]

@slotet

the shape is often wrong when exporting.

Hm, what happens? I wasn’t aware of any serious bugs, but I don’t use the tool myself anymore.

@slotet

Besides, there seems to be a limit to the number of vertices that can be set.

Right, you can’t have more than 16. Since you can’t make concave polygons anyway, this usually isn’t much of a limitation…?

@slotet

the collision behaviour is unstable

Hmm, if there is an issue with the polygon exporting, that could be the cause of this, or there is an issue with your collision handling code. In the video it seems to work correctly with one face of the polygon, but not the other. Have you noticed any reproducible pattern to the bug?

---

The Defold Polygon Editor is not designed for making multiple polygons to cover a whole scene (obviously). If I were in your position, I would either:

1. Make my own editor.
2. Drop your background images into Tiled and create the polygons there, and write a simple exporter script to create the polygon files for Defold, and possibly a collection with them in it too.

What you really need for this case is a Chain shape, rather than a Polygon, but sadly Defold doesn’t support this (to my knowledge).

[gianmichele]

I think this is one of the features I miss the most in the editor. It would help a lot in my point and click adventure game.

Right now I’m doing it in Tiled as suggested, but it adds a lot of friction in the workflow and it’s a shame.

[slotet]

Thank you all for your answers.

If you change the value of game.project-physics-scale, does it make a difference to the jitter?

Have you noticed any reproducible pattern to the bug?

I found the cause. When exporting and putting concave polygons as shown in the following image, strange behaviour seems to occur, as shown in the video.

Furthermore, it is exported in a different shape than intended. This is different from the normal usage of the polygon editor, so we can’t call it a bug. I just used it incorrectly.

Anyway,

The Defold Polygon Editor is not designed for making multiple polygons to cover a whole scene (obviously).

What you really need for this case is a Chain shape

You are really right.
(If you reread my first post, you will take it as if I am complaining about Defold Polygon Editor. My intention was not to do so, I just wanted to state my failings and ask for a different approach).

[slotet]

Right now I’m doing it in Tiled as suggested, but it adds a lot of friction in the workflow and it’s a shame.

Glad to find others with the same problem.
I was not aware of the Tiled approach. It would certainly be possible to export the shape I had in mind, but yes, it would complicate the workflow. The main problem with this approach is that the position cannot be finely adjusted on the editor.

I am currently working to fork the Defold Polygon Editor to create my own editor. Instead of having it generate polygons, I intend to have it generate thin box shapes along the points I specify, i.e. reproduce a pseudo-chain-shape. Well, this is not a smart way to do it either.

[ross.grams]

@slotet

I found the cause. When exporting and putting concave polygons as shown in the following image, strange behaviour seems to occur, as shown in the video.

Aha. I wondered if that was it. Yes, very strange things happen when you make concave shapes. I believe the editor exports it as-is, but in-game it doesn’t work, I’m not sure. For me the debug drawing looks correct, but the collision is messed up:

@slotet

If you reread my first post, you will take it as if I am complaining about Defold Polygon Editor. My intention was not to do so, I just wanted to state my failings and ask for a different approach

Oh, no worries, I didn’t take it that way. It was never intended to be an advanced tool, it was just meant to be better than writing out vertex positions by hand.

@gianmichele

Right now I’m doing it in Tiled as suggested, but it adds a lot of friction in the workflow and it’s a shame.

What’s your workflow with Tiled? Do you just export the polygons, or do you generate a collection using them?

I wouldn’t mind helping/creating a plugin for Tiled that makes this easier. I’m sure it’s a common issue and I doubt the editor will support polygon shapes anytime soon.

[paulbaucom]

I don’t know if this helps, but I’ll throw it out for consideration: Defold will generate collision shapes per tile based on transparency of the source image. See the section of the manual:

Defold tile source manual

I wonder if you can take a low resolution image of your background and make the walkable areas transparent. Then you use the Defold tile source importer to generate collision shapes.

Then you can use a tilemap with this tile source for the collision. But don’t draw it. Put it behind the high res image you’re rendering, and scale it up and move it so it matches. Maybe apply a custom material so it doesn’t render it at all but the engine still uses it for collision (but this is an optimization for later after testing).

I don’t know if this will work or if it’s a good idea. Maybe it gives you some ideas. I started to test this, but I realized I don’t have time make a polished example. I’ve spent way too much time building bike sheds in linux the last week and have done no creative work.

I did include a zip of a Defold project of what I did so far to demonstrate what I’m talking about. Physics debugging is on, and it shows it’s detecting collisions against the scaled tile map. You will need this to see the player collision sphere (move with arrow keys) since there is no sprite for the player in this test.

I used an image from FF7 since this problem reminded me of that game. I rushed the image in Gimp (which I don’t yet know how to use), so it’s pretty rough. You can see in physics debug that you’ll get collision messages (see the vector normal arrows), but I don’t have any code to respond to that. You can move thorough the colliders since the player is kinematic.

In the main.collection, the “background” game object with the high res sprite has a z position of 0.1, and the “collision” game object with the tilemap has a z position of 0 (behind the background image). It is scaled to match. In this example, the “high res” background is 3x the “low res” background for demonstration. The source images were already at PSX resolution.

There is probably a good workflow to be developed here if you think this is a useable approach for you. Look at both images I included to make sense of this.

Archive.zip (3.3 MB)

[slotet]

Thank you for the sample project. I have tried the approach you suggested.
For clarity, I’ve made the walkable area transparent.

It was made in a hurry and still needs to be tweaked, but it looks pretty good.

[paulbaucom]

That looks great! I like this style of game a lot. I thought of PSX Resident Evil and Final Fantasy games from my youth when I saw your post. Fond memories.

[slotet]

Sample projects have been added to github.

HTML version is here Top-down-collision-with-tile-source 1.0 (physics debug is disabled in web version, it would be available on local build).

[slotet]

The sample project has been updated.
I don’t know if this is the best way and the workflow is a bit complicated, but at least it works.