No you are 100% wrong becasue Microsoft (actually no one in their right mind) doesn't plan its product in terms of unit price...they plan them in terms of overall net return. You don't build a product and allocate resources based on what you can sell it for per copy, you base it on what you will get in cumulative return. If I sell a widget at $10.00 but know that I will sell 10,000,000 of them if I can build a widget that people will want to buy then I can allocate my project resources as a percentage of my projected return on investment. If I based it on only on unit price the product would be garbage. I can commit 5 million dollars on research and development and everything else required to deliver a quaility product and still sell it at $10. According to your logic a $10 product would have quality based on $10 when in fact it is based on my cumulative expected return. If all of the resources required to develop, test and sell FSX costs $1 million dollars and the estimated sales of said product is 500,000 units at the market pricepoint of $50 then the gross sales would be $25 million. Assume retail markup, cost of production and bulk sales prices cuts into that and even if it were by half your gross profit would be $12.5 million on a $1 million dollar initial investment. Microsoft sees the product as a $1 million dollar product and YOU see it as a $50 product, there is a big difference between what YOU see and what Microsoft sees so don't confuse the two.

If you're asserting that .. no one in their right mind .. takes into consideration a projected unit price when setting out to develop software, and allocate resources, then I'm not sure what to say.. it's silliness..

No you are 100% wrong becasue Microsoft (actually no one in their right mind) doesn't plan its product in terms of unit price...they plan them in terms of overall net return.  You don't build a product and allocate resources based on what you can sell it for per copy, you base it on what you will get in cumulative return. If I sell a widget at $10.00 but know that I will sell 10,000,000 of them if I can build a widget that people will want to buy then I can allocate my project resources as a percentage of my projected return on investment.  If I based it on only on unit price the product would be garbage.  I can commit 5 million dollars on research and development and everything else required to deliver a quaility product and still sell it at $10. According to your logic a $10 product would have quality based on $10 when in fact it is based on my cumulative expected return.  If all of the resources required to develop, test and sell FSX costs $1 million dollars and the estimated sales of said product is 500,000 units at the market pricepoint of $50 then the gross sales would be $25 million.  Assume retail markup, cost of production and bulk sales prices cuts into that and even if it were by half your gross profit would be $12.5 million on a $1 million dollar initial investment.  Microsoft sees the product as a $1 million dollar product and YOU see it as a $50 product.Now let's suppose that Microsoft had a market of only 10 people in the world who would want a product like Microsoft Flight Simulator.  Microsoft would still have to spend that same $1 million to bring the product to market but the product would have to sell for $1.5 million dollars each to make the same profit.  Same product different price. This is the exact price point difference in high density consumer sales vs low density commercial sales.  A consumer doesn't expect to make a profit from a consumer purchase while a commerical buyer does.  If an airline buys the $1.5 million dollar software to train new pilots but makes $200 million from tickets sold and those new pilots that used the expensive software can now fly those flights then it was well worth the expensive software wasn't it? There is a big difference between what YOU see and what Microsoft sees so don't confuse the two.

You point/argument is not an absolute .. but you speak like its an absolute.   Often times, price point is discussed in terms of the number of units that can be moved at a particular price point.  We often plan the ... market share gain at a particular price point vs. net return.

No you are 100% wrong becasue Microsoft (actually no one in their right mind) doesn't plan its product in terms of unit price...they plan them in terms of overall net return. You don't build a product and allocate resources based on what you can sell it for per copy, you base it on what you will get in cumulative return. If I sell a widget at $10.00 but know that I will sell 10,000,000 of them if I can build a widget that people will want to buy then I can allocate my project resources as a percentage of my projected return on investment. If I based it on only on unit price the product would be garbage. I can commit 5 million dollars on research and development and everything else required to deliver a quaility product and still sell it at $10. According to your logic a $10 product would have quality based on $10 when in fact it is based on my cumulative expected return.

You are 100% wrong. Companies do plan in terms of unit price. The number sold depends on the unit price for a particular product and market . The revenue is the product of number of a particular product sold and its unit price and so depends solely on unit price. The reason you know that you will sell 10,000,000 widgets is because you have set the unit price to $10. Change the unit price and the number sold will change.Determining the unit price is an essential first step in development of any product. Why do you thing so many similar products are so similarly priced? It's not chance but because the developers looked at the market to determine the unit price and then worked back, via estimated revenue, to what they could afford to spend on development. Microsoft almost certainly did the same and looked at the market for computer games and decided FS had to be less than $50 in order to sell well and, based on estimated sales, determined its development budget. If at that stage the figures don't stack up then development would be abandoned.

If you're asserting that .. no one in their right mind .. takes into consideration a projected unit price when setting out to develop software, and allocate resources, then I'm not sure what to say.. it's silliness..

No, what I am asserting is that the unit price is the price point at which you can sell your product at a given level period. However, IF that is how you allocate your resourcing budget then yes, one is not in their right mind because you've missed the forest by concentrating on the leaves.

No, what I am asserting is that the unit price is the price point at which you can sell your product at a given level period. However, IF that is how you allocate your resourcing budget then yes, one is not in their right mind because you've missed the forest by concentrating on the leaves.

Ok.. I'll try again... re-quote:

the unit price is the price point at which you can sell your product at a given level period

Simple algebra tells me that that will yield a projected, gross revenue.. and knowing that R&D can only consume a percentage of that.. how can I fund R&D without considering the unit price.. regardless of foliage ?

Ok.. I'll try again... re-quote: Simple algebra tells me that that will yield a projected, gross revenue.. and knowing that R&D can only consume a percentage of that.. how can I fund R&D without considering the unit price.. regardless of foliage ?

Again:1. I want to bring a product to market2. How much will it cost for me to bring a product to market (development, Q&A, marketing, channel sales, logistics)3. How large is the market segment4. Competition = How diluted is the market5. Competition = How does my product compare to similar products already in the market6. What is the market price for similar products7. What can I sell my product for and still be competitive8. How many of my products can I sell given 3,4,5,69. What is my expected return on investmentDo a Google search for Venture Capital Firms. Pick one, call them. Tell them that "you will be successful if only you can sell 'X' amount of product at 'X' price and they will hang the phone up on you. Call another one and tell them the same thing. Keep calling until you find one that will fund you based on the way you think and come back and let me know who that is.The argument here is that a $50.00 game determines the quality of the game. I'm tell YOU that $50.00 is NOT the determining factor of anything in this case. Unfortunately you don't seem to be able to grasp that point.Either way, this has gotten wayyyy off topic, my bad, I'm done so you win.

The venture capitalist (of which I'm one), could very well be the entity that MAKES these calculations (particularly #7 on your list :( ) .. that's part of what they do before determining what they're willing to put at risk.I doubt though, that M$ looks to outside funding for these projects; unless it's part of a presentation before issuing coporate bonds.

Sounds like you haven't been playing games very long... I could probably name a hundred games that are far more buggy than FSX.

Perhaps, but I feel FSX was programmed inefficiently to begin with. SP1/2 helped. But they really could have made better use of the GPU and DX10 if they put forth a bit more effort, instead they were lazy and relied on legacy code to get the product out the door.Sloppy programming imho. You see the same with addons... some have hideous effects on FPS, while others are extremely efficient.

Because Mike T made no attempt to answer my previous post and is done, I suppose it's futile to point out that his list is completely wrong - but I will because it can't be allowed to stand.The first thing anyone planning a new product does is assess the market.. That is, to evaluate potential revenue by considering unit price and number of sales. That covers his points 2 to 9. Only then can a development programme (his point 1) be determined.In reality, there are many manufacturers who have separate sales and production divisions. The sales division specifies the product, its numbers, and its unit cost to the production division The production divison has the responsibilty for achieving those requirements . It then "delivers" the product to the sales division which has the responibility for selling the product at a profit. Such a division matches expertise and responsibilities. The sales division has expertise in marketing but doesn't have responsibily for production, and the productyion division has expertise in production engineering butdoesn't have responsibility for sales. Both can concentrate on their own areas of expertise.No company ever begins by deciding how much to spend on development, hoping sales will cover it - not if it wants to stay in busines.

Perhaps, but I feel FSX was programmed inefficiently to begin with. SP1/2 helped. But they really could have made better use of the GPU and DX10 if they put forth a bit more effort, instead they were lazy and relied on legacy code to get the product out the door.Sloppy programming imho. You see the same with addons... some have hideous effects on FPS, while others are extremely efficient.

The costs of re-writing Flight simulator as you suggest might have ensured the product never "got out of the door". Commercial realities tend to be forgotten in these discussions.

I think some folks see FS's biggest asset as its biggest liability...I guess I see it the otherway around.It’s like operating a farm you don’t raze it every couple of years ;)Components are maintained upgraded and replaced.Calling for a ‘rewrite’ (whatever that is?) assume way too much insider info.Good engines aren’t built in three years they need time to evolve.The next installment will maintain upgraded and replace engine elements according to priority and feasibility.That’s not just good, it's ideal.

Because Mike T made no attempt to answer my previous post and is done, I suppose it's futile to point out that his list is completely wrong - but I will because it can't be allowed to stand.The first thing anyone planning a new product does is assess the market.. That is, to evaluate potential revenue by considering unit price and number of sales. That covers his points 2 to 9. Only then can a development programme (his  point 1) be determined.In reality, there are many manufacturers who have separate sales and production divisions. The sales division specifies the product, its numbers, and its unit cost to the production division The production divison has the responsibilty for achieving those requirements . It then "delivers" the product to the sales division which has the responibility for selling the product at a profit. Such a division matches expertise and responsibilities. The sales division has expertise in marketing but doesn't have responsibily for production, and the productyion division has expertise in production engineering  butdoesn't have responsibility for sales. Both can concentrate on their own areas of expertise.No company ever begins by deciding how much to spend on development, hoping sales will cover it - not if it wants to stay in busines.

Most of what you say is spot on .. with the exception that you do estimate  you costs fixed and variable, this includes R&D costs.  At the start of a new development, you project/estimate the following simplified pointsRevenue (forecaster number of units sold X project price point) - Costs (cost of sales, production, R&D) = projected program earning/return.

Most of what you say is spot on .. with the exception that you do estimate you costs fixed and variable, this includes R&D costs. At the start of a new development, you project/estimate the following simplified pointsRevenue (forecaster number of units sold X project price point) - Costs (cost of sales, production, R&D) = projected program earning/return.

Exactly - cost has to cover all costs associated with the product.

Perhaps, but I feel FSX was programmed inefficiently to begin with. SP1/2 helped. But they really could have made better use of the GPU and DX10 if they put forth a bit more effort, instead they were lazy and relied on legacy code to get the product out the door.Sloppy programming imho. You see the same with addons... some have hideous effects on FPS, while others are extremely efficient.

Your comments might be a little harsh and a bit uninformed? While Microsoft sells Windows and Flight Simulator, they have to treat each as a separate entity. So that meant while the world was waiting for Vista and DirectX 10, so was the Flight Simulator team. ACES would have gotten preview data just the same as any other game developer. But there would have been NO inside, inter-company additional information about Vista and DX10. That would have opened Microsoft to a suit for unfair business practices.Up until the "almost release date" the world and ACES were expecting 5ghz processors. As Intel goes, so goes the gaming world. Only a little time before RTM did we hear and discover the benefits of Core2Duo and the system changes that it brought forward. My intention upon the release of FSX was to build a new system around a relatively fast AMD processor that would allow for overclocking. That plan went down the drain once the benchmarks for the C2Ds started to appear.That late in the development cycle for ACES to go in and make wholesale changes to FSX would have blown the budget. So they released what they had and used the SPs to improve things. But to say they were lazy is unjustified, IMO. We've seen the postings of the former ACES members, haven't we? They are passionate about their work. They aren't a group of people who just got out of some trade school programming class and decided to go to work with Microsoft. Scraping the bottom of the programming barrel isn't what Microsoft does.FSX has it's flaws. But there is a whole lot of good that comes on two or three DVDs. Most especially a pretty solid set of SDKs that allow addon developers to make all those things you buy, Ryan. Now if the add on developer monkeys around with default files or tries to cut some corners, then things can and will go wrong. Check the thread about the OBXxxxx files that were replaced by an add on product. Why? I haven't a clue, as there is a set way of dealing with scenery replacement. Or watch for another thread about bad landing lights because a plane modified an effect file, which means all planes that use that effect are now modified.But I guess we can just blame ACES? They are a lazy bunch, or so I've read in a forum some where... :(

Here's my effort at helping to rectify one of the biggest ways in which FSX can get broken - corruption of the dll.xml file - inspired partly by this thread and partly by one on our forum today:http://support.preci...leshooting.aspx