Forums

isn'it more or less the way it works actually ?
do they send controller inputs in FPS games ?

I think (in Unreal anyway) they send the results of player actions (function calls)... but it's very similar.

ok
for now I'll write the network code unplugged from vdrift
I'll publish the interfaces before the end of the week, so we can discuss the requirements
let me know when the multiplayer layer is going forward

I built the protocol yesterday on top of ENet, and it looks strong enough. For now it doesn't contain the QoS features I talked about but I think it's would be much more clever to first plug it as it is on vDrift (which I can't do myself since I don't understand the multiplayer part), and then afterwards to implement the QoS

the only thing to remember is that the data you send need to be classes of primitives (no pointer or references... or you'll need to serialize it before and reconstruct it after), kinda obvious

I havn't write the interface yet but it's almost straigforward
I'll put it on the web tonight or tomorrow

This sounds good Nigo, I'd really like to see the code. How did you use Enet - link against it or compile it with your program?

Don't we already have some serialization going on? I'll have to look into this.

Thanks for your effort. I'm interested to play around with this.

here it is http://nigoni60.perso.cegetel.net/testEnet2.tar.gz
it's still messy but the idea is there. I have a big headache so I'll improve it another day
the main.cpp is just an example how to use it

about enet : I built it as a static lib under Solaris and Windows, it can't be easier

Well I compiled enet and installed it, then I tried compiling your program, but I got this:
I can't figure out what's causing this. I looked at the code and it looks fine...

I compiled it on gcc 3.4.6 and it was fine, but anyway...

it's saying you can't define a variable in a switch's case, so just define it before the switch

before the switch :
Packet::NewClientConnected* ncc;

in the switch :
ncc = ...

Ah, silly I didn't think of that, but the error message is not all that clear. I'm using gcc 4.1.2. I get similar errors in Server.cpp. It wouldn't link until I removed -lsocket because I think the sockets API might be integrated into my libc.

The program runs fine using localhost as server. I'll play around with it more and let you know how it goes...

think about trying with several clients

PS : I cleaned it up and improved it a bit
keep your Makefile and update the rest

up
if you need help in anything let me know :wink:

joevenzon Wrote: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)).

I agree. Update the inputs 20 times a second would have terrible results (especially in drift, that would be very funny though :lol: )

I say 20 because it's a usual frequency. Sniffing a GPL game I found out it's about 15

Back to networking...the discussion got side-tracked for a page or so, thanks Nigo for pointing that out, I've split those posts into a new thread which is here: http://vdrift.net/Forum/viewtopic.php?t=539