Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Chris Hecker <checker@d...>
Subject: Re: [Caml-list] Ocaml and games

>Just curious and wondering if anyone is doing (or has links to) games coded with OCaml...  looking to get some opinions on overall structure and/or feelings as to how well it is working for that.

I'm writing a commercial game in Ocaml right now (and for the past year, and for the next year ;).  I'm reserving judgement on the overall worthiness of Ocaml for games until I actually finish and ship a robust product, but it's been fun and educational at least.

Some short thoughts:

- Performance seems to be totally acceptable so far, but I haven't been focusing on optimization yet, and the options are limited for optimizations-in-the-small short of dropping to C or modifying the compiler, so I'm slightly worried about it in the future.  The GC performance predicability and smoothness is a huge looming shadow on the horizon that may or may not materialize, I have no idea.

- Lack of a debugger for native code sucks (not helped by the lack of the bytecode debugger on non-cygwin Win32 builds, and the debugger's not great even when it works after rebuilding for cygwin, in my experience so far).

- The toplevel has been a win (sometimes just as a pseudo-debugger).

- Linking of bytecode and native code would be good.  Currently if you're using bytecode (debugging, compile speed, toplevel, etc.) and you need to optimize something, dropping to C is your only choice, which is silly.

- Lack of overloaded operators (needing op. for floats), overloaded functions (need mult_matrix_vector, mult_matrix_matrix, mult_scalar_vector, etc.), and "let mutable" makes imperative mathematical code (most of what I've done so far, since the game uses a lot of physics simulation) messy and overly verbose.

- Closures are great.  Variants are great.  Pattern matching is good.  Code is easier and faster to refactor than in C.  I've noticed that code seems to get smaller as I add more features, which is fun and non-intuitive.  ;)

- Rigid for-loop structure is lame, recursive functions not as readable (and floats are boxed across them).

- The library has been useful, although it desperately needs an orthogonality pass.

- Labltk was fine for prototyping, but I now have my own Win32 thing I wrote because TK's a pig and unstable.  LablGL is working fine but I expect to write a thinner layer over OpenGL/D3D before shipping.

I've got a much bigger list that I'll post at some point.  Overall, I don't regret deciding to use Ocaml.

>(I am also reminded, having seen another email by Chris Hecker, that he mentioned something along these lines at his talk at the last Game Developers Conference.)

My talk was about programming language features that C/C++/Java/C# don't have but that seem useful, not about Ocaml specifically.


Bug reports:  FAQ:
To unsubscribe, mail  Archives: