Massive multiplayer, what should i use?

Lol I'm just as confused as you are. I can't quite relate the situation with the 1,4,10 room thing.

I have no idea what that is about either - lol

[quote:3upa4pqv]peers can only handle 15 other peers connected because host collects info from peers and broadcasts to peers and peers broadcast to peers via host...

I believe this is inaccurate ; we've run the numbers already - but while bandwidth requirement is exponential on the host/server, quadratic O(n^2), it's only linear on the peers O(n).

Since peers don't connect to other peers directly and only send/receive data to/via the host, peers only send data about themselves and only receive 1 update about other peers.

Session with N peers - n bytes of data per peer to store their status. Size of the data to describe the entire "world" = N*n bytes

Peer : sends n bytes to the host ; receives N*n bytes of world update

Host : sends N*N*n bytes (broadcast the world update to all the peers) ; receives N*n bytes (peer updates)

If peer download bandwidth is the limiting factor, I think there are bigger issues to sort at the architecture level than room sizes !

Though we still don't know what the "1, 4, 10" room thing is all about

"peers can only handle 15 other peers connected because host collects info from peers and broadcasts to peers and peers broadcast to peers via host..."

I believe this is inaccurate ; we've run the numbers already - but while bandwidth requirements is exponential on the host/server, quadratic O(n^2), it's only linear on the peers O(n).

Since peers don't connect to other peers directly and only send/receive data to/via the host, peers only send data about themselves and only receive 1 update about other peers.

Session with N peers - n bytes of data per peer to store their status. Size of the data to describe the entire "world" = N*n bytes

Peer : sends n bytes to the host ; receives N*n bytes of world update

Host : sends N*N*n bytes (broadcast the world update to all the peers) ; receives N*n bytes (peer updates)

If peer download bandwidth is the limitating factor, I think there are bigger issues to sort at the architecture level than room sizes !

I was trying to highlight the upload speed, not the download speed. And even if it is just 1 update to the host at 30 times a second. You will have issues on a 1mb/s line which can only upload at 100kb/s and 15 peers would put it about 105kb/s upload which is 5bytes more than the line can handle

Of course the numbers are not set in stone. And the upload size is dependent on so many things. But could we agree that a single update could be at least 3.5kb and if it is by default sent 30times a second... then can we agree we are going to have a upload bottleneck on a 1mb/s line???

I believe this is accurate... those are the numbers right there.... Unless I am missing something? Which is very possible

[quote:1bnn3bqv]could we agree that a single update could be at least 3.5kb and if it is by default sent 30times a second... then can we agree we are going to have a upload bottleneck on a 1mb/s line?

Absolutely, I will agree that 3-4kbytes updates, 30 times a second, will saturate a home-user 1mbit line !

Though 3-4kbytes is quite a lot to describe the actions, status and updates of one single peer. That's ~2000 int16 or float16, and since the peer won't be running any critical gameplay logic for security reasons, there's usually not much more to send than just player input and actions, and a few miscellaneous useful bits of data.

There are already lots of perfectly viable multiplayer games working with this limitation, including massively multiplayer ones.

What I don't understand is why you consider the number of peers a relevant factor when analysing the upload bandwidth on the peer side ; it's very possible I got your point wrong, in all the confusion about room, sizes, sessions, etc.

[quote:3hlt05ml]could we agree that a single update could be at least 3.5kb and if it is by default sent 30times a second... then can we agree we are going to have a upload bottleneck on a 1mb/s line?

Absolutely, I will agree that 3-4kbytes updates, 30 times a second, will saturate a home-user 1mbit line !

Though 3-4kbytes is quite a lot to describe the actions, status and updates of one single peer. That's ~2000 int16 or float16, and since the peer won't be running any critical gameplay logic for security reasons, there's usually not much more to send than just player input and actions, and a few miscellaneous useful bits of data.

There are already lots of perfectly viable multiplayer games working with this limitation, including massively multiplayer ones.

What I don't understand is why you consider the number of peers a relevant factor when analysing the upload bandwidth on the peer side ; it's very possible I got your point wrong, in all the confusion about room, sizes, sessions, etc.

Agreed, and the number is just a number. He was talking 1,4,10 I still have no idea what that is -lol

1 game that is divided by location. Players in the north are connected via host1 and players in the south via host2 etc...

I was just putting a number. It could be 30, 50 depending on number in the area itself.

I think Duckfaceninja said somewhere he managed to get users to switch hosts with little or no issues. So dividing a large map (for ships, I think the OP was talking about) might be the way to go.

Agree 3.5kb is pretty big, but again it depends on the game...

I've been experimenting with a slightly different take on things, and I have had files as big is 35kb+ go out... obviously not every tick but it all depends on so many things.

webtrc isn't limited to multiplayer only

It might be packaged as such in C2, but it is capable of so much more...

I'm am thrilled everyone is wrestling this beast.... will shortcut dev time considerably.

I think Duckfaceninja said somewhere he managed to get users to switch hosts with little or no issues.

Yeah I did succeed doing that previously, with almost similar technique with the capx in my bug report previously. The only downside is, there's a noticable "waiting" it can be like 0.5s or can go until 3s (rather busy with torrent and all), depends on your internet connection and the "waiting" scene should be replaced with loading screen because object and environment creation looks too undesirable. Similar to WOW or any other MMORPG loading screen, I bet the loading screen purpose is to hide the object and environment creation flickery thingy.

So creating loading screen is a norm even for a big MMORPG, I think this is how it is going to be for us too.

Wait, you guys go on something out of what i was thinking

I never talked about hosting a 100+ player server at home, it'll be an option for people who wants to run big servers on dedicated servers with enough bandwidth ect. I just want the people who wants to only player with few friend to run a server for few players, this is was i was talking about the rooms of 2,4,10 ect..