G2/G3: Group Project Design

The project starts with each group preparing a design document and doing a design presentation, and then revising that document based on feedback.

Each group will do an initial design presentation, the week of November 3rd.  4455A1 will present Monday, 4455A2 will present Wednesday (an anonymized summary of the design documents must be submitted on the blog before the class you present in, and the full documents submitted to t-square).

The design (presented, and in the documents you submit) should cover all aspects of the game idea, the schedule, who is doing what, and the targets for each of the play testing deadlines (more details below).  You will receive feedback in class, and (possibly) on the blog afterwards.  Each group will adjust their plans based on this feedback, and their initial work, and post an updated design document by the following week.

Depending on the number of groups, you will have approximately 5 minutes to present, and we will have about 3 minutes for questions and comments (from the instructor and the class).  You should all be prepared to present from your own laptop, or from the web on the class machine without logging in anywhere (it takes too long to logout/login):  a simple solution is to use Google Docs, make the presentation public, and post the URL to the class blog under your group category tag.

However you choose to present, make sure you know how to present via an external monitor on your machine, as any “technical fiddling” will be taken away from your time (you will have ~1 min to set up after the previous group is done).

Pay attention to the short time, as you will be graded on how well you use it.  Rambling, repetition, obvious lack of preparation, and so on will be penalized.  As will reading a script; don’t do it.  Practice and a be prepared.  Similarly, you should maximize the effectiveness of what you put on your slides, and how it coordinates with what you say. Having text-heavy slides that mirror what you say is not effective.  Showing key words/phrases, and using pictures (including hand-drawn sketches) and so forth is much more effective.  Maximize the information you convey.

The focus of the presentation and your design documents should be on the “core idea” of the game.  You should present (and write about) whatever details you think will convey:

  • Who you are, what each of you will do in the game.
  • What the game idea is, what the “fun” and “aha moments” are.
  • What your target experience is.

DELIVERABLE:  In addition to submitting your presentation materials on t-square, you you should submit documents describing the design.  The documents should contain whatever you feel is necessary to concisely and clearly explain the game idea, the targets for the alpha and final builds, and who is doing what on a week by week level of detail.  We are not specifying exactly how you should prepare the design, or what section to include: it is up to you to be clear and concise.  Use tables or charts, if you want, or prose.  You should be clear and concise:  say what you need to say in as little space as you can, I don’t want you writing huge amounts of text and many pages of excessive detail.

You must also do an initial blog post on this site containing the same information:  who is in the group (keep it anonymized by linking to your respective category pages with your pseudonyms), what your game title and idea is, who will be doing what, and why you think this will fun.

The Revised Project Design

By the end of the day on November 10th, you will submit a revised design for your game,  taking into account the feedback you got both during the presentation and after (including, possibly, on the blog post).  You MUST also post this more complete design to the blog.

Both of your design documents/blog post should include the following:

  • a detailed plan for the game
  • three feature set targets: the minimum low-bar of what you will do, a target that you expect to get done, and a desired high-bar if things go exceptionally well.  Plan these out carefully, so that you can definitely high the first, and likely hit the second
  • a timeline of what you intend to accomplish by the end of each week through the end of the semester.  Look at the personal schedules of your team, you classes and other projects, and plan accordingly.  If you will have a light week because of deadlines in other classes, but spend more time on another week, say so.
  • a target feature set for each milestone (alpha on Nov 19, final play test on Dec 3), along with a discussion of why you are targeting this particular subset of your game at each stage, and what you hope to learn by having people play-test each of these.  Please remember: the alpha build is not just “partway to the end,” as this wouldn’t be playable and would be unlikely to give you feedback that you can take action on.  There should be things that are finished by then, and things that are likely unstarted (or for which you have crude stand-in elements). Think this through!

DELIVERABLE: you will submit the first version of your documents to t-square, and post an anonymized version to the class blog, before your presentation (Nov 3 or Nov 5).  You will submit the revised version by the end of the day on Nov 10.

IMPORTANT: Think these submissions through.  You will be graded both on this document, and on how well you meet your plans.  If your plans are poor (i.e., too trivial, or unachievable;  not well thought through week-by-week), your grade will reflect it.  If you have a reasonable plan, and meet it (or do not meet it), your grade will reflect it.

IMPORTANT:  the point of the week by week plan is as a feedback mechanism for you.  If you see your plans slipping, you should (a) try to fix it and/or (b) come talk to use for help or advice.   If you completely miss your plan, but it’s clear you’ve been working and adjusting appropriately (as measured by how much you interact with us and talk to us about it), you will not be graded poorly.  But, if you show up at the alpha and/or the final and are far from where you need to be, and have not talked to us about it, your grade will suffer, REGARDLESS of how good a story you tell.

Or, put another way:  I (the instructor) have implemented many large software systems.  It is never the case that things are going smoothly until the last minute, and then fall apart.  It is often the case that seeing things gradually slip, but hoping you can make it up later, leads to disaster.  Or that leaving things to the last minute, and having an overly optimistic expectation of what can be accomplished in a short amount of time, leads to things falling apart.  I will obviously not be able to deduct points from people who do everything at the last minute, and succeed (because I only see these milestones).  But I will NOT have sympathy for people who wait until a few nights before, and fail.  You are all adults, you can budget your time as you like.   But you also get to take responsibility for the results of your choices.   You have been warned.