|
|
 |
 |  | | | | |  | |||
 | ||||||
          |  |  | ||||
|
Extreme
Game Development: Using XGD, testing is not simply a good habit, but second nature. No feature, code function, or asset can be said to exist until it's been tested. Furthermore, all tests should be automated (this is compulsory with XP), and all these tests can be chained and run in batch-mode at any time. There are two kinds of tests: functional tests and unit tests. The producer, along with the game designer and the lead tester, defines functional tests when defining user stories. For each of these scenarios, one or several scripts need to be written, and the requirement is met when these scripts run successfully. These tests are then added to the global test chain to ensure that this requirement is never broken. On the other side of the production chain, the developers ensure unit testing, by performing one or more tests on each function or created asset. Programmers can use CppUnit, a dedicated unit-test toolbox. Artists can define automated scripts to test quantitative metrics. ("Are there no more that 4000 polygons in the highest LOD?", "Has the alpha channel been downgraded to 4 bits in my texture?", and so on.) Automating tests doesn't imply the end of the QA department. Human testers can concentrate on tuning gameplay, focus testing or ergonomic testing, all of these being subjective testing and unsuitable for automation. The result of these tests will be given to the development team during the feedback stage and then translated into new user stories if the producer finds it necessary. Practical Tools To Apply XGD It's finally time to focus on how to apply XGD techniques. All of these tools I'm about to mention will be used on our own projects at Titus. Some are already in use, while others are being progressively integrated into our development process. Project management. Project managers can track their XGD integration using the "XGD dashboard". This dashboard is a simple list of all practices and tools you, as a project manager, are currently using or would like to implement into your development process. Every six weeks, when performing your milestone postmortem during the feedback stage, you give a 0 to 5 score for each applied practice or tool you use. You also add a short comment about each one, and compute your general XGD score. The score's evolution throughout development shows you if your team is losing motivation due to XGD. If the score drops over several iterations, you have to ask yourself if XGD is really right for your team, or if you might not be better off trying another one. You can also check on team motivation during the daily "stand-up meeting", so called because the entire team stands around the project manager. The physical discomfort caused by standing ensures that the meeting stays short (around 15 minutes, tops). You can use this opportunity to communicate company news, but the main goal is for each member of the team to explain what they are going to do that particular day, whether or not they need help, and who they will be paired with. This kind of meeting is really easy to implement, and will likely be adopted quickly by the whole team. As the project manager, keep in mind that your role is to coach the team, not assign tasks or dictate how pairs are created. As stated earlier, one of the practices states that the team should be considered as a whole. Creating a game is a team effort, and not just the sum of individual work. All programmers are responsible for the code; all modelers are responsible for models and backgrounds, and so forth. Asset management. Since one developer can take on the work of another at any time, everyone needs to agree upon some ground rules. This is the reason why the coding rules and the art pipeline need to be defined beforehand - including object- and file-name conventions, coding conventions and indention rules, and so on - in order to reduce the hassle of adapting to someone else's style. Despite those rules, you might be confronted with situations where a developer unnecessarily modifies someone else's work, or you could even find that the latest code modification crashes all the unit tests. You can't possibly leave broken code in place, since milestones are so frequent and integration continuous. Therefore, an asset management tool is absolutely essential. Thankfully, several tools are available: Microsoft SourceSafe, Perforce, and NxN alienbrain are common choices. Some Open Source solutions also exist, like CVS or SvN, which can be installed either on a Linux or a Windows server. Game design. Some XGD practices and tools involve the game designer. For game-related user stories, the producer should seek the help and advice of the game designer. What is really necessary for a test to be valid is that it must include at least one scripted functional test. The game designer can also use a very specific tool for his work: UML - the Universal Modeling Language. XP actually recommends not using UML for extensive software design, but UML can be use to describe game design elements and interaction. [DEMACHY02] Using UML for game design improves communication between game designers and programmers, and can be useful in dealing with artists and management, too. A UML diagram is a good starting point that everyone can agree upon. For your designs, you can use simple UML diagram editors, like SmartDraw, or rely on more powerful solutions like Open Source ArgoUML and Rational Rose. A UML design can also be refactored using almost mechanical rules: new game design classes can be introduced, others can be removed, and interactions between objects precisely defined. For improving communication, feedback and simplicity, UML for game design is definitely an XGD tool. It can even be used to define functional testing of object interactions. Quality assurance. All functional testing should be performed using automated scripts. The best way to create automated testing scripts is to use your game's own scripting language, adding specific test bypasses. Any scripting language can be used, but you will probably rely on Lua or Python, if you don't already. What should be kept in mind is that all tests must stay in chain, and must be re-run frequently (at least once per day, during the nightly build). The total number of successful tests is the best progress indicator you can have for your project. You may also have to construct specific scenes for these tests. These test scenes will eventually be integrated into the test process and used over and over, not erased as soon as the test runs successfully (which is commonly the case in game development). The QA department can also add their own tests. Indeed, despite all the care taken during development, some bugs can get through and be detected during a QA test. It might be a good idea to record player activity onto the memory card, and then use the scripting language to replay this sequence. Imagine if your game crashed at a particular time, and your programmer couldn't repeat this bug after trying dozens of times. Most certainly he would lose both his temper, possibly even his mind, and finally declare the bug as not reproducible. Recording a player's sequence can help sidestep this problem, and then that test can be added in the test chain to make sure that the bug does not recur. Wish Us Luck! XGD is a new method for managing game projects to ensure that games are delivered on time. XGD was not invented from scratch. Rather, it is an adaptation of Extreme Programming (XP) to the game development process. As I said earlier, XGD is currently being rolled out at Titus Interactive Studio on two projects. I'll let you know in a few months how we fared using XGD -- which practices worked and which did not. Note that several "Extreme" practices were not covered in this article, so I recommend reading the XP books by Kent Beck to give you a better picture of these practices and help you understand the differences between XP and XGD. Finally, I wish to thank Randall Roberts, who's great with a keyboard and words. (He's the guy responsible for "the glass-walled penthouse office" analogy -- probably thinks that everybody works in one of those.) For further information Web
: Extreme
Game Development Web Site (mostly in French): Books: Ron Jeffries, Ann Anderson, Chet Hendrickson, Extreme Programming Installed, Addison-Wesley Pub Co, October 2000 References [CHARNE01]
: Jim Charne, "Time is of the Essence" [DEMACHY02] Thomas Demachy, "Programming a Game Design-Compliant Engine Using UML", in Game Programming Gems 3, Edited by Dante Treglia, Charles River Media, 2002 (End of the article) [FRISTOM02] : James Fristrom, "Treyarch's Spider-Man", Game Developer Magazine, August 2002 [GAMASUTRA] [IRVING00] : Francis Irving, Automated build process, Gamasutra feature article, December 2000 - http://www.gamasutra.com/features/20001208/irving_01.htm
________________________________________________________ |
|||||||||||||
|
|
Resource
Guide 
