Closed Beta Report
This two week-report covers what you did to get ready for closed beta release. This report has exactly the same format of the previous one. You will have another CATME survey asking how you worked as a group. In addition, you should fill out a short report documenting what tasks were completed and what tasks a proposed for the next milestone.
If you received any negative comments about your previous report, you should address those this time. 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.
With that said, there is one more thing we need in this report. Every master’s student is expected to make a CUGL and/or design tutorial for this course. In this report, each master’s student should propose what they will do as their tutorial.
Table of Contents
Progress Report
This report will have a simiarly format to what you submitted for the alpha release. First of all, the report should begin with a short description of what the entire group did for this release. For example, what work was required for the level design, and how did you approach it?
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. We should have included this previously, but we forgot to add it. We are paying more attention to it for this 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 release, you should layout your plans for the next stage, open beta. This release should be somewhat finished, but possibly buggy. It will be your last in-class release before Showcase (e.g. this is analagous to “final release” in the introductory course).
Unlike the introductory class, you will have two full weeks between this release and Showcase. Therefore, there is plenty of time to work on code fixes and extra levels during that time. However, you will not get any more feedback on your design after this presentation.
As with the progress report, start with a short, overall summary of what you propose to do. Remember to include the app store proposal (a very short document) as well as your goals for the second beta release. In short, this paragraph should constitute the deliverables for the next assignment.
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 preparing for the app store page
- Time spent on the open beta release.
- Time spent on level design.
- Time spent on art or music assets.
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 responsibilities among your teammates. In particular, you should use what you learned about your group dynamics in making the closed beta release to assign responsibilities for the second 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.
Tutorial Proposals
This report will have an additional, third section. As explained in the grading guidelines, each student enrolled in either CS or INFO 5152 must create a tutorial for future students in the class. This should be a short tutorial about how to do something that was not explicitly covered in a lab. It does not have to be as long as a lab. Ideally it should be something that takes a student 1-2 hours to read through and understand.
For programmers, this means tackling some unique feature of CUGL that we do not cover. It could be how to do something interesting with the audio system. It could be how to use dollar gestures or some form of gesture recognition. It could be how to write post-processing shader. It could be how to extend the obstacle classes to add new box2d features.
For designers, we do not expect you to do any programming. But best practices on how to design a button are good. As are any animation tutorials. If you are unsure of what might be useful, talk to one of the design TAs.
Whatever you decide, we are not asking you to give this to us now. We just want a proposal. Tell us what you want to do. We will respond with how much we expect from you on that tutorial. Tutorials will be turned in during finals week.
Submission
Due: Sat, Apr 20 at 11:59 PM
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.