# Player Movement

This topic is 4431 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

What is the best method for handling player movement in a client-server 2D tile based real-time game? I know about dead reckoning, but that is only part of it (and the only thing I was able to find info about when I searched the forums). VBStrider

##### Share on other sites
What is special about tile-based? Do you move only onto "whole" tiles (a la strategy games) such that you can't be "between" tiles? If you send positions to clients, and use some form of interpolation or dead reckoning, what part of that doesn't work for you?

##### Share on other sites
Yes, players cannot be between two tiles.

I have attempted writing this myself, but the system did not work out (players jumped too much). Which is why I'm asking what the best system to use is.

VBStrider

##### Share on other sites
Well, if the player can't be between tiles, then the player needs to jump between tiles.

What I would do is send the destination tile, and then have each client run path-finding for the player from the source to the destination. Move the player along at some pre-determined walk/run speed (i e, one square every 0.5 seconds or whatever) along this path-found path.

##### Share on other sites
There is no jumping as far as the server is concerned. It sees positions as tile positions, not pixel positions.

What is the destination, and when should it be sent?

VBStrider

##### Share on other sites
Quote:
 What is the destination, and when should it be sent?

The destination is where the player wants to move to (or NPC), and it should be sent in the next available update packet.

##### Share on other sites
The player is moved by the arrow keys, so the destination in your system would be postion+1?

When is the update packet sent?

VBStrider

##### Share on other sites
this is how i handle it in my 2d tile based MMORPG. in my game though you aren't limited to moving from tile to tile. since that is how yours is, it should simplify things a lot.

FWIW, this is how i handle it though:

- when the user presses an arrow key, he sends to the server "i want my direction to be X"    - server gets this, starts moving on his simulation, then tells the player and everyone else whos important "player X is moving in direction Y"- when the user releases the arrow key, he sends to the server "i want to stop"      - server gets this, stops the player on his simulation, and then tells the player and everyone else "player X has stopped"

If you handle it like this, you will only have to send a packet when the player changes directions...... this means if they are moving for long distances in a single direction, you will never have to send any movement packets...... seems like that sort of thing might be common in a 2d RPG, you might want to keep that in mind. of course, this might not work for you depending on how you partition your world network wise.....

##### Share on other sites
graveyard filla, that is the system I am currently using. However, players get out of sync slightly and when the stop packet is received, the player is jumped to that location. This causes players to appear to jerk around while moving.

VBStrider

##### Share on other sites
why are they getting out of sync?

make sure you are doing it exactly like this:

-player pushes arrow key but does NOT move yet, only sends "request to move" packet     -server gets this message, validates, starts moving the player on HIS simulation, and then sends back to the player + all players who are important "player X is starting to move"            -the player who requested to move, as well as the other players in his area get the message. then they start moving that player on their simulation

if you do it like this, you should be in perfect sync. the server is running the "live" simulation, and all the clients are watching a slightly delayed version of this simulation - however they are all watching the same exact thing, just at different times. you basically sacrifice response time to have this perfect sync, but in a 2d MMORPG it is perfectly acceptable. in fact, my game is heavily action based (you can aim and shoot in 360 degrees, real time) and I still find the movement delay perfectly acceptable. you can even start getting more complicated with prediction and interpolation to makes things appear even smoother...

• 10
• 17
• 9
• 13
• 41