Environmental Collision Detection in Platform game

Game Play & Game Design
#1

I’m coding up the map part of my game engine ATM, which brings me too this question.

Is this a good way to handle way to handle collision detection with the environment (like walls, floors, etc.) in a platform scrolling game:

I create an image for my level in the game, and I split it up into tiles. The game loads the tiles and then renders the ones that are on the screen. This is fine and dandy.

For collision, I’d make a special “collision channel” (like an alpha channel) based on black and white values that corresponds to the background image and this is also split into tiles. For collisions detection with the character(s) and sprites, I get the tile they are one and then test to see if they are touching any of the non-black pixels of the “collision channel.”

The advantage to using this system, is I could define volumes that slow motion (like water for example). Any value less than white would be a “slowing down” (friction) area.

Does this make sense? Will it be too processor intensive? Is there a better way?

Edit: I’ve been giving this more thought, and I realized that it would be inneficient to scan the “collision channel” image for the gray->white pixels every game loop.

Anyway to cache the data? Would storing the colors in custom objects that takes a double array of ints (x,y coords) and a Color object, and cycle through the array?) be good enough do you think?

#2

Here’s how I do things in Quix:

Originally I just had tile properties (a fake enum on each Tile object), which were basically SOLID, EMPTY, PLATFORM and WATER. Solid was non-passable, platform allowed you to walk on the top edge but jump though it, water would be like empty but slow you down.

Since my Tile objects are in a 2d array, its dead easy to turn a 2d pixel coord into a specific Tile object. Then you just need to check the different edges against the tiles that they’re over.

Unfortunatly that means you’re pretty restricted to flat platforms and everything looks very square (although you might be able to hide that with good art). So I added heightfields. Heightfields start off as a 32x32 (tile size) black/white image, which at load time are converted into a 1d heightfield. Tiles may have an associated heightfield that means that everything above the heightfield is empty, and everything below is solid. Then you just need to convert your normal walking movement into one that follows the surface of your heightfield.

Fairly simple idea, but I think it makes the levels much more interesting (even though its not as flexible as something like Sonic’s looping, twisting levels).

#3

Two tutorials you might want to read:
http://www.harveycartel.org/metanet/tutorials/tutorialA.html
http://www.harveycartel.org/metanet/tutorials/tutorialB.html

You won’t necessarly need to do it the way they did, but for me it was a nice source of inspiration. The stuff there is highly optimized, because the game (N) was written in (extremely slow) action script.

What’s certainly faster than a collision map is using simple gemetric constuctions for each (different) tile. Well, look at the tutorials… it’s all there :slight_smile:

#4

Thanks guys; I’ll look through those tutorials later and think about Orangy Tang’s Quix implementation.

When I get into the mood to code (I have been unable to achieve nirvana for the past few days), I’ll let you know if I have more questions. :slight_smile: