Re: [Caml-list] Games

[Jere Sanisalo <xm@xmunkki.org>]

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