
Ask YC: Game programming in Lisp - is it possible? - gameprogrdr
Dear HN,<p>I have been programming small games in Java for the past 3 years or so and would like to expand my horizons by learning functional programming.<p>Is it possible to make games using something like Lisp (or another functional language)? Would there be any benefits as opposed to OOP?<p>For instance: say I want to make a pacman game. In java, you just have a bunch of objects that keep their state and thus globally keep the state of the game. Then you check for collisions etc. But in Lisp, you don't have state - so would that be possible to make pacman purely functionally? If so, how? And would there be any benefits?
======
silentbicycle
You can have state, several styles of OO, or even the worst sort of imperative
spaghetti code in Lisp. It's not a pure functional language like Haskell -- it
doesn't force you to write functionally, it just has excellent support for
using FP when it suits it the problem. The design of Scheme (a Lisp dialect)
_encourages_ functional programming, but it's mostly via things like naming
conventions -- functions which mutate state end in exclamation marks (set!),
for example. You may consider this nagging, but it's easy to ignore. It's not
a bad idea to know which parts of your program depend on mutating state,
though.

Good libraries, particularly multimedia ones, will be _very_ important.
Chicken Scheme has a great library collection (<http://www.call-with-current-
continuation.org/eggs/>) and works well with C. (Chicken compiles Scheme to
C.) Other people here strongly recommend PLT Scheme, though I haven't
personally used it much.

For learning functional programming in Lisp, I'd recommend starting with _The
Little Schemer_. After that, _The Seasoned Schemer_ and/or _SICP_.

I would also consider Lua under those circumstances. Game programming is one
of its strongest areas, and IMHO it is a very practical and well-designed
language. (Lua and Scheme are, by far, my favorites.) You can also do FP in
Lua, though it's not really emphasized, so Scheme is better suited to learning
it.

~~~
mjgoins
I agree with all this, but still haven't seen any large games in scheme. Some
folks made a first person shooter in haskell, however, apparently for a school
project:

<http://www.haskell.org/haskellwiki/Frag>

~~~
silentbicycle
Interesting link!

I think part of the issue is that writing a game in Haskell is a novel
challenge (it's running head-on into the weak points of the language), so the
people who succeed make a big deal out of it. I'm not saying they don't
deserve credit, but if they had used more appropriate language(s), the game
would be judged on its own merits, you know? Similarly, I find kkrieger
(<http://www.theprodukkt.com/kkrieger>) quite impressive. Not because of great
gameplay (I don't even _like_ first-person shooters), but because they fit so
much into 96kb.

Half the original post's question is about _learning_ functional programming.
That's one of the niches where Scheme trumps almost everything else, and I
also think Scheme is worth learning in general.

------
icosahedron
You can easily write games in Lisp. Since you write for the JVM, you may want
to look at Clojure (<http://clojure.org/>), since it runs on the JVM and gives
you access to the libraries you've already been using.

There are also ABCL (Common Lisp) and SISC (Scheme) if you want something
standard that still runs on the JVM.

~~~
flatline
I like what I've seen of clojure so far, and have written a couple small
programs in it for fun, with an eye towards game programming.

Plusses:

-JVM at your disposal

-STM for concurrency (haven't used this much yet but what it offers is nice)

-built-in collection types like you'd see in perl, js, python, etc., which is a much nicer syntax over the more traditional lisp dialects for those of us who aren't hard core lisp programmers.

-nice emacs/slime integration - REPL for debugging, etc.

Minuses:

-The language is still being actively developed and while most of the core features are there, there are some things that I've found missing and some things that are still changing (have had trouble with the project/module/package heirarchy a bit, would like metadata on anonymous functions).

-Debugging can be tricky, stuff will come up from the JVM without an associated line number in the clojure code, though I've seen a patch for this online

-Complexity added by the plusses. The java interop has a lot of power but it takes some getting used to. I also came into this with no recent java experience so YMMV.

-No native OO syntax, and I didn't want to write a hybrid of java/clojure code. Still, it has structs, and the idea (I think) is to use closures as the "glue" rather than objects.

~~~
markokocic
One cannot expect that a language that young as clojure is mature and stable.
Of course it changes, and it is a good thing thah all the changes are
discussed in the mailing lists in advance.

~~~
flatline
Yeah, I actually like the fact that it's changing, because it's improving and
it's interesting to watch a new language evolve in useful ways. And the
communication level on changes is very high. Just something to be aware of if
you're starting out...

------
feijai
I don't know how to say this without sounding like a troll, so I'll just come
out and say it: the people who have responded to your question so far sound
like they know a lot about Lisp or functional programming and rather little
about games.

You came to HackerNews, where all the functional programming boosters hang out
(myself included) and asked: can I use functional languages for X? What, were
you expecting an unbiased answer? To HackerNews, functional programming can do
X optimally, forall X.

All languages have tradeoffs, though it sometimes seems like we have yet to
face up to the tradeoffs in functional programming. But in truth, functional
programming kinda sucks for games, and the more functional it gets (that is,
as it approaches Haskell), the more it sucks. Because game logic is all about
the one thing that pure functional programming disdains with all its heart:
global internal state and side effects. The purer you get the more you have to
jump through hoops to manage this kind of stuff. So IMHO you're really asking:
can I learn a functional programming language by coding something which
functional programming is fairly hostile? And people here are responding:
sure, you'll love it! It's perfect for you!

Also note that real game programming is also often about speed and soft real-
time guarantees. Sure, games often have a high-level scripting language in
which certain gameplay elements are written. Lua, for example, is one popular
choice. Variations on Javascript are another. But if you're looking to _write
a game_ in a programming language, and need to eek out that extra bit of
cycles to do something nifty, most of the languages here are bad bad choices.
This is probably not something you care about since you're just looking to
learn, which I applaud. But it does tell me that boosterism is in effect when
people recommend Lua and Clojure and ABCL and SISC for game programming that
they've not considered, and they don't bother to tell you that these languages
are quite slow, for an environment (games) where speed really matters.

So if you're trying to learn a functional language by doing a game, I'd pick
the least hostile functional language that has highly portable graphics and
event support and which is decently fast. Ordinarily I'd say CommonLisp, but
ABCL's not there yet. One language in this category is Kawa, a JVM scheme
which can be optimized to run at a decent fraction of Java. PLT might be
another choice: it's not super fast but has very strong and portable
libraries.

~~~
silentbicycle
I agree with you ("Hey self-selecting community of lispers: Is Lisp a good
language for X?" is going to get a predictable reply), but half of the
original question was about learning functional programming. Separating the
two halves of the question would have probably got a more useful response.

Scheme is a good language for learning functional programming. (Haskell is as
well, but I would argue that several techniques the poster is likely to learn
from Haskell are difficult to use in non-lazy languages, and telling them
apart requires experience they probably do not possess. Also, Haskell is very
poorly suited to games, and (* dodges rocks* ) seems to me like a less
practical language overall .)

Also: Lua is fast (certainly fast enough for prototyping), and has a clear
migration path to C / C++ for libraries and the parts of the game that need
the raw speed. Something on the JVM (including Java, of course) may better
suit the author, since they are probably already familiar with many of the
relevant libraries, but I don't have much experience there.

------
woid
Abuse game logic was programmed in Lisp. This was the first time I saw Lisp in
a commercial game.

<http://en.wikipedia.org/wiki/Abuse_(computer_game)>

Any other examples?

~~~
gommm
The games from naugty dog software (crash bandicoot and others) were programed
in Lisp.

Unfortunately they were purchased by Sony and had to stop using Lisp... I
guess it's the same story as viaweb/yahoo store :-)

See :
[http://www.franz.com/success/customer_apps/animation_graphic...](http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml)
<http://c2.com/cgi/wiki?LispInJakAndDaxter>

~~~
doihaveto
Although in all honesty Naughty Dog used Lisp to write their own compiler from
a Lisp-based DSL into highly optimized Playstation assembly, and then wrote
huge chunks of the game in that.

Which is a little different from wanting to learn functional programming by
writing a game. ;)

------
dlweinreb
Take a look at InspireData (<http://www.inspiration.com/InspireData>). It is
entirely written in Common Lisp (<http://www.lispworks.com/success-
stories/inspiredata.html>). The creators of InspireData used Lisp for its high
productivity and ease of development.It uses native menus, drop-downs, and so
on, and is uses OpenGL. The customers never know it's written in Lisp. There
is no problem at all with garbage collection (i.e. no pauses that anyone ever
notices).

It's pretty obvious that since you can do this, a game like PacMan can also be
done. I don't see any obstacle to writing 3D games. Common Lisp has been used
for a huge range of kinds of application.

If you're looking for a languages with no side-effects in the same sense as in
Haskell, the Clojure dialect of Lisp is well worth looking at.

------
snprbob86
Quite a few large games have (or still do) use Lisp or Lisp-like languages for
scripting.

I work only a few offices away from the Xbox developer support team, so I've
heard a few war stories about game scripting. Artists and designers at one
huuuuge studio (I won't mention their name) have been using Lisp for runtime
tweaking of weapon, AI, and vehicle behavior (among other things) for well
over a decade without even knowing that it is Lisp.

Naughty Dog used their own GOAL (Game Oriented Action Lisp) for Jak and
Daxter, which you can read all about at
<http://www.gamasutra.com/features/20020710/white_02.htm>

I think the bottom line is that you need to use raw C/C++ for the fast core
graphics stuff, but once you stitch your engine together in a way that
supports easy COMPOSITION, then you need a scripting language. Most studios
with custom engines choose Lua or similar. Big engines like Unreal and Doom
use their own. Some clever teams write their own Lisps.

------
carlosrr
Lua is a multi paradigm programming language that is very popular with game
makers. There's also an engine written in Lua for making 2d video games called
Love <http://love2d.org/>.

~~~
sachinag
Lua is the _dominant_ language for AAA console games. If you are serious about
making games, you absolutely should learn Lua. It's a language usually
"learned on the job", which is why the industry is so incestuous and it's so
hard to break in.

~~~
silentbicycle
Lua is a tremendously well-designed language, IMHO, and it would be pretty sad
if people write it off as a serious programming language because the first
thing they associate it with is WoW.

It developed primarily for use as an embedded language, so the Lua authors
have kept the core very small. It's easy to use it with C, and to extend the
core with libraries written in C or Lua. Many things that other languages
require in the core can just be loaded as libraries. This means that (much
like Scheme) it makes for a clean foundation for interesting CS projects --
LPEG (<http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html>) is a novel
parsing/pattern matching system, there's a new library to add Erlang-style
concurrency (<http://concurrentlua.luaforge.net/>), LuaJIT
(<http://luajit.org/>) is a cutting edge JIT compiler, etc.

It's trivially portable to anywhere C is used, and is quite fast. It's also
distributed under a BSD license, if your company wants to use their own fork
internally (it's ~500k of source). You can also deliver executable files with
byte-compiled Lua embedded in them.

Stylistically, it's probably closest to Python, but with more Scheme influence
(tail-call optimization, coroutines, non-crippled "lambdas", etc.). It's
idiomatic to make heavy use of tables, which are very similar to Python
dictionaries.

The standard intro is _Programming in Lua_ (<http://www.inf.puc-
rio.br/~roberto/pil2/>). The first version (covering Lua 5.0) of the book is
free online, but there were some significant changes to the language with 5.1,
particularly the module system.

It has some downsides as a Language (the community, while nice, is rather
small, so sometimes documentation is sparse or scattered; it's generally
assumed you're already using C or C++, so the standard libraries have gaps
when using Lua on its own; the module system is still maturing (LuaRocks
(<http://luarocks.luaforge.net/rocks/>) is an attempt to fix this); etc.), but
picking any particular language always involves trade-offs. I've been quite
pleased with it.

~~~
sachinag
It's crazy that Lua gets a bad rap. At the end of the day, it's a key language
for the industry, and not just for MMORPGs.

~~~
silentbicycle
I don't think it gets a bad rap so much as that it's just not well-known
outside a few niches. (FWIW: I'm not in the game industry. I work with high-
performance rendered graphics, though, so there are similar concerns.)

(Also, MIT license, not BSD.)

------
michael_dorfman
Sounds like you want to read this: <http://prog21.dadgum.com/23.html>

------
TY
There is a Montreal based company called Gamerizon that is currently
developing a Scheme based game called QuantZ.

Check out their website for the demo video and screenshots of the game:

<http://www.gamerizon.com/>

Btw, they are now hiring.

------
lispm
See Ypsilon Scheme: <http://code.google.com/p/ypsilon/>

Ypsilon has been developed as a fundamental technology for LittleWing Pinball
Construction System.

More info:

<http://www.littlewingpinball.com/contents/en/ypsilon.html>

------
jamii
Fluxus ( <http://www.pawfal.org/fluxus/> ) is a scheme environment for live-
coding graphics. Its a brilliant way to get started with games programming
since you can modify code on the fly and see the results immediately. The
underlying graphics engine is written in C++ so you don't lose much
performance by choosing scheme.

------
krschultz
To get down to the nuts and bolts of it, does it have an OpenGL binding or are
you capable of creating an OpenGL binding? Functional programming is great for
the logic of the game, but you don't want to reinvent the wheel for
rasterization, its just not worth it.

Start here maybe? [http://shiny-dynamics.blogspot.com/2006/01/munching-on-
openg...](http://shiny-dynamics.blogspot.com/2006/01/munching-on-opengl-in-
common-lisp.html)

------
dgolden
Well, as other posters have pointed out, lisp is multiparadigm, not just
functional.

Anyway your question was more about abstract concerns, but concretely, note
there are pretty decent SDL and OpenGL bindings for common lisp, and mildly
optimised native compiled lisp code borders on "fast enough" for fast-paced 3D
games - I mean people write fun games in Python these days, never mind lisp!
even if GC is not concurrent, GC pausing is much less of a problem than people
make out with a little common sense and care, - prealloc object pools before
levels begin, code consless or at least cons-lightly, perhaps even go ahead
and disable GC runs except at inter-level breaks...

IMO CLOS is a very nice object system for game code in an object-oriented
style due to multiple dispatch (see wikipedia example):

<http://en.wikipedia.org/wiki/Multiple_dispatch#Common_Lisp>

<http://lispbuilder.sourceforge.net/lispbuilder-sdl.html>

<http://common-lisp.net/project/cl-opengl/>

When I last looked a while back (it might be neater now), the secret to
getting cl-opengl and lispbuilder-sdl to play nice together was the following
incantation, enabling use of opengl 2 shaders and stuff:

    
    
       ; N.B. don't use any ext. functions which go through GetProcAddress
       ; until AFTER an opengl sdl surface exists, presumably there's late binding going on...
       (setf cl-opengl-bindings:*gl-get-proc-address* #'sdl-cffi::sdl-gl-get-proc-address)

------
horia314
Hello,

There's a small thinking shift between writing a game in an imperative style
and writing it in a functional style. In particular, it's smaller, I think,
for games than for other kinds of applications.

In a typical game, you have a global state - a series of objects describing
the properties of the game world at a certain time. You continuously update
these objects, based on what input you receive from the user, and then present
those changes to him, by way of video and audio rendering.

In pseudoC it would look like this :

gameState s; int time = 0;

int main() { load_resources();

    
    
       while(!game_exit()) {
            get_input();
            update_state();
            render_video();
            render_audio();
    
            time = time + 1;
       }
    
       return 0;

}

Switching to a functional language, a way of thinking about the game flow I've
found useful is this :

The main loop becomes a function of two parameters : the current game state
and the current inputs. From these it computes the next state. After the
current simulation tick has passed, the next game state become the current
one, whatever video and audio you have is updated and new inputs are gathered.
It would look like this :

int main() { game_loop(load_resources(),init_inputs(),0); }

gameState game_loop(gameState currentState, gameInput inputs, int game_time) {
render_video(currentState); render_audio(currentState);

    
    
         game_loop(next_state(currentState,inputs),new_inputs(),game_time + 1);

}

Yeah, in C it will blow your stack, but functional languages have to deal with
recursion much more often, and what you see there will be optimised away to a
loop and be executed in constant space.

Other things to note are that you see the state passed explicitly between
functions (no relying on it inherently existing as a global) and that the
shift is from modifing an object as the game progresses, to creating a new
object to represent the new state of the world, and discarding the old one.

Languages, be it lisp, haskell, calm, scala, f# or python, java, c, c# (used
as functional languages) are relatively easy to learn. What's hard is adapting
your thinking to the strengths and limitations imposed by them.

Hope this helped.

------
stonemetal
First off lisp does have state. It isn't a pure language. That aside there are
several approaches. The easiest is to thread state that is have a function
that looks like update Worldstate = do userinput <\- getUserinput; Worldstate'
<\- updateworldstate userinput worldstate; drawworldstate worldstate'; update
worldstate';

------
Hexstream
Lisp is a multi-paradigm language. You can write code as imperatively as you
need with it. Use the functional paradigm "by default" and then revert to
imperative where it makes sense.

If you wanted to make a game in Haskell, which is purely functional, then your
concerns would be more appropriate.

------
speek
plt-scheme has a wonderful library for "world" programming. It allows you to
get user input and makes it relatively easy (although some of the terminology
is a little odd) to make things that move/do stuff graphically.
[http://download.plt-
scheme.org/doc/371/html/teachpack/world....](http://download.plt-
scheme.org/doc/371/html/teachpack/world.html)

------
doihaveto
I would actually recommend taking a look at Flash. With ActionScript 3, you
can write your game a very functional style - arrays have map and filter
operators, you can get events and pass them through chains of filters, etc.
And then you can just publish your game on the web for everyone to check out.

And by the way, you won't be able to do _pure_ functional game programming in
any language. At some point you'll have to bottom out in modifying display
state - whether opengl calls, or directx calls, or flash display list changes.

~~~
forensic
doesnt that apply to all applications with output besides the REPL?

------
JoelMcCracken
It seems that you haven't had the "benefits" explained yet.

Writing in a functional way allows you to express algorithms more easily than
you could otherwise. At any given point, while doing something functionally,
you only need be concerned about the state of your inputs and your output(s).
Letting go of state frees your mind from worrying about so many variables, and
it allows you to think about the algorithms more easily. Of course, it may
take a while to start to think about things functionally, but you'll have that
any time you are learning something new.

Another benefit is it makes things easily concurrent, which is a large
challenge for the game industry at large. Caveat -- make sure you know how
your language/implementation deals with this, however. Erlang is much
different than Common Lisp in this regard, for example (unless there is a
specific CL language with threads that I don't know about).

BTW, basically every lisp you'd ever use has objects, _or multimethods_
<http://clojure.org/multimethods> << basically the same thing, as far as it
matters.

Thus, Lisp, ML, etc allow you to use FP whenever it is beneficial, and allow
you to confine your state changes such that you won't have to worry about them
nearly as much. Thus, many fewer bugs.

I cannot encourage you enough to continue to look into this. My only concern
is that you will run into a lack of libraries, which clojure addresses, as
everyone has already mentioned.

------
mahmud
You need to take a look at PAL, a 2D game programming library built atop
OpenGL and SDL.

<http://common-lisp.net/project/pal/>

It even has a game written in it already:

<http://www.cliki.net/Bermuda>

I use SBCL with lambda-gtk, lispbuilder-SDL and CL-OpenGL. Couldn't be
happier. And oh, on Win32 and Linux :-)

------
eru
The pure,lazy, functional programming language 'Clean' includes a jump'n'run
in the examples:

[http://clean.cs.ru.nl/About_Clean/Platform_Games/platform_ga...](http://clean.cs.ru.nl/About_Clean/Platform_Games/platform_games.htm)

------
nitam
You might also want to read this :
[http://www.franz.com/success/customer_apps/animation_graphic...](http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml)

------
siong1987
IF you are coming from a Java background, I strongly recommend you to use
clojure. I have never tried clojure myself. But, it is a functional language
that is built on JVM. So, it basically supports all the JAVA library you may
have used before.

------
zitterbewegung
PLT scheme has a couple of demo games included in the distribution that you
might be interested in.

------
gameprogrdr
Thank you all for responding!

------
time_management
Since you're already familiar with Java, consider using Clojure, a Lisp that
runs on the JVM and therefore has access to all the Java libraries. Java and
Clojure have full interactivity, so if you need speed, you can always move the
performance-critical component to Java.

Haskell has "state", but uses monads (design patterns derived from the type
system) to segregate it carefully. Clojure has state, though "variables" are
immutable by default and state requires the use of special concurrency-safe
features.

