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 18:48, 2 June 2014
, 2 June 2014→Some context on different perceptions: we should rename bigstones' modified script to contentmonster.js ;-)
m (→Some context on different perceptions: we should rename bigstones' modified script to contentmonster.js ;-)) |
|||
| Line 336: | Line 336: | ||
Assume you have this interesting feature in mind which is not in FG. Chances are, you assume that just nobody thought about having it before. Chances are however that this assumption is wrong (a rough estimate would be that perhaps 5% of the suggestions are of that type). People working e.g. with shader effects have spent thousands of hours working with rendering code and usually have a habit of comparing nature and FG to see how to improve things. They also know what other games do and have read books and tutorials on GLSL shaders. So what's the case most of the time is that if a feature is not there, it failed a cost-benefit analysis - either it's not interesting enough so that it's low on a to-do list, or it would cost too much framerate to implement it, or too much coding time. If it'd be interesting and easy to do over the weekend, someone would have done it already. As a result, the reaction to simply suggesting the feature will be along 'Oh yeah, thought about this a while ago, not so interesting...' So if you want to change this, you have to understand and change the cost-benefit analysis. | Assume you have this interesting feature in mind which is not in FG. Chances are, you assume that just nobody thought about having it before. Chances are however that this assumption is wrong (a rough estimate would be that perhaps 5% of the suggestions are of that type). People working e.g. with shader effects have spent thousands of hours working with rendering code and usually have a habit of comparing nature and FG to see how to improve things. They also know what other games do and have read books and tutorials on GLSL shaders. So what's the case most of the time is that if a feature is not there, it failed a cost-benefit analysis - either it's not interesting enough so that it's low on a to-do list, or it would cost too much framerate to implement it, or too much coding time. If it'd be interesting and easy to do over the weekend, someone would have done it already. As a result, the reaction to simply suggesting the feature will be along 'Oh yeah, thought about this a while ago, not so interesting...' So if you want to change this, you have to understand and change the cost-benefit analysis. | ||
=== Case stuy - about empowering the masses === | |||
{{cquote | |||
|<nowiki>If the coders here at FG spent their time (1000 hrs) making the aps / tools that take all the coding out of making stuff, then the modders those with little coding knowledge would spend the 3000 hrs doing the rest.</nowiki> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211072#p211072 | |||
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | |||
|author=<nowiki>Bomber</nowiki> | |||
|date=<nowiki>Thu May 29</nowiki> | |||
}} | |||
}} | |||
{{cquote | |||
|<nowiki>Basically, that's what's been happening over the last few years in various areas, especially canvas - however, rather than focusing on "tools" or "apps", developers tend to focus on infrastructure and building blocks - often using existing standards and established technologies, so that existing tools can be used, without those having to be coded from scratch (XML=>XML editors, Blender/AC3D, textures: GIMP, sound editing, GRASS/QGIS etc)</nowiki> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211075#p211075 | |||
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Thu May 29</nowiki> | |||
}} | |||
}} | |||
{{cquote | |||
|<nowiki>Here's my personal experiment with this: Making terrain texturing look better. After a few years of coding and nagging others to code, we now have</nowiki> | |||
* xml-configured regional texture definitions | |||
* general-purpose xml-configurable effects for the terrain | |||
* and the best - all controlled from the same file! | |||
* and the whole thing documented in the wiki | |||
* and my personal help for people who want to do it in the forum | |||
<nowiki>It's the classical grunt task - most of the actual work is gathering aerial imagery of an area, finding or making the textures you need and lots of trial and error with different texture schemes - almost zero coding requirement, the necessary xml you can pick up in an afternoon if you don't do cut and paste. And it makes a hell of a difference for the visuals of a region, more than any amount of CORINE data or static models can do. | |||
The net effect is that I still do 90% of the regional te...s me is a few days. | |||
Some folks use it for custom scenery, and every once in a while someone makes a definition that can actually go to GIT, but it's really the opposite of what you claim to be true - there's lots of time invested in an easy-to-use tool which enables people to make 'their' region much better - and what happens is that nobody uses it. | |||
It's simply not true that the grunts would appear and start working if only they had the proper tools / the documentation / the whatnot. The fact of the matter is that I've almost never seen it happen, so by now my prevalent philosophy (born from that experience) is that I want to see very solid evidence that someone will actually use any tool requested from me before I consider coding it.</nowiki> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211165#p211165 | |||
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | |||
|author=<nowiki>Thorsten</nowiki> | |||
|date=<nowiki>Fri May 30</nowiki> | |||
}} | |||
}} | |||
{{cquote | |||
|<nowiki>We've actually tried that with the MapStructure framework, which is rather extensively documented now, and which even provides kind of a "plugin" or "module" system, where people can easily add their own map layers for custom stuff. While the documentation is obviously very popular (14k views within just 6 months), we still have to see someone else step up and actually adopt the system. Admittedly, FlightGear 3.2 is going to be the first release that will provide most of the building blocks required here, but currently it doesn't seem likely that there will be dozens of modules provided by others, despite us having taken the time to work out a system, and document it rather well. Still, I don't regret having spent that time, because the contribution is at least "future-proof" that way - i.e. it doesn't matter if we're around or not, because people can look up all the required info and actually understand the code sufficiently well to improve/maintain the system, or...d of seeing someone contributing something back is exponentially higher once certain criteria are met, i.e. either a corresponding track record, absent that, a strong willingness to follow advice, or at least acquire knowledge and follow pointers. | |||
Ultimately, the question still boils down to motivation - we've seen some very experienced contributors/core developers who agreed that certain features would be "good to have", but who still didn't care enough to actually work on those - at least, they stated so upfront | |||
Seriously, the same people asking for GUI tools like an aircraft, scenery, texture or mission editor are usually the same ones who refuse to use existing tools like Blender, GIMP, QGIS/GRASS or even just a good XML editor.</nowiki> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211169#p211169 | |||
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Fri May 30</nowiki> | |||
}} | |||
}} | |||
=== Case study - when is rendering simple? === | === Case study - when is rendering simple? === | ||