Graphical representation to collision information (grey: destroyable, black: indestructible, white: nothing)
The landscapes in Worms, Liero and Lemmings always fascinated me. You could blow the complete landscape apart, what added a great dynamic feeling and awesome gameplay element to those games.
Today I'll show you my approach to recreating what's been done years ago.
This article won't include any code, but everything described here is used in the game PixelWar [discontinued].
The system is based on using a huge 2d array to store the pixel collision information (nothing, solid, indestructible). I'm constructing this array by reading pixel colors from an Image.
The collision array is used for collision detection as well as blasting away the landscape.
The collision detection method is almost similar to the jnrdev #1 tile based collision detection technique (seperately scanning for collisions along each axis).
And for blowing things apart I'll show you what you have to take into account.
My map class contains two things:
When loading a map I first load an image and then construct the collision array based on the colors in this image.
I check each pixel in the image and set the pixel in the collision array accordingly (Ie: brown->solid, grey->indestructible, white->nothing).
Graphical representation to collision information (grey: destroyable, black: indestructible, white: nothing)
Explosions are stored as images:
Example explosion image. The magenta area (transparent) won't affect the landscape, the white area removes landscape and black changes the landscape color.
The explosion consists of transparent pixels (are not affected by the explosion), type:nothing pixels (remove map pixel) and coloured pixels (the map should get dirty!).
For blowing up things we "draw" the explosion over the map and the collision array:
if(Is the explosion pixel not transparent?){
if(Is the map pixel destroyable?){
Draw Explosion color to map image.
Draw Explosion pixel type to collision array.
}
}
 | 1. Explosion overlapping the map (graphic and collision array) 2a. Collision information that changes 2b. Changes to map graphic 3a. Collision information after explosion 3b. Map graphic after explosion |
Collision detection works similar to the jnrdev #1 tile based collision detection technique:
A single pixel is used for object-map collision detection.
First I check for collision pixels along the X-axis, then along the Y-axis.
Checking along an axis means, we test each pixel on the line our check-pixel travels along.
 | 1. Collision-check-pixel, movement 2. Checking on X-axis 3. Checking on Y-axis |
Slopes are a bit more complicated:
If I hit a pixel while checking along the X-axis I check if the wall is low enough to "climb". If the wall is low enough I alter the Y position, so we stand on top of the slope.
Then I decrease the total movement distance (climbing makes us slower) and continue checking on the remaining distance.
If a wall is hit I check if it's low enough to climb up.
I wanted to have shells that bounce when hitting the ground, so I needed some kind of pseudo bounce behaviour.
The easiest way to do this is using the collision information you get from collision detection (collision while scanning left/right/up/down) and invert the X/Y speed accordingly.
This works quite well and should be enough for most games.
But if you feel lucky you could try scanning the sourrounding of your pixel after collision detection to get a plane for "proper" maths.
That's it for today.
When building a Worms like game just don't think to complex. If you spent too much time on a single problem (Ie: physics), use a simpler approach instead of canceling your game.
Remember: games shouldn't be perfect simulations, games should be fun.
If you want some inspiration / see pixel maps in action, you should try this games: