Time will tell. Id's latest games tend to run on OpenGL engines, so at the end of the day, most modern rendering is done "under the sheets." The more games trend in that direction, the more clearly wrong Jon's prediction will be.

However, let me make an important observation. The capacity to code a "state of the art" 3-D simulation product is hardly the same as "Game Programming." As an old-fart gray-hair hall-of-fame game designer, I can tell you that, IMHO, game designing stopped almost concurrently with the advent of the first person shooter. For a ten year period beginning in the late eighties, products denominated as games were defined as Jon would have it. Ninety to one hundred percent of the computer resources dedicated to driving pixels, there was no way to design a game -- it was all in the visual heat. And a larger percentage of financial resources dedicated to the art than to the coding. In short, much eye-candy, little game. Mid-nineties began a sea-change away from that. Hardware assisted cards generating far better and deeper rendering than the most Abrashed of optimized code, game makers used the hardware. Suddenly, they had resources they didn't know what to do with. Lo, and behold, they started making games again.

The hardware will likely stay way ahead of software mechanics for quite awhile, and thus a premium will soon be placed on Game Programming rather than rendering mechanics.

Here is where Squeak and comparable languages can shine. Better, deeper, more perfect games are possible in a language where better, deeper more perfect ideas can be better expressed.

Game Programming in Squeak will DEFINE the state of the art, in a way that pixel pushing of the past could never conceivably accomplish.

On Wednesday, October 31, 2001, at 03:06 PM, Jon Hylands wrote:

On Wed, 31 Oct 2001 10:10:57 +0100, Bruce ONeel beoneel@bluewin.ch wrote:

...

Along these lines there was a fairly funny post on comp.lang.c a few years ago between someone who KNEW that it was impossible to write DOOM in ANSI Standard C because ANSI C was way way way to slow. He got a response from some one named dmr@research.att.com who was complaining that it had absorbed all of the leisure time in his lab and yes it built with their ansi c compilers.

Be that as it may, I still stand by my (corrected) post saying that you will probably not be able to write a "state of the art" first person shooter (i.e., one that is directly comparable with id's latest game) in Squeak, at least not unless Squeak gets an order of magnitude faster than it is now (through software, not hardware).

Yes, hardware and graphics hardware gets better exponentially. But "state of the art" is a moving target, and as the processors and graphics chips get faster, the best games out there use it all up.

It wouldn't surprise me at all if you could write Doom right now in Squeak on today's hardware. When Doom came out, it ran really well on a 66 Mhz 486. A 1.5 GHz PIII is probably, what, 50 times faster?

I'd even be willing to bet you could write the original Descent game in Squeak right now. When it came out, it screamed on my Pentium 166.

But, like I said before, Doom and Descent are hardly state of the art...

Later, Jon

---

Jon Hylands Jon@huv.com http://www.huv.com/jon

Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com

On Wednesday, October 31, 2001, at 06:57 PM, Jon Hylands wrote:

I've emphasized this in all of my messages. Pushing pixels takes very little cost now, but scene management with today's complex levels and high polygon counts is the big hit.

OpenGL hardware doesn't help a single iota with scene management.

The last sentence is, of course, quite true -- most hardware support doesn't doesn't really hurt scene management.

Actually, unlike the inherently brute force processing inherent in pixel pushing, scene management admits highly complex and logic-deep algorithms. I disagree that the "big hit" is manifest in scene management as suggested, or that modern state-of-the-art games are even close to as processor-intensive as those of past years.

I had this out with John Romero a few years ago, when the technology mismatch for pixel pushing was not even close to the range today; at a time I took your position. He was trying to convince me that first-person shooter medium is destined to come beyond the processor-deep no-brain no-game doldrums in which it was buried; pointing out the particular technical changes that had already occurred. Having seen the insides of these games, I see now that he was right and I (then) and you (now) are wrong.

Game programming companies, the particular ones you described in earlier posts in fact, are desperately seeking to evolve from the graphics-deep technical skill pushers into a content-deep game design plant. They realize that the time for game mechanics (in the auto mechanic sense) is the past and game mechanics (in the game design sense) is the future.

Jon's argument ignores reality -- and more significantly the particular lesson that Alan and crew taught us more than twenty years ago. When bitblt technology was considered deep dark magic, the idea that it could be delivered in a full GUI interface from a uber-slow, memory-managed byte-coded p-machine was ludicrous. But they did it, and on machines many orders of magnitude slower than a Palm hand-held. The model of identifying complex hunks of technology as data-driven primitives and executing them is enormously powerful.

Jon's nihilistic suggestion that Squeak is incapable of doing ubergames is, IMHO, naive.

Hi.

Just a few cents. Games do not need to have extraordinary gfx to be good. Example: the Atari Tetris arcade machine. Moreover, games do not necessarily have to be simple if they don't have extraordinary gfx. Example: chess.

Andres.

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

That's nice to hear! BTW, some serious stuff has been done to make CLOS capable of being very efficient. Most of these will work well in Squeak, should we choose ....

Cheers,

Alan

----- At 9:43 PM +0100 11/1/01, ducasse wrote:

Hi

Just to mention that Crash Bandicoot was develop in CommonLisp look at www.franz.com

Naughty Dog Software Application: Crash Bandicoot Game System Crash Bandicoot is the latest game release from Naughty Dog Software, Universal City, CA. The game is a popular Sony Playstation release. Naughty Dog used Allegro CL for the character control portions of the game. The character control and AI written in Lisp enabled the development of over 500 different types of game objects, each with uniquely crafted and tuned gameplay and visual characteristics.

For the 3D addict I can also tell you that www.nichimen.com implemented (and I believe still does) everything in CommonLisp (with image nearly 100Mb running on Silicon boxes). I was nearly working for them. But this is true that their libraries has been optimized to the cell consumption level according to the Lisp gurus I met at that time.

NICHIMEN Application: N-World Nintendo's highly successful game release for the Nintendo 64, Super Mario 64, was built using the N-World development tool suite from Nichimen Graphics Inc. Nichimen chose Allegro CL from Franz Inc. to develop its powerful N-World products.

It was really impressive for an academic like me to see CLOS and its MOP use for making really software ;)

Stef