let's talk about network then

[Nigo]

apart from technical details, I think the main discussion really is about what kind of data should the server and the clients exchange, in order to make the cars... kinda move :lol: . Even if it depends of Vamos, I suppose it would be very interesting to ask other sim-racers about that, in the RSC forum or something. I mean, some of them have a very good idea how modern simulations (rFactor, Netkar Pro, you name it) are set up, while some others worked on similar projects

in the meantime, joe or thelusiv, could you sketch me what we can expect from Vamos ? if I got it right, Vamos takes care about all the physics, from the control inputs to the position of the car on the track. But still we can move objects apart from any physical constraints... right ? did we already test if and how Vamos can manage collisions ?

[thelusiv]

Right now Vamos has never been used to do car/car collisions. It does indeed take care of the physics, well most of them anyway, I think there's some collision code outside of Vamos. It does however handle all the car physics and driving itself.

[Nigo]

ok and would it be hard to make Vamos take care about the collision detection in the actual multiplayer code ?

[joevenzon]

Vamos doesn't do any collision detection, just collision response. I wrote some collision detection code, but it's not as good as the dedicated collision detection libraries available (but perhaps could be tweaked to be better).

[cotharyus]

From a personal standpoint, short of making the network code *work* (ok, it may work, but it didn't the only time I tried it) there are three main things that need to be done:

1) Multiple starting possitions. This requires work on the track editor.
2) Collisions.
3) More than two players. This means a way to display lap times correctly for all of the players as well.

[thelusiv]

The AI system needs all those things as well. Thus I think those 3 things should move up in developmental importance.

[cotharyus]

I agree. Honestly, I'd be more than happy to help, as I've stated, however, currently when working with the code here, I've spent a lot more time looking at things and learning than I have changing things. My dirty little secret is, all the programing I've done in the past....none of it has been Object Oriented, and me, being me, prefer to understand how and why these things work the way they do rather than just guessing that I can change X without really being sure why it produces the desired result. So honestly, don't expect to see any great amount of code production out of me any time real soon, but do expect to keep seeing me do what I can.

[Nigo]

I'm back :wink:

could someone give us a tight explanation how the actual system works (in the code) ?

* where is the joystick input sent to the network layer ?
* where is it received and sent to the physical engine ?

thanks :wink:

[cotharyus]

Nigo, my understanding of the way the network code works currently, is that essentially, a replay of each client is sent to the other client. Literally you are driving in your opponent's replay, to the extent that contact between the two cars on track is not even possible.

[Nigo]

ok. But since I don't know how the replay works, it's not telling me much :lol:
my question was were exactly in the code is the multiplayer code plugged in

Vamos doesn't do any collision detection, just collision response

what is the difference ? does it mean that it handles the collision itself and doesn't say anything about it ?

[joevenzon]

Vamos doesn't do any collision detection, just collision response

What I meant there was that Vamos doesn't detect collisions, but it does handle the forces applied to cars, which happens as a result of a collision (after you detect it and compute what the force should be).

where is the joystick input sent to the network layer ?

This happens in vamosworld.cc on line 1697 of R1475 with the following:

Code:

multiplay.AddRecord(dofunction, dovalue, state);

where is it received and sent to the physical engine ?

This happens in vamosworld.cc on line 1037 of R1475 with the following:

Code:

DoOp(GetCar(CONT_PLAYERREMOTE), curfunc.func_name, curfunc.newval, 0.0, false, timefactor, fps);

In addition, the current multiplayer code also sends/receives car state updates every second to make sure the car is put in the right spot in case packets are dropped. This happens in vamosworld.cc as well. If you are interested I can show you where those are, too.

[Nigo]

In addition, the current multiplayer code also sends/receives car state updates every second to make sure the car is put in the right spot in case packets are dropped. This happens in vamosworld.cc as well

good to know, that's what we talked about in the mailing list some time ago about "hybrid solutions"

[Nigo]

ok this is my proposition as a NETWORK (not a multiplayer) layer

simple client / (dedicated) server architecture (of course several clients/server)

when the client connects, it sends it's (estimated) download bandwidth (which will be further negociated at runtime according to the capacity of the server, the number of clients, their ping and so on)

X times a second the clients send their position or controller inputs or whatever the server needs to know (multiplayer's layer job)

X times a second the server computes for each client what is the best things for the client to know at the time, according to it's bandwidth (for example, the closest cars around the client), puts it in a packet and sends it

the clients receive this packet and update the states of the other players, and so does the server

and we're happy



---> the idea is not to overload the client's Internet connection no matter what it is, which of course shouldn't happen often nowadays but is really annoying for all players when it happens (the Christmas Tree syndrom :lol: )

I already implemented something somewhat similar for another project, so it shouldn't be too hard

I'm looking forward to read your comments

[thelusiv]

That sounds like a good system. We also need more ideas for multiplayer system, has anybody got good concrete ideas on how that should be set up?

[joevenzon]

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.