Game Du Jour

TrackBalls: a Marble Madness clone for Win32 and Linux (and from what I see, could easily port to Mac OS X). Marble Madness was one of my favourtie arcade games ever, so I expect this one to result in quite a bit of lost productivity..

BlogTidy - HTMLTidy for Blogger

I've been spending my time knocking together a version of HTML-Tidy that understands Blogger block tags. It's an out and out hack, but it seems to work ok, for all it's potential template mangling properties that might be a consequence of redefining the blogger tags to be part of the table content model.

If you are feeling brave, the sources live here and the binaries live here. Note that you will need SCons to build it, although modifying the SConstruct script to your taste should be trivial.

Language Comparisons

Lisp.
Python.
C.

I found it interesting that the LISP forced me to decompose the code into much smaller functions. You can see just how radically *different* LISP is, and you can see the parallels between Python and C that make the two languages such a close fit, including the fact that Python delegates much of the performance - related work to C...I'll add Java, C++ with the next post; but it does highlight the fact that LISP is a completely different approach to the process of compiling and composing programs when compared to block - structure of languages like Java, C and Pascal. I'm not sure that this is the best illustrative code possible. I think something animating a set of different but similar objects - boids, would be the best test case to see if a language is "game-worthy"..does anyone have any more suggestions?

Incidentally, in the course of preparing this post, I discovered the insanely handy TOhtml vim plugin for tranforming source code to HTML. I wonder if Emacs has anything similar?

Language Complexity

"Simple things should be simple. Difficult things should be possible." This is the hallmark of any good computer programming language. If it is hard to do a simple thing, then the language is poorly designed.

I don't know who this quote is attributable to, but it is language design in a nutshell. The devil, however, is in the details, as ever. I'd like to start this series of posts about language complexity by taking aim at two canards within the game development community:

One: Garbage collection is evil. There's a myth that garbage collected languages are unsuitable for game development because games are soft real-time applications and a decent framerate is one of their prime requirements. The pauses due to garbage collection are often cited as a reason for not using such languages as Java and Lisp or Python. Each has separate issues that are problematic for game development, but Garbage Collection isn't among them. Typically a soft real time game allocates all the resources it needs prior to entering a main loop and then does NO MORE ALLOCATION. It's at this point garbage collection is moot as no more garbage is being created for collection, providing the compiler has a mechanism for creating function-local variables on the stack frame or in registers rather than the heap - which both Java and Lisp compilers can do. So the recipe for a game would be: pre-allocate all arrays, globals, etc needed for resource tracking in the main loop, switch off garbage collection, make any heap allocations an exception (so they don't creep in by accident), then when the main loop (shooting the aliens, driving round the city, flying the spaceship, whatever) is done, switch off the exception and switch garbage collection back on. Yes, it's really that simple. It's dynamic allocation and heap walking that is the true problem for a soft-real time system..that's all. More information can be found in the Garbage Collection FAQ.

Two: Static typechecking is a win. Yes it is, but only in a language like C++ where the cost of compilation is HUGE. Compile times of an hour were common on Driv3r. However, your typical Python or Lisp program is composed interactively, and run instantly. In this case, pushing type checking to run-time is no big loss. Which is Python's approach. The other approach is the Lisp approach - to pick out a single, versatile data structure and operate on it as much as possible as in : "It's better to have 100 functions operating on 1 data type than 10 functions operating on 10 data types.". Further discussion of this can be found *here* on Bruce Eckels Weblog .

I'm going to follow up this post with the implementation of a name-generation algorithm in a number of different languages, starting with the original, in Python. It's better that the languages speak for themselves.