eecs.prototools.net | eecs 494 | syllabus

EECS 494 – Winter 2016 – Syllabus

Computer Game Design — TTh 11:30a-1:30p in 2150 DOW or TTh 4:00-6:00p in 1500 EECS

Class Meetings:

Sec. 001: TTh 4:00-6:00p
          2150 DOW

Sec. 002: TTh 11:30a-1:30p
          1500 EECS

Instructors:

494@eecs.prototools.net

Jeremy Bond - Professor
Office Hours: M 1-3p
Office: 2632 BBB

Austin Yarger - GSI
Office Hours: F 2:30-4:30p
Office: 1695 BBB

Ryan Wawrzaszek - GSI
Office Hours: W 3-5p
Office: 1637 BBB

Matt Stone - IA
Office Hours: TTh 2-3p
Office: 1695 BBB

Course Overview & Welcome to EECS 494

Let's get this out of the way first: this class is a lot of work. Ask around. However, despite the heavy work load (or, probably because of it), many students have also told me that it's one of the most useful EECS courses that they have taken. Every semester, several students tell me that it's their favorite course they've ever taken at U-M, but every one of those students has been someone who has put in the work required to get good results, make a good game, and get a good grade. So, as you approach this class, it's time to step up and work hard. You'll be glad you did.

My four core goals for this class are to:

  • Teach you about games, game design, and game development
  • Give you hands-on experience creating games & game prototypes through multiple design iterations
  • Teach you a new language, C#, which is similar in syntax to C++ but similar in capabilities to Java
  • Help you manage your own projects both during the class and in the future using Agile development methodologies like burndown charts and scrum

I have been teaching game development and design at the university level for over a decade now, and I've been teaching EECS 494 since Fall 2013. Every semester, this class continues to improve and adapt. This semester will be somewhat different from the last because I see every semester as an iteration, a chance to improve the class, to increase student learning, and to help you to create better final game projects.

This course is an experiment in pushing to see how far you can go in one semester. Throughout the semester, I will be pushing myself, and I expect the same from each of you. Because we have very, very few games classes here at U-M, it is my responsibility is to teach you as much theory and implementation as possible in a single class. As advanced undergraduate students in the fantastic U-M Electrical Engineering and Computer Science program, you already know how to program; so teaching you how to program is not my job. It is my job to teach you how to approach both design and technical problems using a repeatable strategy that will make your games and other projects better and will help you to implement them effectively. It is also my job to help you understand the nuances of game design and some of the history that has led to where the industry is now.

Prerequisites

In addition to EECS 281, we expect that you have significant programming experience and knowledge of programming language concepts. We also assume that students can learn new programming concepts and systems on their own.

 

Required Text

Introduction to Game Design, Prototyping, and Development by Jeremy Gibson

This is the book that I've always wanted to have when teaching this class, and after two years of writing, it was finally released in July, 2014. This is just the 1st edition, so please let me know of any issues, errors, etc. that you encounter so that I can make it better in the future. The book is currently one of the highest-rated Unity books on Amazon.com with an average of 4.7/5 stars and has frequently been the #1 best-selling game design book on Amazon. The book was originally written for Unity 4.3, but any changes required are covered on the book's web page http://book.prototools.net .

All readings from IGDPD must be completed before class on the day that they are listed in the schedule. You may also have other readings assigned that you also must read before class.

Recommended Readings

Game Programming Patterns by Robert Nystrom – This is a relatively new book that talks about how to implement several of the Gang of Four's programming patters in the realm of game development.
The Art of Game Design by Jesse Schell – This is a fantastic book by my former game design professor at CMU.
Game Design Workshop by Tracy Fullerton & Chris Swain – This is the book that I have taught from most often, and it was based off of the Game Design Workshop class that I eventually taught at USC. Unlike almost all other books on game design, this focuses on giving you real, applicable strategies for implementing games start to finish.
Characteristics of Games by Elias, Garfield, and Gutschera – Recommended by Professor Laird
Fundamentals of Game Design by Ernest Adams – Recommended by Professor Laird
Rules of Play: Game Design Fundamentals by Katie Salen & Eric Zimmerman – This book is a decent read once you already have a thorough understanding of game design. There is some good information but it is overly repetitive.

Course Home Page  –  http://eecs.prototools.net/494/

On the home page, you will find the weekly course schedule, assignments, and this syllabus. Assignment turn-in will be handled via CTools or Canvas, and I expect a healthy discussion on the Piazza forum as well.

Attendance

All students are expected to attend all scheduled classes. If you anticipate an absence, you must email the staff at 494@eecs.prototools.net before the class that you will miss. If you are on a team with someone, they must know where you are if you are absent.

Collaboration and Honor Code

You are encouraged to discuss ideas and techniques broadly with other class members, but not the specifics of assigned problems except as part of group projects. Sharing of code is expressly prohibited. We expect adherence to the Engineering Honor Code in all assignments. Violation of this policy is grounds for us to initiate an action that would be filed with the Dean's office and would come before the College of Engineering's Honor Council. If you have any questions about this policy, PLEASE do not hesitate to contact me. One of the best ways to be sure that your collaboration is okay is to ask the question publicly on the class Piazza. If you feel comfortable asking and answering the question publicly, then it's probably fine.

It is permissible to use software and materials (e.g bitmaps, models, code libraries) available from other sources as long as:

– You check with us before doing it.
– You acknowledge explicitly which aspects of your assignment were taken from other sources and what those sources are.
– The materials are freely and legally available.
– The material was not created by a student at the University of Michigan as part of this course this year or in prior years.

All write-ups, reviews, documentation, and other written material must be original and may not be derived from other sources.

Student Mental Health and Wellbeing

University of Michigan is committed to advancing the mental health and wellbeing of its students. If you or someone you know is feeling overwhelmed, depressed, and/or in need of support, services are available. For help, contact Counseling and Psychological Services (CAPS) at (734) 764-8312 and https://caps.umich.edu/ during and after hours, on weekends and holidays, or through its counselors physically located in schools on both North and Central Campus. You may also consult University Health Service (UHS) at (734) 764-8320 and https://www.uhs.umich.edu/mentalhealthsvcs, or for alcohol or drug concerns, see www.uhs.umich.edu/aodresources.

For a listing of other mental health resources available on and off campus, visit: http://umich.edu/~mhealth/.

(On a more personal note, as an undergraduate advisor, I've seen many students who have had to deal with something difficult during the semester. CAPS help is free and completely confidential, and talking to them early can make a significant difference in how much adversity that you may experience will affect your semester. Please talk to them, even if you don't think you really need to. They can help.)

Grading

Your final grade for this class will be based on the grades you achieve on class assignments as well as a participation grade that will be given based on: your contributions to discussions both in class and on the forums, the number and quality of game evaluations that you submit for your peers' games, your participation in in-class scrums, and other potential factors. Each assignment will be composed of several subassignments. If you have a problem with the grading on a particular assignment, write a brief (one-paragraph) description of the problem, and hand it in with the assignment for a regrade. It is usually difficult to get an A in this class, but if you do the work, you have an extremely good chance of passing.

Element % Grade Description

Tutorial 1

4% Chapter 28 or 29 tutorial from the book (individual)

Tutorial 2

6% Chapter 30 tutorial from the book (individual)

GameBase

10% Game Analyses on the GameBase Wiki (individual)

Project 1

15% Classic Game Project (pairs)
Project 2 10% Game Prototype A (assigned group)
Project 3 10% Game Prototype B (assigned group)
Project 4 25% Final Game Project (group)
Formal Playtests 10% Formal Playtesting of Other Team's Projects (individual)
Participation+ 10% Participation in forums and game feedback
Also includes additional small assignments (individual)

Announcements

Announcements regarding homework assignments and other course matters will be made in class or via Piazza announcements.

Lecture Recording

Most class lectures will be recorded and available via the course Canvas page.

Late Policy

To be considered on time, assignments must be turned in at the specified time before class on the due date. No exceptions. Late assignments will be assessed a penalty of 2.5% for each 6 hours that it is late (i.e., 10% or "one letter grade" per day). We will not grant extensions except for extended sicknesses.

Tuesdays vs. Thursdays

Thursdays will be taught as a single class with everyone in the same room, while some Tuesdays, we will split the class into smaller rooms and we will focus on giving each of you as much individual interaction and feedback as possible. Basically, we're helping make this big class feel a lot more like a small class. During the final project, every group will present their work and get feedback in class every Tuesday. This might make you nervous; it will make your game better.

You will each be assigned to a specific room for Tuesdays, and the GSI, IA, and Professor will rotate between rooms each time so that you can each benefit from all of our expertise.

Formal Playtesting

In addition to the informal in-class playtests we will run on Tuesdays, you will also be responsible for conducting formal playtests this semester. In a formal playtest, you will be responsible for writing a playtest script and form that will be used by someone who is not on your team to run playtests of your game. In the final formal playtest, you will be showing your games to the general public somewhere on campus (outside of class). The formal playtests that you run for another team's game are worth 10% of your grade.

Internet Access

I don't expect this to be an issue in a computer science class, but you will need to have the ability to access the internet to submit your reviews at all in-class playtests. Be sure that you bring some sort of internet-enabled device to class with you at least every Tuesday.

In-Class Scrums & Project Burndown Charts

It is very important to me that you are making consistent progress throughout all of the projects for this class. To ensure this, there are many days that we will be doing in-class scrum meetings for your projects. Scrum meetings are part of the Agile development methodology, and they are becoming a ubiquitous part of game development, particularly for small teams and preproduction teams. Agile development will be discussed at length in class, but there are a few things you need to know about our scrums beforehand:

– A scrum is a 15-minute stand-up meeting where each person or team makes four statements:

  1. Tell us the logline for your game (e.g. "Space Farmer is a cross of M.U.L.E., Harvest Moon, and Lost in Blue where you must find seeds and grow exotic foods to survive on an abandoned moon while trying to find a way to contact a towtruck to come get you off this rock.").
  2. Since the last scrum, I accomplished X.
  3. Before the next scrum, I will accomplish Y.
  4. In order to do so, I will need help with Z.

Every single student must be ready for every scrum. This means you must have updated your burndown chart before class on the day of the scrum. Even if you are not chosen to take part in the scrum, your burndown chart must have been updated for the day of the scrum. The staff will be checking this.
– Students will be chosen at random to take part in each scrum. This will be handled fairly, and each student's opportunity to participate in the scrum will be recorded. Whether or not you are ready to scrum will be reflected in your grade.
– Every project team will take part in every scrum during the final project.

Conclusion

Thank you for participating in this class with me. I have had many fantastic students in my years as a professor, and I am excited to be working with the calibre of students here at U-M.

This moment, right now, is the most exciting time that I have ever seen in the game industry. The indie dev scene and serious, experiential games have come to maturity in just the last few years, and I feel that we are finally seeing an expansion of both designers' and players' understandings of what a game can be. At this moment, it is easier for a small team to make a game than it has ever been at any time in the past, and new platforms and distribution possibilities are making it possible for even a single individual developer to get her game seen by millions of people.

So, forget about making money; forget about AAA games; forget about the latest fad in game monetization. Think about an experience that you want to craft for someone; think about how you want to make your players feel. Game development is about creating an experience; inscribing that experience into bits of code, art, and sound; and then giving it to someone else to turn into an experience through play. That is the power and the art of game design.

This class is going to take a lot of work, and I'm going to expect a lot from you, but through your dedication, you will create games.

 

Instructor Bio

 

Jeremy Gibson Bond is an independent game designer/developer and a Lecturer in the School of Engineering at U-M. From 2009-2013, he was an Assistant Professor teaching game design for the Interactive Media and Games Division of the University of Southern California's School of Cinematic Arts, which was named the #1 game design school in North America throughout his tenure there. Jeremy serves IndieCade as the Chair for Education and Advancement where he is responsible for the IndieXchange and GameU tracks. He earned a BS in Radio, Television, and Film from the University of Texas in Austin in 1999 and an MET from Carnegie Mellon University's Entertainment Technology Center in 2007. Jeremy has worked as a programmer and prototyper for companies such as Human Code and frog design; has taught classes for Great Northern Way Campus (in Vancouver, BC), Texas State University San Marcos, The Art Institute of Pittsburgh, Austin Community College, and The University of Texas at Austin; and has worked for Walt Disney Imagineering, Maxis, and EA/Pogo.com among others. His grad school team created the game Skyrates, which won the Silver Gleemax Award at the 2008 Independent Games Festival, and he has spoken at the Game Developers Conference nine times since 2009. Jeremy also apparently has the distinction of being the first person to ever teach game design in Costa Rica.