Give Up on Your Games

One useful piece of advice I’ve learned as a designer is “give up on your games”. No, I’m not overcome by a wave of ennui for game design. But it’s time for spring cleaning, which means getting rid of some game ideas that are holding me back. Letting go of a design is a hard thing for a designer to do, but holding on to a design long after it is viable can waste your time, energy, and passion. After some recent playtests and design sessions, there are a few games that I’m no longer going to work on. I hope that by sharing my reasons behind these decisions, other designers will find reasons to leave their old ideas behind and make way for some new ones.

The first game I crossed off my list was Cash Out. This started as a loose concept at GenCon last year, and morphed into a casino-themed bidding and bluffing game, reminiscent of both No Thanks and For Sale. It was slightly harder to learn than those games, and had slightly more going on. But family, regular gamers, and designers all responded well to it. Then I had a bad test, and while some of that was due to some rule misunderstandings, I realized the game didn’t know what it was doing. It didn’t have a clear audience. Casual gamers don’t want or need something at that complexity level, but the complexity wasn’t high enough to make it interesting on its own to regular strategy gamers. The theme and mechanics didn’t do anything original enough. So I had a game for a gap that nobody wants to fill. I started with a mechanism and tried to build a game around it. Like piling dry sand to make a castle, there was nothing to give it structure, no matter how long I pile the same sand up.

Lesson learned: Know what your game is trying to do. If your design is like some other game, make sure you know what parts of it specifically your game is building on. Otherwise, you don’t need to make it.

The second game was Ten Acres. It was a light farming game that focused on growth every turn. After Unpub 4, I put it away, because it had the problem of being too fiddly to upkeep, with a large number of wooden cubes needed. I eventually reworked the system to make upkeep easier, but that change really took away a lot of the core experience of things growing every round. In order to keep that core, I need lots of bits. In what is, ideally, a 20 minute game, the number of tokens, cards, etc. needed is out of proportion to the intended complexity of the game. I’m always really tempted to return to this game because the constant growth and theme are so compelling to me, but it is either too little of a game for the right number of components, or too clunky to play if it does everything I want it to.

Lesson learned: Figure out if the effort required to play the game matches the experience you want from the game. It’s easy to ignore the physical and mental acrobatics you need while you’re in the middle of chasing an experience, but they can easily overwhelm the game when it stands alone.

The third game was Iceburgh, an 18-card game I’ve been developing for about a year. It started as game about shape-shifting monsters fighting for dark and light, and gradually shifted to a game about an town built on ice floes. I finally admitted that the game was a mess, collecting bits of theme and mechanisms like a snowball rolling down a hill. Parts of the game work together (the theme of ice floes works great with the central mechanism of cards sliding around). There are interesting mechanics in upgrading buildings. But swapping roles by flipping cards (a holdover from the older version) and resources (are they building with the snow and ice, or what?) don’t fit in at all. To solve a problem with an end-of-game stalemate, I had to take away the key mechanism of getting tension. The game plays, but lacks one of my core game design goals of providing a coherent experience. There are still a lot of great usable parts of the game, but as a whole it just doesn’t work.

Lesson learned: Design games you would play, not parts of a game you would play. Once you realize you have a collection of parts instead of a game, you can start to use them for something else.

Giving up on these old games isn’t really giving up. It’s learning to identify when working on a design is no longer productive, accepting that, and doing something about it. By putting these away, I’m free to move on to other things. Interestingly, all three of these games were holdovers from before my recent re-evaluation of myself as a designer, so there’s also a symbolism to moving on from these older designs, that reflects my moving on as a designer. So I happily look at these games and say, “I give up,” and I think I am the better for it.

I think maturing as a game designer is when you can recognize that one of your own prototypes is no longer worth pursuing.
Byron Collins via Cardboard Edison

 

10 comments

  1. I wholeheartedly agree that being productive as a designer involves knowing when to move on to a different idea. My very first (never published) game was under development for a long time. I ended up with many playable but ultimately mediocre games. Moving on and doing something else was liberating, and I produced better stuff afterwards. But it was still a valuable process and I have many bits and pieces from that game floating around in the back of my head for other projects.

    • Anywhere from about 5 to 10 that I’m actively working on designing, developing, or testing. Recently, a lot of them have been very small, so it has been toward the high end of the range, but it’s at the lower end right now because I just got a few games where I want them. I’ve been trying to manage that better, using the spreadsheet here. I have a lot more designs that are just sitting around that I’m not doing anything with. And of the 3 games here, I was only actively testing Iceburgh; the other two were inactive.

      • Thanks for the information and I’m going to check out your other post + spreadsheet.

        How many games do you finish in say a year?

      • It’s hard to say. I haven’t been doing this long enough, and “finished” is sort of hard to define. (I “finished” New Bedford in 2014. But then it took another year before I was done with expansion stuff, and the final edits to the print files were just completed recently.) But if I base it on when testing finishes, 2015 was 2. This year looks like it will be three or four if I’m really lucky. (Not counting a few microgame promo side-projects). My next goal is to reach at least 5 a year.

      • 5, wow! But I guess that with more experience things can move faster. Hope to get there myself! πŸ™‚

  2. This is a really clever mindset to have I think. This kind of gave me some insight, opened my eyes a bit.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.