Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
106 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Pull Together: Getting Team Buy-in


Gameplay footage, however raw it might be, gives your team an idea of what to expect. If it's too early in the process to take footage of gameplay, you can use storyboards. Storyboards are often created as a part of the gameplay design or cinematic design. However, these can also serve a function as a tool to illustrate the game's concept for the rest of the team. You can create an animatic sequence through the use of video creation software. Windows Movie Maker ships free on some versions of Win XP. If you don't have that program, then hassle your cheapskate producer for the money. If you're a producer, um, sorry.

After exporting your still images as a slideshow, set it to music. Or, if you have other audio assets available, you can add these to your video. It's not important to create an elaborate movie with scripted dialogue and appropriate sound effects. The focus should be on giving the team a preview of what the game feel will be. This can clarify a new direction for an existing franchise, or convey the idea of a new kind of game to your team.

You may want to debut the video at a team meeting, or schedule a separate meeting for the screening. If your movie is elaborate enough, you may want to add some fun to the proceedings by making popcorn. Either way, allow time after the screening for discussion. If people have things to say, positive or negative, you've got communication.

Group Playtest

When there is a multiplayer build stable enough to play, get a group together and play it. Make it known that the purpose of the playtest is not to find bugs or to critique artistic decisions -- there will be time enough for that later. The point is to play the game, and to get a feel for what the multiplayer aspect is all about.

Establish some ground rules for the session before play begins. The purpose is not to find fault with anything. The purpose is not to test the shell, or the menu. Don't jump in, then exit out and restart it to see if anything goes wrong. Just start up a server, get in the game, and frag people (or start killing rabbits, or stealing cars, or whatever).

If your game features team-based multiplayer, assign teams arbitrarily beforehand. You don't want artists on one team and designers on another. You want to mix up your developers, so partner people who don't know each other well. In addition to getting people excited about the game, it will help form bonds between them. They'll start communicating, and this will streamline matters immeasurably.

If your game doesn't feature multiplayer, there's no reason you can't set up four stations and get everyone together for a solid hour of gameplay. Let people take turns, get everyone around to watch and heckle.

Later, after the session, have your dev team send their feedback. You may want to set up an intraweb forum where they can post their comments, or you may want them to send email to a specific person. Just ensure that the playtest session itself is free of negativity. You want the session to be a venue for fun and team-bonding. Make sure that they reserve all commentary for the post-game feedback.


As a game lurches out of the preproduction phase and slouches towards final submission, its hour come round at last, you hope that your team has a strong vision of the game that they're all working on.

Ultimately, the strategies outlined above are all just extensions of a single idea: present the team with the game concept (but not in the form of interminable design documents) and get them excited about it. Get them talking to one another. Break down the barriers to communication and get them working as a team.

Make it fun.


Katzenbach, Jon R., and Smith, Douglas K. The Wisdom of Teams. New York, HarperCollins Publishers, 1999.

About the Author

About the author: Rafael Chandler is a game writer and designer at Red Storm Entertainment. He got his start in the industry at Electronic Arts in 2000. He has worked on over 20 games in a variety of roles, from QA Tester to Designer to Writer. His credits include games like Majestic, Motor City Online, Ghost Recon 2, and Rainbow Six: Lockdown. For more information, visit www.draconianproductions.com.

  Page 1
  Page 2

  Printable version
  Discuss this article