p2p is basically the industry standard for RTS games. don't be misinformed. the problems Demigod has experienced were due to poor scalability on a particular piece of code (the NAT facilitator, if you care about specifics). it can be argued (and has been, succesfully, i might add) that Demigod should have had a BETTER p2p system but it is really foolish to suggest that there's anything inherently unusual or bad about a p2p system in its own right.
Frogboy seems a nice guy and is obviously dedicated to working things out, but you are just regurgitating what you read in his posts and acting like an authority on the subject based on loose reasoning.
P2P is not an industry standard. Any software engineer worth his salt will tell you first and foremost that the solution you use for a problem is dependant on your specific needs. If you try to shoehorn your needs into a specific design, you wind up with a mess. This here is a mess.
There are some really good reasons to consider using P2P. However, I would have to disagree with the primary reason Frogboy has given - that being Demigod requires accuracy and that P2P is the way to go for attaining it. From obersvation, the P2P system has been used in place of, say, client side prediction. Client side prediction is a nasty subject when dealing with network issues: a fairly golden rule is that you can never trust what the client says, which is why even games with client side prediction check against the server at some point (assuming a reasonably well made game).
Probably a big concern with Demigod using a client/server set up is that it would seem to put a lot of control with whomever hosts. This is generally typical, but the sort of game play Demigod has should result in neutrality - that is, no player should be advantaged. If one person is the server, then that person could theoretically tamper. As I said, you cannot trust the client, and if the server and client is one in the same, there can be no trust.
Some notable things we see with this P2P system: many more connections need to be maintained in a game. A server/client scenario would see 9 connections in a 5vs5 player game: 1 for each client connected to the server. These connections as mentioned here could be considered the typical two-way streets - each connection lets the client and server communicate with each other. Hence, because one person is the server, only the nine clients need connections.
For a P2P system, each person connects to all other people. For a 5vs5 player game, each person is connected to 9 other people. This results in 45 connections being made.
P2P system basically represents a complete graph; the number of edges between nodes (in our case, connections between people) is given by (N * (N+1)) / 2 where N is the number of people in this case. A 6 person game is 15 connections.
My point here is that the number of connections grows greatly with the more people there are. In a 5vs5 each person has 9 connections. That by itself isn't much, but 45 connections for the entire game? That is not insignificant. 45 connections established where any one of them can and will cause problems for the entire game. Packet loss to an ISP data center isn't much worry when you're dealing with 9 routes across the globe, such as with a server/client model. 45 routes, however, should worry anybody that claims they implemented the system to maintain accuracy. This system is begging to have dropped packets everywhere.
And then we have the byproduct issues, most notably stemming from simspeed. Or rather, if a person's computer is too slow, it will be slow in responding to packet updates from the other peers. By design, this means each person's view will not update until the slow person accepts and responds to the updates. Hence, by design, we get the priveldge of knowing very nearly what it is like to play on a low end system regardless of our own system's capability.
Hind sight might be 20/20, or maybe Frogboy's claims are correct and that the NAT facilitator is the sole blame. Given that the problems go beyond simply establishing the connections, however, it should be obvious that there is more to worry about.
Now, I mentioned that we cannot trust a server that is also a client. I maintain this. Demigod clearly has handling in place to verify the data that it recieves from each of its peers. My change would be this: a server/client model based on top of the P2P system.
One person, the host, is the server. Each person will connect only to the host. The host will push the updates about the whole game to each client. The P2P part of the system that verifies the data will still be in place, however. So each client will verify the state of the data it is given from the server; likewise the server will verify data it is sent. This still makes it hard to cheat since the clients still have a say about what is valid, but it helps decrease the other problems - not as many network connections need to be established and potentially broken. Each client in a game need only be able to connect to one person in order for the game to play. These two issues alone would help tremendously.
This setup, essentially, could give the best of both worlds.
This is also theorycraft - I have never used Raknet, and so I cannot claim to know if such a change would be trivial or complicated. What I do know is that it would have benefits. What I do know is that the network issues need to be solved. What I do know is that no developer wants to scrap all of the work they put in - and this would allow them to keep a large chunk of their work.
Demigod Forums
Stardock Forums
