why is rfactor

> Huh? Explain please.

The physics seem good to me, but the cars & tracks are about as exciting
as sliced bread and the graphics & sounds are woeful.

As I'm writing client/server netcode for a flight sim right at this
very moment, I can tell you that it is a grade-A bitch.

This is the basic way things work...

You have a whole bunch of clients who are trying to play the same
game-that is, everyone needs to know where everyone else is, what
they're doing, etc. This is called the game state. You designate a
server to be the one 'true' game, and each client sends info on what
they are doing to the server, and the server collates it and sends it
all back out to the clients. As a client, you tell the server what
you're doing, the server tells you what everybody else is doing.

Except... the game state is *huge*, much bigger than even broadband
could possibly cope with as player numbers go up, so the server only
sends 'deltas', it only sends what changed since the last frame. But
each packet might get lost en route, a series of packets might arrive
out of order, so the client has to somehow patch this all together to
get some kind of representation of what's going on.

Also, when you steer left, you don't send your new position/velocity to
the server, you send your control input, and the server does the
physics and stuff, then tells you where you end up. This is because
you might have just steered into another car. Lets say you're driving
alongside somebody else, there's a bit of a gap between you, and you
move towards them just as they move towards you. You (your computer)
thinks there is no crash (because you steer immediately but you don't
see them move for a while due to lag), their computer thinks there is
no crash, but the server sees you *both* steer, decides you crashed and
then has to tell you both (and everybody else) that you just crashed.

Even stranger, because of lag, lets say everyone in the game has a ping
of 100ms to the server. If you steer, the server only finds out about
it 100ms later. If someone else steers, you only find out about it
200ms later. 1/5 of a second. If you're on dialup and your ping is
500ms, you steer and it happens on your screen *half a second* later.
That's unplayable, so your computer doesn't wait for the server, it
does it immediately, assuming that the server will tell you the same
thing anyway. Your computer also predicts what everybody else is up
to. When you finally get an answer from the server, your computer
shifts everybody in the world into their proper place, which makes them
jump, or 'warp'. Of course, they warp to the places they were at when
the server sent the packet, so 100ms ago...

Basically, no client ever sees what's really going on. They are always
incorrect by some margin. If you have a steady broadband connection to
a decent server in a game with good netcode and prediction, you might
not even notice anything except the occasional warp, but you're still
seeing into the past to a certain extent.

As for client replays, the positions of the cars comes from the server,
the client does no physics on them, it just puts them where it's told,
or predicts if it has no data. Client replays are *always* incorrect.
Plus, good netcode will drop distant state info. If the server is
sending out state for 40 cars, that's a lot of data (=bandwidth), so it
will drop cars which are further away, updating them less often, so the
client does more prediction. It's less accurate, but you don't care.
Sometimes they might disappear completely. The only replay which shows
what really happened to everybody is (by design) the server replay.

Why are flight sims better for replays? Because if you're 10 miles
from someone and the server isn't giving you much info, or you have a
lot of lag, then you start to predict, your predictions start to go
wrong, but hey! If they are 10 miles away and their position is 5
metres out of true, can you tell? No. If you're driving alongside
someone at 200mph and their position is 5 metres out, can you tell?
You betcha.

I know this is a bit epic, but I've had my head in this stuff for ages
and I'm only just figuring it out. I'm making my netcode generic, but
I'm starting with a flight sim because it hides the errors ;-) The
biggest problem I've had (thankfully 'solved' now) is, if you're
sending the difference on each frame, what happens if the last packet
didn't arrive? How do you work out the new values if you never had the
old ones?! You could just resend the lot, but that takes *ages*. What
happens if you get packet 6 before packet 5? Arrgh, it's a nightmare!
Thanks for letting me vent! :-)

By the way if anybody wants to know more (details, code), I'm happy to
help out. The internet is great for WinSock tutorials, great to tell
you the problems for games, but thin on solutions... all of my info
comes mainly from Quake, Quake 2 and Freespace 2 source code.

"Nick" > wrote in message
oups.com...
>
> Also, when you steer left, you don't send your new position/velocity to
> the server, you send your control input, and the server does the
> physics and stuff, then tells you where you end up. This is because
> you might have just steered into another car. Lets say you're driving
> alongside somebody else, there's a bit of a gap between you, and you
> move towards them just as they move towards you. You (your computer)
> thinks there is no crash (because you steer immediately but you don't
> see them move for a while due to lag), their computer thinks there is
> no crash, but the server sees you *both* steer, decides you crashed and
> then has to tell you both (and everybody else) that you just crashed.
>

An educated guess tells me that any netcode that starts out using
control input is stuffed. I would think it should start by having 6 pieces
of info, X times per secong. The 6 pieces of info are a 3D point + the
accompanying 3 angles of rotation about the 3 planes. I'd guess that's how
Papy code works. The only problem with Papy code is the crude use of linear
prediction which creates collisions that never actually happened such as
when an inside car warps up into an outsie car. Anyway, anything after these
6 bits of info is just nice - engine rpm and throttle opening/engine volume,
tyre squeal/smoke probably being next in the pecking order. Then maybe you
throw in front wheel turn, etc, etc. The server should be able to have the
option to enable/disable as much of the nice stuff as possible and also
control the freq that data is sent/recieved at. That way available bandwidth
can be used to either maximize field numbers and/or the quality of the multi

I basically disagree with the gist of your post too ie that it's a
nightmare. Papy have had it pretty well sorted since GPL and even b4 that
with Hawai. Any company setting out to do things properly, with the right,
dedicated people, should have this sorted in no time. And it should be the
first thing to be sorted with emphasis on not only the racing, but the
results reporting after races.

> An educated guess tells me that any netcode that starts out using
> control input is stuffed.

Well, that's about all the net games ever made, then. If you let
clients just send their positions, they can hack the game to speed up,
for example. If you don't send the control inputs to the server for it
to verify movement, you've got one almighty cheat-filled game going on.
Ideally, you would want to do as much as possible on the client, but
clients are easy to hack. Look at Counter-Strike-the most common hacks
are aimbots, because the speed you can turn is not restricted, so they
just lock on to the nearest player, calculate the control inputs they
would need to do so and send them back to the server, so the server
can't tell anything bad is going on. You never see teleport hacks or
jump hacks or speed hacks, because the server would notice and disallow
it.

There are a few good articles around, such as "The Internet Sucks: Or,
What I Learned Coding X-Wing vs. TIE Fighter" by Peter Lincroft on
Gamasutra. Another good one is "Instant Replay : Building a Game
Engine with Reproducible Behavior" by Patrick Dickinson. They dovetail
quite nicely. You could also check out the Unreal Networking
Architecture at http://unreal.epicgames.com/Network.htm (look at the
client prediction bit). Or, just check out the source code to, say,
Quake, which is pretty much identical in operation to Quake 2, Quake 3,
Half-Life, Counter-Strike, and all the other games descended from
Quake.

> The 6 pieces of info are a 3D point + the accompanying 3
> angles of rotation about the 3 planes.

Well, you need a velocity vector to even start predicting any kind of
movement, and if you wanted to add any kind of accuracy you'd need an
acceleration vector too. Same for angular velocity and angular
acceleration. So minimum 18 floats, which is 72 bytes per packet.
That, as you say, is without the 'nice' stuff. Add on the IP header
(20 bytes) and UDP header (8 bytes), and it starts getting big. Figure
100 bytes for this 'bare minimum' stuff. If the server is running at
20fps (like Quake 2), and you have 40 cars, each client has to download
100 * 20 * 39 = 78,000 bytes every second from the server. If you're
on 512kbps broadband, that's 512 kiloBITS per second, 64 kiloBYTES per
second. So you physically CANNOT play the game, even on half-a-meg
broadband. God help you if you're on dialup. Remember, this wouldn't
result in lag, that's the delay between sending and receiving data,
this is beyond the physical limit of the amount of data you can receive
over a given timeslice.

> I basically disagree with the gist of your post too ie that it's
> a nightmare. Papy have had it pretty well sorted since
> GPL and even b4 that with Hawai.

LOL! Papy have some of the best netcode around, and as you say, it's
been in development since, well, when was Hawaii? We're talking 8
years minimum. My netcode isn't even 8 weeks old! It is a nightmare
trying to coordinate dozens of people across the world, each with
different pings, packets getting lost, arriving out of order, needing
to severely restrict what you send due to the reasons I've outlined
above, stopping cheating, etc. It isn't a case of ISI netcode being
especially bad, it's Papy netcode being especially good. Remember, ISI
weren't even allowed to do dedicated servers until recently, so they
don't exactly have 8+ years of experience here...

In article . com>,
(Nick) wrote:

> Well, you need a velocity vector to even start predicting
> any kind of movement

If every online object has a buffer that's stored between frames all
you need is X,Y,Z. As you already have a record of the last N
locations you can use that to predict the next movement. Ok it'd use
local CPU cycles, but that's a fair swap and look-up tables ought to
help considerably.

Andrew McP

Lets say that a remote players' data takes 100ms to get to the server,
and it takes another 100ms to get to you, their data is already 200ms
old by the time it gets to you. To go back another 50ms (server rate)
to take an average is just increasing the inaccuracies twofold (older
data, and averaging). Plus, what happens if data from the remote
player gets lost for a bit? You either use some data that's whole
seconds old to get your average, or you have no velocity data at all.
Either way it's pretty meaningless. This is what makes it so hard, you
come up with something that sounds like it works, it works on your LAN,
but as soon as it hits the internet it dies, and more often than not
it's hard to figure out why it died, because you can't replicate the
conditions, and you can't exactly set breakpoints in a multiplayer
game...

As soon as a car goes around a corner, the velocity keeps changing, but
the acceleration remains pretty constant (towards the centre of the
corner), so if you only use velocities, then as soon as you lose data
in a corner, all the cars start going straight (imagine swirling a rock
on a piece of string around your head-losing a packet is like cutting
the string, the rock moves in a straight line with its last known
velocity, now that it has no acceleration acting on it to drag it round
the circle).

On Thu, 11 Aug 2005 21:18 +0100 (BST),
(Andrew MacPherson) wrote:

>In article . com>,
(Nick) wrote:
>
>> Well, you need a velocity vector to even start predicting
>> any kind of movement
>
>If every online object has a buffer that's stored between frames all
>you need is X,Y,Z. As you already have a record of the last N
>locations you can use that to predict the next movement. Ok it'd use
>local CPU cycles, but that's a fair swap and look-up tables ought to
>help considerably.

Actually, you need more than XYZ. You obviously need a time stamp, but
also travel velocity, travel accelaration, turn velocity and turn
accelaration. You also want to send other data aswell, to represent
the car right, like rpm, wheel angle and suspension state.


Cheers!


Remco

In article >,
(Remco Moedt) wrote:

> Actually, you need more than XYZ

Obviously! :-) I was just commenting on the velocity.

Andrew McP

Steve Simpson wrote:
> > Huh? Explain please.
>
> The physics seem good to me, but the cars & tracks are about as exciting
> as sliced bread and the graphics & sounds are woeful.

I've just recently unlocked the LFS S2 alpha and am having a bunch of
fun with it, the physics are actually very good and there is a good
selection of cars with my favourite probably being the open wheel
formula XR.

Have no problem with the tracks and graphics but the sound is perhaps
the weakest part of the game but it doesn't detract hugely from what is
a very well done racing simulator with solid netcode.

The guys behind this deserve a lot of credit.

Jan Verschueren wrote:

> rFactor corrects some of the issues related to the "ISI" multi, like the
> join pauses, but is, in essence, no better than GTR in that department.

Boo.

I haven't messed much with the multi demo, have they at least
implemented a better tire model if not better net, menu (argh, the demo
menus are worse than the old SCGT/F1x menus), and replay code?