• The solution is one word.
• Post a comment with your answer. I will moderate comments so incorrect solutions will not appear.
• Feel free to put a link to your profile or contact information in the comment with your solution, so people that are impressed with your puzzle skillz can find you.
• Don’t submit more than one solution per day or you will be disqualified.
• If I get more than one solution within a few days, I will post them all.
• After a solution is posted, comments will be closed.

To simplify the game mechanic functions, we’ll carry the game state around in a State monad called GameStateM.

This is created by the input functions that we’ll see later.

The first thing we want is a high-level function that can be used to move a piece. This is easy to describe in plain English: if the move from space A to space B is valid, move the piece on the board and remove any piece that was jumped, then it’s the next player’s turn. It is almost as easy to write in Haskell:

We’ll look at isMoveValid soon. When the move is valid, this gets the board from the current state, makes a new board with the pieces moved, then puts the new board back in the state. The function gets board maps the projection board into the state, so it is equivalent to get >>= return . board. We put the new board back into the state with modify, which takes a function that modifies the current state. So modify f is equivalent to get >>= put . f. We’ll look at switchPlayer and selectPosition in the part about input.

Now, let’s define move and jumpPiece.

In move we first try to get the moving piece from the board. If it existed, we return the board with the piece moved. To do that, we delete the piece from the old position and insert it at the new one.

Next, we take a leap.

Notice that these are partial functions. If the position that was jumped is Nothing, i.e. no jump, then don’t modify the board. Otherwise, delete the piece that was jumped.

Now the hard part: checking if the move is valid. We have a number of things to check here, so let’s break it down. A move is valid if:

• The destination is on the board
• The destination space is empty
• If the piece that is moving is a goose, then it must move forward
• The spaces have to be adjacent or a jump
• A jump can only occur if the destination is two spaces away from the start along a line, and the moving piece is a fox, and the space jumped had a goose, and the first two rules still apply

Whew, that’s a lot to check. Let’s start.

We’ll need to know what piece is moving in a few places, so get it here. It also helps to get what we need from the state here, so we can define helper functions which aren’t in the state monad. Next, we check if the destination is empty with Map.member. Remember, we don’t store empty spaces in the map. We use a couple of helper functions to check if the move is a jump, then we combine all of our rules in a call to and. Finally, the result of the function is if the move is valid and which space was jumped, if any.

Let’s dive into these helper functions.

These are all very simple definitions. We need dx and dy in a lot of places, so they’re defined here. onBoard and isAdjacent use two definitions from part 1. The function isGoose checks if a jumped space has a goose. How do we calculate the jumped space? We know that it has to be either two positions up, down, or sideways, and if (x + y) is even then we can go diagonally also.

If the jumping piece isn’t a fox, or the move isn’t a jump, return Nothing.

This is the bare minimum of mechanics for a working fox and geese game. It’s actually not complete, because we don’t allow multiple jumps, and we don’t force a player to take a jump if he can. I will add those later and write a new post.

Next time, we’ll see how to make our game interact with the world, with input and drawing. The source code is available on GitHub, so please fork it and make it better.

But first, an overview of fox & geese. It’s similar to checkers, except that it is asymmetrical. The rules are pretty simple:

• The pieces move along the lines on the board and sit on the intersections, which I’ll call “spaces” even though they should be called “points.”
• There are only one or two foxes and fourteen to 24 geese (the variations balance the game differently)
• The foxes can capture the geese by jumping like checkers, but the geese can’t capture the foxes
• The geese can’t move backwards, but the foxes can move any direction
• The geese win by occupying the nine spaces at the far side of the board or blocking the foxes so they can’t move
• The foxes win by capturing enough geese that they can’t win.

Like most old games, there are a number of variations. Later we’ll add options that let the user customize the game to the variation he likes, but for now we’ll stick to two foxes and 24 geese.

And now, the program! It will help to get the source and follow along. The code is available on GitHub; this part will refer to tag v0.1.1. The source code is cabalized, so after you check it out you should be able to do cabal configure and cabal build to build it.

The Board

I decided to represent the board as a map from a position to a piece. Empty spaces on the board aren’t in the map. So, we need a type to represent our pieces in the map, and a type for the spaces.

I used a qualified import for Data.Map because it has names that conflict with Prelude.

It’s useful to know which spaces in our 7×7 grid actually exist on the board, so let’s make a list of valid positions. First I generate all the positions in a 7×7 grid, then I filter out the invalid ones.

It’s also helpful to know which positions can be reached from any other position. I call this adjacentPositions, and it’s more complicated than it seems because of the odd board shape, and because diagonal movements are only allowed from certain spaces. First I generate all the possible movements¹ with [(x, y) | x <- [-1..1], y <- [-1..1]], then filter out the movements that aren’t valid. The result is offsets in the next code snippet. Then I use those offsets to generate the possible adjacent positions and filter out those that are off the board.

The Haskell books I’ve been reading call this using lists as non-deterministic values. The idea is that instead of finding one possible move, testing it, finding the next move, etc., we just put all the possible moves in a list and operate on them as one value. It’s something you can do in imperative languages, but functional programming, and especially lazy evaluation, makes it a lot easier to work this way.

Another thing we need to do with our board is find out who is where. If we try to see which piece is at a space on the board, we might get a piece or we might not. This looks like a job for Maybe! The map function lookup already gives us a Maybe value, so we’re good.

Don’t worry about GameState right now. It wraps together a bunch of stuff that we need for interacting with the game. All that’s important right now is the board, stored conveniently in record notation with the name board. So getPiece first gets the board from the GameState, then it tries to lookup the Position in the map. Maybe it finds a piece, maybe it finds bupkis.

We now have a working representation of a board for a game of fox and geese. We also know which positions on the board are valid, what movements we can make, and we can see what is on the board. In the next post, we’ll build the game mechanics that move pieces around the board.

As always, feel free to fork the project and fix all my glaring mistakes. Just be a dear and let me know about it in the comments.

What are some other ways that you might represent the board in Haskell? Leave a comment and let us know!

Next, learn how to move the pieces in part 2.

The feature list was miles long, but I’m getting too busy to work on it. Look forward to a second version when I can get back to it.

Click on “more” to play the game.

This week’s Pizza Hut code

Here’s what they’re giving away:

• $30k for a car
• 5 entertainment centers worth $4k each
• 20 $400 Pizza Hut gift cards
• 500 $5 music download gift cards