Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Multiplayer Flight-sim Network Strategy  (Read 1426 times)
0 Members and 1 Guest are viewing this topic.
Offline Mahoney

Junior Newbie




Java games rock!


« Posted 2004-04-23 09:06:41 »

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
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #1 - Posted 2004-04-23 10:33:05 »

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.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Mahoney

Junior Newbie




Java games rock!


« Reply #2 - Posted 2004-04-23 11:13:25 »

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


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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #3 - Posted 2004-04-23 11:26:01 »

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 Smiley.
 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

Offline Mahoney

Junior Newbie




Java games rock!


« Reply #4 - Posted 2004-04-23 11:37:22 »

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*.


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
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

UprightPath (10 views)
2014-09-20 20:14:06

BurntPizza (26 views)
2014-09-19 03:14:18

Dwinin (40 views)
2014-09-12 09:08:26

Norakomi (70 views)
2014-09-10 13:57:51

TehJavaDev (95 views)
2014-09-10 06:39:09

Tekkerue (49 views)
2014-09-09 02:24:56

mitcheeb (70 views)
2014-09-08 06:06:29

BurntPizza (52 views)
2014-09-07 01:13:42

Longarmx (39 views)
2014-09-07 01:12:14

Longarmx (45 views)
2014-09-07 01:11:22
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!