Designing Meeples with Kane Klenko on designing real-time and co-op games.
In this edition of Designing Meeples we talk with designer Kane Klenko, who has had a few of his games published by the likes of Rio Grande, Mayfair and Minion Games. His new real-time co-op FUSE will be published Late Summer 2015 by Renegade Games.
Kane let’s start with question to learn more about you and why you design. Why did you start designing games and why did you keep designing games?
Kane: I’ve always been creative. When I started getting into music, I started teaching myself instruments. When I started getting into games, I think it was just a natural progression for me to try to design one of my own. Early on in my gaming career (we really should be able to make a career out of playing games!) I remember playing a new game and a friend of mine said, “These are great! What kind of person thinks up these things?,” and I remember thinking “People like me. I think I could do this.” As a game player I’m not one to over-analyze things and get into big strategy discussions. I play for fun and from the gut. That said, I’ve always been interested in what makes a game tick. Why did the designer do this or that? Why were different parts of the game included and what did they add to the design? At some point (2010 to be exact), I just decided to give designing a shot.
Why do I still design games? I don’t think I have a choice anymore. I’ve trained my brain to work through game designs, and I have new ideas every day. I don’t think I could stop if I wanted to. Besides, it’s a great feeling to both have these new ideas, and to see the fruits of my labor when I see people having fun with one of my games. Knowing that I created something that is making people have that much fun is great.
I’d like to think that I would keep on designing even if it wasn’t working out for me, but I’d say that early success has also kept me going. My first design (Pressure Cooker) was picked up by a major publisher (Rio Grande), and every game that I’ve thought was good enough to show a publisher has either been signed or is currently being looked at by a publisher. It’s nice to know that my excitement when I have these ideas is not in vain, and other people see the potential in the games too.
How do you usually start with designing your games – say a theme or idea hits you – where do you go from there?
Kane: I try to picture people playing the game, and how I want them to feel playing the game. Do I want it to be a fast-paced game where people feel the tension of impending doom, or a light-hearted family game, or a deeper strategy game where players can pull off clever combos and plan ahead for what they want to do in the game? Do I want it to be competitive or cooperative? I just try to get a feel for the game and the experience that I want the players to have in the game. That can be decided based on the theme or a specific idea for a mechanic. Every game is different, but I usually try to set the overall tone from the very beginning and then have every other decision follow that path. Specific mechanics and parts of the game will always change through the design process, but I think having the overall tone and feel of the game set from the beginning helps me to stay focused, and know which parts are helping the game and which parts need trimming.
You seem to have two types of games that get published, real-time or co-ops (and in the case of the upcoming FUSE both mechanics) – what draws you to design those types of games?
Kane: Yes, that has definitely been the case. I didn’t set out to be an expert in real-time games or anything like that (not that I AM an expert…). I think it was just that I really enjoyed the real-time games I was designing, I was having success with them, and I kept having new ideas that fit well into that space. They have become more popular recently, but when I started working on real-time games there were only a couple on the market, so I thought it would be a fun niche to try and fill.
My first game idea that I really worked on was Pressure Cooker. I was sitting in a Dennys and there was a big group at a nearby table, and I was thinking that it would be tough to be a cook trying to prepare all of these meals at the same time, and have them come out to the table at the same time. DING! Instant game idea. And real-time just fit the theme. After that it was just a case of having so much fun with the real-time aspect of the game that I kept thinking about other ways to approach it.
As far as co-ops, I think that’s just because I personally enjoy cooperative games and they are a hit in my group. The second game I worked on was a fire-fighting game, and it was just a natural fit to make it cooperative. Of course, as soon as I started pitching it to publishers Flash Point was announced so nobody wanted to look at it. I ended up completely re-working that game and making it even better as Dead Men Tell No Tales. But that’s where the cooperative nature of that game came from.
So, to give a short answer (too late for that!), I think I focus on real-time and co-op games because that style of play fits the themes I’ve been interested in designing around, and I just enjoy playing those types of games.
Let’s talk real-time designs first. What do you think the key is to making a good real-time game?
Kane: The short answer is Fun. For me, the whole purpose of a real-time game is to make the experience fun for gamers and non-gamers alike. I have family members who love party games, but hate any kind of strategy games. Any time I would suggest a game, the immediate response was “Is it fun?” I found that they loved real-time games though. Even if a game was a bit more complicated than any other game they would play, if it had that real-time tension, it was an instant hit. So, that’s how I’ve approached my real-time designs: make them fun for my gamer groups, and make them equally fun for my non-gamer extended family. If I can please both groups, then I feel like I’m on the right path. From the very beginning of every design, I try to think of the target market and make sure all of my design choices fit into that target.
Early on in my design career, when I was first coming up with ideas for games, I remember thinking about video games. I was trying to think about why video games are so much more popular than board games. There are lots of answers to that question, but one thing I came up with that apparently really stuck with me was the real-time nature of most video games. In general, you’re not sitting waiting for your turn. All players are always engaged in the game, and a lot of times there is a time pressure or some other tension that you are battling. I decided to focus on that tension and try to bring it into my designs.
What was the question again? Oh yah, the key to making a good real-time game. Like any good game, there are probably a lot of answers to that question, but I’ll say balance. I don’t mean balance in the tradition sense of making sure all of the special abilities and other parts of the game are equal. I mean the balance between the amount of ‘stuff’ you’re asking the players to do, and the amount of time you’re giving them to do it.
Let’s take my game Mad City for example. In Mad City, players have one minute to build a city. In that minute they need to determine how big they want their residential, industrial, and commercial zones based on their current scoring state, they need to build the longest road without breaking up those zones, they need to build ponds and parks if they want to go for the bonus, and they need to look around at what everyone else is building to determine if they can get extra majority bonuses. That’s a lot of stuff to pay attention to in one minute, but it’s not TOO much stuff. If rounds were 30 seconds long it would be frustratingly difficult to get anything done. In contrast, if rounds were 2 minutes long, the game would be a simple puzzle and would drag on and become boring pretty quick. And a minute would be way too long if all they had to do was build a road and maybe fit their parks together. The key is finding the balance between the amount of time the players have to do something and what you’re asking them to do. You don’t want frustration, and you don’t want boredom. You want that perfect tension that makes people say “Oh, I was so close! I’ll get it this next round!” Or, in the case of FUSE, “We were so close! Let’s play again!”
Another thing is that I don’t always want the fastest player to win. Being fast shouldn’t necessarily be the key to everything in the game. Yes, it is a part of real-time games, but you want to give everyone a fairly equal chance at the game even if their brains don’t work in the same way. In Mad City, you can build your city any way you want (as long as it’s 3×3) and you’ll score some points. While players who are better spatially will probably do better, all players will feel engaged and a sense of accomplishment as they unlock their scoring tiles and score points. It’s a real-time game, and being fast is definitely a part of the game, but overall speed is not the focus of the game. Players who take their time can do equally well at the game. Again, it’s that balance of how much time the players are given and how much they have to do. You have to balance all of that with different play styles too.
Let’s talk about that balance. I imagine a lot of that fine tuning is done through playtesting. So when playtesting a real-time game, what do you look for (as the designer,) when the game is in play
Kane: As far as real-time games goes, I think I mainly look for that balance. I do a lot of testing in my head before ever making prototypes, so I think that helps me. It’s rare that I’ll get a game to the point of making a prototype and it won’t work and be fun. Once I have other people involved through playtesting it’s a matter of making sure that balance is right and all of my numbers work. Is there enough tension in the game? Is there too much tension? If it’s a cooperative game is it too easy? Too hard? Too frustrating? Is there enough in the game that forces the players to communicate? Do I have enough layers, and is the time pressure tight enough that one player can’t take over and dominate the game? Like I said, I usually have most of that worked out before I start making a prototype, but there’s a lot of testing to make sure I was right.
For instance, with FUSE, the basic structure of the game has not changed at all. The final game uses the same cards that the very first prototype had. The first time we played it though, I thought the game would be five minutes long. We hit that five minutes and I immediately said, “It needs to be 10 minutes, keep playing.” 10 minutes ended up being perfect. The game length felt right. From there I needed to make sure everything else fit with that ten minutes; namely, the number of cards that were used each game, and how the FUSE Cards and unused dice would work.
Sometimes it’s a bit more complicated and takes more time. Like in my game-that-cannot-yet-be-talked-about, I had the idea for the basic mechanic and I knew it would be a hit. Well, I thought it would anyway. I made a quick prototype with just a few parts in order to test that one mechanic. It worked great. I had a cool mechanic and a theme, but it wasn’t a game yet. I needed to add to it, and that took a lot more time. I ended up adding pieces to the game bit by bit. Adding things here, tweaking things there, and removing parts that didn’t quite flow right, until I felt I had the right balance. I didn’t want to add too many pieces that the real-time aspect became overwhelming, but I knew I needed more than that basic mechanic to hold people’s attention and keep them engaged in the game. I had to find that right balance.
Other than that, it’s just like any other game. Make sure it’s fun.
What are some good questions to ask your playtesters, when playtesting a real-time game?
Kane: My regular playtesters are always honest with me and have no problem telling me when they don’t like something. My wife is by far the best playtester I’ve ever played with, and she can pick things apart pretty quickly and see where things can be cut and improved. So, I usually don’t have to ask too many questions. They will freely give me their opinions.
Early on I always play the games with the group, but once I’m pretty satisfied with things and start moving out to a wider circle of testers, I like to sit back and watch them play. I don’t know that I necessarily have specific questions that I ask; I just watch to see where the tension in the game is (good tension and bad tension), which rules confused people, if the communication stayed strong in a cooperative game, and those types of things.
More than asking specific questions, I try to know specifically what I want a game to be and then watch people play the game and see where my goals and the current state of the game match up, and where it needs work. Of course I always get people’s opinions, but I know that not every game will be a hit with every player. And that’s probably even more true with real-time games.
I would like to switch gears here and talk about the other type of game you like to design, co-ops. What is the key to making a solid co-op game in your mind?
Kane: I wouldn’t say there’s one specific thing, but since we’re talking about balance, I’ll say it’s getting the balance right. With a real-time game, it’s the balance between the amount of things players need to do and the amount of time they have to do it. In a co-op game, it’s the balance in the difficulty of the game. If the game is too easy, then players get bored and the game doesn’t offer replayability. If the game is too hard, then players will become frustrated and again, they won’t want to re-play the game. The trick is in finding that right balance, and in my experience, that is what a big part of the playtesting comes down to. If you can find that perfect balance where games usually come down to the end and, win or lose, it’s by the skin of their teeth, then players will want to play again.
Another thing I try to do with co-op games is distract the players. What I mean is that I give the players a clear goal of what they need to do to win the game and then throw a bunch of other things at them. Technically they could ignore those things in order to focus on the goal, but if they do that too long they are going to be making things more difficult for themselves, and possibly spiraling the game out of their control. Not every game needs this, and I didn’t use it in FUSE since that is a more streamlined and straightforward game of win or lose, but I like to do this especially in bigger co-op games.
I used this a lot in my game-of-which-we-cannot-yet-speak, but I also like the way it plays out in Dead Men Tell No Tales. Your goal is simple: find the treasure and get it off the ship. You can try to ignore the fire, the crew members, and the Skeleton Crew and just run around grabbing treasure, but the longer you ignore those things the harder the game will be and the more out of control things will get. They aren’t the goal of the game, but you have to pay attention to them if you want to accomplish your goal. It’s about the balance of following the path to your goal and at the same time dealing with everything that the game is throwing at you, even if those things don’t win you the game.
How is designing co-op games different than designing competitive games?
Kane: In a competitive game, you need to create a system that the players will try to manipulate to their advantage in the most efficient way possible. All of the players are working under the same system of constraints, and they need to figure out the best way to work through that in order to come out ahead of their opponents. In a co-operative game, you need to design a system for the players to interact in, and give them exciting things to do, but you also need to design a system that will actively fight back against them.
For example, in Dead Men Tell No Tales, I wanted a system working against the players that was multi-leveled. I didn’t want them to just have to worry about one thing. The goal of the game is to search the ship, find the treasures, and get them off. That’s all well and good, but without having threats actively pursuing the players, the game would become dull. Players need to collectively worry about the fire on the ship (both because it impedes their movement, and because the entire ship will explode if it gets out of hand), they need to worry about the Crew Members that are spreading all over the ship, they need to worry about the Skeleton Crew that is chasing them down and trying to fight, they need to worry about the way they place the tiles when exploring the ship, and they also need to worry about their own Fatigue level. If they let their Fatigue get out of hand, then they will not be as big of a help to their team. Having multiple levels of things that the players have to worry about keeps the game interesting. One game the fire will be out of control, and you’re constantly worried about explosions. The next game maybe the fire is able to be contained, but the Crew Members are spreading like crazy. Every game is different, but the challenge is always there.
In contrast, FUSE is a much simpler design. The main thing players are fighting in FUSE is time. But just because the idea is more streamlined and simple, that doesn’t mean the importance of playtesting to get that balance right is any less important. Luckily for me, it just meant it was easier to get to the table over and over and over and over again, since FUSE is only a 10 minute game. But getting the difficulty and tension right has paid off; players almost always say “Let’s do that again!”….win or lose.
What are some things designers should keep in mind when they are designing co-op games?
Kane: I’ll stick with my theme of balance. You want to be Goldilocks with your designs. Not too easy. Not too hard. Not too long. Not too short. Find that balance. As has been the case when designing a few of my own co-operative games, you may feel like the design is done and the mechanics are exactly how you want them, but you should still keep testing to make sure that balance is right for all player numbers and player types. You can scale difficulty in the rules, but it’s up to you to come up with that. And playtesting is the only way you’ll figure it out.
I would also say that you should know what you want the design to be. Dead Men Tell No Tales is a bigger game with multiple levels of threat that you have to deal with. FUSE is a smaller game with fewer number of threats that you need to deal with. Both games offer a high level of tension, replayability, and fun. I knew what I wanted out of each game going into the design, and I made all of my decisions with those parameters in mind.
Let’s hit on some general design advice to start off with what are your do’s and don’t of prototyping a game?
Kane: I hate making prototypes. I actually enjoy doing illustrations, and the crafty stuff really isn’t that bad. It’s just that I usually have a few different ideas that I want to work on and I hate having to spend so much time making physical components. Also, I’m impatient. When I get to the point in my head that I think a design is ready for a prototype, I just want to play it. I don’t want to have to wait until I’ve actually made the game before I can play it.
I know a lot of designers have a different approach than I do. So my way is certainly not the ‘right’ way; it’s just what has worked for me. I usually work on a game in my head, and just write a lot of notes until I think a game will be great. I play through turns in my head, figuring out what each player will do and how the interactions will work, and figure out where the fun in the game is. Once I get to a point that I feel the game will be what I want, and I can’t find major issues, or if I’m at a point where I know it needs to be played to move forward, then I will make a prototype. So far, doing this has at least resulted in ‘good’ games. Those ‘good’ games are still sitting on a shelf, waiting for their potential to be fully realized. Luckily, a lot of times the games show their potential immediately and I fall in love with a game the first time I get to play an actual prototype. Those are the games that I pursue.
As far as the actual prototypes go, my first drafts are always done with crayon, colored pencil, and marker on paper and card stock. I play it this way with my closest playtest groups for quite awhile. It’s much easier to throw things away, scribble on the components in the middle of a playtest, and add things in when the prototype is so simple. Once I’ve played several games in a row with no major changes, then I’ll start working on putting together a nicer prototype that can be shown to a wider group of people.
Like I said, I actually enjoy doing illustration, so my first couple of games that I designed I did a lot of that, and they looked really good. These days I have too many games that I want to work on at a time, so I usually use clip art and Google images. The prototypes still look nice, but it’s much easier to drop in an image that matches my vision for the game than to do all of the illustration myself. I try to think about graphic design and functionality as well as the overall look of the game when putting it together. It makes it easier for players (and potential publishers) to get immersed in the game.
So, I guess my overall advice for prototyping would be: Start quick and dirty, and then when you’re happy with the game, make a nice looking prototype using free art and graphics. Make it functional and clean and don’t spend money on art.
You have had success with getting your games published with established publishers. What are your tips for pitching your game?
Kane: It’s all about the game. I am in no way a salesman, and I am not comfortable trying to sell anything. That said, I am confident in my games, and I’m passionate about gaming. And I want to be a published game designer, so I push myself to try to show my games to the publishers that I think would be the best fit. I’ve gone to GenCon the past 2 years and I played a total of 1 game over both of those years combined. And that was late at night. I go to work, and to get as much done in a couple of days as I can. I set up meetings with publishers if I can, but otherwise I just lug around a big heavy bag of prototypes and approach the publishers that I think would be interested in the games I have. I try to be respectful of their time while being confident that the games I have are something they are going to want to see. So far it’s worked out.
As far as actually having the games that publishers want….. I think about that through the entire design process. As soon as I have an idea that I know will work, I think about the publishers that would be interested in the game, and what they would want out of it. I keep that in mind as I make design decisions. I design games for fun, and I design games that I want to play, but I also design them as a product. There are a lot of unpublished games out there that are fun. Publishers aren’t just looking for fun; they’re looking for something they can sell. It’s my job to design a game that is fun for the players and profitable for a publisher. I have games that my playtesters love, but I’ve put on the back burner because I don’t feel they are ready to be a great product yet. I just try to think like a publisher when I design.
Do you suggest at all that designers keep a designer journal?
Kane: Yes. My natural tendency is to just grab a scrap of paper or a post-it and jot down an idea that I have. The problem is that I’ve lost a lot of ideas that way. Now I try to keep a small notebook with me at all times. I still end up with notes here and there because if I’m at a computer I’ll start typing the idea, but other times I’ll write it down, especially if I want to sketch something out.
I recently bought an N2 Neo Smart Pen, and I really like it. It allows me to write out ideas and sketches by hand, keeps them contained in one notebook, but also gives me an instant digital backup that I can review on my phone. Everyone will have a different method that they prefer, but so far, this is the one that I like best.
How do you know your prototype is ready to be pitched to a publisher?
Kane: I usually just go with my gut, but I guess I’d say it comes down to a few things. In no particular order:
- The game is what I set out to make it.
- I’ve played it several times without making changes to it, and I don’t see rough edges that need to be fixed.
- If I played the game for the first time, I would want to buy it.
- People ask to play it without me pushing for it. I have hundreds of games. When I have people over for games and they can choose whatever they want to play, and they say “Can we play FUSE?”…..that’s when I know I’m on to something and it’s ready.
What was best piece of design advice you were ever given?
Kane: It wasn’t really advice, but one thing that has stuck with me is something I either read or heard in an interview with Reiner Knizia. I don’t even remember what the context of the comment was, but he said that he thinks about how he wants players to feel when he is designing his games. I try to keep that in mind when working on a new game; especially in the very early stages when I’m coming up with the basic ideas. Knowing what I want the overall experience to be like, and what I want the players to feel helps me maintain focus throughout the design.
As a designer, what has been the hardest lesson for you to learn?
Kane: Patience. Like I said, when I have an idea I just want to play it immediately, but I need to stop and create a prototype. While I’m playtesting a game I just want to play it constantly, but I usually have to wait to get people together. Once a game is finished, it’s all about waiting to hear back from publishers. Once a game is signed it goes into a queue for publication. Once we’re getting close, then it’s all about waiting for art. I’m not complaining. A lot of those steps are also filled with excitement. But Tom Petty had it right: The waiting is the hardest part!
Or maybe that’s just what I’m feeling right at this moment.
Any parting game design wisdom that you can share with us?
Kane: I’ve said this a couple of times, but know the game you want to design, and make sure your design choices steer you in that direction. You’ll have playtesters who love your game, and you’ll have some that don’t like it. Your game won’t please everyone. Know what you want to design, and who your audience is, and I think you’ll be happier with the outcome and more productive.
What’s that you say? Inquiring meeples want to know more?
Want to read more articles like this one? Subscribe to The Inquisitive Meeple via our email service (found at the bottom of the site) and have the newest article links come to you! You can also follow us on Board Game Geek at: The Inquisitive Meeple 2015 Interview List, on our Facebook page or on Twitter @inquiry_meeple. Thanks for reading and stay inquisitive!