Fimbul, I beg to differ. I?m not a game developer, I work with servers and datacenters for a living so I actually know when I tell you that most people want servers for their games and p2p has all type of troubles for data connections unless your requirement is just for 2 persons and packets are low on bandwidth. also work with servers, datacenters and clusters, and I can tell you it's looking more decentralized every day, because monolithic servers simply cannot scale.
Not only I see people asking this all day but like I explained before, even Microsoft switched Skype off from p2p. Most people using Voip which is going to be similar to game requirements, also use a middle server, usually a voip provider, and do not usually call from machine to machine.icrosoft moved skype to the cloud. The p2p remains, but now the peers are microsoft's own servers. Even if Microsoft ends up completely centralizing the whole Skype infrastructure, so what? As if Microsoft were the king of good decisions - see Internet Explorer.
On the Google presentation they even explain for WebRTC, you will need a server to handle multiple connections because its just the nature of it once its scales.ou need a server for it to work at all, not just for scaling it.
This may work wonderful for someone playing chess with another party, but not if you want to connect 100 players together playing the same game at the same time. The network will start to drag the slowest link of all.hat? If that were the case, bittorrent would only download at the speed of the slowest peer, and that is clearly not the case.
Its not correct than p2p is the shortest path either because that is not how networks are deployed worldwide.
In this small example case if your target is Latin America or have players there you would have a server in the US and it will be faster for everyone vs players connecting with each other.layer A in Brazil connects to Player B also in Brazil via link C in the US (p2p-model)
Player A in Brazil connects to server C in the US, which then transmits data to player B in Brazil (server model)
How is that any faster? Worst case scenario, they are exactly the same. In all other cases, the p2p model is faster.
Besides, like I said three times before, you can mix the models:
Player A in Brazil connects to Player B also in Brazil
Player A in Brazil connects to Server C in the US
Player A sends data to both B and C
Server C sends player A's data to player B
Player B receives the data from player A and, much later, the same data again from server C
In player B's perspective, data received directly from player A isn't trusted implicitly, but is used for interpolation. Data received from server C is authoritative, and is used to determine serious state changes, such as kills, health, etc., and also as a backup should the direct link from A to B fail.
Even if they are local players (same city, state, etc) you will not achieve high bandwidth outputs with p2p, it will work for a couple of players tops because each user needs to stream their connection up to the network, and even in countries with high Internet speeds this is usually very low. Example, last time I was in Germany on a residential ISP connection download speeds for a 25 MBPS connection, only had tops 1 Mbps upload, now try connecting all your players via 1 Mbps. For a small game that only sends positions this will work fine, but it will cause problems as players increase. Now most games only send a few details, like position, score, etc, but still if latency sucks in one user it will drag the whole game down, this means all players.Mbps uplink is more than enough: you could send 10kb packets every 10ms (that is, 100 frames per second) - 10Kb of UTF8 text allows for between 10240 and 40960 characters. Those are insanely high values for a packet, and you could probably get away with something like 128 kbps.
On real live games this means suffering connection drops, slow games, etc.
Is that all worth?
In particular because setting up a server is so cheap and you will need to host scores, registrations, and probably a website anyway for your game.
I?m not against P2P but if P2P worked for most things we would not have datacenters and servers today. P2P like its name says is peer to peer, and is usually designed for person to person. I imagine someone developing a game will need more than just a couple of players, that is the idea of multi-player. If you are creating a big multiple player game there is no way P2P will ever work.
If you only need to test it with a coupe of people or are playing with friends, then this will work just fine.2P is not exclusively person to person, though, it's peer to peer. Must I repeat myself again? A server is just a special type of peer!
If you want to argue with me that you can't possibly program a server in construct 2 to handle thousands of players, then yes I agree, but no one said you had to do that. Fire up node.js, it can talk to c2 just fine.
But for open code like HTML5 games usually are, a server side is the only way to protect the game, just like no one would allow users to view your asp or php code that runs on the website. The server side option is the only realistic option that can potentially avoid some of this cheating problems.id you read what I posted? It makes no difference whether the game is made in HTML5 or C++, and it makes no difference if the game is hosted on a server or on a machine in the client, the architecture is all that matters. If starcraft 2 needed server-side security to prevent cheating, it wouldn't have become the e-sport it is today. If bitcoin needed a server to provide security, it wouldn't be worth over $800 each.
Besides, no one said you can't have a server.