   2D MMORPG Movement?
  I've started developing a map based 2D MMORPG. I'm developing the engine myself using Adobe Director which is working fine. Basically, a character connects to the game and is on a map, you move from map to map by leaving the screen and it's a fast paced hack and slash style game.Currently movement is working terribly. When a client presses the UP arrow key, it animates the sprite and moves them one tile UP, it then sends a message to the server containing the direction I have moved. From there, the server then sends a message to each player (excluding the character that walked) on the map containing the player's ID that has moved and the direction in which they have moved.I have around 3 players on a map and the lag is unbelievable. Players are even going out of sync at times based on their connections. I have tried both TCP and UDP and it just seems that packets get queued up and take forever to come through.I've read a few guides on the forums but a lot of them are for 3D gaming environments which is unrelated to my project.Basically, I am wondering what the best way would be to have the sprite positions synchronized across all the clients on a map without insane amounts of lag?Thanks in advance.   
  You might want to check out (how to remove) the Nagle algo, as it might cause insane lag.   ;  The suggestion to remove Nagle's algorithm is definitely a good one, and is probably the solution if packets are being queued up. Also, make sure packets aren't being sent every time the game is rendered or updated. Movement packets for a game like Zelda should probably be sent 2-4 times a second.If things seem too rigid, I'd suggest letting players have positions that aren't grid aligned. Rather than forcing players to sit in cell [1, 1], let them be at [1.523, 1.478].If movement seems jumpy, than using relative information, try sending the coordinates of the movement. Rather than saying the player (wherever s/he may be) is moving up 1 cell, say the player (wherever s/he may be) is moving to cell [6, 8].Or, if you want to stick to relative position, make sure to include length of the movement vector, rather than just direction.Do everything on the client at first to see if it fixes your issue, then have the server authenticate to see if that position is actually possible (speedhack & wallhack prevention).Most importantly, if you aren't doing so already, make sure to interpolate positions.   ;  Thanks for the quick replies.Would I best using UDP over TCP for this style of game?I may sound a bit like a noob but what is interpolation?   ;  If you want an action game there is NO WAY to avoid some kind of prediction/interpolation. UDP won't help you much.You need to predict where the players will go next. For instance if the last time you got a packet from the player he/she was moving east at one tile/second. So, until you get new information you keep repeating the last movement. The downside is if there is huge lag, information will be very inaccurate. Also the server needs to adjust this info from time to time, since it's the only one with the true picture of the situation.Did it ever happen to you in Quake where you picked up the rocket launcher and theserver removed it from your hands a second later? That was the prediction failing and the server correcting the situation.More advanced simulations on the server is also possible to give all players the full picture. Also, sending your own keypresses to the server and treating the local player as another network player is bad too, since then the local player will lag too.It's a huge task getting it to run well, but you might get away with something simple since you move a tile at a time, instead of needed smooth acceleration and stuff.Interpolation is where you generate information you don't have from some control points on the timeline. Used in 3D animations/movement a lot. For instance. If you get erratic messages from a client he will jump around on screen. Instead determine a control point from his/her current position/speed sometime into the future and then generate the movement position inbetween. When you get real information from the network just add it as future control points. That way movement will be smooth, but might be somewhat inaccurate. The gameplay/test will usually determine what's acceptable.The worst situation with interpolation/prediction is where you seem to get killed even though you where not hit. Again gameplay/test/tweaking will determine what is acceptable :);  Currently the local client does not wait for the server to respond to move. When I press the arrow key, it runs moves my sprite then sends the message to the server. The server doesn't tell my client to move my sprite, only the other plays on the map. I did it this way to ensure smooth movement. I didn't want the movement to be completely server determined like Tibia, I find it impossible to play.Would it make sense to send 1 message when a key is held down and only send a packet again if the key is no longer being held down?After doing some tests with the Adobe Multiuser protocol (a very badly undocumented protocol) it seems that clients receive messages in increments of 150ms. So if the server sends 50 messages, it will receive them individually every 150ms. This may also be a cause of the lag.I just can't seem to find an efficient way to develop this.   ;  It's fine that you don't wait for the server when moving the local player.I think you should somewhat adjust how fast they can move so you won't get too much lag. That way you can predict where players will move next within a certain accuracy.It makes sense to send keypresses to the server to keep it simple (or directions).But then the speed must be limited. So when the server gets an updated movement it sends a position and direction to everybody. That way you keep moving players in the last direction they send at a certain speed and then adjust the position when you get a real server update packet.That way the server can also validate the movement. And since they only send directions, only the server knows their real position so a rogue client cannot teleport around the map.You can tweak the speed of movement to counter the lag. Too much lag will never be truly fixed, but if the average player experiences smooth movement with the speed you choose, then it's probably alright.This is the most simple solution and the one I would personally try first.I'd like to hear how it works out if you try this solution. Only used it a few times, but with great success (although in none-action games)   