MMO - How are you guys handling multiplayer movement?

[Orthonormal]

To the friendly folks developing MMOs. :D

Lets ignore how I am getting the client to call server side functions
or syncing variables (node.js/socket.io or a library like nowjs can do
these). The first method that came to mind is:

playerPosition = { x : 0; y : 0 }

updatePosition = function (a,b)
{
playerPosition.x = a;
playerPosition.y = b;
}

if (this.vel.x!=0 || this.vel.y!=0)
{

updatePosition( this.pos.x, this pos.y );

this.parent(this);
return true;
}

So, I have a server-side associative array, "playerPosition", to store
the x,y coordinates. And a server-side "updatePosition" function to
change the player position.

On the client-side, I let MelonJS handle movement and collision. Then
in the update function of the object entity, call the server-side
function to update its position. The "playerPosition" array can then
be sent to other clients to draw the sprites on the appropriate
coordinates.

Question: If I let MelonJS handle movement and collision client-side,
I think players would be able to cheat?

[Orthonormal]

More thoughts about this:

Since we know the maximum number of pixel sprites can move per frame,
we can "validate" data sent to the updatePosition function by checking
if the coordinate change is bigger than the maximum allowed.

The only thing I feel iffy about is collision validation. MelonJS is
going to handle collision client side. But I am going to keep an array
of "forbidden" coordinates server-side to check if players are trying
to move into a collidable, and ignore the position update if he is.

Are there better ways to do it though?

[Enriko Riba]

This is never ever done in MMO's. Only one (the server) can control states.

You should try to think about clients as dummy views of the current server state.

Clients can request actions but not decide about them.

e.g.  

1. the player clicks somewhere on the map. 

2. the client requests a "move to" but is not changing the local player sprites position nor adding any other state 

3. the server receives the "move to", stores the players requests, calculates a movement vector and updates the players state

4. on each turn the server iterates all players, gets their "states" and calculates actions: for "moveto" state calc the movement depending on dt, check if already there and reset state to "stop", check if the movement is legal (could change between turns), calculate the new position, check if overrun (its further than requested) and correct, store new position in a "send to client" queue

6. check who is in the players zone of visibility and store a "player N moved to x,y" message in queues for all such clients

5. Once the turn is done send all messages to clients 

Thats a very oversimplified version! 

You can check in my Borg Server Project how this is handled, there are both diagrams and source (c#). Check the demo MoveManager in the \trunk\Source\Servers\WorldExtension\Movement (the SF source links can be found on the site).

Also it is common that the client tries to help the server by calculating as many things as possible on the client. e.g. 

1. player clicks somewhere

2. client calculates path finding, notifies the player that the destination is not reachable without ever sending a request to the server

...or if reachable splits the path into nav points and sends a "moveto" request only for the first nav point, once reached path finding is recalculated (maybe something has changed and blocking the way) etc.

3. still the server receives requests and calculates movements while checking for invalid conditions

This is a very huge topic and MMO's (if done right) are absolute the toughest beasts to program one can only imagine :-)

HTH

[Orthonormal]

Well, thankfully, I am not making an MMO. :p Just a puzzle/adventure
game with 2 players on one map. The title was just to attract their
attention lol.

The problem is, I am using MelonJS to make display the tile map,
handle the movement and check collision. All client-side. How do I
move MelonJS to server side?

Is it enough for MelonJS to process the movement and collision client-
side, and then for the server to somehow validate the final position?

On May 24, 6:29 pm, Enriko Riba <er...@titanium.hr> wrote:
> This is never ever done in MMO's. Only one (the server) can control states.
> You should try to think about clients as dummy views of the current server
> state.
> Clients can request actions but not decide about them.
> e.g.
> 1. the player clicks somewhere on the map.
> 2. the client requests a "move to" but is not changing the local player
> sprites position nor adding any other state
> 3. the server receives the "move to", stores the players requests,
> calculates a movement vector and updates the players state
> 4. on each turn the server iterates all players, gets their "states" and
> calculates actions: for "moveto" state calc the movement depending on dt,
> check if already there and reset state to "stop", check if the movement is
> legal (could change between turns), calculate the new position, check if
> overrun (its further than requested) and correct, store new position in a
> "send to client" queue
> 6. check who is in the players zone of visibility and store a "player N
> moved to x,y" message in queues for all such clients
> 5. Once the turn is done send all messages to clients
>
> Thats a very oversimplified version!

> You can check in my Borg Server Project <http://www.borgserver.net/> how

[Enriko Riba]

I am confused lol

So you have a server and two clients or just two clients acting as peers?

If you have a server let the server calc/check everything and the clients just display the map.

If you have only two peers the easiest way is to have one (first connected?) take the server role. 

Regarding moving melonJS server side not sure if thats possible. 

You might borrow some code from melonJS and do the collision/movement on the server.

[Orthonormal]

A node.js server with two clients.

There are two problems with doing everything server-side:

1) I will have to break apart MelonJS and do the collision/movement on
the server, and make the client-side MelonJS draw the resulting
animation. I think this will be extremely time consuming. Furthermore,
I have been reading about multiplayer networking and people seem to be
saying that game physics shouldn't be simulated server side because it
would put too much load on the server.

2) There might be lag issues. According to this article:
http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/.
If we simulate everything server-side, when the client presses the
movement key, he has to wait for the input to reach the server, and
then the server's response to return before he can move. If the ping
is 100-200ms or higher, the game might be unplayable.

I think some client-side simulation + server-side validated is
required to make this work.

[Enriko Riba]

Just a thought: 

 - doing movement calc is really trivial, so no big deal you do that yourself on server (x = x + speed * passed time)

- collision is a bit harder but for puzzle type games you dont need CCD (continuous detection). I figure a simple check if destination is free is enough

If you need something more you can always use a lib like box2d for collision

HTH

[Enriko Riba]

We where posting at same time :-)

You don't need to worry about that. 

Game physics is so much more than collision. A modern PC can barely handle its own physics in modern games so yes the server cant handle that. 

But what you need is just movement and very basic collision detection! 

Again I am not good with melonJS (or JavaScript), just starting with it but "porting" melon server side just to do this simple things you need is an overkill.

Regarding lag, for multiplayer FPS games 100-200ms lag would mean its unplayable. For a game like yours thats not noticeable.

BTW 200ms is already huge lag and if you experience something like that than there is something wrong with your Node/code!

[Orthonormal]

Haha. Thanks for the lengthy input. :)

When you say "x = x + speed * passed time", how do you keep track of
passed time? I am thinking of running "Date().getTime()" server-side
to "time stamp" each position update.

E.g. Player press "right" key. Input sent to server which updates
where the player is supposed to be 1 second into the future and time
stamp it. After 1 second, client checks with server to determine if it
is in the correct position.

I guess I am back at the method I suggested in the original post: Let
MelonJS handle movement and collision client-side, while we do simple
validation server-side to ensure the moves and collisions are valid.

200 ms lag -- I am just preparing for the worse case scenario. :p

[Enriko Riba]

there should only be just one state - the current, no future 1 sec state. But try it out and see if it works for you.

Just think what happens when two clients are near and both at same time do mutually exclusive actions, like stepping on same field -)

If melonJS does that for you client side for both clients thats perfectly legal, so both move and after one second....how would you resolve conflicts on server etc.?

[Orthonormal]

Enriko Riba:

Imagine you are simulating a bouncing ball server-side. The x,y,z
coordinates (state) of the ball on the server-side is always current.
When the x,y,z coordinate/state of the ball reaches the client, the
ball would have moved server-side. So, the client is always seeing
the
ball in the past.

Likewise, if the client fires a bullet at the ball's location, by the
time the input reaches the server, the ball's current location would
have changed.

So, having only the current set of coordinates server does not work.

> ...
>
> read more »

[Norb]

The point is how far is the past  ? if it's 10 ms do you really care ?
You don't need to implement any lib on server, you can just like me convert the TMX map as a javascript data and use it to check the state of the case or even use it in any A* algo.

The issue in your "x = x + speed * passed time" is that in MelonJS we use setvelocity(x, y) and i'm not sure of what the x and y represent in MelonJS pixel per second, pixel per frame , ... I will raise another post for that since I think is part of my issue on sync of my move

Out of al discussion on this subject I understood that the program should look like that :

Server :
request movement event
{
 define path
 inform everyone regarding this change
}

Independant Movement management Loop()
{
 for each player or mob
  {
   if (movementto be Done according to timing)
   {
    place the entity according to the next action in path queue
    inform all about the new position and the time of this change
    }
  }
}


Client:
On mouse or Keyb()
{
 ask for a movement
 and start to move according to the same algo of movement that is on server side
}

On message of position
{
if discrepancy on actual position and real position based on timing change
  change speed or position depending the gap
}

On paper that does not look too difficult but the check of timing it's quite an issue.

Am I wrong in this view of movement management ?

[Orthonormal]

Norb: I don't think its wise to assume players in an MMO would have 10
ms latency. :)

Average latency for a World of Warcraft player is 200-300 ms (http://
us.battle.net/wow/en/forum/topic/2301723213). They are all on high
speed broadband connections in that thread.

[Norb]

I did not speak about latency but about difference between the simulation server side and the reality on client

You received the position with a time and your client have to guess where it should be now, so yes you have always a difference but really not that big since it's only the diff of time calculation no ?

[Orthonormal]

Client (time = 0)
Server (time = 0)

Client asks server for player's position at time = 0.

Client (time = 300 ms)
Server (time = 300 ms)

If the latency is 300 ms, this is when the client receives the
player's position.

However, the position the client receives is for time = 0 (past). The
client is already at time = 300 ms (present).

In this simple framework, there is no way for the client to receive
its current position from the server. All positions it receives are
those in the past.

[Norb]

yes and it's actually where you add the time diff * distance per sec

300 ms later after the client order, the server received X, Y, Time so based on the velocity he can define where the client must me based on (Now - Time) * distance per sec

and the same for client : when he receive a message from the server he do the same Now - Time * dist per sec

[Norb]

To be fully right i'm not trying to do it exactly like that, the client send the message "moveTO" and don't move until the server send back the movment order  to all client like that you don't have the first latency issue.

But the server still send "Reminder" packet with the server position at a time 300 ms later (depending on latency) client receive the packet and do what needed to be back on the timing with the assumption of movement since the server have sent the packet.

[Orthonormal]

Ah, thanks for clarifying. I still see a problem with this approach:

Client clicks on a spot. If the latency is 350 ms, the client has to
wait 350 ms before he can move. The game might feel "laggy" and
unresponsive since movement won't be instant but has a 1/3 - 1/2
second lag time.

[Enriko Riba]

Why do you think a client would have 350 ms? You measured that or just guessing?

The truth is that if a client has 150ms lag he has far greater problems than playing your game (unless the lag is caused by your server code).

Some AAA titles try to predict server responses: after the player clicks, actions are executed immediately and once the server response arrives actions are synchronized. 

IMHO thats just not worth the huge efforts to make it play well.

[Orthonormal]

According to World of Warcraft players here - http://us.battle.net/wow/en/forum/topic/2301723213
, they have latencies of 300-350 ms and up to 450-500 ms average on
high speed broadband connections.

How do you know your clients will have < 150 ms average latency?

[Enriko Riba]

Experience only - developing MMO server frameworks and multiplayer games for over 20 years.

Back in old days where 99% ppl had modems +200ms latency was something to be expected, today 99% people have broadband connections. 

I can not comment on the particular WoW topic you mentioned but lets just say that lag depends on your network (ISP, hardware, configuration etc) and server side software/stress conditions.

The former is out of your control but ISP as far as I can tell you should never expect duration's in range 100ms and above.

Lag introduced by server overcrowding and badly written software is more common. It's your job to handle this.

IMHO you are over optimizing things you haven't even measured yet. Just implement something that works, once you have stuff up & running measure and optimize.

[Orthonormal]

100% of those WoW players have broadband connections. I have been
reading threads in which people playing different MMOs post their
latency. 100% of them uses broadband but pings of 200-450 ms are still
very common.

Oops, I forgot to update this thread. I got the multiplayer up a few
days ago. Using "client as dummy terminal viewing current game state
on server" framework. Which is why I am looking into client-side
prediction right now.

But you are right that client-side prediction is tricky to implement.
Because the input gets animated right away client-side, but not on
other clients (they don't know your input until the server informs
them).

I will be sticking to the dummy terminal model for now. Thanks for
your help Enriko. :)

[Norb]

I'm still on all that and figure out another issue :)

Creating a latency check on my client I figure out that my server and client had a latency of 2400 (outch !!) :) but I figure out that most of the latency was due to time not exactly at the same time

So in case you doing real time you also must think of a way of sync the time.

[Orthonormal]

Norb: Is your problem like this,

1) Client A sends input to server.
2) Server sends new position to all clients.
3) Sprite moves on client A and B upon receiving the new position. But
takes different time to complete for client A and B.

So the same move takes different time to carry out for both clients,
making them out of sync?

[Enriko Riba]

So the same move takes different time to carry out for both clients,
making them out of sync?

 

Guys, this is normal! I wouldn't worry about such things. Clients cant even notice that unless they sit next to each others.

You would need to worry only if the type of enforces the players to interact in realtime, like PvP where one can start an attack move and the other player can react on that with a defensive move. For such games the 'out of sync' is a real problem and they must 'slow down' all players to match the slowest and sync its state very often.

Again don't worry unless you encounter a problem. 

Once you have a playability problem measure to detect where the latency is coming from and optimize.