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
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
