Hi all - first post here - just a few comments about Squeak and games.
First, virtually all "serious, competitive, state-of-the-art" games use a high level scripting language of some sort. Squeak is an admirable candidate for this role, as it allows one to go well beyond traditional approaches toward scripting and do far more interesting things. We used Visual Basic on our last project and one of the companies I work with is using Lingo. Some people even write their own scripting engines. I think that writing a new language is more difficult than developing a new game engine.
Second, most games today rely on hardware acceleration for graphics. This include transforms and lighting and now shaders. Certain effects are done in software, but any good graphics engine designer usually searches for ways to use the hardware more creatively with blending methods, as anything that might effect the graphics pipeline (any software based special effects) has a serious impact on performance.
Third, another key to winning big is to precompute everything you can, essentially turning it into a hardware problem again. Much of scene management is about precomputing relationships (BSPs for example). High quality lighting is typically done with vertex based radiosity (precomputed) or light maps (just another static texture). Squeak may take somewhat longer to set up this data, but the end user never sees it.
That leaves the area between the hardware and the scripting where the bulk of the heavy lifting is done today. We know a few things about this (large) set of problems. (IMHO) most of this is working with large scale homogenous data sets. A few examples:
- Arbitrary transformations of meshes. (bones, multi-resolution meshes, ...) - Ray testing - Particle systems. - Collision detection. - Physics transforms. - procedural textures, shaders (already being done in hardware) - procedural geometry (fractals, l-systems) - Any kind of interesting simulation. - Scene management (in particular)
Traditional approaches (C++) hit a wall in precisely the same place that Squeak does, which is scaling up to deal with all of this data in an efficient way. The difference is just a matter of degree. But it is also clear that this is a fundamental bottleneck for any current approach. C++ just has the current advantage in being the best way to implement this stuff serially.
The hardware designers understand this issue and have been adding vector processing capabilities to the CPUs (Altivec, MMX, the two VPUs in the PSX2, etc), though these are still difficult to work with, typically requiring the developer to drop into some form of assembly code. This is made even more difficult in management of CPU/FPU/VPU resources which often overlap. (Andreas Raab and I found a problem with a collision between the FPU and MMX units on the Pentium that we still don't quite understand.)
What this means is simple. Squeak is extremely malleable at very low levels. Adding generic first class hardware assisted vector/matrix processing has the potential of allowing Squeak to even outperform existing approaches in a far broader, more generic way. Interestingly enough, this is not just about extending the language. It means learning how to form problems and design algorithms with true parallel processing in mind. A think that any good game engine designer already does this - he just doesn't get much support from the language.
Anyway, as you can guess, my opinion is that Squeak will make a fine next generation game platform.
David