Dan Cook
Indie life, remote collaboration, and the magic of small groups
Today, we’ll be talking with one of my heroes – Dan Cook, pioneering co-op game designer, co-founder of Indie game studio Spry Fox, author of the legendary Lost Garden website, and a truly inspiring and insightful guy. Come along as Dan takes us on a whirlwind tour of indie game design life, remote collaboration, and the magic of small groups for getting things done.
About this episode
[Amy Jo Kim] Tell us a bit about your background, both academic, but even more so work background that led you to the skill set and the role that you’re playing today.
[Dan Cook] I went to school to get a degree in physics because I thought I was going to become a computer chip engineer, some flavor of electrical engineer, but then I got sidetracked because I did art on the side, so I did lots and lots of pixel art. So I ended up, for a summer job, instead of pumping gas one year, I ended up working for a company called Epic Mega Games making pixel art for one of their games, and that sort of turned eventually into a design role and I started doing game design full-time after that.
Then I sort of bumped along in the industry as you do and picked up more design skills, picked up UI skills, a lot of it was trial by fire. It’s like this game needs UI. Okay, let’s go and burn through seven UIs and learn why they all are horrible. Then from there I went into developing software. So we made art tools for 3D cards, which were new and exciting at the time, and I learned about product design, and I learned about Scrum, and Agile, and all the ways that you could possibly schedule a project. Again, it was trial by fire. It’s like we need to do this, how we’re doing it doesn’t work. How can I educate myself, read as many books as I can and try to put it into practice in a live team to see if any of these things are effective?
Along the way I started getting some pushback that I was a little bit too much on the artsy side. So at that point I went off and got my MBA (Master of Business Administration), and I started learning the language of business, and then that transferred over to a job at Microsoft, and then I started my own studio about five years ago, Spry Fox, which is where I’m at now, and we are turning out strange, little, innovative games.
Some of which turn into hits.
Yes, yes, we’ve had a couple hits so far, we’ve had one called Triple Town, and we’ve had another one called, an MMO called Realm of the Mad God. So we’re all over the place. Triple Town was a success on mobile devices, and then Realm of the Mad God was actually an online MMO (Massively Multiplayer Online) that was also a success. So we tend to release all over the place. We have experience with all sorts of different areas, consoles, online games, mobile. I’ve dabbled in consulting on the side for places like WordPress and such as well.
Interesting. So earlier you and I were talking about the process that led to these hits, and the process that also led to other games you released, which involved lots of prototyping and lots of funneling your ideas. So that you might be starting and working on several prototypes and only ending up shipping one. Can you talk to us about that process and what you’ve learned about what works?
Yeah, so one of the early lessons I learned about the game industry is that failure is very, very likely. It’s a highly, highly volatile product space. So you have your dream idea, and you try it out, and there’s probably only a one in five to one in ten chances that even if you execute wonderfully that it’s actually going to work out. So one of the things that I got really excited about is can we make that process, of making these games in this highly space, can we make that more efficient and less expensive, and try more things, find success more quickly, all the things that reduce your cost of development and increase your chance of success.
So early on I ran into this model called the Stage Gate model which is a popular product development model. The idea is imagine a funnel if you will, and at the top of this funnel is a whole bunch of tiny little experiments that you’re doing. These are projects that you’re spending, we spend on our games, we probably spend two days to five weeks on, roughly, for those sort of smaller projects. That’s sort of a stage, that’s sort of an early concept stage, prototyping stage, and then there’s a gate, and the gate says what are our criteria for killing these projects? What’s a good project that will pass through? So we look at things like hey, is this game prototype engaging for at least 15 minutes, and if it’s not, then we’ve got issues. If we look at things like is our rate of progress on improving the fun of this game fast enough? You can sort of think of it, I think of it as prototype momentum. If you add an idea and it works, that’s a success. If you add an idea and it doesn’t work, that’s a failure. You’re looking for projects that have a much higher rate of success than the other ones.
Sometimes you’ll run into a project that is just painful to work on. You’re like oh, if I add this idea, it doesn’t work, if I add this other idea, it doesn’t work, I add this other idea, it doesn’t work. To me, that’s a low momentum project. When, I’ve tried for years to turn those type of things around and it’s almost impossible. So at this point I’ll say never mind those projects, I’ll just move on to a new idea and try that out. So you do these stages and these gates. So during the stage you’re developing a bunch of experiments, and during the gate you’re killing them, then you move some of those onto the next stage and you invest in them further. Then you kill a bunch of those and you keep doing this until you have one or two concepts at the very end of that funnel that are actually going to be released into the world.
Now, PopCap does the same process.
They do, they do, and PopCap’s a fascinating example of where it can go wrong. At one point in their history, they had a huge issue where their gates became so rigorous that almost nothing escaped. Basically everything that came out of them had to be a hundred million dollar game, or it wasn’t worth releasing. So their pipeline of new, innovative projects actually dried up. If you look at many of their successful projects, they’re ones that escaped the standard process. The process was too rigid, and therefore it was only by going outside of the process that people were actually able to make hit games.
Wow, so that really speaks to that you need different processes at different stages of your company’s growth.
You do. There’s certain demands on it, like one of the flaws of the Stage Gate process is that essentially bureaucracy sets in and you get people who are like well there was this one example back in three years ago where this didn’t work so let’s put a little criteria in that deals with that. In doing so, that law has suddenly killed something that was really going to be quite successful. So for super large companies that implement Stage Gate, one of the things that they’ve had to learn is to be a little loose about it. Keep those gates a little loose, don’t get too anal retentive about the process.
You’ve done a lot of early stage product work. What are some of the mistakes that you see people making that are common mistakes that you would love to say don’t make those common mistakes.
There’s lots of it. So many opportunities to fail. So not testing early enough, not showing it to people, not showing it to potential customers or users early enough, not listening to them when they express vague doubt about your idea. Sometimes it’s really, really good to dig into that vague doubt and ask, there’s, is it five Ys or three Ys? I forget.
We had the five Ys.
Yeah, you basically ask, so you’re expressing some discomfort about that, why is that? Then you keep digging in a little further, and often you’ll find some wonderful nuggets of insight.
For example one of the things that we’re working on right now is a, we just got a grant for a financial literacy game. We were like oh, well we could have this little like Sims like life simulator and we could have people live out a life and they could learn financial decisions they make throughout a life relatively quickly, and we kept getting this sort of vague like I don’t know if that’s a good idea, a lot of people have tried something similar and it doesn’t seem to really work all that well. The nugget of it, which was a really wonderful nugget that we can act on is if you’re poor, you don’t like playing a game where you start out poor. It’s not an enticing fantasy, or an engaging fantasy for you. So we will build that insight into the game, and if we hadn’t listened to that, which we haven’t on some projects in the past, then the entire project could have been fundamentally flawed from the very start. So ask, talk to customers, show your stuff early.
The other one is being, this has actually been the hardest one for me, is killing things, can you kill things early? I talked about momentum on a project earlier, and one of the things that happens is you get emotionally invested in a project and it’s the only project you have, and you can’t imagine your life without it. So even when all these negative signs are building up, you really don’t have anything else to compare it to and you don’t want to get rid of it. You’ll find tons of excuses to not kill the project. So some of the things that have helped me deal with that is having more rigorous understanding of what a good project is and a bad project is. Then the other piece is leaning towards killing things earlier rather than not. Then the last bit would be having alternatives. Always having two or three alternatives in my head at once so that even if I kill something, I know that I can jump onto another experiment which is also promising. That’s helped me deal with the very expensive mistake in developing a bad experiment for too long.
Wow, that was gold, what you just said, and it started with start the whole thing with lots of small experiments that you are not emotionally invested in. Which is really, think like a scientist about your ideas, not like a pitch person.
Absolutely, I actually find pitches to be complete and absolute poison. Some of the worst projects that we’ve started working on and actually had to release have been pitch-based projects. So I would say it’s the difference between a story and a thing that needs to function. A story is a dream, a pitch is a dream, and you can hand wave, and you can say all this wonderful stuff, and you can get people emotionally invested. Once you’ve emotionally invested people they’ll charge into battle. They’ll sacrifice themselves in order to do something that’s really, really, really stupid.
But if you’re working at it from the perspective of “hey, this thing has to function, this thing has to work, I’m an engineer, I’m a scientist. I’m building this thing that has to work for real humans in the real world.”, you don’t have that lie being told you. You’re not bought into this lie, you’re bought into does this thing work? What are the metrics? What are the results? It’s a very different perspective. So I actually tried to eliminate pitch concepts and pitchness from my prototyping process.
You now run a company, Spry Fox, you’ve been running it for five years and you’re co-founder, lead game designer, you all work remotely, and I think for many of us, first of all that’s reality, second of all, we’re really interested in lessons learned, how to do that well, what didn’t work, things that worked particularly well. Of course some of them are specific to you and what you’re doing, but I think a lot of them are useful tips for everyone, so what have you learned about remote collaboration?
So remote collaboration has been wonderful. It’s allowed us to hire some of the best people in the world no matter where they live. It allows us to work from our homes, it allows us to set mostly our own hours. For people with kids it allows them to juggle kids and work to a much greater degree than they would otherwise. Again, that opens up people who are in situations where they can’t have a normal nine to five job, suddenly these very, very talented people are available to us to hire. So there’s a lot of good things about remote collaboration.
In order to make it work, what we’ve done is we have a way of communicating, right now we’re using primarily Slack. We were using Skype earlier. What we do is we, sort of the secret sauce to all of our online collaboration is we split up into small groups. So if there’s a specific project-based group, a game will start out with two people in it, there’ll be a designer and a programmer, usually me and a programmer. And we sort of set these sort of what are the rules for working within this group. Since there’s only two people there, it’s really easy to setup here’s how we work together. It’s really easy to get consensus. It’s really easy to have these sort of intimate one-on-one conversations with each other. You know, they’re little chat conversations usually. You know sort of get the team coherent and on track really quickly.
That’s a really important thing, often when people try collaboration, they try to put a whole bunch of people in there all at once and suddenly everyone’s going through the standard, what’s the list? Forming, storming, norming, and performing. You form a group, the group has to fight it out with themselves and figure out what they’re doing it and why they’re doing it and who’s in charge, and then you finally get some social norms, and then at the end of all that, you get to actually get your job done. When you have lots of people, the storming and the norming phases of that group formation take a very, very long time. In fact they may never actually converge.
So by starting with a small group we sort of seed that and get that locked down early. In Toyota they used to have this thing where if someone sees a problem they’re able to stop the entire production line and say hey, there’s a problem here, and deal with that immediately and fix that. It ends up increasing the overall quality of their production immensely because problems don’t linger. When you’re dealing with remote working, it’s really easy for problems to linger and sort of fester, and bad mojo spreads throughout the group. The interactions are so limited in many ways that you just don’t have a lot of communication bandwidth to do what is called social grooming, like “hey, how’s it going? How’s your day going, tell me about your kids, is that a new haircut?” That type of activity is very limited. So if there are social problems or group problems, group dynamics issues, they don’t get solved because there’s not enough bandwidth to deal with them.
So what we’ve implemented is sort of this stop the line moment where if the conversation starts going off track, it if starts to become non-productive or people are arguing with each other or talking past each other, we just immediately jump on a Skype call. Usually within 10, 15 minutes, the issue is resolved, and everyone goes back and is able to interact productively again. So having that outlet, even though it’s just a Skype call, it’s not an in-person thing, has prevented days of madness that I’ve seen on other teams, or weeks of madness on other teams.
So do you feel that the Skype call is providing some social grooming?
It is. It provides social grooming, it lets you hear the context of someone’s voice. It also seems to close off conversations that are getting out of hand. We’ve all done email threads where people are kind of like ping-ponging back and forth with one another and never actually getting anything accomplished. So the idea is to just shut that down. Not shut down the conversation, but come to a conclusion and say okay, here’s the issues, here’s what we agree on, are we all good? Why were you so concerned about that? Let’s surface that, talk through it, and move on.
That’s a great tip. What are some mistakes you’ve made that you now know not to make? Or that you’ve seen other people make?
The large groups. I think large groups in online collaboration actually can be a huge problem. You get a lot of people who aren’t necessarily bought into the conversation and it just becomes a very noisy hangout space. Or it becomes a dead room that no one pays attention to. So keeping your team small seems to be super successful for us, which limits the areas that you can use our methods on.
The other one, which is actually a huge issue for established companies, is often there’s a group of people who are co-located with one another. They’re in the same office, they’re talking to each other all the time, and because they have such high-bandwidth communication they are advancing their social ties with one another and their language about the project, and their understanding of the project at a much different rate than the people who they are collaborating with remotely. So you end up getting this “fissure” between the co-located people and the remote people. This is especially problematic when there’s only a handful of remote people, because at that point the handful of remote people are actually the minority and people just start ignoring them. It’s so much easier to just talk in-person through things, that it becomes this whole, additional, extra laborious process to summarize what was discussed and then send it out to people, and then they’re not actually part of the conversation so they feel a little alienated. You end up getting this rift between the two groups.
So what we do is basically everyone runs on the same clock. Everyone is basically, or at the same rate of communication because everyone is remote. So we just don’t get that disjunction between the two social groups.
Wow, that’s incredibly valuable perspective, thank you for sharing that. So you’ve mentioned social norms a few times Dan, and I know that you’ve been reading some studies on the side about social norm, having social norms, pretty unexpected findings. Could you just share a quick summary of what you’re learning there, about social norms and how they shape behavior?
There’s this wonderful, disturbing study, which was, there’s a message out there, which is, people are realizing that it’s an implicit biases to a lot of what we do. So as a response to that, people have been saying everybody stereotypes, be aware of it, social message to people, tell everyone that they stereotype so that they can understand it and stop stereotyping less.
For example, one of the cases was, if you have two equal candidates that are up for a promotion, and one of them is a woman and one them is a man, then the woman will actually be promoted less, and when she does get a promotion, she’ll earn less than the man. So that’s a very clear stereotype that we don’t want to happen. So if you actually tell hiring managers hey, look, everyone stereotypes, be aware of that and maybe do it less, this really perverse thing happens. They actually end up punishing the women more. They actually give them less promotions, and less, or lower raises than they would otherwise.
So the question is, okay, so wait, we tried to do this nice thing by making people aware that everyone stereotypes, why is it that it had the exact opposite result that we were hoping for? The answer is that a lot of what people do is based off what they think the expected behavior in society is. So people were not actually saying “oh, I’m going to take an ethical stand against this and consciously try to not stereotype.”
What they were hearing was, the default behavior in society, that everyone else is doing, is stereotyping, therefore that’s how I should behave, which was just mind blowing to me. It’s like wait, wait, so that says that people are not operating on an ethical basis, they’re operating on this much, much lower sort of like flock behavior. Where they’re watching what other people are doing, they’re seeing what seems to be the expected standard behavior and they’re unconsciously mimicking that.
So the social norms of the environment end up being much more important than, sort of our conscious stating of like, what we say is what we’re going to do or what we say is ethically responsible. So that sort of insight has been influencing a lot of my design when I’m thinking of behavioral change and how we sort of create these human processes that get work done.
Well that’s, it’s kind of mind blowing. Are there other studies that came to that same conclusion?
Yes, yeah. There’s a whole bunch of work on this. It goes back to the Stanford prison experiment where they normalized people to be guards and prisoners, there’s some flaws in that research but people have been exploring it since then. We see it in the news with Abu Ghraib, with the fine, upstanding, young American soldiers, how is it possible that they’re doing these horrible things to these prisoners in Iraq. So you see the power of norms and socialization there.
There was another one on cooperation, let me see what this one was. Yes, this ties into my interest in cooperation. They’ve found that players who were playing a cooperative game, such as two people sitting on the couch, cooperating with each other, all on the same screen. People who played a cooperative game versus a competitive game, people who played the cooperative game would immediately afterwards they would react positively to other people. They would treat them less aggressively. They do these little cooperation, competition tests using game theory, and they would be more generous.
So they were, they say wait, wait, so playing these cooperative games ends up actually changing people’s behavior outside of the game for at least some period of time. Why is that? Again, they came back to the idea of social norms. The context that these people knew each other was that okay, the social norm is how we treat, we treat each other nicely because we’re cooperating together and we’re dependent on each other. So that’s the sort of like, norm for this group, and I will of course continue using that, because now that it’s been set up, I try not to change my norms too often.
I think for a lot of us, in what we’re designing, using the idea of making social norms visible and suggestive is a very powerful idea. Exactly how you do that, the devil’s in the details, right?
Yes, yes, very much so.
So Dan, couple more questions to close, one is, you mentioned your interest in cooperation. What is your super power as a designer? I mean you’ve clearly got a lot of different, awesome skills, where is your sweet spot?
One of the things I try to do is identify a skill that I lack in and then improve upon that and these are year-long quests. One of my quests right now is to make pro-social, cooperative games. I’ve had some experience and success with that, but it’s deep, rich field. So I wouldn’t necessarily say it’s my superpower, but by studying it obsessively and working at it over a period of years, the hope is that I’ll become much more capable at making those type of games.
I’ve accumulated the multi-player games, social structures that I find fascinating to work on. For a while, I was focused on evergreen games, games that you could play for years, that wouldn’t get boring, so “how do we build these rich, deep systems that people can engage with for a very long period of time?” I feel like I did that and that’s part of my arsenal, but it’s not my main focus.
Previous to that, I was interested in product innovation and a lot of our games are innovative, they’re in a new genre or they’re trying something new or they’re experimental in some fashion. Most working game designers tend to take something that already works and make a plus 10 percent variation on it, and I’m less interested in that. I’d rather go down to the roots of an idea and re-invent the thing to fit the current environment, which is more that entrepreneurial product innovation perspective.
Well, you’re probably one of the world experts in cooperative gaming, so it seems that you might have some skills to bear to bring to that. Are the games you’re working on, do they have any co-op in them?
Yes, we have an MMO, which is SteamBirds, and that one has co-op in it. We have a couple of single-player games that are less cooperative, but I hope to make them one day.
Then there’s another design that I’m working on that I’m excited about, which is like an MMORTS (Massively Multiplayer Online Real-Time Strategy). Clash of Clans is vaguely, genetically related to this. So they’re games where you play five minutes of this every day and that’s all you can do. And they’re multiplayer and often they involve “I build up my city and then I build units and then I attack somebody and the attack takes 24 hours to complete, and then they attack me back and I can get into an alliance and get politics, and so forth.” Very leaderboard-centric, but this genre is one of the most popular genres in the world. It is one of the largest drivers of revenue, it’s bigger than adventure games, it’s bigger than real-time strategy games. You know, when you see one of those horrible advertisements, with Kate Upton? Those are for this style of games, because you can play them in a web browser, you can play them on mobile, you can play them on a PC. It was originally a US innovation and then it moved to Germany and then it moved to Asia.
In terms of cooperative, I thought these games are really horrible in the psychology that they use. It’s all about beating up on other people and competition. Can we make a purely cooperative version of that? That’s the design task I’ve set myself.
Wow. Have you cracked it?
I think so, I have to do some more prototyping, but I think I’ve cracked it.
Thank you so much, Dan, for coming and sharing your wisdom. Your perspective, as always, is very stimulating, mind-expanding, and I can’t wait to play your upcoming games.
Thank you for having me.