Scoville Protospiel Recap
I had the privilege of attending my first Protospiel this past weekend in Milwaukee. Protospiel is a convention for game designers to bring prototypes and get feedback from other designers. So I took my game Scoville along and got some awesome feedback! I think that I’ll focus this recap on my game rather than provide opinions of the games I played that are unpublished. That would not be fair to the designers even if I really enjoyed their games since all the games I played are still in progress. So rather than posting a drawn out chronological recap of the weekend I will just post the drawn out highlights for the play tests of Scoville.
I was fortunate to have Scoville played five times and was pleased to play 8 other games by other designers. Protospiel is an awesome thing for a designer to attend!
Here’s a little background about my Protospiel expectations and goals…
Protospiel: First Contact
Coming to Protospiel I had two goals: 1) validate whether or not Scoville is any good and 2) connect with people who know what they’re talking about. A secondary goal was to leave a copy of the game with Grant Rodiek for inclusion in the Prototype Penpal Program. That was something I could always do later on, but I thought it could be cool to send a copy off with him.
I also had some expectations about the feedback I might receive. I knew that I wanted to adjust the auction phase of the game. So I to see the same feedback about it that I had seen from my prior play tests. I was also a little uncertain about the quality of my prototype (that thought was quickly vanquished!). Thanks to everyone for the kind words about the quality of my prototype. I’ll post an article sometime about how I make prototypes.
So if I received validation and made some connections then I would have considered this weekend a success. Let’s see how it went.
Scoville Play Test #1
Getting to the convention at 8:15am on Saturday allowed me to get my game set up right away since few people were there. I got four people to give it a go and they seemed to really enjoy it. I won’t explain the game much here since I’ll be writing a post all about the game itself. Here are the suggestions that I received after the game:
- Beware of color blindness (Cool apps: Color Blind Vision (Android: FREE) and Colorblind Vision (iOS: $2.99)).
- Stage II orders seem to provide too many points.
- If everyone bids zero in the auction, flop the player order.
- Put endgame trigger scenario onto the guidesheet.
- Tiebreaker should go to the player with the most coins.
- The game was described as a “Euro with luck but no dice.”
- There should be no randomly chosen player order at the start of the game.
- During fulfillment there should be the option to pay for becoming the first player.
That’s a lot of great feedback. The game uses 10 differently colored cubes so I have been aware of the color blindness issue. There are several solutions for this. The biggest takeaway from play test #1 was that I received the auction feedback I was expecting. My plan would be to test a new auction mechanic on Sunday.
One player, who happened to be the winner by a lot, wanted to try a strategy that I am aware of but have not yet seen attempted. Since peppers can be sold for coins based on how many of that color are planted in the fields there is a strategy that you can plant a pepper of a certain color in each round and harvest that same color each round without doing anything else. I have done the math in my head and I do not believe that this would be a winning strategy (at least I hoped not because that would make the game broken). More on this below.
Scoville Play Test #2
After working on Protospiel goal #2 of making connections and meeting some awesome people, they were willing to give Scoville a try. During this second play test there was more bidding and jostling of player order. I think that was the reason that the auction was not mentioned in the post-game discussion. This play also resulted in much closer scores than the first play. Here are the suggestions I received:
- Peppers should be worth something at the end (that are currently worth nothing in the endgame: Use Them or Lose Them!)
- The artwork on the fields should somehow better illustrate where the player pawns can be placed.
- The game was described as a “medium to heavy Euro.”
So I received quite a bit less feedback from play #2. But the fact that I still didn’t receive any feedback about how anything seemed broken meant that perhaps Protospiel goal #1 (validation) was starting to become apparent.
Scoville Play Test #3
Later Saturday night a prominent figure in the board game reviewing business was able to play Scoville. So with three other players I got play test #3 going. In terms of rounds this was the shortest game I have seen. The game lasted 6 rounds. The players again seemed to enjoy the game and nothing seemed broken to them. They did mention the auction as the weak point of the game, so I received good feedback about that that I could implement on Sunday. Here’s the suggestions:
- Possible Trademark issue with the names of peppers used on the recipe tiles.
- Turn order needs adjusting. Option 1: Flop the order. Option 2: Purchase your spot.
- Perhaps just get rid of the reverse order for the harvest action.
- Brown peppers seem too valuable.
I want to point out that the brown peppers are somewhat of an enigma in the game. They don’t breed with anything except the best peppers. They take up space on the map. But they are used quite a bit in the recipes. I had not received feedback that browns were too valuable before this. The normal feedback on the brown peppers is that they seem pointless. So this was interesting feedback from a fresh perspective.
I was also pleased, in a bittersweet way, to hear the same feedback on the auction mechanic. I now knew that I could incorporate a revised auction mechanic on Sunday and expect good things.
I was intrigued by the suggestion to remove the reverse player order for the harvest. My first thought was “absolutely not.” What that would lead to is either huge bids during the auction or rounds of the game where one player can make a huge jump in points. I’ll have to examine this further.
Scoville Play Test #4
Sunday morning I was able to play Scoville for the first time during the weekend. I had not played in the previous play tests. And this time it was just a two player game. I have tried to design the game such that it scales well from 2 to 6 players. There are no AI players necessary and the game feels nearly exactly the same with 6 players as it does with 2.
Since it was now Sunday I was going to implement the new auction mechanic: Bid for Player Order. Now during the auction phase players would be bidding for turn order. Whoever bids the most gets to choose their spot in the turn order. The next highest bidder gets to choose the next spot, and so on. This way, if a player wanted to become the first harvester they could bid high and then choose the last spot, which would allow them to harvest first.
The new auction in the two player game seemed to work, but I suppose that this new auction mechanic would work even better with more players. What the new auction mechanic provided was a way to earn the first harvester spot. That is critical to strategy in the game.
Here are the suggestions I received:
- Are points balanced on the Order tiles?
- Change the artwork on the Cross-Breeding table for the cross-breeds that result in two peppers.
The points on the Order tiles may be slightly unbalanced, but not to the point of brokenness. These can be easily revised, which I may do depending on analysis of the scoring for the first 25 play tests. The artwork suggestion is an excellent one that I will definitely change.
Scoville Play Test #5
The final play of Scoville included the big winner from play #1. He wanted to test the coin building theory and see if it could potentially provide a winning strategy. I welcomed him to try it but made sure that the other players were initially unaware of his proposed gameplay. It was a great final play and I was happy to see that the new auction mechanic really worked well with four players. Here are the suggestions:
- Don’t call it “harvesting, call it “breed-vesting.”
- Check out the game Santiago since there is a similar “fields” mechanic (uh oh… worried about this!)
- The different parts of the game were described by one player as Resources (Auction), Tactics (Orders), and Strategy (Recipes).
The first thing to discuss was the auction. Of note is that this game had the highest average bidding per round of all 5 play tests during the weekend. I think this is due to players now having two things to bid for (first player spot or last player spot) rather than for just moving up in player order. The thing of note was the compliment someone gave to the auction saying that the auction was a good mechanic for the game. This brought the game full circle over the weekend. Previously the auction was described as the weak point of the game. Now it was “good.” I’ll take that!
The other thing that was validated from this final play test was that the game was not broken in that attempting to get coins by planting and harvesting the same color did not result in a winning strategy. The player was going full steam ahead from the get-go with that strategy and came in last place (though could have finished in third place). I was pleased that the game wasn’t close to being won by that strategy. Overall it was a great play test.
Overall Scoville Analysis
Perhaps the best part of the analysis is that people really seemed to enjoy the game. While my goal was to validate whether or not it was any good, I came away from Protospiel very humbled by all the kind words people had for the game. Let’s dig in a little bit and check out the scoring breakdown:
Some further analysis revealed that the number of coins bid during the game varied quite a bit. In terms of coins bid per round the numbers were 2, 6.14, 7.66, 1.38 (2-player), and 7.85 per game. The highest average was the 4-player game with the new auction, though this wasn’t unexpected.
Overall it was apparent that people had fun when playing the game. That’s the most important thing to me as a designer. There are some things that I would like to continue to develop leading up to Gen Con that I mentioned to the players. But I want to avoid the situation where I am needlessly adding complexity. That would steal from the simple elegance of the mechanics currently in the game.
Thank you to all 16 players who play tested my game. I really appreciate the feedback. It was an awesome weekend! And special thanks to Grant Rodiek for humbly accepting a copy for the Prototype Penpal Program. I know that I can expect some awesome, honest feedback!
Designer Diary: Dam It!
Origins of Dam It
Two summers ago I came up with a goofy game design. Last week I wrote about the game being rejected, and what I learned from that. I called the game “Dam It!” The goal of the game is to build a dam across the river before any of the other beavers build their dam. Since the game was recently rejected by a publisher it is now back in my hands. So today I bring you my “designer diary” about the game from concept to its current state.
When I came up with the game I had the idea that it would be really cool to play a card game where you stacked transparent cards so that an image was built up after a few cards were piled on. This fit with a dam theme since you could stack cards to complete a dam (logs, sticks, mud, etc.). The problem with that is that when using transparent cards you can always tell what the other players are holding unless the outlines are the same image. And if the outlines are the same, then there’s no point in stacking them. The only way to make transparent cards work is to have separate decks; one for playing and one for building. So I threw the transparent card idea out right away. But for some reason I still made a game about building dams.
So I came up with the idea to build a dam using Big Logs, Twig Filler, and Mud. Oh, you can also hire helpful beavers to build more efficiently. And you can damage your opponents dams by sending stones or weeds down the river.
Now I had a bunch of cards to make and I had what I thought was a good system for how those cards would be used. Big Logs, Twig Filler, and Mud would be the building materials. Weeds and Stone would be damage cards. And Angry Beavers, Eager Beavers, Mildly Eager Beavers, and Busy Beavers would be the hired help.
The First Play Test
I made a board for up to six players. I printed and cut out about 160 cards. And I got my friends to try it out at a board game day. Here is a hastily made reproduction of what the original board looked like:
On your turn you would draw two cards and then play any or all cards that you wanted to play. When you played sets of cards onto your dam you would remove the appropriate number of cubes from that dam section. When your turn was done you would draw back to five cards.
The first play did not work so well. We were able to play the game, but it was like driving a Yugo down the road with two flat tires. The first problem was that the game took forever. Early on players would have to gather a set of 4 Big Log cards just to get a dam section started. Those Big Log cards each had a percentage on them. When the set of four was played, the percentages were added together and that is how much the flow in that dam section would go down. But players would have to get sets of four for Big Logs, Twig Filler, and Mud. And they would have to do that for each of the 5 dam sections. Changes ensued!
Making it (Marginally) Better
To make the game better and to speed the game up I made the following changes:
- Decrease from 5 dam sections to 4.
- Remove the percentages of the flow decrease on the cards and standardize each set. (i.e., all Big Log sets would be worth a 30% flow decrease).
- Increase the number of cards in a player’s hand from 5 to 7. This would allow for better probability of getting the required building sets.
So with those changes the game played better. But there were still problems. The downtime was too great. The interaction was minimal. And the greatest problem was that the game depended too heavily on getting the right cards. Often there would be one or two players who would just never draw the Big Log cards. And you can’t start building until you get them. So they just sat there at the table unable to do anything fun in the game. That’s boring. So I made more changes.
One of the best ways to illustrate the changes in the game is to show the evolution of the Big Log cards. Note: the log artwork on these cards is from Microsoft (here) and another source that I must not have documented. For future prototypes I plan on using only original artwork or artwork from sites like Game Icons.
In that image you can get an idea of the evolution of the game overall. One of the biggest changes was going from removing blue cubes which represented flow to adding brown cubes which represent the actual dam you are building. Another key change was to allow the Big Log cards to either be used individually or two at a time. Using them individually could help get you started faster. Using two at a time could help you build one section more quickly. But…
People Still Weren’t Having Fun
So during that playtest the night before potentially pitching to a publisher at GenCon one friend of mine pointed out that the game just wasn’t very fun. That’s a HUGE problem. The whole idea of designing board games is to create an environment where the players will be having fun. The comments were the same: minimal interaction, runaway leader, never getting the cards I want. So I made a change that added two new beavers: Sneaky and Grumpy.
The idea of the Grumpy beaver is to increase the interaction between players. Previously the weeds and stone could only be sent downstream. In the late game situations this basically meant you could only attack the player to your left. But if the player to your right is really close to winning, you’d probably rather attack them. So the grumpy beaver, when paired with stone or weeds, allows you to attack any other player, not just downstream.
The idea of the Sneaky beaver is to help prevent a runaway winner. When a sneaky beaver is played one player is attacked. The person playing the Sneaky beaver will remove three cubes from one dam section of the player being attacked. Those cubes are then given to other players and placed on three separate dam sections. This helped with the runaway leader problem.
So I had solved two major problems with the game through one revision. But was it any fun? Just the other night at our board game night the person who had never enjoyed Dam It mentioned that it was never any fun until these two beavers were added. That was music to my ears. So I had converted the hater. And I was now confident enough to send this game off to a publisher.
Yep… the game was rejected. You can read about that in last week’s post: Lessons Learned From Rejection. However, I received some excellent feedback on how to improve the game. The two pieces of feedback I found most helpful were:
- Use the cubes for more than just visual notation of the current state of your dam. For example, be able to spend cubes for a special action.
- Mitigate the luck of the draw aspect by having several cards face up to draw from, a la Ticket to Ride.
Both of these will increase the options for your turn, and give a player more to think about. Good stuff!
One of the things that I thought was really important was the art of the prototype. I should mention that this was before I followed a ton of great people on Twitter, who know what they’re talking about. I thought that the art had to be really good. I didn’t want thin paper cards with minimal art and sketches and notes. I wanted a product that looked complete. I thought this was important for the publisher. Why did I think that? Well, it seems like an obvious thing because it’s the idea of making a good “first impression.”
This was a problem for me as a designer because I spent way too much time working on the art (in The Gimp) when I could have been play testing or designing other games. While I enjoyed working on the art, it just wasn’t important. What if the publisher chose to publish the game, but also chose to re-theme it? Then all that time would have been potentially wasted unless.
Another thing that I would have done differently is to send the game off for blind play-testing. One great program for this is Grant Rodiek’s Prototype Penpal Program. I think blind play-testing is critical so that you can test not only the game, but also the clarity of the rules, from people who are not biased towards you. I plan on utilizing the Prototype Penpal Program after attending Protospiel-Milwaukee in March.
In hindsight there are plenty of things to change about the process I went through with Dam It. I’ve learned tons but only because I made the mistakes that I made. Sometimes it’s better to learn by doing, even if the doing is filled with mistakes.
What’s in Store for Dam It?
I will not currently pursue this game any longer. It is an appropriate time to shelve the project. I am currently heavily testing and revising my game, Scoville, so that it will be ready for demonstration and play-testing at Protospiel-Milwaukee in early March. Since Scoville has more potential than Dam It it means the beavers will have to take a back seat. I also have other game designs that I feel are more intriguing than Dam It that are not quite at the prototype phase yet.
If I were to pursue major revisions for Dam It I would start with play-testing the face up draw cards. That seems an obvious improvement to the game. I would also brainstorm the potential other uses for the cubes. I have added the face up draw to the rules, which should hopefully be up on BGG in the near future. If you want a copy of the rules, just let me know on Twitter.
Dam It has been a fun first game to work through the whole process of invent – prototype – play test – submit. I learned a ton and had a lot of fun. I think Scoville has definitely benefited from my experiences with Dam It! Want to find out? Come try it at Protospiel-Milwaukee!