Adarakion Developer Diary: Issue 6

Hi Guys, I thought I would share some more technical aspects of the coding of Blast! today, as bug fixing seems to be my main focus at the moment. It feels incredibly soul destroying at times as it often involves a LOT of time spent for very little (if any) visible change in the game. A lot of my time and effort at the moment is spent with trying to get the collision detection to work effectively, so now I shall rant for a while about that very subject!

Incredibly important in any game, collision detection, erm, detects collisions (aye son, you have to be clever in this game!). Basically there are a number of common methods used to detect collisions; the most common is by using what’s known as a bounding box. This is effectively an invisible box drawn around sprites and wherever two intersect a collision event occurs. This is all well and good, but trying to get a program to check constantly the coordinates of lots of sprites can be processor hungry if not done efficiently.

At the moment I have opted for a slightly different method (I may change my mind, but this is my current train of thought). As the player controlled sprites move through the various maps, the program keeps track of the colour of the pixel slightly ahead, above and below of the direction the player is headed. If this is anything other than transparent, then a collision has occurred and the sprite should “bounce” away from the object (I use the word bounce, but that might mean stop dead, explode etc). You need to be careful when using this technique that you aren’t checking for collisions with objects that you should be able to pass through (such as clouds say) but there is a way around this, by using multiple buffers.

Each “layer” of the graphics you see on a screen is drawn to an invisible buffer before being shown on screen using a specific compiler command. It’s rather like an ultra fast theatre. You prepare the background, actors, props etc. then open the curtain. Then, you close the curtain, rearrange all the elements slightly and raise the curtain again etc. etc. If you do this quickly enough you get the illusion of movement. By using multiple buffers to build the image, you can check for colour collisions on a certain buffer, or across multiple buffers and leave out any that you don’t want to check against.

So for me and Blast!, the colour checking method of collision detection seems to work quite well, however it does present a few issues, the main one being tunnelling.

Imagine if you will that I’m checking the colour of the pixel at the far right hand side of my sprite whilst it’s moving right. The first check might be clear and so the sprite moves “X” number of pixels to the right as it moves and performs the check again. If there was a thin wall between the point where I started to move and the point where I am now, the “jump” in pixels may mean that my sprite is now actually in the wall, and my next check will show as clear again as the point at which the colour check occurs is outside of the wall again. It’s a very difficult image to get across without drawing a picture, but effectively what happens is that the sprite appears to simply ignore the wall and go straight through it – which is not what the intention is at all!

There are ways around this and the key is finding the best and most efficient way of doing so. The way I propose to resolve this is to check all the pixels from the starting point of the sprite to the point that the sprite will be AFTER the next movement phase. That way you are checking for collisions along a line and effectively looking to see if there will be a collision on the next phase and if there is, “bounce” backwards. To then polish out any “bouncing in mid air” issues, a counter will be implemented to (surprisingly) count the number of pixels before the collision occurs – the sprite will them be moved on that number of pixels before rebounding – so the effect you then get is the sprite hitting the exact spot on the obstruction and bouncing off. I guess this isn’t a million miles away from ray casting, just on a more limited scale. I will need to ensure when I implement this method that the constant pixel checks don’t slow the game down TOO much (if at all).

Doing the colour check method also provides us with a little more flexibility in terms of maps. We can (in theory) use ANY map and we don’t need to constantly tell the program where the obstacles are. It’s almost like having a video camera mounted to the various edges of the sprite constantly looking for obstacles and effecting the collision detection if they spot anything.

All interesting stuff from a coders perspective but a bit heavy and sleepy for those of you not into coding (sorry about that!). I’m happy to answer any questions you may have on any of my programming methods or problems, so feel free to ask away (I don’t think there are many dev’s out there who would be as open as I am prepared to be about this project, so feel free to use and abuse me!)

Away from the science development has been a little slower this week due to other real world work and family commitments however I do feel like progress IS being made (just not as much as I would have liked). I’ve also been focussing on getting a bit of a bandwagon going around Project Blast! and our website. It’s REALLY important to us all that this game does well. It will mean that hopefully publishers etc. will take us seriously and enable us to fully realise our dreams of being paid to do this work we all love so dearly.

Information on Project Blast! and Adarakion can be found at