The “Course Info” posting category has many posts with more details. In particular, refer to the Course Policies page for more details on many of these things, and the Course Announcement for the basic idea behind the class.

Instructor: Mike Gleicher (gleicher@cs.wisc.edu), office: 6385 CS&S, office hours Tuesday 11-noon, or by appointment.

Official TA: Mark Dhillon (mdhillon@cs.wisc.edu)

Unofficial helpers: many!

Textbook: none required (all readings will be provided)

Lectures: Tuesday and Thursday, 2:30-3:45, 1263 Computer Sciences. Lectures are required.

Lab Time: There will be various class activities from 2:30-3:45 on (most) Fridays. Usually these will be in either 1358 or 1366 CS.

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. Communications within the class will be handled in an online forum.

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.

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 policy page.

Grading: Graded projects with an adjustment for participation (online and in-class), which includes assignments.

In general, we ask that you be reasonable and follow the common sense and academic conduct guidelines as in all other classes. There are a few issues that are unique to this class, since it involves larger scale projects and team work.

The general principle: if you’re unsure of something, ask for a clarification.

Grading

We like to separate assessment and feedback. But you might care about the former. If its any consolation, the average/median grades in this class historically been very high. You are graded against expectations, not against other students. If you do awesome work, you get an A. Even if others do even more awesome work.

The main aspect of your grade are your projects. Your projects will be weighted by the length of the project (tentatively this is 3,4 and 6 weeks for the 3 projects). We may make adjustments based on circumstances (if you have some issue come up that hurts your performance on one of the project, we may weight that one lower). Note that project grades are based on the whole project performance (including early milestones), not just the final results.

All other aspects of this class are lumped under “participation” – in fact, even the class assignments are considered participation (since they will usually be used as part of class discussions). At the end of the semester, we will combine quantitative metrics (include attendance, but also metrics from the online forum) with our subjective opinion of your participation. This participation will be used to adjust the grade determined by your projects. We may reduce your final grade by up to a full letter grade if you are consistently below our expectations (e.g. never participate in discussions, blow off lots of assignments). We may raise your grade if you are a particularly valuable contributor to the class. (usually, students who are valuable contributors also do awesome projects, so this is not an issue).

For projects, groups get the same grade for the group parts, although there may be individual aspects of the projects (such as per-person reflections). See collaboration policy.

Attendance and Participation

A big part of this class is to work collaboratively to learn. Also, much of the content comes only in-class. Some if this is because we avoid too much out of class work (like reading) so you can focus on projects. Some of this is that some topics are best learned through discussion and thinking.

In class participation is difficult to assess and very subjective. It also can be difficult for some people. For example, if you are shy and/or not a native speaker, you may be less comfortable contributing to a class discussion. For this reason, we allow online participation in the forums to supplement your in-class participation. If you feel like you aren’t contributing in class, be sure to make up for it online!

In general, we require you to come to class and participate. While we may try to keep score a little bit (e.g. taking attendance, counting contributions), the subjective impression of the course staff is more important. 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.

Generally, it is a good idea for you to inform us if you will miss class. Please send email to the TA and the instructor.

It is worse to show up and not participate. In particular, if you come to class and just use it as a time to catch up on your online chores without paying attention, not only do you not get anything out of class, but you detract from the experience of others.

I will allow students to use mobile computing devices in class (as they have many legitimate uses). However, I reserve the right to demand that you prove that your use of a device in class is legitimate, and to revoke your privilege if you abuse it. For example, we sometimes demanded that students that were taking notes online in class show them to the professor.

Readings

There are no required textbooks.

We will provide you with readings online. Some of the readings will be in a protected course reader (with controlled access for students in this class). 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.

Due times and Late Policies

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, and it might be important for some next step. For example: 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. (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.

Collaboration

Working together is a major piece of this class. See the Collaboration Policy for some discussion.

All of the projects in this class will require you to work in a group that we assign. See the “why groups” page for info. If you don’t like this (or think that your schedule or personality might make it difficult for you to work in this arrangement), you might consider not taking this class – it’s a central part of the class.

Friday lab sessions

We have found it immensely valuable to have class “lab sessions” – whether its for tutorials, playtests (sessions where we each play each others games), or even just shared work time where people work with others around (so people can learn from each other, get a sense of what each other is doing, etc). Some of these sessions will be pretty essential (for example, project demos), while others are less so (the shared work times).

Unfortunately, this class does not have a formally scheduled lab. We will use Fridays 2:30-3:45 for the shared lab time. If you have a recurring commitment in this time slot and know you won’t be able to come at all, please inform the Professor at the beginning of the semester.

Computing Environment Policy

This class has been assigned to the “Windows Computing Labs” in 1358 and 1366 Computer Sciences. 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).

For assignments that run in a web browser: you may specify which major browser your assignment works best with. You do not need to make your project cross-browser, but it must run in some browser available in 1358/1366 CS. Be sure to specify which.

In general: if it doesn’t run in 1358/1366, it doesn’t count as running.

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). We will grant exceptions to this policy only in rare (and pre-arranged) circumstances.

Your Intellectual Property and Ownership

All of your work in this class may be presented to others, and therefore it is difficult for you to retain “ownership” of certain aspects of it. We therefore encourage you to consider your contributions (including projects) to class as being given to the class, which means you may not want to use things that you consider particularly valuable. While the actual legal technicalities are probably more complex, you should probably consider any idea or code you contribute to class (either in discussion or handed in as part of a project or assignment) as being placed into the public domain.

For example:

1. If you have an idea for a game that you think is really awesome and want to start a company so you can get rich and famous from it, you might not want to use it in class (since others will see it, and you can’t prevent them from building it too).
2. If you’ve built some software outside of class, you really shouldn’t “bring it to class” unless you really are giving it to everyone.

For these reasons, we will discourage people in bringing code and ideas they’ve been working on outside of class – and may even require you to explicitly release code or designs to the public domain.

Intellectual Property of Others

You must respect the intellectual property of others. This should go without saying, but it really comes up in a games class.

You may only use things that (not only) do you have legal license to use, but also that you have legal license to give to others in the class. This is particularly an issue with artistic resources: you need to be careful if you download a piece of music, copy a piece of artwork, use the characters or stories from a book, etc. If you use something, make sure you are using it legally, and give it proper attribution.

Another issue is that you must be sure that the things you use (art and code) are things that are legal for you to use in the class setting. We are aware of some software (the Unity game engine, for instance) that are free for personal use, but class is not personal use. There is a similar issue with the Autodesk content creation tools (e.g. Maya and 3D Studio Max), but the CS department has licenses for these.

Online work:

We will use online mechanisms for many aspects of this class. This is important because it is not only how you will share your work with us, but also because it is how you will interact with other students. Interaction with other students is a central component of this class. Some specific elements of this:

1. Many of your assignments will require you to post things on the online discussion forum so that course staff (and other students) can see them. In fact, some of your online assignments will require you to give feedback to your classmates.
2. Part of your “participation” in this class is to contribute to the online forums.
3. Your projects for the class need to be posted online so they can be accessed from the web so that course staff and fellow students can look at it. We will give you mechanisms to restrict access (although we encourage you to make it visible to the world).

There are some privacy rules about student work (FERPA) that might apply to these things. Actual compliance is a complicated thing. For reasons of fairness:

1. No grading information from the course staff will be given in either the online discussion forum, or on the web. We may send unofficial grading information to you by email.
2. The online discussion forum will be restricted to class members only.
3. You will be given the option of restricting access to your projects on the web. Unfortunately, the default mechanism is to restrict the pages to any person with a valid CS user account (not just people in the class). This is usually not an issue (since other people don’t necessarily want to look at things), but if you are uncomfortable with it, we can try to make other arrangements.
4. Your projects may be shown to others after the end of the class. If you prefer that we do not show your projects to people outside of the class (for example, to students in future editions of the class), please let us know and we will archive your project at the end of the semester.
5. If you feel that we are not adequately protecting your rights (from FERPA), we will allow you to opt out of online participation. However, you must notify the Professor ahead of time, and make alternate arrangements.

Misuse of the online mechanisms of this class will not be tolerated. We reserve the right to remove inappropriate contributions to the online forums.

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 their 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 we will not always honor them (this post explains why).
4. Ultimately, each student is responsible for the material.
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. For assignments designed as individual efforts, every student must turn in their own assignment, and is responsible for it.
7. For group projects, specific instructions will be given (generally it is turned in once, and other group members give pointers).
8. 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).
9. 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.
10. 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.
11. 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)

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

CS679: Computer Games Technologies, Fall 2012

This class will be most similar to last year’s (2011) offering (see the old course web). Previous years (2010, 2008, 2007) share some of the same course design, but our new emphasis on the design and software engineering aspects of the class, as well as our use of web-technologies for projects first emerged in 2011.

Some basic things:

Instructor: Mike Gleicher

Class Meetings: 2:30-3:45 Tuesday/Thursday, 1263 Computer Sciences. Note: we will also have some sessions in the computer labs, and we will also have scheduled sessions outside of class times (to be determined). You are are expected to be in class.

Intended Audience: Students who are interested in how computer games work, how the technologies behind computer games (like high performance graphics and rich internet applications) may be applied to other things, and/or want the experience of working on a non-trivial project as a group from design through testing.

Workload: This is a project intensive class. Over the course of the semester, you will build 3 games. Most of it in groups ranging in size from 2-4. On the other hand, this is not purely a project class. There will be reading and other assignments, and you will be expected to demonstrate that you’ve learned the technical materials.
Many students tell me the class was a lot of work. Few complain.

The story…

A “Games class” in computer science can mean a lot of things. In fact, it has meant a lot of different things to me over the years I’ve taught it. This year, my thoughts have evolved a bit. Understanding what I think this class is is important for you to know what to expect, what you will be doing (and why), how you will be evaluated, …

Over the course of the years, the class has evolved into being more of a project-based experience to help students learn about how to design and build cool interactive systems. This means learning how to work on projects in a group, to think about practical issues like efficiency, and understanding design and usability is as much a part of the class as learning some fancy new graphics trick or AI technique.

I see this class as having three interconnected parts:

1. Technology for Games – The advanced computer science that goes into making games – graphics, AI, … Games have interesting demands on technology, with demands that are different than other applications.
2. Games as Technology – The “science” (or art) of what games are and how to make good ones. Game design is particularly interesting because understanding how to make fun games gets at general issues of how to make “stuff” that is enjoyable to use, and to bring elements of game design to the creation of things other than games.
3. Building Games – How to actually create the software that is a game. While a lot of this is “just” software engineering, the desire to make a game is a good excuse to learn how to work with others to make a non-trivial program.

In this class, you will learn about all 3. Each of these 3 topics is a key component of the class. This is a break in philosophy from previous offerings of this class which were focused on #1, and did a little bit of #2 and #3 since I wanted people to do a project.

What this means is that you should expect course content (lectures, readings, assignments) related to all 3 topic areas. We’ll spend time talking about software engineering, and expect you to do projects where you’ll get to try your hand and building things. We’ll spend time talking about game design, and try our hands at designing games and seeing how game design ideas can be applied in “the real world.” We’ll spend time talking about some advanced technical stuff, and try to apply them. …

This class is an experiment. There are many things a class on "Game Technologies" could mean. There are many different "technologies" involved in interactive systems and games and many different ways to teach people about it. The idea here is to pick some of the software technologies that are used in interactive applications and games and some of the ways to learn about them, and see how they work out in a class setting.

During this class, we’ll pick topics related to games that are some combination of:

• Things that people in the games industry have told me they think are valuable for students to learn in a class like this.
• CS topics that I think are important for computer games.
• Topics in art, design, and psychology that are important for designing good interactive systems.
• While this class is not "graphics 2", there will be an emphasis on graphics and animation techniques that apply to interactive things like games.
• Projects that seem to be fun an interesting to do as part of a class like this.

If it sounds like I’m making this up as I go along, then you’ve read correctly.

A big part of this class is its project orientation: you will work on a pretty significant project as part of a team. You’ll get to see a project go from the initial design stages all of the way through testing. Experience working as part of a team and following through on projects is something that is valuable (for example if you’re looking for a job).

According to the Course Catalog:

Survey of software technology important to computer games and other forms of interactive technology. Real-time image generation, managing complex geometric models, creating virtual characters, simulating physical phenomenon, networking technology for distributed virtual environments.

Who can take it?

The official prerequisite is CS559 (Computer Graphics) – but I am open to the idea that some people have learned equivalent material on their own, so if you’re "self-taught" you should contact me. Having taken a graphics class is useful because many of the "technologies" we discuss are graphics related (animation, shaders, …).

If you really want to take this class, but have no graphics experience, please come talk to me. If you’re an art/design/education/… student who has a strong interest in game technology, we might be able to accommodate you. CS679 is targeted towards CS students who are experienced programmers – but if you have different (but relevant) skills, we might be able to adapt the class for you. You might need to sign up under a different number. Please contact Prof. Gleicher to discuss it.

When does this get offered?

Unfortunately, I cannot be sure when this class will be offered again. Basically, it gets offered if and when there are enough people to cover all of the other classes that need to be taught. Sometimes, we only find the opportunity to have a class covered at the last minute, which frees someone to teach this.

Right now, there is no plan to teach the course in Spring 2013, or in the 2013-14 academic year. But surprises happen. I am sorry that I can’t give a more definite answer, or offer this course on a regular schedule. At least we get to offer it period.