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!

Project Handin

Please make sure that your final project is in the directory before class time Friday, November 4th. If your game is an in-browser game, make sure that it runs if someone points a web browser at the Project2 page. If you choose to make your game accessible to the whole world, remove .htaccess file.

Your handin should have an index page (what happens when you go to the web directory) that identifies that game, the people in it. It should have (or link to) any instructions. For a web-based game, it should either have the game on the page, or link to a page with the game.

Reflection Exercise

Each person must do this individually. There is no “group reflection.” Please send it to both the TA and the Professor before class on Monday, November 7th. (this is a little later than originally announced)

Please put your response to these questions right in the text of the email. Do not add any attachments.

Please answer the following questions:

1. How happy are you with the game you produced?
2. If you had another week, how might your game have been better?
3. Describe your design/development process. What went right/wrong? How did you divide up the tasks?
4. What did the different members do? (this is your chance to praise/curse them)
5. What would you have done differently? (or will you do differently next time)
6. If we give this assignment again next year, what should we (the course staff) do differently to improve the experience for the students? Is there a lecture or two we should have given to better prepare you?
7. What might we not appreciate about your game, if we grade it simply by playing it and looking at the code?
8. What tools (languages, libraries, editors, content creation, …) did you use? How did they work out? Are there some we should recommend to students in the future?
9. How well did your group work together? What coordination mechanisms did you use?
10. What did you learn from this project?

Note: it is much better to be honest than delusional. If you simply say “our game was great” (without much thought as to why), its not as good as giving a thorough critique (even if negative). We’re looking for the depth in your thought. We’ll judge your game ourselves (modulo #5), and are probably more realistic in our expectations than you are.

The 2011 679 Game Project

This is the main “overview” page

The goal of this project is to produce a game by working in a team of 4 people. What game you create is up to your team, but is subject to some Rules.

All parts of the project will contribute towards your grade (including your proposal and post-mortem).

Ideas for games must be presented as a Proposal. You team may choose any one of the proposed designs. Even if the design was proposed by someone who isn’t a member of the team.

Teams will be assigned on Monday, November 7tth. Each team will need to choose a game to build, and create a plan in time for a project meeting with the course staff on Friday, November 11th. The games will be built over the following 3 weeks, culminating in a playtesting session when each person will play each game. (expect to give and recveive lots of demos). The following week will give an opportunity to tune the game and produce the final documentation.

The project Phases:

• Game Proposals (Wednesday, November 2nd)
• Project Kickoff (Monday, November 7th)
• Project Plans and Meetings (Friday, November 11th)
• Signs of Life Demos (Friday, November 18th)
• Tech Demos (Friday, December 2nd)
• Playtests (Friday, December 9th)
• Gold Masters (Wednesday, December 14th)
• Festival of Games! (Thursday, December 22nd)

A Brief Discussion of the Phases (with links to each)

Game Design (Proposal) (due Wednesday 11/2)

Pairs of people will propose games for project groups to build. Each pair will give a 3 minute “pitch” to the class, as well as provide a 1-page proposal (which we will post to the course web). The proposal is due before class.

Project Kickoff (Monday, 11/7)

Teams will be announced. Class time will be used for teams to meet, and try to decide what game to build.

Game Plans (due Friday 11/11, 9am)

Each project team will complete a detailed plan. During class time, there will be meetings to discuss the designs (the early deadline is to give the instructor and TA time to read over the plans).

Signs of Life Checkpoint (due Friday 11/18 – demo lab)

Each project team will have to provide evidence that they are making progress towards implementing their plan.

Tech Demo -> Checkpoints (due 12/2, demo lab)

Each project team will give a demonstration of the their “technology” implemented to that point.

Playtests (Friday, 12/9)

In class, we will have a “play testing” session where each person will get to play each other group’s game. Enough stuff needs to be prepared (including documentation) such that people can play the game at class time.

Gold Master (Wednesday December 14th)

The last day of class, “everything” is due (code, documentation, …). Official University Policy says things cannot be due after this. Late projects (up until the final deadline) are negotiable.
While the post-mortems are officially due at this time, there is leniency for them.

Festival of Games! (December 22nd, official class time slot)

We won’t have a final exam. During the final exam time slot, it is my plan to play the games that you’ve built. Note: late projects cannot be accepted after the exam period. Period.

Some instructions on the last phases of Project 2

Milestone 3: Show and Tell. Friday Oct 21: we’ll meet in a lab session. At least one member of each group must be there. You’ll need to show the Professor what your progress is, and give some idea as to how things are going, and what you’ll have next week. The expectation is that you’ll have an incomplete, but playable, prototype. This is a good opportunity to show off an early prototype to your classmates as well to get some feedback.

Milestone 4: Playtests. Friday Oct 28: we’ll meet as a lab session again. Everyone sets up their games, and goes and plays other games.You should have a version of your game in the handin directory so that people can play the game remotely. Someone should be “watching” people play, while other group members play other games (and switch off). We’ll do the “index card” thing (turn in an envelope with your name on it, with index cards with feedback for other groups (put the group name on the card) – just like with Project 1. Please turn your envelope (with at least 5 cards in it) to Gautam before the end of the class period. He’ll sort them so you can get them back on Monday.

Final Handins: Friday, November 4th. Again, we’ll meet in a lab session to play the final games. The games must be in your handin directories (ask the TA – they have been created), and will be available on the way. At class time, your reflections will be due by email – instructions to be specified.

Note: like with Project 1, your handin directories are linked to the web. You can manipulate the visibility using the .htaccess file accordingly.

You should be getting Project 1 feedback by email soon.

Note: in some cases, we couldn’t decide if your grade should be an A or an AB, so we marked down both grades. We’ll try to make the final decisions when we’re in a generous mood.

The parts that you get:

• A subjective grade (this is the letter grade)
• Mike’s subjective feedback
• Objective checkmarks (we did not provide any feedback on the reflections here, only noting whether or not you did them)
• Scores/Comments from David. David’s feedback focuses on the game aspects, which wasn’t necessarily the focus of this project. The 3 numbers can be interpretted as “qualitative assessment of flocking,’” “assessment of game idea,” and “extra game features” (like art).

On Friday, October 14th, the second Project 2 Milestone is due. For this milestone, each group is required to have done at least some design of their game.

At class time (2:30-3:45), we’ll have a “lab session” so that groups can work together on their projects. During this time, each group needs to show off their ideas to the Professor. If you don’t get to talk to me, make sure that the TA sees that you’ve met the requirements.

The “requirement” is that you have some form of story board. It can be rough. It can be a picture of a whiteboard, or a sketch on paper, or… Really its just that you have something written to initiate a conversation to describe your game. By this point, you should know enough about your game to be diving into implementing it.

Usually, I start the conversation about Game Design with a discussion of HCI and User Experiences more generally. This year, we’re doing it backwards.

what I want you to think about is something even more fundamental than Human Computer Interaction: let’s start by considering the design considerations for making usable things in general.

The readings for this come from The Design of Everyday Things, a great book by Don Norman (link on Amazon). The required reading is the first 2 chapters. The third chapter is optional (but highly recommended).

Chapter 1: The Psychopathology of Everyday Things

Chapter 2: The Psychology of Everyday Actions

Chapter 3: Knowledge in the Head and in the World

Note: all three chapters are in the protected reader.

Read at least chapters 1 and 2 (I recommend reading chapter 3 as well), and post a comment.

In your comment, consider some object (it might be a computer program, or it might be something else) that you use on a regular basis. How does it follow Norman’s principles? (having a good conceptual model, making things visible, good mappings, feedback, affordances).

Please post your comment before reading other people’s – although, you will probably find reading other peoples’ comments instructive (and comment on their comments). There has been some interesting discussion in the past around this.

We’ll discuss this material in class on Wednesday, October 12th. Please complete the reading and post your comment before class on 10/12.

Project 1 was a huge success. 14 games. While some were better than others, things really exceeded expectations. Its amazing what was achieved. However, rather than giving more time to clean up the results from Project 1, I think we need to move on to project 2.

Several people commented that they had wanted to have a little more experience with game design before doing project 1. And probably, you have new thoughts about how to use the tools (since you have a lot more experience).

Project 2 is similar to project 1. Make a game. Very limited time. Small team (3 this time). A little less restrictive in terms of platform (we aren’t going to REQUIRE Javascript), a lot less restrictive in terms of content (only a small technical requirement). But, you’ll have more experience, and a few game design lectures behind you.

The schedule (at least as insane as last time):

• Friday, October 7 – team discussion email
• Friday, October 14 – planning show-and-tell
• Friday, October 21 – show-and-tell
• Friday, October 28 – playtests
• Friday, November 4 – festival! (note, project 3 will start before Nov 4)

Project Objectives

1. To have you make another game
2. To have you try to apply some ideas from game design in order to make a good game
3. To have you work in a group of 3
4. To force you to write some shaders
5. To see who is brave enough to try WebGL

Some Ground Rules

• You must work with your assigned partners.
• Your programs must run on the computers in the 1358 CS lab.
• We would like your programs to run in the web browser. We encourage you to write it using Javascript/HTML5. However, you can make a Java applet if you really want to (we suggest Processing to give you easy access to graphics). It’s up to you to figure out Java graphics. If you require a specific browser, or plugin, just make sure you can get a portable version for the 1358 lab.
• We MAY grant exceptions to the in-browser rule. However, we will have higher expectations for this. If you want an exception to the in-browser rule, you must negotiate this with the Professor before October 11th.
• Your game must use shaders. Each person in the group must write a pair of vertex/fragment shadres. Ideally all 3 should be used in the game (if not, you’ll have to have a seperate page that shows it off). If you’re really stuck in getting shaders into your game, you could write shaders that work off-line, and use those to make images that you use in the game. This is, of course, discouraged. but it is a fallback if everything goes wrong. I guess you could use WebGL for the instructions/splash page, and that qualifies as well. (but again, the spirit of the assignment is to try to use shaders to achieve fancier in-game graphics than you could do otherwise).

• You may use any open-source (or freely available) libraries (such as jquery). However, you must include these libraries as part of your handin.

• Your handin must be fully contained in the handin directory – when your program runs, it should not fetch pieces from anywhere else (like loading an image from a website somewhere else). Put all assets into the one directory, and make sure everything works with relative links. (we may copy all the files to a laptop and look at things off-line).

• The final handin must be a single-player game. It should be self-contained. That is, someone should be able to load the web-page, read any instructions necessary, and start playing. Sufficient documentation is part of the handin.
• Your game must be in good taste.
• It must not require any intellectual property that isn’t either yours or freely available.
• You should not use any artistic or code assets that you do not have license to show. (so if you get art or music, make sure its creative commons or open source).
• It must not require code you’ve written previously.
• Many students in class have their hobby projects or code they’ve written previously. You can’t use this.
• While games must be designed so they are practical to build without using previously written code, teams can make use of "old" code from their members providing that the entire team agrees, the person providing the code agrees to make it publicly available, the code is not overly "game specific", and the students get permission (by email) from the instructor.
• It must have a low-startup overhead. You know how the playtests work now. If it takes 10 minutes to read the instructions, people may move on.
• It should not require the player to already know something obscure.
• The target audience for your game includes the TA and professor, and other members of the class.
• If your game requires the player to be familiar with (for example) the scenario from some book, the characters from some movie, or the rules of some existing game, you might be in trouble if the player hasn’t read the book, seen the movie, or played the game.
• It must provide for a short experience, but have replay value (or extended play)

The Milestones

Milestone 1: Friday, October 7 – team discussion email: By the end of the day on Friday, October 7th, please send the TA and Professor an email (one per group is fine), to let us know that your team has met, and that you have an idea for a game. All we expect by this point is that you are working together and have at least an initial design. Please let us know about your implementation decisions (what language you intend to use, …). Given what you send us, we will try to provide feedback, maybe talking you out of things we think might not be feasible in the time limit.

Milestone 2: Friday, October 14 – planning signs of life: In Friday lab session, at least one member of your team should come to show off your initial progress and discuss your game. By this point, you should have some design done, and hopefully the beginnings of an implementation.

Milestone 3: Friday, October 21 – show-and-tell: In Friday lab session, everyone should come to show off what you’ve done, and maybe get some feedback from others. Ideally, you’ll have a prototype game so that people can do some early play testing. But you should at least have something to show so you can get feedback.

Milestone 3: Friday, October 28 – playtests: We’ll have a Friday lab session playtest (like we did for Project 1). Note: we will allow for some game adjustments after the playtest, but the following week you’ll be busy starting Project 3.

Milestone 4: Friday, November 4 – Festival! (note, project 3 will start before Nov 4). Everything must be turned in before class time (including the reflection exercises). This will be similar to the play test, but a little less structured. We’ll just meet in the lab and play games. (preferably, the ones you’ve written).

Project 1 was a success. I was really impressed with how things turned out. Given the amazingly short timespan, the fact that you had to learn new tools, the fact that you haven’t really been taught much about how to design a game, … its totally amazing. If you want to look at the games, go to the web page.

Remember, the reflection exercises are still due.

Almost all of the games would be better with a little more time. If you want to keep working on your game and improving it, great. We’d be curious to see it!

However, we are going to base grades on what we saw Friday (or see trying it on the web). Don’t worry, that’s uniformly great – we grade projects by comparing your work to our expectations, not to other students.

Project 2 is coming, an initial announcement will be coming today, and partner assignments on Wednesday.