Seeking advice on collision detection for a tile-based game

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
Sky_Render
Prole
Posts: 48
Joined: Fri Jul 05, 2019 2:59 am

Seeking advice on collision detection for a tile-based game

Post by Sky_Render »

First off, I am back; I decided I hadn't given this engine a fair shake, and I was right. My issue last time was entirely on me and my poor code methodology at the time, not the engine. Sorry, LOVE, all is forgiven!

Second, I'm currently designing a game that's in dire need of good collision detection. The problem, of course, is that LOVE's Box2D implementation starts to choke after a few hundred instances, and your typical tile-based map might well have a LOT more tiles that need collision than that! Certainly I don't want 95% of my collision going to just current-map collision detection. So what I'm looking for is advice on a good set of collision code that is also capable of at least some shape dynamics (I'd like at least 45-degree and 27.5-degree slope support). The maths behind collision detection make my head hurt, so writing my own engine from scratch with no help whatsoever is currently off the table, but if anyone can at least point me in the right direction for where to start, that would be much appreciated! Thanks!

EDIT: I remember a lot of PS1 games used a "hidden layer" technique where there was a non-rendered graphics layer that had a particular color which the game interpreted as "the player cannot walk through these pixels". That would be an ideal implementation, and seeing as it worked on the original PlayStation, I would imagine that technique is fairly low-impact. Does anyone know how that type of collision mapping works?
User avatar
ivan
Party member
Posts: 1911
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: Seeking advice on collision detection for a tile-based game

Post by ivan »

Hello,
Box2D can easily handle 2000-3000 "dynamic" bodies which is more than you enough.
"static" bodies are not checked for collisions against each other so you can probably create a lot more of those.
Having said that I should point out that you don't want to run a physics simulation of your entire map at the same time.
Just simulate whatever is on the screen and destroy whatever is offscreen - alternatively you can use body:setActive(false).
For slopes, I would recommend the edge/chain shapes which can work very well for this sort of thing.
Hope this helps!
Sky_Render
Prole
Posts: 48
Joined: Fri Jul 05, 2019 2:59 am

Re: Seeking advice on collision detection for a tile-based game

Post by Sky_Render »

I actually mathematically worked out how the old PS1 games did it! It's pretty efficient, all right. You only have to check the pixels the object's going into on the blockmap layer, and trim or halt the movement accordingly. Just like those old PS1 games, I'm only checking the red channel for a specific color, and that color's what the blockmap layer uses naturally. There's no complicated maths involved, just "if it's blocked, you can't go there". Simple, elegant, effective. Thank you, Squaresoft!
Sky_Render
Prole
Posts: 48
Joined: Fri Jul 05, 2019 2:59 am

Re: Seeking advice on collision detection for a tile-based game

Post by Sky_Render »

Just an update for anyone interested: the final collision check code I came up with is around 150 lines of code, can handle most unusual blockmap shapes gracefully, and it has proper "edge slip" support (ie. if you're pushing in a blocked direction that's not blocked a short distance away in another direction, it will make you move in that direction even if you're not explicitly telling it to).
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 217 guests