Quote:Original post by Antheus
This thread is a complete mess.
+1
Whetever little actual information is present in this thread has been ruined by the zealous nature of the "discussion" (if you can call "im right an you're wrong, so there" a discussion).
They're both appropriate in different situations. If you read descriptions from popular engines (e.g. the Half-life network overview) then they explain their decisions. Abaraba obviously hasn't read up on how exactly popular C/S is implemented in Source/Unreal/Quake, because he's pointing out flaws like "
and even worse, they may itself be the source of another set of visual artifacts since they can easily mismatch with server’s next update" which are "solved" by the previously mentioned models (and, like most info in this thread, the same solutions could be applied to C/S or P2P...)
Furthermore, many networking models that are independent or the choice of C/S or P2P have been muddled in with either of these choices during the thread.
For example, the lock-step technique where the inputs of the simulation are shared and agreed upon in advance (the actual state is not shared) can be implemented in either C/S or P2P...
These models may be more useful to one system than the other though.
For example, lock-step fits in well with P2P as there is very little data shared between clients, however if for whatever reason the lock-step model will not work for your game, then that may sway your decision as to whether S/C or P2P is feasible or not.
E.g. if your game *requires* a huge amount of state to be broadcast, then limited client bandwidth might mean that your game simply doesn't work without a dedicated high bandwidth host.
Of course you can try do design games without steep requirements, but in the real world we deal with diverse requirements, and in the real world there are no silver bullets. There are however, decision trees, which can tell is which bullet is the silver one *for this particular situation*.
If something useful was to come out of this thread it might be some kind of flow-chart that shows in what situations S/C or P2P show their strengths and weaknesses...
e.g. if cheating is not a concern you may choose to have clients do hit-detection client side - this decision works in both S/C and P2P though! So now you've decided to run game logic client side, you can decide if clients broadcast to each other, or forward packets through a server. Perhaps they would even do a bit of both (low-bandwidth players using high-bandwidth players as a proxy).
Perhaps it's not possible to run much game logic client side, which would require an 'authority' (server or a peer). Perhaps in the case of a full authoritative server clients can still share their inputs P2P style for prediction.
There's obviously a multitude of ways that data can be shared, various places that data can be computed (with different levels of authority) and lots of techniques for replicating a simulation.
There is no one perfect answer for all situations! Anyone who says they've found the silver bullet is likely ignorant, inexperienced or is simply trolling.
[Edited by - Hodgman on September 7, 2009 10:35:13 PM]
