This is an archived course. A more recent version may be available at ocw.mit.edu.

This Course at MIT

Course Overview

This page focuses on the course CMS.611J/6.073J Creating Video Games as it was taught by Philip B Tan, Sara Verrilli, and Richard Eberhardt in Fall 2013.

Students learned creative design and production methods, working together in small teams to design, develop, and thoroughly test their own original digital games. Design iteration across all aspects of video game development was stressed, such as game design, audio design, visual aesthetics, fiction, and programming. Students were required to focus test their games, and have to support and challenge their game design decisions with testing and data analysis.

Course Outcomes

Course Goals for Students

This course was about learning the proper processes and procedures for working as a team on a complex, multi­functional project. While successfully delivering the project was important, the focus was on teaching students to practice and improve project management and group teamwork skills. Grading included the methods, tools, and processes that students use to develop their games, as well as the justification and explanation of the choices made in team organization and game development.

Possibilities for Further Study/Careers

Students have continued on to careers in software engineering, game development, or other areas of the game industry such as publishing.

 

Instructor Insights

In Class Course Components

Lectures

We try to keep lectures short and move on to hands-on work as quickly as possible to reinforce the concepts we want to get across. We prefer to provide new information very shortly before the students need to apply them, instead of expecting students to rely on the memory of what they might have heard weeks ago.

Game development professionals came once a week in the final 8 weeks of class to expose the students to the realities of professional game development, particularly as it is practiced in the entertainment industry at various sized studios (2-5 person up to 200 person studios). Each professional gave a lecture based on one of the many roles practiced in game development (producer, designer, programmer/engineer, tester, researcher, artist, sound designer, writer, composer, publisher) as well as provided critique of student projects. This time was crucial to help students to understand that the project management and soft skills we were asking them to practice were of necessity in the industry no matter what role you filled. It is also important for students to understand the breadth of specialties that are used when making video games professionally.

Discussion

Since this was team-based class, students may only have had the opportunity to meet their entire team face-to-face during class hours. We provided students with class time to thoroughly discuss the status of their projects, both so that they have some amount of co-located time to work, but also so that we can observe the teams in this way to better understand their challenges and their use of process.

Workshop

The first 3 projects had several 2-hour workshops during which the project teams simultaneously work on some aspect of the material at the same time. This usually happens no more than twice per project (each project is 2-3 weeks long). These workshops are to make sure that not only are the students practicing with the basic materials/methods we are teaching, but also so that we can provide in-class guidance about how they are performing. These workshops are often a 15-20 minute lecture, an hour of work, and up to 30 minutes of review and debrief.

Playtesting

Each project had at least one 2 hour in-class test session, usually 2 days after the assignment began on their initial prototypes. For project 4, which lasts 8 weeks, there would be a 30 minute play test session whenever a guest lecturer came in (about once a week) to give students access to professional game designers for feedback and critique.

Presentations

All four projects have 2 group presentations:

  • A short presentation (2 minutes) at the beginning, highlighting the design challenge they are doing (a core game mechanic, possibly information about how they will implement the mechanic)
  • A longer presentation (5 minutes for the first 3 projects, 20 minutes for the final project) that gives a postmortem of the process of making their game. In essence, it covers what went right, what went wrong, what was interesting, and what they will do on future projects based on the lessons they learned.

Student Population and Pedagogical Approach

Since the majority of our students have an EECS background, we understand that they are capable of figuring out on their own most of the programming and computer science concepts they are likely to encounter in this course. We also understand that because they might not have a strong humanities or design background, we need to devote a good amount of class time to help boost their knowledge in these areas. In the future, this course will have a requirement (CMS.301 Introduction to Game Design Methods), alleviating some of this strain.

For many of these students, even the seniors in EECS, their final project will likely be both the largest code base they’ve worked with and the largest team they’ve worked with. It will also definitely be the most complex project, since it will require creation and integration of many art and sound assets as well as code. Because of this, the material is entirely focused on how to manage these kinds of projects well: how to scope, how to estimate, how to think through the problems they will face, and how to be flexible enough to maneuver through and around these problems.

Course History and Future

This course continually evolves and changes year to year as we learn how to refine its structure. It began as a series of game jam challenges, where students formed small teams, voted on the best games, and the teams increased in size with each assignment. The increasing team size remains in place, but it is structured in a way to focus more on the project management and prototyping practice, rather than being a popularity contest for particular game designs (or game designers).

Our next change will be to streamline the team formation aspect of the course. This is in part due to our increasing the cap from 35 to 50 in the next year, as we have a larger classroom to accommodate student interest. We hope to provide more support for team building as well, possibly through use of an online communication tool, to make sure that student teams are able to form based on their available hours. Co-located team work is a tool we want students to use to improve their in-team communication.

We are also structuring the course to be a more natural pre-requisite for other courses in our curriculum (CMS.610 Media Industries and Systems, CMS.615 Games for Social Change, CMS.617 Advanced Game Studio) so that students are able to transfer the project management and teamworking lessons they learn here to the design challenges they will be facing in other courses.

For the past few years, this course has been the main thrust of our game development curriculum. We have devoted a significant amount of time to make sure this course provides fundamentals that will be used throughout our students’ academic and professional careers. At this point, most changes are to move some of the more basic material into our introductory course (CMS.301 Introduction to Game Design Methods), so that we can spend more time in this course working on the project management and team building aspects, and less on game design fundamentals. We are also looking to incorporate more ways to involve multidisciplinary aspects to the course, as it is currently taken by a majority EECS cohort. Bringing artists and designers into the course will be crucial in future years.

 

Curriculum Information

Prerequisites

CMS.608 Game Design or 6.01 Introduction to Electrical Engineering and Computer Science I

Requirements Satisfied

Offered

Every fall semester

The Classroom

  • A photo of a classroom with rows of individual chairs, a table for the instructor, and a chalkboard on the side wall.

    Room 1 of 1

    Seminar

    This course was taught in a room with a capacity of 41, modern tablet armchairs, video projector and sound system, screen, and plenty of board space.

 

Assessment

The students' grades were based on the following activities:

The color used on the preceding chart which represents the percentage of the total grade contributed by preparedness, participation, and a tutorial assignment. 25% Preparedness for class; overall participation in class group exercises and group focus testing, weekly retrospectives and other in class work. Also includes the Game Engine Tutorial Assignment.
The color used on the preceding chart which represents the percentage of the total grade contributed by team project 1. 15% Team Project 1
The color used on the preceding chart which represents the percentage of the total grade contributed by team project 2. 15% Team Project 2
The color used on the preceding chart which represents the percentage of the total grade contributed by team project 3. 15% Team Project 3
The color used on the preceding chart which represents the percentage of the total grade contributed by team project 4. 30% Team Project 4
 

Instructor Insights on Assessment

All of the projects were team-based, so we had students turn in a mix of individually written essays as well as team-based presentations. Both of these assignments were to reflect on their process: what did they do over the course of a project, how did they do it, what problems did they have, how did they solve them (if they were solved), and most importantly what would they do differently in the future. We also had each team turn in a change log, recording all of the changes they went through in the development of their game (basically a diary they worked on throughout), and we checked in on their process by looking at the materials created by the project management methods we taught (because this is scrum, this was product backlogs and sprint task lists). These methods were chosen because, even though the students are practicing the techniques and material taught in class through the creation of their projects, they needed to be spurred to reflect on their learning at multiple points, both to help them understand what they did and to help us understand their understanding of it.

Student Information

On average, 45 students take this course each time it is offered.

Enrollment

40-50 (Cap was recently raised from 35 to 50)

Breakdown by Year

1/2 Seniors, 1/3 Juniors, 1/6 Sophomores.

While freshman are not specifically excluded, it is unlikely that they would have the requisite background. In addition, the course is usually oversubscribed, with priority given to senior students.

Breakdown by Major

Mainly Electrical Engineering and Computer Science majors, a few Comparative Media Studies majors, several from other departments.

Typical Student Background

Students were required to have completed CMS.608 Game Design or 6.01 Introduction to Electrical Engineering and Computer Science I. Many students also brought very different tastes and experiences from having played games throughout their lives, but students did not have to be “gamers” to enroll or excel in the class.

Enrollment Cap

We capped enrollment at the capacity of the room we were able to get for the course. Because it was taught as a lab - 3 hours per session - we needed enough space in the room for student teams to meet and work together.

Ideal Class Size

The ideal size is at least 40 students per section, capping at about 50 max for a single section. In this way, students have the opportunity to work on multiple teams with different students on each, as well as to form teams for the final project that were big enough to fail. We purposefully set teams up for the final project to have communication issues (having 7-8 students on a single team) because part of their challenge is to use the tools and methods we provide to overcome the challenge. At 40 students, this allows 5 large teams to operate for the final project.

 

How Student Time Was Spent

During an average week, students were expected to spend 12 hours on the course, roughly divided as follows:

In Class

6 hours per week

Use of class time varied widely as students moved through the different stages of each project. Main activities, with approximate average time spent, included:

  • Lectures (1-2 hours/week)
  • Discussion (1 hour/week)
  • Workshop (1 hour/week)
  • Playtesting (variable)
  • Presentations (variable)

For more details, see the instructor insights section below.

 

Out of Class

6 hours per week

Students are expected to be doing most of the development on their game projects outside of class, working collaboratively and individually to meet regular deadlines.

 

Semester Breakdown

WEEK M T W Th F
1 No classes throughout MIT. No classes throughout MIT. Lecture session. No session scheduled. No session scheduled.
2 Lecture session; playtesting; assignment due date. No session scheduled. Guest lecture; student presentations. No session scheduled. No session scheduled.
3 Lecture session; assignment due date. No session scheduled. Lecture session; student presentations. No session scheduled. No classes throughout MIT.
4 Lecture session; student presentations; assignment due date. No session scheduled. Lecture session; playtesting; assignment due date. No session scheduled. No session scheduled.
5 Lecture session; student presentations; assignment due date. No session scheduled. Guest lecture; assignment due date. No session scheduled. No session scheduled.
6 Lecture session; student presentations; assignment due date. No session scheduled. Guest lecture; assignment due date. No session scheduled. No session scheduled.
7 No classes throughout MIT. No classes throughout MIT. Lecture session; student presentations; assignment due date. No session scheduled. No session scheduled.
8 Lecture session. No session scheduled. Guest lecture; assignment due date. No session scheduled. No session scheduled.
9 Guest lecture; student presentations; assignment due date. No session scheduled. Guest lecture. No session scheduled. No session scheduled.
10 Lecture session; assignment due date. No session scheduled. Lecture session. No session scheduled. No session scheduled.
11 No classes throughout MIT. No session scheduled. Lecture session; student presentations. No session scheduled. No session scheduled.
12 Guest lecture; assignment due date. No session scheduled. Guest lecture. No session scheduled. No session scheduled.
13 Lecture session. No session scheduled. Guest lecture. No classes throughout MIT. No classes throughout MIT.
14 Lecture session; assignment due date. No session scheduled. Lecture session. No session scheduled. No session scheduled.
15 Lecture session. No session scheduled. Lecture session; student presentations; assignment due date. No classes throughout MIT. No classes throughout MIT.
16 No classes throughout MIT. No classes throughout MIT. No classes throughout MIT. No classes throughout MIT. No classes throughout MIT.
Displays the color and pattern used on the preceding table to indicate dates when classes are not held at MIT. No classes throughout MIT
Displays the color used on the preceding table to indicate dates when lecture sessions are held. Lecture session
Displays the color used on the preceding table to indicate dates when student presentations are held. Student presentations
Displays the symbol used on the preceding table to indicate dates when assignments are due. Assignment due date
Displays the color used on the preceding table to indicate dates when no class session is scheduled. No class session scheduled
Displays the color used on the preceding table to indicate dates when guest lectures are held. Guest lecture
Displays the color used on the preceding table to indicate dates when playtesting sessions are held. Playtesting
 

Course Team Roles

Philip Tan

Taught class sessions having to do with game design and prototyping.

Sara Verrilli

Taught sessions devoted to project management and user testing, lead architect of the four project assignments.

Rik Eberhardt

Taught sessions on project management and team building/leadership, arranged playtesting sessions and lectures with guests from the MIT Game Lab’s network of professional game developers.