Category Archives: Dam It
Ah… my first game rejection by a publisher! Not unexpected, however. This page has all articles that include information about my card game named 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!
I’ve been designing games for about three years now. While that may seem a long time to some, it in no way qualifies me to pretend that I know what I’m doing. For the most part I come up with an idea and try to make the game fun. All the other stuff, like approaching publishing companies, determining if you need a patent (you don’t!), and even prototyping, I have learned secondhand by people who have gone through it. If you are a game designer I highly recommend you start following game people on Twitter and listening to what they have to say about everything!
Last August I attended GenCon for the first time. I brought a copy of my game, “Dam It!”, along in hopes of showing it to a publisher. Dam It is a light card game where players compete to complete their dam before anyone else. I’ll write more about the game in a later post. I had the chance to meet some great people at GenCon and I arranged a meeting with a certain publisher. I was fortunate to have three friends on the trip who graciously played Dam It one more time before I would have the meeting. Here’s my first lesson learned:
1. If your friends don’t love it, don’t bother.
That night when my friends played my game again they pointed out a few things that they thought would make it better. The interaction was too limited. Late-game options became fewer. And it had a sort of runaway leader problem. So I brainstormed that night and came up with a way to make the game better. But that meant that I could not approach the publisher since I would not have felt right pitching a game that I knew was incomplete. Here’s the lesson: If your friends aren’t enjoying it, and if they are recommending major changes, don’t waste a publisher’s time!
So I met with the publisher the next day and told him that the game wasn’t ready for discussion. But I got their business card and made plans to contact them when I had implemented the changes.
And that’s just what I did. I added two new cards to the game that both focused on interaction and eliminating a runaway leader. The cards worked as I had hoped. When I play-tested with my friends again they all seemed to agree that the game had improved. So I ordered a copy from The Game Crafter and got it ready to send out. I contacted the publisher to see if they would accept a submission and after an affirmative response I sent my little baby out into the world. But here’s the next lesson:
2. Don’t make emotional deadlines.
I must have been hopped up on the GenCon buzz because I had set a goal to send out a copy of my game before the end of October. Why is that bad? Because by setting that goal it had less to do with game development and more to do with my desires of getting published. This goal was an emotional goal. While I met the goal, I didn’t feel like I was sending out the best possible product, even though it was much better than it had been at GenCon. Here’s the lesson: Don’t make emotional goals that aren’t based on game development.
So it was a little bittersweet when I sent the game off. While on one hand I was happy that I felt like I was becoming a real game designer I was also a little disappointed because I knew that the threat of rejection was real.
It’s an interesting period of life when you’ve submitted a project to a company that could potentially publish it. There were days when I woke up and wondered if they were going to play it. I had received an email in early November stating that the company received the game and would be play-testing over Thanksgiving. So of course all day on Thanksgiving I was thinking my game was being played. It actually made for a long day. And then the waiting began, which leads to my next lesson learned:
3. Must… Be… Patient…
Once you submit a game to a publisher you are committing yourself to a life of patience. Think of it this way…
- Publishers receive a lot of games.
- Publishers have to play all those games (hopefully more than once).
- Publishers also actually produce real games, which might require a bit of their time.
So don’t think that once they get your game they’ll open it up, read the rules, and play it right away. If I were a publisher receiving submissions I would likely have a submission queue. So when you submit a game it would go to the end of the queue. You can also look at it this way: how often do you play games? and how often are those games someone’s unpublished prototype? I imagine publishers are in the business because they like to play games. I also imagine that playing only unpublished prototypes could get very old. That means some of their time is also spent playing good, published games. Here’s the lesson: When you submit a game, just forget about it for a while. Contact the publisher on a quarterly basis. And if you haven’t heard after a year, cordially request your game back.
And when you do hear back, try and listen to what the publisher is actually saying. That leads me to lesson #4:
4. All Feedback is Good Feedback
Publishers know what they’re talking about. Odds are if you are an unpublished designer, you probably do not know what you’re talking about. So listen to what they have to say. Of course, if what they are saying is, “We love your game and want to publish it,” then congratulations to you! But if they have rejected your game, make sure you understand why. Some reasons could include:
- Your game may not fit their company flavor (Like sending a zombie game to Haba, for example… bad idea)
- Your game may not fit their budget currently, but they may want to retain the rights to the game for a while.
- Your game may not be developed far enough. They may like the idea, but it needs work that they are not willing to put into it.
- Your game may be broken.
Those are obviously just a few of the reasons why a publisher may reject your game. Here’s the lesson: Don’t get frustrated by a rejection, learn from it! Also – They are not rejecting YOU. They are rejecting your game. Don’t take it personally.
What I learned from my rejection is that the game isn’t broken. It is too random. The feedback I received suggested that I not abandon the project, but rather to continue working on it and fixing its failings. So while my game was rejected, I actually learned a lot during the process. I now have a more well defined path forward with Dam It! And I’m better prepared for the next rejection. So to the publisher who rejected the game, Thank You!