20,741
edits
Implementing new features for FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Implementing new features for FlightGear (view source)
Revision as of 20:00, 17 May 2014
, 17 May 2014→Some (unpleasant) truths up front
| Line 34: | Line 34: | ||
# Developers are free to do what they want: <br/> This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily. | # Developers are free to do what they want: <br/> This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily. | ||
# Flightgear development tends to be inclusive: <br/> There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers). | # Flightgear development tends to be inclusive: <br/> There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers). | ||
Obviously, we would all like to have a flight simulator that provides for an experience that doesn't involve a steep learning curve. | |||
Often, people tend to compare usability (or lack thereof) to some great GUI tools available in proprietary simulators. Historically, however, we've learned that implementing such extremely high level end user features doesn't scale all that well. We've seen several years of time spent developing high-level features in C++ space that got quickly re-implented, or even replaced, once middleware developers had sufficient tools at their disposal to customize the simulator through XML and scripting. Besides, it generally works better for us to reuse existing tools whenever possible - no matter if it's Blender for 3D modeling, Inkscape for vector graphics, GIMP for texturing, or even just a conventional text editor for XML/script editing. | |||
What this means is that developing high-level end-user features through core development often doesn't scale as well as using existing tools, customize those or just exposing the infrastructure required to allow middleware developers to implement certain features directly through existing FlightGear extension mechanisms. | |||
Which is a win/win for both sides, because core developers get to do core development, freeing them from having to develop end-user features, while middleware developers get to evaluate end-user requests and implement popular requests. | |||
== Test the waters == | == Test the waters == | ||