CMPUT 350 Advanced Games Programming

Important news: Starting F2018 (CMPUT 204 or 275) and (CMPUT 201 or 275) will be prerequisites for CMPUT 350. See details below.

Check often. If you have clarification questions send a message to the forum (link below). I am not using eClass in this course, except for the forum and assignment submissions. In particular, due dates will NOT appear in your eClass calendar!

Fall 2017, Instructor: Michael Buro
Lectures: TR 11:00 - 12:20 SAB 331 (starting Sep. 5)
Labs: T 14:00-16:50 CSC 153 and 159 (starting Sep. 12)
Office hours MB: TR 9:30-10:00, R 12:30-13:30 (ATH 337)
TA Office hours: send email to TA to arrange a meeting
TAs: Trevor Davis (trdavis1@...), Christopher Solinas (solinas@...) [UAlberta accounts]



Important: registration is open to anyone who has passed (CMPUT 201 or CMPUT 275) and (CMPUT 204 or CMPUT 275) and a 100-level math course. If you haven't, but think you have equivalent knowledge in C programming - covering pointers, dynamic memory allocation, bit operations, input/output, makefiles, debugging - in addition to basic linear algebra knowledge (vectors, matrices, matrix multiplication, cross product, etc) and fundamental algorithms and data structures - please schedule an appointment with me to discuss your case. Students without such prerequisites will be withdrawn from the course without notice.



Tentative Schedule

                  Labs          Lecture     Assign.  Lecture
                                (AI/Gfx)             (C++)
  Week of     Tuesdays (+1)      Tues.(+1)  Wed.(+2) Thurs.(+3)
  (Monday)    14:00 - 16:50   |  11:00      22:00    11:00
 1. Sep.04        %           |   L1                  L2       R1
 2. Sep.11        B0          |   L3                 +L4       R2
 3. Sep.18        B1          |  +L5        A1r      +L6       R3
 4. Sep.25        B2          |  +L7                 +L8       R4
 5. Oct.02        B3          |  +L9        A1d/A2r  +L10      R5
 6. Oct.09        B4          |  +L11       TS       +L12      R6
 7. Oct.16        B5          |  +L13       A2d/A3r  +L14      R7
 8. Oct.23        B6          |  +L15       PP       +L16      R8
 9. Oct.30        B7          |  +L17       A3d      +L18      R9
10. Nov.06        B8          |  +L19       PPR1     +L20      R10
--  Nov.13  %(Reading Week)
11. Nov.20        B9          |  +L21       PPR2     +L22      R11
12. Nov.27        B10         |  +L23                +L24      R12
13. Dec.04  P CSC 333 2-5pm   |  +L25       PR       +L26      REX
Legend: Li         : lecture i (T: AI, R: C++/Gfx)
        Bj         : lab j
        Rl         : reading assignment l
        Ajr/Ajd    : assignment j released / due (Wednesdays 22:00)
        Ajq/Ajs    : assignment j questions / solutions
        %          : no class / lab / reading assignment
        +          : 12 randomized in-class quizzes (about reading assignments, C++/Gfx)
        TS         : project team selection (Oct. 11, 22:00)
        PP         : project proposals due (Oct. 25, 22:00)
        PPRi       : project progress report i due (Nov. 8/22, 22:00)
        P          : project presentations
        PR         : Project report and software due (Dec. 6, 22:00)
        Final Exam : Dec-14-2017, 9-11am, Education Gymnasium Rows 9,11 (seats 1-15),
                     CLOSED BOOK FORMAT


This course is aimed at undergraduate students interested in learning C++, AI, game theory fundamentals, and graphics programming for video games. The course has five parts:

  1. C++ programming: from C to C++, classes, OO programming, templates, STL
  2. AI for video games:
  3. RTS game engine internals: map representations, game frame cycle, fast collision tests
  4. 3D graphics primer: OpenGL intro, fundamental gfx primitives and functions, from geometry to pixels on the screen (some basic linear algebra and geometry needed: 4d vectors, matrix multiplication, 3d rotations)
  5. Team Project (improve video game AI using C++)

Building fast game engines and smarter AI systems for video games is challenging and fun. This course will give students hands-on experience which can open the door to the video games industry!

Course Structure

Teaching C++, game AI, and OpenGL will be interleaved. Each week the lab session and the Thursday lecture will be devoted to C++ and OpenGL programming, and the Tuesday lectures first to game AI. This allows us to implement AI algorithms in C++ earlier in the course.

Also, instead of the established lecture-lab-assignment-exam routine, in this course we will try something different: the inverted class room. The goal of this teaching philosophy, which has been experimented with extensively in recent years, is to teach students to become independent learners and problem solvers more effectively. The main idea is to replace lecture time that used to be filled with instructors' monologues by more valuable interactive problem solving sessions.

In this course we will invert 50% of the lectures:

Benefits: Expected time investment per week: ~8h

Course Work

There will be 3 assignments, 12 quizzes, 9 lab exercises, a team project, and a final exam.


Please visit this page to learn about our interpretation of letter grades. In this course grades will not be curved, they are absolute - closely following these cut points:
≥ 95% A+   ≥ 90% A    ≥ 85% A-
≥ 80% B+   ≥ 75% B    ≥ 70% B-
≥ 65% C+   ≥ 60% C    ≥ 55% C-
≥ 50% D+   ≥ 45% D    < 45% F
subject to this important condition: if the result of the final exam is less than 40%, the final course grade can't be better than D+.


Quizzes at the beginning of 12 randomly selected lectures test whether you have done your weekly reading assignment. Missed quizzes are worth 0 marks, but in the end we only consider the best 10 quizzes out of 12.

Lab Exercises

Each lab session is concluded by a graded lab exercise in which students solve C++ programming problems that relate to the previous week's reading assignment and related Thursday lecture. Missed lab exercises are worth 0 marks, but in the end we only consider the best 8 out of 10 lab exercises.


Assignments are medium-sized programming tasks. Solutions have to be handed in by 22:00 on the due dates electronically via eClass. Each student will be allowed AT MOST ONE assignment submission that is late by at most 24 hours. For such late assignments 30% of the achievable marks will be deducted. Any subsequent late submission will receive 0 marks - as will submissions that are late by more than 24 hours. Assignment marking related questions will be addressed by the TAs. You need to contact them within 2 days after you the marked assignments have been returned. Later inquiries will be ignored.


Project groups will preferably consist of 4 students who will work together on a (video) game (AI) project. This year, possible project topics are:

Each team needs to setup a (private) github/bitbucket repository for the project and give the TAs access, implement and test modules, gather performance statistics, and describe their work in a project report and an in-class presentation.

Team Selection

Pick your team mates and send me an email (subject: [350] TS) containing a list of team members and a tentative project title by the TS deadline above. Only one email per team, please.

Project Proposals

Each team has to submit a project proposal to me (see PP deadline above) (subject [350] Proposal). The format is 1-page, 12pt proportional font, ≤ 2.5cm margins, pdf. The document must motivate your project, describe its goals, and how to achieve them.

Project Progress Report 1

Via eClass, each team has to submit once

Also, all private team git repositories (either on bitbucket or github) need to be in place, with the TAs and I having access. Details about setting up git will be sent in a forum message.

Project Progress Report 2

Via eClass each team has to submit a report that describes your project progress (2/3 of the proposed work done), obstacles you ran into, how to overcome them, possible revisions of your project goals, and a breakdown of work already done by whom. The format is 1-page pdf, 12pt proportional font, ≤ 2.5cm margins.

Project Presentation

Teams that don't present their work will receive 0 marks for the presentation.

Project Submission

Project file needs to be submitted via eClass by Dec. 6, 22:00. Late submissions will not be accepted and will result in 0 marks for software functionality and the report.

Only submit once per team. The file must not be bigger than 30MB.

Contents of :

Make sure your code compiles without warnings and does not crash. Lots of marks will be deducted if this is not the case!

The project report is a more in-depth document which you would use to convey any information about your project including motivation, description of your approach and software modules, evaluation, and future work.

Both the presentation and the report are primarily means by which you can communicate your results. As such, you should focus on whatever you feel is significant that we should know about.

At the end of the report each team member needs to describe his or her contributions to the project in fewer than 200 words, and indicate whether he or she agrees with the other team members' descriptions with a short explanation if this is not the case.

Format (n = number of team members):


  n times {
  Team member name:

    describe own contributions

    n-1 times {
      [ other team member name : AGREE ]  or
      [ other team member name : DON'T AGREE, because ... ]

In case of disagreements EACH TEAM MEMBER needs to submit the project zip file via eClass as described above. If all members agree, only ONE SUBMISSION is required.

If you don't want to show your disagreement in front of your team, you can email one of the TAs directly to tell him if you disagree with the stated contributions of any of your teammates.

Project Evaluation

If there is evidence of lopsided project work distributions, individual team members will be evaluated using the following method:

Let K be the team size, and p_i an estimate of the member i's contributions (≥ 0, sum = 1). Then the work factor (WF) for each member is

WF_i = p_i * K

All project related marks will be multiplied by WF_i. The total in each category can't exceed 140%, though. Example: if the project report received 70%, one student did 80% of the work, the two other 10% each, the updated report scores are: 0.7*0.8*3 = 168% which gets capped to 140%, for the most active member. The other students receive 0.7*0.1*3 = 21% each for the report.

Final Exam

The final 2h exam will cover all course material: The exam question format will be similar to that of the quizzes, mainly focusing on concepts, but at times going beyond simple recall questions. Questions on the AI lecture parts will have higher probability (see the "final" reading assignment). Also, there will likely be a multiple-choice question, as well as bonus questions which can help you regain lost course mark ground.

To prepare for the exam, read the lecture material and then try to answer all reading/assignment/quiz questions *before* looking up solutions. Forming study groups is highly recommended.

Deferred final exam date: Monday, Jan. 8, 2018, 14:00 to 16:00 (ATH 332)

Academic Integrity

The University of Alberta is committed to the highest standards of academic integrity and honesty. Students are expected to be familiar with these standards regarding academic honesty and to uphold the policies of the University in this respect. Students are particularly urged to familiarize themselves with the provisions of the Code of Student Behaviour and avoid any behaviour which could potentially result in suspicions of cheating, plagiarism, misrepresentation of facts and/or participation in an offence. Academic dishonesty is a serious offence and can result in suspension or expulsion from the University. (GFC 29 SEP 2003)

Copying and cheating on assignments will be penalized with a mark of 0 (see the standard handouts for academic dishonesty and copying and cheating), and Section 30.3.2 Inappropriate Academic Behaviour.

Course Policies

Unless otherwise noted, the CS Department Policies are in effect.


In this course we use the "Consultation" model: students are encouraged to discuss and solve problem sets in small groups to speed up learning and stimulate idea exchange. In the end, however, students must write down their own solutions and be able to solve similar problems independently.

Regardless of the collaboration method allowed, you must always properly acknowledge the sources you used and people you worked with. Failure to give proper credit is considered plagiarism. In general, academic dishonesty is a serious offence and can result in suspension or expulsion from the University.

Your professors reserve the right to give you an exam (oral, written, or both) to determine the degree that you participated in the making of the deliverable, and how well you understand what was submitted. For example, you may be asked to explain any code that was submitted and why you choose to write it that way. This may impact the mark that you receive for the deliverable.

Note that this potential additional questioning about your deliverable is part of the assessment process, both summative (for marks) and formative (for feedback to you and us). It is intended to give us additional information about what you have learned. So, whenever you submit a deliverable, especially if you collaborate, you should be prepared for an individual inspection/walkthrough in which you explain what every line of your code, assignment, design, documentation etc. does and why you chose to write it that way.

last modified on  ; you are visitor # since Aug/7/2017