Analog Games: Rapid Prototyping at BoardGameJam (Part 2)

(This is a continuation of the last post about rapid prototyping a board game at Boardgame Jam last week, you can find that post here)

At the start of day two, I had pre-defined a few more additional stats and base game structure: Each player will start the first round with one food truck in hand (the first four food trucks are equal), in order to prevent initial game starvation for players who didn't bid.

The first playtest

After constructing all the parts needed (food and people tokens) it was off to the races.  We quickly discovered the first stumble block merely by just explaining the basic rules:

• When moving, you must choose a position of a street, but then the cost of relocating on the same street is unfairly high
• Since moves cost 1AP, what happens if you move to a street that is filled with cars?  Is that 2AP? Do you execute both AP immediately?
• Can you bid for more than one food truck within a round?

These weren't exactly showstopper problems, so I gave a quick bandaid fix (yes but no fix, ignore the case for now, yes) and reconsider it for the next playtest.  But within two full rounds, we had to stop the game because of numerous issues that had popped up:

• Limiting only two food trucks to be bidded up on turned to be a very limited tool.  The initial intent of this limit was to drive up scarcity for trucks and cause players to compete in bidding.  However, it ended up being a high stakes scenario that quickly spirals out of control (as noted later)
• Allow a player to buy up both trucks available within a round, when combined with the limitation of only two trucks, served to widen the rich/poor gap in the game. Since the number of trucks represents the number of actions, the more trucks a player has, the more actions they can make at a given turn.
• Since movement and serving food both cost 1AP, it was strategically beneficial to idle certain trucks who are controlling a sparsely populated area.  This resulted in the richer players (once with more AP) to spend movement tokens, whereas others were left waiting, further widening the gap
• The Dice Roll mechanic used to spawn customer location (2 sets of D4 rolls, and computing which coordinate needed the spawning) slowed the game down dramatically during each round.  The setup was fairly slow (and would only get worst as more people are spawned on later rounds)

Back to the drawing board...

With the first playtest completed, it's time to address the problems with different solutions:

• Spawning customer was needlessly complicated by dice roll/coordinate matching.  One quick solution that was suggested was to replace it with a small deck of 16 cards, shuffled every round. This gave the intended randomness, but without the long wait and needless calculations.
• Increase the limit of food trucks in bidding phase to four, and restrict only one bid per turn.  I had shied away from these two rules on bidding because they seemed to be aping the template set by PowerGrid (you'll see this becoming a recurring theme), but it was pretty evident that they were in place as a way to "rubber band" progression.
• Create "fuel token" resource - Just like food tokens, a consumable resource that players must buy and have in inventory before using.  This would then be used to layer on top of the action phase, but instead of 1 AP dictating 1 unit of movement, fuel determines how far a player can go within 1AP.   Movement, therefor is now a function of money and action (in contrast to just action before).  This new feature also fixes the problem with area control in the first revision (moving from one position to another on the same street remained unchanged)

The second playtest

With these rules in place, I had around half an hour to run through a second set (it was a tight schedule).      Once again, we stopped within two rounds, with the following observations:

• Using a card deck to generate the spawning position was a drastic improvement in speeding up setup time.
• Fuel token solved overlapping issue, but the cost associated was high enough that it prevented people from moving
• Having more trucks available definitely let more people buy trucks, but...

• ...since the food truck deck was totally random, it was still boiling down to who's got more money: the person in the lead can expand the fastest and use their biggest truck to grow their resources faster
• the turn order made it too powerful for the leader in a given round: they get first rights to bid, placement, and movement.  
• Linearly scaling the amount of actions per truck still means that the more trucks you have, the more powerful you become
• The cost of the food truck purchases and how many people it served were irrelevant: how much each truck paid out heavily influenced each players' purchasing power.
• Since everyone could have had different action counts, it was hard to keep track

Unfortunately, that was all the time we really had, so that was the end of development.

Lessons learned

I think it was interesting that I was able to distill the main problem down to just rubber banding within two playtests.  I knew from the beginning that the numbers were going to be problematic to balance (and at the current state, none of the cost were actually balanced and some were using my first draft of data).  One regret I had was dialling too many knobs between individual rounds: by changing 3 or more variables, it's hard to tell which was the one that really made the most impact.

One nagging concern I had during the entire development process was thinking of ways to distance myself from mechanics found in PowerGrid (and defaulting to their way of approaching how to balance a game).  It's really interesting to have tried out different ways, and seeing why it doesn't work, and why PowerGrid chose it's numbers and methods to balance the game out.  Right now, I have a list of other things that I would like to try next, and since I'm no longer working under a 48 hour deadline, I'll probably take them slowly:

• Play around with reversing turn order
• Some sort of ranking system (and not use the simple "everyone get's a turn")
• a pseudo-sorted system of trucks
• Multiple food types with differnet cost
• Max limit on carrying food/fuel on each truck
• Implementing action tokens to denote turns
• Get away from linearly scaling action points per truck
• etc...