Help with smooth movement and collision testing in tile based game

[evilman772]

What is it you are trying to achieve?
I am making a 2d tile based rpg game, and I wish to have my character move in pixels instead of by tile.


What is the problem you are having?
At the moment, I have the player moving tile by tile on my map, as that is how I am checking for collision. However, I wish to have the character
move by pixel instead to make it seem smoother, but I cannot figure out how I will check for collision with this.


Describe what you have tried to solve this problem
I've attempted to check collision in different ways but none work as the logic is flawed.


Post any relevant code (You may choose to attach the file instead of posting the code if it is too long)
This is what I have atm with it moving tile by tile. The map is 20x20 with each tile being 32 pixels. The map is a text based file.

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
1 1 1 1 1 1 1 0 0 0 1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1
1 1 1 1 1 1 1 1 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Turing:

View.Set ("graphics:640;640,offscreenonly") var maptiles : array 0 .. 19, 0 .. 19 of int var FileName : string := "map.txt" var stream : int var map : int := Pic.FileNew ("map.jpg") var person : int := Pic.FileNew ("right1.bmp") open : stream, FileName, get for decreasing y : 19 .. 0     for x : 0 .. 19         get : stream, maptiles (x, y)     end for end for close (stream) var key : array char of boolean var playerx, playery : int := 1 loop     Pic.Draw (map, 0, 0, 0)     Input.KeyDown (key)     if key ('a') and maptiles (playerx - 1, playery) = 0 then         playerx -= 1     end if     if key ('d') and maptiles (playerx + 1, playery) = 0 then         playerx += 1     end if     if key ('s') and maptiles (playerx, playery - 1) = 0 then         playery -= 1     end if     if key ('w') and maptiles (playerx, playery + 1) = 0 then         playery += 1     end if     Pic.Draw (person, playerx*32, playery*32, picMerge)     View.Update     delay (50) end loop

Please specify what version of Turing you are using
4.1.1

Thanks in advance for any help given!

[Insectoid]

Since you only care if you can walk to the destination tile or not, your collision checks don't need to change. You're going to need to change how your character moves though.

This can easily be accomplished with a simple walk procedure. Once you've checked if you can move to the target tile, you just need to move by 1 pixel, 32 times instead of 32 pixels one time. Your procedure should consist of a single loop that runs 32 times and modifies your X or Y values in the direction you're trying to walk.

If you plan on doing anything else while the character is moving, such as other animations, it will get a little bit more complicated. You'll need a variable to store where the player is trying to get to. If he isn't there yet, move one pixel in that direction. If he is there, don't move.

[evilman772]

Hi, thanks for the reply! I am most likely going to be doing something like other animations while the player is moving, so I'd like to refrain from having movement in a procedure that will have to wait till the procedure is finished.

For you second suggestion, I am a little bit confused. What exactly is the variable of where the player is trying to get to? The movement of the character is dependent on the player, so how will I be able to set a destination of the character?

[Insectoid]

Oh, I thought you meant that if, say, the player presses the 'up' arrow, the character will walk up to the next tile. If you want completely free movement, then it gets a bit simpler. Movement becomes pretty standard- if the left arrow is pressed, move left a pixel, etc. Collision detection becomes standard rectangular collision detection as well, though it can be heavily optimized- since you know which tile the player is on (or rather, you can easily calculate it with some division), you only need to check for a collision with the adjacent tiles in the direction he is moving. If he's on tile (5,5) and moving up, you only need to check tile (5,6) for a collision. If no collision occurs, then he can move up.

[evilman772]

Sorry about that, it seems I was too vague with my description. Yep, I'd like to have completely free movement just as you described.
The problem I have with what you're suggesting is that I can't seem to understand how to check for the collision if my character is moving by pixels.
Let's say I make him move 8 pixels every time the arrow is pressed. How would I decide what tile it is in if the character is the size of the tile, 32 x 32?
With that, how would I check for collision if I am moving by pixels?

[Insectoid]

Quote:

How would I decide what tile it is in if the character is the size of the tile, 32 x 32?

He's going to be in multiple tiles at the same time, so you need to check all the tiles he's in (and you can calculate this with a bit of math). To move left, check for collisions against the tile to the left of the left-most tile the character is occupying. Naturally, you might want to check the tiles above and below that left-most tile.

What you should do is draw a grid on paper, and put your character in various spots on it and decide which tiles you need to check for collisions against for those spots. From this, come up with a set of rules that determine when you can move where, no matter where you are.

Only once you know this set of rules can you actually write the code. This isn't just for new programmers; it's a universal rule. You can't write working code if you don't already understand the solution.