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 Previous Page 2 of 4 Next

Don't let the document do the talking for you. The game design document is not a blueprint for making an awesome game. It is a set of theoretical choices on gameplay, with a theoretical fun final objective. It will change a lot during development, and new information will modify its content rapidly.

That doesn't mean there is no point in writing one; even if it gets changed often, you still need to start somewhere, and the first versions of the design document are critical to shaping the overall vision and strategy of the project. However, many people will interpret it differently -- one sentence will mean something totally different to another team member. Engineers may need more information to understand something that is perfectly clear to an animator.

The design document is the starting point of your collaboration with the rest of the team; it is not the final result of your work. Make sure that when you put out a design document for the team that you go over it with the relevant department leads and people working on that feature. Yes, this means that you must schedule a meeting before they start working, and go over the whole thing in detail.

It really helps if everyone at this meeting has read it beforehand. During the meeting you will get a flurry of questions about stuff that you thought was perfectly clear in the document; this is normal and, in fact, healthy!

It means that you were not precise enough for certain people or that there was an ingrained assumption about the feature inherited from previous discussions. This is what this meeting is designed to iron out, and get everyone on the same understanding about what exactly this design is trying to achieve.

It also allows you to solicit input from the implementation group on how to execute features. The meeting should result in clarifications and small changes to the doc, and you should integrate those changes as quickly as possible and update the feature doc for the participants to review as quickly as possible after the meeting -- memories fade fast.

That process turns the document from a draft to a Version 1, and you are now off to the races. Talking through the doc will save you enormous pain down the line, and gives the team the chance to shape the design and inject their own ideas. You want this to happen -- trust me. The best games come from this collaboration. You must be confident enough as a designer to...

Ask for opinions and take other people's ideas on board. Be open and willing to acknowledge better ideas from others on the team, especially ideas outside the design group. This does not mean design by committee, nor should you hold a massive brain storming session with the entire team -- this will just result in a mess and make you seem uncertain and indecisive.

You are the designer; you are being paid to design the game. It is your responsibility, but all the ideas do not have to come from you; in fact, the best games are the combination of all the best ideas from the entire team. If you manage this process properly, whereby you can keep the design coherent yet at the same time adapt good ideas from others into it, you will have much better game DNA.

If your process is insular and exclusive of outside input, you will end up with an inbred design. It may look healthy and whole until released into the wild; then its crippling flaws will become obvious. On the other extreme, if design decisions are made by a committee, you end up with a Frankenstein game that is basically everyone's favorite personal feature from their favorite game forcefully stitched together in a painful and unnatural way. It never works.

Managing that middle ground takes confidence and experience, but if you are designing what you know (as opposed to someone else's idea of fun) it will be easier to navigate this tightrope. And it is a tightrope, because opening the floor to design ideas can be tricky if you are not confident enough about your design and you start to see a lot of people suggesting alternatives.

If you understand what you are trying to achieve, then you will quickly be able to earn the confidence of the team by explaining your decisions and making them see why you made those choices. Remember that people outside of the design team don't spend all their time thinking about design issues, and so they don't have the big picture that you are supposed to have as the designer. It's easy for them to look at a single feature and come up with a "better" idea outside of the context of the entire game system.

This is an opportunity for you, not a challenge to your ideas. This is where you start giving them a hint at how complex and interwoven the gameplay big picture is, and how much you have a grip on understanding it. It's okay to not have the answer to all the questions that come up during development, but you should have a few scenarios, or options, in mind.

This process should be informal. People should feel free to mention ideas to the design team at any time, without any expectations either way. Make them understand that you are comfortable listening to ideas and that you won't consider such a thing a challenge to your work. Be open and friendly about sharing the design, and your job will be much easier. To manage that process well you need to...

Be objective about your own ideas. Just because you are the designer doesn't mean that you are going to have all the best ideas for the game. You will need a lot of help, and if you shut out others from being part of that process, you will lose a massive resource: the accumulated brainpower of the entire team! In order to cultivate that collaborative relationship with the team, you have to learn to tame your own ego. You must be honest about your ideas and those of others.

It's easy to get defensive, as a designer, when you have all the experience and the job title but someone from an unrelated department comes up with something that is frankly better than what you had chosen. You have to be able to honestly admit to yourself first that this is a good idea, and then vocalize it to the rest of the team if you think it fits with the overall game.

It's not going to make them lose respect for you; on the contrary, it will increase their trust in your decisions when they can see that you are being objective and leaving your ego at the door. Vocalizing it also important -- publicly acknowledging the merits and source of the idea is very important to earning the respect of the team.

If you take someone else's idea and secretly stick it into the design, you will have earned nothing but contempt on two levels, first because you don't have the honesty to admit when you are wrong, and second because you are taking credit for someone else's idea. Even if it's not true, and you had no intention of doing either, nothing will tank you reputation with the team faster.

Being able to honestly evaluate the merits of a design idea regardless of authorship is key to being a good designer; there is no way in hell you will ever be able to make 100 percent of the design decisions 100 percent correctly, so listen to the team! Objectivity is also important to the people who pay for all of this...

Respect the business. Game development can be complex because of the uneasy mix of business and entertainment. In some entertainment industries, this marriage is well managed due to decades of experience honing that relationship. Yet there are still spectacular failures in the movie industry, despite over a century of refinement.

Things will not change in game development any time soon either. Technology is one factor; changes in the business model and evolving tastes are others; mainly problems stem from the easy-to-unbalance relationship between the business and the game people.

One way that you, as a design leader, can help maintain that balance is to understand the factors that are at the foundation of your project: the business conditions. This is probably the most important skill you will need to be an effective leader in design. This doesn't mean that you need to get inside the numbers that management deals with; it just means that you should know the lay of land -- the strategy behind your project.

A good tactician understands what the prevailing conditions are at the strategic and logistical level. In dev terms, you should be designing within the budget, within the technology scope, and to the projected release plan. This is tricky; I have seen some designers become more a part of the marketing team than the dev team as a result of being too preoccupied with the sales strategy side of the job.

Don't try to do upper management's job, but at the same time be aware of their plan and expectations on budget, and let them know you understand it. They need to know you are objective as well as passionate. This really comes down to your features should fit the scope, whether it's a $500,000, $5 million, or $50 million game.

Article Start Previous Page 2 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.