Abandoned Prototypes

"Success consists of going from failure to failure without loss of enthusiasm." - Winston Churchill

Posted on 3/4/2017 by Tim Rice

People always say that you have to fail in order to succeed, but I never truly understood or believed that concept until I started designing games.

About 4 years ago, a friend of mine showed me King of Tokyo, and that triggered a board game obsession in me that persists to this day. It quickly became my main hobby, and it didn’t take long for me to have the thought that so many other gamers have: "I can design games too! How hard could it be?"

Well…..it certainly isn’t as easy as I thought it would be. I’ve been working on ideas in my spare time for about 4 years now, and so far I’ve managed to develop only one game that I feel is fun enough to submit to publishers (that game is Chicken Scratch, in case you’re interested).

As a result, I have a bunch of old prototypes lying around from designs that didn’t work out for one reason or another. Even though I’m not pursuing these designs anymore, I’m still happy I made them because they were great learning experiences and they made me a better designer.

I thought it might be fun and useful to share some of these designs, reflect, and discuss what I learned from each of them. Hopefully any fellow designers reading this can learn from my mistakes, as I did. Or perhaps they’ll spark an idea or two.

Miner Dice

Summary

This is an engine-building dice game with a few economic mechanisms thrown in. The goal is to build the most profitable gem mining operation, and throughout the game players upgrade their tools (dice) to do so.

The gem tiles are laid out in a grid face-down in the middle of the table so that the level 1 tiles are easily accessible, but players have to do some digging before they can mine the higher level tiles. Each player starts with a few basic dice which they roll each turn, and the results determine which actions a player can take.

Pickaxes allow you to mine (pick up gem tiles and add them to your hand). You need 1 pickaxe for a level 1 tile, 2 for level 2, and 3 for level 3.
Shovels allow you to look at a gem tile (any level) and place it back anywhere on the board. This could be used to search for specific tiles and/or block other players' desired gem tiles.
Fire allows you to smelt (put a gem tile in your hand onto the table in front of you) so that it can later be sold.
Each player also gets a free sell action each turn where they can discard a tile in front of them and take a number of coins determined by the constantly changing gem price chart. Each time a player sells a gem, the price of that type of gem goes down by one.
The Refine action allows you to sell an additional gem tile at the price of the current most valuable gem.

Every turn, in addition to their action dice, players roll gem dice which increase the selling price of the corresponding gem types. This means that each gem type’s price fluctuates throughout the game, and players can adapt their strategies based on current gem prices or how they expect the market to change.

Also, different gems are common at different levels. Typically players will hold a lot of rubies near the beginning of the game and a lot of diamonds near the end, so the reward for selling a gem is often tied to how rare it currently is.

With the money earned from selling gems, players can buy additional upgraded dice which allow for better (and more consistent) actions each turn. Whoever has earned the most money after all the gem tiles have been depleted is the winner.

Issues

This game actually isn’t bad, there is at least some fun to be had here. I really enjoy the rolling-for-actions mechanic, engine-building, the custom dice, and the swings in the gem market. As a whole, though, a lot of things didn’t work as I had hoped they would.

The main problem with the game is the weak player interaction. There were two major dynamics that I was attempting to create, and both of them didn’t show up in practice:

I wanted players to compete for gem tiles, but there wasn’t enough incentive to do anything other than mine random tiles and sell them as fast as possible. The Shovel action was clearly a lot weaker than the rest, and that one flaw pretty much turned what I thought would be a tense race for resources into taking turns picking up tiles.
I also wanted players to struggle to decide which gem tiles to sell and when (will this gem tile be more valuable later?). This didn’t work, and I think it’s because new gem tiles were so readily available and pushing the tempo was a lot more important than getting the best value.

While I think that some of these issues could be alleviated with enough tweaking, I’d rather spend my time on other projects. I might return to it at some point, but more likely I’ll use some of these ideas in another game.

What I Learned

Trying to balance a game before playing it is a bad idea. It will almost always change anyway, and you never know if a game is fun until you play it. I often struggle with this because I easily get wrapped up in all the patterns and mathematics that go into designing game components that I forget to make sure the game is engaging first. It’s always best to play an idea as soon as possible and refine it incrementally. In this case, I put a lot of time and effort into making sure the dice were balanced before realizing that one of the actions wasn’t working.....not very efficient.
Printing stickers on sticker paper is a great way to prototype custom dice. It is a bit time-consuming, but prototyping often is anyway.
Having a few good mechanisms isn’t enough, a game also has to flow well. I found that player turns took a lot longer than I expected; even though all the actions were very simple, when players had to resolve all of them at once it created problems. There really is no substitute for playtesting when it comes to this aspect.

UPDATE (9/2/2017): I ended up revisiting this design and improving it, so I guess it can no longer be considered abandoned! Check it out if you're interested: I changed its name to Dig Deep.

Jesters

Summary

This is the first design that I ever prototyped. Looks great right?! Who needs color printing when you have colored pencils. Anyway, it’s a simple card game where players are trying to entertain the king and gain the most favor points.

Each round, a royal decree card is drawn which indicates which color the king would like to see this round as well as a group performance color. Players will then simultaneously play one of their triangles (they each get one of each color) to “claim” that they will play that color this round.

Once all the claims have been made, players simultaneously play a card from their hands. The players with the highest value card in each color wins favor points (but the player with the highest card in the color the king requested gets more favor points). Alternatively, if a majority of players play the group performance color, the favor points are split between those who participated in the group performance and nobody else. If a player claimed a different color than they played, they have to leave their triangle out there until they tell the truth (and in the meantime they can’t claim that color).

Play continues like this until the deck has been exhausted, and I also experimented with a few special cards to mix things up. Whoever has the most favor points at the end of the game wins!

Issues

There simply weren’t very many interesting decisions to make throughout the game. Most of the time there wasn’t enough information to predict what other people were going to play, so luck played a much bigger role than I would have liked.
The claiming mechanism with the triangles was almost completely useless. I had hoped that there would be the opportunity for some mind games where players claim one color to influence everyone else’s decisions only to play a different color unexpectedly. There weren’t very many good reasons to do this, unfortunately, and it ended up being confusing and clunky.

What I Learned

Inspiration and implementation are two completely different things. Just because an idea sounds fun, it doesn’t mean it will be. Not even close. I based this entire game off of the “claim a color” bluffing mechanic, and in practice it just didn’t work.
Even simple games often need a lot of iterations before they can be considered fully developed.
Pro tip: never use cardstock triangles as components. They’re pointy and they hurt.
Another: purple-colored yellow cardstock works just as well as purple cardstock.

Baseball Tournament

Summary

This is a drafting/auction/betting dice game where players recruit a baseball team and then compete in a twelve-game season (I know that’s way too short for baseball). My vision for this game included custom dice, but I never made them so I used a chart instead (this works fine if the dice are simple enough).

The first phase of the game features an auction where player cards are auctioned off one at a time. Players want to make sure they have at least one player to fill every position, but some cards are more valuable than others so conserving money is important.

Once every player has their team, they add up the combined skill, fitness, and discipline of their team members to determine the team’s overall strength.

Having high skill means a team has more total dice.
Having high fitness means a team has more rerolls.
Having high discipline means a team has the ability to select the result of more of their dice.

Each round, teams face off according to the schedule board. Each game is a simple dice battle, and the team that wins increases their roundly income. Throughout the game, players also have the opportunity to bet on others’ games and pick up free agents to improve their team from the deck of unclaimed player cards. Whoever has the best record at the end of the season wins!

Issues

Scaling. This game was designed for six players...and while the rules that were included for non-player teams work fine, that’s never as fun. Having exactly five other people to play games with is pretty rare.
Oftentimes there is no way for teams that fall behind early in the game to catch up, because they don’t have enough income. Even though this may be an accurate representation of the theme, it’s not very fun to lose early in the game because of some unlucky dice rolls.

What I Learned

I tend to avoid incorporating non-player “bots” in games after trying this one out. It’s finicky, and it’s never going to provide the same experience as playing against another person. There are exceptions to this rule of course.
Don’t design a game that only works with six players…..
Catch-up mechanics are tricky. Rewarding players that fall behind often punishes good play, which is what the designer should encourage. On the other hand, it definitely isn't fun to fall behind early in the game and know you have no chance of catching up. One way to address this problem is hidden information/scoring. If a player doesn’t know they’re behind, they’re more likely to enjoy the experience the whole way through.

Conclusion

Of course it can be frustrating when designs don’t work out the way you expect them to. Instead of getting discouraged when this happens, I say we should celebrate our failures and learn from them. Every failure makes the next game better.

If you're a designer, I'd love to hear about any prototypes that you've abandoned and why, and also what you learned from them. Everyone has their own style, after all.

Thanks for reading!

Connect on BoardGameGeek, Twitter, Facebook, or subscribe to my RSS feed for updates.
I'm also looking for people to help me playtest my newest design: Chicken Scratch. If you're interested, let me know!