In the past I've worked around this (in tile based games) by skipping the checks for sides facing another obstructed tile. So if the left side of a tile faces another filled cell, you can't collide with its left side. It feels like a hack, though.
This is what we used in N, this tutorial has an explanation and code, but it's horrible:
http://www.harveycartel.org/metanet/tutorials/tutorialB.html#section2One BIG problem that should be noted is that this is only a partial solution: it only works for axis-aligned edges. If you have sloping tiles in your game, you'll get the exact same "bumping on seams" problem with a series of sloping tiles whose surface forms a solid line (uh.. hopefully what I mean is clear).
The only "real" solution we've found is to extend the above method to its logical conclusion: take all the individual tiles, consider their explicit geometry (i.e a solid tile would be four linesegments, a triangle would be three, etc) and do some CSG to weld/merge/union them together. That way you'll end up with an explicit, solid, closed representation of the _surface_ of the world, which is what you want to collide with: your floor made of multiple tiles gets merged into a single flat lineseg.
This is definitely doable and not too complicated -- you don't need to bother with a general CSG solution because you're on a grid, so you can cheat (since you know all your verts will lie on a grid, this simplifies things a lot).
Of course, at this point you're doing lineseg-based collision, and really tiles are just a metaphor used by your editor to generate the linesegs. This is what made us switch to lineseg-based editing for the in-development game.. tiles are definitely very powerful and useful, but we wanted to see what it would be like to try something different.
Anyway.. I'm amazed at how many seemingly simple things have no good solution, or no good documented solution anyway.
Developer
