When is Municipality?

I settled on a location for Municipality pretty early on. New York City was the undisputed choice from the get go. This was for several reasons.

• It is one of the world's largest cities
• Its various waterways make for interesting gameplay
• As a native New Yorker, I am legally obligated to consider it the center of the universe
• I you can make it there, you can make it anywhere

I still think I should have a second city on the reverse side of the board to help vary gameplay, but New York is certainly going to be one of the two.

While I have answered the "where" of Municipality, I have yet to determine its "when".

The problem is that I haven't figured out a time that would match the gameplay. The most obvious choice is early New York. Unfortunately, one of my three building types, the office tower, did not exist back in 1800. It wasn't until Elisha Otis introduced the safety elevator in the 1850s that skyscrapers even became possible.

The next choice is contemporary New York. While building an office tower in this time frame isn't an anachronism, building New York from scratch would be.

My third option is to create a fake reality, either in the future or an alternate-history modern-day New York, in which players need to rebuild New York after some disaster. This makes it easy for me to shoehorn in thematic reasoning for the various mechanics, as players can't complain "It didn't happen like that". On the flip side, it is harder to immerse yourself in a contrived universe. Many gamers prefer games that hew close to history.

The last option is to just ignore it altogether. I wouldn't try to place Municipality at any particular point in time or give it any back-story. It just is what it is. This option requires the least effort on my part, it also will turn off players who enjoy a game's theme. While I rarely care about a game's theme and only evaluate the mechanics, I am a rarity in this respect. This option is pretty much a non-starter.

This isn't a pressing issue for Municipality, but it is something that needs to get decided before I start shopping it to publishers. Anyone out there care to vote on which option you'd prefer to see?

You Need a Hook

No, I am not talking about marketing. I am talking about how to write a rulebook.

About a half-hour into episode 169 of The Dice Tower, Ryan Sturm explained how to better teach people games by saying:

In order to learn something, you have to have something to attach it to. If you don't, the information just won't make any sense.

Ryan was talking about "schemas", which can be poorly defined as a subject area about which you have previous connected knowledge.

Think about the game Puerto Rico. This game can be confusing to people who've never played a game like it; all those roles to learn and the different buildings. Right away, I start teaching Puerto Rico by telling the players "You're trying to score the most points to win the game. There are two ways to do that: producing and then shipping goods, or getting money and then buying buildings. Bing! Your player now has a schema in which to learn the rest of the game. As you go over the roles and look at the different buildings, players will be able to attach that to the knowledge that they're either trying to make goods and then ship them, or make money and build buildings. They have a very basic schema in which to learn the game . . .

One of the best things about themes in games is they help players to remember the rules.

I recently played Dungeon Lords for the first time. About an hour before we began, I went through the rulebook. I'd been told that it was an excellent example of how to teach really complex rules. This is, without a doubt, a rules-heavy game. However, the rulebook was actually quite well designed.

My favorite design tactic used was when the game had some fiddly, hard-to-remember rules which were obviously only there because playtesting showed it was needed for balance. In these cases, they had characters make up a ridiculous but thematic explanation for that rule.

In the example shown here, Priests' inability to heal when no combat has occurred is explained away as a result of them being the medieval equivalent of Rules Lawyers, gaming the system so that they don't have to work too hard.

This is a clever way to not only help players remember the rule, but defuse any potential reactions of players along the lines of "That makes no sense, they should always be able to heal." During playtests, I get more feedback from things that really boil down to thematic reasoning than I do feedback about game balance. The playtesters aren't wrong. It is my responsibility to provide an intuitive thematic framework for the mechanical decisions I've made.

I doff my cap to whoever came up with this approach. I shall have to steal it.

A Little Perspective Goes a Long Way

Something that always surprises me is how people can react to nice components in a playtest. It's not that people demand a prototype look nice. But when it does, they mention it, and I think that might color their overall impression of the game. Being in a positive frame of mind changes how a person evaluates something from looking for things to dislike to looking for things to like.

So, as I'm approaching the "finishing" date for design of Municipality, I've begun to try to make it look nicer. Below are the current permit card designs.



Since Municipality is played from a bird's-eye view, I wanted the new art to have that perspective. Here is a first go at it from my whiteboard.



The problem with using perspective is that since things are no longer icon-based but are an attempt to look natural, people might not like that things are completely wrong.

The scale of the buildings are completely wrong, relative to both the board and to each other. A single space is supposed to represent dozens of buildings, but if I showed that everything would be too small to distinguish. It is clear to see how even then I've sized up the houses so they're visible when compared to the office tower.

We'll see how this goes over at the next Municipality test.

Things to Keep in Mind

How to get unstuck

Municipality - Week 22

I finally got a chance to test the drastic changes I spoke about previously.

Over the 4+ years I've been designing games, I've gradually gained a sense of how far away from being "complete" a particular design of mine is. And something I've learned is that while minor changes reduce the amount of time remaining until a game is mechanically complete, large changes reset the clock. The larger the change, the further back it is set.

Version 6.0 of Municipality marked these major changes, and I was prepared to have my mental clock set back from 2 months to 4 or 5 months.

Andrew Parks and his team were the first ones to test this version of the game. While Andy tested Municipality version 3.2 back in December (and I had since incorporated his suggestions from that test, the other testers had not seen this game before, so I was prepared for some pretty strong feedback.

The test went much better than expected. Reactions were quite positive. The new mechanics, especially for growth were a fantastic success. Most of the negative feedback I received were things that can be easily dealt with by simply tinkering with the math of the game. The rest concerned the art and graphic design of the game. Mechanically, I believe it may be only balance tweaks from here on out.

My new over-under on "finishing" Municipality? 10 weeks.

Open-Source Board Game Design

There is an attempt to create an open-sourced (kinda, it is only free as in beer, not free as in speech) game with the ultimate goal being to teach children about the animal kindgom. The game is called Phylo and shown here is one of its cards.

I've been thinking recently about collaborative game design. My own weaknesses as a designer have become more obvious over time and I've been thinking about how to get help with areas I am bad at. When I saw an attempt to design a game not with two or three people, but with anyone online who wanted to pitch in, I was intrigued.

I spent some time browsing the game's site and forums. I found some things they were doing right and some things that highlight the problems inherent in distributed game design.

First, let's talk about the smartest thing they've done: stay away from Pokémon. It was annoyance with children's greater knowledge of Pokémon over real animals that inspired Phylo in the first place. I'm sure this made the natural path to steal or closely mirror that of their bête noire to attract the children.

By going a completely different route, they have both given themselves credibility as well as avoided the trap of being seen by potential players as "like Pokémon, only without cool monsters".

Secondly, they've also put the crowd-sourcing to good use in the art department. For me, game art is an annoyance that I suffer only to the point of making prototypes playable. By not putting the burden on a single person for all of the art, they've reduced the boredom stemming from this ancillary activity.

Thirdly, crowd-sourcing also works well for their individual card design. Collectible card games feature dozens of minor variations on cards. This is not something you want to do all by yourself.

However, it appears the open source process is failing in some other respects.

Primarily, people are focusing on the least important parts of the game. Adding illustrations is nice, but the rules were written by a single person and don't appear to have been refined much at all. Furthermore, it is pretty poorly worded (I'm a heavy board and CCG player and this took me a few passes to wrap my head around). No one is taking charge to make sure that these get tested and changed when needed. This game needs more design work and less arguing over the font for the logo.

The other problem I noticed is that when you have lots of people work on a game, things become inconsistent. I don't know how this could be avoided.

Finally, I cringe when I see things like this:

Keywords are AWESOME. Use them.
If you're submitting a whole bunch of cards at once read over them and if you find you're saying almost the same thing over and over and over again in slightly different variations, consider making that thing a keyword instead.

For example, if you have several cards that are predators you may have described it slightly differently each time you described the effect. "The predators eats its target" "The predator hunts its prey" "the predators exhausts the target creature", etc. Make it a keyword instead! Condense those similar sentences into one keyword "Predator" and replace the text with the Keyword. Then everytime it appears on ANY card, it always works exactly the same.

Keywords also make it easier for younger kids to play since they may be able to recognize the Keyword even when they couldn't read the whole sentence without help.

Keywords also make it easier to play with cards in translation. Then only the rules for the Keyword itself need to be translated, not each individual card. Predator does the same thing in English and French. The French speaker just needs to be able to recognize the English word and can read the meaning of that keyword in the French rules. (or in Chinese or Russian or Inuit or whatever language the core rules are translated into)

Keywords increase accessibility.

They absolutely do not increase accessibility. Keywords are great for experienced players. They know the game. They've played it 100 times. Keywords let them quickly ascertain the game state without wading through unnecessary text.

What keywords do not do is help first-time, young players access the game. While I will agree that it is easier to read one word than a whole sentence, it is far more difficult to remember what complex game mechanic that keyword is supposed to instruct you to perform than to just read the card and do what it says.

This is especially true when you have lots of keywords, which is exactly what this person is instructing everyone else to do. You do not want players to have to reference the rulebook 20 times during their first game, or there won't be a second game.

Keywords make things easier for game designers. They make things prettier for experienced adult players. They do not increase accessibility for first-time players, especially children who won't be able to memorize these things beforehand.

Things That Make Me Weep

Have we become so dumb that Scrabble is now too hard for our withered brains?

The Colbert Report	Mon - Thurs 11:30pm / 10:30c
Scrabble Allows Proper Names
www.colbertnation.com
Colbert Report Full Episodes Political Humor Health Care Reform

Extreme Game Makeover - Part 3

This post will complete my three part series on the drastic changes I am making between versions 5 and 6 of Municipality meant to deal with the following problems:

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

The first episode had me addressing the problem of the endgame being too prone to math-paralysis. The second entry dealt with the problem of necessary but boring roles.

The final stubborn problem is the complicated nature of growth. Population growth is an integral part of the game, it is one-half of the formula that determines end-game scoring. In addition, many of the other choices in the game are only meaningful to the extent that they affect population growth.

The growth model is based on both proximity and connections to different types of zones. To remove the complexity of the growth model would drastically reduce the strategic potential of the game. This is why I have been so reluctant to address this problem. The most I've done is play with different ways to represent the growth on a player card chart. I had hoped that if I explained it well enough, the complexity would disappear.

It did not.

So, if I could not remove the complexity, and I could not explain it into simplicity, what could I do? My only remaining option was to reduce the frequency of the complexity. If a complex action occurs less often during a game, the overall complexity of the game drops.

Players are willing to think hard about their choices, as long as they aren't doing so for two continuous hours. Players need to alternate between formulating strategy (high levels of thought) and executing that strategy (relatively low levels of thought). Now I need a way to reduce the frequency with which players have to calculate growth.

Currently, players calculate growth rate at two points. First, they calculate it while placing permits down in order to decide what is best to place and where. Second, they calculate it when actually executing growth.

Strictly speaking, calculating it while executing growth is the only necessary one, because otherwise you wouldn't know how much population to add. Calculating while placing permits is actually optional; a player could theoretically place without thinking about growth and the game would proceed just fine. Therefore, that means I should remove the optional point at which players calculate growth and leave only the necessary point, right?

Wrong.

Players are calculating it while executing growth because they have to. They calculate it while placing permits because they want to. When faced with removing one of two activities, never remove the ones players want to perform and always remove the one they are forced to perform. Players want to calculate their strategy. They don't want to calculate bookkeeping.

How do I remove the need to calculate growth while executing growth? By making actual growth independent of calculating it. One playtester of mine has been suggesting for months that I place growth indicators on the permits that indicate how much their population should change every time growth is executed. I resisted this suggestion because I didn't want to make the board busy with both population cubes and growth indicators on the permits.

While my instinct to not mix the two was correct, my choice in which one to remove was wrong. I have realized that there will be no population on the permits themselves, only growth indicators. Population will now be centrally tracked for each player. (There already was a total population track to remove the need to constantly count cubes on the board, but now this will be the only record of population.) This step will remove the need to calculate growth while executing it. Though this doesn't remove the most complicated part of the game, it does severely reduce its frequency, which is almost as good.

Now, this change will be paired with another. Currently, growth is far stronger in the late game than in the early game, when the board is not nearly as developed. This means that players mostly avoid the growth role in the beginning and scramble for it towards the end. I wanted to smooth out that curve.

The way to do that was make when the role is activated independent of its total effect. The way to do that was to disconnect its magnitude from the board development level. However, if your board position doesn't affect your growth, then what is the point of developing the board? The answer hit me like a freight train. I decided to make growth relative to other players, instead of based on your absolute board development.

Every time the growth role is activated, if a player has the most developed position, they gain 5 population, the second most developed player gets 2 population, and third place gets 1 population.

This has two advantages. First, the growth level will be as powerful at the beginning of the game as at the end. Secondly, players will push each other to keep developing, because if they fall behind, their relative position will handicap their growth for the entirety of the game.

Giving a temporary development bonus to whoever controls the role was the final piece of this puzzle, as if all players were gaining there would need to be an incentive to be the one to actually control the role.

The changes I've outlined for the three core problems are pretty big. I expect the next playtest will be chaotic, as making so many large changes is always a bad idea.

My friends will tell you that I've never shied away from a bad idea.