The final parts of Project 3 are due at 2:30pm on Friday, December 14th.

There are a few pieces of this (each detailed below):

1. The actual game itself, handed in and runnable in the handin directory, including instructions and a note as to whether we can keep it public. Note: the deadline for this is fairly strict (2:30pm on 12/14) since we’ll be playing the game at that time.
2. The “group post-mortem” – a document written by the group (collectively) answering the questions described below. It is mean to be written as a group activity. Note, while this is due 2:30pm on 12/14, everyone gets a no-cost extension until Monday 12/17, noon. Your group only needs to turn this in once. Please email it to both the professor and the TA.
3. Your personal project reflection. Each person should do this individually. Note, while this is due 2:30pm on 12/14, everyone gets a no-cost extension until Monday 12/17, noon.

Remember, the reflections (group and personal) are actually part of your class grade.

Project Hand-in

You need to turn in your game into your handin directory.

The index page (what one sees when they do to “YourDirectory/”) must have:

• A brief description of the game, including the title (and that it is a class project for CS679, Fall 2012).
• A list of the group members.
• A statement as to whether you are willing to leave this game on the “open” web for anyone to see (especially future classes). If you say "We do not want this game to be left on the web”, then the TA and Professor will remove it once grading is complete (we will archive it). Please do not remove it yourself.
• Either the instructions for the game, or a link to them.
• A list of any components you used (open source libraries, artistic resources that you borrowed from, …)
• A list of any requirements. For example you might say “This game was tested only tested on Chrome v. 23.”
• A link to start the game.

Make sure that everything you need to play the game (including the instructions and resources) are in the handin directory. Do not link to other directories.

Your game must run from the handin directory. If there is some technical problem with this, please try to work it out with the TA before asking for an exception to this rule.

Group Post-Mortem

As a group, we would like you to prepare a document discussing some aspects of your game. Please turn in one document for your whole group. While this is due before exams, you are allowed to turn it in late with no penalty (provided we get it before noon on noon on Monday, 12/17).

Please answer the following questions:

1. What did your group learn from the play-test?
2. How is your game different from what you showed at the play-test?
3. What libraries / art resources did you use for your game? What did you use them for? Do you recommend them? (if you tried something and didn’t use it, please mention that as well)
4. What features might we miss out on if we play the game? Since we won’t be able to play it a lot, and we might not be good at it, we might miss some things that lots of effort went into.

Per-Person Reflection

Each person should send a per-person reflection to the professor and TA. These are confidential (we will not tell your classmates what they said).

1. Evaluate the game your produced. How happy are you with it? (this is about the actual thing we would play when we go to the web page – ignore any ugliness behind the scenes). What is good/bad?
2. If you had another week, what would you do?
3. Evaluate the process by which the game was made. What went right/wrong? How did your team work together to make the game? How did you divide up the tasks/coordinate?
4. For each member of your group: give them an evaluation. What did they contribute? How good was their contribution? How well did they work with others?
5. For each member of your group (including yourself): what grade would you give for this project and why? The “why” is particularly important if you don’t give everyone the same grade.
6. It’s a cliché to ask “what did you learn from this project.” It’s also a difficult question to answer (but good self-reflection). So you can answer it if you can think of it.
   An easier question (or pair): What advice would you give to someone starting this project? or What would you do the same/differently from what you did if you had to do it again?
7. Evaluate us (the course staff) with regards to this project. What could we have done to help you have done better? What should we keep/change about this project.

We do need to get your reflections (group and personal) by noon, Monday, December 17th, so we can do grading.

After the playtest, you must record your experiences. You should probably make notes as they do on and type them up afterwards.

Send your playtests feedback to the TA by email before class on December 11th.

For each game that you played: please include:

1. The name of the game, and the person who “observed” your playtest
2. Whether or not you were able to play the game without any “hand-holding’” (were there instructions? was the game self-explanatory (with the instructions?) or did you have to ask questions to the observer. (This should be a sentence or two about how easy it was for you to figure out what to do).
3. What do you think about the game in the current state? Is it playable? Fun? Buggy?
4. What do you think about the game in principle – over look the fact that it may not be overly polished (yet). Do you think the game would be good if the authors did some more work? Why / why not?
5. What do you think would be the most important things for the team to do to make the game better?

We’re expecting a couple of sentences / bullet items for 2-5

For each person who you observe playing your game, please include:

• The name of the person
• How successful were they at figure out what to do? How well did they do at playing it?
• How well did the game work for them? (did they uncover bugs? have performance problems?)
• How did the challenge level work for this player? Was it too easy/too hard? How could you adapt for this person.
• What did you learn from watching this person?

Try to record as much as you can – later, in your post-mortem, we’ll ask you do go through all these play tests and assemble them into a single plan of what to do. Here, its mainly to collect data for doing that bigger planning.

Send this writeup (for all of the playtests you were part of) to the TA before class on December 11th. You may put it into one email, or send a bunch of smaller emails.

As we get closer to the end, I thought I would give you some details as to how the class is going to wrap up (at least the project aspects).

Friday, November 30: the Tech Demo

For this milestone, you should have a playable prototype that conveys that all of the technology behind the game is going to work. It might not all be wired together. It might not be a tuned or fun (or even complete) game. But it should give a pretty compelling idea of what the player is going to see and do.

This milestone is an important checkpoint. If you aren’t (at least) this far along, you will have a tough time having a complete game for playtests (coming soon).

We want to check in with each group to make sure you are this far along. Although, to be honest, if you’re not that far along, about all we can do is say is “good luck, you have a big task ahead of you.”

For this milestone, all you need to do is have someone in your group show a brief glimpse of the game to Mark on Friday, November 30th. He’ll be in the lab during lab time. Alternatively, you can give him a demo at the end of class on the 29th (if you’re ready). Or send him a link where he can try the game online (if it’s sufficiently self-explanatory).

(Note: I will not be at lab session on 11/30. If you have questions for me, talk to me in class on Thursday, or send me email on Friday morning – I will have limited email access on Friday afternoon and over the weekend).

looking ahead:

Friday, December 7th: the Playtest

On one hand, the play test is just that. A chance for other people to play your game and give you feedback.

On the other hand, this is one of the main places that we’ll get an impression of what your game is. So you can sortof view this as the most important demo. It’s also the one time where everyone in class will play your game. You don’t want to waste their time.

During lab time, there will be a relatively tight schedule where each person is scheduled to receive (and/or give) a demo during a time slot. If all goes well, every person will play every game – with one of the games authors watching.

To make the schedule work, each group will need to have their game turned in and running from the web before the session begins.

Details on the logistics will be given prior to the event.

From this, everyone will be expected to write notes about what they learned as part of the gold master.

Friday, December 14th: Gold Master

In lab session time on Friday the 14th, we’ll have a “Festival of Games” where we can spend some time enjoying the final results. The final versions of the games are due at this time. They must be turned in before the class time.

There will also be a number of other documentation elements that are required. Each person will need to write a post-mortem/reflection, and there will be a group written handin (mainly describing what feedback was received at the playtest, and how the game was changed). More details will be provided closer to the date.

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. Use your CS login to access them.

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

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).

A big part of Norman’s chapters is to introduce some vocabulary for considering why things are (or aren’t) usable. Please use this vocabulary in your posting.

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 Tuesday, November 20th. Please complete the reading and post your comment before 11AM on 11/20 (so I can look at them before class).

Apologies for not posting this earlier, make sure it’s in by the class time on Thursday if you haven’t gotten to it.

The assignment is simple: each student shows their game to 2 other students in the class, each from a different group. Write down the name of the student and the details of your conversation, think of this as a “mini” critique just to get some outside perspective on the state of your game so far. Email me (mdhillon AT cs.wisc) with the takeaways from your demonstrations.

Just to be explicit, each student needs to do this assignment.

This assignment is really part of Project 2, but since it is done individually (rather than with your partner) we will call it an assignment. It is due before class on Tuesday, October 30. The reason for this deadline is that you’ll be starting project 3, and we want to have project 2 out of the way! Send your assignment to both the TA and Professor by e-mail.

After doing a big project, an important aspect of learning about it is to reflect on what you have just done.

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. How well did your group work together? This is a chance to give kudos (or complaints) about your partner. Your group gets the same grade for the game.
5. What might we not appreciate about your game, if we grade it simply by playing it and looking at the code? (especially since we might not be good at playing it)
6. What shaders did you write? Describe them and what they do, as well as how they fit into the game. (by “you” here, we mean “you” individually, since each person was supposed to write at least 1 shader)
7. What feedback did you get at the final demos? What might you do about it?

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.

(note: this is the 2nd milestone in the project – make sure you’ve read all the early stuff beginning with the overview).

With all of the proposals discussed, and the critiques available, teams can choose to build any of the games proposed (each team must pick one of the proposals). A team is welcomed to build a proposal even if they weren’t the ones to propose it. Each team will prepare a written document describing the game they intend to build. The purpose is to force your group to work together to agree on what to do, and how to do it.

This planning document is due on Friday, November 9th at 9am. We need it early since the professor and TA need to read it before the afternoon (when we will meet with each group to discuss it).

On Friday, November 9th (during the lab time slot), each group will meet with the professor to discuss their plan and to get "approval" to proceed. There will be a signup sheet in class on November 6th.

You should not do any coding until your plan has been approved.
We do not have any way to enforce this, however, we hope you will comply. The idea is that this initial week is spent planning.

In order to make this meeting effective, your team must provide the planning document to the TA and Instructor by 9am on November 11th.

The plan should contain (at least) all of the information included in the original proposal. Update all of those parts as appropriate. The plan should also address the following topics:

Response to Critiques

What criticism did the original design get, and how did it affect your final proposal. Note: you might respond to positive as well as negative feedback.

Group Inventory

What skills, talents, and resources do the members of your project team bring? Are there things your team is missing or is really good at? How should these effect what you try to achieve?

Tools Choices

What tools do you plan to use to implement the project (note: you might change these choices later – but for now, you should have an idea of what to try first)

Division of Labor

How do you propose to divide the effort of building the game amongst the members of your team?

Milestones

What milestones do you see along the way of building the game? Describe what you expect to have done at the 1 week, 2 week and 3 week marks (these are the "signs of life," "tech demo," and "play test" milestones).

Risks

What are the biggest unknowns or risks facing the project that jepordize its chances of success?

You might also want to work out block diagrams, module specifications, concept sketches, … – basically, the more thinking you do about what your project will be and how you will do it, the more likely you are to make good progress. Please include as much of these details as you can.

At this point, the key is to have a plausible plan. One that, if followed, would lead to the right outcomes. We want to make sure that there is at least one path to success, and that you know it. If you end up changing the plan and succeeding in a different way, that’s OK.

As the project proceeds, make sure that you consult your plan. If you are making major departures from it, please let the instructor and TA know. For example, we don’t want you to scale back your project too much (so that it isn’t interesting), or if you’re really stumbling on something, maybe we will have some ideas.

Please send the document in some convenient form to the Professor and TA by email, before 9am on Friday, November 11th. Emailing us a PDF is probably better than sending a word document.

Here are some previous examples of plans. Note: in the past there was more of an emphasis on critiques, some game engines were more or less popular (there was a phase when everyone was building games in Irlicht), …

• http://graphics.cs.wisc.edu/WP/games10/category/final-project/ (you can see the 5 plans after the announcement of the play test)
• http://www.cs.wisc.edu/graphics/Courses/679-s2008/GameProject/Examples

The 2012 679 Game Project

This is the main "overview" page. The details are on separate pages, but we give you an overview here since the details may not make sense without it.

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. Students will be assigned partners and each pair will create a proposal. After the proposals are presented, the each member of the class will be assigned to a team. 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 Tuesday, November 6th. 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 9th. 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 (with due dates – descriptions below):

• Game Proposals (Wednesday, October 31st)
  • In-Class Pitches (Thursday, November 1st)
  • Critiques (Tuesday, November 6th)
• Project Kickoff (Tuesday, November 6th)
• Project Plans and Meetings (Friday, November 9th)
• Signs of Life Demos (Friday, November 16th)
• Tech Demos (Friday, November 30th)
• Playtests (Friday, December 7th)
• Gold Masters (Thursday, December 13th)
• Festival of Games! (Friday, December 14th)

A Brief Discussion of the Phases (with links to each added as the details are announced)

Game Design (Proposal) (due Wednesday 10/31)

Pairs of people will propose games for project groups to build. You will be assigned a partner, and will create a brief description of a game (using a specified form for the proposals) on the class forum. In class on Thursday 11/1, each pair will give a 3-5 minute “pitch” (you must send the materials (such as power point) to the TA before noon on Thursday 11/1). Note: the proposal (including the pitch) is graded.

Over the next days (Thursday 11/1-Tuesday 11/6) , there will be discussion (online in the forums) about the proposals. Each person must comment on at least half of the other games, and each team is responsible for responding to comments about their game. The idea is to have some dialog and discussion so that people can decide which games to build. Your discussion counts towards your class participation grade.

Project Kickoff (Tuesday, 11/6)

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/9, 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). There will be meetings during lab time to discuss the plans.

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

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

Tech Demo -> Checkpoints (due 11/30, demo lab)

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

Playtests (Friday, 12/7)

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 (Thursday, December 13th)

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 14th)

We’ll play games!

We won’t have a final exam.

Due Wednesday, 10/31.
Note: this deadline is important since you need to post your proposal early enough that other people can look at it. Understand the overall project schedule for this to make more sense.

Also, note that you’ll have to give a 3-5 minute "pitch" in class on Thursday (11/1), and you will have to comment on other people’s proposals (and people will comment on yours).

And finally, the proposals will be graded (after team selection). Grading will not be effected by whether or not a team picked up your proposal. We’ll try not to even decide if we like the game idea: we’re mainly going to judge the quality of the proposal (how well do you convey your idea) and how well your idea gives a sense that you’ve thought through game design issues.

What is it?

Basically, you will come up for an idea for a game to build for the project in this class. These proposals will be presented publicly to class and then teams will pick from the proposals. The game you propose might be built by your group, it might be built by another group, or it might not get built at all.

Think about the proposal this way: you are trying to sell your idea to your project team. You need to let them know what the idea is, convince them that it would be a good game (if it gets built), and give some idea that it will be possible to build it.

This assignment is to be done with an assigned partner. Note: you and your partner will not be on the same project team. This means that for every project that is built, there is a designer who is not part of the team.

Note that there are two parts to this: (1) a written document and (2) the in-class pitch.

1. About the Game

You can basically propose any game you want. There are some Rules that you need to follow. But the key constraint is that it needs to be a game that can be built in the context of this project. For this reason, I strongly encourage you to review both the Rules, as well as the overall instructions for the project.

In your proposal, you will need to consider both the "design" aspects of the game (what is the game, what will make it fun), and (to some degree) the implementation aspects of the game (not the details, which will be left to the team, but a basic idea that shows why you think its feasible to build the game in the limited time and resources of the class project).

2. About the Proposal

The initial game design document must cover the following points:

Name

Your Game must have a descriptive name

Brief Description

A paragraph or two (tops) giving the basic idea

Detailed Description

A longer description, describing the gameplay, the look and feel of the game, …

Scalability Plan

A discussion of how the design can be "scaled" – what is the simplest possible version, what features could be added if there was enough time

Game Principles Discussion

A discussion of what game design principles should be employed in order to make sure the game is fun

Design Challenges

(closely related to the Game Principles discussion) What challenges face the team building the game in terms of making sure the game is fun? Especially in light of the scalability issue (that the team won’t have much time for implementation)

Technical Overview

A brief discussion of how you imagine this game being built. What challenges will the team overcome? Do you have ideas as to how the implementation should be done. We don’t need details here, just the basic ideas that explain why it should be practical to build it.

Technical Challenges

A brief discussion of what challenges will face the team that tries to build the game. This cuts both ways: the game must be sufficiently challenging, but not too challenging. Having contingencies to "hedge" against not being able to address the challenges is good (see "Scalability" above).

You don’t need to have too much detail – just enough to convince people. Also, in terms of grading, you need to show that you’ve thought through the issues.

3. Turning it in

Please make a posting in the “Project 3 Proposals” board on the forum. Start a new thread for each proposal, putting your names and the game name in the title. (I have created a sample). We prefer that you put the text of your proposal in the posting, but you can make a PDF and attach it to your posting instead (I think).

We strongly encourage you to use pictures (like a story board) or concept art to convey your idea. We also encourage you to attach your powerpoint (or PDF) slides as an attachment to the proposal.

Note: people will “reply” to your proposal with feedback.

4. About the Pitches

In class on Thursday,  November 1, each team will give a 3-5 minute pitch to the class. We’ll give you a warning at 3 minutes, a gong at 4 minutes, and physically stop you at 5 minutes. That’ll give only a little bit of time for questions (we need to see 10 pitches in 75 minutes!)

You should use pictures to describe your game. You can draw them on the blackboard, but you might prefer to project slides. If you want to do this, you must send the TA your slides (e.g. powerpoint, PDF, or stack of images) before noon on Thursday, November 1st.

5. Examples

Examples from the past are useful both for game ideas, as well as to see how people wrote stuff up. You’ll see good examples and not-so-good examples. (most of the game ideas are pretty good – too bad only a few get built).

• https://pages.graphics.cs.wisc.edu/679-11/category/project-3/project-3-pitches/
• http://graphics.cs.wisc.edu/Courses/Games10/wp/tags/game-proposal/
• http://graphics.cs.wisc.edu/Courses/Games08/StudentPages/GameProposals

These rules are meant to be common sense – not tricks to limit you. They are the same as the rules as in previous years.

Note: some of these requirements make more sense when you understand how the project will be evaluated when the project is done.

On one hand, trying to do a game design that fits into this funny class project setting is kindof silly – since the constraints are pretty artificial. However, any real design project is about meeting a set of constraints – and the ones imposed by a class could be the ones imposed by the reality of a company’s situation, …

I could have made up a hokey story about how these constraints aren’t because this is a class project, but rather, because you are working for a real game studio and a big publisher is considering buying you, therefore you need to demonstrate to them how good you are in a very short amount of time.

OK, the rules:

1. It must be a game (e.g. fun)

You should think about how you will use game design principles to make it fun.

2. It must be buildable by a team of 4 students in the time period provided.

This is a big constraint. There isn’t much time. You’ll basically have 3 weeks of real implementation.

So, I recommend in your design you consider 3 things:

1. What the game would be like in the ideal, if you had tons of time
2. What the game could be like if 4 people worked for 3 weeks and everything went well
3. What the game could be like if things went badly in those 3 weeks

A different way to put it: your design should have a simple version that can easily be pulled off in 3 weeks (or faster, if things go well), but can be extended into something bigger and cooler (if you have time).

2.1 It must not require code or ideas you’ve written previously

Many students in class have their hobby projects or code they’ve written previously. You can’t use this.

For one: you might not even be part of the team building your game. And while you might be willing to give another group your code, you’ll be too busy making your own game to give them much support.

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.

2.2 You must be willing to “give up” the idea

Once you pitch the idea, other students may like it and go off an build it. Anything you pitch is explicitly in the public domain.

3. It must have a low-startup overhead

Your playtesters (and target audience) will not have a lot of time. In 15 minutes, they need to figure out your game, and play it enough to appreciate it. (although, it should leave them wanting to play more)

This puts a little bit of pressure on you to make your game "demo well." A design that is hard to learn, requires you to get to level 17 before its interesting, or offers no sense of "progress" until you’ve played for hours might be less attractive. (note: the game should offer the depth for long term play – it just needs to get the player hooked quickly).

3.1 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.

4. It must be self-contained

A new player needs to be able to sit down at the game and start playing. This means that any instructions / explanations need to be part of the game itself (or documentation).

5. It must provide for a short experience, but have replay value (or extended play)

6. It must not require any intellectual property that isn’t either yours or freely available.

If you want to use a story, a character, music, … from a copyrighted source, you can’t (since you won’t have a license to do so).

If you need a technology to implement the game, it must be freely available. So (for example) its not OK to design an add-on to a commercial game (and couldn’t be feasibily built from scratch in 3 weeks).

Note: for the project, teams may use available engine platforms, providing they are either freely available or are flash (because we have flash licenses). (actually, we might not have flash licenses – I’ll have to check)

For your actual implementation, you may only use tools for which we have license to use for class projects. This basically means Open Source only. (note: while you can use Unity for your personal projects, using it for class projects or on University owned computers is against their license).

7. It must run on the computers in 1358 and 1366 CS.

An exception can be made if you choose to make things work on a mobile platform (like an iPad or phone). However: it will be up to you to arrange for devices for the playtest. Please discuss with the Professor.

8. It must be single player

This restriction is to make play testing easier. Its a great bonus if there is a multi-player mode, but there should be a single player experience.

9. It must be in good taste

Avoid gratuitous violence, references that may be offensive to some, …

Your game must get an "E" (everyone – all audiences) rating.

10. It must require non-trivial programming and design

This is a hard one to describe.

Basically, the work of building the game must be primarily computer science. It can’t just be making artwork and showing a slideshow. It has to be "hard enough" to build, but there’s a tradeoff: you don’t want to pick something that’s too hard (and risk not finishing by the deadline).

This is why we suggested a "Scalable" design above – pick something where you know you’ll have something at the end, and hopefully you’ll do better than the minimum.

Previous Ideas

Here are the past proposals:

• https://pages.graphics.cs.wisc.edu/679-11/category/project-3/project-3-pitches/
• http://graphics.cs.wisc.edu/Courses/Games10/wp/tags/game-proposal/
• http://graphics.cs.wisc.edu/Courses/Games08/StudentPages/GameProposals