Lisp discussion seems popular at the moment. But instead of focusing on why , I thought a discussion of how may be more useful. So, I "know" lisp dialects from University, and I''ve just "understood" how the lisp way solves all my problems in one elegant swoop. The question is, how do I go about applying it into realtime games? Thoughts welcome on the subject. Dialects It seems Common Lisp is a huge beast; is it feasible to consider including it in a PC or console game? Do the various object systems (CLOS) and other libraries that form Common Lisp have any benefit? I''m slightly more familiar with scheme, which seems better suited to games at the language can be packaged in 64kb apparently. You can also use third party object systems in scheme, but how would packages and namespaces work? Are the scheme macros just as useful as the ones in common lisp? Compilers & Interpreters Reading Paul Graham''s On Lisp book, it seems that a combination of compiled code and interpreted code provides the best balance of performance and flexibility. Are there any good toolkits that do both? It also seems that Scheme interpreters are better suited to optimization too (e.g. tail recursion). Do tools based on the GNU-GPL cause a problem for proprietary solutions? I presume including compiled code is fine from a legal point of view, but embedding the interpreter requires open sourcing the entire engine. See Scheme implementations in this FAQ. Examples Naughty Dog built their own Scheme dialect (GOAL) from Common Lisp, and built their entire game environment on Allegro CL, but apparently only their GOAL implementation is in the game engine. (Post Mortem here.) Bungie use lisp too (in Halo), but that''s about all the information I can find. The founders studied Scheme at Chicago Uni. apparently, so I presume they use Scheme of some kind. FreeCraft uses Scheme heavily too, but since Blizzard got upset with them, the code is nowhere to be found. Any hints there? Alex

---

AiGameDev.com

Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp

Specifications:

• Common Lisp the Language Second Edition
  
• ANSI Common Lisp Hyperspec (online specification)[Xanalysis Mirro]
  
• ISO Draft of ISO Lisp
  
  
• QLisp (Looks interesting)
  

[edited by - flangazor on February 26, 2004 11:12:15 AM]

quote:

---

It seems Common Lisp is a huge beast; is it feasible to consider including it in a PC or console game? Do the various object systems (CLOS) and other libraries that form Common Lisp have any benefit?

---

As much as C++ classes have any benefit :-) Well, CLOS is "slighly" more sophisticated...

quote:

---

I''m slightly more familiar with <a href="http://www.schemers.org/">scheme</a>, which seems better suited to games at the language can be packaged in 64kb apparently. You can also use third party <a href="http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/scheme/part1/faq-doc-6.html">object systems</a> in scheme, but how would packages and namespaces work? Are the scheme macros just as useful as the ones in common lisp?

---

For packages, consult your specific scheme implementation. For instance, PLT scheme has a functionality for dealing with MODULEs.

quote:

---

Reading Paul Graham''s <a href="http://www.paulgraham.com/onlisp.html">On Lisp</a> book, it seems that a combination of compiled code and interpreted code provides the best balance of performance and flexibility. Are there any good toolkits that do both?

---

SBCL, CMUCL only do compile, but you can still use them interactively. Their EVAL form just compiles and then runs the native code. There are some Scheme compilers, too (one that compiles into java byte code, I think).

quote:

---

It also seems that Scheme interpreters are better suited to optimization too (e.g. tail recursion).

---

Well, tail recursion is mandatory in Scheme, but every CL implementation I know of does it, too, so. Also, I think being a Lisp-2 has certain implementation/performance advantages, too.

I, personally, see no reason to implement a specific langauge as a scripting language. I like lisp, so I figured I''d base my language on the syntax and use the same data structures etc to retain the power of Lisp and just improvise everything else. (Well, not really, the reason I picked Lisp syntax is that this is my first parser and Lisp has a REALLY simple syntax, but I like the language too =-)

So what I did is read CLTL2 and started working from there, changing things as I felt like it and I''m now working on creating my own Lisp dialoct. Its not really any different than unrealiscript being based on C/C++, or php being a perl/c hybrid. Since scripting language usually don''t need the low-level power of C, Lisp just seems like a logical base for a high-level language that allows abstraction and elegance =-)

When/If I finish, I''ll (hopefully) have a nice language that suits my style and makes everything easier for me(since I''m the only one working on my projects). If it helps others, then that is great, but the goal is to get a usable scripting engine that implements the features (on both the native and scripting side) that I want.

Did i read that right, half a million lines of lisp code? It''s surprising, given Lisp is suppose to be a higher level language, where you do more with less. It seems they used lisp to write out every little micro-event their AIs do. Is that the way Lisp is suppose to be used? Couldn''t you achive the same goals with a custom AI scripting langauge?

Seems like Naughty Dog set out to use Lisp, no matter what. Though if they showed that Lisp reduced bugs, increased runtime performance, or producitivty, then it might have been a good investment. But given the code size comes out to an equavalient C++ project and the AI wasn''t that outstanding, I''m wondering where Lisp actually improved the process.

I think Lisp sovles some problems well, unforunately that problem set doesn''t overlap with games that much, currently. Perhaps that will change in the future.

-ddn

Steven Edwards (of the Edwards chess endgame database and chess data standards fame) is writing his own Lisp interpreter for a chess program right now. It only understands a subset of Lisp, so I guess it would be a Lisp dialect. The time critical stuff is written in C++ of course, and built into the interpreter.

His goal is to create a program that uses methods that are less brute force approaches, such as using pattern recognition and planning. He wants his program to only look at a few thousand or few hundred positions per second (as opposed to the state of the art programs which can look at millions of positions per second on a PC). His project looks very interesting.

Hmmm... If anyone trying to create their own lisp dialect is doing anything else but declare lisp functions and macros, they are missing the point of lisp entirely. You don''t need to even write your own parser, interpreter or environment as everything can be extended. Lisp is a programmable programming language (see On Lisp). Extrarius, it seems you''re just making another scripting language, but based on s-expressions!


To answer and elaborate on some of my original questions. Common Lisp is definitely NOT suitable for games. I''m pretty sure any game AI programmer would not be willing to sacrifice the memory needed to integrate the CL library and official extensions. So CLOS is not worth it; it''s not like C++ since you can replicate select features of CLOS in a few lines of code.


Scheme is the way to go for any realtime game. The interpreters are compact, and you wouldn''t do a much better job if you were to implement them yourself; they are pretty low fat! All of the interpreters will do compilation (it''s a standard keyword). The benefit in you can still extend scheme and turn it into your own game logic & AI language. You also build up the third party libraries you require -- instead of having to include the whole lot that makes the CL.

Feecraft used the GNU Guile, but switched to SIOD. PLT mzScheme looks very good too.

Alex

quote:

---

Original post by alexjc
Common Lisp is definitely NOT suitable for games.

---

That''s a rather broad assertion.

quote:

---

Original post by Woodsman
That''s a rather broad assertion.

---

That''s why it''s followed by two explanatory paragraphs!

quote:

---

Original post by alexjc
That''s why it''s followed by two explanatory paragraphs!

---

But you only explain why someone wouldn''t be inclined to use it (processing time) and then that scheme is best for realtime games. I don''t see how those statements prove that:

quote:

---

Original post by alexjc
Common Lisp is definitely NOT suitable for games.

---

So you use your assumptions about types of programmers and games as the platform for your assertions about CL.

quote:

---

Original post by alexjc
Common Lisp is definitely NOT suitable for games. I''m pretty sure any game AI programmer would not be willing to sacrifice the memory needed to integrate the CL library and official extensions.

---

Are there other kinds of programmers?

quote:

---

Original post by alexjc
Scheme is the way to go for any realtime game.

---

Are there other kinds of games?

---

If a plant cannot live according to its nature, it dies; so a man.

(princ(substitute #\Space #\0(format()"~36R"5688852237040631986030796883)))