Game Design as a Way of Being, with Eric Zimmerman

Jordan: 00:00

You know what those swoopy sounds mean. You're listening to Playmakers. I'm your host, Jordan Blackman, and on every episode, I interview a game industry legend, leader, luminary, or some other L word. And I go deep with them on a subject of their expertise. This week, Eric Zimmerman, CEO and co-founder of GameLab—they created the iconic Diner Dash. He also teaches at NYU, and we get into it. Stay tuned.

Okay. You're not really supposed to do lip smacks—that’s not good podcast etiquette—but we're keeping it in. We’re doing it live. This is Episode 7 of Playmakers. And if you don’t know by now, I’m your host, Jordan Blackman. On every episode, you know what I do—I interview someone who is a playmaker, an expert in the game industry, and I learn from them. By subscribing, you learn along with me.

This week, we have the great teacher, professor, and game designer above all, Eric Zimmerman, who’s taught at MIT, the University of Texas, Parsons School of Design, NYU, Rhode Island School of Design, and the School of Visual Arts. He also co-founded GameLab, the groundbreaking indie-ish studio that created Diner Dash. Eric is deeply embedded in the New York game scene, and we talk about that. We talk about the story of GameLab and what it was like to be part of that scene, and to actually design that company. We talk about design as a way of life and what that means to Eric.

On this show, a big part of what I do is bring on people and ask them for tips, tricks, tools, tactics, frameworks, and processes—things that will help you get better at what you do. Eric pushed back on that a little and said, “Hey, you know what? It’s not really about any of that stuff—it’s about being a certain way in the world as a designer.” So we talk about that too. He also explains how he designed GameLab to be a place where the people who worked there felt ownership and authorship of the intellectual property they were creating. How did he create a studio where people were able to collaborate and feel like they had agency, but didn’t feel territorial or defensive? All of that is in this episode in my interview with Eric.

And, gosh, as we were ending the interview, I was immediately thinking, "I want to interview this guy again." So, enjoy the interview, and I will see you on the other side.

Thanks for coming on the show, Eric.

Eric: 02:43

Oh, I'm really happy to be here. I'm always happy to talk about games.

Jordan: 02:46

I was really interested in having you on the show because you've done so much work both with indies and in academia. For our audience of people who are mostly indie developers, corporate developers, or students, how would you contextualize the value of the academic game world for that group?

Eric: 03:04

Well, it's kind of funny the way I ended up in academia. My parents are professors, so I do have to say it's a little bit my cultural background. I grew up as a campus brat in Bloomington, Indiana. My parents taught art education there. But I'll also say that coming of age in the industry in New York City, it's a very particular place.

New York has never had a big triple-A production studio where people worked. I started in the game industry in the early ‘90s. It was really in the CD-ROM era, but again, there weren’t major development studios in New York City. There was never an Ubisoft or an Origin or something like that in New York.

Jordan: 03:49

I think of Gameloft as the closest thing.

Eric: 03:52

Yeah, but even they were doing kind of mobile and online games. So there’s been a lot of smaller platform work, a lot of ad agencies. There’s a lot of content companies here like MTV and Fisher-Price or Sesame Workshop. And there’s been a lot of freelancers and people doing experimental work. So just to say that New York City game designers, for the last 20 years or so, we’ve kind of had to cobble together our careers. In a sense, we were all sort of indie before indie started. I remember writing an essay around 2001 called “Do Independent Games Exist?” and this was like five years or so before indie games became a thing.

arted our studio, GameLab, in: 2000

h was, I don’t know, around: 1993

For example, I was actually trained as a painter. As an undergrad, I studied painting. In painting, I got this very formalist training. They have ways of teaching you about line and color and composition and visual thinking, and there’s kind of a standard set of classes. Then there are people who overthrow that—there’s kind of schools of thought about what it means to be an artist, and obviously, that changes from decade to decade and century to century. But there’s kind of these battling “-isms,” right? Like modernism, minimalism, conceptual art—all of these different schools of thought are kind of battling it out.

Today in games, we have a little bit of that, but back then, in the ‘90s, it was more like people were just kind of working in the industry, and there wasn’t the same kind of complicated discourse that bridged the theory and practice of what we were doing. There weren’t books coming out, and there weren’t conferences other than very industry-oriented ones—like, "Here’s how to make games," or "Here’s the business of the industry." It’s not like today where you have conferences on games and learning, or reaching a casual audience, or academic conferences about games and players, or how games create meaning, and all these other things.

So, in a sense, we were really discovering this field of game design. When I was a painter, I felt like I was in a discipline—there was a disciplinary knowledge, a way of doing things, a language that had been refined, at least since the Renaissance when Vasari published Lies of the Artist and started talking about what it means to be an artist, kind of establishing our contemporary idea of art as a discipline. But in games, teaching with Frank Lantz at the Interactive Telecommunications Program, I was really figuring out what it meant to be a game designer in the sense of, what is a game? How do they function? How do we talk about what we're doing? How do we communicate to each other—whether you’re a designer on a team of other developers, talking to a publisher to get funding, or talking to a journalist to get them to write about your game?

Also, out of that, I worked with Katie Salen to write Rules of Play, which ended up being a textbook about game design. It’s still in heavy rotation these days.

Jordan: 08:04

I've seen it on so many, I've seen it on desk after desk in studios as well.

Eric: 08:10

To me, the book is really basic, but we were just trying to establish some basic concepts. So I guess here's what I'm trying to say to answer your question—being an academic for me was never like, "I want to be a professor." It was just like, "Oh, teaching a class helps me understand what game design is." Writing this book helps me clarify my thinking about what games are. So, even though now I'm a full-time professor and I spend a lot of time teaching and talking to students and being part of this academic community, I still think of myself as basically a game designer who does these other things. I teach classes in order to be a better designer. I teach in order to hone my skills as a designer.

I study martial arts. And my teacher, who's an amazing Kung Fu practitioner, teaches every day, even the beginner classes. And it's clear that for him, teaching is part of his practice as a martial arts practitioner. So for me, I also feel like teaching—and this is my own personal approach to game design, there are a lot of valid ways to be a designer—but for me, teaching, I kind of fold it into my practice. It helps me keep my sword sharp.

Jordan: 09:23

Well, I totally get that. I taught for about three years at the Bay Area Video Coalition, teaching beginning game design classes. And it was incredibly useful to me. I still, as I transitioned into mobile, found that I leaned a lot on some of the frameworks that I had taught students because it was much muddier waters, wading into some of those new territories. That's what I think I’m excited about learning from you— with everything you’ve studied and everything you teach, what are the pieces you feel like, "Ah, if more game developers understood MDA, or some other framework, some other way of thinking about game design," this is a good opportunity to discuss some of those ideas.

Eric: 10:13

You know what, it's funny. I used to think that there were kind of nuggets of knowledge that people needed to understand. If they just got, for example, the fundamentals of designing a choice for a player—that you have to present it in a way, they have to understand the outcome of what they did, and those choices are kind of the building blocks of making a successful game experience—like, things like that, these kinds of fundamentals and basic concepts.

But I guess I have a different feeling now. My feeling is that being a game designer is not about the knowledge that you have. And I think about design as kind of like a way of being—like a lifestyle choice, or something. It's a way of seeing the world. It's a set of practices that you do, a set of activities, some of which are making games, but some of which are how you approach your personal relationships, how you think about the environment that you live in, or how you think about the culture that you live in.

I see young designers falling into certain traps or making certain mistakes that I made, like thinking, "Oh, well, how do I make a game that's as compelling as a film?" because I love films, and films are stories. So, why can't my games give me the pleasure of film? And my answer to that is always, "Well, you never want to create one cultural medium or form under the shadow of another one." So instead of saying, "Why don't I have a game that tells a story as great as a film," you should say, "What is a story that I could only tell in a game that leverages the unique characteristics of games in order to tell a story?" So, that’s the kind of thing I think you’re talking about, like basic ideas and maybe fundamental concepts that would help designers avoid these pitfalls that we all fall into, or that a lot of people tend to fall into when they first start making games.

But see, now I'm not so sure. Because I used to think, okay, my job as a teacher is to help people avoid those mistakes. But maybe my job as a teacher, and as also a colleague, is just to help people as they stumble through that landscape, doing things like overscoping a project and then having to realize, oh my gosh, everything always takes longer, it’s harder to communicate, and I can't fix bugs in time like I thought I would. That’s just part of the process of learning how things work, and making conceptual mistakes, like misunderstandings about narrative and film.

Maybe everybody has to work through those issues on their own, and that’s just part of what it means to grow as a designer. Or, in fact, maybe those misunderstandings result in amazing games. Because sometimes you have veteran designers that have been around a long time, and they make a crappy game, and sometimes you have some young buck who stumbles into an amazing design, and they come out with something spectacular.

So it’s not really clear to me that more knowledge is always better. Sometimes knowledge can be a bad thing. You can get so polluted, like, "Oh my gosh, I'm never going to have a new idea. Everything's already been thought of," or, "I need to think ten times before I make a decision because so many people have been in this space before." That can kill off the youthful vigor that might otherwise propel your overconfidence into something totally weird, experimental, and fantastic.

So, yeah, I guess what I’m trying to say is that I used to think I was providing knowledge to help people overcome these problems, but now I think everyone has their own journey. This is starting to sound kind of new-agey. I don't mean it like that, but everyone has to make their own mistakes. Making games, playing games, talking about games, and teaching game design are all just part of what I do as a designer. My students are there as well, and often I don’t think of my students as students. I think of them as other designers, and we're just doing stuff together. A classroom is just a situation, just like a development studio is a situation. There are different constraints—commercial, legal, bureaucratic—but in the end, it's just about solving problems. And I’m the one handing problems to my students to solve. That’s all I’m really there to do—hand them problems and help them see how their solutions are working and not working.

I mean, it’s a really good question you’re asking. But if there were silver bullets of game design knowledge that we could just shoot into people and suddenly they’d make great games, then the world would be full of great games, you know? We don’t think about music that way, right? It’s not like, "Oh, musicians are full of misconceptions. If they only understood what music is really about, then we’d have great music." Music is also about something that’s ineffable, right, something we can’t fully put into words. And I think games are the same. We’re talking about pleasure.

Jordan: 15:29

Well, I think you’re right that it’s the same, but I do think people make that same error, like, "Oh, what are the licks? If I could just get these guitar licks or these particular drum fills, that would make me a musician." Well, but what are the things that you think everyone is leaving out? What do you look around and say, "Oh gosh, here are the mistakes everyone is making that we should try to correct"?

I don't think there are silver bullets. What I'm actually interested in is going more deeply into what you mean by what it's like to live as a designer and that perspective, because I think that's super interesting. But I do think there are pieces of information that have had a big impact on me, that have been really valuable in my own design work.

For example, a layers-of-the-onion model of games has been super helpful for me in understanding what a core loop is and why it's important. Some ways that I can knock on it, tap on it from different angles to see if it has qualities that tend to make core loops effective. Is that something that's going to be true in all contexts and always? No. And some of those ways that I like to look at a core loop.

It seems like they work better in a mobile context than they probably would in other contexts. And I think, to your point, I can get stuck in those things in ways where they don't necessarily apply. I can enjoy Firewatch even though the core loop might not have much to it. But that designer went and made a statement with the way they're doing that game that worked. My feeling is that there's sort of an in-between space where we can have these useful tools; we just can't kind of worship them.

Eric: 17:13

And when you say tool, you mean like a conceptual model or framework that helps you think through a problem?

Jordan: 17:17

Yeah.

Eric: 17:18

Well, I guess I will say this. The way that I teach, and the way that Frank and I started teaching, the way that Katie Salen and I wrote Rules of Play, is that there's not one correct way of looking at games.

And what we have to do is we have to be able to put on a whole series of different lenses or frameworks or paradigms, or whatever you want to call them. Katie and I call them schema. And Rules of Play is organized with some schema that are around logic and math and cybernetic feedback loops and probability—more numerical, formal approaches.

Then there's a whole bunch that have to do with human experience. They have to do with emotion, narrative, psychology, social interaction, pleasure, addiction—a whole different set of schema. And then there's another one that has to do with cultural context: understanding how what you're doing fits into larger cultural landscapes or media, how it creates communities of players, how you might be falling into traps of representation around gender or ideology, or things like that. So that idea of different frameworks or different schema—some of them formal, some of them more experiential, some more cultural.

That's the most important thing, that as designers, we are flexible. You don't want to fall into just using one lens to look at games. It might be that your game is broken, and players don't like it because it's a two-person game, and the first player always wins. Well, there's probably a formal problem, right? You need to rebalance; you need to make the first player's turn half as powerful as a regular turn so they don't get a leg up on turn two, et cetera. But it may be that your players just aren't identifying with the main character. And that's a totally different, maybe more cultural issue. Who's your audience? Who's your main character? How are they connected? What's the psychology of that, or what's the narrative world you're creating? Those are totally different ways of thinking.

Now, to me, this is why I love being a game designer. Because everything you might study, read about, or think about is relevant. You can study science and math and logic, but you can also study storytelling, human psychology, and brain chemistry if you want. You can be an anthropologist or sociologist and think about culture that way. All of that is relevant to what we do as game creators. But the most important thing is to have our students be flexible, and for designers to be flexible. If you're only looking at things from a formalist point of view, or from a feminist point of view, and you can't pop out of that, then I think the design does start to suffer.

So maybe this is the best answer to your question: it's not one thing, but many things. It's the ability to be many things. I sometimes see designers who have a really interesting model, and they decide, "Everything is wrong with the game industry. It's all about competition, winning, and goals." So they've joined the "not games" movement or focus on walking simulators or pure interactive narrative experiences. And they say, "Down with games; games are bad." I love that. That's great. Have a position, like things, don't like things. But then to say, "Therefore, this is how everyone should make their culture," is problematic.

Therefore, this is the proper model for what being a game is. I call that design fundamentalism. When you have your own point of view, the same thing can happen on the formalist end. People can say, "Games are about mechanics and balance, and the content is just the surface. The only thing that really matters is what's underneath." An eSports player might stop caring about the narrative and the world, and all they care about is balance and interaction, et cetera. That's okay too, but then to say that's the only way isn't true. Not every game or every player's experience works that way. So, I think of these models and ways of thinking as tools—like tools on your bat belt.

Jordan: 21:29

Right, I was imagining it right there.

Eric: 21:31

Yeah, you can't use a batarang to solve every problem, right? If all you've been practicing is the batarang, but then you need your bat gas grenade and it's not there...

Jordan: 21:45

I think that a lot of working pros, myself included, get used to a particular tool belt because we're working on a particular genre or platform, or we've just been at it for a while. And I think... so what I feel like this is ultimately becoming is a giant advertisement for this podcast because we're going to bring lots of different ways of thinking to people, hopefully. Yeah. But I think that's probably the answer to the question I came here with, which is: what can academia offer? Well, it has all these—it has a rich vocabulary, right?

Eric: 22:18

Yeah. I mean, I think academia is not the right context for everyone. But I will say that it's wonderful for me, as a designer, to not have to make a living from my work and be able to do weird experiments.

So, for the last five or six years, I’ve been working with Natalie Putzi, who's an architect. She and I have been doing these large-scale museum installations that are games. They're not digital, they’re just physical games. Some of them are a little more like theater performances. Most of them are big sculptures that people play. Some of them are huge, like immense, inflatable things with people moving large objects. I could never do that if I was working at a commercial studio or running my own company. I mean, I don’t make money from them. We’re lucky if they break even. But they get shown around the world in different museums, and it’s amazing that I’m able to do it because I’m a professor. I teach classes here, but that's not full-time. My "research" is my creative practice, because we’re in Tisch School of the Arts at NYU. So that’s how academia is good.

And I should also mention one other thing: collaborating with people outside of games has really helped me. Just being with people who aren’t always game makers—you don’t realize how much you take for granted. Every time I start working with Natalie on a project, I’m like, "Okay, so people are on a grid, and they’re moving," and she’s like, "Why are they on a grid?" And I’m like, "Well, of course, put them in squares on a grid." She’s like, "I don’t like grids. I don’t like the way they look. They’re not going to be on a grid." And I say, "Well, they have to be in spaces, we have to know where they are." And she’s like, "Well, let’s try some other shapes then." So, we end up with these weird, organic, flowing patterns and things like that. We just take so much for granted as game designers—the idea of a grid. A grid underlies code; you start a 3D space with a 3D coordinate grid. But if that’s not your starting point, you end up somewhere different. So, that’s been one of my tools—finding great collaborators.

Jordan: 24:22

Any of those exhibits that people could check out?

Eric: 24:25

No, but you can go to ericzimmerman.com or Natalie’s site, knackworks.com—N-A-K-W-O-R-K-S dot com. They’re more like temporary exhibitions, so they’re not up permanently anywhere.

Jordan: 24:35

I was poking around a little bit online, and I saw on LinkedIn that someone had mentioned that GameLab was an incredibly well-structured company. I thought that was a really interesting comment, and it made me curious. I want to learn more about what that structure was and how it worked.

Eric: 24:53

Maybe that’s the best comment I could get on GameLab. I should say that GameLab wasn’t just me—it was Peter Lee. He and I were the two co-founders. He’s now living in South Korea, but he and I ran GameLab for about a decade. GameLab made mostly online games. Diner Dash was the one we were most well known for, but we did a ton of games. We did small games. We grew to about 30 people at our peak.

Jordan: 25:22

I feel like that was a very fundamental—and I don’t know it particularly well—but like a fundamental part of the history of the New York game scene.

Eric: 25:31

Well, that’s nice of you to say. I mean, definitely, when I look around at people who are running companies now in New York City, like Gigantic Mechanic or Playmatics, Frank’s company, Area/Code, where you worked, a lot of people came through.

Jordan: 25:45

I work with.

Eric: 25:45

Work with, sorry, sorry, work with. A lot of people came through GameLab. So, yeah, we were early. And it's not a huge scene here, so a lot of people passed through the company. I feel like I approached the design of a company kind of like a game. In the sense that, with a game, you're not really designing the outcome, unless you’re making an on-rails shooter or something that's very linear.

If you’re designing a game like poker or a fighting game, you’re just designing a set of possibilities. You don’t know how they’re going to play out. Essentially, game designers create rules, a context, and things for people to do, or set up potentials, and that’s what a company is as well. It’s a set of procedures, policies, a physical layout, personnel policies, work processes, and technical tools. And, as with a game, you hope unexpected stuff happens.

The sweetest pleasure for me as a game designer is seeing players do things with my games that I never could have anticipated. Like, "Oh my gosh, I never thought this social interaction would happen," or "this strategy," or "this way of cheating at the game." That’s genius. It puts the biggest smile on my face. For a company, that was my goal—this idea of innovation where you’re just setting things in motion and creating structures. The paradox is that constraints produce creativity.

Just like in a game, if you give people a blank piece of paper and a pencil, they might not know what to do. But if you make a tic-tac-toe grid, suddenly there’s something they can do. There’s a way for them to be virtuosic, or generous, or cheat, or be creative. Or they’ll say, "Let’s add some more squares and see what happens." Those kinds of constraints and structures enable creativity. That’s the way we approached GameLab, so I’m glad that came across to at least someone.

Jordan: 27:52

What were some of the actual structures? Like, was it kind of like an incubator, what we would call today an incubator?

Eric: 28:00

It wasn’t an incubator because we were a totally independent company doing mostly client work and some original stuff. We didn’t have deep pockets. So we were just hustling from month to month, trying to find new jobs and get them done. Get a job in, do it, get it out. We were hustling to make rent every month. I mean, we weren’t about to go bankrupt, but let’s just say I did business development, and I was always trying to bring in more jobs.

Once we had some successes like Diner Dash, it got a little bit easier. But as we grew, our overhead got bigger, and we had to support even more. In terms of company structures, one of the things I liked about GameLab is that we never had creative directors on projects. We had five to seven people on a project. There’s one thing I learned from this very old, musty Microsoft book called Project Development. It made the distinction between people who punch in, do their job, and leave versus people who feel authorship and ownership of a project—people who feel like they’re genuinely creating intellectual property.

The point of this book, which had some boring title like Managing Software Development—it wasn’t even a game development book—was that the point of designing a process is to give people that feeling of authorship.

What I realized at GameLab was that you can’t fake it. The only way to actually give people authorship is to give it to them. The worst creative situations I’ve been in—working with or for other companies—are when there’s a creative director with a big ego sitting on top of the project, seeing everyone else as extensions to fulfill their vision. No one else feels like it’s their project; everyone feels like they’re just a tool for this big idiot to use.

At GameLab, we never had creative directors. We never had someone sitting at the top. If you were doing audio design, that was your role and authority. You could make creative decisions about that. Now, that didn’t mean we ignored the client or the publisher—we had to please them, and we had to please the player most of all. But if there’s trust, respect, and communication, like in a good relationship, people don’t get territorial.

They don’t say, “Hey, stay off my turf. I’m the audio designer, don’t tell me what to do.” Instead, you get the opposite: “I’m desperate for feedback. Please help me integrate what I’m doing into what everyone else is doing. Tell me if it’s working or not. Let’s work together.” And guess what? I have ideas for you too—about the visual design and the game design. Even though it’s not my main area of expertise, I want to help.

Peter Lee and I really focused on the culture of the company. If you can create that feeling of collaboration, where people have authority but aren’t being territorial, an amazing process bubbles up. It’s like getting something boiling to the critical mass where ideas can come from anywhere. People are always receptive but still focused, with a very clear sense of their role. So it’s not just loose, unfocused collaboration.

When GameLab was at its best, I think we achieved that. We didn’t always achieve it—it was always a work in progress. This worked especially well for smaller teams. We had teams of three, five, or seven people for most of our projects. That’s what I mean when I say we were kind of like an indie studio before indie games were a thing. For those smaller teams, this worked really well. It’s probably totally different when you have a hundred or two hundred people working on a project.

But I’ve never worked on a AAA project. The biggest projects I’ve worked on had about forty, fifty, sixty people, but I’ve never worked on a really huge project like that.

Jordan: 32:11

What you're saying reminds me a little bit of how a band would work.

Eric: 32:15

Yeah, hopefully.

Jordan: 32:17

Ideally, yeah. If it works well, obviously it can go wrong in a million different ways.

Eric: 32:20

Right, right. So again, I don’t feel like there’s one solution to how a company should be structured, but I think a lot of people feel like, "Oh, we’ve got a good idea. Get some smart people in a room, and then you just make the thing." Or, "We’ve got a job, we’ve got a contract, now that's basically it. We get some chairs in a room, and we just start making the game."

I feel like you have to design the company. That’s what I feel people often miss. It’s like, "Oh, we have to think about our company culture. We have to think about the experience of people when they come in in the morning and when they leave at the end of the day." To me, it’s just applying design thinking to the idea of a company, because you’d always think about your players that way. You’d always think about, "How do they feel when they first see the logo and title? How do they feel when they first load up the game? Are we taking care of them? Are they having fun or not?"

You have to think about a company in the same way. Not that it’s all about fun, but it’s like in academia, same thing with conferences. People are like, "Oh, we’ll get some smart people in a room and put them on a panel." It doesn’t work that way. What makes a good panel? What makes a bad panel? You can have great people on a panel, but if the panel is poorly structured... well, they don’t have anything to say to each other because there was no prep work, no structure, no good moderation.

It’s the same with a company. It’s not just about getting good people in a room, it’s about creating enabling structures that challenge them, support them, and enable their collaboration.

Eric: 34:00

To me, a game designer creates the rules of a game, but then you don’t know what your players are going to do. With a company or a project, someone has to set up those structures, and the project that results—the actual game that gets launched to the public—is like the residue of a process. It’s like, "Oh, this creative thing happened, and look, this game was the result."

But that kind of goes back to the very first question you asked me: what’s design about, or what’s the thing that designers should know? For me, it’s that you have to think about what you do as a process and engage deeply with that process all the time. The games we make, our creative work, are like the skin we shed as we move on to our next form, the next thing we do.

We leave these games behind, and they’re good markers of what I was interested in then, what I was thinking about, and what that team was like. They’re problems we solved, but there are always new problems for me to solve, and that’s what I want to be thinking about.

Jordan: 35:06

And the beat goes on.

Eric: 35:08

Yeah, exactly. Sorry, getting a little prosaic.

Jordan: 35:12

No, it's all good. I was actually thinking the exact same thing. You're showing what you were talking about earlier, about how design is kind of a way of life and a way of being in the world, rather than just a bunch of rules. I think it’s a great place to leave off. I’d actually love to talk with you more about that process and way of life, but I think it's going to have to be next time.

Eric: 35:34

Next episode. I'll be back for sure.

Jordan: 35:36

Thanks, Eric. Thank you very much.

Eric: 35:38

Thanks, Jordan. Great talking to you.

Jordan: 35:39

Have a good one.

So, where do you net out on tools and frameworks and how they’ve helped or hindered you? It’s so funny to talk to a guy who writes Rules of Play and then says, "Hey, it’s not about the rules; it’s about the way of being." I feel like it’s one of those paradoxes wrapped inside an enigma—or maybe an enigma wrapped inside a paradox.

Eric also kind of reminded me of a Zen monk or a Buddhist monk. Some of his perspectives made me think of Buddhist stories, like the idea of "you destroy the raft when you cross the river." When you're seeking enlightenment, you're looking for wisdom, information, and knowledge. But once you’ve crossed into enlightenment, you realize the ladder or the raft that took you across was a lie—not unlike the cake in Portal 2.

I think that’s kind of the deal when it comes to frameworks, practices, rules, and tools. These concepts are incredibly valuable and useful, and the more of them you have, the better. At the same time, once you’ve mastered them, you need to be able to let them go. And that can be really hard to do, especially since they’ve probably served you really well.

Another expression in Buddhism is "the gateless gate."

You walk through a gate, and you turn around, and it’s gone. I think that’s a bit of what it’s like to master your craft, whatever that may be—whether in the game industry or not. So, I wish you an enjoyable journey through your gateless gate, and I’ll see you on the next episode of PlayMakers.