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 BF41ED55E for ; Thu, 28 Jul 2005 23:14:54 +0200 (CEST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6SLEsnj019267 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jul 2005 23:14:54 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay01.plus.net with esmtp (Exim) id 1DyFiP-0000wu-2N for caml-list@yquem.inria.fr; Thu, 28 Jul 2005 22:14:53 +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 20:48:29 +0100 User-Agent: KMail/1.7.2 References: <200507280344.03323.jon@ffconsultancy.com> <1122526158.6769.93.camel@localhost.localdomain> In-Reply-To: <1122526158.6769.93.camel@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200507282048.29965.jon@ffconsultancy.com> X-Miltered: at nez-perce with ID 42E94ACE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 recursion:01 recursion:01 simulate:01 ocaml:01 low-level:01 ocaml:01 vastly:01 predictable:01 ocamlopt:01 funky:01 ...:98 monster:98 stone:98 frog:98 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 Thursday 28 July 2005 05:49, skaller wrote: > On Thu, 2005-07-28 at 03:44 +0100, Jon Harrop wrote: > > If the mutual recursion from having them "all know about each other" > > causes a problem then you can use objects to circumvent the mutual > > recursion, > > That isn't really the problem. Consider two fighters, with various > kinds of attacks and defences: what happens when A uses punch type P, > and B defends with action D .. taking into account other properties > like speed and strength.. now consider all the possible combinations: > it isn't possible to actually list them all. > > You also cannot simulate the real physics -- there isn't > time for a proper simulation. The terms "real physics" and "proper simulation" don't mean anything. Howev= er,=20 a modern PC can do a huge amount of physics modelling in real time (IMHO). > This problem is often handled by sending messages and > interpreting them.. and having a default. If the default > seems wrong, it is fixed. I'm still not clear on how this is difficult in OCaml. From your descriptio= n,=20 it seems very straightforward... > Crudely, you need an approximation physics that works > for the game: and this is what most games get wrong. > They don't actually design a physics, they do hoc > hacks left right and centre, and then the whole > system becomes almost impossible to manage. I disagree. I've written a few games. One was very popular (twoplay, for th= e=20 Acorn). I deliberately used "fake physics" on all of them because real=20 physics almost always leads to bad game play. You get more freedom with fak= e=20 physics (anything goes) which does make it easier to break the code but I'm= =20 not convinced that this is a real problem. I think there are much bigger=20 problems with some of the algorithms, e.g. getting stuck. > This is why simplistic games work, and more sophisticated > ones tend to be full of stupid bugs .. for example > casting a 'life leech' spell on an undead monster > or stone gargoyle .. the programmers forgot to > make a special case, and they didn't design > a workable physics either. One of the few games that I have really enjoyed in recent years is Grand Th= eft=20 Auto, Vice City (on PS2). That was quite sophisticed with LOD algorithms an= d=20 so forth. It also had many bugs. After you'd been playing for a while it=20 slowed down to a crawl (probably due to manual memory allocation ;-). It=20 would also hang quite often (probably due to too much low-level coding). =46rom my point of view, there is nothing technologically difficult in that= game=20 at all. I can see no reason for those bugs except poor programming. I think there is no question that OCaml could have been used to write most = of=20 the code for the PC version without adversely affecting performance whilst= =20 greatly improving reliability. I see no reason to think that the console=20 versions would not be similarly feasible, although it would require more=20 work. Many games now use quite sophisticated LOD algorithms and OCaml is=20 vastly better suited to this than C++. > > Yes, I doubt anyone here has used their language on a console but there > > is a lot of interesting non-console stuff to discuss. > > Felix has been used on an X-Box .. not really a console like > a PS2 but anyhow .. :) Impressive. :-) > > > 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 wor= k, > > > many hours on end. > > > > Yes, this is the kind of games programming that OCaml is least > > well-suited to. > > Why do you think that it is any worse than C++? C++ has much more predictable memory requirements and it is much easier to= =20 squeeze memory usage in C++ than in OCaml. So if I were programming for=20 something with really tight memory requirements (like embedded) then I'd=20 probably avoid OCaml. However, modern consoles have a lot more memory and, = I=20 think, with a little effort OCaml should be workable. If I were a console=20 games programmer then I'd definitely want to play with a suitable working=20 OCaml setup before using it in a production game, of course. I guess it would take 6 months of hard work by a single OCaml-familiar=20 programmer to get a working system up and running (provided ocamlopt alread= y=20 has a backend for the CPU). Given the potential savings, I'd be surprised i= f=20 some games house wouldn't fund such work. Failing that, it would make a fun= ky=20 academic project. :-) =2D-=20 Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists