Objective:
To adapt XP practices for use in game development.
Differences between games and VanillaXp projects
A game includes programming, design, and art, plus other disciplines if you want to use a narrow definition of "art" (excluding, for example, music and voice acting). Each of these teams is a customer of the others, which requests features from them and works within the constraints they set.
Team sizes for big-budget games are very large. As early as 2004 one saw teams of 100+ people working on a title; as of 2014 that number has further grown (although very small groups -- one person or a handful -- have lately been doing quite well for themselves as well).
Games' requirements can be fully known in advance, fully specified up front, and changed to suit the development process' convenience, and they are not changed by external events. This isn't ChryslerComprehensiveCompensation.
Fitting the ExtremeProgrammingCorePractices to games
As stated in ComputerGamesIndustry, computer game projects vary enormously. Therefore, adaptions of XP to games must likewise vary -- if it makes sense to create them at all. See the limitations listed below.
- ProgrammerTests
- There are no unresolved problems with using this practice, as is, for all original game engine and game scripting code. The programming team may need to create a testing framework for the the design team script programmers to use. Testing hardware is often presented as a problem, but MockObject allows us to create such tests.
- In projects with a high degree of existing and untested code, UnitTestingLegacyCode provides some helpful suggestions.
- Although not strictly programmer tests, automated tests can also be used to automatically enforce art asset limitations. This prevents time being wasted while searching for problems with source data.
- PairProgramming
- This practice can be used for programmers in every instance except for developments with only one programmer. Many game developers are of the opinion that you will never get game programmers to pair. However, there are recorded instances of game companies and programmers pairing, eg:
- This practice should also be used for designers when working on scripts. Game scripts now typically account for more code (lines of code) than the game engine itself. Because many designers lack previous experience in writing code, script code tends to be poorly factored and buggy.
- Pairing has no practical role to play within an art team except perhaps in training situations.
- SustainablePace
- This is often held as a contentious issue within the games industry but there is no good reason why any game company cannot introduce this policy. Although there are many examples of computer game companies where mandatory overtime is rife, there are companies that have avoided it. One such example is CoyoteDevelopments, who recently released two games back to back, and under aggressive schedules. Although the workload increased considerably around the release dates, the extra work was reclaimed through informal use of FlexTime. Coyote are now adopting flextime formally as company policy.
- WholeTeam
- Small game projects should be able to adopt this practice without any adjustment.
- For larger teams (over a dozen) there are problems. It may be possible to divide the project into smaller sub-projects, each of which may be able to adopt XP like practices. Natural large scale dividing lines within a game project are: engine, scripting, artwork, tools. (EditHint: add references to work arounds for larger teams here.)
Problem(s)
- STRONG requirements for flexibility in design, as games develop. BUT solution of 'ExtremeProgramming' (as it currently stands) seems to be undermined by existing (deficient) management style which is:
- EITHER ad-hoc style - managers don't treat management as a learned skill.
- OR production-line management - resembles bank managers of 60s sitcoms.
- STRONG requirement for communication 'Games coders have an intricate binding with artists', BUT currently we are missing a development/management model that recognizes this explicitly.
- STRONG requirements for reuse. BUT solution of ObjectOrientation seems to be undermined by the need for extreme optimization.
- With managers, it's hard to teach OldDogsNewTricks.
- Artists and coders talk different creative languages.
- MostGamesProgrammersDontGrokObjectOrientation -- and object orientation can get in the way; see EntityComponentSystem?.
- Automated unit tests can't tell you if your art is ugly, your writing is cheesy, your music is simplistic, or your gameplay isn't fun.
- The design can be known up front, except in cases of extreme mismanagement, so a full, complete specification can be drawn up in advance of beginning work. Drawing up such a full specification can often reveal problems with the game, i.e., if it's boring, or if elements are more trouble than they're worth to pursue, or if there are internal contradictions.
The implied premises in the problem statement are believed to be true in at least some part(s) of the ComputerGamesIndustry.
The following are no longer considered general problems within the ComputerGamesIndustry:
Reuse (NotInventedHere syndrome)
In the late 90's there was still much resistance within the game development community to what is now known as MiddleWare. Several highly profitable game successes using MiddleWare have somewhat changed the landscape. The MiddleWare success that most contributed to this shift in attitude was the release in 2001 of Rockstar Games' GTA3 (http://www.rockstargames.com/grandtheftauto3/) which used Critereon Software's RenderWare.
Links
At http://www.gamasutra.com/features/20000628a/fristrom_02.htm they mention doing pair programming in game development. They even reference the Wiki.
Thomas Demachy wrote an article about his adaption of XP (XGD) on GamaSutra: http://www.gamasutra.com/resource_guide/20030714/demachy_01.shtml
http://www.ExtremeGameDev.org/ is a Wiki on XP for games in French and English.
Kai-Peter Backman of Mistaril Games has written a PostMortem of their game Space Station Manager: http://www.mistaril.com/about/post_mortem_ssm.php
Mail Links
The "Software Engineering Gamedev" mailing list has a large (seemingly) contingent of games programmers who do grok object oriented programming, some of whom are also actively trying to find a way to adopt ExtremeProgramming.
To subscribe go to:
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
The list is alive and well, but it's somewhat "bursty", so there might be periods of a week or so with hardly any messages, and then a few hundred messages in a couple of days.
See also ComputerGame, CabalDesignProcess, ExtremeProgrammingForGamesDiscussion.
Extreme Programming For Games