rec.autos.simulators

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 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

[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.

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---

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

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.

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.

- Matt
WB: =para=

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---

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.

- Matt
WB: =para=