I recently finished a six month project at SMU Guildhall where I was working as the Game Designer. Since I’m in the graduate program as a producer, and since I’m much more experienced with project management than with game design, it was a very enlightening experience for me. I certainly learned a lot about being a game designer over the course of those six months, but I think my favorite takeaways are those that will enable me to perform better as a producer working on my future projects. I wanted to take a few minutes and share a few of the lessons that I learned, with an eye toward how the producer side of my brain learned them.
This might seem like an obvious one, but I know I’ve heard fellow producers say some variation on how the game designer’s job is so easy compared to theirs, and that they could do the game designer’s job in their sleep. Heck, I'll confess that the thought crossed my mind once or twice! While this idea may be true for some projects, in my experience the role of game designer is at least equally as difficult as the producer’s.
Game designers utilize many, if not all, of the same “producer” communication skills when collaborating with and giving direction to the team, and when giving presentations to stakeholders about the design. Game designers even arbitrate disagreements between team members—usually creative ones, rather than interpersonal ones, which can sometimes be even more sensitive.
One interesting communication element that I didn’t fully understand was that people ask the game designer to explain themselves all the time. Developers want to know more about the system you designed, stakeholders want to know why you chose to design the system that way, the producer wants to prioritize everything about the system in case something needs to get cut, and everyone along the way will want to know why you didn’t implement their idea—or didn’t implement it in the way they wanted. Producers get a lot of this too, though as a producer I often feel one step removed: you’re explaining the project, rather than yourself.
The two jobs do many of the same things, they just approach the communication and the coordination from two different angles: producers on the managerial side, and game designers on the creative side. Based on my experience, neither role is “harder” than the other, they’re just different, and it takes some empathy for one to figure out what the other is going through.
This was another lesson that I thought I understood going in, but I really had no appreciation for until I was on the other side. Because the producer and the game designer are two sides of the same coin, and because they have to work so closely with one another, the two must be in lock step with one another. If the two don’t understand and trust each other, the team won’t feel like it has unified leadership, which gives rise to a number of other problems that can trickle down through the rest of the team. For example, when my producer and I experienced a number of communication breakdowns over the early sprints of the project, we noticed that there were other similar communication breakdowns between us and our leads, and our leads and their departments. Regardless of whether or not we realize it, team members can sense when their leaders aren’t getting along with one another, and that destabilizes the rest of the project.
The inverse is also true. Later in the project, the producer and I felt so in sync we kept joking that we shared a brain, and we noticed that the team seemed motivated to work hard and succeed together. The two of us leading together not only helped us support each other and lower our stress levels, it helped our team figure out how to work together.
Furthermore, the dynamic between producer and game designer isn’t going to be a one-size fits all relationship. I realized after talking with my producer early in the project that one of the reasons why we had problems together was because he assumed I had the same strengths and needs as his previous game designer, when I actually needed a different kind of support. Producers and game designers must take the time to get to know their “other half,” and be flexible enough to find new ways to work with each partnership they have.
My producer and I fell each fell into this trap at several points in the first half of the project, largely because we felt too pressed for time. I asked for a feature and he would approve it without asking me for all the details. He would ask me to push something to the next sprint in response to schedule pressure, and I would do it without fully thinking through the ramifications or trying to decide what else to cut. In these kinds of situations, we lost more time by rushing than we would have by sitting down and having a detailed conversation.
This concept extended to interactions with team members as well. There was one moment where I approved a level design without clarifying my understanding with the designer, and it ended up being completely wrong for the game. On the flip side, I tasked a developer with implementing a feature, he seemed to understand it, then implemented it incorrectly and had to start over—grumbling that he could have saved time by asking questions about things we was unsure about.
About halfway through the project, my producer and I started employing a lot of reflective listening techniques: “I think what you’re saying is…” The reflections extended our design discussions a bit, but we ended up with significantly fewer errors and omissions. It had the added benefit of further ingraining how our game worked with each member of the team that overheard the conversation, which allowed everyone to spend less time talking and more time working in the long run.
This is a more game designer specific lesson, but I also think it’s good for producers to understand. Game designers, in general, seem to have the reputation of being the ones with all the answers. This may be true in some cases, but I know without a doubt that I wasn’t the only creative mind coming up with features and solutions on my last game, even if I was the game designer. The game designer’s role, similar to the producer’s, is to identify problems and identify solutions to those problems—whether they come from themselves or from another team member. For example, I spent a fair amount of time trying to describe the camera I thought we needed based on words and other game references, and I wasn’t having a lot of luck. Our camera system got significantly better once I stopped trying to dictate how it was supposed to work and just asked the level designer and programmer working together on it to simply make whatever felt good to them.
In order to get these ideas, though, the game designer and the producer must take steps to create a collaborative culture where team members feel free to speak their minds and share their insights. In doing so, there’s some risk of falling into the “design by committee” trap, but I found that with practice—and a little bit of diplomacy—it’s a fine line that a game designer can walk. “That’s a cool idea. Let me think about it and discuss it with the other leads,” is a polite phrase that I’ve used to work toward no, or to work toward yes but with changes.
There are a lot of things that I’ll be taking away from this experience that will make me a better producer. Some of these lessons come from my work as game designer, and some come from watching someone else work as producer. I’d definitely recommend that producers go through at least one project as a game designer at some point in their careers to better empathize with their creative counterparts. While I may not be quick to volunteer to do it again, the experience gave me a great appreciation for what game designers go through. It also improved my understanding of how I can better support the next game designer I work with so that we can build the solid game designer/producer relationship vital to the game’s success.