Gamasutra: The Art & Business of Making Gamesspacer
How to be a Better Game Designer
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

How to be a Better Game Designer

January 29, 2013 Article Start Page 1 of 4 Next

"Regardless of what kind of game you work on, design leadership is at the center of success or failure," writes design consultant Phil O'Connor, whose credits include Far Cry 3 and Operation Flashpoint 2. Here are some of his practical tips to help you become a better design leader.

"Good judgment comes from experience, and experience comes from bad judgment." - Rita Mae Brown, Alma Mater

A few years back I was inspired to write an article, How to Hire Good Game Designers, which Gamasutra graciously published. The positive response it received was surprising and inspiring, so here goes some more advice -- this time to my peers in the design trade.

This is not an article about game design techniques, however -- that subject is so broad and personal to each designer that an article would barely scratch the surface. In addition, my fun is not your fun; everyone likes different things, and as a good designer, you should be true to yourself. Trying to make someone else's idea (or "formula") of fun is rarely successful. I guess that, in itself, is my advice on game design technique: do what you know, follow your instincts.

The real point of this article, however, is how to be an effective design leader in a development team. This is just a catalog of my personal observations over the years. It is neither a definitive pronouncement on the subject nor a standard that everyone should try to reach; it's just a collection of personal lessons learned over the years. Take them or leave them in whole or in part, ignore them, share them -- do as you will.

I have been designing games for most of my life and 16 years in a professional capacity. I have never really considered design itself difficult. What I mean by that is, coming up with gameplay ideas or concepts for a game has been the fun part -- the easy part, I guess. What has been the difficult part of learning my trade is how to work in a development team, and specifically work with the different disciplines in development.

As a designer, you don't work in a vacuum. Everything you do affects other people's work on the team, and learning to understand that effect and how to be a professional is the key to successful design implementation. This is a collection of my conclusions on the subject after over a decade in entertainment software.

Regardless of what kind of game you work on, design leadership is at the center of success or failure. Every studio has their own approach to managing design work, but these recommendations should apply in most cases.

The key to being an effective designer is understanding that you are at the center of a workflow that affects all the other disciplines. Design decisions affect art, sound, technology, production plans, budget, and marketing. Assuming you have good design instincts, fresh ideas, and a creative capacity, the key to being successful as a design leader is first understanding the high profile that your work has in the team.

The first thing that should come to mind when you realize this is to have respect, or humility, as Kim Swift put it in a recent article. You are in a tremendously powerful and sensitive position; you are going to have a major impact on the success of this project without necessarily having authority in the team hierarchy.

And even if you do have that authority, it should rarely, if ever, be used. Respect the other disciplines and their role in the project. They are not there to execute your ideas; you are going to work with them to create something fun, together. You work for them as much as they may work for you. Nothing turns off a team more than an arrogant and imposing designer who throws out his "vision" in vague public speeches or voluminous documents and expects them to turn into concrete gameplay.

Once a team has lost respect for you, there will be resistance -- even if not overt or obvious. A team that does not feel like partners in the design process will question every decision, will remain pessimistic about gameplay choices long after they have been implemented, and generally drag their heels throughout the project. This kind of atmosphere ends up hurting everything in the game; things take longer to make, features that had potential will get cut because they go over budget, and finally the greatest buzzkill: overtime is never far behind...

This is not to say that the designer is responsible for everything that can go wrong in a project, projects fail for many different reasons, but the central role of your work puts you in a position to affect the delicate relationships between all teams, so be mindful of this situation and always act with the intent of earning the team's respect and trust in a long term way. How do you earn the team's respect? Here are some ideas:

Be prepared. Whenever you are meeting with other disciplines to discuss implementation, make sure you are prepared with the latest information, updated documents, and a set of possible solutions from design. Developers don't like doing your job for you; if asked for information on how something is supposed to work, don't throw it back at them and ask them to figure it out. Have an answer, or work something out based on information they provide.

If there is a decision to be made, understand the options and the consequences for each option and make precise choices. That means you should be an encyclopedia on the project, and this is easier for you as the designer to achieve, because you have more contact with all the different disciplines. You are somewhat of a central repository for what everyone is doing, so use that position to share and communicate the current state of progress on the project. This leads to...

Make decisions. Artists/animators, engineers and sound designers work according to precise schedules and budgets. They must produce assets at a predictable rate and give regular constant updates on the progress of this work. Nothing can upset this more than failure to make design decisions when they are needed, or making vague ones.

Designers have to provide concrete and hard information when discussing the asset requirements for features with the team. No design document will ever provide all the information necessary for these teams to work independently of your input. You must interpret the design for them, modify it if necessary due to the myriad technical or production related limits, and provide a final say when it is necessary to have that precision.

If you need to make a decision on the spot, make it, record it (by email) and stick to it. Nobody expects you to be right all the time, or even to have all the answers, but they do expect you to make design decisions. When you fail to do this, you introduce uncertainty and leave things up in the air. It's better to risk making a mistake than to not make a decision at all. And you will make wrong decisions; all designers do. Which leads us to...

Don't worry about being wrong. Some things that you thought were cool won't be in the final cut, and that is part of development. Don't worry about your ideas not working out in the end; worry about the game as a whole. Some of your ideas will fail for reasons that do not invalidate the idea itself.

It could be due to scoping issues, or a technical issue no longer making it feasible, another feature rendering it obsolete... Don't sweat about your precious idea getting rejected after playtesting; games are created in an iterative process, and you can only find out if something is really going to work once it is actually prototyped. Until then, it is just theory, based on your design instincts. Speaking of theory...

Article Start Page 1 of 4 Next

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer


Josh Sutphin
profile image
Having been in AAA design leadership myself, I must say: this is the strongest article I've seen on Gamasutra in years.

Bravo, sir. Bravo.

Randolph Heard
profile image
Why no mention of writers? Have you not encountered us in your work?

Nice piece otherwise.

Erin OConnor
profile image
O'Connor's RULE !

Luciano Lombardi
profile image
great read, thanks for sharing the article. Many useful advices

Noah Young
profile image
Thanks for this article ! As a starting Game Designer it's great and insightful advice :)

Phil O'Connor
profile image
@ Randolph: Yes, I have made several grave sins of omission, writers, LDs and marketing to name a few. My apologies! I have worked with writers, but only for a very small proportion of my projects. I guess I haven't learned enough about working with writers to recommend best practices in the article, just one more thing I will need to learn as writers become more and more important in the industry. I also did not mention level designers, but this is because I consider them the same as designers, perhaps this is old school, sorry to any offended LDs out there..... To all those marketing people out there, you are just as important, but I rarely work with marketing day to day during a project, and the article was mainly about daily working interaction with the team. Maybe there is a marketing person out there who can help with a suggestion on how they like designers to work with them?

@ Erin: "nec timeo nec sperno" :)

Thanks to all for your kind comments. They are much appreciated.

John Rose
profile image
This article has a little of everything! Well done, and thanks for sharing the wisdom of decades.

Anthony Buchalka
profile image
Thanks for sharing Phil. Although we have a relatively small team of 7, there are plenty of great tips here that we will start using immediately. Cheers.

Muge Arikut
profile image
My associate producer recommended this article and there are really lots of useful details for both of us here.
Thank you Mr. O'Connor.

Marvin Papin
profile image
The firsts 2 lines are enough and i totally agree.

Mark Sample
profile image
Really good article. Nicely done and no fluff... win!

Gregory Booth
profile image
"I hope this reads more of "learn my from mistakes" than "I am such an expert! Blah, blah, blah." "

God knows we have enough "experts" here on Gamasutra.

Your qualified opinions and experiences are a breath of fresh air!

Awesome article. Please write more!

Tray Epperly
profile image
Good tips. Thanks for sharing!

Francisco Javier Espejo Gargallo
profile image
Thank you very much for sharing. I've been on testing for 9 years and I miss our role there. As a QA Manager I always teach my mates to be close to the Lead Designer and know as much as him/her about the project.

For me it's the most important thing and I always though that we're crucial to anticipate design flaws and help the design team finishing a polished game.

Phil O'Connor
profile image
Indeed, yet another vital role that I did not include. QA is of course, essential to successful development, sorry for the omission!

Francisco Javier Espejo Gargallo
profile image
It's pretty uncommom to see designers willing to share their goals or objectives with testers, and I feel that they should be included on the team meetings and the discussions.

Please spread the word! :-P

Axel Cholewa
profile image
Great article!

A small addition for "Working with programmers". I recently read a very nice article (
k-order-hell) by Joe Houston (former Dishonoured programmer, now went Indie), and he advised programmers to approach problems "by getting into the skin of a game designer."

The other way 'round is also true: for communication with programmers, it's a great exercise to think like one.

Jeremie Sinic
profile image
Thanks for sharing! As an ex-producer, I praise your sound advice to game designers: producers are not the enemy :)

Tyler Gedeon
profile image
This is a fantastic article; thank you for sharing your experiences with us!

Abby Friesen
profile image
This article is great! It really shows how a designer is both a leader AND a servant to the team.

Christopher Stallworth
profile image
Wow excellent piece. My collegues and I are starting our own indie company and this article has helped me be able to clarify things and see that I have been taking the wrong apporach in some areas, which would have killed our project. I am the game/level designer for our company.....amazing!! Thanks Phil

Kain Shin
profile image

Jim Chen
profile image
Hi, Mr. O'Connor,

This article is great, most opinions of this list remind me some experience and mistakes I'd been through.
I am a game designer from Taiwan. I'm wondering if you can authorize me to translate to my native language, Traditional Chinese, to let more developers in Taiwan read your article and understand your great advice.

I will note your name and this page's URL in the translation. After I finish the translation, I will give you my blog's URL to check. Let me know whether you allow me to do and any other requirement.

Thank you so much! I learned a lot from this article!

Phil O'Connor
profile image
Mr Chen, thanks for the comments, absolutely go ahead and translate this article and share it. That is why I wrote it :) Any one else who wishes to translate and share the article has my permission.

Jim Chen
profile image
Thank you so much!
Here is my translation:

Kushal Yeole
profile image
Hi Mr. Phil O' Connor,

This article is great learned a lot......

Thank You for sharing....:)

Antonio Zapp
profile image
Thank you for sharing your experiences Mr. O' Connor. I'm coming from another "world" (electronic engineering) and I completely agree with your thoughts on the large discussion of team managing. Your considerations are valable on many fields (especially the general initial ones) not only in the game factory. It is really a good article.