It's not about technology for its own sake. It's about being able to implement your ideas.
Admitting that functional programming can be awkward drew a much bigger audience than I expected, so here's some insight into why I wrote it, plus some responses to specific comments.
I started learning some functional programming languages in 1999, because I was looking for a more pleasant way to deal with complex programming tasks. I eventually decided to focus on Erlang (the reasons for which are probably worthy of an entire entry), and after a while I found I was not only using Erlang for some tasks I would have previously used Perl for (and truth be told, I still use Perl sometimes); I was able to approach problems that would have been just plain nasty in C. But I also found that some tasks were surprisingly hard in Erlang, clearly harder than banging out an imperative solution.
Video games are good manifestation of a difficult problem to approach functionally: lots of tangled interactions between actors. I periodically search for information on video games written in functional languages, and I always get the same type of results. There's much gushing about how wonderful functional programming is, how games are complex, and how the two are a great match. Eight years ago I even did this myself, and I keep running into it as a cited source about the topic. Then there's Functional Reactive Programming, but the demos are always bouncing balls and Pong and Space Invaders--which are trivial to write in any language--and it's not at all clear if it scales up to arbitrary projects. There are also a handful of games written in procedural or object-oriented styles in homebrew Lisp variants, and this is often equated with "game in a functional language."
My conclusion is that there's very little work in existence or being done on how to cleanly approach video game-like problems in functional languages. And that's okay; it's unexplored (or at least undocumented) territory. I wrote "Admitting..." because of my own experiences writing game-like code in Erlang. I don't think the overall point was Erlang-specific, and it would apply to pure subsets of ML, Scheme, etc. It wasn't meant as a cry for help or a way of venting frustration. If you're writing games in functional languages, I'd love to hear from you!
Now some responses to specific comments.
All you have to do is pass the world state to each function and return a new state.
True, yes, but...yuck. It can be clunky in a language with single-assignment. And what is this really gaining you over C?
All you have to do is make entities be functions of time. You pass in a time and the position and state of that entity at that time are returned.
For a bouncing ball or spinning cube, yes, that's easy. But is there a closed-form solution for a game where entities can collide with each other and react to what the player is doing?
All languages suck at something. You should use a multi-paradigm language.
Fair enough.
You used the word "modify" which shows you don't understand how functional programming works.
If a spider does something that causes the spawn rate of ants to change, then of course the old rate isn't modified to contain the new value. But conceptually the system needs to know that the new rate is what matters, so somehow that data needs to propagate up out of a function in such a way that it gets passed to the insect spawning function from that point on. I was using "modify" in that regard.
permalink November 13, 2007
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?