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