Original Post
Hello, I'm currently developing a small 2d mmorpg using Tcp for networking. I did position synchronistaion over a centralized server for another game some time ago, but it used a grid based coordinate system, and mouse input to target a cell you wanted to move to. This was quite easy, as a client only needed to tell the server it wanted to move to grid X, and the server would tell all clients in range, that player 1 is now moving to grid X. All clients in range would then move the sprite for player 1 from it's current location to grix X taking into account the player speed. Not only was this very easy to implement, but the networking was completely event based (there was no need to send position updates every x ms). However, my current game is a different animal. It's more of a hack&slash style game, meaning you are able to freely walk around using keyboard input. So there is no "target I want to move to" anymore, only a walking direction. I spend some time thinking about how to properly implement this, but I couldn't come up with a solution that I knew would work out. Here are a few ideas I came up with though: - Clients should only send a walking direction to the server. Maybe it would be sufficient to only send an update in walking direction if it actually changes, I don't think I need to do this every X ms, tcp should make sure the packet get's to the server. If a client has packet loss / lag though, this would cause them to keep running into the same direction until the delayed packet get's there. I'm not sure if this is a serious problem though, from experience network issues don't occur very often, and if they do, they're so bad it's unplayable anyways. - This is where I get lost, what should the server send to all clients in visual range? Say it just received from player 1, that he's running up now. What do I send to all clients in visual range? One possibility would be something like the playerid and direction.up only. The client would then make the player sprite with the given id walk up until it recieves something else. This would mean no real position checks though, so maybe the server should send a player position to everyone every time a player stops moving? Clients would check how far it is off from what they got, and correct if necessary (in this situation the sprite would jump though, and I see this happening rather often). Another possibility I thought of would be for the server to send the internal player position every x ms (if it changed) to players in range. The clients would then make the player sprite walk into the direction of the position they just received, and stop once they reach it. For some reason I don't see this working either. It shouldn't result in "jumpy" sprites, but it may result in an additional increase in delay, because the clients only get notified after a player has moved, and not once a player starts moving. I'm also not sure if this would result in fluid movement. I'm not even sure if I'm approaching this right at all, I've noticed that in some online games, your character starts moving the moment you hit a movement key, so the client is acting witout a server reply. I have no idea how they manage to keep that in sync. I'm assuming they don't treat the client who sends movement information the same way they treat observer clients. This may be what I actually want though, because in a fast-paced game with direct input (as opposed to clicking where you want to go), any kind of delay between hitting a key and your character moving will be somewhat annoying. Any insight on this would be greatly appreciated :) Hyu
