One of the cool things about Javascript is that it is easy to run the program: all you need is a web browser.

In terms of the tools for writing Javascript, however, its a bit more open (since the runtime environment isn’t the programming environment).

At a basic level, all you need is a text editor to create your HTML pages and script files. However, as you try to do non-trivial things, you will quickly want to have better tools. For example, a text-editor that really helps you (with syntax highlighting and checking, and tooltips, and …) and a debugger.

The web browsers (especially Chrome) have some debugging and profiling support built in. Firefox gets better debugging support through plugins (like Firebug). It’s probably a good idea to get familiar with a debugger sooner rather than later. Learn to use it on simple programs, so you’re ready to find the hard bugs in your complicated programs.

There are a zillion text editors, IDEs, and other Javascript programming tools out there. If you find one that you think is good enough to recommend, please tell us about it in a comment in this post.

Notepad++ is a remarkably lightweight-yet-complete text editor that is javascript/html aware, and can connect to your web browser. Recommended as an easy tool for script editing.

If you’re an Eclipse user, there is an Eclipse environment for web development (including Javascript) called “Aptana.” It’s a pretty huge beast, but the Javascript editor and connection with the in-browser debugger is pretty cool. It’s pretty good at handling the various pieces you end up making in order to make something in Javascript (the scripts, the HTML, the CSS, …)

Please let us know what tools you find useful for Javascript programming and doing Project 1!

Demo Files From the JS Workshop are Here

Welcome to the course web for CS679.

This web site will serve as the main way we communicate with you. All announcements will be made here, so you should check this page regularly. There is an RSS feed for the announcements, if you like to check things that way.

In general, when something new is added to the website (like an assigment), it won’t be on the main page. However, when something new is added, we’ll make an announcement pointing you to it. This keeps the announcements page uncluttered.

The exception is the initial material put on the web before classes start. We recommend you look over all the material on the website at the beginning, so you get some sense of what’s here. In particular, make sure you:

• Read over the “Course Announcement” and “What is this class” pages.
• Have a look at the various pages linked to from the Course Info page to learn the basic policies and organization info about the class.
• Check the Syllabus and Calendar (links at the top) to get a sense of what is coming up.
• Look at the Assignments and Readings (since several have already been assigned)

This website is built using WordPress. The organization comes from trying to shoehorn a class organization into how wordpress wants to work. Hopefully, it won’t be too disorganized.

We will also use this wordpress site for other things,like for students to submit assignments (as comments to posts).

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.

First, I recommend looking at the “What is this class” page, to get an idea of what we want you to learn.

In order to teach you these things, there will be:

• Class lectures and discussions (Monday/Wednesday class meetings). We will try to keep track of attendance and participation.
• Tutorials and project help sessions (generally on Fridays). These will be discussions or hands-on lectures where we try to help you with the projects, and the tools you need to work with. If you can figure things out yourself, these are optional. We will try to make them valuable to everyone.
• Readings. There will be many required readings, and lots of optional ones as well. We will try to confirm that you’ve learned from the readings through class participation and assignments.
• Assignments. These will be things you must do to show that you are learning stuff. More importantly, they will be designed to help you think about what you’re supposed to be learning in the readings and lectures so that you can internalize it better.  Assignments will generally be turned in online – with mechanisms explained with each assignment.
• Projects. Three of them. Of increasing size and difficulty. Each will require you to make a game. This is the main piece of the class. Each project will have a number of sub-parts (generally, there is something due every week). Projects will be done in assigned groups of various sizes (see the discussion of groups). Projects will also have individual components (generally asking you to reflect on the group work).

Grading:

Grading (or evaluating) is the least fun part of teaching (for me at least). In the past, most people taking this class have been sufficiently dedicated that its clear that everyone deserves (and receives) a good grade.

Given the diversity of experience in this class, assigning grades fairly is a challenge. People who are experienced programmers will learn different things (and produce different outcomes) than those who are less experienced. Our goal is to reward people for successfully learning new things.

There is no set mechanism to determine the grade. Each part can affect every other part. If you never show up to class, you will get a bad grade even if your projects are awesome. If you are quiet in class, you might make up for it by participating in online discussions and doing the assignments well. If your project doesn’t turn out the way you’d like, you might make up for it by discussing what you would have learned from it in your “reflection” discussion, …

But overall, the graded components are:

• Projects. We’ll evaluate the checkpoints, as well as the final results. We’ll grade what the group turns in as well as individual pieces (generally, each project will have a “reflection” exercise) done individually.
• Assignments. We’ll keep score to make sure everyone does everything. For some, we’ll just check to make sure you do them. (even if its check/no-check, we’ll note exceptional or unacceptable performance). For others, we’ll provide more detailed feedback.
• Participation. We’ll keep score of who shows up, and try to make sure that people are really participating mentally as well as physically.

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.