Extreme Game Makeover - Part 2

Municipality has three stubborn problems which I had decided to finally tackle:

1. Endgame is too mathematical
2. Some of the roles are "boring"
3. Growth is too complicated

Last time, I discussed the first problem, how I was going to prevent the endgame from being too mathematical.

This time, I will go after the second problem, that some of the roles are boring. I mentioned that my answer would be M.E.A., but did not explain the acronym. Well, M.E.A. stands for Make Everything Awesome.

Perhaps a bit of background is in order. At the suggestion of a friend I read an article from Game Developers Conference 2010 on Sirlin.net. GDC is primarily about video games, but I found the discussion highly relevant to board games. Specific to my dilemma were the following passage:

Pardo and I both said that you have to be careful of mathy people who want to balance the fun out of everything. Like we could bring the power level down to be boring and make things balanced, but that fails at our goal of making things FUN and also making different weapons/characters/whatever extremely DIFFERENT from each other. Griesemer's version of this same idea was the concept of making everything crazy powerful, and balancing that. Don't make everything really weak, and balance that, it's boring. If everything is overpowered, then nothing is overpowered.

And this one:

Like Griesemer, Pardo said to make everything overpowered. He cautioned against letting math people balance everything into boringness. Make big exciting effects and moves units and so on and have the confidence that you can balance them at that level. He also said "it doesn't cost anything to make something epic."

That mathy person who wants to balance the fun out of everything? That's me. While choosing the roles available in Municipality, I created a few "utility" roles.

These utility roles are meant to help a person out of a difficult situation. When you're in such a situation, they are extremely useful. However, to prevent them from being too useful, I made them (more or less) pointless when you're not in a difficult situation.

My playtesters hated these roles. They understood their necessity, but didn't like it when they were forced to "waste" a turn picking one of them. The accumulation of Political Capital on unchosen roles was supposed to take the sting out of this, but even though it was nice to get two or three PC as compensation for choosing a utility role, it was still boring.

I didn't want to add on additional powers to utility roles, because I was afraid they would be too powerful and the "core" roles would not be chosen often enough, slowing down the game.

After reading this article, and speaking to one of my testers, the solution dawned on me: Make Everything Awesome. That is my new mantra. How will I apply it? I will make the utility roles awesome. I will make the core roles awesome. Every role will be a BFG.

It will be harder to balance. I might even mess up the balance. But it is better to have a slight imbalance of awesome than to have a player suffer a perfectly balanced, boring turn.

Next up: solving the problem of population growth being too complicated.

Extreme Game Makeover - Part 1

I held another playtest for Municipality to confirm whether the anemic population problem that appeared in the previous test was real or a one-time occurrence. The good news is that the latest test had no population problems.

Version 5.0 test 1

• Total Popoluation: 20
• Highest Player Population: 8

Version 5.0 test 2

• Total Popoluation: 66
• Highest Player Population: 38

The bad news is that it doesn't matter.

I've finally become convinced that I have to deal with some problems I've been avoiding since the earliest versions of the game.

1. Endgame is too mathematical
2. Some of the roles are "boring"
3. Growth is too complicated

These are all problems that I have felt were an innate, if unfortunate part of this game. Sure, I wanted to ameliorate them as much as was possible. However, I didn't think the core design allowed them to be removed completely.

This has happened before. With Titans of Industry, there were a couple of design choices I made early on which I refused to remove. I ignored the feedback of playtesters and even my own gut instincts. I let these design elements fester and waste enormous amounts of playtest time.

One playtest was the straw that broke the camel's back. After that test, I completely remodeled the resource structure for Titans of Industry. In the end, it was a much better game for it.

This past playtest, as well as post-test feedback from the players, has finally convinced me to abandon the elements causing the three problems listed above. Hence, the radical makeover that Municipality will be receiving.

First up: the endgame is too mathematical. Many heavy strategy games see the final one or two rounds lasting several multiples those of the prior rounds. This is not simply because the board is more developed at the end. It is because players begin to completely game out the entire round and every variation thereof.

Even though many great strategy games suffer this problem, that is not an excuse to allow it in my design.

The first step I've taken to combat this problem is pictured above.

Currently, in Municipality, money is hidden information and Political Capital is public information. This means that during the final few rounds, players have been observed obsessively calculating bids of Political Capital in an attempt to predict exactly how much each opponent will have when a crucial role is activated during the final round.

Going forward, both money and Political Capital will be hidden information. To accomplish this, I have designed cards, pictured above, to replace the paper money and Political Capital chips. The cards will have a common back, to further disguise how much Political Capital each player has.

I am confident that, thanks to this change, the amount of time spent on the final three rounds will drop by a third. This will help me keep the total playing time, which has been inching up, within my goal of a 60 to 90 minute window.

Next time, I will tackle the next problem, that of some roles being boring. Hint: M.E.A.

Overcorrections to Overconnections

Municipality has been having a recurring problem. By the end of the game, almost all properties have been connected by the players. Ideally, I'd like see two or three smaller groups of properties instead of one large group.

Originally, I attempted to accomplish this by allowing some permit types to grow merely by being adjacent to something and not having to connect to it. This way, players who were placing such a permit would have an incentive to intentionally not connect permits, especially if doing so would add to opponents' growth more than their own.

However, playtesters still connected to opponents' properties at every opportunity. When asked about this, it seems playtesters were only concerned with maximizing their own positions and the possibility that they were helping opponents more never crossed their mind.

My next tactic was to limit how much an individual permit could grow on a single turn. My hope was that players would realize an additional connection would not actually help their growth, which was already at the limit. My hope was false. Again, players just continued to connect to each others properties at a rate reminiscent of a social network.

I finally gave up on trying to convince players to not connect all willy-nilly. I decided that I would just prevent them from doing it outright. There are two obvious methods for doing this:

1. Set a rules-based limit (i.e. You may not create a connection that would create a group larger than #
2. Make it more difficult to do it in the first place

The first choice is not only clunky, but is something players are likely to forget during play. The second choice was clearly the better option.

I decided to implement this by reducing the amount of road on each permit card. You can see the changes below. On the left are the original layouts of the Housing and Special permits for version 1 through version 4.5. On the right are the 5.0 versions of those cards.

As you can see, I only removed 25% of the road from the Housing (and Office and Industry) permit. Although I removed 50% of the road from the Special permit, those only represent 20% of the deck.

This doesn't seem like a large reduction, does it? Pre-testing, it appeared to be exactly the fix I needed for the connection problem. Post-testing, not so much. Take a look at some end-of-game statistics:

Version 4.2

• Total Popoluation: 108
• Highest Player Population: 54

Version 4.4

• Total Popoluation: 52
• Highest Player Population: 27

Version 4.5

• Total Popoluation: 71
• Highest Player Population: 37

Version 5.0

• Total Popoluation: 20
• Highest Player Population: 8

I use population statistics as a proxy for connectivity as a high number of connections leads to massive growth. My goal has been for players to end the game with between 10 and 20 population apiece.

As you can clearly see, I have wildly overshot my goal with version 5.0. At least, I might have. So far, I have only had one playtest with this new version. So it is entirely possible that this test just happened to be at the tail end of the bell curve caused by the styles of the specific playtesters involved.

If so, then this test was was an aberration and should be ignored. If not, then I need to backtrack and find a new solution.

I'm not ready to abandon this new layout just yet. I am going to run a couple more playtests and see if other groups of players also build in such a way that populations stay this low.

In case I do end up having to scrap this change, does anyone else have more ideas on how to indirectly control connections?

NYC BGD Meeting - March 2010

Saturday I hosted the monthly meeting of the New York City Board Game Designers group. This month attendance was relatively low; we had five designers (including myself) show up.

First we played two games of an expansion for Mark Salzwedel's tile-laying game, Fourth Corner. The expansion added a new mechanic which, as implemented, didn't add anything strategically important. However, we did come up with some suggestions on other ways to implement the mechanic that would make it useful.

Next up was a test of a non-auction variant of Gil Hova's economic efficiency game, Pax Robotica. As much as I like auction mechanics, I felt the game did much better without it. The auction took far too much time in the game. At least, it did the last time I playtested this (admittedly over a year ago).

After that, we tested Municipality. I was generally pleased with how the game itself progressed. It only took 78 minutes and the top two players ended only 8 points apart, less than a 5% difference in final scores. Last place was 120 points behind, but I believe that was because of some serious, and repeated, gameplay errors. Is it necessary to prevent players from making bad choices? I go back and forth on whether I need to do something about this.

The only other thing that bothered me was that I once again saw the appearance of a mega-neighborhood. People seem too eager to connect everything together. They don't realize when hurting yourself a little is okay if it hurts everyone else far more. Again, I don't know if I should just live with this sub-optimal play, hint players away from it, or prevent it altogether. I want the game to end with two medium-sized or three small-sized neighborhoods. I just need to figure out a way to get there.

The changes to Surveyor and Zoning Board were fantastic. People love having choices. Unfortunately, those choices are helping create the mega-neighborhoods. I need to give this some thought.

Also, the limit on Campaign Manager was also very important. Now players cannot just wait for the end of the game to jump from one to ten approval in a single shot. Making them move up in smaller bunches created a rising tension. Players could see their opponents moving up the ladder over time, prodding them to follow suit.

Gil felt that the game was "fun but unsexy". While I am gratified that it is fun, I am discouraged by the "unsexy", as that is exactly what keeps publishers away. I can't seem to get past the mechanics and make my games fun to look at. I have to figure out how to make a game that someone walking through a crowded convention hall will, spotting it in the corner of his or her eye, stop and say, "Hey, that looks cool. What is it about?"

It is a skill I need to learn. Can anyone out there give me some pointers?

Everyone was agreed that the game has a steep learning curve. There is confusion at the beginning over what the different roles do. People keep confusing the Surveyor and Zoning Board, or thinking that one of them does both actions.

I also need to work on the player card. I need to highlight both add more information and simplify the layout. Yes, these are somewhat conflicting goals. Sometimes, I feel like Sisyphus.

For the next version, I am going to address one of Mark's concerns, that having two types of population limits (total population and per-turn growth) is confusing. I will probably just make it per-turn growth, but set them very low, so factories can't become better versions of houses.

Also, I think I should add population loss to double-taxation in addition to the current approval rating loss. This would prevent the cyclical "Grow-Double Tax-Convert to PC-Bid on HHS-Grow" strategy. At least, it would slow it down. Losing one population from each property won't stop you from double-taxing, but it will make it slightly less powerful.

Municipality seems to be strongest with four players and weakest with two. I keep wanting to allow five players, but I can see that everything would come off the rails if I did so. It is just not a game that can scale any bigger, to my chagrin.

After Municipality, we played Lionel's game. It was an identity deduction game with a unique theme. The problem was that he didn't give the players the standard tools of deductive games, including an information tracking sheet. Without it, needing to remember information about each opponent over many rounds was impossible and the game fell apart pretty quickly. We also discussed how he was presenting identity information to the players in the first place; we showed him how it could be reorganized in a more intuitive fashion.

Clay Ewing's game was next. It was an economic game that blended reverse auctions and risk management. The game was both interesting and tense. The problem was that the math didn't work. At first, it made more sense for me to do nothing with my resources, because they just accumulated interest automatically. We switched mid-game to a rule that forced you to play your resources.

However, the new problem was that playing resources for victory points could cost you massive amounts of money. While it was almost always worth it at game's end, in the short term you could be massively screwed by lack of cash flow. It also had a bit of a slippery slope problem. We all fell down the slope (because the numbers on the cards didn't work out), but the one of us who first stumbled was clearly hobbled for the rest of the game.

Clay's game shows promise. It has a great theme and interesting mechanics. Once the numbers are rebalanced, he'll have a winner on his hands.

Finally, we played another of Mark's tile-laying games. This is one I tried a few months back and it is vastly improved. The previous version suffered from it being too easy to prevent anyone from scoring points. Now the game has incentives for cooperation. It still needs a little bit of a push away from attacking each other, but it is headed in the right direction.

That was it for this month's meeting. Played a couple of fun games (I'm definitely a fan of Pax Robotica) and obtained useful feedback for Municipality.

Ode to Fantasy Flight

I don't know if Toothpaste for Dinner was actually talking about them, but it comes pretty close!

Dreamation 2010 - Sunday

Sunday at Dreamation was not as great as Saturday had been, but was nonetheless quite productive.

I had a playtest for Municipality scheduled for Sunday at 1:00pm. While I did have a successful playtest the previous day, I was not optimistic about Sunday's session.

Sundays at conventions are notorious for being low-activity days. This is caused by several factors.

1. People are tired out from three previous days of gaming
2. They have generally forgone sleep for extra gaming
3. People want to say goodbye to friends they might not see for awhile
4. Some people leave immediately after checking out of the hotel Sunday morning

You can see why I didn't expect anyone to show up. Since relatively few people are playing games on Sunday, the chances of them including someone who wants to playtest are pretty low.

However, when 1pm rolled around, I was pleasantly surprised when three people showed up. One of them had even tried to playtest the previous day but had arrived when the playtest was already in progress. It was great that someone I'd never met was willing to try twice to playtest Municipality.

The playtest went well. Although the testers generally had positive things to say, they also gave some valuable feedback about problems with the game. I have already incorporated some of the changes we came up with during the postmortem into the following version that I tested on the 27th. I am quite grateful that they took the time to help me test Municipality.

Following the playtest, I spent some time speaking with friends before packing it in and heading home. All in all, the weekend was well spent.