Tile-based engine collisions

[ShirkDeio]

In a tile-based engine, what is the best way to check for non-tile-based collisions?

Right now I'm trying to create "collision masks" that, when needed, are placed as invisible movieclips inside the tile. The code checks the walkability of the tile and comes up with three possible returns - walkable, collision, or it finds a collision mask and consults it to see if there is a collision. I unsuccessfully tried to use BitmapData, overlaying a hitarea for the character and the mask and using a rectangle to find if there was any intersection. Now I'm trying to use hitTest with shapeflag on the mask, passing the x and y positions of my character.

Another method I've thought of but not tried yet is an array instead of the mask. The array would hold 45 values - one for each pixel in the tile (it's 45 pixels wide). Each index would represent the x, and each value the maximum y value for that x position on that tile.

I am also hoping to add in some code that makes the character slide across the tile when going straight into a slanted collision.

Which method (one I mentioned or not) would be effective and can easily implement the slide effect I want, while avoiding high CPU usage?

[GustTheASGuy]

Confusing! If it's non-tile-based, what does it have to do with tiles? Exactly what collisions do you need? Is it top-down? In that case, don't you need a range instead of a single number in the array?

[KaynSlamdyke]

At 7/16/09 10:16 PM, ShirkDeio wrote: In a tile-based engine, what is the best way to check for non-tile-based collisions?

You don't? You use a bounding box instead, and check if any of the four points are within a collision zone (or the lines connecting these points in a OBB model) - and if a prospective move is found to move an object into a forbidden area you position it so that it is exactly outside of it. Otherwise what you have aren't tiles in a classic sense.

In the case of tiles that don't conform to all-walkable/all-collision (like triangular ones), you calculate the shape of the tile as a graph and test to see if the points are within the correct area. For instance, a slope formed by the bottom and the right sides of a tile is only passable in the y > x zone. If you're storing the location of your objects in your world in terms of tiles (rather than x-y flash coordinates), it's a simple %1 operation to get thier current y and x related to that single tile

For more complex tiles, consider why the hell you have them there in the first place and whether you can make the same game without them

[roboprez]

Tile based engines are much better stored in an array

var grid:Array=new Array(8);
for (var i:Number=0; i<8; i++) {
	grid[i]=new Array(8);
}

Now this will create a stacked array which holds 8x8 values. To access the values (if you don't know how to use arrays) you use grid[x][y]. Change the 8 in the script to the size square you want. You may want to use multiple grids of the same size to hold the player or enemies or bg tiles. If you need better explaining just ask

[ShirkDeio]

Confusing! If it's non-tile-based, what does it have to do with tiles? Exactly what collisions do you need? Is it top-down? In that case, don't you need a range instead of a single number in the array?

I have my tile-based engine with the basic collision testing - some tiles are open, and some are barriers. But I have special tiles that are round, such as a curved wall. The square tile collisions don't work well with the round graphics.

In the case of tiles that don't conform to all-walkable/all-collision (like triangular ones), you calculate the shape of the tile as a graph and test to see if the points are within the correct area. For instance, a slope formed by the bottom and the right sides of a tile is only passable in the y > x zone. If you're storing the location of your objects in your world in terms of tiles (rather than x-y flash coordinates), it's a simple %1 operation to get thier current y and x related to that single tile

That makes sense. A 45 degree slope doesn't sound too difficult to add there when you explain it that way. Thanks!

For more complex tiles, consider why the hell you have them there in the first place and whether you can make the same game without them

Yeah. Quite honestly, I'd just as soon change it back to regular old square collisions and adjust the graphics accordingly. But, I'm doing the game in collaboration with someone else and they want the abnormal collisions. I guess I can try the simpler collisions (such as regular slopes) and see how that works. At the very least it will work better than the square collisions.

Thanks for the help!

[KaynSlamdyke]

At 7/17/09 07:22 AM, ShirkDeio wrote: I have my tile-based engine with the basic collision testing - some tiles are open, and some are barriers. But I have special tiles that are round, such as a curved wall. The square tile collisions don't work well with the round graphics.

Figured this would be the issue. Curves are going to be a pain, but then again, the formula for a circle in a graph is just x^2 + y^2 = 1, so you could do it the same way as with the sloped tiles - turn the tile into a graph, and test for coordinate positioning within. Other slopes can be worked out with y < x/2 (for a 50% gradient) and variations thereof. And at a real pinch, you could use sine and cos functions to check for wavy tiles. But outside of this, you start to get into the branch of mathmatics called Linear Programming, and it just goes downhill from there.

All in all, you should stick to as simple a tileset as possible, if only to make level editting, debugging and pathfinding miles easier.