3 ms·
I'd actually never read that series, although I had seen links to it a couple time. Just read through it and a few things should be pointed out: 1. The author
by zach 16y ago
I'd actually never read that series, although I had seen links to it a couple time. Just read through it and a few things should be pointed out:
1. The author has had second thoughts about his original conclusions:
http://prog21.dadgum.com/37.html http://prog21.dadgum.com/37.html
2. The author is constrained by the Erlang feature set. The author rejects out of hand the idea of using "structs", but Clojure's maps and records are easy to use, share data and would perform admirably.
3. The author is constrained by his retrogame and microsystem domain. No modern gaming platform has issues with game state using too much memory or generating too much garbage (exception: complex physics). In fact, data duplication is now a common game performance technique. But if your tastes run toward ultralean programming, this is a distasteful state of affairs.
4. Much of modern game development has moved to an increasingly functional dataflow model already because of the necessities of multiprocessing and network gaming. It's rarely elegant and never done in a functional language, but it's the current reality.
5. Games are one of the places where a sophisticated view of time, as Rich Hickey advocates in his fantastic JVM Languages Summit keynote, offers a lot of value. It's a problem that thoughtful programmers and designers in the game industry have often considered, but have been unable to innovate much in the current technological regime. I just rewatched the talk last week, in fact, and highly recommend it for game programmers who read Hacker News:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
- frou_dh 16y agoI like that talk. I saved the video a while ago and have watched it several times. His disambiguation of identity, state and value makes a lot of sense.
- zach 16y agoAs a game developer, the treatment of perception vs. presumed authority about the state of a system resonated with me. Trying to infer a state of a system, given observations that are already in the past, is something networked game developers are especially familiar with. Actually, Clojure would be a great host for a library that makes deriving a valid and consistent state from multiple observations in the past, something every networked game needs to do, more regular and predictable. That's often one of those "scary" parts of a game's code base. Things get pretty hairy, there is a lot of ad-hoc code, bugs are hard to track down and nobody wants to mess with it so it tends to get even cruftier and scarier.
- frou_dh 16y agoBut the use of an existing game engine or other substantial middleware might impose certain idioms on you. I worked on an MMO myself, though not on game logic. Anyway, I agree that Clojure's strengths being used in gamedev is an exciting prospect!
- zach 16y agoVery true, and ultimately why I think Clojure is a lot more ripe for nontraditional markets than expecting it to break into mainstream game development. There may be quirky and clever developers who put Clojure into mainstream game technology, but I think new platforms are where it can achieve the greatest leverage.
- frou_dh 16y agoSpeaking of that, my interest in big movie-wannabe games is dwindling rapidly, both as a player and career. Simple focused games and playthings are what I find myself admiring.