I agree it would be getting a little bit too ambitious, and might just overcomplicate things.

While there is definitely room for experimentation in terms of unlockables and weaponry, we are at the same time sticking to the realistic layout of most fighter aircrafts, namely about two to three different weapons. The unlockables will give you more tonnage to store more weapons viz. ten missiles versus five, to give a rough estimate, and will allow you to gain some skills while dealing with flaws in the aircraft at the same time. For instance, the F22 aircraft may be maneuverable which will help when dogfighting another craft or staying away from SAMs, but the F29 will give you more speed and thus lessen your occasions of running on after burners. I am not permitted at this time to release details of the unlockables in terms of how they will be done, but this information will be made available closer to release.

These are excellent suggestions, but remember that Three-D Velocity is meant to be an air-to-air combat simulation. I have played several games in the past where the developers go more for content and sacrifice quality, and that much content is overwhelming to the average gamer. We have very few bigtime gamers here, and most of us just want something to entertain us now and then. That's not to say that a small game which was worked on for maybe a month should be sold for $20.00 purely for the purposes of getting something out the door, but at the same time it shouldn't be so big where the player spends maybe two hours just reading the documentation before they even start playing the game. Aircraft simulations are a different style of games from the first person shooters, and slamming them both in to one program would complicate things, not necessarily from the programming perspective, since many algorithms can be easily scaled down to fit this type of game, but rather to the gamer with respect to keystrokes, methods, etc. It would be best if we left that up to people who design MOOs and MUDs--where the code base and (at the same time) the player interface are both built to handle these things viz. several MOOs have ground and air combat implemented--rather than reinventing the wheel. This way, those developers who venture to make MOOs and MUDs do not have to do a lot of ground work to get the interfaces going (The default MOO database comes with thread handling built in and ready to use, for instance,) and those of us who do have to do much of the ground work when we use a conventional language such as .NET or C can be satisfied when one perspective works flawlessly.
Munawar

The mailing list is now available. You can subscribe by visiting www.bpcprograms.com and following the instructions given on the main page.
Munawar