Ask YC: Game programming in Lisp - is it possible?

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

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

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

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.

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

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.

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?

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

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.

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

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.

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

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.

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.

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)

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

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.

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

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.

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.

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.

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.

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.