Tiles and animating movement between them?

[togFox]

My project has tiles and all positioning and movement is in discrete x/y values so that everything happens in the middle of the tile. This is a chosen style/aesthetic plus a coding convenience.

I now need to work out movement and animation between tiles where an object/sprite is between tiles and not aligned to my tidy x/y grid. Not only that, collision detection and interactions might happen during these transitions.

For example, a wolf is on tile (1,1) and needs to move to (2,2). I'm guessing the (1,1) needs to be converted to a graphics/screen x/y for drawing purposes. I'm then thinking vectors and vector math can move the sprite to the destination. At that point, it is 'safely' centred on the tile and can once again exist in the tiled world of (2,2).

An additional challenge is having the player target the wolf because it won't be in any one tile so I guess the 'targeting cursor' needs to free roam between tiles.

If the player shoots towards the wolf then I guess normal bounding box comes into play, again, abandoning the tile system.

Am I thinking about this the right way?

[pgimeno]

Well, there are many possible approaches.

1. The entity is in the original tile until the movement is finished (your approach).
2. The entity is in the destination tile once it starts moving.
3. The entity occupies both the source and the destination tile at the same time, as it moves.
4. The entity occupies all intermediate tiles as it moves (differs from the previous one in the case of diagonal movements).
5. The entity can be in fractional coordinates, and therefore occupy tiles partially, and is only grid-aligned when it's not moving.

The choice depends on you. I'd say the last one is the most intuitive and produces the least surprise.

[Gunroar:Cannon()]

Of what I've seen, pure tile based games are normally turn based, though this does not stop other games from using a tile like structure with the tile conversion.
In my projects I always have a tilemap of some kind, but the objects are almost never in the middle of the tile exactly, though they always have a parent tile they belong to. I just get the average/rounded tile they're on and assign it to them. Then use bump.lua lib for collision.
All in all it seems actually more convenient to not do it pure tile way, coding wise at least.
But the solution would have the object to animate/tween to that exact position(if it's moving tile by tile). You don't really need vectors for this one, plus the tweening would make it clean(?) as you can tweak speed and it will land there perfectly. (Can still do vectors I guess, but I think tweening with a tweening lib is easier).

And not everything has to be perfectly inline (like bullets/arrows the player shoots?). I don't know if it's turn based or not, if not you would need normal collision(I suggest bump.lua), if it is you can still use normal collision or you could just check if anything is on that tile for collision.

Edit: Dang it, pgimeno beat me to it while I was typing.

[tomxp411]

It all depends on how you store object locations. If you're storing the location of dynamic objects directly in your map grid, then you might want to re-think that strategy. Usually what I do is store background tiles in the map grid and separately store "actors" (any object that can move) in a separate array. I draw the map from the grid, then draw the actors on top of the map in a second loop during the draw process.

So you can move objects fairly easily in a few different ways. If you store actors' locations in their own object, rather than part of the map itself, then you can just update the coordinates and use fractional values to draw the actor moving between tiles.

[Suttebun]

Offsets! And mentally you just need to separate the DATA form and VISUAL form of your game.
Then as a game developer, stay in the DATA form and see what happens. ♡

There are many tricks and illuuuusions to visualizing your game, but in data form it's always similar for arithmetic reasons.
You do the maths, and then afterwards you abstractly visualize the game.

This even includes a fence like, edge focused movement that stays between tiles.
The rules of staying on the edges is really the same as a regular grid -
except your using two grids. One (illusively) of what the edges are, and one of what the tiles are.

tiles
xxx
xxx
xxx

top-left points (pivots)
. . .
. . .
. . .

edges from points
...|
_ . _
...|

So if we pretend that this point is position [1,1] on our LEVEL grid, put a TABLE inside representing [UP,RIGHT] traveleable directions.

.. to make our map of edges from points
[x][y] = {UP,RIGHT} We make a map with a table in every single cell. To represent every edge as a traveleable data form.

Using a for-loop at the beginning to initialize The Level, we give every point it's [UP,RIGHT] walls and we will then have a map of points to travel around with allowed edge movement. This rouse here is using the position point lower-than's data to find out if DOWN & LEFT is traveleable. It's not a bad rouse. ~ kinda multi-dimensional and opening of other possible systems ;-)

Game Entities still use The Cartesian System. Where is the enemy? What position?
The player and wolves are still on the grid, like the tiles are. It's just the detailed checks where we include the edges.
Example: I'm on the same position as The Wolf - but is he on the UP, or RIGHT edge?

The first thing for Entity interactions is checking and measuring the distance away. (Do Game Rules Here ;-P)
If it is an allowed distance, allow ranged attacking.
Then for melee and travel.. the manual entity movement knows it's target, and checks The Cartesian System if they're higher, lower, left or right.. and moves towards. But this ignores collisions.. Until we include knowing blocked POINTS on our point grid - and blocked EDGES on our whimsical edge grid. Then we can do an automatic entity movement.

For our characters to pay attention to collisions.. On movement, their brains permeate branches (like many x,y checking snakes) to find a path to the target. Keeping track of and closing possibilities, working out all the new paths until the right path is found.
Once you program your Pathfinding Function, come up with a name for it - save it - and you'll never need to write one again
for this type of GAME SPACE, unless you'd like to test faster solutions and methods!
(come up with your own to prepare for future challenges.. again, you may come up with new dimensional spaces,
and you'd like to know the steps to maneuvering it ;-P)

edit: I don't often build in static worlds, but you could also create a grid of tables for every final position (edges inside walls)
of all the possible ways to travel the level, if your level is static and unchanging.
This would then be a NAVIGATION MAP for entities to use, instead of pathing individually.
I'd calculate these positions and save the NAVMAPS before hand, so the players don't need to!
The downside would be that this pathing does not rely on the entities senses.. which is a step towards actual life haha ★

If this helped, please let me know. ☆
If you have any immediate questions -
or want to chat games.. message me!

(also, I suggest making images for your questions.. because I don't even know if this is what you asked for haha)

[darkfrei]

Am I thinking about this the right way?

How about this one? (use wasd to move the circle)

[togFox]

Thanks all and thanks Darkfrei. Very useful.

I think I'm going to try to go with tile 'fractions' so that the wolf is in tile 1,1 and then 1.1/1.1 (decimals) and then 1.2/1.2 etc. I'm hoping that maps to screen x/y well enough for drawing and for collision then I can round 1.6 (or whatever to the nearest tile and that will be the 'hitbox' so to speak.

Simple in theory so we'll see.

[darkfrei]

With the respect to dt, we are nned some buffer, that makes the same.

Code: Select all

end_distance = 1
-- update
buffer = buffer + dt
if math.floor(buffer) >= end_distance  then
	end_movement() -- needed small position: correction, x = math.floor(x+0.5); y = math.floor(y+0.5)
	buffer = 0
else
	continue_movement(dt)
end

[togFox]

I'm using isometric tiles so I'll have to check if the math needs adjustment but I get what you're saying.