• Create Account

# Another 2D tiled RPG movement question

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

5 replies to this topic

### #1StarHustler  Members   -  Reputation: 129

Like
0Likes
Like

Posted 02 October 2013 - 11:41 AM

I have a basic understanding of tile maps and movement, but I'm having trouble moving beyond that. My goal is to replicate the movement seen in NES games like Dragon Warrior and Final Fantasy. Here's the code I've been experimenting with:

x = 0
y = 0
dx = 0
dy = 0
size = 64
t = 10
v = size / t
end

function love.draw()
love.graphics.rectangle("fill", x, y, size, size)
end

function love.update(dt)
x = x + (dx - x) * (v * dt)
y = y + (dy - y) * (v * dt)
end

function love.keypressed(key)
if key == "up" then
dy = dy - size
end
if key == "down" then
dy = dy + size
end
if key == "left" then
dx = dx - size
end
if key == "right" then
dx = dx + size
end

if key == "escape" then
love.event.push("quit")
end
end

Currently I can press a button and the block will move a set distance, which is great, but it moves at a variable speed; it slows down as it approaches the end of it's movement.

Am I on the right track at the moment? I feel like I'm missing something in the math department.

Edited by StarHustler, 02 October 2013 - 12:07 PM.

### #2Kaptein  Prime Members   -  Reputation: 1205

Like
0Likes
Like

Posted 02 October 2013 - 12:17 PM

you are moving by a set amount of distance, but that distance is recalculated each update and getting smaller and smaller

this means the greatest speed will happen at the start when the distance is largest, and progressively get smaller and smaller

what you are doing is equal to linear interpolation: x = x * (1.0 - w) + new_x * w;

### #3haegarr  Crossbones+   -  Reputation: 2370

Like
0Likes
Like

Posted 02 October 2013 - 12:19 PM

x = x + (dx - x) * (v * dt)
y = y + (dy - y) * (v * dt)

Each of these lines calculates the current distance from "here" (x,y) to "there" (dx,dy). The greater the distance, the bigger the step you make. When approaching (dx,dy), the distance shrinks down to (0,0).

What you probably want (and I'm not familiar with the movement system you mentioned in examples) is to get the direction but not difference from "here" to "there". This means movement towards (dx,dy) but with a delta only influenced by speed v and elapsed time dt. This is done like so:

ddx = dx - x
ddy = dy - y
ldd = ddx * ddx + ddy * ddy
if ldd > 0.00001 then
ldd = sqrt( ldd )
ddx /= ldd
ddy /= ldd
x = x + ddx * v * dt
y = y + ddy * v * dt
endif

Edited by haegarr, 02 October 2013 - 12:20 PM.

### #4DekuTree64  Members   -  Reputation: 872

Like
0Likes
Like

Posted 02 October 2013 - 05:11 PM

What I do is store the actual character positions in tiles, and a separate pixel offset used for the visual movement.

Say a character moves to the right, add 1 to their tile X position, and set the pixel offset X to -tilesize. Each frame, add or subtract their movement speed (usually 1 or 2 pixels per frame) to the pixel offset to go toward 0.

For collision detection between sprites, only use the tile position. So as soon as a character starts moving, their old position is empty and new position is full. The gradual movement is purely a visual effect.

When you go to calculate the position to draw their sprite on screen, it will look something like

drawPosition.x = entity.position.x * tilesize + entity.offset.x - camera.x;
drawPosition.y = entity.position.y * tilesize + entity.offset.y - camera.y;

Edited by DekuTree64, 02 October 2013 - 05:12 PM.

### #5Khatharr  Crossbones+   -  Reputation: 2491

Like
0Likes
Like

Posted 03 October 2013 - 11:18 AM

The way I usually implement this is to have an integer variable called pendingMotion. When it's set to zero, you may respond to input. Otherwise, it's the offset of your sprite in the opposite direction of your facing.

Say your character starts out facing down and pendingMotion is zero. You run the frame logic and see that the left key was pressed. You're not facing left, so you respond by changing the facing direction.

Next frame, left is still held. If the tile to the left of your position is passable, change your map coordinate to that tile and set pendingMotion to 32 (assuming tiles are 32 pixels wide).

Next frame, pendingMotion is nonzero, so instead of checking input you reduce pendingMotion by 2 (or whatever - you can adjust this) and continue.

When drawing your character, calculate their position from the map coordinates, then offset it by pendingMotion in the direction opposite their facing. In this case you're facing left, so if pendingMotion is 32, you draw the character 32 pixels to the right of their logical map position.

Any frame where pendingMotion is zero you check the input. If no input is present, reset the character's walking animation to the standing frame. Otherwise increment the animation counter for the character.

In this way you get tile-locked movement, but the motion is smooth when the direction is held.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

### #6StarHustler  Members   -  Reputation: 129

Like
0Likes
Like

Posted 03 October 2013 - 12:22 PM

So after doing some more Google'ing I found a Game Maker tutorial about this topic, and a demonstration. I managed to get it working in LOVE, but I'd be interested to hear what people think of that solution in general.

Edited by StarHustler, 03 October 2013 - 12:22 PM.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS