Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am having some issues with trying to detect collision of two isometric tile.

I have tried plotting the lines between each point on the tile and then checking for line intercepts however that didn't work (probably due to incorrect formula)

After looking into this for awhile today I believe I am thinking to much into it and there must be a easier way.

I am not looking for code just some advise on the best way to achieve detection of overlap

share|improve this question
4  
What exactly are you trying to do? Detect when the mouse is over a tile, or detecting if two units are overlapping? If it's the later, you should really think about separating your "game" from the "graphics" –  John McDonald Apr 12 '12 at 3:26
    
I need to make it when the side of a moving iso-tile hits a non moving tile the moving tile stops. Only thing i am having trouble with is the test for collision. I could use a bound box but I need the collision to be accurate. –  Sleepy Rhino Apr 12 '12 at 13:45

2 Answers 2

up vote 21 down vote accepted

I'll come straight out and say that I don't know how to solve the problem you have described in the question (collision detection between iso-tile-shaped rectangles), but I can tell you how others have solved it in the past:

The way it's done in other games is to separate the game world from the screen world. When you're starting out, it common to imagine them being the same thing, but then it leads to problems like the one you're describing.

The general idea is that the game world is stored completely in memory, behind the scenes, it's just numbers, references, and logic. The fact that you are drawing the game world in isometric is irrelevant. Your game world shouldn't have the concept of isometric, or square, or even if the screen is being draw as 3D. All of that is taken care of when you draw the game world to the screen (aka the screen world). The game world should be stored and maintained in the simplest way that makes sense for the game, in isometric games, you typically completely ignore the fact that it's iso and instead store the positions as if you were using an axis-aligned grid. Most games will have methods for converting coordinates between the two worlds, I call mine ScreenToWorld(x, y) and WorldToScreen(x, y). The conversion is often done with Matrix math, but can be achieved other ways. You'll use ScreenToWorld when you use the mouse, and WorldToScreen when you draw.

There are several advantages to splitting the game world and the screen world. One of the advantages is that collision detection and movement all happens in the game world, and is therefore usually quite straight forward because you're not dealing with a slanted grid, or skewed coordinates, or where the screen is, etc. In your case, you'd be dealing with axis-aligned rectangles and squares. Once the game world has been updated, then you draw a representation of the game world to the screen, keyword: representation. It may seem counter-intuitive at first, but your screen is only a representation of what's going on in the game world. This makes things like dedicated servers and terminal-like clients possible.

FreeCiv is actually a great example of all these things. You can view the same exact world as any of: a square North/South Grid, Isometric, or even Hex. Every game you run has a dedicated server running in the background, even for single-player games, therefore the client is also just a display port, nothing more.

Long story short: Separating the game world and logic from the screen world simplifies the game logic, reduces the game<->display coupling, and in turn, makes collision detection between "iso" tiles easier to handle and easier to visualize.

share|improve this answer
    
Thanks for the well explained answer I was separating the logic in whats been drawn and what is happening in the background but i was treating everything as a slanted grid. –  Sleepy Rhino Apr 12 '12 at 21:35
    
For people of the future; graphics are an interpretation of data. The four major pieces of a game: logic, data, input, output. Avoid lumping them together. Also, excellent response John, +1 –  Aarowaim Apr 29 at 3:08

John's answer is quite right, but I will try to explain it in a different way:

There IS no isometric collision detection.

Collision detection does not care what your projection matrix / transformation looks like. Collision detection should not matter if you render things at all (after all, objects which are off the screen can still collide, right?)

It is a more philosophical question: Does a tree falling down in a forest still actually collide with the ground when there's nobody there?

Conventional wisdom would say: Yes. It doesn't matter how you look at it. Things collide in world-space, not view-space.

share|improve this answer
1  
+1 Well put. "There IS no isometric collision detection" –  John McDonald Apr 12 '12 at 19:25
1  
Thanks, I just said what you said already. But a bit differently. –  MarkR Apr 12 '12 at 19:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.