The festive season never seems to be a good time to get any coding done...
With that out of the way, I'm going to press on with my crazy schemes. Over the past few days, I've been trying to recreate the skeleton of my game in Haskell using Nanocurses (this was mostly an excuse to learn Haskell, having tried and failed many, many times already).
I still think in altogether too imperative a fashion for Haskell to look on approvingly, especially when doing things with Curses involves slipping into 'do' notation all the time. Ah well, it'll be interesting to see if rendering my problem in a more pure language will help me spot any solutions.
3 comments:
Haskell curses? Want! :)
You're right about thinking in Imperative. How would the interaction with a monster be in Functional? I've been trying to think in different ways and stay away from state. Off the top of my head...
On a game turn the objects/entities output actions, collected in a general pool of actions, which are used the next turn as input to all objects? Then current health wouldn't be obtained from state, but recursively defined from previous relevant actions. Aside from the memory overhead (I hope Haskell would optimize much of this, but the list would be indefinitely growing), is this different enough from a monad that "keeps track" of state?
More importantly, is it worth the trouble?
If I could only make up my mind...
Heh, it's very hard to get out of the habit of thinking about incrementally changing mutable state.
I'm currently piggy-backing the 'current' world state around with the curses update, in an IO Ref. It's a hacky solution, but to be perfectly honest whenever I read a paper about FRP and arrows... my eyes glaze and my brain goes on holiday.
I'm sure there are far more elegant representations of the kind of computations I'm toying with, possibly in those same papers, but I can't grok them yet.
But even in an impure, imperative framework, I think a lot of value attaches to the functional and pure way of doing stuff. Certainly enough that I don't mind spending an inordinate amount of time thinking about new ways to approach solved problems rather than writing code, even though in the end implementation is the only thing that matters *g*
For the record, I never paid a lot of attention to arrows anyway. It's "advanced haskell" and I don't consider myself up to that level! The guys that write those papers speak functional fluently, I don't.
IO Ref with interface+world state seems like the best compromise so far.
Post a Comment