Version française
Home     About     Download     Resources     Contact us    
Browse thread
How to do this properly with OCaml?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Games
On Wednesday 27 July 2005 21:35, Jere Sanisalo wrote:
> Humh, missed where this started, but.. :)

Skaller flew off on a tangent because he was beaten by a low-level, 
bit-twiddling games programmer as a child. ;-)

> As a games developer I somewhat disagree. Sure there are people who do not
> know how, but in my view (and experience) most of professional games
> developers are pretty good at doing high level code.

I can see the definition of "high-level" causing a problem here. It is my 
belief (but I may well be wrong) that games programmers have a very different 
notion of "high-level" than, say, most of the other people on this list.

> For the problems 
> described here I can see much easier explanations. Mostly having something
> to do with extremely tight deadlines, producers/publishers not knowing what
> they want and changing their mind all the time and the tight coupling to a
> limited hardware.

Tight deadlines and closeness to hardware make sense. But if the specification 
keeps changing then I would say that a higher-level language would be more 
suitable. I know what you mean though...

> On one game developer forum there was a poll on how people managed their
> high level code. Many developers had actually written their own
> preprocessors to C++ in order to get introspection and the like. Only one
> (I know of) have written their own language; GOAL / Naughty Dog.

I suspect that a high proportion of the people on this list have written their 
own language, probably several languages. I think I've written three 
languages now (two interpreted, one JIT) and I'm just a physicist dabbling in 
OCaml. ;-)

> And what I 
> gather, even GOAL is split into two parts. The macro language is a full
> scheme and the game side is more like an imperative language in the lisp
> syntax.

Again, I suspect (but may well be wrong) that a significant number of people 
here would not regard Lisp as very high level compared to ML.

> Most (if not all) game programmers I have talked to have actively pursued
> more better ways to create their games and handle those increasingly
> complicated event queues that happen there. It's not easy, I can tell you.
> I tried to formulate a basic game in ocaml once and failed badly. It's
> mostly because I'm not yet so experienced in FP style and need to learn to
> think things differently.

Ironically, game programmers probably already do lots of functional 
programming without even realising it.

> (btw, one major reason for not using more FP-like languages in gamedev is
> because the platforms are nowadays mostly not-PC and the compilers /
> trained staff is hard to find)

My guess is that there are far more PC game programmers than console 
programmers. Specifically, outside industry.

> >I have actually been thinking about writing an "OCaml for Games
> > Programming" book. I think there is a lot of scope for interesting and
> > unusual material in such a book and I think there are lots of possible
> > examples which would demonstrate the power of OCaml for general purpose
> > programming whilst also making wicked cool games. The downside is mainly
> > the lack of state-of-the-art OpenGL bindings.
>
> I would love such a book!

I'm not sure your 80e would justify another 4 months of my time but it's 
certainly interesting to hear. :-)

Would you be interested in educational software along these lines and, if so, 
for what platforms?

> It would basically have to touch on every single 
> aspect of FP programming I do not yet know how to do. And it would probably
> teach me to think more in FP way, since game programming is much closer to
> my daily programming than algorithmic issues (those I can cleanly write in
> FP.

Given that games programming has quite a few parallels with scientific 
programming, I think you will find my OCaml book instructive:

  http://www.ffconsultancy.com/products/ocaml_for_scientists

> And I have even written a compiler; those are easy to think in FP 
> terms).

There are many resources on interpreter and compiler writing, of course. 
However, I don't like most of them. I do like Appel's, Xavier's, Cardelli's, 
Peyton-Jones' and several others (I'm reading Torben Mogensen's) but I have 
yet to see a killer treatise on this, particularly because the current 
documents either assume too much knowledge for a passing outsider or because 
they are too vague about implementation details (e.g. Cardelli's papers on 
static typing and even Appel's ML book) for people who don't really know what 
they are doing. So compiler and interpreter writing is my other idea for a 
book... :-)

> And I don't think you'd need state-of-the-art OpenGL bindings to write a
> good book on the subject. The problem is in the high level, mostly. The low
> level bindings are relatively straightforward to do.

I agree with you up to the last sentence. I've tried to write low-level OCaml 
bindings to OpenGL and it is very difficult if you are a pedant like me and 
want to do it properly.

> A shameless plug; a game I've written for this years Assembly demo party:
> http://fpb.xmunkki.org/
> The reason I bring this is up is that is uses OpenGL. And all it need is
> textured triangles with two different blending modes (normal alpha and
> additive). And I've played many fun games with only flat shading :).

Absolutely. I think there is a considerable market here.

> The general issue here (I think) is that most programmers are unfamiliar
> with the FP style of thinking (about problems). That's why most of them
> never even try, except by accident.

I think there is also a mental barrier to the weird and wonderful world of FP 
for many game programmers (and similarly for scientists). However, most C++ 
programmers know that gratuitous use of const is good practice without 
noticing that it is purely functional programming and most C++ programmers 
would write vector/matrix computations in a purely functional style.

> >I think there is ample market for a games programming OCaml book but it
> > would be difficult to sell it at a low enough price (again, I think it
> > would really benefit from being full color).
>
> I'd be willing to pay about 80e for such a book.. But then again, it's a
> book I've been looking for a long time.

What you need is a consultant. :-)

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