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