Suggest logic to handle freeform movement over tile based system

Question

I've got no experience with this, so i suspect my logic is overly complicated, or perhaps not complete enough to do what I want.

I have a basic tile based system, but want to move units over the terrain in a coninuous fashion. Right now they are "teleporting" from one tile to another.

I already have a lot of the game logic set up on the tile system,for things like path-finding, cover, terrain type, etc.

My first guess it to have a floating point x/y offset from the center of the unit and the center of a tile, having 0.0 being in the center, and 1.0 being on an edge. This would be for each tile a unit overlaps. Then i can do math to figure out which tile the unit is "most" on, and use that tile for the path-finding logic.

To make it nice, as the unit moves I'd have it adjust the ofset so that he gradually will position himself with the tile line, and not make a bunch of 90* turns to hit the path'd tiles. I could then do some fancy stuff to make him curve gracefully around corners.

For things like wepon distances, i could use the x/y tile distance, then subract out the x/y offsets to get a simple pathagorean distance.

What would be a sucessful way to decouple the movement from the tile, and still be able to "link" the unit to the tile?

Answer 1

You could also specify a tile being of a certain integer size. Say each tile is 100x100. So that you stick with integers instead of going to floats. Finding which tile you/the player is on is equally trivial and still integer based.

Answer 2

Easiest would be to just use floating-point coordinates, and then just round to nearest integer to get the square.

(3.141592, 2.718282) -> (3, 3)

To get the pixel position within the square, you just need to multiply the fraction-part of the coordinate with the tile-size, and round to nearest integer: (Assuming 100x100 tiles)

(3.141592, 2.718282) -> (0.141592, 0.718282) -> (14, 72)

Answer 3

Why not just have the player move onto the tile? When they want to move to Tile B from Tile A, start moving the player in the direction of the tile. When they're within a reasonable distance from the center of the tile, you can switch the Tile that the player is on as far as the game logic is concerned.

So...

Player starts moving from Tile A to Tile B. Most if not all the game logic that is Tile Dependent (such as area of effect weapon damage) will still affect the player if that damage is dealt to Tile A. When the Player gets halfway between the center of Tile A and Tile B, switch the actual tile position of the player to Tile B.

Answer 4

It wasn't clear from your question, but the approach I would use is different depending on whether your game is in 2D or 3D.

For a 2D game, you would be best off using pixels as your coordinates.That way you can use integers to store them keep things nice and simple. You can easily figure out which tile a unit is in by dividing their coordinates by the tile size.

For a 3D game that uses tiles, just use floats as your coordinate system. It would probably be easiest to keep the units in "tiles" if that's how you're thinking of things like weapon ranges.

Whatever system you use, do yourself a favor and put the conversions from position to tile number in one place in your code. If you litter /100 and *100 everywhere just because your current tile size is 100 it's eventually going to come back to bite you. Just replacing the "100" with a constant called TILE_SIZE is probably not the best way to go either because it's entirely possible that somewhere down the road you will want to use a different origin for the two coordinate systems.

Once your units can move inside a tile your path finding problem will get more complicated. Even if all your units are the same size, you might need to make sure they don't get too close to the edge when the adjacent tile is impassable. I would suggest that you keep all your pathing in tile-space and post-process the paths to smooth out all the unnecessary 45 degree turns.