Monkey Traps

If you put a banana in a jar, and make a hole in the side of the jar that’s big enough for a monkey’s hand but not big enough for a banana, and affix the jar to a tree in a jungle, you’ll come back in the morning (so the myth goes) to find a poor little monkey clinging to the banana—trapped by its own desires.

Design space is filled with monkey traps. In fact, I almost want to say that that’s all it consists of. It’s a jungle full of jars containing sparkling gems and scrumptious treats (i.e. game mechanics) that can’t be removed from their tantalizing display cases.

But if they can’t be removed, what’s my goal as a game designer? Let me torture this metaphor further by suggesting that the jars are packed so closely that I’m able to touch (but not remove) multiple prizes at the same time. And let’s just say that at the stroke of midnight, I get to keep whatever I’m touching. My goal, then, is to find a well-matched set of prizes which are all within reach of each other.

Therefore, as I’m wandering through the jungle searching for a well-matched set, the biggest mistake I can make is to become intellectually or emotionally attached to the contents of any one jar. The moment I do that, I’m monkey-trapped. If I decide that I absolutely must have some particular prize, I’m stuck with whatever other prizes happen to be within reach of it, regardless of how poorly they fit. It’s better to recognize not only that the jungle is filled with similar prizes that might do just as well, but that I may not even need the kind of prize that I think I need so badly.

Personal Examples

My design history of Zendo contains many stories about monkey traps that slowed me down. I clung to the idea that nobody should earn a stone when everyone answers a mondo correctly, and the idea that the Master should not interact with the players too much (by setting up initial koans, or answering questions about koans, or building counter-examples), and the idea that the game should be “gamey” (with players earning points or making “strategic” decisions). I have similar stories about every other game I’ve designed. I practically define game design as the process of recognizing and escaping from monkey traps—in other words, figuring out what’s truly important.

My current favorite monkey trap story involves Jewels of the Sultan, a card game that I’ve been working on for at least eight years (and still haven’t published). It’s played with a deck of cards that come in five different colors, and at the end of each round, a randomly-selected color “scores”. (Never mind what that means.) For years, a key element of the game was that exactly one player got to see the scoring color at the beginning of each round. This created all sorts of juicy psychological play, which was the point of the entire game. It also created all sorts of intractable end-game problems, because the player with the secret knowledge could often see who was going to win before the final round even started, or, even worse, was forced to play kingmaker.

I attempted to solve these problems for years without success. (And believe me, I tried some pretty ugly solutions.) It was obvious that I was caught in a monkey trap, but it wasn’t obvious which thing I needed to let go of. Finally, Josh Drobina—a fresh-eyed tester who hadn’t been involved in the previous years of testing—suggested letting each player see a color that’s not going to score, rather than letting any player see the color that’s going to score. Predictably, I resisted the idea, even after we tried it the first time. I felt that it diluted the psychological aspect of the game. Fortunately, I had enough experience with monkey traps to recognize my resistance for what it was, and after thinking about it for a day or two, I stopped clinging and started rebuilding the game around the new idea, which solved all of my problems.

Why Do We Cling?

Over the years, I’ve noticed recurring patterns in my thoughts and emotions that cause me to get caught in monkey traps. Many of these patterns seem directly related to the cognitive biases that psychologists and behavioral economists are always going on about.

One of my most common thought patterns seems to be a species of infatuation. I simply become mesmerized by the beauty, cleverness, or juiciness of one particular game mechanic. When it’s a mechanic I invented myself, my infatuation is often exacerbated by a kind of IKEA effect. As I play my prototype over and over again, my infatuation is almost always exacerbated by the mere exposure effect.

Of course, if my game is perfect and ready to publish, none of this is a problem. However, as long as the game still needs work, this kind of infatuation represents a monkey trap that may keep me from changing something that needs to be changed.

Therefore, I try to remember that the jungle is vast and full of jars, containing prizes of all shapes and sizes. Even if I assume that no two prizes are alike, there are still many others that will exhibit some, if not all, of the characteristics that I’m so crazy about. It’s very unlikely that the exact characteristics of this one particular game mechanic are vitally important to my game. There’s probably an idea there worth clinging to, but it’s much more general, and therefore much more likely to be expressed by many different game mechanics.

My Jewels of the Sultan story is a perfect case in point. The game did lose a very specific psychological quality when I changed that rule, but it turned out that that particular quality (or that particular level of that quality) wasn’t nearly as important to the game as I thought it was. I see shades of the cognitive bias known as anchoring or focalism here.

To go even further, it’s virtually always true that there are many prizes out there that are just as good as the one I’m clinging to, but they’re “good” in a totally different way. If I stop clinging and try some very different ideas, my game might lose all of some quality that I really like, but gain some new quality that I like every bit as much (after I work through the five stages of grief). As an example, I’m constantly toying with the idea of eliminating the capture rule completely from my game Blockers and taking the design in some other direction. This would unquestionably eliminate some of the game’s beautiful emergent properties, but it will probably also lead to some other ruleset that contains a whole different set of beautiful emergent properties that I’ve been missing out on all this time. I don’t know the formal name of the cognitive bias that makes us prefer actualities to potentialities (in other words, makes us really bad at assessing, or even thinking about, opportunity costs), but it seems powerful and all-pervasive.

Another trap I often get caught in is the feeling that a particular rule is necessary, because it solves some specific design problem. It may well be that some new idea genuinely solves a problem. However, it’s always a mistake to believe that this specific solution is the only or best possible one. Not only are there many other solutions out there in design space, there are many other kinds of solutions out there in design space. Of course, if some idea completely solves the problem I was trying to solve without creating any new problems, I won’t feel strongly compelled to keep looking for other solutions. But more often than not, a genuine solution to one problem creates other problems, and more often than not the best solution to those problems is to throw out the original “solution” and keep looking for a different one.

One of the reasons that this kind of monkey trap is so strong is that living with unsolved design problems can be excruciatingly painful (and the longer you live with a problem, the more painful it becomes). I sometimes feel an overwhelming desire to cling to the first real solution I find, and to downplay or ignore any new problems that it causes. Only time and experience seem to help here.

Another thing that sometimes causes me to cling is fear. This is a weird one, and bit hard to unpack. To some extent it’s a fear of change, or a fear of the unknown. There’s a sense that, somehow, I’m going to “ruin” or “lose” what I’ve come up with so far. Maybe there’s a feeling that trying out a new rule implicitly commits me to the idea that the old rule is “bad” and must be rejected. Sometimes, as crazy as it sounds, there’s a fear that the new experiments aren’t going to work out, but I’m going to be unable to find my way back to the old ruleset for some reason (because I forgot to take notes, or I’m caught in a new monkey trap).

Like many fears, these seem a little silly when I say them out loud. There’s simply no reason for me to be afraid of trying a rule change. It doesn’t commit me to anything. I can always return to earlier versions that I liked better (and, let’s face it, it requires almost no effort to keep track of what previous versions I’ve played). I’m not going to ruin or lose anything.

I can only think of one fear that that’s actually rational, and that’s the fear that my constant tinkering will “ruin” the game for some playtesters, to the extent that they no longer want to play the game. This has happened to me plenty of times, and I always feel bad for the playtesters when it happens. They don’t owe me anything, and dealing with my perfectionism is hard work. Nevertheless, I’m caught in a monkey trap if I let other people’s feelings keep me from searching for better solutions. Sometimes the best thing to do is to just find some new playtesters for this particular project. (And fortunately for me, I know some playtesters who are willing to tinker forever!)

There’s one other major reason why I cling: exhaustion. Sometimes I just don’t feel like trudging through the jungle any more, and I end up making excuses for parts of my game that still need work. In such cases, I just need a break from the design. Eventually my energy returns, and my vision clarifies. If I never feel like returning to that game again, then it wasn’t worth worth releasing anyway.


I haven’t provided an exhaustive list of all possible game design monkey traps. I’ve merely listed the ones that I most commonly find myself caught in. I want to reiterate that getting caught in monkey traps is unavoidable in game design, and in life. It’s just part of the process. Feeling ashamed or sheepish about it probably makes things worse, and even creates new monkey traps!

The real point about monkey traps is that we’re never truly trapped. All we have to do is stop clinging, and we’re free.

My Imperfect Children

Over the years, I’ve banged the drum quite a bit in favor of perfectionism in board game design. Whenever I do so, I try to emphasize that, while I think “perfection” is the correct target to aim at, I don’t believe that any of my own designs have actually hit this target. “Perfection” is like an infinitesimal point at the center of a fuzzy circle. The point is real, and it’s the correct thing to aim at, but it’s unreachable in practice. The fuzzy circle represents the threshold that each of my designs must cross before I’m willing to call it “good enough”. And the moment I conclude that a design will probably never cross that threshold, I shelve it.

Over the course of about 15 years of hobbyist board game design, I’ve ended up with exactly five published designs that I consider to be “good enough”. I have a sixth design that I’m pretty happy with, but I haven’t worked very hard on getting it published. I’ve also designed a few party-style games that are probably “good enough” by my standards, but feel so slight that I’ve done nothing more than post their rules here on my site. On the flip side, I’ve had a few of my designs published, in one form or another, which don’t quite live up to my own standards. It reminds me of a line by the comedian Jonathan Katz: “I have a wife and two beautiful children. And a couple of other kids who aren’t so attractive.”

My beautiful children are Zendo, RAMbots, Why Did the Chicken…?, Criminals, and Blockers. Although these designs are “good enough” by my standards, they aren’t perfect. I thought it might be fun to write up a blog post detailing their imperfections as I see them.


One of my biggest complaints about Zendo is that mondos and guessing stones aren’t meaningful enough. Mondo feels satisfying, and it unquestionably improves the experience. It adds a bit of tension, and provides players with intermediate rewards throughout the game. Furthermore, it creates an intimate communal feeling, and allows you to get a glimpse of what other people are thinking.

The problem is that most of the time players end up with more guessing stones than they know what to do with, and at that point calling mondo is kind of pointless. Of course, it’s still fun (which is why people continue do it), and it helps you gauge how well other players are doing, which may have some (very negligible) effect on your winning chances. But overall, its primary purpose of doling out guessing stones has become irrelevant. All else being equal, calling mondo slows the game down, and one can argue that it’s not worth doing when every player already owns a pile of stones.

Over the years, we’ve tried many, many alternatives to the current mondo rules, including making each guess cost more than one stone, making people lose stones when they guess incorrectly, eliminating the mondo rules completely, etc. None of the resulting games have ever felt quite as good as the current ruleset. Zendo seems to lie at a local optimum. Every small tweak we try makes it worse. I don’t doubt that there are deeper changes to consider, but the results are probably different enough from Zendo to count as new games.

Another possible complaint about Zendo is that the downtime can be extreme. A related problem is that people sometimes find it very painful to wait for their turn to come around once they’ve figured out the rule. Some people even play with a variant that allows anyone to spend stones and guess the rule at the end of anyone’s turn. Although that’s a fine idea, I’ve never been willing to make it into an official rule, because it’s complex and unwieldy if you try to write it out (which I have).

Beyond this, there’s a whole cloud of problems relating to the fact that when you’re the Master, you need to know what you’re doing. You need to come up with a rule that’s not too easy and not too hard. You need to mark koans correctly. You need to build counterexamples correctly, which can be difficult even for experienced Masters. You need to make silent judgement calls about ambiguous koans, and you need to communicate correctly with players when they ask about them. Overall, it’s relatively easy to ruin a game when you’re the Master. It all feels a little brittle.

One could argue that some of these flaws—especially the ones in the last paragraph—are inextricably bound up with the goodness of the game. I agree. But I insist, ruthlessly, that they’re still flaws. It sucks that Masters can ruin games so easily, and if I could eliminate that possibility while retaining everything else that I like about Zendo, I certainly would. I see no reason not to call a spade a spade in these situations, and I see a really good reason to do it: a concerted effort to solve these problems could lead to some new game that’s as different from Zendo as Zendo is from Eleusis. I’m not currently working on that problem, but maybe I or someone else will someday. This is part of what I mean by problem-driven game design.


The basic problem I have with RAMbots is that it’s too complex. I doubt I’ll ever create another board game that contains this many rules. Actually, it’s probably simpler than the average board game, but it’s still pushing the edge of my personal complexity threshold.

One specific problem that’s always bothered me relates to the red “damage” beam. The red beam damages other RAMbots, but doesn’t knock any objects over. RAMming damages other RAMbots, but also tags and knocks over upright RAMbots and beacons. This inconsistency often confuses new players. The obvious solution is to allow the red beam to also tag and knock over beacons and RAMbots, but the resulting game simply isn’t as good. We can allow the red beam to knock over objects without tagging them, but that’s even more inconsistent and confusing. We can say that RAMming only tags and knocks over upright objects, and the red beam only damages other RAMbots, but again the resulting game is a lot less interesting.

Recently Jake Davenport suggested scraping the red beam action entirely, and replacing it with a “sideways slide” action. Just like the blue “push” beam and the yellow “pull” beam, the red “slide” beam now moves any object it hits by one, two, or three spaces—but it moves the object sideways away from the beam, and always towards the center line of the board. I have played this version of the game exactly once, and I thought it was great. I didn’t miss the old damage beam at all, and the new slide beam was useful and made the game more fun. Even though it hasn’t been tested much, I’ve gone ahead and updated my RAMbots rule page.

The resulting game still isn’t perfect. It remains more complex than I would like, and there are probably other inelegances that I haven’t quite put my finger on yet. Nevertheless, it does lie comfortably within my fuzzy circle of “good enough”.

Why Did the Chicken…?

I’m only half-joking when I say that the main problem with Why Did the Chicken…? is that it’s a party game, and all party games are broken.

More seriously, many party games break down if the players care too much about winning. For instance, when I’m the judge in WDtC, I can often glean who wrote certain answers based on their word choices and style of humor, and if those players are ahead, I can avoid choosing those answers. Another problem is that it’s possible to get so far behind in the game that you know you can’t possibly win.

A more general complaint is that this game asks its players to be creative and funny on demand, and that’s scary and stressful for many people. This game has provided me with some of the biggest belly laughs of my life, but it’s also generated some of my most awkward gaming experiences. Again, one can argue that this “flaw” is an unavoidable side-effect of what’s great about WDtC. I agree! The flaw is unavoidable given my design goals, but it’s still a flaw. Recognizing it as a flaw doesn’t mean I have to try to fix it. I’ve never been able to see a way to fix it without sacrificing what I love most about the game, and the flaw doesn’t push the game outside my fuzzy circle of acceptability, so I’m happy to call it “done”. However, if I could find a way retain the core that I love while making the game easier to play for many people, I’d certainly do that.

The excellent Cards Against Humanity can be viewed as one possible solution to the problem of making a joke-writing game that’s accessible to a wide audience. Of course, there are always trade-offs, and Cards Against Humanity exhibits a flaw that’s almost the polar opposite of WDtC’s: it makes players feel clever and funny, but it’s often the game itself that’s writing the jokes. Cards Against Humanity is to comedy writing as Guitar Hero is to guitar playing.

I’m not suggesting that either game is better than the other, nor am I suggesting that the designers of Cards Against Humanity were influenced by WDtC. (I have no idea if they even know of WDtC’s existence.) My point is that if you were to start with either one of these designs, take its flaws seriously, and try to fix them, you might very well end up with something like the other. And that would be a good thing, because both of these games deserve to exist! On the other hand, simply claiming, “It’s a feature, not a bug!” will never suggest interesting new directions in design space. This is problem-driven game design in action once again.


One minor complaint I have about Criminals is that players are sometimes eliminated. However, it doesn’t seem as bothersome as it does in many other elimination games I’ve played. Criminals is usually pretty short, and if you do get eliminated, you’re still allowed to hang around and take part in the game discussion. It’s also possible to play a full game without any player getting eliminated. Nevertheless, I do consider the elimination aspect to be a flaw, albeit a minor one.

Beyond that, my main complaint about Criminals is similar to my complaint about RAMbots. It’s too complex. Actually, I would say that Criminals is simpler than RAMbots, but that RAMbots is more elegant.

Criminal’s inelegances are related to the existence of the Crime Boss—an extra crime card in the deck that’s not attached to any player. Adding this extra crime created some breathing room in the design, and fixed a bunch of problems. Nevertheless, the mechanism necessitates a number of special-case rules that make the game significantly harder for new players to learn. For instance, accusing the Crime Boss requires a unanimous vote by the entire group rather than the normal vote of “at least half the group”, and a successful accusation ends the game and invokes special win-conditions. There’s even a special rule that says that when a crime comes up and everyone except you has an alibi showing for that crime, you are considered to be accusing the Crime Boss perforce. The fact that such a rule is even necessary is a sign that something’s not quite right.

Co-designer Dave Chalker and I worked on Criminals on and off for years, and at this point I don’t have any new solutions to suggest. The current version isn’t perfect, but it still manages to claim a spot within my fuzzy circle.


Like almost every abstract game that supports three or more players, Blockers can be kingmakerish in the endgame. Sometimes you know you can’t win, and sometimes your final plays will determine who does win. This is obviously a flaw, but it’s a flaw that’s impossible to eliminate completely in most games of this type. My design goal in these situations just to make sure that it doesn’t happen too often, and that it doesn’t feel too bad when it does. Some of the earlier rulesets had unacceptably bad kingmaker problems. I can live with the current version, but your mileage may vary.

As much as I love its overall design, I’ve grown increasingly uncomfortable with Blockers’s capture mechanic—specifically with the fact that you’re not allowed to split another player’s group. This restriction is certainly necessary given the current ruleset, and it generates a lot of juicy gameplay. Nevertheless, virtually every time I play the game with a new group of players, at least one player accidentally tries to split a group, and I have to step in with a correction. Since a copy of me doesn’t come packaged in every box, I can only assume that most new groups who are figuring out the rules for themselves are making game-ruining mistakes (whether they realize it or not) during their first few games. Maybe the emergent juiciness of the rule makes the problem worth putting up with, but I’m not as happy with the whole thing as I used to be.

In fact, I’ve recently begun to theorize that the capture rule in general is indirectly responsible for the game’s failure in the marketplace. (Although you can still find copies of both Uptown and Blockers for sale out on the web, no version of it is in print at the moment.) There were actually two very different productions of Blockers on the market. Briarpatch’s North American version had a nice plastic board, with raised ridges to keep the tiles from sliding around. This production caused the price of the game to be higher than we wanted it to be, and I’ve heard a few claims (by people who know more about the game business than I do) that the price hurt the game’s sales. Amigo’s European production contained a warpy plastic grid riveted to a flat black board. It was an attempt to cut production costs, and it showed. I don’t actually know whether or not this hurt the sales of the game, but I sure wouldn’t have been happy with it if I’d been a customer.

The important point is that these problems were ultimately caused by my game design. Blockers has players placing tiles into a tightly-packed grid, and then awkwardly trying to pull them back out again. Although this generates some juicy gameplay, it also creates a logistical problem that forced the publishers to produce overly expensive or disappointingly substandard game boards. I would love to see a production of Blockers that’s as elegant and functional as that of Qwirkle or Ingenious, but I don’t think it can happen with the current ruleset.

Of course, the capture mechanic was added in order to address a tough design problem. Although some people might think I’m nuts, I occasionally toy with the idea of returning to the root of the design and branching off in some other direction that doesn’t involve moving pieces once they’ve been placed. I even have a few ideas about what directions I might try, but I’ll save those for another time.

Beyond all of this, I’m also willing to consider the possibility that Blockers didn’t do so well in the marketplace for marketing reasons, or because it just isn’t as good as Ingenious or Qwirkle. Maybe it’s too abstract, or too dry, or too heavy, or too something else that I can’t put my finger on. I can live with that!


I want to reiterate that, in spite of all of their flaws, I’m really happy with all five of these designs, and I don’t regret letting any of them loose in their current forms. It’s possible to be a crazy perfectionist without going perfectly crazy, and it’s possible to find flaws in your best creations and still sleep well at night.

I’d love to drive a stake through the heart of that old vampire, “the perfect is the enemy of the good,” but something tells me that all I’m doing here is holding up a pathetic, fleshy cross. So be it!

Problem-Driven Game Design

In my experience, a problem-driven approach is the only reliable generator of high-quality game designs. The more time I spend focusing on specific, well-articulated problems and questions, the more likely it is that my final design will be novel, deep, and valuable.

This approach pervades every stage of my design process, including the initial choice of what to work on. I won’t even start a project if I don’t have at least one clearly-stated problem or question in mind. Maybe I dislike something about an existing game or genre. Maybe I have a question about some game system that I’ve never seen in action before. It doesn’t need to be an earth-shattering question. It just needs to be well-formed, interesting, and unresolved.

The desire to get rich is unlikely to generate a high-quality design. The desire to create a new game in a genre that I truly love is equally unlikely to generate a high-quality design. The issue is not one of ethics or aesthetics. The issue is that the design space is mind-bogglingly vast and only sparsely populated with high-quality games. I’m standing in a desert, and I need to know which way to go. Neither love nor money helps me in this situation.

Problems provide direction. They point. They’re features of the local environment that say, “There may be water over there.” Success isn’t guaranteed, but this methodology succeeds more often than random chance would dictate, which is not true of any other approach I’ve tried.

An Example

Werewolf is a great game, but there are things I don’t like about it:

  • It requires a moderator and a logistically awkward eye-closing phase.
  • It doesn’t play well with fewer than seven players, and is often long.
  • Being a werewolf is unpleasantly exhausting.
  • Players are often eliminated early and must either leave the room or sit in silence.

Not everyone is bothered by these problems. That’s fine. My unique design sensibilities determine which problems I choose to work on. The important point is that my problems are specific enough and unambiguous enough to suggest a direction.

Indeed, on the day I clearly articulated these problems to myself, I had the following game idea: assign a hidden character card to each player, and then try to discover the owner of a different card each round.

This hypothetical proto-game addresses all four of my problems, to varying degrees. It requires no moderator or eye-closing. It works with as few as three players. It doesn’t put an individual player on the chopping block for an entire game. And if players are ever eliminated, they’re allowed to stick around and keep talking, because they don’t have any game-ruining information.

This isn’t a complete design, but there’s enough there for an initial playtest. We tried it, and the results were promising. Of course, we then had a new list of problems to solve. Good! Problems are our signposts in the vast and trackless land of game design.

We iterated on this cycle of problem-solving and playtesting (with Dave Chalker doing much of the heavy lifting) until we didn’t have any more problems to solve—or at least, until we were able to live with the remaining unsolved problems. The result is a cute little card game called Criminals.

Money, Love, Originality, and Fun

With this concrete example in place, it’s easier to see why the desire to make money is unlikely, in isolation, to lead to good game design. That desire will never help me come up with a specific idea like the one that lies at the core of Criminals, because it doesn’t (and can’t) tell me where in design space to search. The desire may be an excellent motivator, but it’s a terrible navigator.

If I declare that I love Werewolf and would love to design my own psychology game, my desire is also unlikely, in isolation, to help me design Criminals or any other interesting game. There are millions of ways to modify Werewolf, and almost all of them are bad. I need some methodology that actually helps me figure out what to try, and why.

The honest desire to create something original is similarly useless, because it has nothing to say about how to find non-derivitave moves through design space. If the only clear problem I can articulate about my current rule-set is that it’s too much like some existing game, my solution is not to search for ways to differentiate it. My solution is to scrap the project. Otherwise, I’ll end up with a derivative result which differs from its inspiration in ways that exist only for the sake of differentiation, and likely make the game worse. I want an actual methodology that helps me find unexplored, high-quality regions of design space.

Finally, the honest desire simply to create a fun game fares no better than any of these other motivations. If the only clear problem I can articulate about my current rule-set is that it’s “not fun enough,” I’m strongly inclined to return to an earlier, better iteration and branch out from there, or scrap the project entirely. “Not fun enough” is navigationally useless, unless I can translate it into a specific, unambiguous problem-statement that doesn’t include the word “fun”. If I can do that, great! Now I have a problem to focus on which will likely suggest new ideas and directions. Otherwise, I’m just wasting my time.

Closing Thoughts

Why might I design a game?

  • To make money.
  • To pay homage to an existing beloved game.
  • To create something original.
  • To create something fun.

There’s nothing wrong with these motivations, but they’ve never helped me design good games. I’ve always obtained my best results when I’ve ignored these motivations and focused on solving interesting problems and answering interesting questions.

Katamari vs. Peggle

KatamariPeggleKatamari Damacy is a game built around a brilliant core concept, but its overarching goal structure nearly ruins the experience for me. Here’s the brilliant part: you push around a growing ball which can grab literally any object in the game world if it grows large enough. Here’s the annoying part: in each of the main “Make a Star” levels of the game, if you don’t grow your Katamari big enough within a given amount of time, you have to start the level over again from the beginning.

It’s easy to turn a fun, sandboxy pastime into a game by adding a time-pressure to it, but that’s almost always the least interesting way to do it, and it usually has negative side-effects. For instance, Katamari’s final level is 25 minutes long, and most players will need to play through it multiple times in order to win. At the end of my first 25-minute attempt, my Katamari wasn’t even close to the goal of 300 meters. That was okay—at least I’d gotten the lay of the land, and had a better idea of what I needed to do. When the timer ran out at the end of my second attempt, my Katamari was 298 meters large, and rolling at high speed toward a juicy island full of skyscrapers. Oof. Now all I have to do is spend another 25 minutes doing the exact same thing I just did for the last 25 minutes, but a tiny bit faster. This is not good game design.

There’s a more emergent negative consequence of this goal-structure: if you get off to a bad start in a level, you can know before you’re even halfway through that you can’t succeed. In such a case, playing out the rest of the level feels like a waste of time. This is analogous to playing through the last painful stretch of Monopoly when it’s obvious that you’re going to lose. Since Katamari Damacy is a single-player game, I can at least quit and restart without annoying a bunch of other players. But if I’m doing this on almost every level, there’s something wrong with the game design.

The designers of Peggle were faced with a similar design challenge. In Peggle, you’ve got a pachinko-machine screen full of pegs, and you’ve got ten shots to try to hit all of the orange ones. On the surface, this feels nothing like Katamari Damacy, but in fact, the two games bear a deep structural similarity. In Katamari Damacy, you’re trying to collect a given amount of stuff in a given amount of time, and in Peggle, you’re trying to hit a given number of pegs with a given number of shots. The games share a pair of design problems: how do we make it fun to replay levels after failing, and how do we keep players from sometimes feeling hopeless halfway through a level? Peggle’s designers actually managed to solve these problems.

They solved the first problem by randomly distributing the orange, blue, and green pegs at the beginning of each level. The physical layout of the pegs is the same each time—that’s what defines the level—but the distribution of peg-colors within that layout is different each time you play it. You never really play the same level twice, because each replay presents you with a unique situation that you’ve never seen before. Studying the initial layout of a Peggle level is fun in the same way that studying the initial layout of a Settlers of Catan island is fun.

And then there’s the Free Ball Bucket—a steely well that sweeps back and forth across the bottom of every level. The first time I played Peggle, I wondered what it was. After a ball fell into it, I understood, and thought “I wonder why the designers did that?” A few turns later, I realized that it was a brilliant solution to a serious design problem, and is in fact the key to making the whole game work. No matter how badly you’re doing in a level—no matter how many shots you’ve wasted on poorly-aimed or ill-conceived plans—it’s always possible, in principle, that the Free Ball Bucket will save your ass and keep you going long enough to mop up the remaining stragglers. In fact, the more dire your situation, the more glorious your comeback will be if you manage to pull it off. That’s top-notch game design, and like all non-band-aidy design solutions, it doesn’t just solve the immediate problem at hand, but ends up adding strategic depth to the entire game.

There’s no easy way to apply Peggle’s design solutions to Katamari Damacy. I don’t think that randomizing the item layout at the beginning of each Katamari level would improve the game, and while it might be nice to have some way to increase your timer in the middle of a level, it’s still hard to think of a way to do this that’s always capable of providing hope and that improves the fundamental gameplay. I don’t have a good solution to offer for Katamari’s design problem, but my design experience tells me that there there must be a solution—in fact, multiple solutions—out there. The key is to insist on looking for them.

I don’t mean to argue that Peggle is an objectively better game than Katamari Damacy. Katamari Damacy is brilliant. I love the music, I love the art, I love the writing, and I love the gameplay. I just wish the designers had found some way of avoiding the “do it within X minutes” paradigm.

Blockhouse is Now Available

BlockhouseLevel059Blockhouse is now available on the iTunes App Store!

Give it a download and let me know what you think. I’m working on putting up some solution pages here on the website, but in the meantime, if you get stuck on a puzzle, just post a comment here and I (or someone else) will lend a hand.

Also, I’d like to hear which puzzles were your favorites, and why, since I’m already starting to think about what mix of puzzle-types to put into Blockhouse 2. You can let me know which individual puzzles you liked the best, and you can also tell me which categories of puzzles you preferred. I would divide the puzzles into four main categories:

  • Single-block mazes (like puzzles 26-28).
  • Single-polyomino puzzles (like 29-32).
  • Segmented puzzles (like 33-35).
  • Double-polyomino puzzles (like 36-45).

Of course, there are also puzzles that are harder to categorize, like 14-15, 46, 49, etc.

All thoughts are welcome!

Building Blockhouse

BlockhouseLevelsBy the time I decided that I was going to implement Blockhouse as a commercial iPhone app, the game design was already done. Tilt or swipe in one of the four cardinal directions to cause all blocks to slide as far as they can, and try to put them on their respective targets. What could be easier? Many aspects of the aesthetic design and the user-interface were still up in the air, but I had an inkling of where I was headed: chicklet-style blocks and walls, bright candy colors, minimalist interface. Implementing this stuff wasn’t going to be particularly difficult.

I knew that the hard part was going to be actually designing 100 unique puzzles. The only way I could think of to do this was to create some kind of puzzle-building tool that would allow me evolve, tinker, and tweak these puzzles into shape. As it turns out, I spent about six weeks on this task before I even wrote a line of iPhone code. The result was a rather clunky but serviceable OS X app called BlockhouseBuilder.

This was the first time I’d ever implemented a Mac app. Indeed, I’d only been using a Mac since about May of 2008, which is when I’d jumped into iPhone development with both feet. I knew there was going to be a bit of a learning curve. My goal was to make a fully-functioning document-based app, which would allow me to edit puzzles in groups of 100, save them, cut and paste them, undo and redo all editing actions, etc.

None of that was easy, but nevertheless I managed to cobble together an editor that allowed me to create and edit the layout of walls and blocks within a puzzle. It also allowed me to choose the grid-size of each puzzle, and I wrangled for a while about what range of sizes I should allow. Eventually I decided on an aspect ratio of 3:4 for all puzzles. This fit the screen of the iPhone well, leaving some room at the top for UI buttons. It also allowed for a nice range of puzzle sizes: 3×4, 6×8, 9×12, 12×16, and so on.

The really hard part was coming up with some way of displaying the abstract structure of the puzzles I was creating. I wanted to actually see the “puzzle-graph”—a visual representation of every possible position that the blocks could get into, along with the connections between them.

This turned out to be a tough nut for me to crack. There are algorithms for displaying arbitrary graphs, but they aren’t simple, and they often result in winding connections and crossed lines. I wanted all of the orthogonal relationships between states to be retained—in other words, if you can get to one puzzle state by swiping to the right, I wanted that state to appear directly to the right in the puzzle graph. I suspected that someone had already solved this graphing problem—if not for tilt-mazes, then for something isomorphic to them—but I didn’t know enough about graph theory to know where to look, or even to know for sure that what I wanted to do was possible in all cases.

I tried a number of different methods—even some evolutionary ones—but none of them quite did the trick. After working on the problem full-time for almost a week, I started to panic. What if the solution was simply beyond me? I couldn’t afford to keep pouring 8-hour days into it, and yet I couldn’t see how to do what I needed to do without it.

Fortunately, an new idea occurred to me involving a mix of two different techniques I’d tried earlier. I tried arranging all the puzzle positions along horizontal and vertical “struts” or “dowels”, like the beads of an abacus. Each strut contained all the puzzle positions that were connected to each other horizontally or vertically. Each puzzle position was connected to exactly one horizontal strut and one vertical strut. This created a large connected mesh of all the puzzle positions. This mesh was often too compact, overlapping itself at many points, but I could fix that by iteratively pushing the struts away from each other until no two horizontal or vertical struts lay on the same line. The result was a fast algorithm that displayed a flattened, 2D representation of the entire layout of a puzzle, with all orthogonal connections intact. Success!

Here’s a screenshot of BlockhouseBuilder in action, displaying puzzle #16 from the release version of Blockhouse.


The lower left portion of the window displays tiny images of all 100 puzzles and allows me to move between them, change their order, or cut-and-paste entire puzzles from one slot to another. The upper left portion of the window displays a close up of the selected puzzle, which allows me to add and remove blocks and walls, and change their colors. The main window displays the graph of all possible positions that this puzzle can get into, including the starting position (outlined in blue), the ending position (outlined in yellow), and the shortest path between them (represented by the weird black arrows). I can select any starting and ending positions in the graph, and it will instantly show me the shortest path between those two positions. I also created some buttons that automatically find the ending position that’s furthest away from the current starting position (in number of moves), the starting position that’s furthest away from the current ending position, or the longest path between any two positions in the entire puzzle. This was helpful, because in general I wanted the starting and ending positions of a puzzle to be as many moves apart as possible. Finally, I created a button that allowed me to export the collection of 100 puzzles to a property-list file, which I could then include in the iPhone application bundle.

Once I solved the graphing problem and implemented the above functionality, I started adding other features that I knew I was going to need in order to design 100 interesting puzzles. First, I added a bunch of criteria that all puzzles had to meet in order to be exported. Most importantly, all puzzles had to be “connected”. In other words, for any given puzzle, it had to be possible to reach every puzzle state from every other puzzle state. I wanted every puzzle to remain solvable, no matter how you moved the blocks. I did include a reset button in the final game, but it’s always optional. Mostly, it’s there so that people can easily input the online solutions when they give up on a puzzle, but sometimes it’s just nice to get a fresh start on a puzzle when you’re stuck in a rut.

I also implemented some other criteria. For instance, I didn’t want the starting blocks to obscure any portion of their destination footprints. I planned on representing the block destinations using painted marks on the floor of each puzzle, and I wanted these marks to be visible at the beginning of each puzzle. There are plenty of perfectly good puzzles in which two blocks (for instance) swap positions, but I decided to disallow these. Beyond this, there are other criteria that are too obscure to even bother describing.

I didn’t know what percentage of puzzles would still be valid after pruning out all of the ones that didn’t meet my criteria. There was some risk that it would be very low, which would make it a lot harder to come up with interesting puzzles. Fortunately for me, this turned out not to be the case.

After about six weeks of working on BlockhouseBuilder, I was finally ready to actually start working on the iPhone app that would read the property-list file and let me play the puzzles I was creating. The bulk of that work took about a month, and then I spent another couple of weeks integrating the two, adding more features to BlockhouseBuilder as the iPhone app required them.

When it finally came time to start designing all 100 puzzles in earnest, I still felt pretty overwhelmed by the task, even with my fancy new tool at hand. Therefore, I added an “Evolve” button to BlockhouseBuilder. This button caused the program  to create thousands of variations of the layout of the current puzzle, looking for various criteria, like a particular ratio between the longest path and the total number of positions. With the click of a button I could have the program spit out a random variation of the current puzzle that was “better” in some way. Determining what counted as “better” was a black art, and I didn’t bother building a UI to tweak these values, because I had no idea what variables I should even be tweaking. Instead, I just kept changing the actual code for the “Evolve” button, recompiling BlockhouseBuilder, and playing around with the results. So I’d set up the basic situation—the size of the grid, the shapes of the blocks—and then I’d start hitting this button over and over again, cranking out a ton of evolved variations. Of course, on top of this I did a lot “artificial selection” (i.e. tossing out results that were unacceptable for various reasons), and manual high-level tweaking.

It was kludgey, but it worked. Exploring the puzzle-space in this way was fascinating, and because of the evolutionary nature of the process, I didn’t automatically know the solution to each new puzzle that I came up with. Not only did this allow me to play (and enjoy) hundreds of these puzzles myself, but it allowed me to directly test how difficult various puzzles were. It also allowed me to answer a few questions I’d been curious about for years. For instance, what’s a good ratio of path length to total number of puzzle positions? I found that it was somewhere between 1:2 and 1:3. In other words, if it takes 15 moves to solve a puzzle, I wanted there to be about 30 or 40 total positions in the puzzle. How hard do puzzles get as you increase the total number of positions? I found that 100 total positions is usually too hard. Most of the puzzles that I included in the final product have between 30 and 80 total positions. On the other hand, there isn’t a one-to-one correspondence between total number of positions and difficulty. I found some 40-position double-block puzzles that I was incapable of solving after multiple hours of trying.

As I explored the space, the puzzles I came up with fell into four distinct categories, each of which had its own flavor. The most basic type of puzzle contained only a single square block. These puzzles were only interesting on grid-sizes of 9×12 or larger, and I decided that they should all be explicitly maze-like. As it turns out, my evolutionary process wasn’t very good at coming up with maze-like puzzles, so I had to do a lot of manual editing on these. Another type of puzzle contained only a single polyomino. These puzzles were also only interesting on grid-sizes of 9×12 or larger, but unlike the puzzles in the previous category, these puzzles didn’t work well as mazes. Instead, they worked well in more open spaces peppered with single-square walls. Another type of puzzle consisted of two or more single-square blocks, each in its own walled-off compartment. These had a unique flavor, and were too difficult if larger than 6×8. The fourth type of puzzle consisted of two polyominoes together in the same compartment. Most of these puzzles were way too difficult if larger than 6×8, but they became easier if the blocks were large, because large blocks fill the space and cut down on the total number of positions possible. This was my favorite type of puzzle, and they make up about half of all the puzzles in the final product.

All in all, it was a fascinating project, and I hope some people get a kick out of the result. You can count on seeing Blockhouse 2 at some point. The puzzle-space is huge, and I’ve got BlockhouseBuilder burning a hole in my pocket…