Long Term Goals

Note: this is not an official collection of goals, rather it is simply assembled from various mailing list discussions and thus reflects mainly personal goals of individual contributors, rather than the official set of goals of the FlightGear project as a whole. However, given that FlightGear is being developed by these very contributors, this should be a fairly representative list of long term goals.

As someone new coming to FG, it's pretty tricky to get a handle on what's going on, what's being worked on, what needs fixed and so on. Of course this is an issue for all software projects, and there's different solutions depending on the nature of the team, how many active contributors exist and so on. — James Turner (Jul 28th, 2008). [Flightgear-devel] Project tracking. (powered by Instant-Cquotes)

There used to be some kind of mission statement, e.g. see: http://www.flightgear.org/proposal-3.0.1 (from 1998). And then there's a more recent wiki article trying to cover the same thing based on community activity: Long_Term_Goals The most representative long-term list of goals is probably any core developer page listing their own goals: Developer Plans — Hooray (Tue Jan 13). Re: 5-10 Year Goals?. (powered by Instant-Cquotes)

These days, many core development efforts have a lifetime of at least 5 years given the low number of active core developers, as well as the degree of required architectural large-scale changes - for instance, to name just a few ongoing efforts: increasingly adopting OSG (since early 2006, still in progress) support reset/re-init, for switching aircraft at run-time, without requiring existing/restarting fgfs (equally, people want to be able to save/load flights to continue a flight at a later time) increasing focus on proficiency/flight instruction scenarios (e.g. by being able to replay/continue an approach reliably) allowing aircraft/scenery to be downloaded/installed and managed from inside the simulator better use of multi-core systems supporting distributed setups with multiple windows/viewers and multiple graphics cards adopting HLA/RTI, especially for distributed setups, but also for better leveraging multi-core systems and an improved multiplayer experience making more and more subsystems configurable and entirely optional, e.g. for better troubleshooting/regression testing For the past few years, the Canvas subsystems has been used to re-implement MFD functionality without requiring core development modernizing the GUI procedurally populated scenery ("autogen") is becoming increasingly relevant, i.e. we're seeing a lot of activity in anything involving OSM and procedural scenery creation equally, people want to keep on improving the scenery engine and the TerraGear compilation suite to support more and more visibility, while also providing good performance — Hooray (Tue Jan 13). Re: 5-10 Year . (powered by Instant-Cquotes)

General

• multi platform flight simulator: support as many platforms as possible
• provide an open framework for educational and scientific projects
• uncomplicated installation/deinstallation
• stable flight simulation platform
• framework for research related efforts (i.e. proof of concept avionics)
• provide a compelling and free alternative to commercial flight simulator products
• highly available (i.e. provide binaries for all supported platforms)
• provide fully interactive tutorials and courses

Development & Contributions

• encourage contributions and community involvement
• non-obfuscated architecture: expose all internals to users via public, well-documented interfaces
• framework-centric development philosophy and -model

Realism

• worldwide scenery coverage - available, look for "World Scenery"
• appropriate realism
• wide support for all sorts of aircraft (airplanes, helicopters, unpowered flight)
• realistic avionics modeling
• realistic weather modeling
• realistic IFR simulator
• realistic VFR simulator
• procedure trainer
• realistic visual and aural effects where appropriate
• realistic and complete systems modeling, including failure modeling

Features

• multiplayer support Mutiplayer
  • Multiple players has been implemented.
  • Multiple pilots/passengers per plane is currently in development
• support for multi-core architectures (SMP)
• support for networked distribution
• strive for eligibility for FAA PCATD/FTD certification
• provide support for use with virtual ATC facilities
• provide support for AI Traffic to populate the virtual world with aircraft

Graphics

• provide support for multiple output windows per instance
• multi-head/monitor support - for multiple screens per instance
• multi-accelerator support - for multiple 3D cards per running instance

Hardware

• support lower-end hardware
• support a wide range of input hardware (joysticks, yokes, pedals)
• support various makes of 3D accelerator cards

Performance

• appropriate startup and runtime performance
• provide playable framerates (>=20fps) in 1024x768 on older systems

Footprint

• appropriate download size
• appropriate memory footprint, resource consumption
• minimum amount of external dependencies (Deboostify !)
• reasonable build times

Technical

• conveniently extensible, even for non-programmers
• highly configurable and customizable
• fully runtime configurable [1]
• backwards compatible

Code Base

• support as many C++ compilers and -versions as possible
• provide current project files for as many compilers/IDEs as possible
• modular design and architecture
• comprehensible source code
• tight code base
• quality code base
• well documented and commented

...