To adapt XP practices for use in game development.
Differences between games and VanillaXp projects
The most obvious difference is that a game is an intimate collaboration between three separate disciplines: programming, design, and art. Each team is effectively a customer of the other two. For example, although the art team request features from the programming team (such as bump mapping or pixel shaders) they must also work within limitations set by the programmers (eg. all textures must be square or powers of 2).
Recently team sizes have been booming. It is now (in 2004) not uncommon to hear of 100+ developers per title.
Unlike a custom business application with a real concrete need to fill (eg. payroll) games are purely entertainment. There is no real world source of requirements to guide the customer.
Fitting the ExtremeProgrammingCorePractices to games
As stated in ComputerGamesIndustry
, computer game projects vary enormously. Therefore, adaptions of XP to games must likewise vary.
- 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.
- 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.
- 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.
- 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.)
The implied premises in the problem statement are believed to be true in at least some part(s) of the ComputerGamesIndustry.
- 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 may talk a different language.
- ..and sadly MostGamesProgrammersDontGrokObjectOrientation.
- Finally an (automated) unit test can never tell you if your art is ugly. This seems to preclude Xp for at least some parts of the project.
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
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
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
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:
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