Final Project

The syllabus page gives an overview of the project, and the various deadlines are listed on the schedule.  Here, we provide more specific details.

Your Project Deliverables:  The Class Blog

Rather than requiring a webpage, you’ll simply continue using the class blog for your submissions, as follows.

Each team will have an identifying category for their group, as a sub-category of “Groups.”  For each deliverable, the group will do a blog post, categorized with their group category.  The “description” of the group should provide an appropriate one sentence summary of their group.  The first post will be a summary of the project, including a list of group members, the game design idea, etc.  Additional posts will be added for all the game turn-ins, the final game, all game prototypes, and the final video.  The content should be neatly and concisely laid out on each of these posts, such that the final page containing those posts is polished.  All game projects are expected to be targeted to Unity’s web plugin (with the unity3d file stored in t-square’s resources), so all of the game milestones will be playable on your post’s pages, and available to the your classmates and anyone on the internet who stumbles on your page.

DELIVERABLE: The information we need for your group (name, a “tag line”, category tag, and members) is due on the t-square wiki page before 12 noon on Friday Oct 18th.

DELIVERABLE: Submit the same information to the t-square assignment.  Pick one of your group members as the person who will do all of your t-square submissions, and submit it under their ID.  For all the project submissions, only one of you (this person) should do the submissions.

Project (From Syllabus)

The final project will be done in groups of 3.  Not 4, not 2.  But 3.  Teams will be formed after fall break, and an initial game pitch will be done by each team. Each team will then work on their game over the last month of the semester.  There will be four major milestones (the Alpha build, 2 intermediate in-class playtesting sessions, and a final complete build, all of which will be play-tested in class.)

The game project is best thought of as “30 to 60 seconds of pure fun that demonstrates the core fun of your game idea.”  The emphasis is on demonstrating the fun.  The game should play well for at least that brief period, and it should be clear to the player where this game would go if it were to become real.  Polished art is not necessary, but the prototype should be complete and clean enough to not interfere with the experience; opting for a clean geometric world rather than “cobbled together mismatched models” is a good idea.  While you should have at least minimal splash screens, menus, instructions and environmental polish, you will NOT get additional credit for things unrelated to the fun of your core idea: not for complex levels or level editors, generalized internal structures, super-cool animated 3D characters, etc.  But the critical elements of game feel (as described in the text and in class) are important, insofar as they contribute to a smooth and compelling game experience.

The core requirement for the game, like Project 4, is that it must satisfy Swink’s definition of a “true game feel” game (i.e., it must have a character/avatar you control, who moves through a simulated space, and whose interactions with that space are reinforced through polish effects).  There are no additional technical requirements for the game, aside from doing what you need to make it fun.  If your game requires “enemies or multiple players” you must implement it (AI controlled enemies, or networking).  If your game requires physics, then use physics.  You should focus directly on making a fun-to-play interactive experience.  Avoid extra complexity that does not contribute to the goal, and put in work on things that contribute to it.

The Pitch

On October 21st and Oct 23rd, in class, each team will do a short project pitch. You will have exactly 3 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 (3 mins), 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 should be on the “core idea” of the game.  You should present 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 must 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.

IMPORTANT: The t-square submission FOR ALL GROUPS is due before class on Oct 21st (even if  you are presenting on the 23rd); you MUST use the materials you post in your presentation, even if you go on the 23rd.

You can finish or edit your blog post after class, incorporating the feedback you get and your responses to it, but you MUST finish all editing/posting by the end of the day on the 23rd.

The Project Design

By the end of the week of Oct 21st, you will submit a more detailed design for your game, expanding on the pitch, and 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.

Your design documents/post should include

  • a more detailed plan for the game
  • three feature set targets: the minimum low-bar of 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 other classes, but spend more time on another week, say so!
  • a target feature set for each milestone (alpha on Nov 4, beta playtest on Nov 18, final play test on Nov 25), 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 and beta builds are 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 your documents to t-square, and to the class blog, by 5pm on Oct 25th.

IMPORTANT: Think this submission 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 do not meet it, your grade will reflect it.  NOTE:  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 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 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.

Game Logs

Each week (before Monday’s class) you should do a blog post that summarizes what you planned to do by the end of the previous week (from your design document), what you accomplished, what problems you ran into, and how this affects your plan moving forward.  These posts should be succinct, and might be quite short if everything is proceeding as planned.  But, this is where you can document how things are changing based on what you are learning as you go along.

DELIVERABLE: On Nov 4, Nov 18 and Nov 25, these blog posts should include the build you intend to show in class.

DELIVERABLE: On Nov 11, you can include a build if you want, but a short update is sufficient.

Alpha

The Alpha should be an initial playable demo, designed to give you feedback on the core fun of your game.  By this point, a player should be able to experience the core feel of your game. Consider Brad’s squid game:  he focused initially on the interaction of the player with the squid and the squid with the world, and added the scoring, enemies and effects later.  And so it should be with you.  Do not create an alpha that is the “structural shell” of your game, with all the various bits implemented but nothing implemented well, and nothing to “play” and give feedback on.

You will post these to the blog as part of you weekly blog post, and bring your laptops to class.  We will use two class periods to allow students to play each others games and give their feedback.  We will post a signup page on the wiki once we have the groups set.  Each group will choose Tuesday or Thursday for their demo, and bring at least 2 laptops, preferably one per team member, to allow others to play their game.  The students not demoing will go around and play at least 5 of the other games, and give the team feedback.  The instructor and TAs will try to play every game between them (but that will be hard in a class this size).

Final Playtesting Build

The week before final presentations, you will be expected to have your game 99% complete, and we will play-test in class, just as with the alpha.  We will use the same order as the alpha (if you do the alpha on Tuesday, you will do the final playtest on Tuesday).

After the playtesting, you may update the game based on what you learned (e.g., adjust balance, update some content or technical bugs, etc.) but this should only be updates that could plausibly be called refinement.  Adding new features after the playtesting build, rather than adjusting features that were there, will NOT count toward your final grade.

You will have until the end of the weekend  after the final play-testing (11:55pm Sunday night) to post your final game on the class blog (with the unity3d file in t-square).  You will then do your final presentation during dead week.

Final Presentation

During dead week, you will present your game, primarily by showing a short video (less than two minutes) documenting your game. You should also present a discussion of what worked and did not work, what you learned, changed and adjusted as you went along.  If appropriate, you should highlight anything non-trivial you changed since the final playtest, in response to what you learned during that testing.

We will use the same schedule, but with the days in reverse order, that were used for the Alpha and Final Playtest days.

You will turn in your video, your presentation, and a short document that expands on your presentation by reflecting back on your design document, talking about what you managed to do, didn’t do, and what you would change if you could do it all over again.  You are encouraged to look back and your weekly logs and use what was posted there to create this reflection.

DELIVERABLE:  Upload all of your materials to the t-square assignment submission.  Your video should be uploaded to the t-square resources.  You should create a summary blog post that contains what you will present (but structured for the blog;  do not just upload and link to a presentation).  Your video should be embedded in your post.  If one of you uploads your video to youtube or vimeo, and you want to embed that copy of your video in the blog post, that is ok, but please also upload your video to t-square.