Hello there,

I'm programming a 2d mmorpg using c++ and winsock ( TCP ONLY).
My problem is: my client can't receive many messages.
these messages look like:
P,5,32.4455,2.77555
per client.

And this message is sent every 60 ms. which is 17 times per second.
So the maximum number of players per zone is 50.
So if there are 50 players : 50 x 17 = 850
Which means my client has to receive 850 of these messages per second
And it gets worse: there will be like 50 monsters too, so it's going to be 100x17.
Which is too much. What must I do?

Don't !
Send updates when they occur, monsters are prone to idle a lot, there is no need to send updates if an entity rarely does anything.

Disclaimer: I've never written an online game before, much less a MMO. I have done some conceptual work with Raknet and Winsock and done non-game-related online applications with sockets, however.

First, I don't think you should be making an MMORPG. You should try an online game before even attempting to do an MMORPG.

With that out of the way, it would seem to me you need to do two things:

1) Only send updates when something actually changes

AND

2) Only send updates when you absolutely have to

You should probably be interpolating positions on the client. IE, guessing positions when possible.

Thank you for the quick responses. I'll see what I can do.

Alright, It only sends messages when something is actually happening. When a player doesn't move, no position messages are sent. But I did some stresstesting with 50 MOVING clients, and there was some noticable latency, is this going to be a real problem?

How much latency are you experiencing and in what context is the latency?

As others have indicated, be sure to only be sending updates when changes happen, but also be sure you're sending updates for things that are within the visibility mask of the client. For example, if your zone is 1000 yards wide, you obviously can't see that far into the distance or shouldn't be concerned about dynamic content that far away. By limiting the data update based on a range of the current player, you eliminate the need to distribute updates on such a large scale, even if you're using zones. In World of Warcraft for example, each Zone or WMO such as Ogrimmar or Stormwind are broken into subgrids where only information about players within that subgrid are distributed. This keeps network bandwidth considerably lower.

Your monsters could be designed to pick a destination of where to move using AI and then you could simply transmit the destination point for the simulation, only adjusting and sending an update when direction changes or destination is reached. You could use a similar approach for actual players where you transmit the desired movement direction and then on an much lower frame interval, you synchronize positions and adjust for any inaccuracies. This way you send one message when movement starts, a message every sync point, and then a message when movement direction changes or ends. This allows for smooth movement and you can build in some "fluff" so that if there is a small difference of yards you ignore or consider the sync successful and don't realign the player's position to avoid rubber banding. Later on you could apply a client algorithm where as you get these differences, you adjust the movement of the character accordingly over the next several frames so there isn't that much gittering. Under a FPS of course, position must be far more accurate than an RPG.

HTH

How much latency are you experiencing and in what context is the latency?

As others have indicated, be sure to only be sending updates when changes happen, but also be sure you're sending updates for things that are within the visibility mask of the client. For example, if your zone is 1000 yards wide, you obviously can't see that far into the distance or shouldn't be concerned about dynamic content that far away. By limiting the data update based on a range of the current player, you eliminate the need to distribute updates on such a large scale, even if you're using zones. In World of Warcraft for example, each Zone or WMO such as Ogrimmar or Stormwind are broken into subgrids where only information about players within that subgrid are distributed. This keeps network bandwidth considerably lower.

Your monsters could be designed to pick a destination of where to move using AI and then you could simply transmit the destination point for the simulation, only adjusting and sending an update when direction changes or destination is reached. You could use a similar approach for actual players where you transmit the desired movement direction and then on an much lower frame interval, you synchronize positions and adjust for any inaccuracies. This way you send one message when movement starts, a message every sync point, and then a message when movement direction changes or ends. This allows for smooth movement and you can build in some "fluff" so that if there is a small difference of yards you ignore or consider the sync successful and don't realign the player's position to avoid rubber banding. Later on you could apply a client algorithm where as you get these differences, you adjust the movement of the character accordingly over the next several frames so there isn't that much gittering. Under a FPS of course, position must be far more accurate than an RPG.

HTH

Thank you for this very helpful post!