Pre-Conj Interview: Zach Oakes
Talk: Making Games at Runtime with Clojure
Zach Oakes' talk at the conj is about making games in a dynamic programming environment.
Background
Clojure, and Lisps in general, are famous for dynamic programming. That means being able to modify the program as it is running without restarting it. Wouldn't it be nice to develop games in this way? It seems like the perfect fit, since video games are so visual, you'd want to see what your code changes look like very quickly. This talk will explore this. Nightmod is a development environment written by Zach Oakes to modify a game in one window while it is running in another. It is based on the play-clj library, which he also wrote.
Why it matters
Game programming is a huge industry dominated by static languages with long code-compile-run cycles. Games cost millions of dollars to make, so even small improvements in developer productivity can save lots of money.
But further, games are hugely complex systems that are often on the cutting edge of programming. Functional programming has a lot to say about complex systems, yet there has not been a lot of functional programming in commercial games. The domain is ripe for exploration and discovery.
About Zach Oakes
You can support Zach Oakes at Gratipay.
Introduction
I had a conversation with Zach Oakes about game development in Clojure. He is giving a talk at Clojure/conj. Read the background to his talk.
Interview
PurelyFunctional.tv: Briefly, how did you get into Clojure?
Zach Oakes: Being hosted on the JVM was my original draw to Clojure. I wanted to hack on an anonymous networking project called I2P, which is written in Java, but I wanted to use a more enjoyable language. Clojure's interop made it effortless, and later on I came to enjoy the other aspects of Clojure as well.
PF.tv: How long have you been into games programming?
ZO: Games were how I originally got into programming as a teenager. However, I had a ten-year period where I did nothing but crypto software. I only got back into games last year, and since Clojure was my favorite language by then, it was inevitable that I would start using it for game development.
PF.tv: What is the main concept of play-clj? Is it based on immutable game states, or something else?
ZO: The main technical concept is that most of your game should just be list transformations, so your code mostly consists of using normal Clojure functions to transform your entities. It definitely encourages immutability, but since it builds on top of a Java framework, there are times when you will need to mutate things.
PF.tv: What is the advantage of using list transformations instead of mutating game objects? Is this a drastic departure from normal game architectures?
ZO: The advantage of functional programming in games is the same as in other kinds of software; the code becomes simpler to understand, and parallelism becomes trivial. I think this is very unusual for game development. Many games keep entities as class data members that the methods mutate directly, which quickly becomes a mess.
That said, I think the REPL is by far the biggest reason to use Clojure for game development. A disciplined programmer might be able to avoid the aforementioned mess, but it's hard to replicate the runtime modifiability of Clojure if your language wasn't built for it, and I think it has a big effect on how you make your game.
PF.tv: What kind of response from game programmers have you had to using functional programming in games?
ZO: So far the response to functional game development has been tepid. They are understandably conservative about their technical choices due to the performance sensitivity of games, but nonetheless they are slowly adopting functional idioms in their non-functional languages. The next step is to get them to use a functional language. I think it's up for grabs, and the languages that are hosted and provide an excellent REPL will have the advantage.
PF.tv: Can you tell us a little about play-clj? Is it based on a Java framework?
ZO: Yes, play-clj is essentially a big wrapper around libGDX, a popular Java framework. I used it to teach Java game development, and eventually made play-clj so I could use Clojure instead. It is a fairly thick wrapper and hopefully a nice teaching tool.
The core of the library is defscreen, a macro in which you provide
functions that will be run during various events like "on-show" and
"on-key-down". Making a game consists primarily of transforming your
entities in response to these events.
There is always a design compromise when you build on top of a large object-oriented framework, but I think it is crucial to leverage existing work to make it practical to use a functional language to build games worth shipping.
PF.tv: Yeah, I agree. Game frameworks have a lot of work put into them. Was it a challenge combining OO/mutable state with the Clojure functional approach?
ZO: It's definitely a challenge, and since this is the first library I've ever made I have been learning as I go along. I took some inspiration from neko, a Clojure wrapper for the Android API, since it is doing something similar. I don't try to hide mutations; most of the library is just a series of macros that allow you to use the underlying Java classes with a nicer syntax.
That said, you can at least keep your core game logic free of side-effects by deferring those mutations until later. In my play-clj games, I typically first map over my entities with a series of pure functions, then afterwards I do various side-effecting things like playing sounds and rendering. This allows me to trivially parallelize the pure portion of my code while also doing the necessary side-effecting things.
PF.tv: That's pretty cool. I've always wanted to program games, but every time I start, I get lost in a forest of spaghetti code. Have you found that a functional approach makes that better?
ZO: I think it definitely imposes discipline on your game's code. It is easy in Java to make your entities and other objects data members in a class and mutate them from methods without even explicitly passing them as arguments, which is an easy path to spaghetti code. In play-clj, entities are records so transforming them requires explicitly passing them to functions and returning new ones at the end.
I would say that play-clj also imposes an additional degree of structure as well. It has its own built-in system for managing state, including its own entity system, which is exposed to you in the defscreen macro. I think this causes play-clj games to essentially have the same general design. The downside is that it makes a lot of design decisions for you, so more advanced Clojure programmers may desire a thinner wrapper.
PF.tv: What resources could a beginner use beforehand to make the most of your talk?
ZO: I wrote a tutorial for play-clj that people could check out if they'd like to see how it works:
https://github.com/oakes/play-clj/blob/master/TUTORIAL.md
There are also some example games they could play to see it in action:
https://github.com/oakes/play-clj-examples
PF.tv: Where can people follow your adventures online?
ZO: I don't do much social networking, unless Reddit/HN count. I suppose the best way to see what I'm up to is follow my Github!
PF.tv: One last question: If Clojure were a Star Trek character from the original series, what character would it be?
ZO: I suppose Clojure would be all the re dshirts collectively. It sounds like a bad thing, but when they died they were always replaced, so I guess that means Clojure will live forever.
PF.tv: Thanks for the informative interview. It was a pleasure.
*include: templates/pre-conj.html