Apr 5, 2010

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.

2 comments:

  1. I like! My only question: If this change goes in, what is the strategic advantage of A1 vs B2 vs D5 etc when I'm choosing a zone to buy...?

    ReplyDelete
  2. The strategic advantage is still that it will affect your growth rate, but indirectly. You still want to put buildings where they will "grow", because it is your total growth factor that determines your rankings for actually gaining citizens.

    ReplyDelete