Tile collision on/off + tile destruction/creation similar to Terraria/Starbound

[Darko Draskovic]

Hello! I've been using Melonjs for several days now and am very happy with it.

However, there is one thing that bothers me. If I were to create a level where every tile on a certain platformer level is collidable and can be destroyed, what would be the best way to go about it?

1) Should I attach a collision rectangle to every single tile? Would it be expensive to perform collision tests afterwards? I'm asking this since Melonjs does not have a tile dedicated collision algorithm, but only handles tile shapes as normal collision polygons via SAT (as far as I've got it).

2) Will I run into 4th issue of mentioned here https://github.com/melonjs/melonJS/wiki/Frequently-Asked-Questions#collisions: "Collision shapes with aligned edges (like rectangles that cover adjacent tiles) can cause moving Entities to get stuck on the inner corners as the Entity slides across what should be a flat surface. This is a well-known problem where "internal edges" confuse the collision detection system, etc."

[Aaron McLeod]

1) Before we added proper shapes & SAT, the only collision we had was AABB for every tile. It performed pretty alright. Mileage may vary, one might have to test on their device range to really determine where slowdowns occur.

2) It's quite possible. I ran into not a getting stuck scenario, but one where i would fall through if i had two polyon objects touching corners instead of sides. So to fix this, i always made sure my pieces overlapped a bit. Obviously this is not ideal when you want objects to be destructable. Really i think the best thing you can do is construct a small prototype where you can destroy little tiles, see what issues if any you run into.

[Jay Oster]

Consider using a big polygon that you tear down piece-by-piece, splitting into multiple polygons as necessary. This can be done with triangulation. This is the "right" way to make destructive scenery. Putting a rectangle over every tile is a naïve implementation, and will serve as a performance hit.

[melonJS]

since we use a quadtree, the performance hit should be minimum no ? although it depends for sure of the tile size. However there will be definitely a memory consumption increase as the amount of object created for the level will increase as well.

I would however second Aaron's recommendation and give it a try, after all (in my opinion) it's better to have a naive solution rather than an over-engineered solution, but at the end, it depends on how much effort  you want to put in your code   :)

[Jay Oster]

There's over-engineering, and then there's practicality. ;) QuadTree and Spatial Hashing are complex algorithms, but they replaced a naïve solution for practical reasons. In the same vein, polygon triangulation is complex but practical.

Anyway, I agree that you'll be just fine using the naïve implementation to start with. Make it better later.

[Darko Draskovic]

Thank you all for your answers.

I've tried a bit entity - tile interaction where to each tile an entity with a colliding body is asigned. It does not seem to produce any problem with entity stucking horizontaly or verticaly. Everything went smoothly at reasonable speeds.

This is quite amazing. Namely, before I've discovered Melonjs, I was making my own framework using almost the same libraries - SAT, Howler, etc. I wrote my own physics module. A hair-pulling task - a task which was consuming the most of the time dedicated to physics module development - was precisely how to tell a floor/ceiling from a wall and vice versa. So I've finished by writing specialized tile-based collision routine which test for floors and walls. For the rest, I've used SAT and simple physics responses based on impulse resolution.

Did you guys do anything special in order to account for "how to tell the difference between a wall and a floor when using tiles"? It seems as if you did. Anyway, for now works nicely.

[Jay Oster]

The trick, I think, is that melonJS physics does not make any attempt to differentiate between floors/ceiling/walls. It's not designed to handle collisions in any special way, with the exception that user code may override the default collision behavior to add special handling, like the "one-way platforms" in the platformer demo. (Slopes also have special handling to counter bugs introduced by gravity.)

It sounds like you were able to get good results for this, I hope you're unblocked for the moment on collision detection, now!