IrresponsibleUseOfFr's Journal: Problems Faced Due to HD-Content

One particular problem that faces the game industry is the challenge poised by HD. Simply put, one could estimate that the XBox360 is ten times as powerful as the original XBox. However, it would be a mistake to believe all of that power is solely at the developer's disposal. One reason is the developer tax of HD. The framebuffer for the XBox to support progressive scan is 640x480. For the XBox360 a framebuffer of 1280x720 is required (three times as many pixels).

The point that I'm trying to make, and this might seem exceptionally crude, is that all the power of the high-end Next-Gen consoles is not being used to solve the same problem (unlike NES, S-NES, N64, to GameCube). High-end consoles and by corollary their games actually have to solve a larger problem. Simply put, the target moved.

This higher fidelity output requires higher fidelity input. More detailed textures, more detailed models, etc. At the end of the day, every single one of those texels or verts will be touched by a human being. I don't hold out much hope for procedural texture synthesis saving the too much labor on the texture end. Procedural texturing may take it 80% of the way, but I think there will always be a need for a human to twiddle with the results and clean up the artifacts. Procedural texturing is a tool for an artist to use, not a replacement. I think similar arguments can be made for other asset types that require higher fidelity.

The conclusion is that production costs on games are going to be higher on the high-end (XBox360 and PS3, not necessarily the Wii). In the face of this challenge, I would like to recommend that studios do not simply hire more artists. The problem is that production work tends to be uneven. It may take a long time to get a working level because features haven't been implemented, but after features and pipeline are in place the only limiting factors are skill and man-power. In that it may take one person a month to build character or a level.

This may sound like a classical man-month fallicy, but I don't believe it to be the case. As long as the assets are isolated and intercommunication is minimal, then man-months of effort is achieveable. Every level can be isolated from every other level. It isn't like one level is suddenly going to break every other one in the game. It wouldn't be advisable to split off one character to multiple people. But, I do think it is reasonable to get 5 artists all churning out a character in a month once all the pieces are in place. Admitadly, it only works up to a point, but in reasonable scales (4-6 months) I can see contracting upto 20 artists as a workable proposition.

The only reason I advocate this position is because production is uneven. In that very little production work can be done at the beginning of project, but a lot can be done near the end. If the production model is flat, and a ramp-up isn't planned for then an implicit assumption is that production work can be done during the early phases. In my experience, it simply can't. What ends up happening is the schedule says production work is done, when it actually isn't. Near the end of the cycle, when production gets unblocked, there is an unacceptable revisting of previous work which eats into future deliverables. Revisiting and debugging work from months ago, frequently without scheduled time to do so, is very unproductive and a key state that good process seeks to avoid.

My recommendation is to plan for ramp-up. Keep some staff artists whose responsibility is concept and prototype, get the tools solid, then contract the remaining artists near the middle to end of the project, when you have a proven production pipeline. The staff artists primarily responsibility at that point is to instruct and direct the building of the assets and troubleshoot.

I am not saying that it can't go awry, any software project can go awry. However, with production art work there are pieces that need to be put in place inorder to get production quality work done. However, if those pieces are not inplace (or are incomplete) developers find themselves implementing stop-gap solutions to get the artists productive to meet the schedule. But the artists never get productive because all the solutions are stop-gaps, and the developers never get the time to fix deep issues because they are too busy helping the multitudes of artists with the stop-gap solutions they've implemented. Which feeds into the fact that production quality work isn't really getting done.

Plan for a ramp-up, contract the artists in, plan a few weeks of training, assume that 10-25% will not cut the mustard and watch their output like a hawk. I am not stating that this is an ideal scenario, but I think it is better than the alternative scenario and will keep overall production costs down.