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.

We’ll due Course Evals (the traditional CS form, with the fill in dots and the “do you recommend the instructor” question) on the last day of class (Wednesday, December 14th). Please come if only to fill out the form. (we’ll also have a class, but we’ll end early to give you time to do the forms). The department actually cares how many people fill out the forms.

I do care what you think. This years class was a bit of an experiment (successful in many ways, less successful in others), and I am really interested in how it worked from the student perspective. I am going to run this class again next fall, so your advice can really impact future students!

While I do get the department forms (the department only looks at the fill in dots), and do read them carefully (honest! I care what you think), it doesn’t necessarily give you much opportunity to really give me a sense of the class.

I am asking people to do an addition “course evaluation” to help me with planning. I will keep track of who turns it in, but I will not look at them until after grading is done. You can send it to me by email, or give it to me on paper at the Festival of Games. If you want to be anonymous, do it on paper and put it in an envelope with your name on it. If you do it anonymously, please let me know what graphics class you had (I want to correlate impressions with this). (actually, even if you aren’t anonymous, please remind me so I don’t need to go back to the survey we did at the beginning of class).

I will be doing my own self-evaluation after I am done grading. If you want to see this, let me know and I’ll send it to you.

While you can write anything you want (including nothing), I would appreciate feedback on the following:

1. What were the best parts of the class? What things should I make sure not to change in the future (I have a lot of ideas on things to change, but I don’t want to destroy what’s good about the class).
2. What things did we not get to in class that you would like to have learned about? (somehow, the semester breezed by without covering a lot of the topics that I wanted to get to)
3. What topics in class were most memorable?
4. How did the Friday afternoon sessions work for you? This semester, we mainly did playtests and group work times. We tried a tutorial or two, but we never got to the group critique experiences, or other experiments we wanted to.
5. This class took on a different flavor than previous years: we spent more time on design issues, and emphasized web prototypes over more technical details. What is your opinion on this shift? Did we sufficiently warn you about it?

With 29 people in class, I am expecting that there were 29 different experiences. In the past, I’ve gotten some great insights from students – although, there is rarely a consensus on suggesting what should/shouldn’t change.

Thanks in advance!

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.

This lecture was a crash course in rigid transformations, leading up to an attempt to tell you what a Quaternion is, why Unit Quaternions can encode rotations, and a sense of why you might want to do it.

The notes I used were a pile of old notes from previous classes. There is no actual notes for the lecture.

Some things to refer to:

• 2008 Games notes on Quaternions

This was a brief scan through some ideas in AI and path planning and algorithms for games and …

I had a rough outline, and referred to old notes. Topics

• AI Overview (what is AI, why for games?)
• Reactive vs Contemplative -> Maps
• Chessboard transforms, EDT, Geodesic transforms
• Search in Discrete spaces
• Trees, Minimax
• Pathplanning, Navigation Meshes, PRM
• Dijkstra’s algorithm, A*
• Believable vs. practical AI

AI Notes from Previous Games Class

ai-notes (old and outline for 2011)

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.

We’re now fully in “Project” mode – where everyone is hopefully devoted to getting their project built.

In lectures, we’ll focus on “technical topics that you should learn in a class like this.” Unfortunately, most of these won’t be directly relevant to your projects (since the projects are diverse and generally not tech-heavy). But we’ll talk about graphics, AI, animation, applications of games, …

We’ll try having the lectures be isolated: nothing required before or after the class. But if I don’t get the sense that people are learning something, I might change that. At least you won’t be able to say you didn’t hear about the important ideas in class. A lot of this stuff is hard to learn from lectures alone, but hopefully I can plant some ideas in your head should you need them later.

For project work this week: a “sign of life” demo is due this week (Friday, November 11th). A seperate post will be made explaining the signs of life demo, but basically each group will get an individualized email explaining what they need to do.

So the schedule (tech topics subject to change):

• Monday, November 14th: Tech Lecture: AI and Path Planning
• Wednesday, November 16th: Tech Lecture: Rotations
• Friday, November 18th: Lab work time (signs of life demos). This is optional, but we encourage people to use the lab session as a time for working all together, and for talking to other groups about similar issues they face.
• Monday, November 21st: Guest Lectures! Kurt Squier and Ben Shapiro from WID will talk about Games in Education
• Wednesday, November 23rd: Lab work time. (Honestly, I expect that a lot of people will want to leave early for Thanksgiving)
• Friday, November 25th: Thanksgiving break.

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.