Re: [Caml-list] How to do this properly with OCaml?

[skaller <skaller@users.sourceforge.net>]

[-- Attachment #1: Type: text/plain, Size: 5845 bytes --]

On Wed, 2005-07-27 at 14:13 -0700, Pal-Kristian Engstad wrote:
> On Wednesday 27 July 2005 10:21 am, skaller wrote:
> > Just an aside-- but this is why
> > most games are utter crap. The developers have no idea
> > how to develop high level code, so they focus on weenie
> > details of graphics, and as a result we have stunning
> > high performance motion interfacing to the most banal
> > rubbish I have ever seen. As time goes by things just
> > seem to get worse.
> 
> Hi,
> 
> Skaller, that's one of the most sweeping generalizations I
> have ever seen.

hehe .. 

>  Exactly what kind of games are you talking
> about? 

My experience is with PC based games, not console.
Consoles are obviously limited by storage constraints.

> The gaming industry is big - I believe the latest 
> numbers indicate that we're bigger than the movie industry 
> w.r.t to earnings.

Yup, I think 4'th largest industry in Japan one year.

> I've been looking into O'Caml, and I've written some tools
> in it (caml is great for tools), but here's a couple of points 
> against it:
> 
> 1. It doesn't support console platforms.
> 	- The PC market is quite minor compared to consoles.

That is the fault of marketing idiots. The PC market
is in fact far larger and worth lots of money,
especially the adult market.

However, this is only evident where by luck someone
produced a good game for adults. One of my friends
works with Trainz, for example. It is basically owns
the world market for train enthusiasts, having killed
Microsofts offering.. and I can tell you train people
are all mad, rich, and there are a heck of a lot of
them -- hows that for another sweeping generalisation? :)

Some of these people spend $50-100 per week on this
single game .. that's a LOT of money. And the game
isn't going to die next week, like some fad game
for 14 year olds... it will keep developing
and growing for a long time.

> 2. It doesn't support low-level constructs.
> 	- No SIMD (AltiVec/VMX) vector operations.
> 	- No explicit assignment of (bit and byte) offsets 
> 	  within a record.
> 	- No explicit alignment specification.
> 	- No inline assembly.

It isn't necessary for higher level parts of a PC based game.
For a console, yes, you'd need lots of low level stuff,
but I have no interest in arcade games, which is about
all you can do on a standalone console.

That may change with unwired online networking, where
a lot of the engine runs on a remote server -- this
is happening with phones now so it may not be long
before online consoles (if not just your phone) are
the way to go: in this case most of the game
is running on a large server.

> 3. There is no controlled real-time GC. 
> 	- GC needs to run between frames, 
> 	  and only for a controlled amount of time.

That is open to debate. Ocaml uses an incremental
generational and very fast collector. I have played
plenty of games where the framerate varied, and the
game even froze up a bit sometimes, so it is not clear
that a bit of sloppiness won't be tolerated.

It also isn't clear manual memory management can
do any better. If you limit what you're doing 
for a console to a finite state machine, then
of course you don't really need ANY memory management.

As soon as you go to a more advanced game model,
you're going to need to split the video generator
thread off from the rest of the system anyhow:
the generator can provide a constant frame-rate
by running at a higher priority.

Fact is that most PC games I have played the programmers
didn't have the faintest idea how to get good frame rates,
in fact they couldn't even get double buffering to
work properly -- 2/3 games the mouse cursor is incorrectly
handled (and also on some Gnome/Linux apps too, it is done wrong).


> 4. There is no real support for unboxed data-types.
> 	- This one is actually very important for consoles.

There is some support, but not as much as you'd get from
C, C++ or my language Felix (which is designed for games
and uses C/C++ object model including unboxed types).

> For game-code (AI, behaviors, etc.), it is better suited, 
> though the GC issue is there. But it doesn't support much 
> of threading - be it through pthreads or cooperatively - 
> which renders it unusable to us. 

This isn't really correct. Ocaml certainly DOES support
pthreads, it just doesn't allow for multi-processing.

The bytecode interpreter actually DOES do cooperative
multi-tasking, using the same interface as the pthreads
in fact -- its pretty cool.

And of course you can design your own technique for
cooperation, although programming it can be painful:
the required control inversion is done automatically
by Felix.

> So in the end, ... ocaml is nice as a tool, but it is by far 
> not usable for the game console world.

Yup, if you have a small box with limited store, and you need
to spend a lot of time playing with the hardware, then
Ocaml may not be ideal -- you could look at Felix instead
(it is a C++ code generator, so it can be used WITH your
existing codes).

however for larger games, eg RPG or Strategy class PC games,
you aren't tweaking the hardware anyhow: you'll have an
underlying abstraction like DirectX or OpenGl to work with
instead. On that class of platform, Ocaml would be quite
competitive IMHO.

Again, if you have a need to interface with C/C++ have
a look at Felix -- it provides lots of higher level stuff
like first class functions, pattern matching, high performance
user space threading, and other things, while retaining
C/C++ compatibility (to see how you'll need to look: the
language syntax isn't compatible, but the system is
source compatible .. :)

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]