GrandMaster B. (a.k.a. Brian Hook): Is one of the programmers for Id Software and was instrumental in the developement of Quake II and Quake Arena. Another one of Brian's most notable programming talents was the development of the first version of the proprietary 3dfx 3D graphical API, "Glide". Brian posts a column called "Ask GrandMaster B" on a website hosted by Billy Wilson, Voodoo Extreme http://www.voodooextreme.com. The discourse is fairly technical and sometimes brash and humorous.

I have reprinted the following without permission from Billy Wilson or Brian Hook.

And now, on to the real thing... 

• February 5th - RE:The keys to development success...? (7:00am MST))

February 5th, 1999 - (7:00am MST)

GMB:

The world seems to be full of late games, failing game projects, and dead game projects.   The typical scenario seems to be the game development goes on 2x as long as projected and the game is either delivered late and technically obsolete, or the cash runs dry before the game is delivered and the whole project tanks.  Your current employer, on the other hand, seems to keep cranking out leading edge games pretty much on schedule.   Briefly, what do you feel are the key ingredients to successful, on-time, game development?

- Tom Leathley

Tom,

Developing games in a timely manner is a very very tough task.  There are many factors involved when it comes to delivering a good game:

- vision
- team dynamics
- leadership
- communication
- development
- thorough testing
- publisher support

VISION:

In order to develop a product, you need to know what product is being developed.   This may seem rather "duh", but a lot of times you can see a product under development where it's obvious that different members of the development crew have no clue what the end product is supposed to be except in the most general terms.

There must be a set vision, a design document, a development GOAL.  The development team should clearly understand what they're doing and what they're trying to accomplish.   No member of the team should have answers like "I'm doing some graphics" or "I do some levels".  Each team member is responsible for putting together a piece of a big puzzle, but they can't design a good piece unless they know how it fits into the grand scheme of things.

And in order for everyone to know how their piece fits into the big picture, a big picture must be defined.  Before the project is started there needs to exist a mission statement, a design document, concept art (if necessary), and at least one good design meeting where everyone walks away understanding what the hell they're trying to do.

If you don't have a vision for your product, then no one knows what they're trying to do.   And if you don't know what you're trying to do, how the hell are you supposed to get it done?

Lack of vision will cause a project to meander about aimlessly until something resembling a game eventually shows up (if you're lucky).  The project ends up late, and a lot of reviewers will feel that the game is inconsistent, random, and unpolished.

Know very specifically what you're supposed to be creating.

TEAM DYNAMICS:

The development team doesn't have to consist of a bunch of old college buddies, but they need to respect each other's abilities, work ethic, and desire to bring out a great product.  If this is missing, everything goes to hell quickly.  At the very least they should get along.

Team dynamics often define how well a project will go.  When everyone gets along and can communicate, things go well.  If everyone else dislikes each other and, even worse, doesn't respect each other professionally, then you'll have big BIG problems.

It is much better to have a strong team of good developers than a weak team of awesome developers.  Individual talent alone very rarely carries a game to greatness, but a strong team of competent developers often leads to greatness beyond the skills of any single team member.

LEADERSHIP:

Leadership is partly responsible for ensuring positive team dynamics.  By strong leadership you need managers/project leaders that are assertive and decisive without seeming arbitrary, will swiftly settle any internal team conflicts, and that foster communication between team members. 

A good project leader will remove incompetent or demoralizing team members IMMEDIATELY once they know -- without a doubt -- that that team member is a detriment to the completion of a project because of their ineptitude, lack of dedication, or negative impact on company morale.  They will also solve conflicts effectively by being objective and unbiased and making decisions based on the arguments presented.  If the team members respect their leader, they will defer to him or her once a decision has been made.

Poor leadership equivocates on major decisions because of lack of confidence in their own decision making skills or because they don't want to anger or alienate specific team members.  If you don't have it in you to make large, sweeping decisions with confidence, then you should not be in a position of leadership.

By the same token, leaders need to avoid being arbitrary or the perception of arbitrariness.  They need to be able to communicate the thought process behind their decisions so that everyone understands why certain decisions were made.  If inadequate effort is put forth with this, then there will be a perception that the leader is arbitrary and dictatorial and makes decisions on a whim instead of through careful analysis.

The worst thing possible is when you have a project with weak leadership. The project tends to aimlessly wander about with no direction; internal team conflicts tend to rise more frequently since the team members will attempt to "solve" problems themselves, even if they don't have any real authority to do so; bickering and polarization tends to manifest itself more frequently as team members attempt to point the finger of blame on specific employees; employees quit out of frustration because they don't know what's expected of them; and communication goes to hell since the employees don't have a central clearing house for status reports/comments/questions. 

Competent leaders will enhance strong team communication skills by making sure everyone understands what is expected of them and each other.  The leader will help other team members resolve conflicts and communication problems.  He or she will make sure that deliverables owed between team members are delivered so that conflict does not arise between employees. He or she will make sure that when one part of the project is slipping badly that steps are taken to solve the problem as soon as possible.

Leadership is about decision making -- knowing what decisions to make, when to make them, and how to propagate the changes effectively through the team.

A poor leadership or a lack of leadership altogether can single handedly destroy a project, and sometimes even a company, even if the game design itself great and individual team members are highly competent.

COMMUNICATION:

Communication binds the pieces together.  A clear vision of the project is useless if it is not communicated effectively to the team.  Team cohesion suffers if the team members don't speak to each other and do not understand what is going on.

Once again, this is where leadership steps in.  A leader will make sure that the team members talk to each other, that all team members are aware of the status of the overall project, and that everyone understands what they are responsible for.  The leader should act as a clearing house of information -- anything to do with the project should be known by the product manager so that any developer can walk up to him or her and ask anything from "Hey, how's the sound coming along?" to "When's the manual going to be done?" to "How are we going to handle European distribution?" to "What are our competitor's sales figures looking like?"

Since the leader is expected to know what the hell is going on at all times, he or she is vital for communication, in effect being the hub of all information.

If everyone is on the same page, then there is very little room for miscommunication.   You don't have people saying "Oh shit, I had no idea you needed this done today" or "Wow, I was doing things this way, but that won't work with what you're doing".

DEVELOPMENT:

This is pretty much the obvious part.  You need developers -- programmers, artists, mission/level designers, sound people, modelers, etc. -- that are going to get the job done on time and competently.  Without this, you're pretty much screwed.

THOROUGH TESTING:

Compatibility and performance is a big issue these days with most games.  During the development of a title, especially a technologically aggressive one, you need to thoroughly test your software with a wide variety of hardware, software, operating environments, network conditions, memory conditions, etc.  It's a pain in the ass, since no one wants to be stuck with their XYZ P.O.S. graphics accelerator, but this is often the only way to make sure that problems are found and fixed early on.

PUBLISHER SUPPORT:

When you have strong support from your publisher -- financial, moral, and public -- then it's much easier to develop a game.  It's very difficult to stay focused when you're arguing over milestones, timely payment, specific features, things of that nature.   But it's a thing of wonder when you have confidence that your publisher is on the up and up and when they have strong confidence in your team's ability to deliver a great product.

The opinions expressed here are of "GrandMaster B", Brian Hook, and do not
necessarily represent those of Voodoo Extreme, id Software, or Momma Spice.

blah, blah, blah... legal crap...

Copyright 1998 Billy Wilson. All rights reserved