Gamasutra: The Art & Business of Making Gamesspacer
How to be a Better Game Designer
View All     RSS
October 30, 2014
arrowPress Releases
October 30, 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 3 of 4 Next

How to Work with Different Disciplines

As a final bit of advice, here are some lessons I have learned about working with different disciplines. I have found that these have helped me build a good relationship within each "culture" in development, understanding the work from their perspective goes a long way to earn their trust and professional respect.

Working with programmers. When working with programmers, keep in mind that they work in very precise and concrete terms. Whatever feature you have come up with, they will have to make it happen down to the smallest detail, and in doing so they will be carrying the design mantle that you hand off once you have outlined the feature.

Be precise when discussing implementation with programmers. Mathematical formulas are nice, if you can provide them. Provide feature lists with all asset requirements, exact details on mechanics and systems.

Point form information is best for this kind of documentation. Programmers don't like sifting through paragraphs of flowery language, backstory details and character bios when looking for the information they need to code. Provide functional diagrams, failure and edge cases, alternative implementation options, Plan B versions -- as much as they ask for or need.

Some programming teams want to get directly into the design with you. Great! Build a mutual understanding of the gameplay objectives together, then discuss nuts and bolts as they require. Be available to the engineering leads to work on stuff according to their needs. Don't just begin publishing documents as the mood strikes you; ask the programming leads to give you a work list that will satisfy their information needs according to their pipeline. If you can be Johnny-on-the-Spot with the information they need when they need it, you will be working together.

Programmers need to know that the information that you are providing is relevant to their current work; they don't want to sift through a large bunch of documentation looking for the information they need. Direct your documentation to their needs and at the level of detail they need, when they need it. If you cannot detail a feature because of a dependency on something else, then discuss the dependency and agree to a mutual plan of action.

This essentially means that you should be writing two levels of documentation: big picture level stuff that gives overall vision and scoping detail for general team consumption, and nuts and bolts design documents that are as direct and precise as possible regarding features and mechanics. Engineering leads may have a preference for the format and style of this kind of documentation; talk to them and find out what would suit them best.

Working with artists. Artists, modelers, and animators deal in aesthetics as well as concrete asset production. The important part for you as a designer is to not intrude upon their area of expertise -- the aesthetics, or simply put, the art.

When reviewing art assets or discussing art direction, don't become an artist. Make sure you keep your designer hat on, and leave the art to the artists. If they solicit your input on an aesthetic call, give your personal preference by all means -- but know that nothing turns off artists more than a wannabe art critic. If you have artistic training, great, make sure that they know you may have some basis for your opinion, but don't try to be the art director as well as the creative one.

If you want artists to be part of the design process, ask them for options and preferences and see if that works or fits the game. You want to cultivate their artistic sensibility so that they pour their best work into the game. If you criticize art choices based on personal preferences rather than what is objectively best for the game, then you shut them down as partners in the process.

When you ask for art assets, make sure that you get into stylistic dos and don'ts before they start working on them. Telling an artist that your game is not steampunk style after they made a character model is never going to win you points. Be clear about what the game is NOT about as well as what it is stylistically close to.

Some art teams want precise, detailed designs on all art related components; some teams want to be able to interpret the art needs from the design direction. Make sure you work with the style they prefer. If it is detailed they want, then detailed you give. If they prefer to be left to make assets according to their interpretation, then try to work with that and harness their creative talent while of course keeping it within the scope of the design.

Animators merit a special mention. Depending on how much animation your game uses, this is a crucial relationship. Animations have a huge impact on performance and the final appearance and polish level. It is easy to become overzealous in animation and break the memory bank, but if you go too cheap, your game will not compete visually. Finding that fine balance requires a close understanding between you and the animation team.

What is the minimum that your design can live with, and what is the "would be awesome" extra that would really give you more bang for the buck is a tough thing to work out ahead of time. Working closely with animation throughout the project is important to maintain that balance. Keep on top of animation design, make sure that the designers and animators are in agreement, and provide precise lists of requirements as the animation team needs. Make sure that the animators and gameplay designers are both working on the same page in terms of visual bang for asset buck.

Working with sound designers. Sound is psychologically a huge part of the game experience (right up there with the visuals). I go online and look for soundtracks of games that I played almost 20 years ago because they bring such a rush of nostalgia and good memories. There is something very primordial about sound, as far as its role in building emotional memory.

Your relationship to your sound design team should be such that you both understand what kind of mood you want to build in the game. You should pitch the design to them and ask them to pitch you music and sound effects that would match it. It's just like scoring a film, and just as important.

The best way to show them what you mean is videos and sound files. Once you agree on the atmosphere you want to create, then the rest should be relatively smooth. If you are providing dialog for them, or even directing recording sessions, make sure that you are open to changing things on the fly. Experienced sound people know what sounds right; don't be resistant to changing your script based on the sound designer's or voice actor's different interpretation of it. Something that looks good on paper may be totally silly out loud. Just like the other disciplines, be willing to make your stuff better with the creative input of those who have the experience to know.

Article Start Previous Page 3 of 4 Next

Related Jobs

DeNA Studios Canada
DeNA Studios Canada — Vancouver, British Columbia, Canada

Analytical Game Designer
Blizzard Entertainment
Blizzard Entertainment — Irvine, California, United States

Senior User Experience Designer, Irvine
Blizzard Entertainment
Blizzard Entertainment — Irvine, California, United States

Senior User Experience Designer, San Francisco
Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Artist/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.