Custom Tile-Based Movement

[Clowerweb]

So I'm trying to create a game where the map is basically a Pacman-like maze. I've observed 3 types of movement for these:

 

• Where the characters move 1 whole tile at a time (either instant snapping, or tweening the movement into position, but always ending up centered on a tile).
• Characters "autorun", like Pacman, where they move in a constant direction until they hit a wall or the player changes directions.
• "Free" movement - characters move and stop responsively according to controls, into arbitrary positions. There is no grid snapping or tweening, so tapping right will move you a couple pixels to the right, then stop.

The system I'm building is based on #3 (free movement). The player moves along tight corridors in a maze only, so there are no open areas. I first experimented with collision detection (Arcade physics), but that proved to be a little buggy, with the player sometimes getting bounced around, and enemies sometimes getting stuck on corners. With a hack-hack here, and a hack-hack there, I was eventually able to alleviate some of it, but ultimately I think collision detection is the wrong way to approach something like this.

 

So how do you get a nice tight grid movement system that simulates collision detection, without having to keep the characters centered on tiles? That's the question I've been pondering for a long time now. I tried a system where you constantly check for non-empty tiles that are within 1 pixel of the character (i.e. the character is up against the face of a tile), but that proved to be inaccurate, depending on movement speed, the speed of the loop/framerate, etc., which could cause the character to be > 1 px away (and thus allowed to keep moving in that direction), and the next frame they're passing through the wall (they moved 2 pixels in a frame). So I tried then adding a check for overlap - if they're overlapping a non-empty tile, move them out. That doesn't seem like a very elegant solution though - it's noticeable when it happens, and just doesn't look like a solidly-built system; it looks like a cheap hack to correct a problem that shouldn't exist.

 

Maybe I'm looking at the problem and potential solutions the wrong way. Any ideas would be greatly appreciated! Thanks!

[rich]

I agree that for grid based systems like this I probably wouldn't use collision at all. Instead I would use a tile-based look-ahead. So you work out which tile the sprite is currently in (by simply rounding and dividing its x/y with the tile dimensions) and then you can easily 'look ahead' 1 tile based on the direction the sprite is moving. Then you instantly know what to allow re: movement. If the sprite is moving super fast an/or the tiles are tiny then you may need to look ahead several tiles to avoid tunnelling.

[Clowerweb]

Thanks Rich! I'm giving it a go, but I'm not really sure how, by looking ahead, I can tell the system how far to allow the character to move. For example, the tile above is non-empty, so we can move 16 pixels (grid is 32x32) before "colliding" with a tile. Any ideas on how I can basically say "you can move 16 pixels, but not more than 16 pixels, in that direction"? Would you just have it track your distance (say 16) from the solid object, and have that variable reduce as you get closer, then say "if it's < 1, don't move in that direction"? What happens if it's < 0 (you jumped half a pixel past 0)? Do you do some kind of correction then?