Computer Game development is extremely hard. It demands excellence in all fields - programming, graphic and audio design, and game design. Consequently it also demands excellence in methodology, and this is nowhere to be found. The result is 100-hour weeks and a high occurrence of burn-out.

There is a staggering lack of management skill within the industry. Almost every company has grown from a small and motley crew of programmers and artists, who manage the organization by default. This is reasonable insofar as it is acknowledged; unfortunately, many of these "managers" believe that management skill is inherent not learned, and even the evidence (that they do not have the necessary skills and therefore the project is failing) will not convince them.

At the other end of the scale are companies such as ElectronicArts, which employ a production line metaphor and manage their staff in ways which resemble the bank managers in 60s sitcoms. They get results, but the morale suffers as a result. Many creative people have left such places and formed their own companies, who belong in the above class.

My vision is for a unified approach to the problem, which exploits symmetries in the problem domain. The idea of a ToolSmith is an important one - programmers, artists and designers all need tools. A well-written tool could serve all these needs in a unified manner, rather than (as is typical) having a bunch of tools all different and all incompatible. I believe we can justify the cost in terms of increased productivity; but if one employs reuse in a broad way, one can spread the cost of tools over several architecturally similar projects.

Reuse is vital. Software is extremely expensive to develop, and no-one makes a profit from a game that has no sequel. Of course, sequels can be made without naming them after the original game - we reuse the technology, but not the concepts (assuming it was the concepts that failed in the marketplace - if the concepts succeeded in the market place, we do a straight sequel). A game cannot usually be adapted to serve a modified purpose - especially not one written as spaghetti code! But modern computer technology is mature enough to allow a modular approach to the design of the important pieces of a game - graphics engine components, overall system architecture, sound library components, etc. And a modular approach asks for - nay, ''requires'' - ObjectOrientation, and MostGamesProgrammersDontGrokObjectOrientation.

This form of reuse is broad. Lesser forms of reuse should certainly be possible within the industry, but are too microcosmic to be seen by the ComputerGamesIndustry in the large.

Once we have determined that profitability comes from ObjectOrientation, we look to object-oriented design practices. But we must never forget the need to optimize code ... again, an assumed (but highly arguable) prerequisite for success in the marketplace. Perhaps, as well as DesignPatterns, we will look to OptimizationPattern''''''s. The NeedForSpeed, and the need for stability and maintainability, are diametrically opposed.

Eventually, we must put it all together in a programming team. Such a team may well be run using ExtremeProgramming, but the question, "Who is the customer?" poses a difficulty - programmers answer to not only the publisher (who finances the game) but also the artists and designers. The publisher may or may not provide user stories; the artists and designers most certainly will.

If we can answer this question, and unify the communications across teams by modelling the art and design departments as pseudo-customers, then ExtremeProgrammingForGames promises to solve the ultimate problem, that of project management (I assume here that ExtremeProgramming ''per se'' solves the majority of management problems, which is why it is so valuable. It tells us how to manage the project.)

-- EddieEdwards

OoIsNotAboutReuse