Sharpen your sword as a game designer
Peek inside the creative mind of Eric Zimmerman – a multi-talented game designer, educator and artist who never stops innovating. A self-described Play-Test Fundamentalist, Eric teaches at the NYU Game School and co-creates innovative experiences on the sides. Eric is a true industry visionary – always ahead of his time. What does Eric thinks about teaching, playing and creating compelling and meaningful games: Listen in.
More on Eric Zimmerman
Eric’s Website: EricZimmerman.com
Eric’s Game: The Metagame
Eric’s Book: Rules of Play
Connect: LinkedIn @zimmermaneric
About this episode
[Amy Jo Kim] We’re really thrilled that you’re here with us. Eric, for those who don’t know you, give us a whirlwind tour of your background. How did you get started and how did you decide what to pursue along the way?
[Eric Zimmerman] Well, I’ve been working as a game designer for the last 20 years or a little bit more than that. I started mostly in the online gaming world, so this was before the indie games era. People didn’t use that term very much, but we were making small scale independent games for browsers. I had a studio called Game Lab that I co-founded with my partner, Peter Lee, that we founded in 2000, and we made a variety of games for browsers. Some of them were for big websites like Lego.com. We made a lot of the classic Lego games like JunkBot. Other times we helped invent what are now called “casual games,” although I don’t love that word, casual, but we made games like Diner Dash and that helped spread the idea that games were something that not just hardcore gamers could play, not just sort of young white dudes but all kinds of people could play games.
During my time at Game Lab we spun off a sister nonprofit company called The Institute Of Play. That nonprofit is still around and thriving and it’s created public schools in New York City and Chicago where the entire curriculum is based on games and play as the model for learning. While my company, Game Lab, was really a commercial enterprise, The Institute of Play is a nonprofit that looks at games at learning. During that whole time I was a game developer, I also taught at places like New York University, MIT, School of Visual Arts, Parsons School of Design, but in the last several years I’ve actually switched over and become a full-time academic. I don’t know if that means switching over to the dark side of the light side. Just the other side.
Now I’m a full-time academic. I’m a professor at the NYU Game Center here in New York City and we have an amazing MFA, Master of Fine Art and a BFA program as well that’s focused on game design and game development, game scholarship. If any of your listeners are passing through New York City, definitely check out our events. We have lots of speakers and events and workshops going on. As an academic, my research is just my creative stuff that I like to do. I am still making video games, tabletop games, and most recently I’ve been collaborating with architect, Natalie Pozzi. She and I have been doing large scale museum installations for museums, galleries festivals, that are mostly non-digital. They’re just large sculptural games that you ply with your body and with other people in the space.
I guess I’ve had a long and varied career. What motivates me, I think, is just inventing new forms of play, and in that sense I’m easy. I sleep around a lot. I’ll make a tabletop game. I’ll make an indie video game. I’ve made massively multi-player online games. I’ve made retail box-packaged good games back in the day, and now I’m just doing whatever kinds of games interest me.
What kind of games do interest you, Eric?
Well, I am really interested in … I guess it varies from project to project. A lot of it varies from who I’m working with as well. When I’m working with Natalie Pozzi, the architect, I’m learning so much about space and light and form and how people engage through each other, through their bodies in a real live actual social space. I just have a new game out called The Metagame this year that is a card game I did with Local No. 12, Colleen Macklin and John Sharp, and that game is kind of mixing and remixing culture as a field of play. It’s a game where you share your opinions about culture, and that’s really different, too. It just completely depends on the game I’m making and what interests me.
You’ve been a hands-on maker for a long time and you’ve also been a teacher. What prompted you to start writing and speaking about game design along the way? What were the issues that first came up that you really felt compelled to share your perspective on a wider stage?
Well, Amy, I started designing games in the ’90s, the early to mid ’90s, which I think is the same kind of generation as when you started working in the industry. At that time, I had actually been trained as an artist, as a painter, and I thought, “Oh, well, I’m entering into this new field of games, and of course there’s going to be these whole theoretical vocabularies to learn and schools of thought about what is a game and what isn’t and what’s a right way to design a game and what isn’t?”
Today, of course, all that stuff does exist. We have lots of intense online debates about what game criticism should look like and what are the right ways that game designers should think about what they do, but 20 plus years ago, none of that existed. Even though games are an ancient form of human expression and we can go back tens of thousands of years to the earliest board games and sports from ancient Egypt and Africa and Asia, on the other hand, game design as a field has really only come into being in the last decade or two with the explosion of digital games.
What led me to teaching was teaching became a way for me to really understand what was I doing. If game design was a field like architecture or graphic design, other design fields, what are the concepts that we would use for understanding what a game was, how it functioned and what it meant to design meaningful play for players. I would say I still teach because it makes me a better designer. Teaching for me and speaking and writing, it’s all part of my practice as a game designer.
For example, “Rules of Play,” the textbook that I wrote with Katie Salen, that was also a part of just trying to understand, “Hey. There isn’t really a textbook for game design that exists, but maybe if we wrote one it would help us understand game design better.” The teaching that I did starting with Frank Lantz at NYU in the ’90s and through today I do because it’s my way of sharpening my sword. It helps me stay sharp and fresh as a game designer.
That’s fantastic. Eric, following up on what you said, you’re one of those amazing people … I have to just tell you up front how much I admire you. You and Tracy Fullerton at USC and Jesse Schell at CMU, you are all teaching and helping to run the top game design programs in the county, and you’re also creating on the side. That’s just a lot of giving to the world and a lot of personal creative energy. You’ve been in the position of bringing many, many new ideas to life. As you said, you’re always looking to innovate with new forms of play. As you’ve done that, box products with teams that are building online games, with your students that you’re helping build their own games, what are some of the most common mistakes that you see first-time creators make in the early stages of designing and testing their ideas?
Well, that’s a big question, but I’ll try and answer it. I have been called a play-testing fundamentalist because I really believe that play-testing as early as you can is the key to game design. We do have some caveats and maybe we can talk about that, but in general, I think the biggest mistake that people don’t do is they don’t rely on an iterative process where they do rapid prototyping and they base their design decisions on their experience of the prototype. There’s often an idea when people are entering into an industry for the first time, whether it’s they want to make fill-ins or write a book or make a video game, that somehow the idea of the game, the concept behind the game is the main thing. Once you have that concept, well then, you know, just executing the game is the matter of crossing your T’s and dotting your I’s, but really, it couldn’t be further from the truth.
I really think that any idea is a valid starting point. The actual design happens once you start building the game and play-testing it, seeing what the prototype is trying to tell you about what’s working and what’s not working in the game. The only time when an idea in and of itself might be sufficient is if you’re doing a complete copy of an existing game, because then you don’t have any uncertainty about the way things are going to play out, but the more innovative, the more you want to mix and match genres, the more you want to try out new ways of telling stories or new forms of player interaction or new kinds of social relationships among new players or communities that you want to form, the more you want to innovate, the more essential it is to play-test and prototype, because you just don’t know in advance what’s going to work and what’s not going to work.
In fact, one of the pleasures of play-testing is seeing all of your brilliant ideas shattered on the rocks of reality, but if you can learn to enjoy that painful process of coming to the truth about your design, through play-testing, then you also can take advantage of it and learn to benefit, for example, from happy accidents that can occur during play-testing or collaborate with your players as they play-test your games and gain from their insight and wisdom into your own design process. I can’t emphasize it enough, but I think one of the big problems with the start is that people overemphasize the idea. Then they just want to iterate on what’s the best idea. Let’s argue in the abstract about whose idea is working. If I have a group of students and they’re arguing about whose idea is better, I say, “Okay, you know what? Everyone go make a prototype. Come back here in 15 minutes and we’ll try them out.”
I actually teach game design off the computer so that everything is a tabletop game or a physical game or a social game so that people can quickly prototype and iterate ideas. I understand it’s harder to do that once you move to a digital medium, and of course we have plenty of video game making classes at NYU as well, but the fundamentals courses are all off the computer, but I would say that, to me, that idea that you just want to play-test early and often is very essential to my approach.
Awesome. I love it. It’s central to mine as well, and so I think you and I have had some parallel experiences that led us to that realization, which is you get better results that way. It’s really that simple. Building on that, Eric, can you take us through how you approach early testing and iteration on a new project. Perhaps on something that’s fresh on your mind or something you’re planning, using that same approach. Let’s say you’re working with a group of students or you’re working with a collaborator on an art project or a museum project. How do you then do that early testing and iteration, and in particular, how do you filter out which ideas to pursue and which to cast aside as you’re doing that?
Well, think that the challenge of the earliest play-testing it’s about the strategy of how can I squeeze down what might in the end be a big game into a tiny prototype. For example, how can I take a game that’s going to be played by thousands of players and make it a prototype that maybe a handful of players can test the core mechanic, or how can they take a game that’s meant to last for hours or days or weeks and do some kind of quick prototype where I can turn around to play test in 15 minutes or half an hour?
It’s really about identifying the core of the game that you want to begin play-testing and prototyping that you have to be very tactical and strategic. There is a game that I did in 1999 called Sissyfight 2000. It came out I guess a year before 2000 with word.com, and that was an online game that was a browser-based social game about little girls on a playground in a horrible social contest where they’re trying to reduce each other’s self esteem. I should also mention that it was very much a feminist intervention into video games if you think that sounds like a cruel portrayal of girls, in this case, since they’re little girls on a playground.
In any case, I don’t mean to digress, but Sissyfight was a highly social game, three to six players in a browser chatting with each other, interacting in real time. The first version of that game we played with Post-It notes around a table where I was the computer and people were sending in their moods to me and I was quickly passing out the results of what everyone else did. The next prototype that we had was a text-only one that we played in an IRC chat channel with some very skeletal logic, so that we could just get the sense of people sitting at their own computers interacting in real time in this turn-based social game. After that, we started having very ugly-looking prototypes of the game that slowly evolved towards the final look and feel, but the entire development process we always had a working version of the game that we could sit down and play and that helped instruct us as to how we wanted to develop the game further.
I think in the early stages it’s about really strategizing about how you’re going to quickly move out of the clouds of pure abstraction and conceptualizing them into a prototype, so before you write your big design document, write a prototype spec. Write the minimum stuff that’s going to get your programmer building an actual playable version of the game, even if it’s ugly and very, very simple.
Yep. I could not agree more. Again, I’ve learned that through painful experience of what happens when you don’t do that.
I don’t know if this is going to be a kind of podcast where you and I go point, counterpoint. I think it’s going to be more like a happy fest of two people agreeing with each other.
Well, then the other thing I’m all about that I love to learn from you and to share with all of you out there is the hot tips and tricks, the shortcuts. On that note, along the way, since you and I vehemently agree about prototyping and about low-fidelity first, keep it very quick and dirty and easy to change and low-fidelity. Figure out how to learn the thing you need to learn, all that stuff. How do you actually do that? Then it comes to, “Well, that sounds great.” Let’s say, somebody says, “Great! Okay, well, give me some concrete tips and tricks and hacks to do that.” What do you offer? Obviously you teach, so you offer that, but what are some of the things you wish you had known ten years ago that you now teach your students and how to do that well?
I think that there’s kind of specific tips and tricks, but I think that the most important thing to get play-testing right is an attitude. It’s an attitude towards the idea of play-testing. What I mean is that I feel that design makes us better people because, for example, to design something you have to put yourself in the shoes, in the place of another person and think about how is someone who’s never seen this game before going to learn how to use the controls and interface. How are they going to adjust to the difficulty curb that I’m designing, et cetera.
Design is an intrinsically humanizing discipline on many levels, and I think in play-testing as well. I feel that when you play-test what you’re doing is giving yourself an opportunity to expand your ego and your sense of self beyond just yourself, that you can expand your sense of authorship to include your play-testers, and that, for example, this whole idea of valuing the brilliant genius idea over everything, I think it’s more important to value the process at which you’re making something. There’s a lot of ego in this idea of I have a brilliant idea and there’s a creative director on a team and the team is just there to implement the genius visionary’s idea, and I think that’s the opposite way that’s worked for me in the past of how games are developed, that games are a team effort, that anybody can contribute ideas, but even more significantly, that a game is about a collaboration between you and your audience that you find and use as you begin play-testing your game and moving forward.
For example, collaborating with your audience and taking their ideas from your play-test, even as you’re realizing that your great ideas are not working but what could work and listening to them. I think that a lot of it is about having an attitude towards play-testing. Like I said, to me it’s something which makes us better people. A lot for me about a play-test is in addition to just how do you get strategizing given your game, and I don’t think there’s any silver bullet. I think it’s part of the design challenge. What is the core interactive risk or innovation that our game is making? What is that core interesting thing that we’ve never seen before in a game or interesting mix of existing mechanics? Let’s just strip them down to their essence and just put it in a game. If it’s multi-player, can we do it with single-player? If it’s supposed to be in a 3D world, can we do it in a 2D world? Just always simplifying for that first prototype. Then, once you actually have that prototype, I feel that you want to kind of spiral out to your audience.
Actually, Amy, I don’t know if you and I agree with this, but I always say, “You always start with you and your team as the initial testers. Then it might be people in your office that you’re pulling over to play,” and as you move forward in the development of the game, you want to move towards the kind of people that are your actual audience. Especially if they’re very different than you. If you’re designing for kids, you want to get kids in playing your game of the appropriate age as soon as possible. You learn from that process of kind of spiraling outwards towards your core audience. Later in the process you probably want to be much more rigorous about finding people that really represent the audience that you’re game is intended to be played. I would also say that there’s a lot of stuff …
For me, that moment when people are playing your game, preparing for that moment for the play-test is very, very important as well. You always want to know going in what is the question that you’re hoping your play-test will answer. You always need to be open to discover stuff you never expected to have a play-test. You also really want to be focused and say, “Why are we making this prototype? What is the question that we’re hoping that this prototype begins to address?” Not that it’ll answer it fully, but you should know about that. I also think it’s important to always have a generous attitude towards your play-testers. Your play-testers are people that are donating their time, unless you’re paying them. That’s a different situation, but for a lot of indies, it’s going to be people that are donating their time to play, basically, with a broken game.
That, to me, is an incredibly generous action that someone is doing to help you out and to help you develop your game, and always think that you need to be as generous as you can to them, to thank them for doing it, to let them know that if they’re having trouble, it’s not their fault. It’s your fault as a designer. I think as they’re playing your game, you want to observe. You don’t want to interfere. I think maybe the number one thing that I always see my students do is if someone is having trouble, it’s very hard not to rush in and help them out, but it’s so important to let your play-testers struggle to learn how to play your game and to overcome the challenges.
If things totally break down, of course go in there and help them out or change things, but for me, this is the meditation under the waterfall moment of play-testing, is to watch your play-testers having a huge amount of trouble with your game and just observe and not interfere. Because as soon as you start telling them what to do, suddenly the play-test isn’t about them anymore. It’s about you. The whole reason why you’re play-testing the game is so that you get someone else’s point of view. You always want to keep yourself apart from the process. If they ask you a question and you’re standing there, I always say answer a question with a question. If they say, “Well, what does the blue button do?” ask them, “Well, what do you think it does or what do you think it should do?”
Always try and get your play-testers to themselves own their own experience rather than you trying to tell them what to do, and it’s much harder than you think. We all have an instinct to want to rush in and help people because we feel horrible when our play-testers are having trouble with our interface or learning the keys or solving a particular problem. You should also take notes on everything that you can. You should prepare a notes sheet in advance. I like to write by hand instead of typing on a computer in front of someone, but that’s up to you and varies according to the setup that you have for your play-testing.
I think it’s really important to think about what you want to take notes on in advance and then taken notes during play-testing because otherwise, you’re going to be at the mercy of your own selective memory and you’re going to rewrite history to make things seem better than they actually were. You really want to remember where people had trouble and where their problems were. You want to take notes on what their emotional responses were at certain points in the game, how long they took during certain times.
Now, of course, if you’re working in software, you can build in data collection. You want to be very selective in your data collection. You don’t want to collect too much data, because then it becomes difficult to know what’s good data and what’s not good data. That’s why it’s important to have a very focused research question for a particular play-test, because it can also help you focus on what’s the data that you want to collect. In any case, you should always take notes on what your players are doing so that you don’t end up with what we call the “happy face syndrome” in some of my teaching, and what I mean is that it’s easy just to remember the fun, happy moments when your players were having a good time and let those memories override all of the pain that your play-testers were having. That’s why you want to be really cognizant of that.
Pay attention to your play-testers, not just what they’re doing but their whole body language. When are they leaning in towards the screen? When are they leaning back? When are they engaged? When are they not engaged? Sometimes that’s easier for tabletop games. If it’s not their turn and they’re texting on their phone, well, you know that your game is failing to engage them at that particular moment, for example. Even though I try and teach my students not to interfere during the play-test, after the play-test, of course, you want a dialogue with your players. You want to talk with them about their experience. I always like to start with very specific questions. “Tell me about how this system in the game worked. What did you think of this character, this moment, and end with more general questions. Things like, “What was the most fun of the game? What would you change about the game to make it better?” and give them an opportunity to give you open-ended answers as well. There’s a lot to say, but those are some of the tips.
That’s fantastic. For you personally, Eric, you clearly can help many different kinds of people building many different kinds of games on many different platforms. You’ve worked in so many different areas. For you personally, what’s your super power as a designer, as a creator? What’s your sweet spot? What kind of projects really light you up?
I think that my strength as a game designer is generating concepts for games. This is going to sound contradictory because I just was recommending that we devalue the idea for a game, but I think that my strength as a game designer is generating ideas and then moving to a prototype as quickly as possible. Usually when I’m thinking of an idea, a solution to a game design problem, I’m always thinking about, “Well, what’s the prototype that could help solve that problem?” As a game designer, I’m not a visual designer. I’m not a programmer. I’m more of a pure game designer in the sense that I really focus on the player’s experience and the rules of the game, so to speak. I really also feel like I have to pull my weight and be able to think structurally and in terms of systems and what are the systems that we can create in order to pull together a prototype.
That’s so interesting because one thing I’ve noticed as I’ve talked to many more game designers through recording this podcast is that there’s so many different types of game designers and people start from a different place. Some people start with narrative. They’re centered in narrative, and when they start to design a game or whenever they do a personal project it will be narrative-based. Some people start with systems.
I’m a system designer, so I always start with systems and player experience, as it sounds like you do because that’s my background, and it’s also my nature. Often I’ll be paired on a game with a great narrative designer or a great visual designer, and then some people that approach game design might start with something else. They start with like a core mechanic that they just want to explore and they go from there. Have you noticed that too?
Oh, I totally agree. I definitely think that game design is such a great field because it’s so varied and there are so many ways to approach what we do as game designers and starting points for our creative process. There are game designers who are more like economic numbers, gear heads who love making spread sheets of their virtual economies and balancing them that way. There are game designers that really focus on the social interaction between players and just have a great sense for how human beings interact with each other. There are other game designers, I think, who are just really smart about pop culture, and their strength is just thinking about “How does what I’m going to do fit into this larger landscape of media?”
Then there are game designers that are just really in tune with their own sense of pleasure and they can follow it like a dowsing rod. They can follow it towards the fun and they’re really in tune with what’s fun and what’s not fun about a game that they’re working on. I’m more of a systems designer, but I think that it’s wonderful how many super powers different game designers can have.
Absolutely. Eric, what’s on your horizon these days? What are you paying attention to? What’s coming up for you?
In terms of my own projects, I would say The Metagame is one that I am spending a lot of time on now. I mentioned it before. It’s a card game that I did with John Sharp and Colleen Macklin, Local No. 12, and it is a tabletop card game. It’s a little bit in the Apples To Apples, Cards Against Humanity genre. In fact, it was one of the inspirations for Cards Against Humanity several years ago, but this is a game that we’ve recently published and you can look for it online. The Metagame. It’s available on Amazon and we just launched some expansions for it. I’m really enjoying being a little bit in the tabletop world in addition to the video game world.
Awesome. You can also find links to The Metagame and to Eric’s personal site and the NYU program in the episode notes. Thank you so much, Eric, for joining us today and sharing your wisdom and your experience and your insights about the power of play-testing.
Thanks, Amy. It was a blast.