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

GAME CONSOLE

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

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

BASIC PROGRAM ARCHITECTURE

ArchitectureBASIC OBJECT RELATIONSHIP ARCHITECTURE

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++

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 Metrics Technical Metrics

METRICS

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

• 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

• 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

• 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

• 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

• 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

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

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

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)

• 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

• Did not follow the refactoring techniques

• Moving code• Main loop -> Level

• Adding parameters as they were needed

DESIGN IMPROVEMENT

• 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

• Not a concern• Most coding done during meetings• Tuesday Nights

• Pair programming / Team programming• Thursday meeting

• Usually just discussed project details

SUSTAINABLE PACE