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.

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

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.

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.

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.

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.

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...

If you're going to use the code tag, please be kind enough to wrap your sentences.

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.

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.

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?

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://c2.com/cgi/wiki?LispInJakAndDaxter

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. ;)

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.

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.

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/.

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.

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.

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.

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.)

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

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.

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.

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

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.

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...

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)

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';

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.

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....

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.

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

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.

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 :-)

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...

You might also want to read this : http://www.franz.com/success/customer_apps/animation_graphic...

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.

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

Thank you all for responding!

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.