Gameplay Prototype Report

This week you need to submit your first two-week report. The report should be two things: a summary of the work that you did in order to get your gameplay prototype working, and a prediction of the amount of work you will need to do to get the technical prototype working.

In the past, we have used this document for you to give self-assessments about how well you have been working together and whether or not your time has been spent wisely. This is now the purpose of CATME, so we do not need this information any more. Instead, as part of your two-week report, you will fill out the CATME survey.

However, there are things that CATME cannot handle, like the task breakdowns. Therefore, we are asking for an abbreviated version of the traditional two-week report. We outline this report below. However, if you just want to see what such a report looks like, skip to the example below.

Table of Contents

Progress Report

Your report is divided into two halves: 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 gameplay prototype and gameplay specification. However, did you do anything else (e.g. animation, music)?
Furthermore, exactly what did you show off in your gameplay prototype?

This description should be no more than a paragraph or two. After this summary, you should begin a more detailed breakdown for each individual on the team.

Activity Breakdown

For each team member you need to create a subsection. At the start of the subsection you should give short description of the primary responsbilities of that team member over the course of this prototype. This needs be no longer than a paragraph. These paragraphs should be written in the third person, referring to each person by last name. This is the professional way to ensure this document has a single voice.

After this paragraph, provide a table where each row consists of the following:

  • An individual task that the team member worked on
  • The date at which this task was completed
  • An estimate of the number of hours spent on that task

In the example, the report compares these values to the predictions of the previous report. However, you did not have a previous report for this milestone, and so this is not relevant.

After the table, you should provide the total number of hours that this person worked over this reporting period. Please be honest here. 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.

Milestone Predictions

Once you have finished the report for this prototype, you should describe your plans for the next stage, technical prototype. The technical prototype is like the gameplay prototype, except that it needs to be a more polished piece of software and should show off some substantial engineering/developement challenge. For example, it might show off some some complicated physics, pathfinding, or lighting algorithm.

As with the progress report, start with a short, overall summary of what you propose to do. Remember to include the architecture and design specificatiosn (which are in this two week period) as well as the technical prototype. Describe what subsystem you are planning to complete. In short, this paragraph should constitute the deliverables for the next assignment.

Activity Breakdown

For each team member, you should describe his or her 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 architecture specification.
  • Time spent on the design specification.
  • Time spent on the technical prototype.
  • Time spent on art or music assets.

In essence, we are asking that you take what you predicted in your milestones and give us a lot more detail for the next two-weeks. In the milestones, we just wanted a prediction of what the entire group will accomplish. In the two-week report, we want a individual assignments and a prediction of the hours that each person will spend on each.

In estimating time spent, we again ask that you organize this information into a table. In each row of the table, you should have the following:

  • An individual task that the team member is assigned
  • The internal (team) deadline for completing this task
  • An estimate of the number of hours that will be spent on the task
  • A priority value for the task; lower priority tasks are optional

In assigning these tasks, you should use what you learned about your group dynamics during the gameplay prototype. While tasks may be uneven at the start of the semester, we hope that they will even out by the end.

Workflow Revision

This last activity is completely optional. If, after this two-week sprint, you have made any revisions to your team workflow, you should let us know. We do not want the workflow revision as part of the two-week report, but you are welcome to submit it along with the two-week report. The revised workflow should have the same format as your original submission.

Example

The example linked above is an (edited) version of a two-week report submitted by the game Dispossessed in Spring 2015. We have removed the parts of the report that are no longer relevant for this year. What remains is exactly what we are looking for in a two-week report.

This report is taken from later in the semester, as the team had really gotten into a grove at this point and was submitting excellent reports. As a result, the progress report compares the number of hours worked to the hours predicted. You did not make any predictions before this report, and so this is not relevant. But we want everything else.

Submission

Due: Sat, Mar 12 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.

If you are revising your team workflow, this is also a space for it in CMS called workflow. However, this is completely optional; you should not submit anything here if you are not revising your workflow.