Functional languages in gamedev

Started by
29 comments, last by ApochPiQ 12 years, 4 months ago
Does anyone here use (or know of someone using) a functional langauge in gamedev? Any game that there's a remote chance I may have heard of?

A friend and I was having this discussion about languages when he mentioned Scheme. He posted some examples of scenarios where scheme was much simpler/cleaner [than <insert_imperative_language_of_choice>] and so on, in particular an algorithm to generate primes. While I may or may not agree, he can be right for arguments sake at least. My response was "the question is how nice and clean you can do something more practial.." to which he said that Lisp was invented for AI, so it should at least be able to handle that, and probably also physics..

I then asked him if he could name an example, which he couldn't. I'm guessing that's because there are none, (feel free to prove me wrong) but why is that? Education among developers (or lack thereof)? Lack of performant implementations? No significant advantage? Solution looking for a problem?
Advertisement
Well I'm using racket scheme to make small demos, though not a game. The advantages for are that it's functional, and has all the advantages that come with that (Of which I'm never going back to an imperative language for personal use). You can mix imperative code with functional, which is necessary for doing inputs and outputs, e.g. drawing graphics, loading files, keyboard input etc.

Also it has macros which allow you do add extensions to the language, e.g. I used this to make a system for loading and setting shaders.




(define (some-effect)
(effect
(attribute "a_pos" 0)
(attribute "a_nor" 1)

(uniform "a" 0.0 0.3 0.0)
(uniform "b" 0.9)

(vertex "
#version 150
attribute vec3 a_pos, a_nor;
uniform mat4 u_modelViewProjMat;
varying vec3 c;

void main() {
gl_Position = u_modelViewProjMat * vec4(a_pos,1.0);
c = abs(normalize(a_nor));
}")

(fragment "
#version 150
varying vec3 c;
uniform float b[2];
uniform vec3 a;


void main() {
gl_FragColor = vec4(c+a+vec3(0.0,b[1],b[0]),1.0);
}")))







The disadvantages are that you have to write interfaces to c shared libraries to do anything useful, e.g. latest version of opengl, physics, sound, window etc. Though some of the other lisps might have bindings for those things already (I know common lisp does, but I prefer scheme).

I'm currently in the process of writing a library that auto generates bindings from c header files (nearly complete), it uses macros so that you just make a module and call a macro from my library which when compiled will auto generate the bindings for you.

I have a feeling writing a physics engine in it wouldn't be as fast as one written in c/c++, but for a game, if all the intensive code is imported from c bindings leaving the the rest in scheme, it should be fine. 
Check out Land of Lisp!
About 5 years ago, Tim Sweeney (creator of the Unreal Engine) was making a lot of noise about Haskell/Erlang (can't remember which) being the next big language for game development, but AFAIK, they're still sticking with procedural C++/UnrealScript.

A search for his name + Haskell or Erlang might turn up some of these presentations.
Naughty Dog supposedly did a lot of their work using a language called GOAL, which was a customized version of Lisp. I've heard conflicting reports about the extent to which this was actually successful, including an old insider who told me that the public description of GOAL was pretty much BS. I'm not sure, but I know they did build a lot of the old games in it.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
If I were to pick a functional language and try to write a game in it right now, it's probably be Scala. Scala actually has a mixture of functional and procedural/OO paradigms, but it is heavily influenced by Scheme/Lisp in its idioms. The good thing is that the language compiles down to Java bytecode to run on the JVM (and can utilize any Java class library), and there are a bunch of Java libraries for game development, so it might actually work.
I think the main barriers to adoptation as a game language are functional purity; its hard to think of a game where you wouldnt want to mutate state at some point (and do it efficiently). I know you are supposedly able to do all this in functional languages, but give me set_pixel(x,y,color) any day of the week.

On a related issue, most successful game languages have relatively smooth interoperability with C.

The only way I could see myself using a functional language in a game, would be if I was making the game in C#. The seemless interoperability of F# with the .NET platform is a pretty awesome thing.

About 5 years ago, Tim Sweeney (creator of the Unreal Engine) was making a lot of noise about Haskell/Erlang (can't remember which) being the next big language for game development, but AFAIK, they're still sticking with procedural C++/UnrealScript.

A search for his name + Haskell or Erlang might turn up some of these presentations.


You mean this? He talked about Haskell's advantages but said that the syntax is not accessible enough for new programmers. It was essentially a call for a new, practical and easily accessible functional PL.
Andrew111, check out SWIG. I haven't had an opportunity to use it yet, but it looks like a solid project for auto-generating wrappers. A quick check shows that they support Racket.


The disadvantages are that you have to write interfaces to c shared libraries to do anything useful, e.g. latest version of opengl, physics, sound, window etc. Though some of the other lisps might have bindings for those things already (I know common lisp does, but I prefer scheme).

I'm currently in the process of writing a library that auto generates bindings from c header files (nearly complete), it uses macros so that you just make a module and call a macro from my library which when compiled will auto generate the bindings for you.
There are thousands of 18-year olds who have 5 years of experience in C++ (because it's fast) applying for every single job to work 90 hours a week at minimum wage.

The odd math PhD that benefits from functional programming is a poor fit in such environments. And they'll probably apply at Wall Street anyway.


On technical side, graphics APIs, due to being defined in C and based on legacy of decades of C usage aren't perfect fit. Functional programming also produces non-deterministic running-time results, which isn't a problem when expressiveness is concerned, but is a big deal for real-time systems. There is also dire lack of tooling. So even if functional approaches are used, they need to be watered down. Finally there's deadlines. With project development cycles ranging from 1 year and down to 2 weeks, there simply isn't time for experimentation of any kind. There is essentially no new tech being developed outside of middleware and research companies and for something to be used it needs to have a track record of several years to demonstrate real world maturity.

This topic is closed to new replies.

Advertisement