From: Lorne M. <spa...@ho...> - 2007-05-10 17:36:11
|
I recall reading a document some time ago about re-structuring FG into a more robust client / server architecture: http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.p df You might want to give that a read. it's fairly similar to your "Suggested Solution #1" I think. That solution would also be the best for cheating-prevention (not like it means much though when the client purposefully exposes interfaces for writing UAVs or *cough* aim-bots, haha). But at least it would preclude a WWI bi-plane from doing Mach 8. Lorne _____ From: fli...@li... [mailto:fli...@li...] On Behalf Of James Palmer Sent: Thursday, May 10, 2007 7:58 AM To: fli...@li... Subject: [Flightgear-devel] More ideas on dogfighting I have a better idea on what is involved now for adding dogfighting to FG. Thanks to all who have given me input,.. Keep it coming. After talking with alot of you, here are the additional and more finely tuned ideas that I have. Dogfight On/Off Option: (Thanks to Vivian) -I will include an option for turning off dogfighting and still allowing multi player. As someone pointed out we don't want some kid shooting down everyone over San Fransisco while everyone else is doing serious flying. The option will not turn off AI-Aircraft, as you still want to see other players (otherwise you'd play single player on the local machine), it will just ignore all submodel information from the server ( i.e. guns and missiles). This option should probably be turned Off by default. Server Coordination: Some discussion on how to coordinate AI-Ballistic and AI-missile (yet to be created) with players was had yesterday. Basic Problem: Jet A is travelling at mach 2 and he has a slow Internet connection (200ms latency). Jet B is approaching him from a direct right angle (i.e. Jet A will exactly cross Jet B's gun sight very shortly) When Jet A's pilot realizes that he is about to be toast, he makes a hard turn, but at mach 2 he will travel approximately 450 feet before his slow packet reaches the server. This is a very simplified example, but it gets the point across. I need to figure out the best way to minimize the effects of Jet A's latency and determine the best method of position coordination between players. Suggested Solution #1 - DFMP is server driven and server coordinated: The dogfighting MP (DFMP) should be server driven (thanks to Lethe for the insight into this direction) and server coordinated. Clients should send user input information to the server and let the server calculate where the player is on the earth and inform the player of it. The server would also be responsible for determining whether a collision has occured. This is the approach taken by many of todays MP Internet games. Changes for this approach include : 1-an overhaul of the MP protocol. Currently users send a UDP message on their position to the server which then updates the other players AI-Aircraft models (I think I understand this correctly,.. if not someone please chime in). Clients would now have to send user input information to the server. The server would have to model the FDM of the craft they are using, determine its new position and then update the client and other DFMP players on the clients new location. These calculations and updates would happen for every DFMP there is on the server. 2 - a change in the client side of MP protocol to send only user input, and to accept new positions from the server that is driving. 3 - the server would need additional collision detection ("hit-box" relative to the size of the craft flown) Suggested Solution #2 - DFMP is client driven and server coordinated: The DFMP should be client driven and server coordinated. Clients would be responsible for calculating their own FDM and position on the earth. Each client would send its position information to the server, which would maintain a list of aircraft and AI positions. The server would only be responsible for passing position information to all players and determining whether a collision has occurred. To further reduce the effects of latency, vector extrapolation may be used to determine a player's position when no new information packet has arrived. Changes for this approach include : 1- Adding AI objects to the MP protocol so that gun and missile information can be transferred. 2 - the server would need additional collision detection ("hit-box" relative to the size of the craft flown) Cutting down the information needed for DFMP I've been trying to think of some methods to cut down the network traffic required, by allowing the client to do some of the heavy lifting. Here are some ideas I have. - Ballistic Objects would be initiated but not updated by sender (i.e. bullet from a gun). Jet A shoots a bullet at Jet B. Jet A sends a BO initiation packet to the server. It has all of the property information that is normally associated with it (initial position, speed, weight etc). Server sends a copy of the BO packet to Jet B. Jet B receives the BO packet and creates his own AI-ballistic object with the same properties. Jet B will now keep track of the BO for his own visual purposes only. The server will also create a BO to track for position information ( i.e. collision detection). Jet B will not determine if he is hit, the server will tell him, but Jet B will create his own visual for the bullet. This can further be enhanced by modifying the BO to have a "time created" property describing the UTC time it was created. This will allow Jet B and the server to adjust the BO for the latency in the network and initiate it in the correct position. (initial position plus distance traveled in packet latency period) - A similar approach could be used for the "dumb rocket" type of missile. I still have some thinking to do for guided type of missiles. (Any suggestions are welcome here) The only other missile type I can image accurately modeling right now is a "fly by wire" type, where the user could hit a button to switch the joystick control to the missile. Problems with this approach: Since the protocol is UDP, if the BO initiation packet is lost, then either the server or Jet B may never know of the object. (depending on which packet is lost) Switching to TCP would solve this, but that opens up a can of worms I'd rather not deal with. (anyone want to help out on this?) A nti-cheating: Some brought up that cheating could be a concern. With OSS I don't think we can prevent cheating altogether, but there are a few things that I thought of to cut down on it. Setting limits on player capability in the server. Things like setting boundaries on BO properties ( i.e. cant have bullets with an initial velocity of mach 100). Having the server count the number of bullets and missiles used so that players don't get infinite of either. Perhaps even having the server check the player vector to ensure that vector changes don't exceed the crafts capability. This area is not my main focus right now. For the time being I plan to trust FG players and hope that anyone willing to put the effort to modify code will contribute to the project rather than use their time and skills for cheating. There will be more to come in the following weeks and months. Thanks to all who have given me input so far. It is greatly appreciated. -- James Palmer |