: The problem is that you can't predict what the human controlling : the joystick on the other side of the table did.  You can't model : a person and predict his actions, period. : Thats not an absolute.  Its just how GOOD can you predict.  You obviously : can predict : SOME things, and hopefully you'll get the REAL input before it gets TOO out : of whack. : Its definitely not something to put a period after. Okay, so ammend to say you can't model an individual human being well enough to predict his actions on a minute scale.  If someone throws a pie at your face I can obviously predict that you'll try to dodge it but I can't predict whether you'll duck under it, move to the right or left, or whether your reaction will be successful.  Period. : I think your goal of a smooth game at 1 second latencies is indeed futile. : Why set such a : goal when there are gazillions of folks (myself included) that never get a : ping higher than say 550ms? Because there are gazillions more that DO get pings higher than 550ms and if you ever connect with one of them you'll get that kind of ping time too.  It takes two to ping... if you're satisfied with sorting p_layer_s _base_d on connection speed then I haven't argued that isn't a valid thing to do.  Selectivity in the media _layer_ is always an option. : See Duke Nukem 3D and Descent over Kali for this confirmation.  When I play : Quake, I always am able to : find a server thats under 200ms. That's you.  Try playing it with a person from China or South Africa and see if you can both find a server with 200ms response time. : The game still stalls on any lag over 400 milliseconds and I'll : get some icky correction artifacts when my predictive motion model : doesn't fit what actually happenedi when lag is over 200 milliseconds. : I think thats to be expected.  If you could make it work decent with 300ms, : I think the majority would be satisfied. That's the whole problem - some people DON'T think it's expected that there be problems and that there's some overlooked magic bullet to make the problems go away. : Doesn't help.  The critical event that I can't miss is trivially : packaged with events that I can miss.  Next... : Hmm, if the score count is changed on whatever computer recognized a : score, maybe you could confirm scores on both machines (every time a : score was made) to see if 1 computer missed something?  Or some other such : confirmation that doesn't have to be done on a regular basis.  If you got : unused : room to spare in your packets, maybe have it relate something such as the : scores : so it can make sure those few critical events weren't lost among all the : trivial : events. I can continue the game in any number of ways but the bottom line is that at some point I have to correct for predictions that replaced real time information from the other instance where the predictions were wrong. : Methinks that you are talking so defeatistly to stir somebody up who'll be : bent on : proving you wrong, in the hopes that the extra motivation will make someone : come up : with a real solution for you.   If that happens it'll be nice but I'm not holding my breath...  I'm writing turn _base_d games and breathing normally. : You haven't found the solution yet, so nothing is exhausted, just your : current mindset.   Not all problems have practical solutions.  We can go all philosophical to the point where we prove that nothing is real but that doesn't change the practical impact of what appears to be real. : Once you see something in action, and know its possible, then it seems like : your : mind will eventually formulate a solution.  You've seen Quake haven't you? Of course.  I've also seen my son install an ISDN router in his bedroom so it plays better.  Ping times of 200ms are range from unacceptable to some to barely acceptable for others to quite playable to others.  It's a subjective thing. : There simply isn't enough in the way of possible solutions to warrant : a book on the subject (OR a mailing list).  We've already ran the : whole gamut of possibilities. : Ummm, you need to play Quake if you haven't.  Or even Duke3D & Descent over : Kali, even though they are programmed for a LAN, and Kali translates their : IPX packets to TCP/IP on the fly, Duke and Descent are even smoother than : Quake. : Sometimes Duke approaches direct modem connect smoothness (which is almost : as smooth as single play). : It was a rhetorical question... I knew you couldn't help me and you : didn't.  The problem has no solution.  Don't be such an idealist : that you can't recognize when a problem has no solution. : Hoo boy!  You're a positive one.  I will say one thing regarding air hockey : specifically.  It might be MORE frustrating than : current games, because if its like real air hockey, that puck can whip : around really quick.  A bit quicker than Quake's rockets.  Maybe you should : think about an action game with slower projectiles, or simply slow down the : pucks possible speed.  Unless you're using a mouse, you couldn't possibley : play air hockey SOLO with it being as fast as real air hockey. : I KNOW id and plenty of other action game companies could easily do what : you seem to think is impossible.  When you say there is no solution, do you : mean that no average joe programmer could possibly think of the solution : himself, and must wait til Quake or similar code is old and becomes : downloadable? If you read the rest of the thread you'd have seen that I opened it up by saying that you can design a game to work around network lag. What you can't do is design a communications _layer_ to eliminate network lag.  Obviously slower moving projectiles are one way to use game play to best advantage.  I've come up with a lot of other ways of *masking* network lag behind contrived game play but no way of eliminating network lag through generalized solutions. David Springer

: Wouldn't it be cool if you could design an internet flight sim that let over : 200 people play in the same arena and tolerated latencies up to 2 seconds? Way cool. : Wouldn't it be even cooler if people from more than 30 different countries : played this game? Even better. : An wouldn't it be even cooler if the server was up and running 24 hours a day, : seven days a week, and you didn't have to go searching for people to play : against because there are always people on? That's the easy part... : Why set such a : goal when there are gazillions of folks (myself included) that never get a : ping higher than say 550ms? : Because if you want to reach customers outside of the US you have to be ready : for the connectivity problems associated with overseas connections. The connectivity problems aren't limited to overseas connections.  I was watching response times in a backgammon game I was playing with a fellow in New York City - I'm in Austin,Texas - several times during the games, which lasted an hour or so, there was a network delay of 5 seconds or more. I have no idea where the delay was generated at - it was a two p_layer_ game and we were directly connected through a winsock stream TCP socket. Even a turn _base_d game like backgammon deteriorates with 5 second delays. It makes you wonder whether the connection was lost, the other p_layer_ is daydreaming and doesn't know it's his turn, or what... David Springer

[good reply on Air Hockey snipped] Best reply I've heard and pretty much explains how it has to work. The key points were - it will work okay sometimes when network connections are good and at other times it will suck. This is pretty much the fate of games that aren't specifically designed to mask network lag with gameplay. : How can you say that when there are 16 p_layer_ Quake matches running 24hrs a : day on billions of servers (ok, little exaggeration)? : I can say that because 1) Quake had a lot of thought put into making it internetworkable, and 2) it sucks on a poor connection.  Try playing it with randomly selected p_layer_s from all over the world and let me know how it goes... : game, but its an awesome piece of technology. : Just think, Quake, with 16 clients, each firing multiple projectiles, : opening doors, moving platforms.  I think Air Hockey : should be relatively easy compared to that.  Well, I guess the pucks do : tend to be a bit faster than Quake's rockets, but : not by much.  Those rockets FLY. I think you've been spoiled by good network connections and using some selection criteria in opponents.  If you're lucky enough to have a good ISP and find opponents not too far away with a good ISP also then you can, barely, make a white knuckle game work well. For anyone, anytime, anywhere it won't make it. Also note that one person's opinion of what's playable isn't necessarily another person's.  More serious p_layer_s will install a good ISDN router at home to improve the game play.  It'll subtract about 100ms from the ping time to a server or another ISDN equipped p_layer_.  If 200ms were acceptable to everyone then an expensive ISDN router, service, and line wouldn't be needed. David Springer ********* WEB GAMES ONLINE ENTERTAINMENT SYSTEM *********** *                                                         * *  A client/server system designed from the ground up to  * *  support real time multi-p_layer_ games on the Internet.  * *  Game developers, p_layer_s, and ISP's check it out at:   * *                                                         * ************** http://www.eden.com/~springer **************

The way most action games work, you have to have 500ms latency or less.  Which is HALF a second right (serious question   )? The issue is _not_ the amount of latency, the issue is the acceptable error rate in the predictive algorithms at a given latency.  The amount of time that an _object_ spends traveling along a path that the predictive algorithm can handle vs. the amount of time without updates at which the algorithm breaks down is the window of acceptability of the game.   Most of the moving _object_s in Quake are moving in straight lines for periods of time greater than the latency, so the predictive algorithms don't have to work all that hard. When things do move faster than the latency they don't move that far, so the algorithms are able to keep things close enough .  My guess is as much as 10% over 500ms and nobody will complain.  By 1000ms, things can change position far more than 10%, and the algorithms fail, and the game is a mess. In a game like air hockey, the puck is also traveling in a straight line, but for periods of time _shorter_ than the latency of 500ms, so a predictive algorithm for air hockey would have a 100% error rate at this latency. My guess is that to keep the error rate below 10% you'd need a latency close to 50ms, or one heck of a cool predictive algorithm Mike