Networking and movement in MMORPG's UNITY

Question

I'm programming a dedicated server in C# using BeamServer2 DLL's. At first I wanted to be able to see other players move on our already made Omuni map. This I did by just sending your position to the server each frame. This worked out and I was able to play with a few friends but the movement wasn't laggfree. So I started trying to add movement smoothing and also some security so they can't just send a false position to the server without the server stopping it from reaching the other clients.

What I than did, I made a masterClient that has a movementController on the remotePlayer. When a client wants to move he moves localy and sends a message to the server with hes direction to move. The server than takes hes speed and sends it to the masterClient. The masterClient than moves the remotePlayer just like the remotePlayer moves himself. When he stopes moving he sends a message with hes position in it. The masterclient than checkes if the position that he has come to is as close as the position he has from the client, if it is realistic according to the ping of the client the server puts him on the client's position.

This works, but I still have a lagg problem and I'm not sure how to fix this. I must make movement smoothing on the client but I found out myself that I can just lerp (x/2,y/2,z/2) to the position and put him on the real position next frame, I failed at that and I will try again soon. Even if that is added I'm not sure if the lagg is fixed.

Any other techniques, suggestions, questions, ... ? Thanks, Diede.

Answer 1

There a many problems/tasks involved when programming "no lagging" realtime network games.

• hardware speed (CPU power needed pr. player both client and server)
• network distance and equipment (connection LAN or WAN?)
• server bandwidth (how many players)

Secondly you have the "bad guys" who always tries to cheat in games. If your game is going public, then consider what would happend if I sat down and injected "false" network packages. Consider if someone posted "unreachable positions" or "full health/ammo".

My suggestion for your architecture for a start, would be something like this:

• Server, controls all vital data, calculates AND validates movement.
• Client, receives data on what to show on the screen + some "think ahead" data on moving objects.

Most realtime FPS's as I know, does some sort of "we know you are moving this direction at this speed, so we just simulate that until we get other details from the server"

So your client should post "what it requests" and might even start to move itself that direction, but it might get "forced back" by the server if the server rejects the movement. Here you have to think, what if the client posts "false coords" outside the map, or suddently "jumps". The server needs to track if the new position is possible from its previous point OR the server just receives the message that says: "CLIENT MOVE FORWARD 200" and then the server process what this will do according to map and game data.

This will give some lag, but again, if you let the client receive these data and does some math itself, it does not need an update every ms/frame, it can lag a little without noticeable lag on the screen.

Perhaps you can even divide the map into "virtual tiles" (if its a vector game) so that you have a fast way to calculate where the objects should be next.

World of Warcraft/Battlefield/Counterstrike

I believe WOW is doing it this way too. You press a key, the server receives your movement "wish" and reply with "you are moving now" and then the client shows this + the server simulates the new position on the server in some sort of "session pr. client". This is were the "maximum amount of players pr. game" is getting nasty, because your server has to keep track of everyone and basically do this as "turnbased" - but so fast that it looks realtime.

So...

Foreach (Client in GameSessionList)
{
   ParseInput();
   ParseMovement(); // including collission test
   ResponseSend(); // new positions+movement data for client and objects/other players
}

Answer 2

The challenging part in lag compensation is that you will get updates from clients that are out of order. A laggy client's command sent at time T may very well arrive after a non-laggy client command sent at T+40ms. Applying the commands in the order you get them will lead to all sorts of nastiness. Doing it correctly on the other hand involves winding back time and replaying all commands that have been issued since.

There is no easy way around this, but there are multiple valid solutions. You can find a relatively easy one described here.

There's a lot of research in this field, have a look around!

Answer 3

I'd create the client like it's a non-network game. That is, anything you do you do it immideately on the client. Then add, parallel to that, your network code. This code will get the movement data. Simple as from coords, direction and speed. It just sends this to the server who validate. Server sends you an ok or a new position.

So you have all you client code running like it's alone in the world. Then it just recieve new correction data from the server or an ok. If you press forward and hold it for ten seconds, then the server will just recieve that one data. You might concider sending/recieving data every second even though you're just holding the forward button, or else, if you hit a lag spike you might run forever.