   Player movement for a rpgish real time game
  Im a little lost (and over my head here), I have manged to get my TCP based winsock server and client up and running and working well together quite effectively.How I am currently handling movement is really really bad! and im looking for some guidance on how I should handle movements I receive from the server as far as animation etc...I have read over most of the stuff posted on http://www.gamasutra.com/features/20010322/terrano_01.htm, the 1500 archers arcticle, im not sure if that system would work for me.Do you think this would be a good option? maybe you will need some explanation on my game here is a run down..Basically its at its core its going to run like a RTS (this is all in 2d), but players control their individual player using keyboard input... as of right now im sending hard X,Y coordinates for every move a movement packet would consist of something like this:Player ID, Rotation, X, YWhere rotation is just a number specify the direction 0 = north 1 = east, etcIts working but its really bad! Clients get out of sync and get rubber banded back very quickly. if I move my clients slow enough everything works fine but im going for more quick action instead of a slow dumpy RTS style..When a player movement packet is received (on the client) a animation event is started for that player if I receive a new animation event before the first one is completed the player is teleported to the new start location and that animation starts..Im thinking im going to have to do something like this:Some how sync all the clients to a consistent tick count and when the server sends out movement packets it has a time in which that movement is supposed to be completed?Basically the server would run 200 ms ahead of what all the connected clients can see on their simulation?Im really lost here any help would be appreciated I have seen alot of stuff using interpolation and extrapolation but can this be applied to a 2d game?Would I be better off just sending velocities and rotations? so that I could implement something like EPIC?Any help would be greatly appreciated =p, and thank you for your time if you read this big wall of text.   
  First, you should read through the Forum FAQ. It really does answers most of your questions.Second, you should use forum search, because almost exactly these questions have been answered in this forum in the last two months. (Perhaps you could just browse the last 50 threads, even);  Heh, I thought I did maybe I missed something..I was more asking if something like epic would be good for a 2d based system not based on velocities, or should I just rework all my player movement code to use rotation / velocity so I could implement something like EPIC.Sorry for lack of direction in my post but I check this forum constantly and almost all of the reply I have seen have dealt with using vectors and game movement in a 3d space.. I figured 2d movement would be alot easier, but I was just kinda lost...I will do as you suggest and try to find some previous posts on 2d interpolated or extrapolated movement.   ;Quote:For an RPG like that, when the player is moving, I would send a "position and velocity" (or maybe just "position") packet twice a second, and the server can forward it to interested clients. When the client receives the packet, it can use interpolation to move the character towards that position, or it can use extrapolation to place the character at the position and move it in the given direction, or some variant thereof (such as the linear spline in EPIC).I think im going to just have to go with this, I think originally I was trying to use a 4 direction method for network movement when apparently its just easier to change my graphics engine to use position and rotation instead of position and compass directions.  Horray for way too many 2d animations!EDIT:I also think maybe some sort of frame lock for input would work nicely on the clients maybe at around 30 fps.EDIT2:I also apologize =p There was a post on Network Efficiency (in the faq), this has almost all the infromation I was really looking for, I think the real key here is to just scrap the system im using because its bad and not worth using when its just so much easier to use velocities.[Edited by - yewbie on June 19, 2009 3:12:49 PM];  I do have one question, do you think this would work?Basically I just send my x,y,facing movement packets like I am doing when the client receives them it runs a pathfinding function to makeup the movement from the current position to the position we just received, and the speed in which it moves to that location is based on on how far behind it is from its actual location.EDIT: Because of how im sending the actual movements are always received so I could just keep track of them and play them out in actual order.IE: we receive a player packet at 4,4then we receive the move to 4,5 and 4,6 from that same player at the same time, since he is 2 squares away from where he was he would move to 4,6 at double the movement speed of moving just one squareI don't really think I have having the synchronization problems that I thought I was having, the local client always has correct information about where the remote client is I was just not using that information to draw where the player is very well.Any input on this would be appreciated.[Edited by - yewbie on June 20, 2009 11:56:06 PM]