Re: [Caml-list] Games

[Jon Harrop <jon@ffconsultancy.com>]

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. However, 
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 description, 
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 the 
Acorn). I deliberately used "fake physics" on all of them because real 
physics almost always leads to bad game play. You get more freedom with fake 
physics (anything goes) which does make it easier to break the code but I'm 
not convinced that this is a real problem. I think there are much bigger 
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 Theft 
Auto, Vice City (on PS2). That was quite sophisticed with LOD algorithms and 
so forth. It also had many bugs. After you'd been playing for a while it 
slowed down to a crawl (probably due to manual memory allocation ;-). It 
would also hang quite often (probably due to too much low-level coding).

From my point of view, there is nothing technologically difficult in that game 
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 
the code for the PC version without adversely affecting performance whilst 
greatly improving reliability. I see no reason to think that the console 
versions would not be similarly feasible, although it would require more 
work. Many games now use quite sophisticated LOD algorithms and OCaml is 
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 work,
> > > 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 
squeeze memory usage in C++ than in OCaml. So if I were programming for 
something with really tight memory requirements (like embedded) then I'd 
probably avoid OCaml. However, modern consoles have a lot more memory and, I 
think, with a little effort OCaml should be workable. If I were a console 
games programmer then I'd definitely want to play with a suitable working 
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 
programmer to get a working system up and running (provided ocamlopt already 
has a backend for the CPU). Given the potential savings, I'd be surprised if 
some games house wouldn't fund such work. Failing that, it would make a funky 
academic project. :-)

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