In this episode:

Jordan interviews Dave Rohrl, a veteran game designer with 30 years of experience designing and producing online games. Dave has held senior positions at leading companies like Pogo, PopCap (he’s actually Crazy Dave in Plants vs. Zombies), Zynga, and Playdom, overseeing the design of more than 50 games and consulting on countless others. In 2014, Dave founded Mobile Game Doctor, a global network of dozens of experts that helps game developers worldwide improve their free-to-play games and game businesses. Dave shares his insights into the game design process, emphasizing how to achieve 'fun' early in development, the importance of rapid prototyping, and why using rough code and art early on helps reduce design risks.

Topics covered:

• Dave’s journey from non-profits to leading game development at top companies
• How to find fun early in the development process
• The importance of fun and player engagement in game design
• Why using rough code and art early on helps reduce design risk
• How to balance creativity, technical implementation, and budget constraints
• Dave's approach to evaluating game prototypes and reducing project risks early
• Aligning game mechanics with user behavior
• Best practices for mobile game development and free-to-play business models

For more game industry tips:

• Learn more about Jordan & Bright Black
• Listen on iTunes | Spotify (Support the show and leave a review)
• Visit www.playmakerspodcast.com for the full blog post and more!

Timestamps:

[03:02] Dave’s background: From non-profits to game design

[07:00] Early career at The Learning Company and Pogo

[10:25] Lessons from PopCap and Zynga: The rise of free-to-play gaming

[12:12] Rapid prototyping and the "fail fast" approach

[16:50] Balancing creativity with risk management in game design

[21:20] Working with small, focused teams during pre-production

[22:55] The five fun factors: Building engaging game mechanics

[29:43] Balancing creativity and budget in mobile game development

[34:12] Dave’s advice for designers: Focus on gameplay, not flashy assets

[37:00] Prototype-driven development: Managing design risks and early testing

[41:00] The challenges of "polishing the turd" and when to abandon a game project

[47:40] The role of external feedback: Being the "emperor’s new clothes" guy

[51:50] Working with teams to improve games during different development phases

[54:30] Dave’s thoughts on the evolution of mobile and casual gaming

Resources & media mentioned in this episode:

Learn more and Connect with Dave Rohrl:

• LinkedIn
• Twitter

Games & companies mentioned:

• Plants vs. Zombies (PopCap)
• Peggle (PopCap)
• The Learning Company
• Pogo (Electronic Arts)
• Zynga (FarmVille)
• Playdom (Disney Interactive)
• Sid Meier’s Pirates (MicroProse)
• SimCity (Maxis)
• Star Wars: Commander (Disney Interactive)
• Reader Rabbit (The Learning Company)
• ClueFinders (The Learning Company)
• BoardGameGeek (Online platform)

Hey, what's up? You're listening to Playmakers Podcast. I'm your host, Jordan Blackman. On every episode, I interview a game industry legend or luminary to bring information to you that's going to help you do better on your project, in your discipline, in your domain, and to get a bigger, wider view of the game industry. This week, I've got Dave Rohrl, known as the Mobile Game Doctor. He has a lot to share about designing efficiently and effectively for mobile games. That's coming up. Here we go.

Dave has held senior-level positions—I'm talking executive positions—at companies like Playdom, PopCap, Zynga, Pogo. There aren't many companies like that. Those are the biggest players in that space, and Dave's been there. If you've played Plants vs. Zombies, as you’ll learn in this interview, Dave is Crazy Dave—or at least the inspiration for Crazy Dave—in those games. We get into some really interesting information about what Dave has learned in his many years doing casual games, about designing efficiently, producing efficiently, minimizing design risk, finding the fun early, the soft launch process— all that stuff. So if you're working on a mobile project, a casual project, or just want to get some best practices from that field, you're going to get that in this episode.

Dave is someone I wanted to have on the show because he’s someone I personally admire as a designer. I've gone to him in the past with specific design issues I was working out when I wanted outside input, and he’s been very helpful in that capacity. I have a lot of respect and trust in Dave, his skills, his background, and his professionalism. I think you'll get a taste of all that in this interview.

Now, before we get to the interview, I just want to mention that if you're enjoying the show, if you're getting something useful out of it, please share it with anyone you know who would enjoy this episode or any of the others we've done. You can also head to iTunes, subscribe, and write us a review, which is awesome because that's how I find out who you want on the show, what's helping you, and what you like about the show. It also helps support the show and get the word out there. And if you just want to reach out to me directly, you can do that at jordan@brightblack.co. I want to hear about the struggles you're having on your project, the topics you want covered on the show, and the guests you want on the show because this show is here to help you. It's for you. This is my way of serving the game design, production, and development community—and the business community as well. So, I’ll leave it at that. Let’s go talk to Dave, the Mobile Game Doctor.

Well, thanks, Dave. Welcome to Playmakers. It’s great to have you on.

Thank you so much for having me, Jordan. It’s a pleasure.

I've had the chance to work with you on a couple of things, and I really admire your skills, your coolness, and your honesty. I want to start by asking how you got into the industry. I know you've been in games for over 20 years. What brought you in, and what got you interested?

So, I actually got into games relatively late. It was right around the time I was 30, which means I had a couple of careers before that. After college, I spent about five years working in nonprofits, saving the world. As you can see, mission accomplished.

What kind of nonprofits were you into?

I did some environmental work, I did some diversity work, and I did some anti-nuclear work. Sort of at the Bernie Sanders end of the political spectrum.

That's amazing.

Yeah, it was really fun work, but I had a very interesting experience in a couple of different nonprofits where I had an opportunity to rise up in the ranks and take on a lot of responsibility in a senior post, and I just couldn't get excited about it. The second time that happened, I took a giant step back and said, okay, if I can't get excited about growing my career here, it's probably not the right career. That led me to take stock of what I love and what I'm passionate about. I've actually been obsessed with games since I was very, very little. Like, I've been obsessed with games since before there were video games. I was the little kid who wanted my parents to play one more game of gin rummy before bedtime and, you know, got together with my friends for games.

Not too many kids like that anymore.

Well, this is true because we've opened up solo entertainment so much. The rate at which entertainment pours into our lives right now is staggering—just the amount of content that's out there to interact with.

Totally. The idea that social gaming would be a distinct thing, rather than just what games are, shows how much we've changed.

Yeah, I got into a couple of arguments with some semanticists at the GDC talks about people saying how games had forever been multiplayer, and only in the last couple of decades, they've been single-player. I pulled them aside and said, "Actually, dude, single-player video games evolved from puzzles, not from games." But that's kind of semantic and nitpicky. I’ve always loved games, and I’ve always loved technology. I also looked around in the late '80s, early '90s, and said, do I think I can make a living making board games? Board games are a tremendous passion of mine. I've got about 700 around the house.

Oh my gosh.

Yeah, they're kind of taking over the house. I'm selling off some because I literally can't fit them in the shelving anymore.

If you want to put a link to your board game collection sales, maybe we can help you out.

There you go, will do. Yeah, I'm selling them off via auctions on boardgamegeek.com, which, if you're as geeky about board gaming as me, is a great resource. But I took my love of games, my love of technology, and I had recently been playing some games that really excited and inspired me—games like Sid Meier's Pirates! and Railroad Tycoon, and the original SimCity. That, combined with my lifelong love of strategy games, made me say, "Okay, I really want to do this. I want to participate in this act of creation." So that's what pulled me in. I was around 27 when I decided I wanted to get there. It took me a couple of years to build the right professional skills to transition from nonprofits into technology and then into games. I broke in around '94 and have been having a lot of fun ever since.

Where did you break in?

So, my first job in gaming—I did a very short-term engagement for an educational courseware developer that was part of Simon & Schuster. But my first real job in gaming was actually as a senior QA engineer at The Learning Company down in Fremont. The folks that made the original Reader Rabbit and ClueFinders titles. I spent about six and a half years there.

It seems like quite a few people got started there.

There were a lot of smart folks inside that company. They did some really interesting games, too. I think it was a good and interesting place to launch in some ways, just because making games for kids means you really need to learn to make something that's fun for someone who isn't you. You have to understand an audience externally and realize that kids will hit usability issues that you never will. They’re going to hit a threshold of confusion that you won’t because you’re in your 30s and making something for six-year-olds.

I've definitely seen a lot of developers struggle with that.

Yeah, and also how to work lean. When I started in the '90s, there really were no online games to speak of. In the early '90s, you had some MUDs, and that was about it.

So games were mostly delivered on a CD-ROM, and they were super dependent on the video card you had in your PC. A lot of kids tended to work on hand-me-down PCs—not a lot of memory, not a lot of processor power, not very good graphics. So you kind of learned to work lean and to really focus your design, not hiding behind rich assets.

It sounds like some of these skills—working lean and being able to understand how to think like your user, who might be different than you—gave you a jumpstart when you started working in casual mobile games.

Yeah, absolutely. I think those are really valuable skills for any designer, regardless of what you're doing. I think, generally, in down-market platforms, there's more value in understanding leanness and going asset-light. But really knowing how to focus on gameplay and deliver that strongly without relying on big flashy assets is your friend—whether you're making games for smartwatches or next-gen consoles.

Yeah, well, I want to get into that with you. But before we do, you went on to work at Pogo, PopCap, Zynga, and Playdom in a number of very senior positions. Who were you learning from along the way? Who were the people and what were the projects where you built up the skill set that you have today?

Yeah, well, after two decades in the industry, I've had a lot of teachers who've had profound impacts. At Pogo, it was interesting—there was definitely a management hierarchy, but there were three or four really strong designers. None of them were celebrities, but they were really strong designers, all at the same points in their careers, and they all came in at the same time. I feel like just by working together, building a culture of critique, collaborating, and challenging each other, I learned a ton. I don't know, maybe I slipstreamed off those guys, or maybe they learned something too. But those were Troy Whitlock, who not only created a lot of great stuff at Pogo, but he's also a very successful designer at Disney and created Star Wars: Commander, among other things. And Todd Kerpelman, who is now working on the other side of the fence. Last I heard, he's at Google, working as an advocate for game developers, helping give them a voice inside the technical development of Android and helping with their issues.

Todd and Troy were the guys who really brought prototyping to Pogo. Before that, it had been much more of a waterfall shop, so I learned a lot about prototype-driven development there. At PopCap, I got exposed to Jason Kapalka, one of the co-founders of PopCap and really one of the great intuitive game designers. He wasn’t necessarily the best at breaking down his process, but watching him work and learning from that was amazing. I worked with him, and George Fan was actually one of my employees at PopCap, the creator of Plants vs. Zombies.

Oh, wow.

Yeah, actually, you're talking to Crazy Dave—the original inspiration for the character.

No way! You're the inspiration for Crazy Dave?

I am the original Crazy Dave! It's eight years later, and there's still a zombie on my lawn.

I was just looking at the new card game.

Yeah, I checked that out early in soft launch. I'm really eager to see how it's come together in its final version. But yeah, there goes 14 minutes and 59 seconds of my 15 minutes of fame right there. George is a fabulous and intuitive designer. Sukhbir Sidhu, who was the producer and designer on Peggle, was my boss while I was there, and watching him work was fantastic.

One interesting thing about this part of my career, which was really the first 12 years, was that there wasn't a separation between producers and designers. I didn’t start early enough in the industry where it was the same person doing the coding, art, design, and audio. I came in after coding, art, and audio had split off as distinct disciplines. But you were generally the lead designer and lead producer on your project. That actually taught me some valuable things, like thinking about the difficulty of implementation, overhead, and the cost of what I wanted to build. As a designer, it taught me to facilitate risk management, cost containment, and really focus on bang for the buck. It's one thing to come up with ideas, but it's another thing to be accountable for getting them done and into the game.

I would imagine it also helps with what you mentioned earlier, as far as understanding your demographic and designing for them rather than for yourself.

Yeah, absolutely. And then I think it also gave me much more of a connection to quality and the design process, and the amount of iteration necessary as a producer, than I would have had if I were coming up as a pure producer. So I feel like playing both of those roles has a lot of value. Even though I’m a better designer than a Gantt chart completer, I feel like building up both of those skills was important.

You just made a lot of producers very angry.

There’s a lot more to the job than that. Please don’t get me started. I once referred to the title of producer as a "null signifier" in a job interview because I’ve known producers who were almost purely creatives, producers who were almost purely project managers, and even producers who were almost purely dealmakers.

It’s a bit of a catch-all title. One of the things I tell people about being a producer is that other people are various tiles in the structure, and you have to be the grout.

Yes, it’s your job to kind of make it happen. I have my whole building-a-house analogy. Whenever I tell people I’m a game designer, the first thing they ask is if I write a lot of code. The answer is, no, relative to any capable coder, I’m a pretty bad one. Although that’s one of my skill sets that I’m hoping to rebuild and strengthen in the coming year. But I tell people, if you think about building a building, the designer is the architect, the producer is the contractor. The producer is the one who’s going to get it all there. Hopefully, they’re super invested in the quality of the final product. I liken the engineers and the artists to the carpenters and electricians who are really going to come in and put those things in place.

The craftspeople.

The craftspeople. But the producer’s got to bring that team together, keep them flowing and organized, and deal with all the unexpected stuff that comes up during the project. And then, of course, they have to disappear for three weeks and stop answering phone calls. No, I’m sorry. That’s how they’re different from contractors.

And then there are the associate producers, who are more like craft services. No, I’m kidding. Totally kidding.

No, but I actually really enjoy production. I really enjoy leading teams, figuring out the puzzles of what we have to do next, and working with prioritization, road mapping, and planning. I also really enjoy agile process management. I think it’s really fun, and I’ve learned some interesting methods from some super cool people. But when it comes down to the meticulous tracking of every detail, there are other people who are much better at that.

In terms of mentors—and I know I’ve gone long, but I’ll finish up quickly—there was an incredibly brilliant staff of creative designers at Playdom. Troy Whitlock was there again, and I also learned a ton from Steve Meretzky.

Oh, yeah.

So Steve and I are old friends. We've done a lot of public speaking together. We've organized symposia together, so having a chance to work with him for a few years was great. And a brilliant, brilliant fellow named Eric Todd, the Gardens of Time guy, was also there. I learned a tremendous amount from him. Oh, and Raph Koster, who...

I read his book.

One of the smartest guys in the business, for sure.

Now, was that whole crew in the SOMA office?

No, the HQ was actually in Palo Alto. Steve worked out of SOMA, Raph worked out of a studio we acquired down in San Diego, and Eric, Troy, and I worked out of the Palo Alto office. Although we all did a fair amount of flying around. Playdom was a company that grew a lot by acquisition, so we had studios in North Carolina, Seattle, Buenos Aires. I got to fly to Buenos Aires a couple of times. No complaints—especially Buenos Aires in January, fabulous. Middle of summer down there. I really enjoyed flying around, partnering with those different teams, and trying to help get them on track.

So let's dig in a little bit on process because you mentioned to me, when we were talking ahead of the interview, how this was something you really cared about. I want to learn a little bit about the kinds of processes you feel are really important to mobile and free-to-play gaming and working with your clients.

Sure. Well, let's talk about the processes that are critical to game development in general.

I hear a little clinking over there, so that's always a good sign.

It is, it is. It's a glass of seltzer water. Very exciting afternoon fare. So, one of the big things—and this actually gets missed a lot as folks become more engaged with the business models of their game—is that your game has to be fun. If it's not fun, if it's not compelling, if it's not engaging, then there's nothing you can do in terms of monetization or metagame that's going to save it.

And for what it’s worth, there are a lot of games that don’t deserve to be saved.

Not spoken like a former nonprofit person, Dave.

No, there are a lot of nonprofit projects that don't deserve to be saved either. Ultimately, using prototype-driven development is a way of quickly finding out whether your game is worth finishing. One of the things I really push teams to do is to stack up and order the early de-risking or pre-production process. A fair amount of my thinking on this is shaped by a paper by Mark Cerny—he’s the guy that created Marble Madness and, I think, Crash Bandicoot and many others. It’s called the Cerny Method, and it’s really about separating a project into a pre-production segment where the process is very loose, the team works really fast, and they get to the point where they can build a scale model of a game they think is going to be commercially successful. From there, you move into production, where the game is better understood, and you just focus on building it out in a much more predictable, process-driven way.

Right, like in one phase you’re figuring out how to make the dishes, what the recipes are, and in the next stage, you’re making the dishes.

Yeah, theoretically. I mean, I think development isn't quite as rigid as that, and you need to allow for learnings that occur later in the process. Early on, at the very beginning of a project, there are a couple of things I like to maneuver teams into doing. One is using some really tightly defined rubrics to help them identify what they think the core fun of the game is going to be and who the audience is. It’s important to take some time to step back and think about what they want to build and why.

And the second thing—so that’s kind of more of a design and production collaboration.

And that’s kind of like aligning the product with the audience, coming up with prototypical players, that sort of thing.

Yeah, what I try to do is get a really simple demographic profile. Who do you think you're building this for? Gender, age, favorite games, favorite TV shows. Can we build a little picture of what the content profile of the consumer who’s going to like this game might be? And then, as we think about what we're putting into it, let’s really consider how it aligns.

There are a couple of rubrics I use—one of my favorites, which I’m working on a blog post about at the moment, is what I call the “five fun factors.” This is something I picked up at Pogo. The idea is that your game should have somewhere between three and five absolutely great, super fun, highly repeatable things that your player can do, wants to do, and knows how to get to. That way, they're willing to crawl through the mud to do these great things that are exciting and compelling.

And how granular do you get when you're thinking about what a thing is?

I usually define it in terms of a player action. So, let's say you're thinking about a Civilization-type game. Maybe it’s unlocking a new unit or building. When I get to do that, it’s really exciting because now I can win fights I couldn't win before, or I can make my cities bigger in ways I couldn't before. I want that moment of unlocking to feel really good.

Gotcha.

And I'm willing to jump through a lot of hoops for that. In a Civ game, I probably want conquering an enemy city to feel great. I want discovering hidden features on the map to feel great.

So these are like abstract, a little bit abstract, fun mechanics.

Yeah, I mean, if you think about them from a sort of mechanics, dynamics, aesthetics perspective, they're kind of on the low end of the dynamics level. But yeah, these are things where the player says, "Man, I want to do that again. That was great." In my experience, if you're working on something at the scope of a mobile game and you're trying to get more than about five of those into your initial release, you tend to have a diffuse design. You tend to get feature creep, and those big moments that you're trying to punch actually don’t sing. They don’t get there. They don’t hook the players.

Yep. That makes sense. You try to punch too much stuff, and you end up with a lot of noise.

Yep. And if you have fewer than three and you're trying to do something at the scope of a mobile game, you really need to be on the lookout for whether there’s enough there to keep people engaged.

One of the things I find working with many designers, especially young designers—so I mentioned I’m a board game nut. Board games are very mechanically driven, they’re very mechanically naked, and they need to be human-moderated. A lot of young designers really like to start with very granular mechanics and build the game up from there: "We’re going to have this feature."

So I’ve found that forcing the team or the designer to step back and say, "Okay, these are the things we think are going to be awesome," and then challenging them as to whether the granular features they’re talking about actually support that awesome. Do they help make that happen? Are they necessary scaffolding and infrastructure, or are they gone? Those are the three baskets I like to see for those granular feature designs. Either they make the payoffs great, they’re connective tissue you need to get there, or you should focus your limited time and resources on something else.

Along with that sort of vision-crafting process, there are a few other rubrics I use, but that’s a good one to start with. There's also a list of risks for the project, and that’s something that is very producer-y. A producer’s number one job is to manage risk.

That’s my take on the producer’s role. You’re trying to understand what the risks are for the project getting off course and mitigate them as best you can, as early as you can, to keep things on track. So I like to see the producer having, really from the kickoff, a list of game-killing risks. For games where you're innovating in gameplay, the gameplay idea itself is usually a top risk.

Yeah.

And in fact, even on games where you say, "Well, we're going to take this from Column A and that from Column B and put them together," often that interface is a bit of a stress point where you need to make sure that System A from Game X and System B from Game Y actually fit together in a meaningful way, and the interface you want to put in between them is going to be comprehensible and fun.

Yeah, and even ensuring that your version of element X or Y comes out well.

Yeah, so I like to have that full list of stuff. It may be about gameplay, it may be about technology, it may be about validating that an audience exists, the one you think is out there. It may be about developing a visual style for the game.

Looking around and saying, "Okay, what are all the risks that can take my game out of the air with a single bullet?" And then, as a good producer, you want a mitigation plan for all of those. For gameplay issues, it’s usually a prototype of some sort, and you want that prototype to be as quick and cheap as you can make it.

If you can do a paper prototype that really answers your key questions, that’s by far the best way to do it. The designer can grab some office supplies, go off in a corner, make up some cards, build the thing as a card game or board game, play through it, and figure out if it’s going to work at that level.

Take some pieces from one of your 700 board games.

They belong together. I actually have a separate drawer of board game prototyping supplies.

Okay.

It's full of meeples, gems, hex grids, bingo chips, Scrabble tiles—you name it. And that's actually super valuable. Every designer should have one of those crates.

A lot of stuff, particularly stuff that involves real-time interactions, needs a code prototype. When I'm building a prototype in code, I really like to see a very small, focused team there—a designer and a programmer, maybe two—iterating really, really fast. The objective of a prototype is to fail fast, make lots of mistakes, learn from them, move on, and keep moving until you either get to a game that’s going to work, that’s fun and playable and exciting, or you conclude that you need to shelve the project.

What would be fast? What's a fast iteration?

For me, I like to start with concepts that can be playable in less than two weeks. And then I like to make a significant change every one to two days.

During that two-week sprint?

No, I'm saying that the initial two weeks, the project is permitted to go dark because it may take a week or two to get your core systems and mechanics functioning, to get something actually happening on screen that resembles the part of the game you’re trying to address. Once that's done, I want a significant change daily. I want to try stuff out, give it a green, yellow, or red tag. Green means, "This is awesome, it needs to stay in the game." Red means, "That didn't work at all, let's not go back there. Let’s learn from it, but it's a dead end." And yellow means, "Let's take this idea and revise it in the next iteration."

Once you have something playable in prototype form, I like to have the engineers hand off something in the afternoon, the designers play it in the afternoon and evening, and come back in the morning with, "Okay, here's what we're going to try next."

For a 12-month project, I'm willing to let this process go on for up to three months after you get that first playable. My rule of thumb is, within a month of having something moving on screen that represents the basic idea of your game, there needs to be some kind of spark in the prototype. People should be playing it and saying, "I think there's something here," or "This seems interesting." And by the time you get to 90 days, the fun should be clear and well elaborated. People should be saying, "This is good. Where are the other levels? How do I play more?" You should have people hooked on your prototype.

Now, inside the prototype, I'm a huge proponent of using few, if any, assets. I use a lot of squares, circles, triangles, and text labels to make it clear what things are. I don't want to put anything pretty in my prototype because once you start putting beautiful art into something, people fall in love with it.

People get confused, yeah.

Yeah, or they overestimate the fun factor if the game is fun. They also overestimate how close it is to shipping. When I have an engineer I'm prototyping with, I ask them to write code that they would be ashamed to show their colleagues in a review. The code should be literally embarrassing—it should be as slapdash as humanly possible so we can do it fast and move on to the next iteration. I’d rather take a month of that, and then have the developer throw up their hands and say, "Oh my God, dude, this thing is such a mess. You've asked us to do all this crappy code. I need three days to refactor it." Let them go dark for three days. I'd much rather have that than have them try to architect and scaffold and make stuff pretty.

Right. Or decide three months later that now they need to refactor because they're using the same code they started with.

Yeah, yeah, yeah. The code for the prototype should always be dumb. Always, always, always, always. It can be hard to get political cover for that in a lot of studios. So, one trick I’ve learned over the years is to prototype in something different than your development platform.

Oh, that’s very interesting. Yeah, like GameMaker or something like that.

GameMaker, Defold, GameSalad—there's a bunch of tools out there. So, if you're going to make a Unity game, prototype it in Flash.

Anything but Unity.

Anything but Unity.

That’s a great trick.

Yeah, and then when management says, "But we’ve got all this code here," you say, "Sorry, can’t." Right?

I’m a big believer in time-boxing during prototyping. So, if after a month it’s not feeling like there’s a spark—if instead of "This looks interesting" or "There’s something there," people are saying, "I don’t get it" or "I think I hear my mommy calling, sorry, I have to go home, I can’t play baseball anymore"—you don’t want to give that project a whole lot more time. In that situation, you might give the team up to a week to get something with a little bit of grab. And if they don’t, okay, move on. Likewise, if you hit that three-month milestone and it’s still not fun, still not grabbing people, maybe give it another three weeks at most. If it’s still not working, put it aside. Sometimes, just like writing an article, you need to write your rough draft, put it in your desk drawer for a couple of days, and come back to it. Sometimes stepping away from a prototype is the best thing you can do.

So mapping that back onto the Cerny Method you were talking about earlier, would that three-month window be kind of like the end of the pre-production phase?

Yeah. While the prototype is in development, I like to have some concept art going at the same time. If you need technology prototypes because you have technical risk, I like to have those going too. But at the end of that three months, I really hope you can step back from the project and say, "Okay, we built something to address all the game-killing risks. We believe the game can be successful. We’ve seen that it’s fun, we’ve solved our tech problems, and we’ve got some art direction that we think is going to work for the target population."

Now it’s time to shift gears a little bit. So, I actually have a brief planning stage that comes after that. It says, "Okay, given everything we’ve learned during prototyping, what do we think the product will take to build?" Then there’s a much more linear building stage, where you’re working in the target codebase, integrating assets, and elaborating on the less risky design or buttoning up details.

One mistake people make—and Dan Cook, who I think is a brilliant game design thinker, has a great article about this on Lost Garden—is shutting down the creative process completely after the prototyping and pre-production stages, and saying, "Now we’re going to build this out exactly, and we cannot deviate at all." You wind up missing out on a lot of good creative opportunities.

So, you want to make sure you’ve got some wiggle room left to learn more about the game, learn more about the players, and discover and improve as you go. But yeah, pre-production is about de-risking all the crazy risks, planning is figuring out what it will take to build, and building is... well, building it. And then, of course, this is very much a packaged goods model. So, the building never really ends as you go into endless cycles of live development and free-to-play, as you get more and more user data coming into the process.

What do you do if opinions differ about whether there's a spark?

So, in general, building a competitive mobile game at this point in history is going to cost you multiple millions.

Yeah, I think a lot of people have still not come to terms with that, but yes.

Yeah, I’ve been doing some scratch budgets for a potential project, and even the cheap ones at this point tend to be around a million and a half to two million.

We’re talking about free-to-play, games-as-a-service style mobile games?

Yeah, absolutely. So, this is kind of what your development costs you up to the point where you're ready to soft launch. Then, if the game looks like it's going to be competitive as you bring it to market through soft launch, you're going to need to continue supporting that team, and you’ll need to acquire users on a steady basis to verify that players are behaving the way you think, that the technology stands up, and so on.

And then, if the numbers look good coming out of soft launch, you're likely going to want a large launch marketing budget on top of that, which can be multiple millions again. So, just ask yourself—before you come out of pocket for the, whatever, three to five to 10 million bucks it’s going to cost to launch a top-of-market mobile game—how strong would you want your proof and conviction to be?

Right.

Right. It’s a big investment. This is not "Let’s take 200,000 in development funds, throw it together, and see what happens."

Right, but somehow there still ends up being quite a bit of gilding the lily.

I’m not quite sure what you mean.

Meaning taking something that doesn’t have that heart of gold and dressing it up, thinking that’s going to change the outcome.

You mean polishing the turd?

Yes.

Gilding the lily is actually a term I've heard in game development to mean something at the opposite end, which is taking a game that's really solid and continuing to work on it well past the point when it's actually done.

Oh, you're right. You're right. Yeah, that makes sense. So it's taking something that's basically done and continuing to work on it.

Yeah, exactly. Gilding the lily has its own problems—mostly that you can lose some market incumbency, and you have additional burn while you fool around with stuff. There's also a minor risk of breaking things. Polishing the turd, though, is a much bigger problem.

Yeah, let’s talk a little bit about polishing the turd.

Yeah, I have polished some turds in my career, and it never ends well.

Right.

At the end of the day, a game that isn’t fun for some meaningful target segment, isn’t engaging, and isn’t retentive—something people don’t want to do—is not going to be a financial success. If nobody's having fun with your game, you're not going to keep people around, and they're not going to give you money. I’m a big believer in brutal honesty about where a game is and what its prospects are. But I do think there are a lot of games that should not go into production that do—usually for a few reasons.

Some typical causes that I’ve seen: there are external contractual obligations. For example, you might have a licensing deal signed, and there’s a big breakup fee if you don’t deliver the product. Or, even just not delivering a product can be a PR nightmare. A lot of these reasons show up around other types of external commitments, especially in public companies. If you’ve gone out and told the investment community that you’re going to make a lot of money in Q3 because of this release, it’s hard not to release it in Q3. But if it’s not ready, not releasing it is usually the right decision.

People are hopefully passionate about the games they work on. I know that I work really, really hard to make the games fun, enjoyable, and engaging. And when you invest a lot of yourself into your work, especially into creative work, it can be really hard to get enough perspective on it to be able to objectively say, "This is working" or "This is not working." And frankly, even if you kind of know it’s not working, it can be hard to admit that externally.

Yeah, absolutely. But it gets even harder not to admit it over time, doesn’t it?

Yes, absolutely. There’s this sunk cost problem, where the more you work on it, the more invested you become, so the more hesitant you are to judge that work in a really critical way.

This is something I find myself doing with a lot of teams: being what I call the "Emperor’s New Clothes guy." So, presumably, you're familiar with the tale of The Emperor's New Clothes?

I have my own use of that term in game development that I’ll tell you about after.

Interesting. Okay. So, for any listeners who may not be familiar, The Emperor’s New Clothes is a folktale about a very vain emperor who loves to be well-dressed. A tailor comes to him—a bit of a charlatan—and tells him he’s going to sew a fantastic set of clothes that will be gorgeous and the envy of everyone at the royal parade. The king gives him a fabulous sum of money, but the tailor just pockets the money and makes nothing. He goes to the king, pretends to dress him, and tells him he looks fabulous, but the clothes are invisible to him, even though they’ll look amazing to everyone else.

Of course, all of the king’s court, his supporters, and his toadies tell him he looks amazing. He walks down the street during the royal parade, and everyone’s applauding. Then some little boy comes forward and says, "He’s naked." All the adults around the boy go, "No, no, no, he looks great. The clothes are fantastic." Because they know the king is vain and they’re trying to keep up appearances. But the truth is, he’s naked. Everyone can see it.

This often becomes my function on a team: to be the guy who comes in, takes a hard look at what they’re building, and makes sure they have a realistic handle on what its problems and challenges are—and what they’re going to need to do to actually make it successful. Wooga, who I did a lot of consulting for over the last couple of years, recently released a game called Warlord. This is a game I coincidentally touched while I was driving development on another prototype there, or driving design.

The product lead asked me to play it. I played it for a few minutes and told him it was quite terrible. The game had been in development for, I think, a couple of years at that point, and it was really dreadful. I didn’t want to keep playing it, and I told him he needed to get out of production mode, get back into prototyping, and make the game fun—or kill it before continuing to develop it.

To their credit, they went back, built a gameplay prototyping team, did a bunch of paper prototyping, and built a bunch of board games to play internally. They got the core mechanic to a place where it was pretty damn fun. Throughout that process, they brought me in every few months to help evaluate progress, though I wasn’t super hands-on.

Now, a couple of years later, I just heard from the producer of that project. The game recently released worldwide for iOS and Android, and it’s pretty fun—check it out. He sent me a note thanking me for saying that my intervention, making the team realize that what they were building wasn’t fun and needed serious work on the core game and engagement, was one of the most valuable things anyone had ever done for the project.

Yeah, that’s great. You were the little kid.

I was. I was the emperor’s new clothes guy. Like, "That game is naked! I can see stuff I shouldn’t see on that game—that’s not good."

Well, I think having an experienced hand like you give an outside perspective on a product in development can be incredibly valuable.

It helps. It’s one of the services I provide for teams—just looking at a snapshot of where the game is, regardless of where it is in the development cycle. I’ve done this with live games, prototypes, games in production. And often that’s the beginning of a longer relationship, where I work with the team more regularly throughout their development cycle, help them mature their processes, and teach them some of these tools and rubrics.

Ultimately, what I’m trying to do is, over time, get the team operating at as high a level as possible so that they can then unceremoniously boot me out and force me to look around for new customers—because they’ve downloaded all that wisdom. But it’s amazing how many times it just starts with me going, "Yeah, the game is naked, guys. Sorry."

I’ve had to do that too. And you’re somebody I’ve gone to when I’m looking for wisdom on a project.

Well, I’m kind of an omnivorous guy. I try to study what’s working in the marketplace, look at the prior art out there. And over time, I’ve wound up with 700 board games in my house, and I think I’ve led production or design on 50-plus video games. I’ve now consulted on dozens and dozens of others. So, I’ve got this massive library of things that work, and I’m often able to slot those in.

I have a friend who works in the investment consulting space—games are one of two or three sectors he covers. He does a lot of due diligence for investors and helps companies trying to raise money. What he says is that he’s got three decades of painful mistakes in his bag of experience, and now he’s really skilled at pattern matching.

Yeah. So, by the way, just as an aside, my use of the Emperor’s New Clothes analogy is when, as a producer doing external development, you get into a situation where the executives at the publishing company and at the development studio agree to ridiculous schedules and budgets. And they do it because it benefits the studio just to have the relationship and the deal, even if they know it’s not going to work out on that schedule or budget. And, of course, the publishing execs are often looking for what they think is the best deal they can get. So, it leaves the producer in the position of the kid saying, "This is not realistic," and everyone’s just winking at each other.

Yes. Yeah, absolutely. I’ve been in those situations as well, and unwinding them is always painful. That’s what leads to the "come to Jesus" meeting.

Right. But sometimes maybe that’s all part of it.

Sometimes, what’s all part of it?

Like a project may just need to get started with a wink and have a "come to Jesus" moment later.

Oh, yeah. You know, the more games I make, the less I am fond of starting games with what I know are unrealistic premises.

I personally really don't enjoy it.

Yeah, no, it's not fun. In fact, one of the things I got into the habit of doing as a producer, when I was doing some external stuff, was inserting some cushion between my budget and my contract.

Because in my experience, a really well-managed and well-thought-out game goes over budget by about 20 percent. On average, it’s about 50 percent, and poorly managed ones go over by a hundred percent or more. I ran things pretty tight, so I just tried to give myself a 20 to 25 percent buffer.

Right, right. But it gets complicated, right? Because a lot of people add buffer. So then this average of 20 percent—does that include the buffer? And it’s happening up and down the chain. So if you ask an engineer for an estimate, are they including buffer? It’s a funny, and very personal, thing to know how to schedule specific groups of people.

Yeah. One of my favorite little bits of extreme programming, which came about right after the Agile manifesto was written—there were a bunch of tightly defined and, honestly, kind of rigid Agile methodologies that arose. One of them was called Extreme Programming, and they had some tenets I didn’t particularly care for. For instance, every line of code should be pair-programmed.

Right. I remember this. I think the programmers were supposed to sit next to each other in some specific way.

Yeah. Basically, at any given time, one programmer should be coding and explaining what they’re doing to another programmer, who’s sitting over their shoulder, listening and offering feedback. For what it’s worth, for super tricky bits of code that are hard to get right, this is still valuable. But for every line of code in a project, it’s just overkill. But they did have a nice tool as part of that Agile methodology that focused on person-by-person velocity measurement. The idea was that for each person on the project, you record what their task estimates are and what their actual task times are.

Not to be punitive or create trouble in a performance review, but more to acknowledge the truth. For example: "Warning, truth ahead—Dave is a terrible estimator. Things always take, on average, 30 percent longer than he thinks they will." Then, in the future, whenever Dave turns in an estimate, you mentally mark it up by 30 percent.

Yeah.

Whereas you say, "Jordan’s a sandbagger, man. He always gets it done in half the time he tells us." Then, in your internal accounting, you cut Jordan’s estimates in half. Because I know you're like that, man.

I don’t know if that’s a compliment, but I’ll take it.

Ha ha ha! It’s actually a really useful measure. And really understanding the proclivities of your team is important. What I will say is, even if that padding does go all the way up the chain, the padding goes up the chain because it tends to get consumed. Games are really hard. They’re less predictable than non-game app development. They have colossal non-functional requirements you have to account for—which is to say, they have to be fun, and they have to monetize. Getting all that stuff right is hard. And in a red ocean like free-to-play mobile games, you really have to get it right. You really have to get it all right.

That is a red ocean. That ocean is so bloody right now.

Yeah, I definitely feel it some mornings.

Well, I know from my experience working with you, and it’s clear from our chat today, that you're a great person to bring wisdom and processes to the development of these sorts of games. I’m curious, as we kind of close out here, where do you think the new opportunities are? Where’s the blue ocean in the industry, in your mind?

Well, that’s an interesting question. I will say, if you're looking for the gold rush, by all means, make some VR titles, because the funding environment over there right now is kind of stupid. There are a lot of investors spreading a lot of bets on the table, and there are a lot of platform providers willing to take a bath in order to get software made for their hardware—because, ultimately, software sells hardware. So, if you’re looking to fund a company that might implode in two to three years, I would totally do VR.

As for things that I think are a little more interesting and durable—let me put a little caveat on this: I’ve done a lot in my career by being able to see what the next kind of down-market platform was going to be. I spent years building kids’ games, then games in browsers, then games on Facebook, and now games on mobile.

The crystal ball on the next thing right now is cloudier than it’s been in a while. We’ve kind of been on mobile as the dominant platform. I have a couple of ideas about things that may be next. On the sideways side of the market, not the down-market, I actually find AR pretty interesting.

Yep.

Just the idea that you don’t have to be fully immersed, you don’t have to unplug—you can be in the world and gaming and enjoying. I think that’s a really compelling idea.

You’ll certainly look a lot less foolish doing AR.

Maybe. Tell that to Google Glasses. No, I think there’s potential to do interesting AR stuff that doesn’t make you look like you're in a scene from Tommy.

Have you seen the Snapchat glasses?

No, I have not, actually.

They launched, like—I mean, I haven’t seen them in person—but they just launched a sort of Google Glasses kind of thing to record snaps.

Oh man, you're going to make me do a web search while I'm talking to you on this interview.

Check it out. They’re trying to make it cool. They’re actually trying to make that cool.

For what it’s worth, I do think VR games may arrive at some point, but it’s a number of years out. And it’s not going to be until non-game VR applications have pushed very, very deep.

Oh, that’s interesting.

So, yeah, dude, like, let’s go to Paris.

Or let’s go home shopping.

Let’s go home shopping. Let’s redecorate. I’m going to put on my glasses and start moving furniture around the living room. But I think, ultimately, AR is probably the better play in most of those spaces—or many of them.

But do you think that’s pretty far off too? Because it seems like that’s a pretty big lift technologically as well.

Yeah, I do. But I think, over the long term for gaming, it feels like it’s got a little more potential. The trend I see in gaming is actually toward less immersion, shorter sessions. And VR is all about plugging in and tuning out.

I’m really interested in how the sort of game market for wearables evolves. This is another place where you think about your Apple Watch—you have it for other reasons. It’s there to give you notifications on SMS, but if you can enjoy a little bit of light gameplay with it as you go, I think that’s super interesting.

Personally, I’m really fascinated by what kind of games you can do that are really, really concentrated in audio. One of the things I’m noodling on right now—so I’ll just tell all your listeners so someone can beat me to the punch—is working on designs for a game that you play entirely using audio via the Bluetooth stereo in your car.

I know that Grossman is doing some work in that space.

I know a little bit about what Day is doing, and the creative direction I want to take is quite different from the really narrative-focused stuff that he’s doing.

Interesting. Well, I’m very curious. I don’t know how much you can talk about that.

Probably about as much as I did.

Well, when you’re ready, we’re going to have you back.

Yeah, we can talk about that a little more offline. And hopefully, when I have a team and a little bit of money to explore that idea, it’ll be a great time for a follow-up conversation.

Sounds good, Dave. It was great having you on the show. I love hearing your thoughts and your wisdom. Always appreciated. Thanks for coming on.

Jordan, it’s been a pleasure. Thanks so much for having me. I look forward to working with you in the future.

If you enjoyed this episode and my interview with Dave, please consider supporting the show. It’s very easy to do, and it’s free. All I ask is that you head over to iTunes, Stitcher, Google Play, or wherever your podcasts are not sold, and subscribe. Write us a review, and tell me what you like about the show and what you’d like to see in the future, because the show is here for you.

You can also reach out to me directly if you have any questions about any of the topics we’ve covered—jordan@brightblack.co. You can find links on the blog, which is playmakerspodcast.com. There, we’ve got a blog post with all the links to everything we talked about on the show.

So, for example, all the designers mentioned, the games, the companies—anything else relevant from the interview with Dave—you can find it there. Check out playmakerspodcast.com, where you can do everything: learn about the guest, get the links to what we talked about, and also subscribe and find us on all the major platforms. So, that’s playmakerspodcast.com.

And with that, I will sign out and see you next week. Thanks for listening to Playmakers.