let's talk about network then

[stenyak]

Sounds good to me.

For a multiplayer system, I've been thinking about this, and I read about how this sort of thing is done in FPS games (specifically Unreal engine games). The quake 3 source is available also, but I haven't looked at it yet. My idea is basically that the "official" copy of the game world is on the server, and everyone's individual game sends their inputs to the server for processing, with timestamps indicating when they sent them. At the same time, though, the client is also processing the inputs, anticipating that the server will process them similarly. The server will send periodic state updates to the clients with timestamps, and if all went well, those states should agree with whatever the client's copy computed (if not there will be jumps, but that should only occur if there is some packet loss). The client rewinds the world back to whatever state the server sent and re-applies the input to get the client back up to the present.

Anyway, I'm still thinking about all of this, and I may be making it overly complex... I'm going to use my FPS game as a test-bed for this sort of technology and see what works out there. It should be easy to apply this back to VDrift at that point.

Unfortunately, in a car simulator, it's not easy at all to "rewind" to certain world state. If it is now (very simple world state), it surely won't be in the future (dynamic objetcs lying around, multiple cars...).

Also, don't forget that FPS physics are so simple that you could probably compute them at 10000x realtime, while in a car sim you may be able to compute it at 10x or so. Divide that by the number of cars you want in a multiplayer race, and you realize the quake method is not feasible in a car sim.
(the numbers are made up, but you get the idea).

Finally, keep in mind that quake physics do not require much "control", in the sense that you can stop or gain max speed in a split second. In a car sim, if you have your client have updated positions/speeds whenever the server wants, you may easily end up losing control of the car because you're suddenly in a 90º drift, while you expected to be gripping nicely through the corner apex.

All of this means that, for a real time multiplayer car race, at the moment the best solution is to send computed physics data (position, rotation, speed, etc..) rather than input.
Still, you can send (or derive) input data (steering wheel angle, for example), so that you see the other cars cockpit elements moving. Or in order to show the front wheels steering properly (it might be asier to send one steeering wheel value, than to send 4 wheels "toe" rotation; same for gas pedal vs. speeds rotational speed (for smoke/skidmarks purposes)).