The Next Mainstream Programming Language: A Game Developer's Perspective (2006)

Inertia. From a technical standpoint the game industry is about customer-facing features that happen to also be technologies. You can go from one product to another carrying along many of those features, but change the language and you blow them all up.

Today you have a "legacy" group of AAA developers with huge, well-tuned C++ engines designed specifically around that dev model(typically, lots of scripted and hand-crafted static content with photorealistic graphics and in-game cutscenes), and a growing number on the indie/mobile/web/social side who are using whatever is convenient, and often rolling their own thing to fit their own projects. For many that still means C++ since they're already familiar with it, there's plenty of examples and library code around, and some targets still demand(or literally require, in the case of consoles) that mix of tooling, performance and features. For others it might be Java, Objective C, Actionscript, or Javascript.

The value proposition of a new language isn't great for the AAA developer because the engine coding effort - on a large project - is tiny compared to the content. For tiny games most of the pressure to ship is on programming - but once you're past the core engine(resources, scene/entity/rendering management, collision, events, etc.), the benefits are still unclear since most gameplay coding uses the same patterns in any language - lots of intermittent special-case logic, blobs of state accessable through various indexes, timing, and sequencing. These things can usually get parceled out to a scripting language for faster iteration(or, at minimum, designer-driven iteration, vs. coder+designer pairing).

I haven't mentioned parallelism once yet, notice. Despite Tim Sweeney's focus on this in his slides, it's not a big concern for anyone but the AAA guys who are specifically aiming to max out the hardware. The gameplay proper is hard to enforce in-parallel because most game designs are massively stateful and interdependent. That leaves rendering and miscellaneous auxiliary processes. Rendering quality is now bottlenecked mostly by the content creation process, not by runtime concerns. We can always throw more polygons into a scene, but the details of shading, texturing, and animation have become far more important to image quality.

Look at what Valve and Blizzard are doing. They've both stayed far away from the cutting edge in their own technology, and that hasn't hurt them a bit in sales. So again, there's just very little reason to move forward on the tech if you aren't an indie, and if you are then you have to weigh your choice against how difficult it'll be to ship the final product to consumers. The math tends to favor one of the languages mentioned earlier(C++, Obj C, JS, AS3, Java).

C++ is very ingrained in the traditional (big game) industry. Even if the legacy/library compatibility and performance of alternatives were no longer issues, I think a lot of the more senior developers have chosen "C++ for life".

I am not a game developer but I believe its an issue of legacy, tooling, libraries, tutorials, documentation and tradition. As late as 2002 I was still seeing C vs C++ speed arguments in gamedev forums.

Lua is fairly popular in the game industry, for scripting engines written in C++ or C.

It doesn't attain C-level speed yet. Maybe for a web developer's purposes it does, but definitely not for the kind of ridiculous optimizations that console games frequently need.

Further, C/C++ runs the industry, and that's all the console manufacturers are going to provide for in their SDKs beyond scripting, such as Lua. Even then, use of that has to be limited because they're usually so cramped by the hardware.

http://www.wiisworld.com/wii-specs.html

88mb of memory in the Wii.

Lets not forget that you have to interface with OpenGL / DirectX for the graphics. Good luck wrangling with OCaml for something like that.

Oh, and you'll have to retrain everyone anew for it too.

It's just not a good enough tool/language to justify the switch given the immense inertia weighing against it.

Edit: This is why I don't work in the gaming industry, amongst other things.

Checked exceptions, at least the way Java does them are exceedingly verbose, potentially requiring a try/catch block at every level of a call stack. I think it would be possible do static analysis of most possible execution paths and determine whether there's a possible exception not being caught by a certain level without having to deal with it in every call.

It's a little disappointing that we didn't get to 20 cores by 2009. We didn't even make it to 8.

Ruby, Python, and in the game-dev world, Lua have become quite popular without curly brackets and semicolons. I don't think syntax is all that critical to a language becoming popular[0]. What does matter is that it solves an immediate problem that simply isn't being solved by other languages, or is attached to a framework or tool that does so. Python got popular because it was a more readable replacement for Perl. Ruby got popular because it was used for a framework that eliminated half the work from the average web app[1].

[0] With certain limitations. A painful syntax will keep people away, and it remains to be seen whether Lisp is painful enough to most programmers to prevent adoption when a language otherwise solves all their problems.

[1] Compared to PHP, Java or just about any language with CGI and a hand-rolled data access layer.