Last time, I discussed the design goals that have guided my latest project, a drafting board game about fungus releasing spores from a pile of rotting logs (tentatively called Fungus). Today I’ll describe how those goals have helped shape the game through the iterative design process.

Lend Me a Hand

More Fungus concept art!

Let’s start with an awful playtest! It took place in a dark, loud bar with a bunch of moderately intoxicated friends after playing other games for hours. By the end of the game, my playtesters were confused and frustrated. But through the disappointment I learned a very valuable lesson: players need some guidance from the beginning.

You see, I assumed players should start with nothing but a draft pool and build up from there, like other drafting games. But this ended up violating two of my design goals.

First, it made the game more difficult to learn, breaking goal 10. Easy to learn, difficult to master. Giving players a starting hand helps guide their early draft picks (since they start with some potential goals and resources). This makes the early turns less overwhelming.

Second, goal 4. Always something there, was pretty much thrown out the window without a starting hand. Some powerful cards in the game require you to build up before you can play them, so you might draft them early planning to use them later. But if you don’t have any cards in your hand and take a card to use later, you can’t do anything on your turn, which is totally boring!

After my playtesters helped me identify this problem, it only took a few games with starting hands to realize the change was simple and a huge improvement.

Counter-Intuitive

The very first version of Fungus included counters, surprise cards that stop another player’s action. They were included for more than just the fun of it–they have three very important uses.

First, they can be used as protection against attacks, therefore supporting design goal 11. Keep it clean.

Second, they provide interaction between players, for goal 1. Lots of interaction.

Finally, they act as a pressure valve, ensuring that any cards that are too powerful have something to keep them under control. (Note: This is pretty lazy. It’s the game designer’s job to make sure there aren’t cards that are so powerful they require generic counters. But still, it’s nice having a little security.)

Putting them in sounds like a brilliant move! A job well done, right?

Actually counters cause three problems.

First, while counters prevent other players from doing nasty things, stopping someone else from doing something exciting is pretty nasty itself. It’s effectively taking something away from them, and we all know people are loss averse. So counters actually break goal 11. Keep it clean, even while supporting it at the same time.

Second, counters really complicate turn order. It is almost impossible to be explicit about when you can use them without introducing something messy like the stack from Magic. So counters violate goal 10. Easy to learn, difficult to master.

Third, counters can really break the flow of a turn since players have to wait to see if someone will react to every action. Even though it’s not a perfect violation, I’ll chalk this one up against goal 8. Short turns.

Third and a half, it’s very discouraging when you forget to use your counter, since you usually don’t have to worry about your cards on another player’s turn.

In short, the counters weren’t pulling their weight. I wanted them out. But I didn’t want to totally give up the good things they do, especially protecting you against your nasty opponents.

My solution was to change counters from being reactionary cards to pro-action cards. Instead of playing them in response to another player’s action, you place them in front of you and they protect you when another player attacks you–like a shield. This isn’t as nasty, since your opponent can see it coming, and it’s hard to forget since it’s sitting right in front of you.

While I had to experiment with several versions of these shield like counters, I’m happy to say they are performing well.

Aiming High

As you know from goal 9. ‘Till the bitter end, I want scores to be hidden until the end of the game. My first attempt at doing this involved special score cards that, unlike other cards, never got played over the course of the game. Instead, they gave you points for being in your hand when the game ends.

Unfortunately, people were confused by this rule, since you actively play all other cards. Additionally, this helped violate good ol’ goal 4. Always something there, since you would skip turns to keep cards in your hand.

I looked at a few other options, including playing score cards and immediately earning points or playing them face up to be scored at the end of the game, but unfortunately both of these go against 9. ‘Till the bitter end. Thankfully, a simple middle ground of playing score cards face down to be revealed and scored at the end of the game maintained the mystery of hidden scores while giving players something to do during the game. In fact, it adds great tension, since playing a score card means sacrificing another action. This makes players think carefully about when it is appropriate to spend their turns scoring.

End Game

Maybe other designers don’t have this problem, but I often come up with the structure for a game without knowing how it should end. A game should end naturally, but it also needs to end in a reasonable, fairly consistent amount of time (see goal 6. 30 – 45 minutes). Both the draft games that helped inspire Fungus, 7 Wonders and Magic, have fixed lengths, but I wanted Fungus to be a little less predictable.

In the first iteration, the game ended when the board was full of fungus. Unfortunately, this resulted in games dragging on longer than I’d like, partially because certain nasty moves go against filling the board, lengthening the game. It was also awkward and annoying when the deck needed to be reshuffled before the board filled up.

My next thought was to end the game when the board fills or when the deck runs out. The deck gives a ticking clock and avoids the shuffling problem. Unfortunately, it also feels unnatural and creates awkward situations when there aren’t enough cards left in the deck for everyone to draw a card on the last turn.

To solve this problem, I ended up sticking with the original end condition (filling the board), but I just tweaked some of the things that were causing the problems. There are now enough cards in the deck that players have never made it through all of them before the board fills up, and the number of nasty cards that can prolong the game has been reduced. Problem solved!

That said, the solution hasn’t come without sacrifices. In particular, games take 45-60 minutes rather than the 30-45 minutes I was shooting for. Thankfully, people seem happy with this time range, so I’m willing to fudge my own design goals a bit.

Keep on Iteratin’

There you have it: a glimpse of how Fungus has evolved over the past few months. Of course, that’s not the whole story. There have been three major revisions and many more minor revisions with countless changes. I’m sure I’ll have more opportunities to tell those stories at some point, but today I wanted to focus on decisions that were informed by my design goals. I hope it helps show how design goals compliment the iterative design process, guiding you through the big structural changes that take place early for every game!