I am not quite sure why something like OCaml has not taken off in game development yet. Seems the promise of C speed, better programming abstractions and functional core would be something a strong game development studio would jump all over.
Though, being completely honest, I am not fully in tune with the game development community. Can anyone else comment?
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).
If true, the industry would be vulnerable to disruption by an ocaml shop.
I think C's low-level hackability and integration with assembler is hard to beat for max performance. In other cases, a scripting language is more agile. And correctness isn't important in games (if it seems right, it is right). So ocaml's impressive attributes don't win any of these battles.
With xbox having 3 cores and ps3 having 8, a better concurrency language has an opportunity to have an impact. Maybe in the next nextgen... (if launched today, moore predicts x8 as many cores: 24...64).
You can program Xbox 360 games in F# (a Microsoft language that's based on ML, and is similar to ocaml) using XNA. A few very small indie games have been written that way.
People who write a game in ocaml tend not to write a second game in ocaml. They tend to go back to C/C++. To me this indicates that ocaml is not a good fit for game development.
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.
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.
I am not quite sure why something like OCaml has not taken off in game development yet. Seems the promise of C speed, better programming abstractions and functional core would be something a strong game development studio would jump all over.
Though, being completely honest, I am not fully in tune with the game development community. Can anyone else comment?