Profile: Retro Interview: Kevin Cloud
Kevin Cloud, artist, co-owner, and project manager at id, describes the biggest challenges he faced working on Quake II. Cloud discusses art skills with respect to the transition to Trinity. He also describes his texturing tools, the art team at id, and project management.
Andrew “Kolinahr” Wu
By Alex Dunne / Gamasutra / Game Developer Magazine
January 23, 1998
What do you get when you cross an game artist, a project director, and a company owner? At id, Kevin Cloud is the result of this unique concoction. As one of the three people responsible for the models, textures, and other visual aspects of Quake II, Kevin Cloud put his stamp on the game. As the project director, he kept the highly anticipated game on schedule and got it out the door in time for Christmas. As one of the three owners of the company, let’s just say he’s doing well. In addition, Quake II just supplanted Riven and Myst at the top spot of the PC Data top-selling game list for week after Christmas. I exchanged e-mail with Kevin over the course of several days in mid-January, which is the basis for this interview.
When did you join the company Kevin, and what were you doing beforehand?
I started with idon March 10, 1992. They were midway through the development of Wolfenstein 3-D at that time. Prior to joining id I worked as a computer artist for about seven years at Softdisk. Currently I’m one of three owners at id, along with John Carmack, Adrian Carmack.
What did you contribute to Quake II?
For Quake II, I worked as artist and project director. As an artist I created wall textures, models, and a few skins. As project director I coordinated the project, oversaw the design, and maintained the schedule.
What were some of the biggest challenges for you in creating the textures and models for Quake II?
Designing art for 3-D games presents some unique challenges. For me there are two major hurdles in the texture creation process:
- Choosing a palette.
- Determining a texture style for a level or unit
Due to shading and dynamic lighting, games like Quake offer a uniquely limited texture palette. In software Quake is displayed through an 8-bit palette. To accommodate shading and dynamic lighting our 256-color palette exists in 16 rows of 16 colors that range from fully lit to nearly black. I’ll need a range for blood, a range for explosions, one for gray, and one range empty until the game is nearly complete. That empty range is used to solve color problems generated by the lighting. In the end, the majority of the textures must be built from the remaining ranges of 12 unique colors. If you don’t choose wisely, half way through the game you may find yourself with a palette that doesn’t offer enough range. At that point it’s too late to change.
Determining the texture style is also difficult. Each texture set begins with a handful of basic textures that set the style for that environment. It is a collaborative effort between the artist and the level designer. We have to understand his specific vision for an environment and produce the appropriate textures. Creating these first graphics is a trial and error process where often days of effort are lost.
After that, the challenge is just a matter of having more good or “creative” days than bad. Focus on the tasks in front of you. Seek out resources for inspiration. And stay in front of the computer.
For me model creation and animation suffers from a learning curve. Using the tools effectively is still not an effortless process. I’m going to spend a ton of time with Maya between now and the start of Trinity, our next project.
Quake II presents limitations on model detail and animation frame rate that you won’t find in designing models for cinematics. Quake II’s polygon models are built from a mesh of about 600 interconnected triangles. The animation is designed at 10 frames per second. When the frame rate goes above 10 Hz the program interpolates the necessary frames.
Trying to design an interesting model that falls under the polygon limit is challenging. Each model must be constructed with joints detailed enough to accommodate a full range of motion. Too few polygons in a joint will force the models to improperly deform during animation. Also, each monster must have a unique enough form and detail to differentiate itself from the other characters. I’ll spend days just building the basic model and trying to tear it down to the lowest amount of polygons possible.
A frame rate of 10 Hz is enough to make realistic animation. However, you don’t want just normal animation. Each monster needs to have a unique style to its motion to give it personality. The enforcer struts while the tank lumbers and the gladiator moves methodically. Creating nuances in animation at this frame rate is difficult. Tons of effort is spent tweaking each frame. One frame too many or too few makes a big difference when working at this low a frame rate.
It sounds like you’re really moving towards a lot more modeling and animation. Is that what you’d like to be doing for Trinity instead of the tiles, or is it another skill you’re trying to develop in addition to tiles?
I’m not moving more towards modeling. I created all the models for Quake and did quite a few models in Quake II. My skills improved quite a bit between the two projects, but I still need to get much better at it. Trinity will require a great deal of polygon editing work. All of the world surfaces, models, etc. will use polygons created by the artists. My goal is to be able to competently do any job that is required from me. That is the goal of all three of the artists at id. We’re a small team and can’t afford to specialize.
What tools did you and Adrian use to create Quake II’s textures?
Adrian and I use Deluxe Paint for creating wall textures and an in-house program called Texpaint for making skin textures for models.
Art in Quake is never seen as we create it. The engine scales, lights, and slants each texture programmatically. Although more and more artists are rendering their tiles in a 3-D program, the freedom a paint program like Deluxe Paint provides for creating and modifying a texture allows us to better address these unique problems.
We use Texpaint to edit a skin texture directly on the model. A skin in Quake is created from a 2-D front and back projection of a model. This is similar to taking a photograph of the front and rear of an object.
This technique is adequate, but doesn’t provide proper access to the sides of the models or surfaces hidden by other parts of the model. To solve this problem we create a special manipulated frame called the base frame. By pulling out vertices and separating out different pieces in the base frame we can show more surface area of the model from the front and the rear. The skin is then calculated from this manipulated frame.
Prior to Texpaint we’d edit the skin in Deluxe Paint. However, in Deluxe Paint you can’t easily identify what part of the skin is where and how it should really look wrapped on the model. Using Texpaint we load any frame of the model, not just the manipulated base frame and edit the skin directly on that model. It is easier to edit a skin in 3-D because you don’t have to predict the distortion caused from displaying a 3-D object on a 2-D plane. Also we can better edit and compensate for pixel distortion across the mesh. And by editing directly on the model we can easily smooth seams between the front and back of the model and between connected model pieces.
Is the texture budget known from the outset of game development, or does it fluctuate over time? Is that decision handed down from John?
The texture budget is not specifically known, but is estimated. Due to limitations in the engine, a map file with all its polygons, textures, and entities needs to be under a certain size. Since the map designer is closest to the map we rely on his judgment. If he says he can use more textures we do our best to make them.
From some of the columns that Brian Hook has written for Game Developer Magazine, I get the impression that the programmers on the team are pretty close. Is it the same for the artists and animators?
Not to knock the programmers, but I think the artists are the closest team of all. You can’t work as close as we do for so many hours without either liking or hating each other. I see these guys more often than I see my own family.
I have to say that all the guys I work with are the best people I know. Not to say we’re all buddies and hang out together. However, on a “respect” level they are the best. They’re all honest, talented, hard working people that basically dedicate their lives towards making games.
Does the fact that the engines in id‘s games get so much attention from the press and public (rather than your games’ visuals) ever bother you, Adrian or Paul?
The attention does not bother me at all. I’m not big on public attention, and Adrian is even less concerned with it. Not a week goes by without me praising my luck for landing at a company like id. And the primary reason for id‘s extraordinary success is John Carmack’s technology. Without a doubt, he is a genius programmer. And in an industry driven by technological advancements, new technology is the big story.
What is troublesome is that the emphasis on technology often leads magazines to characterize id as a tech company. Though technology is the primary reason for id‘s success, it is not the only reason. It is difficult to explain because so many people see technology, design and art as three separate elements that can be created without concern for the other. Game design, art, and technology are all equal parts of the same equation. Even that is an understatement because each element is so dependent on the other.
You can drop a Ferrari engine in a school bus, but who would drive it. The public recognizes that design influences the way that engine performs, is perceived, and enjoyed. In the end people don’t buy a game because they like technology, but because they like the game. And the fact that our games are played by so many people is proof to me that the efforts of everyone at id are recognized.
Project Management At id
Talk a little bit about id‘s process of conceptualizing, designing and testing the look of characters. Do you have a lot of control over the look as you go along, or is the look of characters and environments largely predetermined and you execute decisions made by the team?
The general game ideas are determined during several group meetings. Generally I organize and direct the meetings, but the ideas for the game come from everyone.
From information determined in these early meetings I create a basic design document. It primarily focuses on the game play goals and the elements needed to achieve those goals.
The design document is not a bible, but a starting point. I don’t like a static system broken up into rigid stages. It may be comforting to say, “I’ve designed the game and now that process is finished.” However, it implies that your first ideas are always your best, which logically we know is incorrect. A creative process needs to be dynamic. Talented people can manage riding the waves created by a changing and improving product as long as they have some control over the project’s destiny.
Once someone starts on a level, model or graphic it is his to create. Each person controls his work as long as it fits within the overall plan for the game. Tim Willits oversees the quality of the levels in progress. Most of the art comments are done informally. Adrian, Paul and I share an office and discuss each other’s efforts regularly on an informal basis.
We have regular meetings to review the progress of the entire game and make comments to it. The guys here are responsive to the opinions of the team. The bottom line is that everyone does their best to make their work the best it can be.
Are there ever times at id when you have to say “whoa, we can’t implement features x, y, and z in time” or are your instincts good enough at this point that you can gauge what the team is capable of from the outset?
In general we know what features we can implement in a given time, but inevitably we shoot higher. I rely on the person doing the work to make the final assessment. That is why it is so important to involve everyone in the creative process as early as possible. Since our game design is created in cooperation with the entire team poor design requirements can be pointed out early.
Most of our goals have priorities associated with them. Even though it doesn’t gain much attention, much of our effort is spent on tweaking the moment to moment interactions when you encounter a monster, shoot, move, or get shot. Making the core game fun is our primary goal. All the ambient effects, special events and story line in the world won’t help an action game if it isn’t fun to move and shoot.
In the end it is always necessary to cut something. Sometimes a new idea just doesn’t work or clutters the game. This decision is more difficult when one part of the team has already spent time working on it. However, you try to make the best decision and move on.
It is frustrating when an idea is cut because of time. However, if the idea doesn’t directly support the major design goals of the game it sometimes happens. id has never been contractually obligated to meet a deadline. The quality of the game comes first. We have always reserved the right to decide when the game is ready to go.
Certainly you can always remain silent on the issue of deadlines. But deadlines are as important for the development team as they are for the publisher. For a developer the process of creating is never ending. It is a matter of discipline. You can create one game the rest of your life or finish it and move on to the next great game. Having our game enjoyed by the public and experiencing new challenges is what drives us forward. Knowing when to finish is good for the team.
As a side note, I find it interesting that some magazines rail against the idea of deadlines, claiming the industry has become too corporate. This is ironic given that most magazines are written three months prior to release and contain more than 60% ads. I guess hypocrisy sells as well as anything.
How much technical experimentation goes on during development?
Quite a bit of experimentation goes on during the development of the game. Expending effort experimenting for no apparent gain is often frustrating. However, that is simply the cost of doing business in this industry.
Games need to have new discoveries if they are going to appeal to your core audience. Also, experimentation is healthy for the team. The thrill of creating is what makes game development so exciting.
For Quake II, most of our team was new to id and didn’t have a great deal of computer game design experience. We could have taken the easy path and made Quake II a simple sequel to Quake. However, we weren’t happy with what Quake offered as a setting for a sequel so we started over.
For me Quake II wasn’t just the making of a game, but the building of a new team. We set our goals both in terms of game play and scheduling and did everything we could to achieve them. The last few months wasn’t a matter of proper scheduling, but pure human effort. Carmack once said that people are at their best working in a pressure cooker. I think that Quake II was proof of that.
Have you started having meetings about Trinity yet? If so (and assuming you can talk about it), what goals you have for yourself or the art within that project?
We have had discussions about Trinity. However, right now Trinity is in the hands of John Carmack. As he makes different program discoveries, the technology will begin to take shape. We’ve discussed various game ideas to give context to the technology. One of our goals is to try to break free of the current design path we’ve been on over the transition from Doom to Quake. When the technology is a bit more defined we’ll start talking more definitely about the game it will eventually become. Right now, it is best not to handicap John by setting in stone a game design that may eventually constrain his programming.
Currently Trinity has two different directions it is taking. One is a larger more detailed world. The other is a more complex and intelligent AI system. Neither can exist in their optimum state together in one engine. So sooner or later we’ll choose a dominant technology path.
How long were your days in the final push to get the game out the door?
The days were deliriously long. I was getting home at five in the morning and getting up four hours later. I adopted that schedule so I could see my baby daughter for about 30 minutes in the morning before I went to work. People were sleeping on cots, couches, and the floor. Todd and Bear managed the company’s business during the day and play tested the game through the night. We ate lunch and dinner, exercised and lifted weights all at the office.
Strangely enough it was more fun in a way than brutal. Like I said, the pressure cooker often yields the best results. The day after the project was completed people were coming up to me asking if I had something for them to do. I said, “Go home.” They replied, “Why aren’t you at home?”
I heard that Quake II was banned on the first day of sales in Germany? Is that true? If so, what was the reason, and what’s your reaction to that?
Actually Quake II was never banned. It has never been sold since their review board would not give it a rating. It may eventually be indexed, which means it can’t be sold to minors. However, due to liability issues some retailers may refuse to sale it under those conditions. Because the German government doesn’t like computer entertainment that has violent content, being restricted in Germany is a fact of life. We won’t change our content and they aren’t going to change their culture or government. So I really have no reaction to it at all.
What do you think about Mike Wilson’s g.o.d. (Gathering of Developers)? Is there any talk at id about that publishing option?
Let’s just say I don’t have faith in g.o.d. And right now faith is the only thing g.o.d is offering. It isn’t offering a proven track record, or an experienced distribution system. With a review board of founding developers to oversee product quality it isn’t promising creative freedom. What g.o.d. offers is the opportunity to be on the ground floor of a potentially publicly held organization.
I am not saying anything negative about the intentions of the organization or the developers. The founding developers of g.o.d. are all good companies interested in creating great games. They may be disenchanted with the normal publisher/developer relationship either in the areas of control and finances and believe this is the solution.
In my opinion the solution is in the hands of the developer, not the publisher. There are a thousand ways to make money, but if you want to be a successful game developer you need to remain focused on making games. If you consistently make quality games, the rest will follow. By joining g.o.d., id would be distracted with new economic risks, inter-developer quality reviews, competing release schedules, and discussions over competing advertising and packaging budgets.
If you want to create games without publisher influence you need to grow slowly and work off the income generated by your own games. If you ask for millions of dollars in publisher advances and work under milestones you are already agreeing to publisher control. After all, they are essentially paying your salary.
I’m not an expert on publishing, but in my opinion g.o.d.’s basic business structure is flawed. For some teams, g.o.d. could be an attractive publisher, but not for id. I don’t want other developers reviewing our games or controlling our publishing—even just a little is too much. I am not interested in the distraction of overseeing the quality and publishing of other developers’ products. And more importantly, I’m not willing to risk the efforts of this team on a beginning publisher still struggling for funding.
Alex Dunne is Editor in Chief of Game Developer Magazine.
QuakeWiki Projects
