Who is my customer?
There are actually two answers to that question. The first and most obvious is the end user – the person who actually buys the game. But, the right answer for me, a game programmer, is the artists and designers who are going to take what I build and use it to make an actual game. It is by paying attention to those people that I can have the biggest impact on the game.
So why aren’t the end users my customers? Well they are. I’m responsible for making sure the game runs well on their computers, doesn’t crash, and faithfully implements the game design. One thing that I probably can’t help with is making the game fun. I usually don’t design the UI, rarely design the game systems, and never tune a damned thing. Making the game pretty isn’t my job either. The art team produces all the visuals, and if something is ugly it is far more likely to be their problem than mine. Performance is a duty I own jointly with the other departments – artists and designers are often under strict constraints determined by how many polygons, pixels, particles, or AIs I’ve managed to coax out of the system.
The group of people that are, by far, the most important customers for me are the designers and artists. These people take the inert lump of code I’ve created and make a game with it. My job is to provide them with the tools they. Those tools vary depending on the customer, but in general they spend as much or more time using my tools as I do building them. I pay a lot of attention to compile and link times to keep my code-compile-debug loop as short as possible and I also need to pay close attention to the iteration time of designers and artists. This is one of the biggest things I can do to increase the productivity of the other departments.
I use data-driven design to put as much of the game as possible into data files and out of the code. I need to make every single tuning value something that can be modified without a code change, and if possible without rebooting the game. This has the advantage of greatly reducing the amount of up-front work a designer has to do – they don’t need to know what missions the game will have or what recipes the economy will contain, just how a mission interacts with other game systems, or how a recipe uses ingredients and produces products. Using this information, I can build the system and leave all the what for later. Knowing designers are going to change their minds about how things work, it is my responsibility to build things to be as adaptable to change as possible. It is also my responsibility to make creating the what as easy as possible, which usually means developing some sort of editor for all the data files the game will read.
While data-driven design for game systems is relatively new phenomenon, game art has been data-driven since programmer art was banished from professional game development. It is my responsibility to take the output of art packages and get it to display in the game in real-time. To help with art iteration time, I need to get the art to display as final game visuals as early in the pipeline as possible. An important part of serving the artists is to work with the art director to determine what graphical features the game engine actually needs, and implement those as early in development as possible.
I need to treat these internal customers as I would an external customer. They need stable code from me on a regular basis. Their tools need to run and boot quickly. Warning dialogs and reasonable UI choices must save them from common human error. They must be able to see the output of their work without any involvement from me because they are always going to outnumber me. The list of features I implement needs to be driven by their needs, not by whatever new technology I thought would be cool, or whatever is easiest for me to implement. I need to work with them to understand their needs instead of building systems for myself imagining that they are just like me. Under no circumstances should they have to throw away their work on my account – I need to make data files backward compatible or write further tools to convert them to the new formats.
If I can manage to do all of these things, the team will be very productive and quite happy. Artists and designers joining the team from other companies will marvel at the way things work on my team. When the game finally ships I will have done everything I can do to make it the best game it can be, and will deserve a big part of the credit for the game’s success. After all, a stack of design documents and XML files isn’t a game any more than a collection of code is. And a bunch of Maya files with no runtime engine is called a “movieâ€. I may not make the game, but without me the game could not exist.