“Gold Master” (final handin) Requirements

Official Deadline: Thursday, Dec 15. (any time)
No-Cost Extension: Wednesday, December 21st, 2:30pm (if your group requests it)

A “gold master” is the thing that gets shipped from the developer to the publisher so that the publisher can mass produce the actual units for the customer.

For us, the “Gold Master” is the pile of stuff you turn in at the end of the project.

By university rules, this is officially due before the end of semester. But I can give everyone an extension. We need everything on the day before the Festival of Games so that we can look it over, and decide if there’s anything else we need to get from you, or ask you during the Festival.

Note 1: in addition to this “Gold Master” (which is the group handin), there are several other handin requirements that are independent (and explained elsewhere):

• Personal Playtest write-up (due Monday, December 12)
• Group Playtest write-up (this is where you get to ask for you no-cost extension) (due Wednesday, December 14)
• Personal Reflection (due when the Gold Master is)
• Course Evaluation (the official CS form will be done in class on Wednesday, the extra feedback is due at the Festival of Games).

Note 2: for grading, everything must be available via the web. However, you may restrict access to it to just people from CS. Also, while I would prefer that we can make all the materials from the class available for future students (and others to play the games), you have the right not to have your stuff be public and/or kept for posterity. If you would prefer me to remove your work from the web once we are done grading, please let me know.

Mechanics of Final Handins

Gold master handins will be through the handin directories (that are web linked). Even if your project is not a browser-based game, you must put everything in this directory (and we’ll download it as appropriate).

Please clear out anything besides the handin materials from your directory (playtest versions, old copies of the code, …). Its best if you don’t include (or remove) the source control files (the hidden files take up a lot of space).

Please check to make sure that everything is there: that your game runs if it is accessed via the web (if its supposed to), or that there is a binary distribution available (if it is not a web game). If there is a binary distribution (as a ZIP file), please test to make sure that it works  – that all files necessary are there, etc. Please make things be self-contained.

This folder will most likely get moved, so please make sure all links are relative (except for ones to the Course wordpress documents, like the project pitches).

What to Hand In

1. Your handin directory must have a landing page (index.html or similar). This page must clearly identify your group (all people), game, and provide a link to all other aspects of the handin. Include a link to the original “pitch”, the planning document, the group playtest review, as well as the things listed below.
2. If your game is a C++ game, include an executable ZIP. (not just a link to the EXE file). Be sure to include all required assets (we will download it and run it – maybe on a machine outside of CS). Tell us what the requirements are (preferably Win7 x 64).
3. If your game is a web game, have a link to start it (going to the “opening page” – the instructions, tutorial, splash screen, …)
4. Include any instructions. Even if there are instructions in the game, it may be useful to have a brief explanation of the instructions.
5. Your landing page should be an “advertisement” for the game – describe it and have some pictures to show it off. (in the old days, we used to make you design the box). In particular, if there are any cool things that we might not get to experience during testing, include a picture to show it off. (the gallery could be separate from the landing page, but must be linked)
6. Include a ZIP file of the “source code” – even if this is a web game. Include the assets (but not the source control hidden files). Be sure to have a README file explaining what the files are, and where someone should start to look at it. We WILL look at your code to get a sense of what’s behind your game.
7. A document (either a web page of PDF) that is “advice to future students.” We will run this class next year – so think about what you would advise people (for the final project, but if you want to include a section about other aspects of the class, that’s OK). This will probably overlap the traditional “post-mortem” (that people will be asked to do individually), and you might choose to structure this as the “what went right, what went wrong, what we would do the same/differently if we had to do it again). Note: next year we will do a lot of things differently about the class. Also, please let us know if we can let students see this.