Original Post
Hi all, I have been working on my game for a long while now, and have a decent framework and engine running. The game is a 2D tile-based RPG, using fine movement (e.g. players move by pixels, not tiles). Collision with the map is done on a tile-basis, and collision with objects is done on a fine- (e.g. per-pixel) basis. I have progressed in its development such that I am at the point where I am adding player movement. I have read up on various algorithms and theories for synchronized network movement (dead reckoning in particular), but I don't know much about these, so I'm sure my research is primitive at best. In my game, players may move one of eight cardinal directions. What I am considering as a basic system of movement is: 1) Movement Request Client to Server - client requests to move in a particular direction - server checks position+velocity, and notifies all nearby players of the movement change 2) Movement Update Server to Clients - server performs movement of all players X iterations per second, using time-based velocity - if a player *should* stop moving due to collision with an object/player or collision with an impassable map tile, nearby players are updated with that player's new position and velocity - if a player approaches within X tiles of another player, both players receive the update of "new approaching player" - if a player leaves another player's vicinity, all nearby players are notified 3) Direction Request Client to Server - client requests to change facing - server verifies it can happen (e.g. player may be frozen/immobile) then updates nearby clients of the results 4) Position Update Server to Clients - server determines that a client must stop moving - specialized form of Movement Update, which assumes velocity=0, to lower network throughput This is really all the movement that the game needs; I'm curious to know if there is a simpler method of handling movement, or if there is anything which I have overlooked? Best regards, - DH
