4 ms·

http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html I think trying make traditional computer games in functional languages is using the wrong too

http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html I think trying make traditional computer games in functional languages is using the wrong tool for the job, the author reached the same conclusion. Thats not to say that games aren't possible, they just need to be different kinds of games that are grown from the strengths of functional languages. There's also: http://landoflisp.com/ http://landoflisp.com/

jcw 16y ago
I've tried to write games in a pure FP style in Scheme, and, like Hague, found that the difficulty is in keeping track of state in a sane and efficient way. I suspect that Haskell's monads are a solution. Can someone with Haskell experience attest to this?
- zach 16y ago
  My favorite style, which I think maps well to functional use, is to have the entirety of game state (including random number seeds, etc.) be in one "world" data structure, call it W. Then, you collect all your input (say, controller axis values) into another structure, I. So each simulation step takes you from W + I => W' which you hand off to the pre-renderer and the next simulation step. The pre-renderer will combine the game world state with static data (i.e. models and shaders) and produce game-state-free data that a renderer can display to the user. This is the basic framework I've used for twelve years when I've been able to implement it (i.e. not often at my day job). It's worked really well, but I actually have not applied it in a language that supports purely functional programming. So you can guess why I'm in this thread.
  - swannodette 16y ago
    FWIW, this is exactly the model that Penumbra adopts. I'm curious to see how this scales with more complex games. I think there's a lot of awesome research / experimentation /documentation to be done here.
    - zach 16y ago
      Excellent! Well, I guess we have the first article for the wiki then.
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 ago
  I 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 ago
    As 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.

jcw 16y ago

I've tried to write games in a pure FP style in Scheme, and, like Hague, found that the difficulty is in keeping track of state in a sane and efficient way. I suspect that Haskell's monads are a solution. Can someone with Haskell experience attest to this?

zach 16y ago
My favorite style, which I think maps well to functional use, is to have the entirety of game state (including random number seeds, etc.) be in one "world" data structure, call it W. Then, you collect all your input (say, controller axis values) into another structure, I. So each simulation step takes you from W + I => W' which you hand off to the pre-renderer and the next simulation step. The pre-renderer will combine the game world state with static data (i.e. models and shaders) and produce game-state-free data that a renderer can display to the user. This is the basic framework I've used for twelve years when I've been able to implement it (i.e. not often at my day job). It's worked really well, but I actually have not applied it in a language that supports purely functional programming. So you can guess why I'm in this thread.
- swannodette 16y ago
  FWIW, this is exactly the model that Penumbra adopts. I'm curious to see how this scales with more complex games. I think there's a lot of awesome research / experimentation /documentation to be done here.
  - zach 16y ago
    Excellent! Well, I guess we have the first article for the wiki then.

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 ago
I 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 ago
  As 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.