Course web for CS679 Fall 2011

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.

{ Comments on this entry are closed }

On Friday, December 9th, we’ll have the final project playtests.

Before the playtest, put everything you need into the handin directories (just like with previous projects, except now it’s “Proj3”).

You might want to come a few minutes early to check to make sure everything works.

We’ll meet at 2:30 in 1366. There is a schedule where each test is scheduled for 20 minutes, with an assigned observer and one or two players. We also scheduled which computer each test will happen on.

The whole point of the play test is for you to watch people play the game: observe, take notes, try not to intervene.

Ideally, your game should be self-sufficient enough (with instructions, etc) such that the players can just start and figure things out. However, if you need to guide them through the rough spots or help them get started, that’s understandable (but try to keep it to a minimum).

It is the responsibility of the observer to take notes of what the players say (unlike last time, where the players wrote down their impressions of the other games).

Next week, each person will turn in a set of playtest notes about what they learned. Each group will combine these into a final plan. These are described next…

Playtest Notes

Each person must turn in (via email, sent to both the Professor and TA) a set of playtest notes. These are due on Monday, December 12th (any time).

At a minimum, the playtest notes must include:

1. For each player, a description of what happened. How far they got in the game, what they encountered with it, … Any specific things that said or did that are worth remembering. Any problems they ran into, or anything that confused them. (this is why you need to take notes during the playtest)
2. A summary of what you learned from the playtests. (note: you will probably learn about the game, but you might learn about user testing in general)

A way to think about it: part 1 is the raw data – we want you to make sure its all written down. Part 2 is your initial analysis of this data. The idea is to have it organized so that you can discuss things with your group.

Post-Playtest Plan

Each group must turn in (via email, sent to both the Professor and TA a plan for what work the group will do after the playtest. These are due on Wednesday, December 14th (any time).

This note must contain (at a minimum):

1. A summary of what was learned in the playtest (this is mainly a merging and summarization of the individual reports)
2. A description of the updates that you intend to make between the playtest and the final handin.
3. A description of when you expect to turn in the final handin.

The Final Handin

More specific instructions for the final handin will come soon, but:

The final project is due on Thursday, December 15th. University rules are that projects must be due before the exam period.

However, I will give your group a no-cost extension until Wednesday, December 21st at 2:30pm if (and only if) your group has turned in a post-playtest plan.

The Wednesday afternoon deadline is pretty firm, as we need to look at the projects before the final exam period (when we’ll have the festival of games). We won’t complete grading by then, but we want to make sure that if we have questions, we can ask them at the festival.

Details of the final handin will come soon, but it will require:

1. Documentation of the game, including a web page “advertising” the game (you need a web page even if the game is not a web-based game). The documentation page should list any requirements for playing the game (e.g. a particular web browser), and have links to play the game (if it’s a web game), download a playable executable (as a zip-file) if its not a web game, and download the source code as a zip file. If you don’t want you game to be seen, you can put an .htaccess in the directory.
2. Each person must turn in a reflection exercise. (details to be announced after the playtest)
3. The playable game must be either web accessible (or downloadable) so we can grade it. We hope you’ll be willing to put everything online and accessible so that people in future classes can look at it.
4. Your documentation page should link to the original pitch for the game (look for it on the course web). It must also include a link to the game planning document.

{ Comments on this entry are closed }