Are functional programming languages suitable for graphics programming?

Question

Just very curious about this, from my own experience , all the graphic programming seems to C or C++ related. Like the Direct10X. Does functional programming language provide some sort of graphic library to develop video game?

Solution 1

You can use functional languages to do graphics/game programming just as in any other language.

It's only a simple game, but I wrote Ironclad: Steam Legions in Clojure as an exercise in functional programming for game development.

Here are some lessons I learnt / general observations on using Clojure for game programming:

• You need to be careful about performance as games can be very demanding and functional languages do impose some overheads. Clojure is certainly "good enough" for most games, but you need to know the tricks to keep your code optimised. For example, functional languages can get a bit GC-heavy producing a lot of temporary objects. You need to learn the tricks to avoid this (for example, using reduce in a way that avoids creating new sequence objects, or leveraging primitive artithmetic)

• Mutability is useful in games. For example, if you are doing anything with physics or smooth animation you often have a lot of objects with constantly changing locations. You can simulate this with functional/immutable data structures but if you care about performance it's not a good idea. Hence it's worth finding out how to get mutable data in your functional language even if it isn't idiomatic (e.g. in Clojure you will probably want to make use of Java arrays)

• Immutable persistent data structures actually turn out to be very useful in games as well. In Ironclad, the entire game state was stored in a single immutable data structure. This allowed for some cool tricks like efficiently snapshotting the game state / instant undos / running backwards in time.

• Clojure is awesome for game scripting. The dynamic nature coupled with runtime compilation and the ability to define arbitrary DSLs with macros is a massive win. In fact, even if I was writing a game in an OOP language like Java I would seriously consider using Clojure (or another Lisp) for scripting.

• Clojure is awesome for interactive development. I often found myself running the game in one window while hacking the running code in a REPL alongside. It's fun to alter game data structures and immediately see the effects! This awesome video also gives you a taste of what's possible with Clojure-style development.

• In Clojure at least you will often want to use the Java libraries for graphics, e.g. Swing for 2D or LWJGL for 3D. In some cases wrappers for these already exist, however I found it easy enough to use them directly from Clojure. After all, Java interop is as simple as (.methodName object arg1 arg2)

In conclusion, I think functional languages are perfectly good choices for game development, with the exception of very performance-intensive games where you are still likely to be better with C/C++ in order to have more direct control over the hardware.

Solution 2

This is a good series on the topic: (4 parts) Purely Functional Retrogames. You could take this approach in Clojure and use underlying Java game libraries to manipulate the graphics.

Solution 3

Probably no one cares about this now five year old question, perhaps not even the original asker. But as an old time graphics-in-Lisp guy, I wanted to weigh in. The title mentions “graphics programming” then the question asks about libraries for game development. Worth noting that graphics programming includes many topics unrelated to game programming. (So for example doing data visualization in Clojure would be an example of “functional programming languages suitable for graphics programming” but not game programming.) There is also a distinction between function-based languages (like Lisp, where everything is a function, but side effects are allowed) and languages that are purely functional with only immutable datatypes (like Haskell or Clojure).

There have certainly been Lisp-based graphics systems written in a “multi-paradigm” style, which is to say, not purely functional/immutable. For example, I worked at Symbolics in the early 1980s, when we produced one of the first “digital content creation” (like Maya or AutoCAD) systems entirely in Lisp. My 1978 MS thesis was about a Lisp-based domain-specific-langauge for procedural animation called ASAS. We used that at triple-I (Information International Inc.) to do very early CGI work for special effects in feature films, including 1982’s TRON. (That is described in this SIGGRAPH paper.) Finally the game studio Naughty Dog programmed the game logic of several titles (Crash Bandicoot, Jak and Daxter series?) with a Scheme inspired language called Game Oriented Assembly Lisp (GOAL).

Speaking about more modern efforts, and more strictly functional/immutable languages: “LambdaCube 3D is Haskell-like purely functional domain specific language for programming the GPU (graphics processing unit).”

In John Carmack’s keynote at Quakecon 2013, he spoke extensively (about 30 minutes) about his interest and experiments with purely functional languages for game development. His view seems to be that there are obvious benefits to using functional programming, but there are some challenges, and that he had not gone far enough down that road to have a strong opinion. He talks about experimenting with both Haskell and Lisp. This topic is between 1:17:00-1:49:00 in this video.

Comments

[castiel]

thank u very much, your answer is very thoughtful and detailed

[Voo]

Really, really fascinating video.

[endbegin]

@Mikera, if possible, can you elaborate on what you mean by "running backwards in time" when you talk about immutable data structures?

[mikera]

@endbegin: well it's very cheap with Clojure's data structures to keep slightly-changed copies of the whole game universe. Cheap enough that you can keep often keep a full history of the game in memory and step back in time / start replaying at any point. If you also keep a history of events (player actions, elapsed timesteps etc.), then your game state update can be done with a single (update-game old-state event) which produces the new immutable game state that shares most of the data with old-state.

[endbegin]

@mikera - thanks for taking the time to write back. I believe I understand the basic idea behind what you are saying. It would help me to see a bit of code to solidify that understanding. Perhaps I should post a new question on here, rather than hijacking this thread.

[Matt Wonlaw]

@mikera Is the source available for Ironclad?