Thursday, February 14, 2008

Games for Programmers: Zendo

In addition to teaching and programming, I also enjoy playing board games. This is the first in an irregular series of game recommendations for programmers. Of course, you don't have to be a programmer to enjoy these games, but if you are a programmer, then I think there's a pretty good chance that you'll like them.

Zendo is a game about debugging. Ok, it's not really about debugging, but you'll see what I mean in a moment.

Zendo is a logic game played with a bunch of Icehouse pieces (plastic pyramids in several different colors and sizes) and some markers.

(photo by Terraliptar)

During the game, pyramids will be placed in groups (called “koans”) that either satisfy or don't satisfy some secret rule. The players try to figure out the rule based on these examples. For example, consider the following group:

(photo by Ted Alspach)

This group might satisfy the rule “at least one piece off the table” or “exactly one tilted piece” or “fewer than two green pieces” or “contains pieces of three different sizes”. It would not satisfy the rule “no two pieces of the same color”.

One player is designated as the master, who chooses the secret rule and judges whether proposed groups satisfy the rule. The master initially sets out one group that satisfies the rule (marked with a white stone), and one that doesn't (marked with a black stone). The other players take turns proposing groups, which the master then marks with white or black stones. Later in the game, players try to guess the rule, based on the evidence they've seen. If a guess is correct, that player wins the round, and a new master is chosen for the next round. If a guess is incorrect, then the master creates a counter-example, either a group the satisfies the secret rule but not the player's rule, or a group that satisfies the player's rule but not the secret rule. Either way, the master marks the counter-example with the appropriately colored stone.

That's the basics of the game. There are a few more details that can be found in the complete Zendo rules. (That site also offers a fascinating design history of the game.)

As a player, you are constantly coming up with possible rules and checking whether they are consistent with the examples that are already on the table. Often you will have more than one possible rule in mind. When it's your turn, you try to design a group that will help narrow down the choices. Ideally, you want a make your group so that either a positive or a negative answer will support some possible rules and deny others.

The primary challenge as master is coming up with a good secret rule, one that is not too hard and not too easy. Of course, too hard and too easy will depend on who you are playing with. Looney Labs sells a pack of Zendo rule cards to get you started. These rules are fairly easy and are perfect for those new to the game. Eventually, you will want to start creating your own rules.

Debugging

Debugging is a fundamental skill of the programmer. When its your own bug or you're operating under severe time pressure, negative emotional reactions can make debugging quite stressful. But when you are helping somebody else debug their code, it can be quite fun, kind of like a logic puzzle.

There are two basic approaches to debugging; most debugging sessions combine both. In one approach, you step through the code, re-thinking each line and looking for something suspicious.

In the other approach, you look at the observable evidence—for this input, it's producing that output, when it should be producing this other output, or the web site crashes every day between 5pm and 6pm— and try to come up with a hypothesis for what might be going wrong. For example, you might hypothesize that something is going wrong when two clients happen to have the same name, or that somebody is mixing up row-column coordinates with X-Y coordinates. Often you try to come up with an experiment that might confirm or deny your hypothesis, or help select between several competing hypotheses. Once you have a fairly solid hypothesis, you can usually narrow down where in the code to go looking for the error.

It's this latter approach to debugging that Zendo captures so well, that of making and testing and refining and discarding hypotheses.

Of course, that's the perspective of a computer scientist. Other kinds of scientists might prefer to think of Zendo in terms of the scientific method.

How to get it

Zendo used to be sold in a nice boxed set, but that is long out of print. In fact, I didn't get my copy until after it was already out of print. I got it as a gift from my BoardGameGeek Secret Santa, a charming annual tradition where hundreds of boardgamers anonymously send Christmas presents (games, naturally) to other gamers around the world, usually gamers that the sender doesn't even know.

You can still buy the pyramids from Looney Labs, where they are sold as Treehouse sets. You would need at least four sets to play Zendo—five would be better. It's kind of expensive that way, but fortunately there are a whole bunch of other games you can play with the pieces. You would still need a set of markers, but poker chips or coins in several denominations work fine.

In fact, with only minor modifications, it's easy to improvise a set of pieces for Zendo out of common household objects, such as bottles of beer.

Harald Korneliussen said...

Another awesome game for programmers: Mind Ninja. One player proposes a pattern rule (within certain constraints), then the other decides whether he will try to build it, or prevent it from being built. The constraints ensure that no game can end in a tie.

It's not inductive like Zendo, but like Zendo it has an infinite game tree, and that's pretty cool in my opinion.

A friend of mine, Arty Sandler, has actually implemented an online version of the game, but you can only choose from a set of predefined patterns.

It's very educational. Patterns that are easy to describe ("Find the two same-coloured stones that are furthest apart by the shortest route of same-coloured stones. If they are red, builder wins.") can be surprisingly hard to write good detection algorithms for.

Reginald Braithwaite said...

I haven't played it, but from your description, Zendo struck me as a game of induction--discerning the rules from observing patterns and performing experiments.

My mother introduced me to a game called Queries and Theories in the 1970s with the same theme. It's still available and well worth the thirty-five dollars.

Needless to say, the manufacturer has some other amazing games for sale, including Wff'n'proof. And a great game based on sets.

Rob Myers said...

A colleague, James Shore, and I used Zendo to demonstrate the value of rapid feedback in Test-Driven Development. I just found this post (and your blog) while searching for images of the Zendo game. Very cool stuff! As an agile coach/trainer, I'm always looking for games/simulations/activities to demonstrate some principle of software development. Thanks!

Jenifer Davis said...

There is a game currently running that teaches Java FX through gaming, www.pietheory.com challenges their players to solve clues that are presented in Java FX and Netbeans 6.5. Pretty cool

Nathan said...

This seems like a fantastic AI problem.

patchworkZombie said...

my favorite rule is "looks like a face" everybody notices that it looks like a face but it takes them quite a while to get to the point where they are willing to guess something as silly as that.

Code of Tanks said...

You might also like Code of Tanks, an online PvP tank battle game, brand new as of this writing. It does require some fundamental .NET programming knowledge, but other than that it's pretty simple: you create or join a room with other players, get your AI ready and pick your tanks, and watch the battle live from anywhere in 3-D. It's in Beta and everyone's invited to check it out: http://codeoftanks.com