1. By: Mike Astarb, Christine Miller, George Sewell, Bobby Mclaughlan

2. Code::Blocks IDE for C++ Google Code w/ Subversion Repository Project Hosting TortoiseSVN for local Repositories Cpptest C++ Testing Suite SDL Multimedia framework for C++ TOOLS, LIBRARIES, AND FRAMEWORKS

3. Basic Animations and Draws Basic Collision Detection Joystick and Keyboard Control Working Credit Manager Movable Test Character Colliding Test Rock Basic Game Architecture Visual Foundation PROJECT ACCOMPLISHMENTS

4. BASIC PROGRAM ARCHITECTURE

5. Architecture BASIC OBJECT RELATIONSHIP ARCHITECTURE

6. UNPREDICTED ISSUES A few issues came up in our early development period Complexities of SDL Syntax for using inheritance in C++ Syntax for using virtual functions in C++

7. Number of People on Project: 4 Time Taken: semester Bugs Found: 2 Bugs Fixed: 2 Program: LocMetrics Number of Classes: 10 Source Files: 48 Directories: 19 Lines of Code: 4755 Blank Lines: 908 Non-Technical MetricsTechnical Metrics METRICS

8. Cyclomatic Complexity directly measures the number of linearly independent paths through a program’s source code Cyclomatic Complexity: 215 Physical lines of code, all lines regardless of content (includes comments, blank lines, ending and starting braces) Executable Physical: 2604 Logical lines of code: Executable Logic: 1376 TECHNICAL METRICS

9. Whole Team Pair Programming The Planning Game Small/Incremental Design Small Releases Test-driven Development Design Improvement/ Refactoring Collective Code Ownership Continuous Integration Sustainable Pace Coding Standards EXTREME PROGRAMING PRACTICES

10. The customer should be integrated into the team, active in daily decision making In a way we implemented this practice if we look at our team mates as the customer. Looking at it this way we were than able to ask our customer questions on a daily basis, which we took advantage of fully by asking questions and opinions of each other frequently The only issue with this mode of thinking is that our customer had a computer science background which will not be common in the real world, but was an advantage for us. WHOLE TEAM

11. Programmers working in pairs program every line of code delivered to the client We did not follow this programming practice precisely in the sense that we did not pair program every single line of code With this being said a lot of the code we produced was written during our pair programming sessions we held on Tuesday evenings We found from pair programming that we produced better code that would not need to be refactored further down the line We also found that pair programming saved time when it came to fixing errors, because syntax errors and most logic errors were eradicated by the second set of eyes which could more easily catch simple mistakes that might be harder to detect as the code becomes more and more complex PAIR PROGRAMMING

12. Client expresses goals through user stories, team then estimates costs and time, then the client prioritizes user stories. If we again look at ourselves as the customer then we the customer created user stories We then gave all user stories an approximate expected number of hours needed to complete each user story Then we prioritized what user stories should be completed first and which ones could be saved for later. During the semester we accomplished the first eight user stories we found the most important THE PLANNING GAME

13. The team, as a whole, owns the system software We frequently modified and refactored sections of code regardless of who wrote the code originally We did this for a couple of reasons, we did this when we noticed a code smell and a section of code needed to be refactored or when we were working on a particular user story that required changing previously implemented code. COLLECTIVE CODE OWNERSHIP

14. Was not a huge part of our project. We created 4 tests that originally work but two have stopped working due to reworking our code for collision. 1. updateTest – checked control state object for an update. 2. getTest – Checks SDL keyboard response 3. Collision – testFalseCollison – test should show that there is no collision.(with the way we reworked our code this test no longer works. testTrueCollison – test should show that there is collision. (again test no longer works at this time.) 4. We also created “test level”. We replaced the credit screen with a scene of ninja on a bridge with a rock to test our collision in a “real world” situation. TEST-DRIVEN DEVELOPMENT

15. Our releases were delivered every 3 weeks. Our first release was mainly behind the scenes work (working on our headers,.cpps and main game loop). In our second release we were able to display a start/credit screen and were able to enter and take away credits. Our third release allowed for interaction with the game using both keyboard and joystick. 1. First iteration Mainly spikes Completed multiple headers SMALL RELEASES

16. 2. Second iteration Completed five user stories Player should be able to see a menu User should be able input credit Credit manager object needs to display itself as an array of text character objects Credit manager should be able to recognize that a credit was inserted Animated objects need to load a sprite sheet and track display data. 3. Third iteration Completed three user stories Collision objects need to be able to detect their sizes and if they’re in a collision. Start menu should be able to display/animate itself Game should be able to use both keyboard and joystick Fixed bug where holding down the credit button would cause multiple credits to be entered. Fixed bug, collision bug where avatar could enter rock from above SMALL RELEASES(CONT’D)

17. Followed by using Google Code / Subversion, although not very strictly Never ran into any real issues even when files were not updated immediately CONTINUOUS INTEGRATION

18. Did not follow the refactoring techniques Moving code Main loop -> Level Adding parameters as they were needed DESIGN IMPROVEMENT

19. Naming Meaningful names Variables/Files: xIndex, maverickClassName.h Constants/Defines: P1_START Functions Prototypes first, define later Use comments to describe all function prototypes Class files Must have header and implementation files Use #ifndef for all header files CODING STANDARDS

20. Not a concern Most coding done during meetings Tuesday Nights Pair programming / Team programming Thursday meeting Usually just discussed project details SUSTAINABLE PACE