IrresponsibleUseOfFr's Journal: Problems Faced Due to Developer Taxes: Part 1 Features

The first part of this series of essays dealt with productions costs due to HD. Although, HD can be considered a feature in the marketplace of other possible features, it impacts artists more than programmers. It is my belief that artists can be added to a project late in the cycle, be given sufficient training to produce quality content, and work with mimimal communication between each other, thus avoiding "Brook's Law" of "adding manpower to a late software project makes it later."

But a related issue is: what about programmers? In next-gen games a number of complicated features are required to gain traction in the high-end. Examples include: Multiplayer (split-screen), Online Multiplayer, Graphics upgrades like (real-time shadowing, image post-processing), and a lot of features that people find in other games like character creation, customization. This is not necessarily a bad thing from a consumer point of view, but it does cut down on innovation. Time spent getting online multiplayer going is time not spent tweaking the AI for single-player. Time getting graphics features up to a level that it is competetive with other games on the market (like Gears of War or Resistance: Fall of Man) is time not spent on an innovative gameplay mechanic.

The days of starting a game from

int main(int argc,char* argv[])
{
return 0;
}

are over, it just isn't cost effective. There is too much work to be done, too many decisions that have to made and implemented. Despite the plethora of "good" libraries that are available on each gaming platform, the really hard problems are left up to the game. Is the game going to be client-server based or controller passed? How does it handle animation (bone or vertex based)? What systems are inplace to help optimize load times? How is the UI authored, and how does it interact with the code? What tools are around to monitor memory usage?

The solution is to start with a code base that answers and implements a large number of these questions in a way that will work for the product. The viable alternatives usually are: license a game engine or port a current-gen game to next-gen. Starting from first-principles and game platform libs is a more expensive way to begin. Theoretically it could be justified to write a custom game engine, assuming it would be used for multiple titles. However, most underestimate the significant cost, risk, and the fact that many organizations are incapable of doing it in a way that will be cheaper than buying an existing engine or porting. In fact, I will say most organizations are incapable of writing a game engine more cheaply than just buying one or porting existing code. I will even go as far to say, the more people involved in the engine, the less likely it will be a success.

When faced with the dilemma of many features and the mentality of starting from scratch (or we can do this ourselves in two weeks and it will be loads better), the unenlightened response is to add more programmers. There are certain reasons why I believe having team sizes of much greater than 10 programmers is a bad idea in the game industry. The first thing is that games are a very competetive market-place. It is important to be agile to survive and smaller teams do a better job. Secondly, designs are frequently subject to change. A perfect design on paper can turn out clumsy and no fun when actually implemented. It is important to adapt to that. Third, the game industry really feeds off passion. It is tough to have qualities like ownership, accomplishment and identity with a product if you are 1 person in 40 working on it. Responsiblility diffuses on large teams so that no one feels responsible for anything.

An objection might be the battle cry of: design better, dammit! I am sympathetic, but I think people's ability to see into the future is extraordinarily limited. And dogmatic adherence to design first leaves out prototyping which I belive to be just as important. A good design does not come out of a vacuum. The best decisions come from trying a bunch of different ideas out and selecting the best. Design vs. prototyping is frequently put as an either/or proposition. And it is to a certain extent because they both eat up wall time. Both need to be bounded and both should happen before development in earnest, yet there are a few outcomes to prototyping that must be addressed. One, it is tempting to take a prototype for a feature and turn it into a real feature. Two, for some features, it takes longer to describe how to implement it than actually implementing it. The best approaches is to do the design also. Do not attempt to get the prototype completely working in the design phase. Write a design based on what was learned, estimate the remaining hours of work and place the code for prototype in a patch file. For designs that take longer to write than to implement, I think a design needs to made regardless. For trivial tasks, the design should be trivial. But, more times than not, the programmer will go down a hole, and the programmer is left in midst of a mess, without a proper amount of time to fix the problem (because it is in the design phase after all) and without a design that another programmer could have pointed out the issues with during a review. Which is to say, all designs are worthless (from a design stand-point) if they are not reviewed. An unreviewed design effectively becomes notes about a task instead of a plan for attacking the task. Working on tasks for unbounded hours defeats cost benefit analysis which I feel is essential for enlightened product development.

The last thing that I would like to state about large development team sizes, is that brings about a situation where no one has a clear idea of what tasks are out there, what truly remains to be done and what the impacts are. This inability to grasp the whole picture at a reasonable level brings about churn since the left-hand is totally unaware what the right-hand is doing. When something happens to cause a collision, the planning starts being reactive to problems instead of provactive in avoiding them. These critical stops in the schedule due to unanticipated and unscheduled issues cause the types of unproductive periods that are the goals of avoiding via implementation of good process.