573
edits
Implementing new features for FlightGear: Difference between revisions
Jump to navigation
Jump to search
Implementing new features for FlightGear (view source)
Revision as of 18:11, 30 May 2014
, 30 May 2014→Some (unpleasant) truths up front: +example from the forum
(→Some (unpleasant) truths up front: +example from the forum) |
|||
| Line 42: | Line 42: | ||
Obviously, we would all like to have a flight simulator that provides for an experience that doesn't involve a steep learning curve. | 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-implemented, or even replaced, once middleware developers had sufficient tools at their disposal to customize the simulator through XML and scripting (for example, the existing weather system is more feature-rich than any previous weather system developed by core developers). Besides, it generally works better for the community 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. Coming up with such tools from scratch, as is common in commercial software projects, would be a huge effort - obviously, having to use generic tools, also means that usability may lack at times. | 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-implemented, or even replaced, once middleware developers had sufficient tools at their disposal to customize the simulator through XML and scripting (for example, the existing weather system is more feature-rich than any previous weather system developed by core developers). Besides, it generally works better for the community 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. Coming up with such tools from scratch, as is common in commercial software projects, would be a huge effort - obviously, having to use generic tools, also means that usability may lack at times. A couple of examples are given in [http://forum.flightgear.org/viewtopic.php?p=211165#p211165 this forum post] and the following one, dealing with this very issue by telling about what happened when it was attempted to make development easier with terrain texturing and the Canvas system. | ||
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. | 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. | ||