Software Engineering and Game Development

1. Software Engineering and Game Development Patrick McCarthy April 7, 2005

2. Overview • Reasons to Look at Game Development • Reasons to Consider Software Engineering for Game Development • Design and Implementation of an actual game using Software Engineering • Demonstration of final product

3. Why Games? • Average gamer spends $700 a year on games (14 full-priced games) • Average gamer spends 20 hours a week playing games • 10% of gamers play games 40 or more hours a week • That’s a full time job!

4. Why Games? • Renting is also a major market • 50% of gamers rent 11 games a month • 60% of renters eventually buy games they rent

5. Why Games? • Video Game industry was a $10 billion business in 2004 • Some games cost $15 – 20 million to develop and rising • Movies currently cost $80 – 100 million to film

6. Why Games? • Sales figures for top 2004 games • Grand Theft Auto: San Andreas $170,000,000 • Halo 2 $160,000,000 • Madden 2005 $120,000,000 • Spider-man 2 $43,000,000 • Fable $40,000,000

7. Why Software Engineering? • In 1980’s games were developed by 1 person • In 1990’s games were developed by 7-10 people • In 2000’s medium sized games are developed by 35 people • Some today need 100 or more people

8. Why Software Engineering? • Real-World example of team growth: • NeverSoft • 10 people developed Tony Hawk Pro Skater 1 • 50 people developed Tony Hawk Underground (Tony Hawk 5)

9. Why Software Engineering? • Games are getting much bigger • Jak and Daxter has almost 1 million lines of code • Doom3 has 780,000 lines which is quite small

10. Why Software Engineering? • Development times are quite long • Doom3 was in development for 4 years • Duke Nukem Forever had an original release date of 1998, and it is still in development today!

11. Why Software Engineering? • Five reasons to use Game Development to teach Software Engineering : • Breadth • Depth • Excitement • Simulation Applications • Career Preparation

12. Bringing it Together • John Flynt author of Software Engineering for Game Developers • Best way to show use of SE in games is through example • Gathered a team of developers in order to build a game strictly using SE principles from beginning to end • Designed, Implemented, and Tested a turn-based Egyptian style strategy game

13. Design • Started by writing a Game Design Document (GDD) • Lays down a foundation of how the game will be developed (37 pages) • Describes the story, graphics, sound, characters, and camera the game will have

14. Design Sati Priest of Isis - Betrayer of Meseru - Sekhem’s repentant guide

15. DesignItem List

16. Design • GDD also specifies movement and attacking

17. Design • Five Levels are Defined • Level 1 – Streets of Alexandria • Level 2 – Monastery of Nebukut • Level 3 – The Underworld • Level 4 – Canyon Oasis • Level 5 -- Temple of Uheset at Thebes

18. Design • GDD also defines the art style and the game script Sekhem: “I’d sooner deliver up my heart to a beast such as you.” Guard: “I was hoping you’d say that!” <The battle begins.>

19. Design • Requirements Gathering • The GDD is looked over for high level requirements • These requirements are placed into the Software Requirements Specification (SRS)

20. Design • The project was divided into 14 separate functional components called Stripes Stripe 1—Opening, Requirements 8, 16, 18, 38, 46, 14, 15, 17, 23, 28, 46, 57 Stripe 2.1—GUI Objects , Requirements 18, 52 Stripe 2.2—Floor Tiling, Requirement 43 Stripe 2.3—Mesh Placement, Requirements 43, 13 Stripe 2.4—Save and Load, Requirement 4 Stripe 3.1—Navigate Alexandria, Requirements 13, 14, 15 , 16, 17, 36, 61 Stripe 3.2—Sound, Requirements 29,30,31,32,33 Stripe 4—Character Editor, Requirements 18, 19, 20, 21, 22, 35, 44 Stripe 5—Unit Physics, Requirements 13, 14, 15, 16, 17, 35, (41), 47, 48, 42, 45, 64 Stripe 6—Inventory Items, Requirements 40, 49, 55 Stripe 7—Combat, Requirements 54, 56 Stripe 8—Acquire Skills, Requirements 20, 34, 47, 55, 56 Stripe 9—Acquire Weapon, Requirements 14, 15, 16, 17, 40, 49 Stripe 10—View Statistics, Requirements 14, 15, 16, 17, 18, 19, 20, 21 Stripe 11—AI, Requirements 24, 25, 26, 37 Stripe 12—Remaining Level, Requirements 27 Stripe 13—Saving and Loading, Requirements 1 ,2,3,4,5,6,7,8,9,10,11,12 Stripe 14—Options, Requirements 39 Nonfunctional Requirements, Requirements 50, 51, 53, 58, (59), 60, 61, 62, 63

21. Design • A total of 64 requirements were gathered • <Req_1> Software shall have the capability to save the game state from a menu • <Req_16> Software shall support a custom mouse pointer • <Req_29> Software shall support MP3 playback and allow the player to select his or her own music • <Req_43> Software shall support a Map Editor • <Req_56> Units gain experience and enhance their skill through combat • <Req_64> Software shall support a global system clock to synchronize events in the game

22. Design • Use Case Scenarios • Use cases were created for each Stripe • A total of 37 were made • An example Use Case is shown next

24. Design • Task-Object-Remarks (TOR) Table is constructed and added to the SRS • Provides a preliminary listing of objects

25. Design • Software Design Description document was written next • This is the “meat and potatoes” • It contains all of the major design pieces of each Stripe • It contains CRC cards, sequence diagrams, collaboration diagrams, and class diagrams

26. Design • The Five Views used in the SDD document

27. Object Diagram

28. Sequence Diagram

29. Collaboration Diagram

30. Class Diagram

31. Component View

32. CRC Card

33. Test Planning • Software Project Test Plan • Divided project into 3 separate sections

34. Test Planning • Software System Test Plan • Deals mainly with the Installation of the game • Specifies the testing environment needed (Visual Studio) • Contains 4 separate test cases

35. System Test Case 1

36. Test Planning • Software Component Test Plan • Tests the “meat and potatoes” of the game • Contains 58 separate test cases

37. Component Test Case 1

38. Test Planning • Software Integration Test Plan • Tests how each of the 14 Stripes come together to work as one game • Consists of 14 separate test cases (obviously)

39. Integration Test Case 1

40. General Test Report

41. Implementation • Software Configuration Plan • Defines the basics for implementation • Describes how files and folders are to be named and organized • Specifies the version control tool that is to be used (TortoiseCVS) • Explains default documentation

42. Implementation • Software Configuration Plan (continued) • States policies to follow: 1. Code check in should be performed after each work session. 2. Additions of external library resources are to be approved by the team and formally added to the shared configuration before they are incorporated into local code. 3. Files are to be cleared of test code before being checked in. 4. Files are not to be renamed and checked in. 5. Development using the server configuration of the software is to be each developer’s responsibility. (Try not to develop for days on end without submitted code for mergers.) 6. Conflicts are to be reconciled as soon as they are detected. 7. After a stripe has been baselined, development work on it is to be discontinued. Work should commence on the next version of the stripe or the next stripe in the development schedule. • States the Revision numbering system • States coding standards and naming convention for variable (Hungarian)

44. Demonstration • The game • The level editor • The character editor

45. Conclusion • SE and Game Development do work together well. However, use what works. • Mick West of NeverSoft stated “Do what is appropriate…There is no silver bullet, you have to use a rich mixture of techniques that suit the problems at hand. And more importantly, that suit the people at hand. UML is fine, but practically nobody at Neversoft has even heard of it, let alone could be comfortable using it. UML does NOT communicate if you don't know UML.”