Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I find it interesting that you took the classic advice of "just use Box2D" for a 2D platformer and it worked well for you. It doesn't seem like your game using anything much more complex than basic box vs. tile grid collision and doesn't use any of the advanced features of Box2D. No complex constraints, rigid body usage seems simple or non-existent, etc. I could be completely wrong about that though, this is all speculation based on the video and your devlog.

What kind of issues were you running into with implementing tile based collision? Was it intersection tests with slopes? Performance issues? Stability (crashes)?



Intersection tests mainly, I'm sure the reason is buried somewhere in the devlog. At the same time it looked like complex dynamic machines (with pistons, pivots and other parts) were also going to be a priority. It was definitely worth the extra effort, and I still have plans for simpler machines, rope-style bridges with connected parts, and more complex monsters which will no doubt have constraints between their parts.

In addition Box2D has given me super quick spatial tests, which I use for melee, mouse-picking, and ray-casts for the particle system (which is a quick custom built thing).


Not to mention helps you solve some more advanced problems like tunneling and collision resolution with no extra effort. I think it was a very smart choice to use Box2D rather then rolling your own solution.


Those aren't advanced problems in most tile based platformers. It's pretty easy to solve tunneling by making sure you check every tile along your movement path for objects that try to move through more than one tile in a frame. Collision resolution is also simple in most platformers, clamp to the tile edge you intersect with and set velocity to zero.

OP gave solid reasons for using Box2D though (machines, rope bridges, fast spatial tests).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: