4 ms·

Games would benefit from having the ability to plug in FP to resolve particular rules, but the aggregate game-world is stateful. (Remember that article here on

Games would benefit from having the ability to plug in FP to resolve particular rules, but the aggregate game-world is stateful. (Remember that article here on HN where someone took several months to sort of write Pac-Man in Haskell, then admitted at the end that it would've taken him a week in C; and look at some of the other hoops that Haskell tutorials jump through when writing games.) OOP is just an enormous win for games; I actually learned OOP with ZZT and Megazeux. Something simple like Pac-Man _might_ fit in a stateless paradigm, more or less, if you have a non-painful way to do I/O; but the more ambitious a game gets, the more it benefits from objects (including rule-processing objects). MVC is also a good thing to use in gaming. For those who haven't heard yet: the model is the database and the deterministic, stateless parts of processing ("characters lose 1 point of nutrition per turn"); the controllers are the player's and any AIs' decisions (both are almost certainly stateful across rounds/timer-ticks); and the views are drawing the game (for the player) and giving a selective picture of the gameworld's state (for the AIs).

rtpg 10y ago
(Talking about FP, but mainly aout Haskell and other languages with some weak OOP tools) The statefulness is managable in FP generally, you could see things like the State monad in Haskell. After all, the current state is just recursive applications of the rules. Experienced users of the FP languages will feel at home The high nesting that would end up in your data will probably mean you want to reach for deep data accessors and the like. This is managed through things like Lenses in Haskell. But that's an extremely high learning curve to basically get what you get for free with dot notation in so many other languages. If you're experienced in the language already, it's fine, but if you're just starting out in the FP language, and you had experience in iterative-style languages... ouch. I really like the idea of applying MVC for game patterns. it makes so much sense! Going to explore that the next time I have the chance.
- clock_tower 10y ago
  How is the current state just recursive application of the rules, if the rules integrate randomness? It would mean saving every call to rand(), as well as every piece of user input...

rtpg 10y ago

(Talking about FP, but mainly aout Haskell and other languages with some weak OOP tools) The statefulness is managable in FP generally, you could see things like the State monad in Haskell. After all, the current state is just recursive applications of the rules. Experienced users of the FP languages will feel at home The high nesting that would end up in your data will probably mean you want to reach for deep data accessors and the like. This is managed through things like Lenses in Haskell. But that's an extremely high learning curve to basically get what you get for free with dot notation in so many other languages. If you're experienced in the language already, it's fine, but if you're just starting out in the FP language, and you had experience in iterative-style languages... ouch. I really like the idea of applying MVC for game patterns. it makes so much sense! Going to explore that the next time I have the chance.

clock_tower 10y ago
How is the current state just recursive application of the rules, if the rules integrate randomness? It would mean saving every call to rand(), as well as every piece of user input...