xna - Isometric Collision Detection

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

Answer

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.