GPL and net play - A summary

Network demands in internet GPL: 1) Bandwidth This isn't such a big problem, because there is a relatively small amount of data (megs) that needs to be transferred (I don't know the size of the data block of a standard IP-package, but I guess all that could be wished for would fit in one single package!) 2) Ping times This is the main problem as far as I see it. Ping times can be improved upon by upgrading the internet, but the speed will NEVER get higher than the speed of light. From one side of the world to the other with light speed and back would yield a pingtime of around 100msecs. When you go at 250 kmh, one thenth of a second is a very long time span, a lot can happen during this time, for instance when the cars are really close, on tenth is a huge amount of time, not to mention when to cars crash. In my view an entire crash simulation can start and finish during one tenth of a second! The ping times divide internet play in two: 1) The close area internet play 2) The remote connection internet play These two categories must be treated in different ways, because the ping time stake out the possibilities in a sim... What can and cannot be included in internet play? 1) Close area When ping times get down toward 50 ms or less, it is possible to simulate the cars within reasonable accuracy, even the crashes. The computers still have to "fill in" where packages are lost. This kind of simulation would demand a flawless line with few glitches and delays, typical of the LAN kind of quality... In this kind of connection and simulation we would have: Crashes based on realtime position (in this instance realtime is the virtual realtime) and orientation. When every computer connected to the race gets 20 packages a second this is possible to do. The crashes are computed on the client machines. The simulation of the players car must take place on each connected racers computer. The local computer still has to simulate the car in between the IP-packages, but the cars position won't deviate very much from the "true" position... The computation of the physics of the other cars must take place on the racers own computer. One would not need a absolute clock to do this, in other words, one could do this without using a server... When ping times get high, for instance 1000 or above (not atypical of the wide net connection), one would need a computer to keep track of time; some have fast connection, and some have devastatingly slow connections. A server would send packages to all cars containing the position on track and the absolute time stamp. Then the client computers would have to fill in between so that the cars would behave reasonably sensible. Crash detection is out of the question, so I guess Crash detection needs to be turned off. Otherwise you would crash with a car in a computer generated position and not the true position. The computer would have to move the car onto the true position once in a while (every 2 secs with a bad connection) adjusted with the absolute timestamp. Defending the line (race line that is ;-) is out of the question! This whole lot sums up to one thing: The close area game need not a server and can make crash simulations, the remote connection need a server to supply the absolute timestamp and positions of the car relative to this, and can never have crash simulations... Anyway, that's how I see it! I think the problem is that the developer uses a LAN network to develop the network play, whereas internet is quite different. We need a way to race people on the other side of the planet! This hasn't been pursued at all in my view by the games devloppers! ---Asgeir---

I guess I've always wondered just how much data is being transferred back and forth. I would think (not one of my strongpoints, I know) that transferring the absolute bare minimum of data would be the key. Why not just design the multiplay part of the game "engine" to only send out, say; the location of 4 points in space. The tires. Your end would just recieve the locations of the four corners of the other cars, and from there, each users computer just puts the body of the cars where they're supposed to be. Why would physics info, or anything else as far as that goes, need to be sent. Let each users computer handle all that stuff and effect their own cars as a result. Your computer shouldn't really be concerned about how physics will effect the OTHER cars, just your OWN. All your computer should be involved in is where the other cars are. Dunno...just seems like constantly sending out 4 little coordinates wouldn't be TOO much of a strain. Gritz

> Christer Andersson (& others) have suggested a solution that *should* work > and doesn't require the use of a server. However some of us have doubts as > to whether there is enough of a market for it to divert effort away from > lower ping solutions. Ta da! http://home4.swipnet.se/~w-41236/OnlineRacing.html

[a lot of interesting stuff] I know the following doesn't contradict your explanation (to the contrary, actually), but I'm curious: I have only the faintest of clues of physics, but shouldn't cornering force, ac- and deceleration be closer to 1g for these cars? I mean, there's no downforce and the tires don't have any "gluing" grip to speak of. The only force that keeps the car on the ground is gravity, i.e. 1 g. As soon as the cornering force exceeds 1 g, the car should spin off. Ditto with braking force (the tires will lock and the car will skid) and acceleration (rear tires will spin.) Right? Or am I completely off track again? -- Wolfgang Preiss \ E-mail copies of replies to this posting are welcome.

For many years, the mechanics and engineers indeed believed that there was a limit of 1 G for tires (the tyre couldn't give grip for more than 1 G in either direction), so I think 1 G is very close to the 1967 car grip limit. Much closer than 3G in any case! I have no idea on physics or network theory either, but I do know that there are difficulties involved in engaging drivers from around the world with very different ping times without experiencing lags or low framerate. I'm pretty sure that the packages sent between computers need some kind of a time stamp to place the car on the track... Remember, when your computer receives a package from a computer with ping 1000ms, the position, orientation and rotation in the package was right 1000ms ago. Your computer simply has to know when the position was generated. Then it has to move the car (hopefully continuously and evenly) into a corrected position. I think the key to achieving this remote connection thing is to calculate the physics only on each players computer, and then creating trajectories and car rotation for all the other cars, not bothering thinking about physics! Anyway, the algorithm needed for adjusting the cars after incoming packages must be of some kind of complexity as the computer in a way needs to predict what's going to happen! The computer calculating the cars positions must be entirely integrated with the network part, so that the network can supply the positions when it is up to it, and the computer AI moving smoothly in when the packages doesn't sift in... That might be another problem, the TCP protocol has rules for packages that gets lost (retransmit etc), and what if an old package gets in after a package with younger time stamp? We need a firm to release a serious sim as shareware code. We would then have a fully implemented internet version in 2 months that coped with these things. The game developper has money to take into concern - we, the true enthusiasts, have quite different motives! ---Asgeir---

Quoted text (19 lines)

> [a lot of interesting stuff] > >I don't know the figures for a 67 F1 car's acceleration or deceleration (or > >cornering force for that matter) but I would guestimate that they don't > >exceed about 3g's (i.e. 30 metres / second). > I know the following doesn't contradict your explanation (to the > contrary, actually), but I'm curious: > I have only the faintest of clues of physics, but shouldn't cornering > force, ac- and deceleration be closer to 1g for these cars? I mean, > there's no downforce and the tires don't have any "gluing" grip to > speak of. The only force that keeps the car on the ground is gravity, > i.e. 1 g. As soon as the cornering force exceeds 1 g, the car should > spin off. Ditto with braking force (the tires will lock and the car > will skid) and acceleration (rear tires will spin.) Right? Or am I > completely off track again? > -- > Wolfgang Preiss \ E-mail copies of replies to this posting are welcome.

On Thu, 03 Sep 1998 17:09:48 +0200, "asgeir nes?en" >We need a firm to release a serious sim as shareware code. We would then have a >fully implemented internet version in 2 months that coped with these things. The >game developper has money to take into concern - we, the true enthusiasts, have >quite different motives! <gasp> It's taken two or three years and we still can't edit ICR2 or N2 track files properly, how the heck do you expect a full internet code in two months? Remember that many of the Papyrus guys used to be "us", the 'net enthusiasts, and probably people also from Ubisoft, GP2 team or whatever. I doubt that the desire is lacking. Cheers! John

On Wed, 2 Sep 1998 16:18:57 -0500, "Gritz" No, but the algorithms required to work off those four points would be complex at best. Surely the best way is simply to send the other driver's controller input, and work off that. I imagine the data from an analogue control device would be far greater than four integers, but it seems the only feasable way of doing it.

Quoted text (19 lines)

> I guess I've always wondered just how much data is being >transferred back and forth. > I would think (not one of my strongpoints, I know) that transferring >the absolute bare minimum of data would be the key. > Why not just design the multiplay part of the game "engine" >to only send out, say; the location of 4 points in space. The tires. >Your end would just recieve the locations of the four corners of the >other cars, and from there, each users computer just puts the body >of the cars where they're supposed to be. Why would physics info, >or anything else as far as that goes, need to be sent. Let each users >computer handle all that stuff and effect their own cars as a result. >Your computer shouldn't really be concerned about how physics will >effect the OTHER cars, just your OWN. All your computer should be >involved in is where the other cars are. > Dunno...just seems like constantly sending out 4 little coordinates >wouldn't be TOO much of a strain.

This would fix the problem, if the problem were bandwidth. It's usually not. (id's John Carmack has talked about adding voice comms to the next Quake game. That's the kind of thing that requires a lot of bandwidth, so it won't be practical anytime soon except over LANs or for the lucky minority with really fast net connections.) The problem is latency. The data packets in well-designed network games are already small enough. (Remember that there's a certain minimal amount of packet overhead involved with the TCP protocol, so cutting out a couple of bytes really doesn't matter than much.) But if it takes half a second to get your packet from one player to another, you're going to see visible lag at times. Clever coding can hide some of it, but the only real solution is to throw away analog modems and use lower-latency hardware. (When either the local phone company idiots or the local cable company morons finally get around to offering me a high-speed low-latency connection for less than the price of a car, I will take great pleasure in smashing my analog modem into itty-bitty pieces.) -- spamgard(tm): To email me, put "geek" in your Subject line.

> This would fix the problem, if the problem were bandwidth. It's > usually not. (id's John Carmack has talked about adding voice > comms to the next Quake game. That's the kind of thing that > requires a lot of bandwidth, so it won't be practical anytime > soon except over LANs or for the lucky minority with really > fast net connections.) Server based flight simulators like WarBirds and Air Warrior send game data AND voice data in (AFAIK) 19.2kb modem connections. In WarBirds, the positioning data sent includes 32 other planes. - Matt WB: =para=

Quoted text (11 lines)

> On Thu, 03 Sep 1998 17:09:48 +0200, "asgeir nes?en" > >We need a firm to release a serious sim as shareware code. We would then have a > >fully implemented internet version in 2 months that coped with these things. The > >game developper has money to take into concern - we, the true enthusiasts, have > >quite different motives! > <gasp> It's taken two or three years and we still can't edit ICR2 or > N2 track files properly, how the heck do you expect a full internet > code in two months?

Let me rephrase that: If we had the source code for a serious racing sim, the internet community would develop the sim no end! Think about what people around the world is capable of with reverse engineering! Then think about what they could do with he source code! This is a truth with many facets... If the guys at Ubisoft and the GP2 team used to be "us", they would have quite a different dialogue with the racing sim community (the have or have had next to no communication!)! Papyrus is the only software developing house I know of that maintains a steady communication with the internet community! The fact that GPL will be outstanding and probably a block buster of course displays how fruitful it can be to listen to the many voices!!! The desire to make flawless internet play for a game is there, the only problem is that the developers feel that they wouldn't make money out of it! The motive of making money is totally irrelevant to the internet community, as they would strive for the ultimate net play, and not to make a lot of money! And that is why I say that a shareware source code released in the internet community would create a perfect internet play in two months... ---Asgeir---

Quoted text (9 lines)

>> This would fix the problem, if the problem were bandwidth. It's >> usually not. (id's John Carmack has talked about adding voice >> comms to the next Quake game. That's the kind of thing that >> requires a lot of bandwidth, so it won't be practical anytime >> soon except over LANs or for the lucky minority with really >> fast net connections.) >Server based flight simulators like WarBirds and Air Warrior >send game data AND voice data in (AFAIK) 19.2kb modem connections.

That's pretty impressive. That's over a point-to-point modem connection, not a TCP/IP connection through the Internet that happens to have a modem at one end, right? Neat, but pretty resource-intensive; those games end up being pretty expensive to play, due to the expense of long-distance phone calls and banks of server modems. We can do better over the net, once we get rid of the analog modems at the client end. Which isn't really all that much data. 32 * 3 (x, y, z coords) * say 4 bytes per coord (this depends on the precision of the coordinate data) is only 384 bytes, which fits nicely inside a single typical TCP packet. -- spamgard(tm): To email me, put "geek" in your Subject line.

> >In WarBirds, the positioning data sent includes 32 other planes. > Which isn't really all that much data. 32 * 3 (x, y, z coords) > * say 4 bytes per coord (this depends on the precision of the > coordinate data) is only 384 bytes, which fits nicely inside a > single typical TCP packet. It's more than that. Attitude information (WarBirds is a six degree-of-freedom sim) and acceleration and time tagging info (guessing) for their proprietary 'smoothing' algorithms. And bandwidth is so prescious that to increase callsigns (aiding labels) from 4 to 6 characters they actually took some characters out of the allowed set to enable the increase with no net change in data requirements. - Matt WB: =para=