Ernest Adams is a technical producer at Electronic Arts, a leading developer in the sports genre. Adams has worked on video production for the John Madden Football title, the best-selling sports video game of all time. He is also a regular contributor to Gamasutra and was Director of the Computer Game Developers' Conference from 1991 to 1995.
How does a development team utilize a design document after it is written? Who do they go to when they are unclear of what something does or means?
Every member of the team should have a copy, and should build to the specifications in the document. The document should describe every screen, menu item, and hot spot, and every keyboard key, mouse button, and joystick button that will be active in the game. It should also describe the basic AI or behavior that is desired from the artificial opponent (if there is one). If the game consists of a sequence of missions it should describe at least an outline of each mission and the overall "story arc" -- that is, the general plot of the game from first mission to last.
Your second question is in fact quite a tricky one and depends on the political structure of your team. You can run into real problems with a volunteer team of people who consider themselves peers. Some one, or two, or at most three people must have the final decision-making authority in the case of conflicts, and the others must cede to them that power. In a game being developed for a publisher, that authority rests with the producer at the publishing company, who is considered the "keeper of the vision." This is because the producer is responsible to the company for the game's financial success, and is therefore the one whose job is on the line if the game contains design flaws that make it sell poorly. Often smaller design adjustments are left to associate producers who help the producer test the milestone builds as they arrive. And many very small design decisions are made by the artists and programmers themselves (when a guy is hit, does he say "oof" or "ugh"?).
If something is unclear in the document, the author of the document -- the designer, who may or may not be the producer -- should be consulted first. If there are conflicts or disagreements over the design, then whoever has been designated as the final authority will have to arbitrate. A bad producer will simply dictate his wishes and demand that it be done that way; a good producer will discuss, think out, and negotiate -- but not be afraid to lay down the law if a compromise seems hopeless.
Is there any sort of coding standard for the programmers?
Software engineering standards are rarely specified in game development, since the software doesn't get maintained. However, the lead programmers should define the major data structures to be used in the game, and communicate them to the junior ones. This doesn't go in the design document, though -- it goes in C header files.
What in your opinion makes a good game?
- A compelling activity or premise, something that people want to do and will enjoy doing. This includes a clearly-defined statement of the player's role.
- Good content: good graphics, good sound, good acting, good writing...
- Solid, bug-free code that runs fast and plays nice with the machine (no under-the-table hacking the OS).
- A clear, unambiguous, and intuitive user interface
What advice can you offer people who want to get started in game development, perhaps to turn it into a career such as yours?
This requires a long answer, but there are fundamentally two ways into the industry. One is to cultivate development skills that the industry needs: programming, writing, animation, 3D design, music composition, sound engineering, videography. Many of these can be learned in college or at trade schools. Once you have these skills, build up a portfolio of sample work, and get a job in the industry on the basis of your skills.
The second is to concentrate on the games themselves. Play them constantly -- lots of different ones. Get a job selling them at retail. If you're good at it, you can get a job in customer service at a publisher, answering the phone and helping people out with their games. From there you can work your way up to being a tester, then an assistant producer, associate producer, and so on up the line. Producers are people who love games and have an instinct about good ones, and can also lead a team and manage a complex production process.
The first is faster and gets you more money right away, but it has a glass ceiling: you can only rise so high on the basis of technical or artistic skills. Beyond that you need production experience, which you only get being in the trenches as a producer -- overseeing the development process, testing, tuning, and tweaking -- and also, managing a budget and a production schedule, and working with marketing and sales. Ultimately, the people who rise to the top of any business are the ones who bring in or manipulate money. The people who build products spend the company's money, they don't make it, so management is always on their case about keeping costs down, and is always slightly suspicious of them. Even though they can't do without your creativity, they need it where it is, being creative, not being an administrator.
Sorry to be so cynical about it, but that's how it looks from where I stand. If you want to rise high, follow the money.
Where do you get your inspiration from for writing games?
From the public library.
I know that sounds flippant, but I'm serious. From history and anthropology and myth and legend. From novels and short stories and plays and poetry. From books. (Movies and TV can give you ideas about presentation and visual style, but they themselves borrow from books for plot. Lots of books get made into decent movies, but when a movie turns into a book, it's usually a TERRIBLE book.)
Get a library card and read your ass off -- especially history. History is enormous and full of amazing things that can be used as the basis for games.
Does a game need a story behind it in today's world?
It depends on the player's motivation for playing the game. id Software deliberately eschewed any story behind Doom -- they called it "the S-word." That's because the motivation is the fun of running around and being aggressive or scared and blowing the hell out things. Doom is a shooting gallery where the little ducks shoot back, that's all.
Some games, like chess, are pure strategy with no story. They're all raw skill. That's OK, too. It's just a chance to exercise your abilities, but they're strategic mental abilities rather than twitch abilities.
However, many mission-based games, where the objective is more complicated than "kill as many things as possible," use a story to create background and motivation. Achieving a mission advances the plot -- it's your reward for doing well.
Personally, I prefer games with some story elements: characters, personal relationships, dramatic tension, a problem to be solved. I'm not that fond either of shooting galleries or pure strategy (although I like Tetris and pinball every now and then). A storyline does limit the character's freedom of action (I gave an entire lecture on this topic once), but even an arcade shooter has a progression of enemies that you face, from little ones to the boss, and you don't have any control over that.
Every game has a set of "win conditions" -- things that you must achieve to be said to have won it. In a shooter like Doom, surviving is winning. In a story-based game, the win conditions are usually more complex, and don't always require the survival of a single individual. That gives you more freedom as a designer to build more complex challenges for the player. Ultimately, Quake is just a faster, smoother, better-looking Doom: more traps, more creatures, more puzzles to solve, but fundamentally it's still just a shooter, and the player's goal is still kill or be killed. An RPG can have missions of all kinds. And an open-ended game like Sim City can have an infinite number of challenges: build a city with no roads, only rail. Build a city with the minimum level of taxes. Build the biggest population in the fastest time. And so on.
