Simpler collision detection?

[Insectoid]

I thought of an interesting way to do collision detection. I'm sure it's been done before, but I'd like some validation for my idea. It was inspired by the DWITE maze questions.

I would make 2 maps, one a regular picture, the other ASCII. Basically, I would divide the map into large sub-coordinates, each corresponding to one of the ASCII characters. The player would still have pixel-by-pixel movement, but collision would be based on perhaps 20X20 blocks. A quick mathematical equation to see what sub-coordinate the player is in, and then a check over the ASCII map of where walls are. This would also simplify the AI.

The only drawbacks I see with this is that the collision would be square, and each wall would have to be 20X20 pixels wide. No slopes or anything. Though I suppose special characters would could be used to represent slopes, with some extra coding/checking for them. Special items or ground types (like springy platforms) could be coded in very easily. This would be far more efficient than checking every wall every loop (I know, most games they use temporal coherence, (wiki)but I'm keeping it simple). It would allow for far more interesting maps than checking color, and is just a cool way of doing it. AI could be simplified as well (as shown by DWITE). It would also remove the need to code in the coordinates of every object. I believe the advantages outweigh the disadvantages, until I stop being lazy and start doing things right.

Tell me what you think? Is it feasible?

[Dan]

Not only is it fesible it's how most simple tile based top down 2d game work. Alot of the RPG makers you can find online use this system as well as alot of the old 2d RPGs and action games.

My first computer sci ISU (it was a 2d top down RPG in turing) used this method (or something like it). I think there are even some tuorials and examples for making such a system on this site.

It works quite well if you make the tiles (the boxes in the gird) with the idea that you can either walk on all of it or none of it in mind.

You can also asign more properies to each tile then walk on or not, such as make some tiles warp poitns that take the player to a new map.

It's not the best method to use but it is one of the easyests if you want the system to be generic enought that you don't need to code each wall, etc. It also lets you make an editor that can make maps for your game so you can add content with out coding.

[CodeMonkey2000]

You mean like 2D Tile based Collision? You can do slopes, it just need a little thinking (ie what side of the slope you are in). A lot of old school snes games used this method to make collision more efficient. There are a bunch of example here that use this.


http://compsci.ca/v3/viewtopic.php?t=7545&start=0 by legolas (this is my personal favorite, it's so well polished)
http://compsci.ca/v3/viewtopic.php?t=19194&highlight=golf by The_Bean
http://compsci.ca/v3/viewtopic.php?t=8512&start=0 by Inf
http://compsci.ca/v3/viewtopic.php?t=15765&start=15 by me the newest version is at the bottom

My octree and final project in the C++ section also used a 3D array for collision, that's why you can also edit the maps.


EDIT: Darn it Dan beat me