Jump to content
  • Advertisement
Sign in to follow this  

MMORPG WINSOCK

This topic is 2344 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement

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?


Group the messages together and send them all at once (Thus you'll still send 17 messages per second to each client), disable nagles algorithm to prevent the protocol implementation from buffering your data for you. (It will add quite alot of latency when you are sending such small data amounts)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!