>about using a functional programming approach to games in general Games are predominantly imperative in structure. Using a functional approach for writing an

>about using a functional programming approach to games in general Games are predominantly imperative in structure. Using a functional approach for writing an entire game seems like a bad idea. Can games be written functionally? Of course. Turing Completeness and all that. >"A Worst Case for Functional Programming?" I read the article. If the author didn't claim to have video game development experience I'd question whether he'd ever written a game; his examples imply the kind of AI that would be needed for a real-time game, but you don't just "move a tank" like 10 meters in a physics frame. Best practice has physics running at least 100FPS; probably higher rates like 1000FPS would be better. One tank being 1/1000 of a second farther along than another isn't going to mess with the AI. If the AI is running at a lower frame rate (making decisions only about 5 times per second, or even once per second, could be totally fine) means that the decision will just affect the acceleration being applied -- and would naturally happen in its own phase, so the state of the world would be constant for all participants. Actions like firing shells, if they can be dodged, are best batched as he suggested. But you still have huge problems like how to handle collisions, which is typically best done in some kind of object oriented way, though I've seen some clever pattern matching approaches as well that functional languages could support ("If a [VEHICLE] collides with a [SHELL], then do X; if [WALL] collides with a [SHELL], do Y..."), but even then each action needs to mutate something in the world. Which brings me to the fact that, for any nontrivial game, you pretty much need mutable data in order to get even halfway decent performance; you might be able to get away with lazy modification of a "world" data structure (copying it N times for N interactions in the world is absolutely going to kill game performance), but then you're again passing a "world" around to every single operation that anything can ever do -- and unless I'm wrong, every single "shell" and "tank" in the world is going to need to dig into the structure to find "itself" or the object it's colliding with in order to actually do the thing it needs to do... No, I stand by my assertion. Functional techniques can be useful in games, and I use them. Taking ideas from functional approaches to stabilize the game and simplify the code is an awesome idea. But trying to write a pure functional game is just a bad idea -- or an exercise in watching bears dance [1]. [1] "It's not about how well they can dance, but that they can dance at all"