This Course at MIT pages provide context for how the course materials published on OCW were used at MIT. They are part of the OCW Educator initiative, which seeks to enhance the value of OCW for educators.
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.
This course was about learning the proper processes and procedures for working as a team on a complex, multifunctional 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.
Students have continued on to careers in software engineering, game development, or other areas of the game industry such as publishing.
Every fall semester
The students' grades were based on the following activities:
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.
40-50 (Cap was recently raised from 35 to 50)
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.
Mainly Electrical Engineering and Computer Science majors, a few Comparative Media Studies majors, several from other departments.
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.
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.
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.
During an average week, students were expected to spend 12 hours on the course, roughly divided as follows:
Use of class time varied widely as students moved through the different stages of each project. Main activities, with approximate average time spent, included:
For more details, see the instructor insights section below.
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.
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.
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.
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.
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.
All four projects have 2 group presentations:
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.
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.
Taught class sessions having to do with game design and prototyping.
Taught sessions devoted to project management and user testing, lead architect of the four project assignments.
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.