Archived

This topic is now archived and is closed to further replies.

Xingo

tile-based movment/collsion

Recommended Posts

Xingo    122
I am just wonder... I have tilebased movement with keyboard right now with no animations and the movment is jurky. From recent posts in here I''d figure I''d try out 3d tilebased engine and although it works find with collision the movement is sooo ugly. It looks like the 3d character is just skipping around becuase I just have the player''s location equal the center position of the tile. Does anyone know how to make smooth transitions from tile to tile. I am not looking for if up arrow is press then the postion is +.01 becuase then i would either need to make more tiles for collision or just get rid of tilebased collsion altogether.... And thats something I dont want todo becuase it works sooo perfectly, just check if next tile is walkable (without worring about complex 3d prograaming for coliision)

Share this post


Link to post
Share on other sites
TANSTAAFL    1160
there is no need to give up the tile based collision method, it just requires the use of a transition animated sequence(which can still be based on the center of a tile, just offset to give the illusion of movement) and having moving objects occupy both the tile they are coming from as well as the tile they are going to until their move has completed.

Share this post


Link to post
Share on other sites
OrangyTang    1298
Also search for AABB collision tests (axis-aligned bounding boxes). Very easy to test if theres an overlap (just 4 if tests) and you already have all the data present with your tiles, all you''ll need to add is a width for the moving object (which is probably the same size as a tile at the moment).

Share this post


Link to post
Share on other sites
Waverider    169
I''m working on a tile-based game now, and I have a problem for simply checking for overlap.

If a block is sliding along a surface and reaches a corner that allows the block to move beyond, that last little bit of corner might be ignored in the collision. This is because checking for overlap as collision detection might not detect the block colliding with that last bit of corner.

This might allow the player to cut corners to get ahead of pursuers.

So I try to predict collisions and force the block to take calculated slides along surfaces until I know it has reached the corner, and then I check again for the intended movement possibility.

I don''t know if this is overkill. But it is resulting in its own set of problems. Particularly, truncation failing to detect a perfect corner-corner collision.

Share this post


Link to post
Share on other sites
OrangyTang    1298
The leap-frogging problem you describe is pretty common, to fix it you need to use swept collision volumes.

If you imagine being a point at A, then moving to point B, your swept volume becomes a line joining A to B. Extending that to swept circles or boxes is slightly tricky since it gives odd shapes.

One method that can be good is to make a swept line for every corner of the box, and test those against the edges of the tiles. This is more work (and line-line testing is a bit more work) but it does give a nice robust collision detection.

Share this post


Link to post
Share on other sites
no_skill    142
try jump''n''run dev #1 - tilebased collision detection and response


http://jnrdev.weed-crew.net/jnrdev1

main site: http://jnrdev.weed-crew.net

Share this post


Link to post
Share on other sites
BlueMonk    142
I''ve been working in 2D, and I''ve been enhancing the same tile collision algorithm since about 1993 (although I haven''t touched it much in the past 2 years). It''s probably the most confusing piece of code in the Scrolling Game Development Kit, but if you like, you can see what I did . The source is downloadable. Visit the home site at http://gamedev.sf.net/. It handles sloped hills and ceilings. It also allows sprites moving at any speed to slip into a passageway exactly 1 tile tall (same height as the player). But it can only do this horizontally -- it''s hard to slip into a vertical passage 1 tile wide because of decisions that had to be made when the sprite approaches a corner at an exact diagonal. Had to choose whether to have a preference to slide horizontally or vertically. You wouldn''t think that collision detection would become the most difficult or complicated aspect of a game, but when you try to do it perfectly and correctly, I guess it often does.

"All you need to do to learn circular logic is learn circular logic"

Share this post


Link to post
Share on other sites
SelethD    456
The way I would do it is like this

say your tiles are 32x32

have your player in the center of a tile, when an arrow key is pressed, move him a lesser value that 32 pixels
say move him 4 pixels.

it might take him a few moves to get from one square to the next, but the movement will be smoother.

To check for collision, just have a bounding box around the feet of your character, say 4x4

backup your characters position
oldx = player.x;
oldy = player.y;

now move your player
if (key uparrow) player.y = player.y - 4;

now set bounding box
bbox.x1 = player.x-2;
bbox.x2 = player.x+2;
bbox.y1 = player.y-2;
bbox.y2 = player.y+2;

now check to see if any corner is in another tile
//check first corner nw

tile.x = bbox.x1/8; //8 is how many steps the player takes per tile

tile.y = bbox.y1/8;
if (mapTile[tile.x][tile.y] == solid)
{player.x=oldx; player.y=oldy; break out of check loop}

//check next corner ne

tile.x = bbox.x2/8;
tile.y = bbox.y1/8;
if (mapTile[tile.x][tile.y] == solid)
{player.x=oldx; player.y=oldy; break out of check loop}

//check next corner sw

tile.x = bbox.x1/8;
tile.y = bbox.y2/8;
if (mapTile[tile.x][tile.y] == solid)
{player.x=oldx; player.y=oldy; break out of check loop}

//check next corner se

tile.x = bbox.x2/8;
tile.y = bbox.y2/8;
if (mapTile[tile.x][tile.y] == solid)
{player.x=oldx; player.y=oldy; break out of check loop}

now draw player


hope this helps

Share this post


Link to post
Share on other sites