See also “What is this Class” and the “Course Announcement”

Instructor: Mike Gleicher (gleicher@cs.wisc.edu)

Co-Instructor: David Gagnon (djgagnon@wisc.edu) – note: David is an unofficial volunteer

TA: TBD

Textbook: no required textbook to buy (see the Books page), there will be numerous other readings

Attendance and Participation: required (see this post)

Lectures: Monday and Wednesday, 2:30-3:45, 1221 Computer Sciences (unless we move)

Friday Sessions: There will be various class activities from 2:30-3:45 on (most) Fridays.

Communications: All announcements will be made to this website (rather than to a mailing list). You are responsible for keeping up. The announcements (news page) has an RSS feed, if you are so inclined.

Projects: There will be 3 projects of increasing size (roughly 3 weeks, 4 weeks, and 6 weeks; groups of 2, 3, and 4)

Final Exam: There will be no final exam. We will have a demo session in the exam time slot. (December 22, 10 AM)

Collaboration Policy: We want people to work together to learn, and to learn to work together. See the Collaboration Policy page.

Computing Environment: Students can use the computers in 1358 CS, 1366CS, or any other computers they have access to. See the Computing Policy page.

Grading: (see “What will we do in this class? (and how will we grade you?)”). Grades will be based on projects, assignments, and participation. Rather than thinking about it as additive parts (e.g. projects are 75%), think about it as multiplicative (project grade * assignment grade * participation grade + generosity factor).

This class has been assigned to the “Windows Computing Labs” in 1358 and 1366 Computer Sciences. These are brand new machines and should provide a nice environment, should you chose to use them.

You are free to work on whatever other computers you have access to. However, all demonstrations must run on the machines in those labs (unless other arrangements are made).

We make no requirements as to what tools that you use. For some of the assignments, we may add requirements (like they must run in a web browser, or be written in a particular language).

If you chose to use other assets in your program (libraries, 3D models, music, images, etc.) they must be things that you legally have the right to use, and you must give proper attribution.

For assignments that run in a web browser: you may specify which major browser your assignment works best with (although, we recommend that you try to make it run in all of them). In the event that the CSL does not support the current version of the browser you prefer, you may install the “portable” version of Firefox or Chrome, in order to have a recent version.

For this class, there will be a number of readings.

Some readings, will be assigned for you to read before the lecture in which they are discussed. Other readings will be for you to “read behind” – to read after the ideas were introduced in the lecture. Often, readings will be coupled with a written assignment designed to help you think through the reading (and help us check that you’ve done it).

Some readings will come from chapters in books. You are not required to buy any books – all the chapters will be provided (although, often it will be through Wendt libraries online service.

Some readings will be papers to download.

Many of the readings we give to you will be placed in a protected course reader. In order to access this reader, you must use your valid CSL login. The reader is located at: https://graphics.cs.wisc.edu/Courses/Readers/Games11/

Note: we put things in the protected reader to honor copyright restrictions that allow only to provide documents for class use. Please do not redistribute them.

Whenever anything is assigned, the first thing people want to know are “when exactly is it due” and “what happens if I am late.”

In general, we make deadlines based on when things really need to be done. We’ll ask you to do readings and exercises before a lecture where they will be discussed. We’ll ask you to turn in your project before the demonstration where it will be evaluated. This will sometimes add some additional constraints (we’ll need to read over comments before lecture so we can work them into the discussion, …)

So:

• Each assignment/project component will have an explicit due date and time. Generally, there will be a reason for that (even if its just “we want you to be done with it so you can move on to the next thing”).
• If a time isn’t given, then the deadline is the day. If the deadline is Thursday, then the assignment is due Thursday. That means not Friday. If its after midnight (12:01am Friday is not Thursday).
• Anything turned in late will be noted. It will be penalized if it effects evaluation. If you turn something in too late for a demo, or after we read the assignments, we will note that you did something, but we may not be able to make alternate arrangements.
• If you are consistently late (or otherwise do not follow direction) it will effect your grade.

In general, our goal is to give you as much time as possible to do great work, subject to the constraint that we need to have time to look at it.

If you notice, this is a 3 credit class, but scheduled as 225 minutes (3 & 75) per week (which is what a 4 credit class would be).

Sorry, you aren’t getting a discount – there will not be 3 power lectures per week.

The class is “overscheduled” to force people to reserve that 75 minutes in their week. We have permission from the Dean to do this.

Mondays and Wednesdays will be “lecture days” – these are required class meetings. This is the 150 minutes of class time a normal 3 credit class is supposed to have.

Fridays are “optional” labs, tutorials, group-work times, … By having these activities at the same time, and in a scheduled class slot, we know that there is at least one time during the week when there should not be any scheduling conflicts for anybody. We know that groups will be able to find a time to meet. We know that we can schedule help sessions and other activities.

(note: we might occasionally  change the schedule to handle an emergency)

Some of the things we plan for the Friday time slots:

• Playing and discussing games as a group (part of learning about game design is to play them – and discuss them)
• Help sessions related to projects
• Demo sessions (for you to show off your projects)
• Group work time (where groups can meet to work on projects, with others around for conversation)

You are required to come to class and participate. Some of this is because a lot of the class material will only happen in the lectures / exercises, some of this is because we need to know that you are learning stuff (and don’t want to give too give exams). Some of this is that it will make it more fun and interesting for everyone (since we’ll hear from different points of view).

Attendance at “lectures” is required. Generally, this is Monday/Wednesday of each week. We will keep score.

If you are going to miss a lecture, inform the instructor.

Attendance at the "Friday Sessions” is optional. If we do some evaluation (like keeping score of participation), we will provide some way for you to do this even if you do not attend. However, you may need to find another way to learn the material.

Attendance means more than just showing up. It means being part of what is going on. It means paying attention and trying to learn. The class is large enough that not everyone will be able to participate in the discussion all the time – but everyone should make some effort to contribute.

Note: that if you cannot contribute through normal “class participation” (we realize that some people are more outspoken than others), we will provide other mechanisms (like making more postings to online discussions).

The various class activities (assignments, projects, take-home assessments) are required for everyone. We’ll consider the assignments, assessments and class participation together: so if you do poorly on one, there is the potential to do better on other parts.

In this class, many of the activities will require you to work in groups.

We do this for several reasons, including:

1. Actual game development is done (almost always) in groups.
2. Almost all work is done in groups.
3. Learning to work in a group is an important skill, and one that you can always get more practice in. Giving you group project experience is an explicit goal of the class. (see “What is This Class”).
4. By working in a group, you can do more substantial projects. Three people can do more than one (admittedly, not three times as much).
5. By working in a group, you will have access to a more diverse array of skills than you would have working alone, which leads to cooler projects.
6. Teaching others is a great way to learn.

The groups you work in will be assigned. You don’t get to pick who you work with. We will take requests, but the instructors will ultimately make the assignments. (see collaboration policy). We do this for a number of reasons, including:

1. Some people in class don’t know that many other people, and its unfair to them.
2. In the real world you don’t get too much control over the group you work in, so assigned groups are good practice.
3. We may try to balance skills and interests.
4. In the real world, stuff happens. Group members get sick or quit, turn out to be unreliable, etc. On the other hand, people often rise to the occasion.
5. We can make sure no one falls through the cracks.
6. We can respond to unexpected situations (problems and opportunities)

If your group really isn’t functioning, discuss it with the instructors. Often, a mal-functioning group is an opportunity to learn to work together better. We have ways to respond to unexpected situations.

We have done this for the 3 previous offerings of the class. We have never had to split up a group. We have never had a catastrophic failure (where some group issue prevented a team from completing a project).

There are downsides: you might have a group whose schedules (or personalities) clash, or where people have very different levels of motivation, or have different amounts of time they can devote to this class. However, even if this does happen, the process of learning how to deal with it may be good for you.

The upsides of assigned groups (in terms of fairness, learning opportunities, better projects, …) really does outweigh the downsides.

Computer game design and development (and Computer Graphics) is (usually) a team sport. In fact, learning computer game development (and, arguably, learning in general) is best done in collaboration with others. Unfortunately, in a university class setting, we have the unfortunate constraint that we must grade individuals independently, so we need to have people work independently on graded assignments so that we can assess them. Therefore, there is a fine line between "collaboration" and "academic misconduct".

For CS679, we want to encourage collaboration. However, we also need to make sure that each individual gets appropriate credit for there work.

To make things more complicated, much of the work in CS679 is done in groups (of 2, 3 or 4). Group work in class can be problematic because of the diversity of skills, interest, ability, time commitments, schedules, … And the fact that we need to assess both individually and as a group.

Students are encouraged to discuss class topics and assignments with other students, subject to the following rules.

1. If you are unsure if something is collaboration or academic misconduct, please ask the instructor or TA for clarification.
2. We will be explicit whether an assignment, project component, or exam is an individual effort or not. If it is not clear, ask.
3. We will assign people to groups. We might ask for requests, but in generally, we will make group assignments (this post explains why).
4. Ultimately, each student is responsible for the material. Projects, assignments, and exams will require you to understand the assignments, so be careful not to rely on help since at some point you might need to do it your self.
5. Collaboration must be a two way street. The person giving help must OK it. (e.g. don’t look at someone else’s work without their permission).
6. It is not OK to broadcast help. Its OK to answer someone who asks for a hint, but its not OK to post a hint to a mailing list or web page. If you have something that you would like to offer to the class, please send it to the instructor.
7. For individual efforts, every student must turn in their own assignment, and is responsible for it.
8. For group projects, specific instructions will be given (generally it is turned in once, and other group members give pointers).
9. When a group project is turned in, all members of the group are responsible for it. The group should turn in a single hand in (unless specifically instructed). Note: most group efforts will also have individual components (which must be done, and handed in, by each individual).
10. Projects must be "substantially" written by the student or group handing it in. In particular, the "meat" of the efforts must be completed by the student/group handing in the project.
11. Any code that you didn’t write must be given proper attribution. If you grab a piece of code from the web (including the class sample code!), another student, some book, … – YOU MUST SAY SO! It is OK to use pieces of sample code – providing that you give proper credit to the author.
12. We will give you example code to work with for various assignments and projects. Be sure to give it proper attribution.

Some implications on group work:

1. The work of the group will be evaluated as a single thing, and the group will be given a single evaluation for the “group parts.” Usually, there will be an individual component to any group work (that will be evaluated independently).
2. The projects are designed to be done in the appropriate sized groups. Part of the goal is to force you to learn to work together. The group turns in a single project. If you do multiple, individual projects, you need to pick the best one and turn it in. This is rarely the best strategy (in terms of learning or actual project quality).

So…

• It is OK to ask a classmate for help on one of the questions on a written assignment. It is not OK to "borrow" their assignment and copy it without their permission. It is not OK to just copy it without understanding it (since you won’t learn the material).
• It is OK to ask a classmate for help looking over your code to find a bug. It is not OK to use a piece of their code without giving them proper attribution, or if its an important part of a project.
• It is OK to use the provided example code, or a data structure implementation you find on the web PROVIDED THAT YOU GIVE PROPER ATTRIBUTION. It is not OK to use a piece of code on the web for a central piece of an assignment (like a required image processing routine)