A Clone of Chips Challenge in Haskell

HUnit, directly based on JUnit: http://hackage.haskell.org/package/HUnit

Quickcheck, which uses randomized testing: http://hackage.haskell.org/package/QuickCheck

HUnit will be very familiar to you, Quickcheck is definitely more interesting. You specify some invariants and the heuristic algorithm tries to come up with random inputs to break your function. It's potentially less accurate as good unit tests, but it's also a ton less work.

I can just say something like "This function takes an array of integers as input, and I expect an output array of the same size, where all numbers are even, and there are no duplicates" (in math-y form, of course), and quickcheck will try however man random inputs I specify to try to find a case that breaks that invariant.

Consider a well known Haskell library, attoparsec. It has extensive tests and benchmarks: https://github.com/bos/attoparsec

That being said, there are those in the Haskell community who take Haskell's referential transparency and equational reasoning to a whole new level and don't write tests, but instead write proofs.

For an example, see the popular Pipes library: https://github.com/Gabriel439/Haskell-Pipes-Library/blob/mas...

gamegoblin is absolutely correct that there is some great tooling for tests in Haskell.

Bigger and longer-lived projects benefit enormously from an automated test suite no matter what they're written in.

That said, when you refactor a program in Haskell, instead of running the tests and some functionality falling, usually the compiler itself will tell you there's a problem at line X of file Y.

That use case of tests is just not there - and that's the main selling point of unit tests. Thus, I'd expect Haskell developers to not write as much of this kind of tests. But again, you'll always need some kind of it.

Then you define a function that is like (in C-ish):

    GameState tick(GameState current, Action playerMove) {
        ... set up the next frame and return it ...
    }

    void play() {
        play(initialState());
    }

    void play(GameState current) {
        if(current.gameOver()) return;
        Action playerMove = getPlayerMove();
        GameState next = tick(current, playerMove);
        play(next); // In Haskell and C on higher optimizations, this tail recursive call will get compiled to a loop
    }

So I'd say functional programming is neither better nor worse. A lot of people get hung up on the idea of immutability, but really I've found it to be a non-issue.

That is just one way to look at it. You could also say that they can all be described by the universe's state at a point in time. Then, you'd have a function that takes the old state and some actions to produce a new state, by recursively doing the same to each object within the universe.

The code is right there on GitHub, although if you're not familiar with Haskell (and lens), it might seem cryptic. But you'll see that it is actually mostly written in an imperative style. The logic is mostly pattern matching on events to generate record updates. This is a common style in Haskell and fits the domain well.

There are other more elegantly value-oriented ways of writing simulations in Haskell; look up functional reactive programming.

It skips a little in the beginning, but I think you might find it interesting.

Do you have anything that you want to do, but discover halfway through for some reason it's not legal? Good luck undoing what was half done. Of course you might think the simple answer is "don't do that", but as the game gets bigger and responsibilities get spread out between all the objects it becomes increasingly easy for some action to become possible that requires a lot of checking, and if things are just willy-nilly mutating themselves the odds of you encountering this sort of problem skyrocket. And that's just one example... games by their nature resist the sort of decomposition that most "real" software can have done on it, because as soon as you tell a designer that X can't talk to Y, by golly they'll start thinking about how awesome it would be if X was talking to Y. You don't get a pretty tree of relationships with occasional crosstalk, you get a nasty snarl of communication patterns, irreducibly.

Many games end up functional under the hood anyhow, with a clearly-defined loop:

    1. Ask all the objects in the world what they "want" to do.
    2. Validate and resolve conflicts.
    3. Render the new world state.

Of course nothing stops you from doing that in OO, with discipline and care unenforced by the compiler. But what it does mean is that suddenly the "mismatch" that you're referring to disappears, and one starts wondering whether perhaps FP is the better match for games and OO the accident of history.

    checkCurTile b = do
      case b of
       Chip -> liftIO $ playSound (soundDir ++ "collect_chip.wav") False
       Gate -> liftIO $ playSound (soundDir ++ "door.wav") False
       (KeyYellow _) -> yellowKeyCount += 1
       (KeyBlue _) -> blueKeyCount += 1
      tileAt Current .= (Empty def)