Depends where you are I guess. That's roughly £33,000 in London and that won't great you that far with developers, but it depends what they where doing. You can easily earn that for web development, game development I'm not so sure. But if anyone knows anything about game development, it starts off normal, but then as deadlines start racing up you're put on 6 and then 7 day weeks, often for more then 12 hours a day. It's a quite brutal industry

10 programmers on $50.000 (seems low, would any of us take on a project with an unknown outcome for $50k pa) then factor in the cost of licensing whatever 3D engine is chosen.

Does anyone know what Unigine would cost for a project like this, perhaps Stephen may want to ask them.

 

Hi, that 50.000 p.a. was meant more as a joke acutally... who can live on coffee alone? OK, you can, but not indefinitely.

 

But I stand by the 2,5 mil initial estimate. Let's say 35.000 develompent hours, which would be by rule of thumb 30% of the total effort. In this special case, as specifications are well known and maybe technology like Unigine or Outerra could be bought in instead of developed from scratch, it may in total end up at 70.000 hours? Diversified between costly PM and architect, mildly expensive developers and free of charge volunteer testers.

 

And the 10 devs will have to know each other very well and ideally already have been working together in the past.

Diversified between costly PM and architect, mildly expensive developers and free of charge volunteer testers.

 

No, everyone is going to be costly (except the PM). This isn't the kind of project you can get a half-dozen VB monkeys to work on. This is multi-threaded C++ code, DirectX 12 code, and then multi-threaded DirectX code. For the scenery data, you need people who've done extensive GIS work and can source and convert the necessary data.

 

You mentioned earlier that you could reach out to local software shops. This simply will not work - you are not talking about rudimentary web development or building a data entry app to push stuff into SQL Server. This is hard, hard work and requires a very specialized set of expertise. You are NOT going to find at your local software shop. The people who can do it are NOT going to even reply to you for less than six figures, plus equity, plus control of the product, not taking feature requests from some anonymous folks on an Internet forum who have no idea how to actually do the work. You don't build a major league baseball team by recruiting folks at the local beer league.

 

Finally, testing is HARD. It's hard because it's a lot of very scripted, repetitive work to get the software into the particular state required to duplicate a particular problem or exercise a piece of code. When I wrote my flight data recorder I flew from JFK to LGA over two hundred times to collect data, fix problems and repeat. And a new problem. Again and again and again. Volunteers are next to useless - look at these forums when people have problems, and how little information they provide. They change six random things with no idea what caused the problem to appear or go away. That's worse than useless in a tester.

 

Compilers and CPUs are the most unforgiving things you can work with. They don't care about your enthusiasm, your energy, your positive attitude or anything else. They strictly operate on knowledge, and logic. That's why negative, cynical old me churns out lots of code regularly despite my bad attitude.

 

Stephen, I have a suggestion - why don't people try to put together an airport, something small, and see how long it takes you? Or why not duplicate the FSGenesis work and create a terrain mesh for North America? Not as a product, but just as 0.0001% of what a new sim needs. That should give you an idea of the amount of work it's likely to take and how hard it is (and proportionally how many people in your community will be able to do it). It might also give you a little bit more credibility as well that you can do more than come up with ideas and work for other people to do.

 

Talk is easy. Code is hard.

 

Luke

Agree. Well stated Luke!

 

Best regards,

Luke,

 

You've missed the parts that the chosen sim engine will handle 95% of this all by itself and the other 5% is done automatically. Just look at all the demos and tech demos that have been shown here. No human interactions are needed, and if they are needed, there are 10,000+ people just willing and able to pitch in.

Luke,

 

You've missed the parts that the chosen sim engine will handle 95% of this all by itself and the other 5% is done automatically. Just look at all the demos and tech demos that have been shown here. No human interactions are needed, and if they are needed, there are 10,000+ people just willing and able to pitch in.

 

I missed that part as well. Could you point it out?

 

But.

 

Some of this at the end illustrates why I keep my money on Outerra. They are not dependant on us here. (which is a very good thing)

 

Certainly they could use our help, and when their own kickstarter occurs, the interest and hopefully the influence of Flight simmers will be important (and I truly hope we will be there) but they have already charted their course and are moving towards it at their own pace and on their own terms.

I missed that part as well. Could you point it out?

 

Your post #119 as a start:

 

"Right now, there exist several freeware/open source libraries (and engines like Unigine) that simply were not available in the past. Libraries and engines that are there specifically to remove the need to recreate some of these self same wheels that you've mentioned. They aren't the holy grail by any means, but they do open the possibility that many things that had to be created painstakingly from scratch in the past might be done more quickly and easily now. Its definitely not 2006.

 

For instance, the very same JSBSIM library that powers Flighgear powers Outerra. That means that powerful features that would have taken years to create from scratch are already at least theoretically available, and much more quickly."

Your post #119 as a start:

 

"Right now, there exist several freeware/open source libraries (and engines like Unigine) that simply were not available in the past. Libraries and engines that are there specifically to remove the need to recreate some of these self same wheels that you've mentioned. They aren't the holy grail by any means, but they do open the possibility that many things that had to be created painstakingly from scratch in the past might be done more quickly and easily now. Its definitely not 2006.

 

For instance, the very same JSBSIM library that powers Flighgear powers Outerra. That means that powerful features that would have taken years to create from scratch are already at least theoretically available, and much more quickly."

 

I've added some emphasis, since what I wrote seems to have gone through your own filter. If you have to distort what somebody has said to make a point, then the point was probably not very valid in the first place.

 

You've missed the parts that the chosen sim engine will handle 95% of this all by itself and the other 5% is done automatically. Just look at all the demos and tech demos that have been shown here. No human interactions are needed, and if they are needed, there are 10,000+ people just willing and able to pitch in.

 

The two statements are not even approximately close to each other, except when focused through a lens of sarcasm. It would also be helpful if you pointed out exactly what was incorrect in my statement. Can you?

 

You know, when watching your posts over the years, I've never been able to figure out exactly why you sometimes approach things in this manner. Its very puzzling. Its obvious you have years of experience and knowledge that could be very helpful. But often not in the way you choose to dispense it.

You can emphasize all you want! 

 

Not incorrect, just inaccurate in your belief that all this stuff just magically appears on a screen with little or no human programming involved. It's really not a problem because there are others that think the same way!

 

I approach things in this manner because I can see both sides of the situation and when one side is living in a fantasy world it is sometimes necessary to inject a bit of reality back into the situation. Re-read Luke's post if you want a more realistic view of things. 

Not incorrect, just inaccurate in your belief that all this stuff just magically appears on a screen with little or no human programming involved. It's really not a problem because there are others that think the same way!

 

What's inaccurate is your writing your own interpretation into what was actually said. You are free to do so, but it has nothing at all in any way to do with me. Typically its a sort of straw man: Reconfiguring another's words into an easily refuted form, which is then attacked as ridiculous, rather than dealing with what was actually said.

 

I approach things in this manner because I can see both sides of the situation and when one side is living in a fantasy world it is sometimes necessary to inject a bit of reality back into the situation. Re-read Luke's post if you want a more realistic view of things. 

 

Actually, Luke's post was an orderly and logical summation of what he believes the issues were. While I have some disagreements with it, it was a valid and useful post.

 

Yours was a loud (and typical) raspberry, and not nearly as useful. Make your points. But not by twisting mine, please.

I approach things in this manner because I can see both sides of the situation and when one side is living in a fantasy world it is sometimes necessary to inject a bit of reality back into the situation. Re-read Luke's post if you want a more realistic view of things. 

 

I agree an injection of reality is needed for those who don't know. Luke does it admirably, without any sarcasm, I guess you're just the sarcastic type. Each to their own I suppose. What is it they say about sarcasm again?

In defense of Jim, if you take away the specific numbers in his post, he has a valid point. I understand his style (and I do it from time to time too) - he's exaggerating for dramatic effect.

 

Whether the NGFS team thinks that an existing engine will do 95% or 25% of the work, there still is an awful lot of hand-waving away of real, significant problems. The reality is that third party libraries rarely do all they promise to do, and their gaps appear in surprising and unpleasant ways. Volunteers either don't show up, or when they do they're flakey. Same thing with crowdsourcing - I'd venture that for every 5 people who thinks it's a great idea only 1 will agree to contribute any money, and then only 1 in 10 will actually pay up.

 

Even if you have an existing engine, you need to have a lot of specialized expertise to determine whether it meets your needs. Emphasis on specialized - what effects does it have on flight modeling, scenery, performance, etc. My guess is that whatever work it saves you in one area, you will pay a certain amount back in others (does it use the same projection for GIS data, etc). If you want to extend the sim for third parties, what kind of API do you need? What are the security implications, or limits on languages used? Cross-platform is a great idea, until you realize that supporting OSX and Linux is 2.9x as much work, maybe more.

 

Really, if you want to build the NGFS, fork FlightGear and turn it in the direction you want. That might in the long run be the least amount of work.

 

Cheers!

 

Luke

Again, I would hope that some folks who have already done it successfully, ie, Aerowinx( one individual, many years) would be asked to share his wisdom. Stephen, go to aerowinx and ask. The guy is always present and speaks with many years of experience in flight simming. Imagine that he alone coded one the most complex flight sims in the market.

Robert Randazzo at PMDG might have a few things to add, too.

 

We are amateurs, and thus very dependent on those who know what they are talking about.

tony

In defense of Jim, if you take away the specific numbers in his post, he has a valid point. I understand his style (and I do it from time to time too) - he's exaggerating for dramatic effect.

 

Exaggeration for dramatic effect is one thing (and sounds quite innocuous and harmless) Twisting another's words? Not so much.

 

Again, I would hope that some folks who have already done it successfully, ie, Aerowinx( one individual, many years) would be asked to share his wisdom. Stephen, go to aerowinx and ask. The guy is always present and speaks with many years of experience in flight simming. Imagine that he alone coded one the most complex flight sims in the market.

Robert Randazzo at PMDG might have a few things to add, too.

 

We are amateurs, and thus very dependent on those who know what they are talking about.

tony

A good idea. You might even speak to the flightgear founder and ask what he thinks. From the interview, it seems he has touched bases with many people over the years that are strong contributors, who might also have valuable input.

I estimate the initial effort for a flight sim at about 20 man-years - that is to say, 10 people working full time at it for 2 years.

 

I estimate that FSX consists of about 20 MB equivalent lines of source code of the total of some total 70 GB on disk.  Assuming a typical working year is about 1700 hr per year, each member of the team would have to develop about 20,000,000 / (20 * 1700) =  580 fully developed, integrated, and debugged lines of source code per hour.

 

On average a programmer's salary in London  is about £35,000.  The actual cost of employment is about twice that, say £70,000,  to allow for the costs running the business, plus ,of course,  profit.

 

The UK government adds a "optimism bias" to all its estimates for work. This is the difference between a project was initially estimated to cost and what it actually cost. The starting value is between 54% and 200% for projects that are concerned with the provision of equipment and/or development of software and systems.

 

We should be careful about estimates.