Extreme Programming For Games Discussion
Extreme Programming For Games DiscussionGameDevelopment? can, in theory, benefit more than many other classes of application from XP because the flexibility required is very high because the requirements, as well as the code, are subject to change. A monolithic Master Plan (BigDesignUpFront) approach is quite likely to drown itself. And no, this doesn't mean people in the industry actually use it... -- CanisLupus
Why can't we extend it simply to the various units? Certainly design can be done collaboratively. Level building can be as well, to some extent. The one that hangs me up is PairArt? - two artists staring at one screen while one person moves vertices does not seem like a productivity booster. ;) -- TomPlunket
EditHint: slowly refactoring this into DocumentMode, as opposed to RavioliMode
Proposed Adaptations to ExtremeProgramming
In more detail:
There is a staggering lack of management skill within the computer games 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 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.
Games coders have an intricate binding with artists, so we need a development model that can deal with this massive communications need too.
Is there any reason (other than typical fear of change) that programmers and artists could not share the same bullpen, thereby creating an environment where communication is easy and cheap? This seems like a natural extension of the WholeTeam concept to me. -- BrianRobinson
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 OptimizationPatterns. The NeedForSpeed?, and the need for stability and maintainability, are diametrically opposed.
Are they? See RethinkingCompilerDesign.
Eventually, we must put it all together in a programming team. Such a team may well be run using ExtremeProgramming, but the question, "WhoIsTheCustomer?" 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.)
My vision is for a unified approach to the problem, which exploits symmetries in the problem domain. The idea of a RoleOfToolSmith? 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.
-- EddieEdwards
Eddie: On toolsmiths - IMO all coders should be involved in enhancing and developing the tools they use. The RoleOfToolsmith? is as a coordinator / lead developer of tools. They need strong skills in prioritizing as well as raw coding skill. -- JamesCrook
I would agree; toolsmiths are akin to specialists, and a fair XP dictates that there are no specialists (or at least they're minimized). Having a full-time specialist is bad. :) Tools to solve a problem should be written by the people who need the problem solved. You wouldn't hire someone to just code editor macros all day because different people need different macros, and the end user is the one that knows the requirements so can most easily do the development. On tools - such as plugins to 3dsMAX, get the people who are doing rendering in touch with the people that know the 3ds API and watch the sparks fly. -- TomPlunket
Missing in Xp...
We cannot simply bolt XP onto an existing production strategy - well, maybe we could if there was an existing production strategy that manifestly worked, but in my experience (4 games companies) there is NO existing working production strategy. In the case a game gets released, it is released because all the programmers and many of the other staff work 100 hour weeks. XP promises a FortyHourWeek, and I like that (esp. as a soon-to-be-married man).
The problem is 99% communication. XP elegantly solves the communication problem between programmers. What about the communication problem between programmers and artists? Can we extend XP to contain "views", where in one "view" the artist is the customer, and in another, the publisher is the customer? This would allow XP to be applied, using the same principles of "stories", but stories would now come from the other departments which depend upon programming, as well as the customer.
Everyone depends on the programmers, but it's not a simple pipeline. Designers require custom design tools or format convertors from OTS design tools. Artists need much the same, plus a graphics engine which meets their artistic requirements ("we're not doing another DOOM game!")
Programmers form a unit. These guys write code. Artists form a unit. These guys make content (I'll include sound effects here) Level designers form a unit. These guys make levels.
Programmers talk to the customers. We're making one end product, but we have a variety of products that we need to build. For some (most) tasks, Design is our customer. For other tasks, Art is the customer. I let Art and Design figure out priorities between them. They can figure out how model exporters and animation playback systems need to be scheduled relative to AIs and design tools between themselves.
In some ways, Game Development is really cool because we always have customers on-site. The game changes a bit when you're doing XP though due to Publishing coming up and dictating these and those changes. In this case, however, the Developers' position is strengthened because you're already used to on-the-spot cost analysis. If Publishing wants those changes, you can tell them how much they will cost, and tell them what expense will be thrown away in making the change. -- TomPlunketz
What Games Designers really do
A good designer is a game architect. They maintain the creative vision. They are the main fun engineer and lead creative person. One of the common causes of lame computer games are programmers who think they can design. (See comments about people who think they can manage and do not know they can't.) A lot of communication problems in game teams stem from not having a lead designer. In game people will not only lose track of what they are supposed to be making, they will not even agree on what they should be making. You get things cool in isolation that make no sense as a whole. More often you get things that are not cool alone or combined, except to the author. I could rant at (greater) length about this but won't unless someone wants to hear it. -- KenMegill
Central Vision Is Important
The problem of a central vision for a game design is related to a problem that ExtremeProgramming tries to address for programming. A motley rag bag of routines in different styles is quite the opposite of what Xp aims for. In my book Xp allows a small team of programmers to work as if with one mind creating a 'central vision' for the software's implementation. More and cooler programming can be done than one programmer, however brilliant, can do on their own.
IMHO the crucial part to Xp is multiple drafts. In Xp, Programmers have to be taught how to criticize each other's work productively, as a first step in redrafting. Good programmers, IMHO, naturally do this for their own work, but really have to learn to do this in a team context. The whole business of 'stories' (which I must own up to not having tried yet) is giving a formula which takes some of the emotional investment in being right out of the process. Once redrafting happens as a team effort, a 'central vision' can emerge. At least it can emerge for software implementation.
Surely the Xp formula CAN be extended to other realms. And we don't have to be as simplistic as applying it separately in each of the three so-far identified units art, code, gameplay.
So, to extend Xp to the other units, do we perhaps need greater clarification of what the various roles really do? Are we not in fact better factoring our definition of what the problem is? If so, what is RoleArtist?? Do artists 'merely draw what they are told' just as we programmers 'merely implement the design' and designers 'merely make levels'? Surely each 'unit' sheds a spotlight on some aspect of the design, and 'A Central Vision' is important from each of these points of view. I don't expect an artist to fully grok what a coder means in saying their code is in ExtremeNormalForm, any more than I expect to fully understand Artistic Integrity, or Design Integrity. Even so, productive criticism across unit boundaries is possible. We all know enough to recognize when the code isn't buggy, the artwork looks great and the game really zings along. -- JamesCrook
Cultural issues in adopting ExtremeProgramming for GameDevelopment?
ProgrammerTests in GameDevelopment?
Why can't you test a graphic engine, and who says they can be sloppy? For given input data you know exactly what you're going to get on the back end, so write the damn tests and don't cry about not really understanding the code you're writing. You can test your code because you know what it's supposed to do. A vertex at this position with this matrix is going to show up here on the screen. Use your calculator and figure it out. I don't see how this is any different from testing whether or not messages sent to an object get there. -- TomPlunket
EditText of this page
(last edited August 6, 2005)
or FindPage with title or text search