Here's a long interview with Inafune about leaving Capcom. He was, until recently, their head of development. One of his main points is that having a huge burn rate is bad. A burn rate is the amount of money you must pay to keep paying your team. This is exactly the point I've made for years, and I've kept my own company at the smallest possible burn rate I can.
If you have a large payroll to meet every month, the good part is that you probably have a lot of great workers who can accomplish a lot of great things. But there is a real bad part too. It means you must have projects going all the time. If it would be better for a project to do a long planning phase of several months before going into production, you'll be wasting everyone's salary by having them sit around and wait for planning. If you are a company that sets up deals with other companies for development (for example, you are a developer who gets paid by a publisher to make a game, or you're a publisher who looks for developers to make games for you), then a high burn rate means you need to make those deals by a certain date or there is going to be a disaster. If you have a horrible deal on the table, you might be forced to take it because waiting 2 months might be astronomically expensive.
Also, a high burn rate means that a huge return is needed to break even. If you need to sell a huge number of copies to just break even, it means you're going to be more afraid to take risks. Even if you say otherwise as you sit in your comfortable arm chair right now, free from any actual responsibility, if you were in such a position, you can't help but think that a risk could destroy the whole company when the stakes are that high. And if you aren't thinking that, your executives are. Being forced into "hit or die" is not great for creativity, and we'd hope that our industry is about creativity. In short, I totally agree with Inafune on that particular point, that a high burn rate is a very dangerous.
I thought this use of genetic algorithms looking for build orders in Starcraft 2 was really interesting. It seems like a good area to apply genetic algorithms, and I've imagined such a thing for years, but I never heard of anyone actually doing it.
The idea is to have a computer try a whole bunch of build orders and rate them on "fitness" (how close they are to a desired outcome of like "build a lot of marines by time X" or something. The ones that are fit, the computer tends to keep; the ones that aren't, it tends to discard. There are mutations over time that test if this or that variation helps or hurts. There are also several "villages" of these algorithms that are running independently, so if one stagnates at some evolutionary dead end, the whole thing is replaced by a new village that's based on the most successful other village.
The algorithm found a new (or at least previously not popular) build order to create 7 Roach units very, very quickly. The build order is kind of unintuitive, so it's exactly the kind of thing that a genetic algorithm would be good at finding. Pretty cool!