Blog Archives
Balancing The Working Relationship Between Game Designers And Programmers
Many people confuse the positions of game designers and game programmers, thinking they are the same role. However, as anyone who has worked in a development team of more than a handful of people knows, the game designer is responsible for specifying the mechanics and rules of a game, while the programmer is responsible for implementing those mechanics and rules as computer code. However, the game designer is not, and should not, be the programmer’s boss.
it is part of a game designer’s responsibilities is to advocate for refinements to the game design so that it is as engaging as possible, and to ensure that the programmer has implemented the design properly. However, individual designers vary in their zeal. If that zeal results in too many changes to the design, especially in the later phases of development, the game’s schedule and budget can be put into jeopardy. That’s one reason why development teams are not led by the game’s designer, but by a director or producer, who can be a bit more impartial in balancing a game’s quality and schedule.
A game designer’s zeal can lead the designer to providing excessive instructions and feedback to the programmer, resulting in micromanagement, a pejorative term for exercising so much control that its a detriment to productivity. A good producer will try to minimize micromanagement within a team, both from the designer and from the producer, so that the programmer is allowed to use some judgment and discretion. Although the designer is responsible for the game’s design, everyone on the team should be able to make suggests for it, since almost everyone in the game industry plays games and can contribute good ideas to the game.
Yet another problem can come from the designer providing too little direction to the programmer. I have also known many programmers to seek out the game designer and get more information about how a design is to be implemented and to get feedback on their implementation, sometimes needing to pull the game designer away from another task that he or she is working on. Here too, game designers vary on their desire and ability to give clarification and feedback to the programmers. When designers are so hands-off after the game design document is written that they become neglectful of their playtesting or balancing responsibilities, the producer needs to step in an ensure that there are regular communications between the design and programmer.
Just as gameplay needs to be balanced so that the game is neither too easy or too difficult for the player, the game development process needs to be balanced so that the designer is neither too much of a micromanager nor too hands-off, while the programmer is neither too autonomous or too constrained is his or her implementation of the design.
When Assembly Language Turned Into Assembly Lines
When I first started my career in game development, programming was much simpler than it is today, and I was able to develop my games in BASIC (Beginner’s All-Purpose Symbolic Instruction Code), with certain functions such as graphics and AI pathfinding done in assembly language. Games in general were much simpler than today’s games, and I was able to do the game design, art (such as it was) and sounds all by myself.
However, over time, games became larger and larger in scope, and more people were needed to develop a game. The lone developer was replaced by a two- or three-person team, which gave way to a half-dozen member team, which in turn evolved into a twenty, then fifty, and eventually a hundred-person team. Now a major AAA game title might involve over a thousand people, sometimes with several studios and art houses working together.
The production values of games also evolved, and so-called “programmer art” could no longer cut it. Therefore, development teams needed artists who knew how to draw, animators who knew how to animated, writers who knew how to write, and audio engineers who knew how to compose music and create sound effects.
Even these disciplines gave way to sub-disciplines on large-scale projects. The design department might be comprised of a lead designer who oversees system designers, content designers, user interface designers, level designers and writers. The programming department might be lead by a technical director who supervises the engine, physics, artificial intelligence, user interface, audio, multiplayer, and tool programmers. The art director in charge of the art department manages concept artists, texture artists, 3D modelers, riggers, animators, and environmental artists. The sound department might have different professionals specializing in music, sound effects and voice over. Each of these developers need to have their tasks scheduled and coordinated so that everyone works together as a team, and so that responsibility would fall to a producer or director, often assisted by a project coordinator and/or production assistant.
Each of the game’s thousands of assets, whether they be character animations, game levels, or cut scenes, might involve many different developers as the asset goes through conceptualization, design, production and implementation into a team. Creation of these assets involve an assembly-line kind of process, called a pipeline, and an individual developer might spend his or her time on the game just doing one step in this process, over and over again.
Many people who aspire to work on AAA games imagine themselves as having complete creative control over the entire game, but that’s not how major games are made nowadays. If you want to work in the game industry, you need to be able to take satisfaction in simply contributing to the game, even if your role is confined to creating the textures for all the rocks, tweaking all the attributes of the items for sale, or programming in the buttons for all the menus. You will likely be part of an assembly line, and your source of pride needs to be in the entire team’s collective work on the game.
David Mullich 