Day 18: Collision woes.

Well, I decided to ditch Box2D for this project. I could had probably made it work somewhat, but it’s probably a bad idea to try and vectorize a pixel based map like that. What I’m still pondering about is if the game would work better or at least as well with completely vector based levels. That of course does make level creation and destructibility a bit harder, although for the level creation I could still utilize bitmaps and the marching cubes algorithm though. I just wouldn’t be using it for the internal representation. The upside would be that in-game physics would be easier. I’ve now gone back to my own collision detection code and physics. It does work, but sometimes the worm gets stuck on things, or can’t jump even though it should be on firm ground. Of course, even with vector based levels I’d probably have similar problems. I just feel like in some ways working with vectors might be simpler because they are accurate. With pixels I need to basically make guesses about angles and such. Currently I try to guesstimate what direction the “wall” of pixels is, and I push the worm out bit by bit until it no longer collides with the map. If that doesn’t work, I just put the worm back where it was on the previous frame. I think that method might actually be more complicated than it needs to be, so I might still change it to something simpler that might work for the benefit of the playability anyhow.

My code is a lot better organized after this whole escapade. I’m only just now roughly at the point I was before I started though, but at least the collision detection is better now.