Re: [Caml-list] Games

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Donnerstag, den 28.07.2005, 04:12 +0300 schrieb Jere Sanisalo:
> >> 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)

Some times ago I wrote a little demo that could be seen as the beginning
of a 3D game: https://gps.dynxs.de/svn/app-3dflight/trunk/

There isn't very much design in it, and because of its simplicity, it
focuses on the rendering part. The key idea is that the various virtual
objects are represented by O'Caml objects that describe themselves. The
only relationship between objects is that they may collide.

I think the interesting part of this demo is the collision algorithm,
because two objects must somehow interact with each other. Actually, no
object needs to know any other object, but it can compute whether it
collides with a single 3D point (i.e. an abstraction of a second
object). This way, the algorithm can be separated in a "local part",
done by the objects themselves, and a "global part", which is the
overall loop. I don't know whether this idea can be applied to other
types of interactions as well, but from a general point of view it seems
to be the right direction to reduce the properties that objects expose
to other objects.

The demo also shows that the speed of the O'Caml code is almost
irrelevant; there is no difference whether you compile it to bytecode or
to native code. The speed of the graphics engine is very relevant.

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

It isn't that hard to port the O'Caml core to a new architecture
(provided the CPU is supported). The problematic part are the libraries,
and you need at least a good 3D graphics library. But if a company
invested in that, e.g. one man year, the resulting platform would be
quite attractive.

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

Exactly this requirement makes O'Caml attractive: you can change the
program frequently, and almost all update problems are detected by the
compiler.

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

For the hardware level it is definitely not a good choice. You need a
graphics API, be a standard one like openGL or a custom API.

Doing the bindings to O'Caml isn't very much work if you don't pass
complex structures.

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

Looks like this type of optimisation can be done in camlp4.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------