Gaffer

Members
  • Content count

    65
  • Joined

  • Last visited

Community Reputation

422 Neutral

About Gaffer

  • Rank
    Member
  1. I agree that the VPS time slicing throws it off - the idea was not to make precise measurements, but to show that the amount of jitter may vary widely from connection to connection, and from day to day I'll be following up with some actual dedicated server tests through Sony which should show "true" jitter without timeslice issues on the host cheers
  2. Hey all, I've released the slides + demo for my GDC 2010 physics tutorial day talk "Networking for Physics Programmers" A quick overview is that here is a technique for synchronizing a cooperative game P2P such that players feel no latency when interacting with physical objects (via authority scheme), plus a corrections scheme for streaming in changes made to the world before a player joined the game. There is also a ton of previously unreleased upload/download bandwidth info from Sony, as well as some RTT and jitter analysis that you guys will probably find interesting! You can download it from here: gafferongames.com Hope you guys like it!
  3. Networked physics

    Hey all, I've released the source code for my networked physics demo that I show at GDC, MIGS'09 etc It's called "Fiedler's Cubes" and it demonstrates how to use an authority scheme to hide latency by taking authority over objects you interact with, as well as how to use distributed algorithms to keep a world of one million physically simulated objects consistent, even when players can late join - all without requiring a dedicated server. This is not of course always the right way to do things, this demo is designed around a COOP game with networked physics and high simulation cost per-player, with the goal of avoiding paying for a dedicated server - but if you are interested in networked physics you will find this demo and source interesting :). It's BSD licence + non-commercial creative commons licence, so take a look at the source code feel free to steal all my ideas but please do not incorporate the source directly into commercial projects. Source + MacOSX Snow Leopard 64bit binary is here: Fiedler's Cubes Source + MacOSX Binary There is also an alpha-Win32 port here, but I haven't had a chance to fully test that one, no PC at home... buyer beware :) Fiedler's Cubes Win32 Binary (Alpha) Feel free to ask any questions about networked physics in this thread and I'm happy to help cheers, Glenn Fiedler www.gafferongames.com
  4. 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.
  5. Network Jitteryness

    This is quite a large subject and there are many options... The way I like to think of this is that you can consider your client as having a window buffer of some 10s of MSec, and it tries to speed up and slow down rate of playback such that the server packets arrive in this window. You try to keep the server delivery within some std deviation of your current guess of what their current time is, and if for some period of time the server jumps too far ahead/behind this window you have to stop and recalibrate. Then other things come into play like interpolation/extrapolation - for example, if you have different delta times on the server vs. your client during playback, it is necessary to do the interpolation at a minimum to avoid introducing temporal aliasing This is actually quite a black art and I've found very little documentation or papers on the game specific implementations of this, so if anybody has some to share - or perhaps some good search terms to hop off on a research expedition on this, i'd really appreciate it thanks [Edited by - Gaffer on September 7, 2009 4:14:00 AM]
  6. 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
  7. 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!
  8. 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]
  9. Quote:abaraba says How do you explain they researched it if there is not a single paper, article or any kind of written assessment or analysis to show, or even suggest P2P would not be suitable or would be less practical for whatever the situation they required. There is no such document. All the research, theory and practice goes only to prove P2P is very useful, practical and heavily underrated. 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. Quote:What would Quake or Counter Strike lose if they provided P2P at least as an option, and what would they gain? their overall bandwidth would be higher, they would be massively susceptible to cheating, and the players would be lagged by the most lagged player when using a lockstep deterministic P2P networking model like the one used in age of empires. Quote:No problem, we already have it. Stickman uses 5KBps upload with 50 players, therefore it would need about 25Kbps for 250 players. It scales easy as that. yes, and... ? it is well known that bandwidth per-peer scales at O(n) - so what? the reason we don't care is because there is something better: with client/server the client bandwidth is O(1) - it does not increase as the number of players increases - it stays the same. Quote: Now, you tell me how much would they save if they used P2P approach instead, and how many more players could they support? It costs less, yet gives you more. they would save nothing. their product would not work and they would lose their jobs. Quote:P2P can distribute the load and have each peer do the physics and collision only for itself. This is particularity about the games without dedicated server or console games, where security risks are not an issue or are the same as with C/S approach. assuming you go with a deterministic lockstep input passing based P2P sync, you cannot perform the physics and collision just for yourself. you must by definition run the exact same code for all peers. i am surprised that you don't seem to understand this, since the age of empires paper is quite explicit in describing that they use a P2P lockstep deterministic network model, like pretty much all other RTS games. [Edited by - Gaffer on September 6, 2009 2:01:55 AM]
  10. Quote:Back to abaraba's comeback. I actually remember his initial rampage and it has provided me with plenty of entertainment in the past. I'm glad to see he hasn't lost his ways and still puts up one hell of a show. I can't help but think he's just faking it. I can only hope anyways. Dude, if he's faking it I will personally nominate him for an academy award. According to Downey Jr. he may have blown his chances though: Quote:Stiller: "It's what we do, right?" Downey: "Everybody knows you never do a full retard." Stiller: "What do you mean?" Downey: "Check it out. Dustin Hoffman, 'Rain Man,' look retarded, act retarded, not retarded. Count toothpicks to your cards. Autistic, sure. Not retarded. You know Tom Hanks, 'Forrest Gump.' Slow, yes. Retarded, maybe. Braces on his legs. But he charmed the pants off Nixon and won a ping-pong competition. That ain't retarded. You went full retard, man. Never go full retard." Zing! :)
  11. Quote:abaraba says I don't know what to tell you. Can you make your point other than proving me wrong? I mean, none of your objections makes P2P any less practical. You are complaining about bandwidth, but please realize there is a point where certain number of players can only be supported with P2P, having the common bandwidth limits. To illustrate, if a maximum number of players on average Xbox 360 game with average ADSL is 16, that means P2P would be able to host 32 or more. So, don't forget, with P2P everyone is a winner. To be fair mate you do make it pretty difficult to make a point without proving you wrong. If you would like for people to stop proving you wrong, perhaps you should stop posting incorrect statements?
  12. Quote:abaraba says: Peer upload: 255 packets Server upload: 256*256 = 65536 packets Incorrect. Peer upload: 255 packets Client upload: 1 packet Integrated server upload: 255 packets Dedicated server upload: 256 packets Why exactly do you think the server must upload 65536 packets? Why would anybody use client/server if this was true?
  13. Read on for the new adventures of abaraba - the timestep crusader! :) http://gafferongames.com/2009/09/04/the-return-of-the-timestep-crusader
  14. I'd *love* to see this guy sweating it out actually trying to ship a console game. Especially considering the 360 TCR that you must function at 64kbit/sec up and down ... try doing that with P2P @ 32 players. I'm waaay too lazy to do the math right now (it's 12:35AM on a sunday night), but the packet header overhead would probably eat up the entire 64kbits, especially if he goes with the 60Hz packet send rate!!! :)