Re: [Caml-list] Games

[Jon Harrop <jon@ffconsultancy.com>]

On Thursday 28 July 2005 02:12, Jere Sanisalo wrote:
> 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.

This is exactly the kind of thing that imperative OCaml programming is well 
suited to. Our software uses OpenGL to provide interactive GUIs and this 
level of the software is largely imperative. Almost everything "beyond" this 
is purely functional, which has many benefits in applications programming and 
probably in games too but I think it is a good idea to use imperative 
programming when dealing with state machines which the user pokes into 
different states.

> 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.

These kinds of numerical algorithms obviously have a lot of parallels with 
scientific computing and I have found that higher-order functions tend to be 
the dish of the day here. Lots of numerical algorithms can be implemented 
much more elegantly with judicious use of HOFs. Once again though, there is 
little published work on this.

> 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.

Yes. It sounds as though a redesign from an OCaml point of view would be 
useful. You may well find that a lot can be done with the "bags of data" by 
simply including functions (closures) in the data.

> 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)

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, i.e. at 
any given point in the code the OCaml object's type is on a need-to-know 
basis, so it doesn't know about all the others until it is "pulled together" 
at the end.

> > 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.

Yes, I doubt anyone here has used their language on a console but there is a 
lot of interesting non-console stuff to discuss.

We're in the early stages of writing an interpreter for a domain-specific 
language for 2D and 3D vector graphics designed to simplify the task of 
diagram generation for technical presentations (as part of Presenta).

> > 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?

And I suspect that a lot of people would cite that as an example of doing too 
much low-level stuff. :-)

> 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.

That isn't really surprising given how difficult it is to write a decent GC. 
It may even be as difficult as writing "mathematical software". ;-)

> 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.

Yes, this is the kind of games programming that OCaml is least well-suited to.

> >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?

Very few, but does that matter? They can still buy products and develop code 
that you guys can use.

> 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.

For games overall, I can't see PC games going anywhere.

> But no matter what, FP is not something a new programmer starts to look at
> first.

Some people start programming when they reach university. Many universities 
teach FP in their first year, AFAIK. That's where I discovered ML.

> >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.

True. I have quite a few games programming books on my shelves here. I think 
lots of people enjoy reading such books even if they never end up writing 
games professionally.

> >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.

I think you're going to find it very difficult to get information on how FP 
can help with projects that big because there is such a small overlap between 
games and FP at the moment. You may find a little about small games written 
in functional languages. That probably ends with Spaceman Spiff though.

> 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 :).

I meant what platforms would you like the educational software to run under, 
rather than what platforms should it describe. :-)

> 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.

I suppose it would be feasible to have a low-volume high-cost tutorial along 
those lines for console games. It would be quite a gamble for the author 
though.

> >So compiler and interpreter writing is my other idea for a book... :-)
>
> And it's a lot fun too! :)

Yes indeed! And I forgot to mention Eijiro Sumii's great work on minCaml:

  http://min-caml.sourceforge.net

> >> 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).

Yes, you'd be better off writing a thick wrapper in C/C++ and binding OCaml 
code to that.

> 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".

Right.

> >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.

That's just the first example. My other favourite example is how often do you 
use "+" vs "+="? Because the former is purely functional and the latter is 
imperative.

See, I've made a functional programmer out of you already. Now, how do you 
write a numerical derivative function (and no peeking at my free first 
chapter)?

> 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).

That is no stranger to a scientist, of course. :-)

> >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)

If I got a dime for every time I've heard that... :-(

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