We had another Boston Game Jam this past weekend, this time focusing on board and card games. A bit of a departure than our usual video game creation, and it really had a different flavor because the weekend was all about game design. Jeff Ward wrote a quick write-up that highlighted these points, so I'll point you there instead of stealing/paraphrasing him.
I worked with Gabe Warshauer-Baker, Kevin Jackson-Mead and Nick Troy on a project that Gabe had pitched. The concept was "Other People's Tools", with the inspiration coming from a mechanic from the game Caylus - the idea being that you gain some residual benefit from letting other players use "tools" that you own.
Here's a sample of cards that represent our first stab at creating the game. For resources, we played with a set of Looney Labs' "Icehouse" pyramids because, well, we happened to have a set.
The white cards are the tools, and the yellow cards are the objectives a player has to meet in order to win. Each player was dealt a hand of 3 tool cards and given 1 objective card. The players presented their tools to the group all at once, and play went around to each player, where they selected which tool they wanted to use. When the round ended, if a player happened to fulfill their objectives, they won and the game was over.
We started with the tool cards on the left, which came to be known as the "gather" tools. They consisted of taking the appropriate number of "triangles" from the resource pool at no cost, and the tool's owner received a triangle for their trouble as indicated on the bottom of the card. We found quickly that there wasn't a lot of strategy in which tool you offered the others - you picked the tool that gave you a benefit that matched your objective, and hoped that the others would provide a tool to help you along, as well. Often you had a choice of three tools that didn't really help you in any way, so the choice was kind of "meh". Players were focused more on meeting their objectives instead of providing helpful tools (which we meant to be our core mechanic).
We played around with other changes - making the objectives private knowledge, more diverse objectives, even adding an "Apples to Apples"-style system of presenting the tools anonymously. By the time we got to adding the "conversion" tools - which we knew we needed - the prototype was dying. (Notice that there aren't any benefits listed on the conversion tool cards in the middle column above.) The biggest problem was that of divergent goals. It boiled down to "I want to help you win (by giving you a tool you want to use), but I don't want to help you win (because I'll lose)." So, back to the drawing board.
The Game Takes Shape
Our goal for the second prototype was focusing on the basic premise - to provide the most useful tool to the other players (and be rewarded for it). So, the tools became the resources, with their value determined by the core "elements" they provided and by what the other players bid on it to claim it, poker-style. Players cannot bid on their own tools (it is forbidden among gnomes), but this was balanced because they were holding the auction and gaining income. At about this time we were also trying to add a bit of flavor with a story, which we settled on a group of gnomes in a silly, steampunk setting. So each tool provides one or two of four elements: whack, hole, cut and fuse. A basic hammer provides 1 whack, where a hammer-saw could provide 1 whack and 1 cut. And so on, up to the Semi-Automatic Blade Pipes and such.
The singular objectives were gone, and now the players were using these tools to build "projects". The projects were priced such that a player would need to use at least two tools to claim it, and they provided additional income. The economy was changed to a single currency (coins, since we were using pennies). Whoever had the most coins at the end of the game won.
At first, we determined the end of the game simply by exhausting the project card pile. But, then we added a lot more projects, which would have dragged the game on. We tried stopping the game when a player built their fourth project, but an interesting wrinkle came up during playtesting. One player had 3 projects and was poised to built a fourth, but he didn't have enough money to win the game. So he declined, postponing the game further until someone else could gather the tools to end the game. Game time was already averaging an hour, so to curb this unnecessary prolonging of the game, a "Game Over" card was added randomly toward the bottom of the project deck (Tourist Season, when the humans flock in to buy up the gnomes' projects).
And so, we are left with our game, Gnome Economics. We plan to complete the cards by adding all of the names and flavor text, and get them set up in a file with graphics that can be printed.
Overall, I think the project was fairly successful. I'm not much on bidding games, but the series of checks and balances inherent in our auction system (created almost by accident) keeps the game from favoring any one particular strategy.
If there's anything that "went wrong" during the game's development, it's that the game is too long for us to get a lot of iterative game testing done. The mechanics of the game are simple, so a lot of our adjustments were minor value tweaking. And an hour-long game isn't too shabby, considering that about how long most modern board games are expected to last. But we found that playtesting among ourselves was slow, because we were discussing the game as we played it, and playtesting with others was slow because they were analyzing the game, trying to figure out the optimum strategy and calculating expense versus returns (which is to be expected - this was a room full of gamers, after all!)
Keep an eye here, I'll make an update when we get the files finished so you can try the game out for yourself!