Choosing Functional Programming for Our Game

In the last couple of months I have been learning how to program. The decision to sit down and learn how to code came inevitably despite my enormous efforts to avoid it up until now. As I mentioned in my previous posts, my plate is already full with 3D graphics, game design, marketing and business stuff, etc. And those nightmarish memories of the “Java for Biologists” course I took during my BSc degree might have also had something to do with it 😉 BUT I am the only one on our team that is working on the game full time, so I had to get over my distaste for ‘if’s and ‘for’s.

It hasn’t been easy. Extreme growing pains would accurately describe the situation- but I am getting to the point that I can handle our basic Unity scripting needs. I started off learning C# on Udemy (Programming for Complete Beginners and Learning to Code by Making Games which I recommend for designers interested in C# coding). The original idea was that I would script in C# and @spacepluk and @Morantron (our programmers) would script in Clojure. They LOVE Clojure- a Functional Programming language that can be used with Unity thanks to the Arcadia project (more about that below). Funny enough, I seem to find the logic of Object Oriented Programming a bit strange, and I naturally tend towards the Functional Programming way of thinking too. So we decided! Functional Programming it is.

Many programmers dismiss Functional Programming as a thing of the past (originally LISP was invented in 1958), or a strange aberration with weird syntax and tons of parentheses meant for academics alone. But we think that after the initial effort of learning the language, its benefits are well worth it and they pay off really quickly, especially in Game Development.

There were a couple specific features of Functional Programming that particularly appealed to us. First and foremost, simplicity. The code is shorter and more manageable. You express more with less code, and not by turning it into undecipherable gibberish but by making it more general and minimizing repetitions. That also means less room for mistakes 🙂 But when you do make a mistake reasoning about your code is a lot easier.

But the real icing on the cake is Live Coding. If you develop in Unity you know the pains of making changes: compiling, deploying, checking the result, rinse and repeat. Again and again and again. It is a time consuming and annoying process. It really gets in the way of creativity because you don’t have an immediate connection with the thing you’re creating (you should really watch Bret Victor’s video “Inventing on Principle” on the subject). Live Coding allows for really quick iterations. You change the program while it runs and see the results in-game immediately (yes, even on your phone!). Without compilations, redeploying to the device, going back to the screen you were testing, etc. Its amazing. Once you have tried it you won’t know how you lived without it. See for yourself:

Live Coding with Arcadia and Unity:

Live Coding with Arcadia and Unity (Android Phone):

So, how do we use Clojure in Unity? Arcadia is a project developed by Ramsey Nasser and Tims Gardner. It integrates Clojure and Unity 3D. As they describe it: “It brings a live coded, functional, dynamic, Lisp to the industry standard cross-platform game development tool.” There is an ever-growing community that is pitching in to help develop Arcadia and bring Functional Programming to a Unity Engine near you 🙂 Check out their repository and community discussion to see for yourself. And let us know what you think!

Thanks for reading 🙂




Choosing Functional Programming for Our Game

18 thoughts on “Choosing Functional Programming for Our Game

      1. I wonder if it’s because most of the programmers I’ve met have degrees in Computer Science or Computer Engineering, so they’ve been exposed to the concepts and have some idea of their value?

        1. Naw, that’s not it. We have plenty of programmers now without CS degrees, and I’ve still never heard them say FP is a thing of the past.

          I question the quality of the folks you associate with. 🙂

          1. liranjulia says:

            I didn´t say anything about quality, only whether people care or don´t care for FP 🙂 and whether they think it is archaic or not. No need to get held up on some sentence, that is definitely not the point of this post.

      2. “Many programmer dismiss FP as a thing of the past.” That’s true because many programmers a bad programmers with their heads up their asses with no understanding of their field. It’s a sad fact.

        The funny thing is that every programmer that makes that statement is programming with concepts from the same era.

        Anyway, It’s great to see interest in functional programming!

    1. liranjulia says:

      It doesn’t need to be. There’s a lot of ongoing work about better ways of dealing with state, see for example what David Nolen did with Om/React. A big part of the story is using immutable persistent data structures.

  1. DanilF says:

    You mentioned starting off in C#. One thing to note about C# is that it’s a multi-paradigm language. While they have great support for OOP, they also have very good support for FP, namely first class functions, closures, tuple types, etc. There are also several proposals to the language for expanding C#’s support for immutable data structures. I remember hearing about them introducing a “record” data type. I’m not saying to abandon Clojure or anything like that, but just letting you know that you can still use a highly functional style of programming in C#. Personally… I’ve found code nirvana by fully embracing both OOP and FP and using them together! =)

  2. ak says:

    Why not try F#? Considering Unity’s native runtime is .NET (and F# is a .NET language) and it has a REPL and everything else you describe. Wouldn’t it be a better fit and give you types as well?

    1. spacepluk says:

      hi AK, we did consider F# but there were several factors that made us go with Clojure instead:

      – Familiarity: We already knew Clojure and we’re very comfortable with it 🙂

      – Community: There seems to be more people adventuring into gamey stuff with Clojure. And in general Clojure’s community is bigger. Also, Arcadia’s community has put a big effort on making the ClojureCLR compiler work well with Unity’s ancient mono idiosyncrasies.

      – Full-stack: Another thing where I think Clojure has an advantage is that it’s a better alternative as a full-stack language. You could share code between the game and a Java backend for example and leverage all the server-side goodies that the JVM has to offer. There’s even a project that allows you to write shaders using Clojure.

      But yes, no built-in static typing. We’re fine with that though 🙂

  3. Very cool. I’ve been having a lot of fun myself porting a Java/OpenGL based game I did years ago to Clojure. Having the REPL and the fast iterative dev style is a real eye-opener. Good luck with your game!

  4. I enjoy what you guys are usually up too. This sort of clever work and exposure!
    Keep up the terrific works guys I’ve added you guys to my own blogroll.

Leave a Reply

Your email address will not be published. Required fields are marked *