We designed our game in iterations.

We designed our game in iterations. We spent approximately 5 days to 8 days per iteration and developed much of the core of the game in the first 2-3 weeks. After designing the core, we then started the iterations on tweaking and feature adding. We got through the first iteration before the Alpha release, and with the knowledge we gained from the Alpha release and the survey, we went through another two rapid iterations before the final release.

We have a minimum of five meetings a week:

During the first 3 weeks of the project we had a minimum of five meetings a week:

After the alpha release, our meetings became a little more scattered; however, we always had a minimum of 4 meetings per week a constant flow of email to keep everyone up to date.

Use feasibility analysis and prototyping

Use of feasibility analysis and prototyping

We have code freezes planned at every prototype. There are certain features that have been deemed as "crucial" and others as "nice" and others as "not likely". We develop the game using an iteration scheme which emphasizes the crucial aspects of the game and in the later iterations, should we have time, we can add in some of the nice and not likely effects and features. The code freeze for the final project is on Wednesday December 15th. We intend to work on documentation an during the last few days of the project. We will be keeping a very constant log of everything we do and there will be comments through out the code, but things such as the final report, user guide, and final presentation will be done in the final days.

test early and often

There are several key concepts we followed when testing our product.

Test early and often (Unit and Integration Tests)

Before code was ever committed, it had to be tested thouroughly by the person who developed this. When ever code was committed, the other members of the team would immediately grab it and compile with the new code and see if their new changes integrated well and just to double check the other person didn't miss something. This kind of redundancy allowed nearly no room for bugs.

including unit test

integration tests

playtests

Whitebox Playtests

Before anyone tested out code, we went through and tested many boundary cases (especially for the collision code). We also logged at least 7-15 hours of playtime for each member during development. After every feature was added we played for a minimum of a couple minutes making sure that the new feature was tested and nothing else was awry.

Blackbox Playtests (Alpha and Beta testers)

We obtained very directed information from our alpha testers through a survey which we distributed. We were fortunate enough to also obtain a fair amount of other ideas from the alpha testers regarding their overall experience with the game. After incorporating some of these ideas, we then made a beta release which friends and family could test. We received more feedback and when the blackbox testing was finished, we had a much better product to deliver.

We used CVS extensively in this project. We had to manage a code base of approximately 15KLOC, so CVS made everyone's life much more pleasant.

We use CVS and the documentation can be found at:

%META:TOPICINFO{author="AaronArvey" date="1102320600" format="1.0" version="1.1"}% %META:TOPICPARENT{name="ProjectThree"}%

Our Development Process

Here are some good links to look at:

• PlanDocuments
• CodingDocuments

Here's a little more information on how we developed our project:

Iterative development

We designed our game in iterations.

Major Milestones

Please see PlanDocuments and CoolPresentations

Weekly planning meeting

We have a minimum of five meetings a week:

• Sunday night
• Wednesday night
• After class on Tuesday
• After class on Thursday
• One misc meeting every week, or at least an "email meeting"

Risk analysis

Please see CoolPresentations

Use feasibility analysis and prototyping

Please see CoolPresentations and PrototypeCountry

Work breakdown

There is a near weekly work breakdown at PlanDocuments

Pert and Gantt Chart

This can also be found in PlanDocuments. The Gantt chart seemed unnecessary with work breakdowns being done for every week

Use Cases

See CoolPresentations

Class and Sequence Diagrams

Please see CodeDocuments

Code Freezes

Testing

test early and often

including unit test

integration tests

playtests

Individual logs

Please see ContactInfo

CVS

Please see CvsInstructions

We use CVS and the documentation can be found at:

-- AaronArvey - 06 Dec 2004