Re: [Caml-list] Games

[Jon Harrop <jon@ffconsultancy.com>]

On Wednesday 27 July 2005 22:13, Pal-Kristian Engstad wrote:
> I've been looking into O'Caml, and I've written some tools
> in it (caml is great for tools), but here's a couple of points
> against it:
>
> 1. It doesn't support console platforms.
> 	- The PC market is quite minor compared to consoles.

Firstly, the PC game market is minor compared to consoles in terms of 
industrial profits. However, the console market is minor compared to the PC 
market in terms of the number of programmers.

Secondly, what would it take for OCaml to support console platforms?

> 2. It doesn't support low-level constructs.
> 	- No SIMD (AltiVec/VMX) vector operations.
> 	- No explicit assignment of (bit and byte) offsets
> 	  within a record.
> 	- No explicit alignment specification.
> 	- No inline assembly.

From my point of view, making a statement that that about ML really makes me 
think that you're pointing in the wrong direction. ML is all about _not_ 
exposing such low-level constructs.

I think you should try forgetting about all of the subpoints you've made here 
for a mini project (if you're interested in persuing this) just to see how 
important they really are.

> 3. There is no controlled real-time GC.
> 	- GC needs to run between frames,
> 	  and only for a controlled amount of time.

OCaml's current GC is good enough for games, IMHO.

> 4. There is no real support for unboxed data-types.
> 	- This one is actually very important for consoles.

Can you explain why this is particularly important for consoles?

> For game-code (AI, behaviors, etc.), it is better suited,
> though the GC issue is there. But it doesn't support much
> of threading - be it through pthreads or cooperatively -
> which renders it unusable to us.

I know very little of threads but I believe your assertion is incorrect. I'm 
sure someone more knowledgeable than I will clarify...

> So in the end, ... ocaml is nice as a tool, but it is by far
> not usable for the game console world. So, I guess we'll stick
> with C++ for a while...

Your statement about OCaml's current suitability for games console programming 
is subjective. I think it would be more productive to try to objectively 
state what work needs to be done in order to make OCaml suitable for games 
console programming. My guess is that you "only" need low-level bindings from 
OCaml to whatever library is exposed. Writing these bindings will probably be 
a lot of work though.

Then it is a case of "suck it and see". As I say, I think you'll find that the 
GC is irrelevant. However, you may be correct about alignment issues etc., in 
which case you will need to move code from OCaml to C. That still leaves 
plenty of interesting high-level code that can be productively written in 
OCaml.

However, I (and I don't think Skaller) was talking about games consoles. I was 
thinking (and gave the example of Darwinia) of the much larger number of 
games that are written for fun, often by people in their spare time, for 
desktop computers. I think there is a market here for educational material to 
teach these people how to program games more easily by using OCaml instead of 
C++. I'd bet that Darwinia, for example, would have been much easier to write 
in OCaml. I agree that OCaml is currently much better suited to this than to 
consoles but consoles aren't everything...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists