Swingpant's Game Lab

Here is a method I developed for a game I produced last year. I had three days, and a top down ball bouncing game with multiple levels to render. Initially I thought I’d use box2D, zero out the gravity, and then build the scenes as box2D models. This looked like taking far too long to create so I needed a quick fire solution. Then it dawned on me: Colour Maps (or to you chaps over the pond Color Maps).

Now Colour Maps are nothing new, but my idea adds to the technique.

Colour Mapping means you can build a map of your game scene with various colours representing the walls and objects. To test whether you have collided with an object, instead of numerous intersect calculations you can just test the colour of the pixel(s) underneath your character.

I realised that if I added a sprite graphic for my ball to the colour map using the Blend Mode ‘add’ then I could see collision. So if I make all the static scene furniture red (0xFF0000) and the ball sprite green (0x00FF00), when they overlap the intersection area becomes yellow.

So how does this help? I calculated that by using getColorBounds on the intersect yellow, I can draw a line from the centre of the rectangle to the centre of the ball. This now becomes the reflection point. I can reflect the angle of bounce against this to give a very accurate result.

OK. So the method will bounce from a partial intersection – but this means that we are calculating the bounce from a ball embedded within the border/scene furniture. I have improved this by calculating the ball path using a recursive method. The function backtracks to where the edge of the ball touches the furniture and then recalculates the path for the remaining distance to be travelled on the current iteration.

Here is a link to a quick demo of the method in action. Demo

Source and example usage is to follow in part 2.