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. This problem is often handled by sending messages and interpreting them.. and having a default. If the default seems wrong, it is fixed. Play testing is essential here. The problem is basically that the interactions are covariant. 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. 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. > 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 .. :) > 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. > > 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++? -- John Skaller