Multiplayer Flight-sim Network Strategy

Networking & Multiplayer
#1

OK, just read the UDP v TCP debate, along with the X-Wing v TIE article and Cormack’s Q3 strategy.

I’d like to run the following strategy for a multiplayer WWI flight-sim past you. For now, can we assume that only the network strategy is under review, not the overall design of the sim? I’ll explain the design of the sim under 1), and my current network thinking under 2).

  1. The sim will have a client server architecture. Each client will send their control input to the server (position of joystick, throttle etc), and the server will work out what happened as a result, and will then send appropriate game state (position, heading, speed, damage state etc for all planes including the client’s in a 3 mile radius of the client) to each client. Obviously some form of prediction and merging will be necessary client side so that it’s not jerking all over the shop.

  2. At present I’m thinking of using Cormack’s strategy; collecting the input states each with a timestamp and building UDP packets made up of all the input states since the state of the last UDP packet that was acknowledged by the server. Server discards any packets it receives that were sent earlier than the last received packet.

And in terms of the packets the server is sending to the client, again order doesn’t matter - the client works form the chronologically latest packet it gets, and ignores any ones with earlier IDs that it receives later than this.

Obviously there’s a lot of thought required to give the client a meaningful and smooth experience, but as a general approach does it sound at least sensible?

Rob

#2

Does not make any sense to me.

1.) Sucks for several reasons. First, you have to decide WHEN to send joystick info to the server. Todays joysticks are highresolution devices so you have to consider a new value each frame. Additionally a physical flight model is (or should be) very sensible on input, so you need to have exact info on the server -> push out control info with max. rate. Thats BAD for the other information that has to be transmitted the same time.

A physical flight model often is non-linear. Mean it is HIGHLY sensible to lag! And such a remote control introduces lag that will make a plane hard to control.

And of cource, when sending control information, you want position information back. Not a gamestate with redundant data that has another updating scheme than the positional data.

Perfomance-wise you may run into difficulties bc. flightmodel computations for 100 planes on a per-frame rate may easily blow any server.

2.) Worse. Both approaches require to run the net at maximum capacity, thereby maximizing lag and packetloss.

Flight sims have smooth, physically motivated motion. This does not compare to ad-hoc, Q3 like motion.

Physics motion can be exploited in network gaming bc. it cannot change abrupt … so it is quite easy to anticipate and to smooth.

Maybe you like to take a look at the FlyingGuns approach, which creates smooth, believable motion with small network load and a high latency-tolerance.

#3

OK, may have misphrased it - what I’m primarily interested in at the moment is that if we assume that 1) is not up for debate, is 2) the best network strategy to meet that need? You begin by rejecting 1), which may well be the right thing to do, but begs the original question.

As you say:

[quote]a physical flight model is (or should be) very sensible on input
[/quote]
which perhaps means that the info that needs to be transmitted from client to server, at least, is similar to Q3 - whether a joystick is hard right or hard left can change in an instant, and it needs to get there ASAP?

Just playing with ideas in the course of learning,

Rob

#4

Hi
Hard left, or hard right isn’t the issue, the issue is that to fly properly in flight sims (single player here) you need an fps of at least 15, to fly helo’s you need 25 (this is based on my own experience with MSFS over the years), any less than that and it’s not pilot proficiency, but luck that controls the outcome of a landing. To run that on a client server bases, the client needs to send controller positions to the server 25 times a second, and get a response with the update position, every 1/25 of a second, that means it can’t miss any, and it can’t lag ever. An alternative solution (I’ve not looked at the flying guns, but this is what I have seen with my own code) is to do the updates locally at what ever speed you can, then send thoes updates to the server, the server can then check if it is posible based on known quantities for that type of aircraft to do what it’s just done (if you are worried about cheats), and then relay that information on. This can be done as low as 2 frames a second and still be playable, and everyone expects at least some lag from remote clients, but not their own. Obviously clients with a faster connection can get updates faster if you let them. You can then do this all using TCP rather than UDP, which means you only send/recieve useful data, saving on bandwidth. I believe that was covered in the TCP v.s. UDP thread at one point. Saving bandwidth at the cost of latency might be worth it for slowdem users, as high bandwidth will increase their latency anyway as the packets get queued in various places. Or thats my understanding (roughly, not the true detail). blah^3 will no doubt correct me if I’m wrong :).
2 updates a second is what I was working on so that 30+ aircraft can exist in the same visible space and still be played over a modem. If you only expect 15, then you can go to 4 updates. Again, this is just my own observations from my own code.

HTH

Endolf

#5

Yes - I think that’s why I was suggesting that if the overall approach (sending controller state to the server) is set in stone, the Carmack network strategy might be necessary in order to get anywhere near implementing it.

[quote]the client needs to send controller positions to the server 25 times a second, and get a response with the update position, every 1/25 of a second, that means it can’t miss any, and it can’t lag ever.
[/quote]
That would be true if the client was doing no prediction - but I presumed that the client would also be working out the consequences of the controller position for instant response on screen, and then comparing the results with the server’s version and merging as appropriate.

Like I say, just playing with ideas. Incidentally, my experience of Red Baron 3D and Il-2 is that you really want a consistent 30fps for decent results, and that a ping of over 100 is undesirable; you can play them at a ping of 300 but it’s not pleasant. Which suggests they are updating info more than 2 times a second, though I don’t know what strategy they are using. Can find out though, as I believe RB3D used the Torque engine which has now been made available for open source.

Rob