rec.autos.simulators

I really hope I got your attention with that subject, cause to me you're truly
envious. I would love to take part in the development of a racing sim, as a
developer, that is :o). Well this aint a job application, but rather an attempt
to influence the development of future racing sims.

The subject is "How to make it almost impossible to cheat in a racing sim". GP2
was very close, but didn't reach all the way. What they did, was to resimulate
saved laps. In order to do this they had to save all the driver's input, the car
setup and all helps used in the replay file. This is the way to do it :o), but
it's not enough to avoid cheating. Sooner of later there will be editors popping
up on the internet, which can change for example tyre type, and it wont be
noticable when resimulating the replay. My solution to this is to add a function
to the racing sim where you can view all the data in a replay file; Car setup,
BHP, grip, weight, tyre type, helps used, etc, etc. This would make it
impossible to cheat with an editor, right :o)?

For multiplayer races, allow at least the drivers fastest lap to be saved as a
replay.

Where GP2 also failed or didn't have the budget :o), is their choice of not
saving timestamps for the driver inputs, instead they choosed to go with a
constant frame rate. I believe much of the calculations in a racing sim is done
with differential equations. I'm also guessing that when you choose a certain
frame rate in GP2 the differential equations used is optimized for that frame
rate. What I'm trying to explain is why GP2 allowed slow motion driving.
Constant frame rate is perhaps a better solution for realism, as long as you
stay below 100% processor occupancy, but why not do this instead? Add a byte to
every driver input. Let that byte tell the simulator which frame rate is to be
used for the next frame. Measure the time it took for that frame to be produced
(GP2 already does this with it's processor occupancy function). If it took
longer time than expected - lower the frame rate. If it took a shorter time than
expected, say between 80% and 100% - keep the frame rate, but if it was lower
than 80% of expected frame rate - increase the frame rate.

With these two solution it would be impossible to cheat with an editor and very,
very hard to cheat by driving in slow motion, right :o)?

Ohh, and a "multiplayer with ghost cars" option, would also be nice :o), or am I
pushing it now :o)?

/Christer Andersson
http://www.racesimcentral.net/
competition
http://www.racesimcentral.net/~w-41236/ - Home page with GP2 hotlaps and F1RS
ghostlaps, setups included

The game itself, is that the simulation part? In that case the clients, our machines,
gets the car positions from the dedicated server, and draws them in the 3D world, then
sends back our driver input to the server. For 30 frames per second we would need
pings below 33 ms??? Say the dedicated server would simulate 22 human cars. Say in a
normal simulation, to produce one frame 1/3 of the time is used to simulate your car,
1/3 is used to do the AI and the last 1/3 is used to calculate and draw the graphics.
Then you would need about a 22 * 1/3 * P200 as a server to get a P200 physics engine
per human player, that is a Pentium 1400 MHz??? So if you mean that the simulation
part should run on a dedicated server we need a Pentium 1400 and pings below 33 ms???

/Christer Andersson

Also note that "ping times" reflect only the overhead of replying to
an ICMP packet, which is done at a fairly low level in the IP stack,
whereas car position updates from control inputs would almost
certainly be a higher latency computational path. :-)

---Jim

My WarBird connections tonight gave around 300ms ping time.
Racing would seem to be a bit different, but any game
will have to live within these limits. I'm sure someone
will figure out how best to deal with this limitation ;)

- Matt
WarBirds: =para=
WarBirds Training Staff

/Christer Andersson

1. Collect driver input.
2. Calculate the new car position (here we need as many iterations in the
differential equations as possible).
3. Calculate (only needed for AI cars) the other cars position.
4. Calculate and draw the frame.
5. Tell the 3Dfx card to show the frame :o).

In step 3 and 4 we cant collect driver inputs, so there's really no meaning in
collecting the driver input more than once per frame.

I actually looked up ICMP :o). I guess with pings you can get a feel for which
bandwidth you have between you and the other driver, since it's always 32 bytes
sent back and forth in a ping. Say you have a ping of 300 ms, then it took 150
ms for 32 bytes, which gives us a bandwidth of about 7 * 250 bits per second,
about 2kbit/s. I guess a 28.8 modem will do, with the current speed of internet
:o).

/Christer Andersson

You need to be fast enough to be much quicker than
the frequencies of the dynamics (suspension, for instance)
you are interested in modeling.
A factor of 10 is a general rule of thumb.
For landing gear in my day job, we integrate at 1000 Hz
for real time sims, and would prefer 5000 ;)

One problem that seems to hit both PC flying and racing
sims is that the pilots/drivers can input in the 10 Hz
range and cause problems by moving the controllers
faster than the vehicles themselves can respond ;)
(causing an oscillation)

- Matt

/Christer Andersson, dont know much, just guessing :o)

On Sat, 21 Feb 1998 14:13:02 +0100, Christer Andersson

Cheers!
John

You're stuck the the MicroProse mindset here. There's no reason that
physics calculations and frame updates should be tied together. It's
perfectly reasonable for the physics to be calculated on a constant
timebase and the graphics engine just draws the results of the latest
physics calculations to be completed at the time one begins to draw a
new frame. This permits the physics rate to be done at a constant rate
in wall-clock time, but a varying rate in frame-count time.

A different (and I'd argue better) method is (very roughly):

Physics thread: (timer driven)
P1. Get control inputs
P2. Calculate new player and AI car positions and collisions with each
other and static objects.
P3. Copy this snapshot and timestamp into a shared memory area.
P4. Goto P1

Graphics thread: (running anytime the physics thread isn't)
G1. Lock and copy the latest world snapshot (from step P3) to a
scratch area in your thread space.
G2. Draw the frame and display it.
G3. Goto G1.

Of course, I have an historical bias in preferring the multiple thread
model.

Unless it's not. The ping protocol supports varying size ping
packets. (This is a source of numerous entries on the "50 ways to
crash Win95 without knowing jack about computers" list.)

Computing bandwidth in the absence of considering latency is not
especially relevant for ***. Latency is the real limiting factor
today. (After all, I could ship you a huge box of CD-Rs, at >660MB
each every day. The bandwidth of this "connection" might be enormous,
but it doesn't have low enough latency to support a racing game. :-) )

Additionally, even a single average latency number isn't everything. %
packet loss and variability of latency on individual packets is
meaningful.

For the purposes of the originating (or, at least an earlier) post,
it's not technically possible to get a good experience for the user by
running the simulation engine on the server. (This would go a long way
to preventing cheating, but it's technically infeasible.)

---Jim

This is (roughly) how it was done in the old Atari arcade games, Hard
Drivin' and Race Drivin'.  Since this was ~10 years ago, there was no cheap
way to do it all with one processor, it was a multi-processor machine and
there were separate processors calculating the car model (now called
physics model), graphics, force feedback, sound, game play, etc...  The
various processors communicated through shared memory -- and all ran as
fast as they could be clocked (reliably).  Road & Track actually did an
article that showed a crude block diagram of the system...

From where (or when)?

So true for something like driving simulation, where there is a (slow)
human in the loop -- any significant lags not part of the real system may
cause the whole thing to be unstable.

-- Doug

                Milliken Research Associates Inc.

I agree in that a threaded version would be more beautiful :o), but I
dont think it's the way to go as long as the client machines (Pentium,
K6, M2) only have one processor. There is to much overhead switching
between the threads instead of using that power to have a little better
physics model, IMO.

I guess your history is not in x86 processors, since you have a bias to multiple
threads :o)?

But you get the latency with pings, dont you :o)? If you get a ping of
300 ms, you know the latency is lower than 300 ms. If we take your
example and you where pinging me with the help of CD-R's, then you would
get them back a couple of days later. We're not talking milli seconds
any longer, are we :o).

Not if you send every packet with a time stamp, which really is needed
if you want to allow 3000 ms pings. The timestamp could just
be 2 bytes, which resets every time it reaches 65536 milli seconds.

If the simulation are done on the clients and the multiplayer game saved
the time of all the drivers fastest lap and you where forced to save
your fastest lap, and the saving of the lap was in the format of driver
inputs and simulation settings, and there was a function in the
simulator where you could view the simulator settings for a saved lap.
Then the lap can be resimulated on every client, producing the same lap
time on every client and the data used for the simulation could be
viewed on every client. Then the only way to cheat is to have another
better driver to drive for you, am I right or am I right :o)?

/Christer

Jim,

Then why is Papy using this model for GPL? According to articles I've
read.

Jeff

--Jim