It's not about technology for its own sake. It's about being able to implement your ideas.
In 1999 I earned $200 writing an essay titled Toward Programmer Interactivity: Writing Games in Modern Programming Languages. It was an early, optimistic exploration of writing commercial games in Haskell, ML, and Lisp.
It was not a good article.
It's empty in the way that so many other "Hey everyone! Functional programming! Yeah!" essays are. I demonstrated the beauty of Haskell in the small, but I didn't offer any solutions for how to write state-heavy games in it. There are a few silly errors in the sample code, too.
Occasionally during the following years, I searched for information about writing games in functional languages, and that article kept coming up. Other interesting references turned up too, like papers on Functional Reactive Programming, but apparently I had accidentally become an authority. An authority who knew almost nothing about the subject.
I still didn't know if a mostly-functional style would scale-up past the usual toy examples. I didn't know how to build even a simple game without destructive assignment. I wasn't sure if there were even any legitimate benefits. Was this a better way of implementing game ideas than the usual tangled web of imperative code--or madness?
As an experiment, I decided to port an action game that I wrote in 1997 to mostly-pure Erlang. It wasn't a toy, but a full-featured game chock full of detail and special cases. I never finished the port, but I had the bulk of the game playable and running smoothly, and except for a list of special cases that I could write on a "Hello! My Name is" label, it was purely functional. I wrote about what I learned in Purely Functional Retrogames.
Now when I search for info about writing games in a functional style, that's what I find.
Sure, there are some other sources out there. Several times a year a new, exuberant "Haskell / ML / Erlang is a perfect match for games!" blog entry appears. Functional Reactive Programming keeps evolving. A couple of people have slogged through similar territory and managed to bang-out real games in Haskell (Raincat is a good example).
If you want to be on the cutting edge of functional programming research, it's easy. Pick something that looks like a poor match for state-free code, like a video game, and start working on it. Try to avoid going for the imperative pressure release valves too quickly. At some point you're going to need them, but make sure you're not simply falling back on old habits. Keep at it, and it won't be long before you're inventing solutions to problems no one else has had to deal with.
If you come up with something interesting, I'd like to hear about it.
(If you liked this, you might enjoy Back to the Basics of Functional Programming.)
permalink May 8, 2012
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?