Simple basic question.

Networking & Multiplayer
#1

I am trying to make my RPG game multiplayer, and this is the first time when i meet with servers.

When any of the players move, a thread sends their position to the server, and then the server transmits the position to the other players. Is it ok to do it like this or i should send a message to the server when someone press a key, and then the server computes the position and send position to the others? If i should to the other way, how can i manage to check collision? ???

#2

The answer to this question is highly dependent what you desire as far as gameplay. There are pros and cons to both systems.

Are your clients constantly moving around?
Will other connected clients need to see them in their exact positions or can they be fudged a little? (think WoW where everyone sees each other in slightly different positions)

In an fast paced game (think first person shooter), the client should be sending only their inputs to the server. The server receives the inputs, validates them, applies them to its version of the game world, and ultimately sends the client back a snapshot that contains their changes. The client is never trusted to determine its own position (or health, money, etc.). Pros to this system is it’s not possible to cheat the server by telling it impossible things. The server will determine the outcome of all actions so they are always correct. Cons are increased communication necessary between client and server and having to implement more client side prediction and recovery code to make inputs appear instantaneous. It simply wouldn’t do for clients to wait 150ms round trip before their actions took effect, so you predict what will happen on the client side and make corrections based on what the server tells you later.

If your game is twitch based and your players are taking aim at each other, then it makes sense to implement a snapshot based system so everyone is seeing the same thing. If your game is more target based, like you select someone and then cast a spell but never have to aim the spell, you might be able to get away with sending just positions (and doing some checks for impossibility). This is what many MMOs do because it allows them to lower the amount of traffic to the server for basic movements.

Edit: As far as collision detection goes, this is just another thing that the server can do on its end and inform the clients of. Here’s sort of an outline of what a server might do in a FPS:

every 15 millseconds:

  1. check network for updates clients have sent me, store the unprocessed input for consumption
  2. for each player in the world, apply any unprocessed input gathered in step 1
  3. run a simulation step and update the game world based on the time since last update (ex. move any projectiles forward)
  4. check all game objects for any collisions, perform appropriate actions (ex. move players back so they aren’t colliding, apply damage for any projectile hits)
  5. clean up the world, removing dead entities
    We have a world that is completely up to date. We could send a snapshot of this world to all players, but it’s usually not necessary to do so every tick.
  6. if it’s time to send a snapshot, create one and send it all connected clients

More information: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

#3

The second: send movement commands to the server, then have the server tell you and the others where you are. You’ll want to do some prediction on the client side, otherwise things will feel really unresponsive. If the client’s prediction is wrong, the player will appear to jump around, which is what happens in most online games. Ideally you get them to converge on a compromise position that actually gets rendered, but usually it doesn’t happen that way, people just live with the stuttering movement.

Collision detection is easier when you compute all positions server-side, since you can use basically the same code as you would for single-player.

#4

Ok, so my idea isn’t good? Until now i used to move the player client-side and send the new coordinates to the server, and then the server send those coordinates to everybody except the user that sent them.

My problem with this is that the movement isn’t smooth enought…

#5

That’s why you interpolate, aka you make the players smoothly move from one position to the other.

#6

And what is the delta in server transfer? How can i calculate it, and how can i handle it?

I am already interpolating the client’s update delta, but how i manage the server one?

#7

You should really read the source multiplayer networking link I posted. You’ll probably need to read it over a dozen times to fully get all the concepts but it’s all layed out quite nicely in there.

I’m not sure I totally understand what you mean by ‘sever delta’, but if you go back to the outline I gave above, you’ll remember that the server is sending the client snapshots of world data. This is typically done every 50 ms. So imagine you’re a client and you’ve just received a snapshot. It contains two things: world data and a timestamp of the server at the time it was created. You now have a snapshot of the world as it was at the time given in the snapshot.

For now I would just assume that both client and server are synced on the same clock. This is absolutely untrue but just getting started it won’t be helpful trying to also work in clock syncing. And for now since you’re developing locally you can put off worrying about ping, since it will be close to 0. These two things you will later need to work into your system as ping and clock deltas obviously do exist, but for the time being assume the server time of your snapshot is also local client time.


public class Snapshot
{
    public long time;
    public WorldData worldData;
}

Just starting out to make sure everything is working you could immediately update your local client version of the world to this snapshot. It will be synced but since you’re only receiving updates every 50ms, it’ll be very, very choppy. How do we solve this? We need a way to get the snapshot of the future state. This is done by moving the client view of the world back in time. If we did so by say 50ms (we’ll call this view lerp) then we’d usually have one snapshot to move forward to (assuming the snapshot packet isn’t delayed or dropped on its way to us). So now you have version of the game world as it will be 0-50 ms from now. Every client update loop you can calculate how close you are to that upcoming snapshot and move everything towards their final authoritative positions (this is called interpolation).

I think that should be enough to get you started, but there is obviously more to it. Most games move their view lerp back 100ms in case a snapshot is dropped, they’ll always have another one to move forward to. Again, read that link, it has all these details and much more.

#8

Interesting read, ta.

There’s also the Q3 article which is quite elegant: http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

#9

Forget what anyone has said in this thread, just get it working over LAN first. Then take suggestions.

#10

You still have a client-server architecture whether you’re connecting via LAN or not, and the same set of challenges as far as how the two should communicate still apply. You have a lot more reliability and less lag over a LAN but since this is more of a discussion about how servers keep clients updated on game state, I don’t see how LAN makes any difference.

#11

I made a game with only movement over lan, disasterously laggy… even when the same pc hosts and acts as a client connecting its noticably jittery lmao.