For the past few months or so I've been trying to solve a problem that's been bugging me. That problem is -- how do you get things done 10x faster? By that I mean implementing features and solving bugs, not making the program itself execute 10 times faster. That might seem like an insoluble problem outside of becoming a lot smarter, but chasing it seems to be a worthwhile goal anyway. Even if you only make yourself twice as productive I'd say it's worth the effort.

Clearly you aren't going to become 10x more productive without doing something drastic. So there can't be any sacred cows.

The most obvious first step is to look at what tools you're using. I think in terms of tools, your choice of programming language is the most important tool choice you'll make. For whatever reason, game development is pretty homogenous in that regard -- almost everyone is using C++; which is actually rather unfortunate since C++ is really a pretty awful language when it comes down to it. It's a standard, of course, which is advantageous, but it's also error prone and buggy, and practically nobody fully understands it. (If you think you fully understand C++, here's are a fun excersize: See if you know what happens when you call an overrided virtual method in a base class's constructor. C++ is full of all sorts of fun surprises like that.)

In fact, really, unless you're making AAA titles for a large company, I think using C++ is a huge mistake. It'd be like an indy film studio trying to compete by making a gaudy summer action flick that relies on special effects rather than story. It'd be a bad move -- there's no way an indy film studio with no money can beat hollywood in the gaudy-special-effects department. If they want to win, they have to do compete in areas where they have an advantage -- perhaps in character development and story writing. Or maybe just by taking risks that the hollywood types wouldn't be willing to take. It's the same with games -- just because all the big developers are using C++, that doesn't mean it's neccesarily a good idea for you to use it.

On the other hand, it doesn't seem like there's a lot of competition with C when it comes to making fast native code. There's D, but its not very mainstream. Lisp can also compete (depending on the implementation), but then, I doubt I'm going to be able to convince many people to use Lisp :).

I'm starting to think though, that speed really isn't as big of an issue as we like to think it is. Consider the things that actually require a lot of speed in a game:
- Rendering. It doesn't matter what language you do this from -- it's going to run the same regardless since all the work is done by the graphics card/driver
- Physics: Practically everyone uses a library for this anyway.
- AI: How much speed this actually needs is rather dependent on the game. But then, a lot of games do AI in scripting languages anyway.

So if we take speed out of the equation, there's a lot more choices for languages. Java and C# seem like popular alternatives at the moment. Both are decent choices, but I don't think either of them are going to make you 10 times as productive. Not to mention that, Java in particular isn't neccessarily a huge improvement -- it lacks good abstractions outside of classes and it's ridiculously verbose at times (public static void main... ugh.)

So, if we start looking at the fringes maybe we can find something interesting. What kind of langauges tend to give you large productivity boosts over more mainstream compiled languages?

I'll leave the as an excersize for the reader for now since I'm sick of typing.