From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 85B26D55E for ; Thu, 28 Jul 2005 02:15:42 +0200 (CEST) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6S0Ffig026559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jul 2005 02:15:42 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay03.plus.net with esmtp (Exim) id 1Dxw3m-0002XV-QU for caml-list@yquem.inria.fr; Thu, 28 Jul 2005 01:15:39 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Games Date: Thu, 28 Jul 2005 01:13:33 +0100 User-Agent: KMail/1.7.2 References: <200507272044.43231.jon@ffconsultancy.com> <20050727203535.GA30737@xmunkki.org> In-Reply-To: <20050727203535.GA30737@xmunkki.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507280113.34285.jon@ffconsultancy.com> X-Miltered: at concorde with ID 42E823AD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 low-level:01 high-level:01 high-level:01 higher-level:01 proportion:01 ocaml:01 syntax:01 ocaml:01 compilers:01 bindings:01 instructive:01 compiler:01 compiler:01 xavier's:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 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