• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Gaffer

Incoming hilarity: abaraba is back, and this time he's fixated on P2P networking!

82 posts in this topic

Quote:

Quote:
Original post by Gaffer
this statement is incorrect. there are many documents discussing the quake, counterstrike and unreal networking models. each of them discuss why client/server is a more attractive choice than peer-to-peer.



There is no such document and I challenge you to prove me wrong. Do you accept the challenge, mate?

And google presents (in 0.29sec no less)

how and why quake's model works:
http://www.runequake.com/hoh/Quake.pdf

discussion of many of the pitfalls of P2P quake and how to help alleviate them. But notice how they skirt around the bandwidth problem by limiting the data set. The same techniques could apply to client/server.
http://cseweb.ucsd.edu/~fuyeda/papers/iptps2007.pdf

More discussion of P2P and the extremes you have to go to in order to make it work for clients with vastly different hardware and networks.
http://prisms.cs.umass.edu/brian/pubs/stjohn.nossdav.2005.pdf

Quote:

How many games have dedicated servers, 2%? Regardless of time P2P will always be able to make it more practical for average users to get together in greater numbers.


Of the games i have:
TF2, MW4, L4D, CS Source, HL2, Quake 3, UT2K4, IL2, Descent Freespace...

hmmm... looks like I didn't find a SINGLE game that has multiplayer, uses ClientServer, and doesn't provide an .exe i can run/remote host as a dedicated server. Not saying they don't exist, but that is a lot of big name games I listed, and they all provide that functionality.

RTS games are usually P2P, so they can all run without hosted servers. (except SupCom, cause they tied that to GPGNet for some stupid reason)

And again, I'm going to stress. Without a dedicated server (pirate bay, battlenet, gpgnet, steam) how many people do you expect to play a game together? It isn't a magical "P2P! GO!", people still need a place to gather to play the game. If you as a company have to provide a matchmaking server, and the gameplay model plays better(lower lag, less cheating, etc) on C/S why not setup that way to start with and save yourself the hassle of making P2P work. Read the papers above, P2P takes a lot more work just to get it to behave close to the QoS level C/S setups have.


Finally, from a developer standpoint. There are deadlines. Imagine 6 months to make this P2P or C/S game model work, with a publisher breathing down your neck, quoting your minimum specs, and quoting you support costs for features if they are to be expected to host anything (server OR just matchmaking server). Now, are you going to go P2P and risk all the problems it has? (have you read how hard it is to get BitTorrent working? Network problems abound.) Or just go with a client server, pay hosting costs, but save on Support line costs? Very few games(ie only PC, and some console live games) are willing to provide devs with support money for patches and the like. So again, something that is risky? or something that works out of the box and you don't have to risk wasting money patching as often?
IF there was some "P2P Networking Middleware!(tm)" company then things would be different, but there isn't one. On the other hand there are tonnes of dedicated server hosting sites a company can choose to rent from.

Quote:

Why do you imagine peers can not predict actions ahead? It's nothing more but velocity extrapolation. Authoritative server is not necessary to make interaction fair.


Ah, but it is. Because in the face of cheaters and packet loss, not every client sees the same view of the game. You need arbatration. Either you waste bandwidth sending data so the clients can choose to agree on the world state, or you have a dedicated server that dictates the world state

Quote:

Read what? There is no such document.

I expect you to give me that link you told me to read upon, so I can read it.

Learn to google. Tonnes of CS majors go onto grad school and have to publish papers on this type of crap all the time. Also, check out some of the networking middleware that is available (like eNet or RakNet). They also discuss quite in depth most of what you are talking about.

It is a bad attitude to demand resources that you aren't willing to look for. I have yet to see you provide any source documents of any academic quality to back up your claims. That is why you keep getting banned. Arguments aren't about "you are wrong I'm right", they are about "here is proof" "rebuttal proof". Scientific method and all. Everyone else is being through and rebutting points categorically down each of your posts. Why not follow in suit? I note you picked a SINGLE point on my list to rebutt/accept. Sounds antagonistic, and like you are skirting the issues instead of attempting to understand, accept, or properly attempt to educate us on how we are wrong.

Quote:

If you pass only input then you likely need determinism, but if you pass all the data then you don't,

And there's the rub. What type of game are you making? an input based twich game(FPS) or a turn-based/lockstep game(RTS)

[Edited by - KulSeran on September 6, 2009 6:45:11 AM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Andrew F Marcus
You are describing two identical techniques, equally implemented in either case. Server running in the past 100ms is the same thing as issuing commands 100ms for the future. The difference is only if you gonna interpolate this lag with client-side predictions or simply let the user experience the latency.


No, there is a huge difference.
1 Model provides real-time feedback to use input by predicting the actions locally.
The other model introduces a delay in the user's actions to hide network fluctuations.
The difference is in the speed of feedback from key presses.

Quote:
Original post by Andrew F Marcus
The point is very simple and not involving any grails - "Stickman" is possible, 5KBps upload with 50 players over P2P. That's all. It's a fact so it's not incorrect. Predicting the possibility of such game, while everyone is saying it's impossible, does not make it naive, but visionary.

A single game is not representative of all games ever made.
Like I stated in my post, it depends on genre. It's all about user expectations and how much lag they're willing to tolerate.
An RTS or RPG can quite often get away with several 100 ms of input lag. An FPS absolutely can not.

Quote:
Original post by Andrew F Marcus
Read what? There is no such document.

http://unreal.epicgames.com/Network.htm
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Few of the many documents on networking in a real-time FPS game.
I had no trouble finding them using Google at all.

Quote:
Original post by Andrew F Marcus
Not true, all the same tricks work all the same.

From this I can only conclude you've never designed or implemented a networking model.
I have. There are very distinct differences in tricks used in C/S and P2P.
P2P with input sharing causes all clients to run a full simulation of the game.
Client/server with authoritative server will turn clients into dumb viewers who only run a partial simulation for the local player to hide latency.


Quote:
Original post by Andrew F Marcus
Why do you imagine peers can not predict actions ahead? It's nothing more but velocity extrapolation. Authoritative server is not necessary to make interaction fair.

No, you can't make predictions in a P2P input sharing model.
Since only input is shared the clients need to run fully deterministic to remain synchronized.
Note the words "input sharing". There are no object positions being shared, only key presses.


Quote:
Original post by Andrew F Marcus
How did you come up with that? If you pass only input then you likely need determinism, but if you pass all the data then you don't, same as with a server approach. Go play Stickamn.

A data sharing model in P2P is highly prone to hacking and cheats.
Additionally it introduces several problems with interactions and timings.
Again, I base this on real life experience. Not assumptions I made by briefly looking at various other games.

Quote:
Original post by Andrew F Marcus
False. It is not about P2P, it's about passing input and determinism. If you wanted to make Age of Empires with C/S model you would need to do exactly the same thing.

It's funny you should mention Age of Empires. That game will freeze all clients when one of the clients freezes sufficiently.
The reason against using the input sharing model with client/server is the additional latency introduced, this is a much bigger factor than bandwidth usage.

Quote:
Original post by Andrew F Marcus
to give me that link you told me to read upon, so I can read it.

They're at the top of the post.
Please educate yourself before making these outrageous claims.
Your posts make it very clear you have no practical experience in designing or implementing network games.
Your statements and theories are out of sync with the real world.

[Edited by - Azgur on September 6, 2009 6:48:29 AM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by KulSeran
And google presents (in 0.29sec no less)



Thank you, my friend. I don't think I need to say anything anymore, from now on I'll just quote these links. Are you on my side or were you just lazy to actually read those papers?


Scaling Peer-to-Peer Games in Low-Bandwidth Environments
http://cseweb.ucsd.edu/~fuyeda/papers/iptps2007.pdf
Jeffrey Pang, Carnegie Mellon University
Frank Uyeda, U. C. San Diego
Jacob R. Lorch, Microsoft Research



...For this reason, we are developing a new architecture,
called Donnybrook, to enable large-scale P2P games even
in environments with highly constrained bandwidth.

To evaluate our techniques, we modify Quake III,
a popular first-person shooter (FPS) game, to run on
Donnybrook.


To test
these techniques, we implement them and conduct
a user study that evaluates the resulting game. We
find that our techniques make a game played with
low bandwidth significantly more fun than existing
techniques, and nearly as much fun as one played
on a LAN. Thus, they enable an order of magnitude
more players than existing techniques.



We present the results of a large user study,
which show that Donnybrook substantially increases the
enjoyment of P2P Quake III in a low-bandwidth environment.
0

Share this post


Link to post
Share on other sites
WOW. You took entirely the wrong take on those papers. I posted those to educate you on the pitfalls of P2P, and how much more work it is to get P2P working vs the standard client server approach. They even document how much more bandwidth the P2P method takes vs C/S. I read each of those end to end before posting them, in the hopes of finding documents that would help you understand what makes P2P the worse of the two solutions.

That said. You were looking for data to prove or disprove P2P is "better". Do your research and you will find there IS research being done in both the C/S and P2P directions. Agreed the "donybrook" method can make P2P work better than P2P currently does, But it is NOT a document comparing C/S directly to P2P. But a comparison of different techniques of P2P vs other P2P techniques.

Quote:

more fun than existing
techniques, and nearly as much fun as one played
on a LAN. Thus, they enable an order of magnitude
more players than existing techniques.

They are only comparing P2P techiques vs other P2P techiques. NOT C/S vs P2P.



-- sorry for all the edits --
0

Share this post


Link to post
Share on other sites
Quote:
Original post by KulSeran
WOW. You took entirely the wrong take on those papers. I posted those to educate you on the pitfalls of P2P, and how much more work it is to get P2P working vs the standard client server approach.


I'm sorry if you find it confusing, but there are no pitfalls in P2P other than usual latency and sync issues, just like with the server approach. Do you realize they made their P2P by running Quake server on each peer? There is no more work involved, it's the one and the same thing.


Quote:
Original post by KulSeran
They even document how much more bandwidth the P2P method takes vs C/S.


Hey, you said they were not comparing it with C/S. You must be talking about some other paper, this one is actually about Low-Bandwidth Environments, no server can run here.


Quote:
Original post by KulSeran
I read each of those end to end before posting them, in the hopes of finding documents that would help you understand what makes P2P the worse of the two solutions.


Worse? What are you referring to, this:

Online multiplayer games have become an important
part of the computing landscape. There is a growing
desire to serve these games using the machines of
participants themselves rather than with dedicated
servers.

Using participant machines reduces subscription costs,
eliminates dependency on centralized infrastructure, and
automatically scales to an arbitrary number of clients.




Quote:
Original post by KulSeran
That said. You were looking for data to prove or disprove P2P is "better". Do your research and you will find there IS research being done in both the C/S and P2P directions.

I can't find anything, so if you have more links to share, please do.

Quote:
Original post by KulSeran
Agreed the "donybrook" method can make P2P work better than P2P currently does, But it is NOT a document comparing C/S directly to P2P. But a comparison of different techniques of P2P vs other P2P techniques.


Are you aware they were measuring "fun". The test subject were all gamers, Quake players, they did not even know the game was running in P2P. So when these guys tell you game was nearly as much fun as one played over LAN, what do you make of it?

P2P Quake had terrible problems?
P2P Quake played worse than normal Quake?
P2P Quake played better than normal Quake?
0

Share this post


Link to post
Share on other sites
Andrew F Marcus, please answer me this:
Do you have any personal experience to back up these claims?
Have you prototyped different approaches and witnessed the pro's and con's first hand?

A large amount of the people providing counter arguments to your claims actually have experience in designing and implementing network models.
Articles (especially if not your own) and theories are not a substitute for real life experiences.
0

Share this post


Link to post
Share on other sites
Come on guys, the OP should have made it perfectly clear not to talk to this moron.
0

Share this post


Link to post
Share on other sites
Quote:
In a P2P model you're required to run the game deterministically (or face a really really huge mess) which means you can't hide latency with the same trick.
P2P games often can't simulate the next step without having received input from all peers.
This results in 1 client being able to freeze all other clients.
This is considered acceptable in RTS games, but completely unacceptable in FPS games.


this is a very valid point.

consider what would happen if abaraba took age of empires networking model and scaled it up to 250 players...

if any one of those 250 players experienced network delays, all other players in the game would have to stop and wait for them.

as the number of players increases the probability of any player having network issues at any time increases too - eventually at some point the game would be generally unplayable as all players get stuck in a feedback loop waiting for the most lagged player.

consider also that a deterministic lockstep model would also generally require all 250 players to join into a lobby before starting the game. you cannot support late joins. consider how long it would take to get 250 players together before you could start the game - it takes long enough to get four together in left 4 dead!

[Edited by - Gaffer on September 6, 2009 4:41:31 PM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Come on guys, the OP should have made it perfectly clear not to talk to this moron.


absolutely.

and now, i think it's only fitting to say goodbye to abaraba - and to thank him for all the good times we've had together

http://www.youtube.com/watch?v=sFR8N_sLvFs

so long abaraba, until next time!
0

Share this post


Link to post
Share on other sites
I've been away from gamedev's network section for a while now.
This topic is really funny, I can't believe there is a discussion
about s/c vs p2p! It is a funny 3 page read though, thanks :)
0

Share this post


Link to post
Share on other sites
Quote:
My current reality is that P2P allows for a higher maximum number of player than Server-Client does in the case we don't use dedicated servers


Actually, the one crucial assumption is that everyone has the same upload limitations. If that is true, then P2P will allow larger amounts of clients than C/S -- but only up to some small amount of clients, like 16 or 32, because limited upload is, well, limited :-)

As soon as you can find one user who has better than average upload, then C/S gives you a lot of benefits, including an authoritative server, larger player counts (even for players with much more limited upload), etc. And that server is, generally, a normal playing doing "hosting," not a dedicated server paid for by the game publisher.

When it comes to RTS games, I'm not so sure they are all P2P -- if you look at Starcraft, for example, it has a clear host, and when on the Internet, it goes through battle.net to avoid NAT problems. I wouldn't be surprised if it actually was C/S topology with the "host" as the server. However, it doesn't matter much, because with 4-8 players, neither model is all that different in network bandwidth usage, so other implementation worries probably weigh more heavily.

0

Share this post


Link to post
Share on other sites
[Most Text Deleted by Moderator]

* Donnybrook is a collaboration between Microsoft Research and the Carnegie Mellon University, the system was at the basis of simulation results involving battles of approximately 900 players interacting simultaneously.

* Players are satisfied by Donnybrook in a low bandwidth environment as they are by Quake III in a high-bandwidth environment, e.g. a LAN.

[Edited by - Promit on September 7, 2009 12:40:51 PM]
0

Share this post


Link to post
Share on other sites
Quote:

Phosphor is a first-person shooter created with Macromedia Director. The Shockwave Player allows the game to run within a web browser on Windows and Mac OS computers. Both single player (with AI-controlled bots) and multiplayer (using peer-to-peer Internet or LAN connections) game modes are supported. Our goal is to create a gaming experience similar to classic FPS games.

http://www2.rasterwerks.com/game/phosphor/beta1.asp


This guy not only implemented P2P multiplayer instead of server based approach, but he also coded a first-person shooter in Macromedia Director instead of C++, what a moron.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by NickS
* Donnybrook is a collaboration between Microsoft Research and the Carnegie Mellon University, the system was at the basis of simulation results involving battles of approximately 900 players interacting simultaneously.
Where do you get the number 900 from? From the papers linked so far in this thread (and all the other papers I have found), it seems to me they're testing only 2 players at a time, with 30 bots (i.e. 32 players in a single game).
Quote:
Original post by NickS
* Players are satisfied by Donnybrook in a low bandwidth environment as they are by Quake III in a high-bandwidth environment, e.g. a LAN.
That's still comparing Donnybrook P2P in low-bandwidth to "naive" P2P in high bandwidth, though. It's not comparing Donnybrook P2P with C/S. Also, the "low bandwidth" Donnybrook is 108Kb/s upload which is already at the limit of many people's broadband plans - that is, even Doonybrook does not scale past 32 players on a standard broadband plan*.




*Technically, Donnybrook bandwidth requirements are supposed to scale better than linearly in the number of players, but it's still not "free".
0

Share this post


Link to post
Share on other sites
It's been a while since I read the donnybrook paper, but it seemed to me really it's just all about encoding a higher level representation of the actions being performed, then playing it back roughly in sync using much smarter locally running interpretive AI actions

eg. get from A to B, I don't really care how you do it - just do it, climb the wall, jump whatever

In other words, just another one of those classic trade-offs between consistency and throughput

The end result being you don't need such a high frequency of updates to get smooth realistic motion of players and AIs in the remote view - you can get away with something like one update per-second vs. the usual 10 or 20

(but then again, if I'm missing something let me know ... it's been a long while since I've read that paper)

cheers
0

Share this post


Link to post
Share on other sites
Another thing to consider is the complexity of implementing the Donnybrook solution, compared to the way it was done in "normal" C/S Quake 3. The way it was implemented in C/S Quake 3 is practically the most naive solution possible while still providing for 32 players (in fact, if you read what he says, it seems Carmack simplified the implementation a lot since the original QTEST).

Donnybrook is far more complex than the C/S implementated in Quake 3, and it doesn't seem to work any more efficiently than C/S quake.
0

Share this post


Link to post
Share on other sites
This thread is a complete mess.

NickS, if you are author or in any way related to the Donnybrook project, it would help to state so.

If you are abaraba, then stop copy pasting sections from the documents. We can read and comprehend, have already done so, and understand what the article says, it is just pointless to comment.

And I have no clue where that rasterwerks link came from or why it matters, except to show author's comment that P2P doesn't work in real world.

Either way, this one way regurgitation of unrelated quotes and terms has gone well beyond any measure of good taste or rational thought. Finnegan's Wake is light reading compared to this.
0

Share this post


Link to post
Share on other sites
Quote:
There is a growing desire to use the machines of participants themselves rather than separate dedicated servers to provide resources for serving games.


Do you have any support at all for this statement?

In my experience, it used to be that users would host, because hosting was expensive. These days, hosting is cheap. Thus, /users/ will pay for dedicated servers (just jump on any C/S:S session -- almost all the servers are hosted at ServerBeach or Gameservers or whatever).

When it comes to large-scale P2P solutions, I still recommend you look into the VAST project. However, it's also been my experience that when people try to really deliver large systems on P2P, they end up adding more and more C/S-like systems, until suddenly the P2P turns out to be something like a C/S set-up with P2P-elected dynamic servers...

Finally, Xbox Live! tech cert requires that you work well in multiplayer on 64 kbps upload. While some users may have 768 (DSL generally comes with 384), you're not allowed to use that in your normal multiplayer scneario.
0

Share this post


Link to post
Share on other sites
Hi guys, I'm the developer of the earlier mentioned Stickman Warfare, one of the banned guys from here has invited me to this topic, so I'm just here to share my experiences.

I've been doing stickman for like 3 years now, and i have to tell you, P2P is a heavy PITA. Not only it has sync and connect issues, it's really easily hacked. But the reason I made it this way is that its absolutely free to host, since a P2P NAT introducer doesn't use too much bandwidth OR CPU, so it can be run from a really cheap (free) virtual server at my friends computer.

Apart from the NAT stuff, i found P2P a lot easier than C/S. Simply because the player only has to care about his characters physics only, and it doesn't have to synchronize with the server, compensate the roundtrip time or anything like that. Only the priority system was a bit difficult/complicated until i fine tuned it. Now the network code is no more than a few thousand lines of PASCAL code.

Oh, and with the right priority system, you can have infinite players using only 7kBps upload. (yes, stickman did not lagg at 70 players and its completely scalable)

OF course, this cannot be applied to a commercial game because its so much less secure than C/S that hacking is inevitable, only delayable (memory protection, debugger detection, etc... but thats only against Cheatengine using script kiddies).

Well, thats all i could think of.

P.S: Its been a long time since i used my English...

EDIT: Forgot to mention, my P2P implementation is rather unstable, there are times when you don't connect to the clod or suffer severe lag. Thats completly my fault, not the P2P's.

EDIT2: I just read th whole topic, and I dont know the guy, please dont ban me :P. I dont consider my game great or innovative, it is just your average P2P shooter.
0

Share this post


Link to post
Share on other sites
Quote:
stickman did not lagg at 70 players and its completely scalable


What happens when 100 players all congretate in the same spot?

Quote:
stickman.hu <=my game (please tell me your opinion about it)


404
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Gagyi
EDIT2: I just read th whole topic, and I dont know the guy, please dont ban me :P. I dont consider my game great or innovative, it is just your average P2P shooter.
Hehe, I don't think you have to worry. At least you have the benefit of having actually implemented your idea, rather than just spouting numbers and selectively quoting other people's work :-)
Quote:
Original post by Gagyi
But the reason I made it this way is that its absolutely free to host, since a P2P NAT introducer doesn't use too much bandwidth OR CPU, so it can be run from a really cheap (free) virtual server at my friends computer.
Yeah, I would say that's probably the biggest advantage for an indy developer.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Super-Sandra
Quote:
Original post by hplus0603
Quote:
There is a growing desire to use the machines of participants themselves rather than separate dedicated servers to provide resources for serving games.


Do you have any support at all for this statement?


In my browser I have a message, from yesterday, that is not here today. It was a summary from the paper answering questions posed by Codeka and Gaffer. It also answers your question.
I don't think that paper actually answers hplus0603's question. Certainly, the paper isn't a study of the desire to use the machines of participants themselves rather than separate dedicated servers, it just "assumes" that's what people are after.
Quote:
Original post by Super-Sandra
Quote:
Original post by Codeka
Where do you get the number 900 from? From the papers linked so far in this thread (and all the other papers I have found), it seems to me they're testing only 2 players at a time, with 30 bots (i.e. 32 players in a single game).

Quote:
Original post by Gaffer
The end result being you don't need such a high frequency of updates to get smooth realistic motion of players and AIs in the remote view - you can get away with something like one update per-second vs. the usual 10 or 20

(but then again, if I'm missing something let me know ... it's been a long while since I've read that paper)


Donnybrook: Enabling Large-Scale, High-Speed, Peer-to-Peer Games
Each player receives frequent updates, at a rate of 20 per second, from only five other players independent of game size. Guidance is sent to all players, but only once per second. Thus, while the mean bandwidth requirement per player still scales quadratically, it is reduced by a factor of approximately 20*n/20*5+n. For a 1,000-player game, this reduces the requirement from 12Mb/s to 670Kb/s, making such a game feasible.
670Kb/s is still unfeasable today.

Actually, there's nothing in Donnybrook that couldn't be implemented in a client/server application to reduce the bandwidth requirements on the server (so you'd still have O(1) upload bandwidth requirement on the client, and you can reduce the upload bandwidth requirements on the server [and download bandwidth requirements on the client as well] using Donnybrook).

You still have to calculate all the physics and such on the server, which might be a problem for a complex 1000-player world, but not impossible (besides, it's much easier to buy more/faster CPUs than it is to buy more network bandwidth)

In any case, my previous statement about the complexity of the implementation still stands as well...
0

Share this post


Link to post
Share on other sites
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]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Gagyi
Oh, and with the right priority system, you can have infinite players using only 7kBps upload. (yes, stickman did not lagg at 70 players and its completely scalable


The problem with abaraba is that he took your game as his main argument to demonstrate that P2P scales better than C/S.

Of course, this priority system could be equally implemented in a C/S model too, so there's nothing you can deduct from the fact that Stickman can handle 70 players at 7kBps, and certainly not that P2P > C/S.

Y.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
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...


agreed 100%, unfortunately abaraba got these things mixed up, glomming on the P2P topology and not considering the networking model - at first he opined that the age of empires networking model (lockstep) was the shining light demonstrating the virtues of P2P, later on he moved to stickman as his new beacon of light in the darkness...

of course, we all know these two games have *radically* different networking models, really i can't think of anything more different in treatment than an input/command based deterministic lockstep model vs. a state passing asynchronous model -- but try explaining that subtlety to a guy like abaraba.

Quote:
Original post by Hodgman
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).


If you read this thread and the other forum links on the internet where this guy has trolled, i'm sure you'll come to the same conclusion as we did - it's simply not possible to have a rational discussion with this guy.

http://gafferongames.com/2009/09/04/the-return-of-the-timestep-crusader/

He's been banned from just about every forum on the internet, and keeps coming back with aliases to further his discussion way past the point of no return. He was actually banned on this site *before* this thread even started, for doing exactly the same thing in two threads previously re. P2P. And yet, he keeps coming back to beat the dead horse in this thread :)

The problem with properly refuting his points and providing useful information is this guy just doesn't care or understand any points you make. Instead of considering the points and thinking about it - he'll immediately take any new information you provide and turn those around to advance the discussion towards his argument.

The only technique I've found that works is to simply refute his points without adding anything new to the discussion for him to "tangent" off, while clearly demonstrating that his original statement is false.

Quote:
Original post by Hodgman
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.


Amen.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0