# 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 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 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 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 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 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 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]

##### 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.

## 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