Rewriting code: tile-player collision code

Rewriting code: tile-player collision code

A lot of time on the Carter Jones Adventures game is spent on rewriting pieces of code. Visually you probably wouldn’t notice any difference if I would show the game before or after a rewrite but in terms of performance, memory leaks, bugs and maintenance of the code there can be a huge difference.

The Carter Jones Adventures is a full-directional sidescrolling game, this means that the player can roam around freely depending on how I layout the level and where I place the platforms. I do the laying out of the levels in my custom level-editor (there are some screenshots of that in previous posts). A level is built up out of graphics that are packed together in one or more large images, by copying tiles out of the larger image into the level, a level is constructed.

Tiles are 32×32 pixels in my game. And previously I defined a heightvalue ranging from 0 to 32 for each tile. This allowed for having a unique height value for each position. Height locations between adjacent tiles were extrapolated. This system of 32 different heights and extrapolating the heights between tiles was causing some problems: occasionally the player could jump ‘between’ tiles and get stuck on a platform for example.

So, today I set out to rewrite that code. The new approach would define a ‘rectangle’ of outer tiles that represent the player. These tiles are investigated, they can be either solid or fallthrough and the new algorithm detects where the solid tiles are (if any). Depending on the current state (e.g. walking to the right) and the measured rectangle (e.g. solid tiles under the player, fallthrough on the right,top and left) I can now determine the possible actions such as moving to the right. I can now use this algorithm everywhere in each object class, not just the player’s (using exactly the same algorithm from several states is one of the basics of programming – which I did not obey: due to the explorative nature of the code I copied it over instead of generalizing). Anyway, the occasional errors are now gone, the code is much cleaner and therefore much easier to read and I will use this code in all future objects thus preventing myself of creating new errors. All in all it was a sunday morning well spent!

Visually representing the rectangle of tiles around the player helped a lot with developing this piece of code. The FPS and milliseconds of time spent in drawing (D) and game-loop updates (U) are always displayed since Dream Build Play 2011 happened.