Replicating Gameboy Sprite Movement in Java

Started by
1 comment, last by Zahlman 13 years, 5 months ago
Hello everyone,

I've been trying to figure out how one could code so that if the user releases the movement key and the sprite hasn't reached the next "tile" that it will continue to move till it gets there.

The only way I can think to do it is to have an if statement that if the sprite isn't completely in the tile it was moving towards, it will continue moving until it is inside the tile.

I'm sure there's a better way to do this, any suggestions?
Advertisement
Try having the move action entirely predetermined from the start, rather than continuously moving as long as a key is held down and handling some special logic if the key gets lifted before movement is complete.

In other words, have logic somewhere in your game loop along the lines of,

"IF sprite is not 'moving' AND keyboard is pressing in a certain direction, THEN begin 'moving' one square in that direction.

IF sprite is 'moving', THEN move it a bit closer to its destination.

IF sprite is 'moving' AND sprite is at its destination, THEN stop 'moving'."

Under such logic, it doesn't matter what the user presses in the time between when the sprite begins moving and when it's finished moving its one square. For all it matters the user could roll their fingers around the arrow keys, and the only direction that will register is what the user is actively pressing when the sprite has arrived at its destination square.
No matter what kind of game you are making, you should be separating the physics (the logic that dictates what can move and how) from the rendering (the logic that draws things on the screen). Whatever you display on screen represents the location of objects but does not encode that information. Rendering functions should be "pure" in the sense that they do not modify the game state (i.e. the information that is calculated by physics is read by the rendering code, in order to figure out what to draw, but never modified by that rendering code.)

When the physics restricts sprite movement to the tile grid, it is normal for the physics to encode the sprite location as an integer tile coordinate. Movement between tiles is an animation trick that depends on the previous location, the current location and elapsed time; but in any event the user input is controlling the actual physics position of the object, not the screen position.

This topic is closed to new replies.

Advertisement