3 ms·

I think this isn't that FP languages themselves are not good for programming games, but that the languages don't really bring much more to the table. Even when

by rtpg 10y ago

I think this isn't that FP languages themselves are not good for programming games, but that the languages don't really bring much more to the table. Even when writing games in C, you end up writing many things in a very functional way by default. You have some state variables, and on every tick you advance things around in a very defined fashion, and redraw the screen. The "default" pattern for making games is so close to functional languages already that the only thing moving to purely functional languages gives you is a tutorial on State monads. In a way, this is a way of saying that functional languages are good for games, though... meanwhile, OOP-style tools are extremely useful in games, because you often find yourself working with Entities with a lot of shared behaviour. The abstraction maps well to the concrete structure of a game. Going to an FP-language will often cause you to sacrifice many OOP-centric language niceties without bringing much to the table to replace those niceties. In game programming, I think the tradeoff is much harder to justify than in other domains.

eru 10y ago
Once the Haskell people have figured out lenses properly, you can have all your OOP niceties (that anyone actually cares about).
- deleted 10y ago
  [deleted]
- clock_tower 10y ago
  We've already got those niceties (including the ones that you don't care about), and we get them without having to learn Haskell's enormous universe of exotic terminology. How do we get them? We don't use Haskell.
  - eru 10y ago
    Oh, you get much more, and better with Haskell. (It's just that stuff is currently widely in flux. Not at the base language, but at the level of basic libraries there's great improvements.)
clock_tower 10y ago
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...

by rtpg 10y ago

eru 10y ago

Once the Haskell people have figured out lenses properly, you can have all your OOP niceties (that anyone actually cares about).

deleted 10y ago
[deleted]
clock_tower 10y ago
We've already got those niceties (including the ones that you don't care about), and we get them without having to learn Haskell's enormous universe of exotic terminology. How do we get them? We don't use Haskell.
- eru 10y ago
  Oh, you get much more, and better with Haskell. (It's just that stuff is currently widely in flux. Not at the base language, but at the level of basic libraries there's great improvements.)

clock_tower 10y ago

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...