These are due the same time that your Gold Master is (effectively, Wednesday, Dec 21st, 2:30pm).

Please send in your reflection by email. I strongly prefer that you put the text into the body of the email. Please note that you also get to do a course evaluation (see the other post).

In terms of your reflection, please discuss:

1. I am not very good at playing games, so I might miss some of the fancier aspects of your game (this is why I do a lot of watching at playtests and festivals). What might I not see if I only play your game a little bit?
2. The final product. What’s good about it? What’s not?
3. If you had another week, how might the results be different.
4. The process. How was the experience of creating the game? What went right along the way? What went wrong along the way? (I saw the various steps along the way, so you don’t need to recount the details of the process, unless you want to).
5. The team. Please comment on each person’s (including yourself) role and their performance in it. Here’s your chance to praise or curse your teammates. How well did your group coordinate? How well did your group make use of the (potentially diverse) set of talents it had? (note: I am well aware that there is a range of backgrounds in this class). What do you think the other people learned from the experience?
6. What would you do the same or different, if you had to do it all over again.
7. Yourself. The cliché is to ask about what you learned from the experience. This is good self-reflection practice, but may already be described above. So feel free to comment on your own performance in this project, or ignore this question.

It was clear at the playtests that a lot of people put a lot of efforts into these projects. I am curious about the sense of accomplishment that people get from this. Was this project worth the effort? But I really have no way to ask that as a self-reflection question. So comment on it if you like.

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.

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.

As you should know, November 18th is the “Signs of Life Demo” requirement for Project 3. Given the diversity of the games being built, we will give a different requirement for each team. You will receive this assignment by email sometime before class on Monday, November 14th.  If you do not, send email to the Professor.

Your “demo” will require your group to send an email (copied to the professor, the TA, and to David – all of whom will be CC’ed on your assignment). This email is due on Sunday, November 20th (so you get a little extra time).

“Class” on Friday, November 18th will be a lab session. It is optional, but we encourage you to use it as a time to coordinate with your group, and to talk to other groups who are working on similar problems.

Project 3 is now underway! On Friday, we will review project plans.

The desired format for the written plan is described on the plan page. But the idea of planning is to really force you to think through what you are going to do over the next 5+ weeks. You will be devoting a lot of time to this project: you want to have a good plan so you are likely to come away with something you are happy with.

While the questions for the (required) written plan are a good way to structure your thinking, at a higher level, you should consider:

1. What game are you going to make? (What is the player going to see and do? Being concrete about where you want to get to is good. The more concrete you can be, the easier it is to plan how to make it)
2. What are you going to make it with? (What tools? What language/platform? Do you need to find an engine?)
3. How are you going to make it? (What needs to be done? Who is going to do it?)
4. What could go wrong? (and how can you get the “big risks” out of the way early, so you can change plans if necessary)
5. How are you going to cram this in to the time between now and mid-December?

It’s a plan, not a contract. But having a concrete plan really helps get things rolling. Even if the plan changes.

On Friday morning (or before) – you’ll send a written plan to us and we’ll review them so we’re ready to talk about it when we meet.

We will meet in Room 1304 Comp Sci (in the hallway between Doit and CS), on the following schedule:

• 2:15 Russel, Zack K, James M. Joe
• 2:30 Dennis, Charles S., Jon K., Alex
• 2:45 Dan, Nate, Tessa, Xixi
• 3:00 Hank, Brandon, Ryan, Phil
• 3:15 Jeff, Yiqing, Lorenzo, Matt Z
• 3:30 Matt A, Chris, Shane, Rachina
• 3:45 Andrew, Zach O, Sam, Josh, Nick

I have added a comment to each of the game proposals – based on a quick read and my notes from the pitches.

I was not commenting on the quality of the proposal – just some thoughts on the idea. Sometimes, better proposals can evoke more thinking of potential pitfalls which might come across as being negative about the ideas. Criticism is a good sign: it means your idea is sufficiently put together than issues can be identified upfront.

If you’d like to review the project 3 pitches, you can find them here.

If you have thoughts on any game, feel free to add a comment to the web page for the proposal. Or, if you prefer to be anonymous, send email to the professor or TA and we’ll post it for you.

Some thoughts I had (warnings to think about before picking an idea):

• Many ideas were “theme” or “story” centric – some good ideas for what the game is about, but less fleshed out ideas about what the player will actually do. While a good story/concept is nice, ultimately it is the gameplay that makes the game fun (especially for a small scale game like a class project). In thinking about what game to make, focus on what the player will see and do – since this is where the effort will go.
• Many games required 3D (either 1st or 3rd person) – and will really need an engine to pull it off. While this is very possible (many games for this class have been done using open-source engines such as OGRE or Irlicht), beware: it takes time to pick an engine and to learn it. (the first is a time cost groups often forget).
• Novelty is good. But not required. It’s OK to make your take on a known good formula. Especially if you can add some new twist to it (once you have the basics working).

I will try to post comments on (most) proposals this weekend.

You might want to bring a laptop to class on Monday, so you can look over the proposals again while discussing them with your group.

ZackChuck_BattlefieldComm

ZachRachina_MidtermMadness

XixiBrandon_StarExpress