Quote:Original post by Andrew F Marcus
I'm sorry, but have you not in fact admitted server upload bandwidth is O(n^2) while peer upload/download bandwidth is O(n)? Do you realize how this means the same client bandwidth can allow for twice the number of players with P2P than with client-server?

...

Is it not the integrated bandwidth of O(n^2) in P2P still better than having just one client(server) use O(n^2) upload bandwidth? Does that not actually make P2P about two times more practical given the same bandwidth constraints?

I don't see how he is wrong here in the case that all clients have equal bandwidth and that if a client had to be a server.

Quote:Original post by Andrew F Marcus
Finally, having only two-player game, do you think it would be better if one player hosted the game for both, or would P2P type of direct link turn out as a better solution in this case?

seems to be about the same but writing p2p is harder to sync.

Quote:Original post by Jeonjr

Quote:Original post by Andrew F Marcus
Finally, having only two-player game, do you think it would be better if one player hosted the game for both, or would P2P type of direct link turn out as a better solution in this case?

seems to be about the same but writing p2p is harder to sync.

Another thing to consider (at least in the real world) is that companies sometimes decide it's less trouble to retrofit their ANCIENT single-player codebases so that they are multiplayer capable. This is almost impossible to do if you use peer-to-peer.

Quote:Original post by Nypyren
Another thing to consider (at least in the real world) is that companies sometimes decide it's less trouble to retrofit their ANCIENT single-player codebases so that they are multiplayer capable. This is almost impossible to do if you use peer-to-peer.

All it takes is to forward the input and for other computers to use that data instead of some AI algorithm. It's the equivalent of making two player hot-seat game or split screen multiplayer.

Quote:Original post by Jeonjr

Quote:Original post by Andrew F Marcus
I'm sorry, but have you not in fact admitted server upload bandwidth is O(n^2) while peer upload/download bandwidth is O(n)? Do you realize how this means the same client bandwidth can allow for twice the number of players with P2P than with client-server?

...

Is it not the integrated bandwidth of O(n^2) in P2P still better than having just one client(server) use O(n^2) upload bandwidth? Does that not actually make P2P about two times more practical given the same bandwidth constraints?

I don't see how he is wrong here in the case that all clients have equal bandwidth and that if a client had to be a server.

P2P bandwidth cost per peer is O(n)
C/S bandwidth cost per client-host is O(n^2)

For example, if upload limit for all the clients was 20units, then P2P could support up to 20 players, while S/C approach could not support more than 4 players. Other mistake was him thinking how collective bandwidth usage is more with P2P than C/S, which is obviously wrong since server sends data to all about all and that makes it very wasteful and superfluous way to communicate information, making a pig out of one of the clients, hogging more bandwidth than all the peers together.

Hope that explains.

Quote:Original post by Jeonjr

Quote:Original post by Andrew F Marcus
Finally, having only two-player game, do you think it would be better if one player hosted the game for both, or would P2P type of direct link turn out as a better solution in this case?

seems to be about the same but writing p2p is harder to sync.

It is easy to write P2P programs and very much easier to sync them. Ask our friend "Stickman": "The multiplayer part is P2P, I've done my best on reducing latency and bandwidth, using various packing schemes and priorities. It works nicely with 30 people online, using only 5kBps upload."

http://www.gamedev.net/community/forums/topic.asp?topic_id=509402&whichpage=1&#3322376

Quote:Original post by hplus0603

Quote:I'm sorry, but have you not in fact admitted server upload bandwidth is O(n^2) while peer upload/download bandwidth is O(n)? Do you realize how this means the same client bandwidth can allow for twice the number of players with P2P than with client-server?

If there is no per-packet overhead, that statement would not be true, because squared and times-two are different functions.
If there is per-packet overhead, that statement would not be true, because packet overhead matters.

Packet overhead hardly makes any difference. Besides, it can always be argued P2P needs only to pass player input between peers. If my statement is wrong than it's because it's understatement, the difference is not "twice", but it rather grows exponentially with the number of players, in favor of P2P.

Quote:
Do you think that the people who wrote Counter-Strike: Source, or Quake III: Arena, or Unreal Tournament, are idiots? Do you think they do not carefully test a number of different approaches before they settle on what works best? Why do you think they are not using P2P topologies?

Yes, if there is no better explanation for not using P2P. Yes, they likely did not think, test, nor care to consider other approaches, most of them did not even write their engines, they copied what others were doing. Everyone is playing it safe, everyone is using one and the same code. Besides, many of them may falsely believe P2P has bandwidth issues. How do you explain it? It's not bandwidth, it's not latency, it's not security. What is it then?

Quote:
Anyway, the proof is simple: Just write a game that is P2P and works much better than current games based on Source, Unreal, Quake etc engines. There are lots of companies out there in the games engine and middleware business, and none of them end up using P2P solutions. If you can write a much better game, or simply license a much better solution, you'll make lots of money!

I wrote some even more incredible stuff, unfortunately no one cares and I am even giving it all away for free. Industry is very inert now days, there is so much money involved that it acts as an obstacle to inventiveness and progress, making all the games play and look alike.

Do you want to play Stickman? "30 people online, using only 5kBps upload"
http://www.gamedev.net/community/forums/topic.asp?topic_id=509402&whichpage=1

Quote:
I'll leave you with another question: We've all heard about MAG (Massive Actiongame), right? Do you think they use client/server, or peer-to-peer, for their 256-player matches? And why?

I don't know. They are being silly?

Quote:Original post by hplus0603
If there is no per-packet overhead, that statement would not be true, because squared and times-two are different functions.

I do believe the server upload bandwidth is O(n^2) since the server needs to send (n-1) sized packets to n players during worst case scenario.

Quote:Original post by hplus0603
Do you think that the people who wrote Counter-Strike: Source, or Quake III: Arena, or Unreal Tournament, are idiots? Do you think they do not carefully test a number of different approaches before they settle on what works best? Why do you think they are not using P2P topologies?

I think they don't use P2P because its not very secure, which leads to a lot of cheating/hacking.

edit:

Quote:Original post by hplus0603
I'll leave you with another question: We've all heard about MAG (Massive Actiongame) [www.gamespot.com], right? Do you think they use client/server, or peer-to-peer, for their 256-player matches? And why?

P2P only works up to the lowest uploading speed of the client, which we know as increasing at the rate of O(n).
Where as Client Server requires O(1) upload for each client.
edit2: also the packet header is going to limit P2P even more as it requires each 256 players to send 255 packets each.
Client Server only needs 256 + 256 packets


sidenote: the link has an extra ' at the end (or is missing one at the start)

Quote:Original post by Andrew F Marcus
It is easy to write P2P programs and very much easier to sync them. Ask our friend "Stickman": "The multiplayer part is P2P, I've done my best on reducing latency and bandwidth, using various packing schemes and priorities. It works nicely with 30 people online, using only 5kBps upload."

http://www.gamedev.net/community/forums/topic.asp?topic_id=509402&whichpage=1

I don't see how it's "easy" to write a P2P program.

[Edited by - Jeonjr on September 5, 2009 2:58:13 AM]

Quote:Original post by Jeonjr
P2P only works up to the lowest uploading speed of the client, which we know as increasing at the rate of O(n).
Where as Client Server requires O(1) upload for each client.

Yes, but advantage only applies if some company is hosting a dedicated server, paying for all the bandwidth. Still, if the game is not super successful, servers will go offline rather quickly, leaving O(n^2) problem to you.

Quote:Original post by Jeonjr
edit2: also the packet header is going to limit P2P even more as it requires each 256 players to send 255 packets each.
Client Server only needs 256 + 256 packets

Peer upload: 255 packets
Server upload: 256*256 = 65536 packets

Quote:Original post by Jeonjr
I don't see how it's "easy" to write a P2P program.

I don't know what to tell you. You use exactly the same network code as in client-server approach, except that you run a server on each client, so to speak. Is there anything in particular you're worried about?

http://stickman.hu/
http://stickman.hu/page/?o=download&l=eng

Ok, this is absolutely fantastic! Stickman works wonderfully!!

There is quite a few people playing there right now, most of them seem to be half the way across the globe, in Hungary, so latency was probably about 400-500ms, but it played beautify nevertheless. There are clans, top players, high-scores, forums, all the stuff... this is really a quality game with many happy users to vouch for it.


It took me about 2min to play the game from the moment I clicked on download link. There is no need for installation or any kind of setup what so ever, you just download 10mb exe and run it. Simple as that.

Just like author says - "The portable version doesnt need to be installed, it just runs". Indeed, it just runs! Ha, great stuff. Click "connect" and there you are... running, jumping, driving vehicle, shooting Stickman half the way across the world. It's smooth, it's fun, it's great... bravo!




Stickman on P2P:
- "Interestingly, this is a P2P online game, and the server I talked about is a simple NAT introducer. It was a great challenge to reduce bandwidth to the minimum. But I think I got it right, because it only uses 5KBps upload with 50 players, so It could even work with Dialup!"

-"I use byte packing and some priority thing (like, I send packets more often to players, who are closer to me etc.), so there's less lag than you would think, since if you're shooting with someone, you send most of your packets to each other."

-"1000 players have played with it since i started to develop it. Not Massive, eh?"




I didn't think stick figures can get any better than Xiao-Xiao, but you did it. Stickman, you rule.

Quote:Original post by Andrew F Marcus
Peer upload: 255 packets
Server upload: 256*256 = 65536 packets

Maximum size of a packet is 1500 bytes due to MTU, minimum is 576. Depending on payload, server will be able to pack multiple payloads into same packet.

(1500-28)/255 = 5.7. This means, if payload is less than 6 bytes (quite possible), then server will send each client entire state of 255 players in single packet:

[UDP Header][C1][C2][C3]....[C254]

As such, server upload is 255 packets.

With 5 bytes of payload, the overhead of P2P is: 84%
With 5 bytes of payload, the overhead of server upload is: 2%

For every another 5 bytes of payload per client, server would need to send an extra packet.

This is where the difference comes from.

Quote:
Maximum size of a packet is 1500 bytes due to MTU, minimum is 576.

What do you mean - minimum?

Quote:
(1500-28)/255 = 5.7. This means, if payload is less than 6 bytes (quite possible), then server will send each client entire state of 255 players in single packet:

[UDP Header][C1][C2][C3]....[C254]

As such, server upload is 255 packets.

Ok, fair enough, quite a few bytes saved there. But packet is not a measure of size anymore and we need to plug in some real bytes, like so...

Peer upload cost: 254 *(28+5)bytes = 8,382 bytes
Server upload cost: 255 *1500bytes = 382,500 bytes



The difference remains huge.