[cl-faq] Why does Lisp suck for Games?
Justin Heyes-Jones
justinhj at gmail.com
Fri Jan 6 08:09:17 CST 2006
On 1/6/06, Paolo Amoroso <amoroso at mclink.it> wrote:
>
> Justin Heyes-Jones <justinhj at gmail.com> writes:
>
> You might consider adding a little plug, and say that joining the CL
> Gardeners project might help improve the situation of Lisp libraries...
>
>
> Paolo
> --
> Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
> _______________________________________________
> cl-faq mailing list
> cl-faq at lispniks.com
> http://www.lispniks.com/mailman/listinfo/cl-faq
>
\faq{
\question{Does lisp suck for games?}
\answer{
99.999% of video games are written in C++, often with a small amount of
lower level assembler and
graphics processor code as well. So could console games and modern high
performance video games be
written in lisp?
The simple answer is yes they could, in fact they have. Two of the biggest
selling games ever; Nintendo's
Mario 64 and Naughty Dog's Jak and Daxter both used lisp very heavily in
their development.
One of Naughty Dog's MIT cofounders, Andy Gavin, wrote a language for
writing video games called GOAL. GOAL's
compiler was an Allegro CL program which took GOAL source and output
executable code running on the Playstation 2.
By doing this and having 'cons-less' code that had explicit memory
management rather than a garbage collector
they were able to utilise the benefits of lisp whilst avoiding two of the
potential performance bottlenecks.
http://www.gamasutra.com/features/20020710/white_01.htm
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
Mario 64 was created using N-World from middleware pioneers Nichemen. This
tool set was created using Allegro CL.
http://www.franz.com/success/customer_apps/animation_graphics/nichimen.lhtml
These two case studies show that it is possible to create high performance
games with lisps help, but is it
feasible in a modern game studio?
There are problems holding it back:
Firstly game developers rely on large sets of libraries from game console
manufacturers and operating system
developers. These libraries come with documentation and sample code which is
almost entirely C or C++. In other
words, by not using C/C++ you lose a lot of shared code, legacy code and
code from other non-lisp studios.
Secondly there are not a lot of programmers that no lisp, or that are wildly
enthusiastic about learning.
Thirdly, managing garbage collection and cons'ing to keep performance and
memory budgets requires great knowledge
of lisp. Whilst it does take some time for a C++ programmer to come up to
speed, the language is a lot more raw
and low level, it less often a mystery what is going on under the hood.
None of these issues should prevent a lisp friendly studio from adopting
lisp however, as some of the advantages of
lisp are particularly advantageous to game development:
Interactive and rapid development - Since the fun aspect of a game is very
subjective Game Development has to be very
fluid. Systems are written with future change in mind. With lisp it's
possible to connect to a running game and change
not just the data but also the code.
Functional paradigm - Since lisp can be used as a purely functional language
it has the potential to be used as a
concurrent programming language with highly parallel processes running.
Modern consoles have several CPU and GPU's
and ways to use multiple CPU's are only just beginning to be explored.
Competitive advantage - Potentially by using the positive aspects of lisp
and avoiding a lot of low level issues
a competitive advantage can be obtained both in terms of product quality and
on-time delivery.
If you're a lisp enthusiast and game developer consider joining the
cl-gardeners project, of which this FAQ is
a part.
http://www.lispniks.com/cl-gardeners/
}}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lispniks.com/pipermail/cl-faq/attachments/20060106/2ed8305e/attachment-0001.html
More information about the cl-faq
mailing list