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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 28EA2D55E for ; Thu, 28 Jul 2005 03:12:50 +0200 (CEST) Received: from naru1.oldskool.fi (naru1.oldskool.fi [193.64.190.82]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6S1Cnwa012683 for ; Thu, 28 Jul 2005 03:12:49 +0200 Received: by naru1.oldskool.fi (Postfix, from userid 562) id C05CE67005A; Thu, 28 Jul 2005 04:12:48 +0300 (EEST) Date: Thu, 28 Jul 2005 04:12:48 +0300 From: Jere Sanisalo To: caml-list@yquem.inria.fr Cc: Jon Harrop Subject: Re: [Caml-list] Games Message-ID: <20050728011248.GA10661@xmunkki.org> Reply-To: xm@xmunkki.org References: <200507272044.43231.jon@ffconsultancy.com> <20050727203535.GA30737@xmunkki.org> <200507280113.34285.jon@ffconsultancy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507280113.34285.jon@ffconsultancy.com> User-Agent: Mutt/1.4.1i X-Miltered: at nez-perce with ID 42E83111.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 handler:01 ocaml:01 proportion:01 ocaml:01 reuse:01 compilers:01 haskell:01 instructive:01 compiler:01 compiler: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 >Skaller flew off on a tangent because he was beaten by a low-level, >bit-twiddling games programmer as a child. ;-) Hey, that's how I became a games programmer in the first place! :D >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. True.. That's the problem with all terms, I guess. It's hard for me to relate how other people (especially scientific people) view it.. But just to say what I think about, it's all about the structure. How to build a framework where there can be several states, each of which is controlled by a different set of rules (think about menu screens and then think about a game area). The menus and the game are usually pretty related in terms of functionality, but the game (if a modern game; following from skallers outburst) has so many interactions it's hard to follow them. So the "high level" becomes how to really make a structure where you can easily manage your resources and define the wanted interactions between your game objects (but handle the unwanted also). It's hard to do that for even a simple game. Almost a highlevel problem, but in my game I gave the URL to, I'd need to somehow detect and handle the collision to objects. What really is a collision is the question. If an object slightly hits the other for 5 physics updates, is that a collisision. And ifit is, how to handle it. And so on. >> 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... Yeah, well as I see it, the more the pros find the tools to get closer to the FP style, the easier they have it. Not sure if it's FP or not, but one intresting idea for handling the game object behaviour was that each object was really just a "bag of data". And then there were many different handlers. An object might be subscribed to one or more of these. One handler might be "physics", one "rendering" and so on. So the data was separated from the implementation. This helped the people to isolate the implementation of different modules from each other. The handlers would only see the data they know the layout to, you see. So the object could contain whatever, and still be easily manipulated and extended. I'm still not sure how to do such a thing in FP languages (strictly typed, I mean). The plus in that was that they could easily add interactions to objects, without even thinking about other parts. And the object itself would not bloat with who-knows-what variables might come upon the development iterations. In ocaml I guess you'd need to make records of them all and make them all know about each other.. (that C++ solution was partly affected by the compile times) >> 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. ;-) Well how many of them have made a console game (or 3) with it? It's just that Naughty Dog managed to iron out the "hey this would not work with a console" things out. [GOAL] >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. Yeah, well how many people would write assembly with lisp? Because if I figure correctly, that's what they can do. And did. They wrote to the co-processors directly. And I think they didn't really have a GC in it. They just ended up to reuse the parts that are good and then end up doing it in imperative manner. I find this somewhat intresting. Why like this. I'm sure they had all the capacity and language to do it all. But maybe the tight performance and memory limits really hit the tone. I know when I'm doing console/mobile stuff, my memory and perfomance limits are REALLY tight. Sometimes all I have memory free is like 200kb out of 32mb total. And it HAS to work, many hours on end. >> (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. True, that.. But how many of them are doing it professionally? The console markets are increasing daily. The PC markets are growing thin and it's looking like soon there will only be a few big ones and a lot of sw/net companies. But no matter what, FP is not something a new programmer starts to look at first. It's something along the lines of C, C++, Java or C#. Or some scripting language. >> 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. :-) If there's one, there's bound to be another. >Would you be interested in educational software along these lines and, if so, >for what platforms? Well my point is to learn as much about FP as possible. So the software would help. Lately I've been looking at the Clean language (haskell variant, as I see it). They have IO and some games made in it, and it intrests me. But none of them are large and address the issues you encounter when the game takes more than 6 month to program by a team of 3 or more. And the platform is all the same to me. Of course, if it's a console platform, I can use the software to persuade others :). But if it's PC, I can use it to learn the paradigms and maybe some day think of a way to really figure out how an FP language should be made to support serious industrial games development. >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 I will look at it later.. Thanks for the link! >> 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. Well I've never read any (about FP, at least). But the thing is, compilers are fairly simple when looking at the high level. Each module has some input and some output. And it's completely linear. The problem, for me, comes when there are many interactions happening and it's not always completely sure what should happen and between what. (and these things tend to change rapindly during the development) >So compiler and interpreter writing is my other idea for a book... :-) And it's a lot fun too! :) >> 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. Yeah, well 1-for-1 probably wouldn't work.. But if I was doing a game with ocaml, I'd probably write my own wrappers for the platform I was using. I'm still not convinced that ocaml is the best tool for the close-to-driver/hw level, so it's easier and better to invent your own API (if you're doing a big game). As for doing educational software, an API that exposes "enough" is not hard, and it imposes the important points. Like "how would FP help me in writing games". >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. Actually I've never thought about const being "like FP". I do see it now, though. Damn you ;D. I've been an FP programmer longer than I thought =). Btw, some even do custom preprocessing for vector/matrix computation in order to minimize the runtime multiplications (for example concatenating matrix multiplications). >> 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. :-) I've yet to see a consultant worth his/her money :). (most I've seen just talk what the spit brings up, take their reward and drive away, leaving the team as lost as ever) -- Jere Sanisalo [xm@xmunkki.org] - http://www.xmunkki.org/