Smooth grid movement

Question

Hey guys!

I'm working on a Java Bomberman clone, using a grid system, and I'm not really satisfied with the movement right now. When the player presses a movement key, the character starts to move (with 0.25 speed). The player loses the control, and the character keeps moving until it has moved a full tile. The player only regains control when the character gets to the center of the next tile.

This makes it's too "laggy". If I want to change direction now, I can't.

Maybe I could make the base of the character smaller than the size of the sprite, meaning I would have to check ahead of the corners to check if it was a valid move. Any thoughts?

Thanks!

Answer 1

You should be able to get rid of current sprite and load the new one exactly when you need it - i.e. if the character moved half way to the next tile and the player presses a key to return, cancel the sprite and load the new one starting at 0.5.

Answer 2

I guess it depends on how you want it to behave.

Say you are moving up, and you click right.. do you want it to stop moving up and go right? I would store the previous grid location when you make a movement. that way if you click to move elsewhere you can hop backwards and change the movement direction..

Or if you are moving up and you click down... you could set the movement speed to be the opposite of what it is...

It is hard to answer with out knowing what you want it to behave like.

Answer 3

I just played Bomberman a few minutes ago :) You can move pretty smooth, there no grid calculations. I haven't used Java that much. I use Flash a lot. Is the Grid for checking collisions ? What is it for exactly ?

Would it make sense to have something like(I'll try to sketch it):

float vx,vy = 0;//velocity on x and y 
Character bomberman

void keyDownHandler(KeyboardEventSomething event){
 if(key is Left && ! Right ) vx -= .5;
else if(key is Right && !Left ) vx += .5;
//idem for Y axis
}

void keyUpHandler(KeyboardEventSomething event){
vx = vy = 0;
}

void updateLoop(){
  bomberman.x += vx;
  bomberman.y += vy;
}

I might be a bit off, because I'm not sure how much you want to clone Bomberman or not. What you're describing with the grid movement seems closer to hopmon

Answer 4

Don't disable user input. Ever. Constantly poll for it.

Have a Tick() or OnFrameEnter() function that does the following:

Poll the keyboard/joystick/whatever, and cache the last direction entered by the user.

Check the position of the character.

If the character is idle in the center of a grid square, set it's velocity in the proper direction and upate the movement one step, unless there's a wall/collision object in the way. Also clear out the last key press to some invalid value.

Else if the character is already moving, update the position of the character, checking for collision with a wall, or proximity to a direction changing node (intersection). If it collides with a wall, stop the character. If it's close to a direction changing node and can travel in the cached direction, change the direction and clear the cached direction. Else if the input direction is opposite the current direction (it's in a hallway and the player wants to reverse), reverse the direction and then clear the key press. This all assumes that the character should continue moving, always, until it hits a wall and stops. If you want the character to stop anywhere, a reverse direction key should simply stop it in place.

Caching the key press allows the player to preemptively change directions as the character approaches an intersection. This way the character doesn't have to wait to stop before moving on, and the player doesn't feel the game is unresponsive. Polling constantly lets the player reverse directions at any time, and makes direction changes at intersections seem faster.

Answer 5

It sounds like you update the players position (start of the animation) by changing the grid cell in which its contained.

To be able to achieve the desired effect, the sprites render position should be independent of where the entity represented by that sprite is located on the grid. And allow the user to move inside that grid within a range of the cell's center without changing cells. If this range is not chosen correctly you may en up with the "doh! im in this (visually) cell but it says im in the future cell" problem, or the "my avatar is overlapping a wall".

Dont change the players cell until he is within a range (lets say 1/3 of the bounding sphere of the sprite) from the limits/borders of the cell that contains him. You would also have to modify the animation process for it to be interruptible.

This is independent of the degrees of liberty you give the player (like, it could only move up, down, left, right, and diagonals vs 360 degrees)

Another thing you should watch out for is, if the sprite is larger than the cell size. For instance, a Fat monster, or a Snake boss which spans across X cells but not necessarily in rectangular form.