Sign in to follow this  
Choisir

Noob Bandwidth question

Recommended Posts

Choisir    104
Hello there o/

I am once again here with a super noob question. I consider a 3rd person isometric shooter (like this [url="http://www.youtube.com/watch?v=YUKSg0UYA6c"]http://www.youtube.com/watch?v=YUKSg0UYA6c[/url] ) but browser based.

As it will be multiplayer so no zombies but people (team) shooting each other, I wonder logical number of players in a room. I know data flow increases exponentially but still tend to believe (hope) up to 100 people in a relatively large map should be possible.

What is your estimation (based on experience if possible :) ) for maximum number of players in a room for an isometric game with simple graphics (in fact theoretically 8 sprite for every player and bullets around) before it becomes out of sync?

Thank you in advance.

Share this post


Link to post
Share on other sites
ApochPiQ    23004
That's going to depend almost entirely on your implementation architecture. A naive broadcast-to-everyone model is going to break down fairly fast - say, maybe 16 players or so - whereas more clever approaches can easily scale up to a few hundred. Of course your choice of technologies is critical as well; say, a PHP-backed AJAX system will crap out at 10-15 people, but obviously custom tailored techniques (such as found in MMOs) can handle hundreds of people.

Share this post


Link to post
Share on other sites
hplus0603    11347
[quote name='Choisir' timestamp='1310925958' post='4836433']
I know data flow increases exponentially but still tend to believe (hope) up to 100 people in a relatively large map should be possible.
[/quote]

First: The data rate increases quadratically, not exponentially. Those are two totally different growth classes, and recognizing the difference is an important skill for any programmer!

In brief: For every player, you need to send them updates about roughly every player. This leads to n-squared traffic out of the server. N-squared is quadratic (polynomial) not exponential.

Second: Just do the math. Suppose you need to send 20 bytes per player per tick, and you use a network tick rate of 10 ticks per second. On the server, that means 200 bytes per player per second per player. So, with eight players, that's roughly 8*8*200 == 13 kilobytes per second out of the server. For twenty players, that's roughly 20*20*200 == 80 kilobytes per second out of the server.

Similarly, on the client, you receive 200 bytes per second per player, which means that, for 20 players, you get 4 kilobytes a second, which any client should be able to deal with.

Regarding the graphics, if it's just isometric sprites, then any graphics card today should be able to do a terrain plus a hundred sprites at reasonable frame rates -- unless every sprite covers all of the screen, or you screw up the rendering in some other way, which is totally possible :-)

Share this post


Link to post
Share on other sites
Choisir    104
[quote name='ApochPiQ' timestamp='1310926711' post='4836435']
That's going to depend almost entirely on your implementation architecture. A naive broadcast-to-everyone model is going to break down fairly fast - say, maybe 16 players or so - whereas more clever approaches can easily scale up to a few hundred. Of course your choice of technologies is critical as well; say, a PHP-backed AJAX system will crap out at 10-15 people, but obviously custom tailored techniques (such as found in MMOs) can handle hundreds of people.
[/quote]

Ideal system will probably be based on node.js - socket.io whenever possible, php+ajax will be depreciated at best. There are some ideas to improve experience like selective-broadcast, smaller viewport or a bit slower gameplay ie lesser ticks (this is not fps :) )


[quote name='hplus0603' timestamp='1310928190' post='4836442']
[quote name='Choisir' timestamp='1310925958' post='4836433']
I know data flow increases exponentially but still tend to believe (hope) up to 100 people in a relatively large map should be possible.
[/quote]

First: The data rate increases quadratically, not exponentially. Those are two totally different growth classes, and recognizing the difference is an important skill for any programmer!

In brief: For every player, you need to send them updates about roughly every player. This leads to n-squared traffic out of the server. N-squared is quadratic (polynomial) not exponential.

Second: Just do the math. Suppose you need to send 20 bytes per player per tick, and you use a network tick rate of 10 ticks per second. On the server, that means 200 bytes per player per second per player. So, with eight players, that's roughly 8*8*200 == 13 kilobytes per second out of the server. For twenty players, that's roughly 20*20*200 == 80 kilobytes per second out of the server.

Similarly, on the client, you receive 200 bytes per second per player, which means that, for 20 players, you get 4 kilobytes a second, which any client should be able to deal with.

Regarding the graphics, if it's just isometric sprites, then any graphics card today should be able to do a terrain plus a hundred sprites at reasonable frame rates -- unless every sprite covers all of the screen, or you screw up the rendering in some other way, which is totally possible :-)
[/quote]

First, thanks for the math and quadratic / exponential difference. :) I am so noob at these and my math days are long past. :/

For graphics, in fact I didn't mention system requirements (even including iOS / Android) but tried to give a brief idea about amount of required data. Thanks to the formula you provided, I can calculate synthetic requirement but I'll be pleased if you also include TCP header (I had read it may take up to 70% of size in small messages) , players with high latency or such.

So I am asking your opinion, is it practically possible? An average map let's say 200x200 to 500x500 and 100 players.

Share this post


Link to post
Share on other sites
hplus0603    11347
[quote name='Choisir' timestamp='1310933785' post='4836472']
So I am asking your opinion, is it practically possible? An average map let's say 200x200 to 500x500 and 100 players.
[/quote]


I imagine you download the map once, and then everybody just has it, so it takes no networking.

The TCP/IP header is at least 44 bytes -- if you send 100 players times 20 bytes, that's 2,000 bytes, and will probably be split in two TCP segments, for a total of 88 bytes of overhead. 2,000 bytes to 100 players, 10 times a second, is 2 megabytes a second from the server, though. That requires roughly a 20 megabit uplink to the internet.

Share this post


Link to post
Share on other sites
goku21060    101
[quote name='hplus0603' timestamp='1310945097' post='4836537']
[quote name='Choisir' timestamp='1310933785' post='4836472']
So I am asking your opinion, is it practically possible? An average map let's say 200x200 to 500x500 and 100 players.
[/quote]


I imagine you download the map once, and then everybody just has it, so it takes no networking.

The TCP/IP header is at least 44 bytes -- if you send 100 players times 20 bytes, that's 2,000 bytes, and will probably be split in two TCP segments, for a total of 88 bytes of overhead. 2,000 bytes to 100 players, 10 times a second, is 2 megabytes a second from the server, though. That requires roughly a 20 megabit uplink to the internet.
[/quote]


Just wondering how did you get the 20 megabit upload speed for internet. which it be better to have 5mbsp ( cost wise lol). Also I am curious as to know how you where able to perdict how many bytes wwould be sent to each player?

Share this post


Link to post
Share on other sites
goku21060    101
Hidden
[quote name='goku21060' timestamp='1310974388' post='4836684']
[quote name='hplus0603' timestamp='1310945097' post='4836537']
[quote name='Choisir' timestamp='1310933785' post='4836472']
So I am asking your opinion, is it practically possible? An average map let's say 200x200 to 500x500 and 100 players.
[/quote]


I imagine you download the map once, and then everybody just has it, so it takes no networking.

The TCP/IP header is at least 44 bytes -- if you send 100 players times 20 bytes, that's 2,000 bytes, and will probably be split in two TCP segments, for a total of 88 bytes of overhead. 2,000 bytes to 100 players, 10 times a second, is 2 megabytes a second from the server, though. That requires roughly a 20 megabit uplink to the internet.
[/quote]


Just wondering how did you get the 20 megabit upload speed for internet. which it be better to have 5mbsp ( cost wise lol). Also I am curious as to know how you where able to perdict how many bytes wwould be sent to each player?
[/quote]

Share this post


Link to post
hplus0603    11347
[quote name='goku21060' timestamp='1310974388' post='4836684']
Just wondering how did you get the 20 megabit upload speed for internet. which it be better to have 5mbsp ( cost wise lol). Also I am curious as to know how you where able to perdict how many bytes wwould be sent to each player?
[/quote]

One megabyte per second is eight megabits per second of payload. However, with overhead and some small margin for variations, a rule of thumb is "1 megabyte == 10 megabit." So, for two megabytes per second, you need 20 megabits per second of uplink.

I estimate player data at 20 bytes per packet, 10 packets per second, per player. This estimate just comes from "typical" usage scenarios I've seen before -- you'll have to actually come up with a specific implementation and measure it in more detail yourself if you want better numbers. Note that, for a naive implementation, it's easy to send kilobytes per user per second; especially if you use text-based formats or built-in serialization support in languages like Java or C#. 20 bytes per player per packet assumes you do reasonably efficient packet encoding yourself.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this