CIS 3000: Introduction to Computer Game Design

Two-Week Report 4
Beta Complete Report

Due: Saturday, April 23rd at 11:59 pm

This two week-report covers what you did to get ready for beta release. You know the drill by now; this report will have exactly the same format of the previous one. It is a summary of the work that you did in order to get your game to beta complete. Second, it is a retrospective on how good your predictions for your beta release were. Finally, it is a prediction of the amount of work you will need to do to reach final release (but not Showcase!).

If you received any negative comments about your previous report, you should address those in this report. We do not want reports to be revised; we always want to be moving forward. However, we will take off for mistakes that are made twice in a row.

Progress Report

Your report is divided into two halfs: the progress report and predictions for the next milestone. In the first part, you should begin with a short description of what the entire group did for these past two weeks. Obviously you worked on the beta release and game manual. However, did you do anything else? In particular, what type of effort went into your level design?

This description should be no more than a paragraph or two. After this summary, you should begin a more detailed breakdown.

Activity Breakdown

Next you need to break down the work for each member of your team. For each team member you need to create a subsection. At the start of the subsection should be a short description of the primary responsbilities of that team member over the course of this prototype. This needs be no longer than a paragraph.

After this paragraph, give a bulleted list of each activity which this team member was involved in. Remember to include the hours worked. Do not be ashamed of how much you worked. We never count off for not working "enough" hours. However, hours give us an idea of who is being productive and who is not. This allows us to make suggestions for improvement in later milestones.

Finally, give a short (one paragraph) assessment of whether these activities were a valuable usage of time. If not, what could that team member have been doing instead?

Productivity Analysis

Once you have detailed all of the activities, you should make comparisons to your projections from your previous two week report. Did you do what you said that you were going to do, or did you do something else? In particular, you should report the following:

  • What took more time than you expected?
  • What took less time than you expected?
  • How does this effect responsibilities in the future?

You can either do this as a section following the activity breakdown, or within the breakdown. If you put it in the breakdown, that means this assessment needs to be person-by-person, instead of for the group overall.

Milestone Predictions

Once you have finished the report for this prototype, you should layout your plans for the next stage, final release. The final release should be a game that could be turned in for a B. It may not be fun or it may be buggy, but it is serviceable in case you had to blow off this course to concentrate on your other finals. The only thing you should do after final release is modify your levels, fix bugs, make minor gameplay adjustments, and clean up the art.

As with the progress report, start with a short, overall summary of what you propose to do. Remember to include the game website as well as the alpha release. Describe what type of level you are shooting for in this release. In short, this paragraph should constitute the deliverables for the next assignment.

Test for Acceptance

As in the milestone document, once you identify deliverables, you need to measure success. Remember, imagine that we are grading your milestone deliverable. How would you like us to evaluate it for a grade? What would count as an A, and what would count as a B? While we are still not assigning these types of grades, this is an good way to create this type of test for acceptance. Please consider our feedback on the milestone document when constructing your test.

Risk Assessment

What are you the most worried about in this upcoming milestone? What could possibly keep you from earning an "A", according to your test for acceptance? Again, consider our feedback on the milestone document when answering these questions.

Activity Breakdown

For each team member, you should describe their responsibilities (in detail) as well as how much time the should be spent on each responsibility. Remember that the time that you assign to each team member should add up to about 10 hours a week (e.g. 20 hours over the two weeks). However, there are a lot of things that you are going to be doing over this period time. You should be very liberal in how you count the time spent by each team member; include all of the following:

  • Time spent discussing in group meetings
  • Time spent on the game manual.
  • Time spent on the beta release.
  • Time spent on concept art (artists).
  • Time spent on musical tracks (musicians).

In estimating time spent, you should try to do the best that you can; as part of the next two week report you will be asked to assess how well you do in distributing responbilities among your teammates. In particular, you should use what you learned about your group dynamics in making the alpha release to assign responsbilities for beta release.

The format for this activity break should be exactly the same as before. That is, have a subsection for each team member. For each person, give a short description of their primary responsbility. Then give a bulleted list of activities with hours.

Submission

Due Saturday, April 23rd at 11:59 pm through CMS.

You should submit a PDF file called report. Again, we ask that the file be a PDF so that we cannot annotate it in order to return it to you with feedback for possible revision. It is fine if you create the document in a program like Microsoft Word, but you should convert it to PDF before submission.