I've been writing a 2D flash multiplayer game and a socket server. My original plan for the movement algorithm between the client and server was the following:
My current calculation for the client (same math is used in server) ==>
Turning
var newTimeStamp:uint = UtilLib.getTimeStamp(); //set current timeStamp
var rot:uint = Math.round((newTimeStamp - turningTimeStamp) / 1000 * 90); //speed = x degrees turning every 1 second
turningTimeStamp = newTimeStamp; //update timeStamp
if (turningMode == 1) //left
{
movementAngle = fixAngle(movementAngle - rot);
}
else if (turningMode == 2) //right
{
movementAngle = fixAngle(movementAngle + rot);
}
private function fixAngle(angle:int):uint //fixes an angle in degrees (365 -> 5, -5 -> 355, etc.)
{
if (angle > 360)
{
angle -= (Math.round(angle / 360) * 360);
}
else if (angle < 0)
{
angle += (Math.round(Math.abs(angle) / 360) + 1) * 360;
}
return angle;
}
Movement
var newTimeStamp:uint = UtilLib.getTimeStamp(); //set current timeStamp
var distance:uint = Math.round((newTimeStamp - movementTimeStamp) / 1000 * 300); //speed = x pixels forward every 1 second
movementTimeStamp = newTimeStamp; //update old timeStamp
var diagonalChange:Array = getDiagonalChange(movementAngle, distance); //with the current angle, howmuch is dX and dY?
x += diagonalChange[0];
y += diagonalChange[1];
private function getDiagonalChange(angle:uint, distance:uint):Array
{
var rAngle:Number = angle * Math.PI/180;
return [Math.round(Math.sin(rAngle) * distance), Math.round((Math.cos(rAngle) * distance) * -1)];
}
This seems to work great. In order to take lag into account, the server corrects the client's info every now and then by sending this data.
With this system very little bandwidth is used to handle movement. However, the differences between my server and the client's coordinates and angles are too big. Should I maybe extend my "algorithm", to also take into account the latency a user has? Or are there better ways of handling movement in client<>server multiplayer games with great performance?
Most MMORPGs are deployed using a client–server system architecture. The server software generates a persistent instance of the virtual world that runs continuously, and players connect to it via a client software.
Essentially, an authoritative client game means each player relies on their own engine's computations in an online game instead of having the game send online dispatches to the game server to respond to the player's actions.
A game client receives input from an individual user. In an FPS game, for example, a player does many different actions such as move, shoot and communicate. Each of them will require the player to control the input devices. After receiving those inputs, the game client will send it back to the server.
My initial design would be similar to yours, but if that's not working, perhaps you could allow the client to do ALL the movement and just have the server do some range checking.
So if your last reported position was X, the next one must be within a radius from X where the radius is based on the difference in timestamps sent from the client with the x,y data.
Mostly this is just needed to detect cheating.
Stopping, fighting, etc would require a position be sent along with the attack, and actions triggered by positions would only be triggered after the client sent the update for that position but would be server-based.
Not sure this would help too much, but it might stop the jolting resyncs you would see from your initial algorithm.
Comment response:
No, the clients would still inform the server of their position, but the server wouldn't try to calculate the next position. This would mean that the server (and all other clients) would be at least one send/receive cycle behind in position.
I guess I'm saying just let the client do all the work, figure out where the character is and tell the server, but include enough info that the server can optionally check validity to ensure nobody's cheating.
The cheat detection could even be turned off for performance or set to randomly check.
Note: All collision/position info on objects within traveling range would need to be sent to the client for this to work.
There are 2 ways I can think of doing this - have the client issue commands to the server & the server will be the ultimate map keeper.
Or, keep the maps in the clients, & the clients will have to establish connections with other clients they're "near" in order to do movement, with recordkeeping being done by the server & checked by a few peers (hacker police).
Interesting to me is the possibility to monitor peer connections, and peers that have a latency above a certain threshold just won't show up in the game.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With