Lisp For Games

Lisp seems to me (a Lisp newbie as a matter of fact) a good environment for writing some portions of games software. I'm not yet ready to put forth any large description, but I have a lot of well-intentioned ideas bouncing around in my head at the moment.

A good first step is to read the PostMortem of LispInJakAndDaxter and the MarketingSpeak? at

http://www.franz.com/success/customer_apps/animation/naughtydog.php3

I'm still trying to form my opinions about what this all means to me. ;)

A good example of LispLanguage in games is the solitaire suite of GnomeDesktopEnvironment, in which the logic is written entirely in GuileScheme.

Here's a summary of most of my thoughts on this topic at the moment:

Most any game will benefit from the addition of an interpreted run-time language. To enumerate some of these benefits:
- Run-time prototyping of game logic (no engine restart required)
- Flexibility of certain interpreted languages to quickly implement generic logic algorithms.
- Most game code does not have to be optimized for speed (as opposed to the rendering, network, audio, io and path-finding routines)

I think many, including myself, would disagree with this. Especially in FPS, MMORPG, RTS and other games where millisecond delays have severe repercussions. The problem is games ALWAYS push the hardware envelope. Ones that don't are fine for your proposition, but it seems few are made these days. It annoys the piss out of me that game devs value graphics over performance, I always turn all of the graphic options off. I don't want jagged laggy frame jumps when I move a super-hi-res object.

No, the original comment isn't wrong. The vast majority of code in any non-trivial sized game will make no difference to this (unlike, as you not, turning on all the graphics options). The key point is whether or not the small amount of code that *is* important to performance can be made as quick as possible. This is impossible in many languages, and also why AssemblyLanguage is still used in small parts of many engines. It is possible to get very good performance out of Lisp, so it isn't immediately hopeless like, say, Python would be (as against a Python+C hybrid, or something).

Game logic can be notoriously ugly especially when you use the typical polling state machine approach (stored state with switch logic state transitions). This is a particularly slippery slope, one state machine begets another and another and another.
Lisp has a simple lexical construction with wonderful (some would say horrible?) capabilities of unity in code and data.
The rules of lisp make it a bit easier to implement things like micro-threads (I'm not schooled enough in the academics of continuations, but that's basically the idea. Correct?)
Although lisp is not purely functional it allows you to write functional programs which makes it possible to take advantage of recent hardware advancements (Ps3 Cell, Xbox multi core)
Many of the core data sets in any game engine are conceivably very easy for Lisp to process (RGBA and XYZW tuples)

So I would love to hear some feedback on what people think in this area. Most recent developments around GPUs and parallel hardware architectures target CeeLikeLanguages? (GLSL, HLSL). This makes sense from a market perspective, but perhaps new insights are available to those who will look to the past to understand the future.

In order to understand this space better I am looking into the following: Lisp based matrix math, Lisp based procedural geometry shaders, Lisp vertex and pixel shaders in general. Lisp micro threads and platform specific compilers and tools. What is required to build a full Lisp back-end for a game:

Run time environment
Compiler
Debugger

-- JacobRepp

Incidentally, I'm currently working on such a project: Genome, a 2D strategy game for Linux, implemented in Common Lisp. It's in its very early stages right now, but you can see what we've got at http://www.w00tism.net/genome. -- NickThomas?

My first thought at the prospect of using LispLanguage to write vertex/pixel shaders was that it was kind of missing the point a little, since at the end of the day these need to be complied to run on the GPU. However, using lisp as a way to describe vertex/pixel shaders (ultimately producing something like HLSL or CG) could be extremely powerful. It is quite common to hook together many different fragments of shaders - say combining shaders that do normal mapping, animating textures and soft skinning together. I've worked with a system that did this and it had to do all sorts of complicated stuff to map variables up, pass data between the fragments, work out the correct vertex format and so on. This could well be an area where representing the fragments as lisp programs that generate HLSL when executed would have been a nice way of looking at it.

It seems that someone is doing pretty much exactly what I was thinking of when I wrote the above. http://www.advogato.org/person/ingvar/diary.html

I know little about the subject, but it sounds as if you're talking about using Lisp to write a compiler for vertex shaders... And Lisp tends to be good at compilers, so. I still wouldn't write a game engine in Lisp, at least not one intended to be really fast, but I would definitely use Lisp as a scripting language...

Yes that pretty much is a compiler (or at least a preprocessor). In addition, though, I'd say that 90% of the work done in games these days is stuff that would be better done using a higher-level language than C++. There's going to be a core part of your engine where you want to be close to the metal - but I seem to spend all my time these days manipulating object hierarchies, dealing with metadata systems built on top of C++ and various other things where performance really isn't being considered as much as maintainability.

There used to be a related page GamesCompiler, that was later renamed to RethinkingCompilerDesign, but you might still find related material there.

CategoryLisp CategoryGame CategoryCompilers