8 Replies - 2001 Views - Last Post: 14 June 2013 - 04:52 PM

#1 dreaminxna   User is offline

  • D.I.C Head

Reputation: 3
  • View blog
  • Posts: 71
  • Joined: 10-June 13

Tile Collision guide?

Posted 13 June 2013 - 06:33 AM

HI. Im new to xna. What are the technique use in tile collision? I am using a tile editor in my game but i dont know how for example if the tile a head of me is a tree? I mean how can i know if there is a tree on my tile so that my sprite would not go through? No the sophisticated way but i am looking for a more newbie? just to have an idea how it works? I really dont know how it works. pls help thanks
Is This A Good Question/Topic? 0
  • +

Replies To: Tile Collision guide?

#2 modi123_1   User is online

  • Suitor #2
  • member icon



Reputation: 14924
  • View blog
  • Posts: 59,580
  • Joined: 12-June 08

Re: Tile Collision guide?

Posted 13 June 2013 - 07:38 AM

How are you tracking items on your tile? Are you stacking images or is this tree just part of the tile? The general gist is your player presses the move button, the character class determines where the next move is, polls that location from where ever/how ever the data is stored to see if it can move, and makes a determination on movement *BEFORE* it moves.
Was This Post Helpful? 0
  • +
  • -

#3 cfoley   User is offline

  • Cabbage
  • member icon

Reputation: 2391
  • View blog
  • Posts: 5,021
  • Joined: 11-December 07

Re: Tile Collision guide?

Posted 13 June 2013 - 07:40 AM

You could loop over all of the objects in the game and see if they are on that tile.
Was This Post Helpful? 0
  • +
  • -

#4 dreaminxna   User is offline

  • D.I.C Head

Reputation: 3
  • View blog
  • Posts: 71
  • Joined: 10-June 13

Re: Tile Collision guide?

Posted 13 June 2013 - 07:51 AM

View Postmodi123_1, on 13 June 2013 - 07:38 AM, said:

How are you tracking items on your tile? Are you stacking images or is this tree just part of the tile? The general gist is your player presses the move button, the character class determines where the next move is, polls that location from where ever/how ever the data is stored to see if it can move, and makes a determination on movement *BEFORE* it moves.


The trees is part of the tiles. Can you give me sir a formula to do this?

View Postcfoley, on 13 June 2013 - 07:40 AM, said:

You could loop over all of the objects in the game and see if they are on that tile.


But isnt looping always makes your game to cause some lag issues?
Was This Post Helpful? 0
  • +
  • -

#5 modi123_1   User is online

  • Suitor #2
  • member icon



Reputation: 14924
  • View blog
  • Posts: 59,580
  • Joined: 12-June 08

Re: Tile Collision guide?

Posted 13 June 2013 - 07:54 AM

I have zero idea what you are doing, or how the tile is setup. Again - if the tile has a number and is setting in an array, or the tile is a custom object have it return true or false if it is passable.. or just have the player's movement function know that trying to move into tile # X is not allowed.
Was This Post Helpful? 0
  • +
  • -

#6 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: Tile Collision guide?

Posted 13 June 2013 - 01:30 PM

One of the easiest ways is to manage everything as a grid. So, for example, say you have a 10 by 10 grid of squares/areas that represents your screen/level/grid. You assign a number to each type of background tile. So, let's say 0=grass/empty, 1=tree, 2=rock, 3=water and so forth. To hold this in a byte value you would have 256 possible types of background tile. Then you define your array to define what is in each of the 10 by 10 squares for the background.

You might have something like this to define your array/grid (you can use ints instead of bytes to keep it simple for now).

int[,] BackgroundGrid = { 
 {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
 {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
 {0, 0, 2, 1, 0, 0, 0, 0, 0, 0},
 {0, 0, 0, 0, 0, 0, 0, 0, 1, 0},
 {0, 0, 0, 0, 0, 0, 1, 3, 3, 3},
 {0, 0, 0, 2, 0, 3, 3, 3, 0, 0},
 {0, 0, 0, 0, 3, 3, 0, 0, 0, 0},
 {0, 1, 0, 0, 3, 1, 0, 0, 0, 0},
 {0, 0, 3, 3, 3, 0, 0, 0, 0, 0},
 {0, 0, 3, 1, 1, 0, 0, 0, 0, 0},
};




This represents your game grid. You draw a sprite/tile for each of these array elements according to the value in the grid/array. So, you have a grid 10 tiles by 10 tiles and the tiles for the background are whatever it says they are in the array (and you draw them according to that on the screen). You can have the player's sprite move from grid square to grid square. You could even allow the player to be at a fractional value between grid squares (if you want to make it more complicated.)

So say the player is in the square that is second column third row. For collision detection, I would have the player request moving right. Then I would check what's in that square to decide whether to grant the request to move right or not. I would search in that square (third column and third row). That grid/array value =2. I could simply verify that it's greater than 0 if all values above zero represent solid objects that prevent the player from entering that square. Once my code determines there's a 2 in the square the player is attempting to move into, I can deny the move request and maybe play a sound that yells "ouch!". As long as the player requests moving into a square that is represented by zero, the move is granted.

Its one of the simpliest ways to handle collision detection. A lot of games early in the history of video games, used grids like this.

If you don't use a grid system like this, you probably aren't working with a tile engine.

Another "trick" you can use here is to have a range of values all mean a certain type of thing. For example, values between 3 and 12 might all be different types of water (salt water, fresh water, poison water, water with fish, water with magic whirlpool that leads to another level, etc.) where a player is allowed to move into them only if he has a boat in his inventory. So you check that the value is >=3 and <=12 and if it is, you apply the "water" rules for collision.

Using arrays like this also works very nicely for multiple levels/areas. I could save this array into a file. I could save 100 files similar to this one but laid out different. Then I could load any of those 100 files into my array and it draws according to the values in the file.

So, I might have a level editor program that allows me to "draw" values into the array that will be stored into a file and loaded later into my game when its time for that level to come up. How you go to the next level is up to you. For example, if you go off the right side of the grid, maybe it automatically loads the next level and places your character on the far left side of the new grid. Or maybe you can only go to a level that represents a castle interior when you say the right things to an NPC.

This post has been edited by BBeck: 13 June 2013 - 01:49 PM

Was This Post Helpful? 2
  • +
  • -

#7 dreaminxna   User is offline

  • D.I.C Head

Reputation: 3
  • View blog
  • Posts: 71
  • Joined: 10-June 13

Re: Tile Collision guide?

Posted 13 June 2013 - 02:54 PM

View PostBBeck, on 13 June 2013 - 01:30 PM, said:

One of the easiest ways is to manage everything as a grid. So, for example, say you have a 10 by 10 grid of squares/areas that represents your screen/level/grid. You assign a number to each type of background tile. So, let's say 0=grass/empty, 1=tree, 2=rock, 3=water and so forth. To hold this in a byte value you would have 256 possible types of background tile. Then you define your array to define what is in each of the 10 by 10 squares for the background.

You might have something like this to define your array/grid (you can use ints instead of bytes to keep it simple for now).

int[,] BackgroundGrid = { 
 {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
 {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
 {0, 0, 2, 1, 0, 0, 0, 0, 0, 0},
 {0, 0, 0, 0, 0, 0, 0, 0, 1, 0},
 {0, 0, 0, 0, 0, 0, 1, 3, 3, 3},
 {0, 0, 0, 2, 0, 3, 3, 3, 0, 0},
 {0, 0, 0, 0, 3, 3, 0, 0, 0, 0},
 {0, 1, 0, 0, 3, 1, 0, 0, 0, 0},
 {0, 0, 3, 3, 3, 0, 0, 0, 0, 0},
 {0, 0, 3, 1, 1, 0, 0, 0, 0, 0},
};




This represents your game grid. You draw a sprite/tile for each of these array elements according to the value in the grid/array. So, you have a grid 10 tiles by 10 tiles and the tiles for the background are whatever it says they are in the array (and you draw them according to that on the screen). You can have the player's sprite move from grid square to grid square. You could even allow the player to be at a fractional value between grid squares (if you want to make it more complicated.)

So say the player is in the square that is second column third row. For collision detection, I would have the player request moving right. Then I would check what's in that square to decide whether to grant the request to move right or not. I would search in that square (third column and third row). That grid/array value =2. I could simply verify that it's greater than 0 if all values above zero represent solid objects that prevent the player from entering that square. Once my code determines there's a 2 in the square the player is attempting to move into, I can deny the move request and maybe play a sound that yells "ouch!". As long as the player requests moving into a square that is represented by zero, the move is granted.

Its one of the simpliest ways to handle collision detection. A lot of games early in the history of video games, used grids like this.

If you don't use a grid system like this, you probably aren't working with a tile engine.

Another "trick" you can use here is to have a range of values all mean a certain type of thing. For example, values between 3 and 12 might all be different types of water (salt water, fresh water, poison water, water with fish, water with magic whirlpool that leads to another level, etc.) where a player is allowed to move into them only if he has a boat in his inventory. So you check that the value is >=3 and <=12 and if it is, you apply the "water" rules for collision.

Using arrays like this also works very nicely for multiple levels/areas. I could save this array into a file. I could save 100 files similar to this one but laid out different. Then I could load any of those 100 files into my array and it draws according to the values in the file.

So, I might have a level editor program that allows me to "draw" values into the array that will be stored into a file and loaded later into my game when its time for that level to come up. How you go to the next level is up to you. For example, if you go off the right side of the grid, maybe it automatically loads the next level and places your character on the far left side of the new grid. Or maybe you can only go to a level that represents a castle interior when you say the right things to an NPC.


Thank you very much for this great explanation. I get it now :D. Your a life saver :D
Was This Post Helpful? 1
  • +
  • -

#8 BBeck   User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: Tile Collision guide?

Posted 14 June 2013 - 04:58 AM

Another trick I wanted to mention is to use remainders. I talked about having a range of numbers mean a certain thing, such as my water example. There's another trick that is similar but a bit more elegant than doing greater than / less than tests all the time.

Also, I would point out that using grids and arrays to represent them can also be used in 3D as well as 2D. My Interiors Example uses an array very much like this to define the "dungeon"/interior.

I used the "remainders trick" to determine the rotation of the tile. In 2D, you might want the tiles to be able to rotate to be able to reuse tiles. For example, in my water example where 3 represented water and I have a river going through the level, there is a problem. In that example, you are pretty much forced to draw it as a blue square and the grass as a green square. The problem is that that doesn't really visually give you a good bank or transition from water to grass.

So, maybe you want water tiles that have some grass on the edge to visually make it not so blocky/square. So, you make a water tile with one side grass. Then you make one with two connecting sides grass, and another with two opposing sides grass. You would have to do a whole lot of tiles for all the possible combinations of having grass on the four edges.

But you could simplify it by making the tile rotatable. Instead of doing a tile that has grass on the west and north sides of the tile, another for north and east, another for east and south, and another for south and west, you could instead just make one tile but make it so you can rotate it to the 4 cardinal directions (north, south, east, and west). So, you have one tile that rotates to four different facings that can be placed in that grid area.

So, the trick is to assign the values for those tiles so that you can tell which direction it is facing. You do this by dividing by the number of options for the tile (4 since there are four cardinal directions).

So, my tile values might be 12 for this tile facing north, 13 for the same tile rotated facing east, 14 for the tile facing south, and 15 for the tile facing west. The rules for this tile are identical because its a water tile (unless there is a rule that takes into account which direction the tile is facing like the direction a door is facing and only being able to pass through from a certain direction).

So, I divide the value (12) by 4 giving me 3 for the tile type (and zero for a remainder). That makes it type 3 (water). If I have 14 for the value, dividing by 4 still gives me 3 for the tile type (water), but I have a remainder of 2. That 2 tells me I need to rotate it twice by 90 degrees, or make it face south.

This only gives you one quarter as many tile types, but it allows you to reuse the same tile by rotating it in any of the 4 directions when you go to draw it on the screen.

The modulo(%) operator will give you a remainder. So, divide (/) by 4 to get the tile type and use the remainder (%) to determine which way the tile faces.

I do that in my 3D "dungeon"/interior example. I have a sub-grid of floor tiles. But there is an array that represents a grid of "areas". Each area is a 3 by 3 area on the floor grid. The areas can have "room" models placed in them, much like placing a tile. I made a model for each "room" type in Blender. There were different combinations such as single wall, two walls facing, two walls connecting, single wall with door, two facing walls where only one has a door, and so on. But I used the remainder trick to determine which way the model/room-area was facing. So, that saved me having to create 4 different models for each facing. I used one model and then rotated it in any of the 4 directions.

The collision detection was a bit more complicated though. For collision detection, I think I took into account the area type (for example two walls facing each other) along with the facing information, and then I made a rule that basically said you could not exit the area through the side(s) that has a wall on it. The exception was if there was a door on that wall and then you could only exit the area through the spot where the door frame was at.

But anyway, that's another trick and an example of using it in 3D.

This post has been edited by BBeck: 14 June 2013 - 08:39 AM

Was This Post Helpful? 1
  • +
  • -

#9 dreaminxna   User is offline

  • D.I.C Head

Reputation: 3
  • View blog
  • Posts: 71
  • Joined: 10-June 13

Re: Tile Collision guide?

Posted 14 June 2013 - 04:52 PM

View PostBBeck, on 14 June 2013 - 04:58 AM, said:

Another trick I wanted to mention is to use remainders. I talked about having a range of numbers mean a certain thing,


Than you very much. Didn't thought about that trick. But its a great idea. Thank you again :D/>
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1