EECS 494 – Game Design and Implementation – Syllabus

Welcome to EECS 494 – Game Design and Implementation, Fall 2016. Please read through this syllabus in its entirety. If any part of it is unclear to you or if you're unsure as to whether it is appropriate for you to be in this course, it is your responsibility to discuss it with the instructor as soon as possible.

  1. Requirements and Recommendations

    1. Broadly Speaking

      1. This class is most appropriate for computer science seniors who are planning on graduating at the end of either this semester or the next.

      2. This class should satisfy a Major Design Experience (MDE) requirement when paired with both EECS 496 – Major Design and Professionalism and TCHNCLCM 497 – Advanced Technical Communication for Computer Science, but if you're unsure please check with an academic advisor.

    2. Requirements

      1. The only formal prerequisite for this class is that you must have passed EECS 281 – Data Structures and Algorithms with a C or better (or have graduate standing).

      2. Introduction to Game Design, Prototyping, and Development (IGDPD) by Jeremy Gibson Bond is the required text for the course. It should be in stock at the Pierpont Commons Bookstore, but ordering from Amazon or your bookstore of choice is fine.

        Jeremy described this as the book he "always wanted to have when teaching this class." The book is currently one of the highest-rated Unity books on Amazon with an average of 4.7/5 stars and it 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 website for the book,

      3. You must have a notebook computer capable of running a demo of your game and allowing you to fill in online forms.

    3. Recommendations

      1. We additionally expect you to have significant knowledge regarding:

        1. Software design and implementation
        2. The ability to read and comprehend online documentation and tutorials
        3. Debugging expertise
        4. Version control
        5. The ability to work and play well with others

        Broader knowledge regarding audio, computer graphics, networking, and real time simulation may come in handy, but are not required.

      2. Please do not take this class at the same time as EECS 381 – Advanced and Object Oriented Programming, EECS 482 – Introduction to Operating Systems or any other courses requiring significant time working on programming projects. (The EECS Undergraduate Workload Survey Results provide an excellent guide.) This class can and will eat all of your time. Your work will suffer as a result.

      3. Please drop this class if you are a graduate student unless you have discussed taking it both with your research advisor and with the instructor. It's a lot of work and will not play nice with your research.

      4. Additional Readings

        1. C# in Depth, 3rd Edition by Jon Skeet – I keep running into posts from his book online and they're great. I recommend reading them where I link to them and buying his book if you really care about learning C#.

        2. 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 patterns in the realm of game development. (Recommended by Jeremy Gibson Bond)
        3. The Art of Game Design by Jesse Schell – This is a fantastic book by Jeremy's former game design professor at CMU. (Recommended by Jeremy Gibson Bond)
        4. Game Design Workshop by Tracy Fullerton & Chris Swain – This is the book that Jeremy Gibson Bond taught from most often, and it was based off of the Game Design Workshop class that he 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. (Recommended by Jeremy Gibson Bond)
        5. Characteristics of Games by Elias, Garfield, and Gutschera (Recommended by John Laird)
        6. Fundamentals of Game Design by Ernest Adams (Recommended by John Laird)
        7. 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. (Recommended by Jeremy Gibson Bond)
  2. Goals

    1. Your Goals

      Some core goals you should have include:

      1. To learn about games, game design, and game development

      2. To get experience with agile development methodology, iterative development and prototyping, burndown charts, and scrum

      3. To further develop project and team management skills as well as mastery of version control

      You will additionally have to learn and work with C#, Unity, supporting tools, image manipulation software, modeling software, version control, and so on.

      If none of this sounds interesting to you, please reconsider your decision to be here. This course will be very difficult if you are not self-motivated.

    2. My Goals

      I want to give you as much constructive criticism as possible, and I want to help you grow as a collaborator and game developer. Teaching you to program to engineer software is mostly outside the scope of this course, with some exceptions specifically related to game development.

      I want you to be capable of critically analyzing video games and to make great video games of your own by the end of this course. At times I will seem exceptionally critical of your game design decisions and your games as a whole, but it is intended to make you think about how to do things better and to help you improve as game developers.

      You can't become a game developer without a thick skin, and you can't become a great game developer without listening. Don't be hurt by negative comments but rather take them for what they are and try to learn as much as possible from them.

      All that being said, I expect you to take more care to be constructive and open to the possibility that the advice you're giving is incorrect when giving feedback to one another. (i.e. I'm allowed to be more blunt.) Be extra polite and courteous to your peers.

    3. In-Class Scrums and 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:

      1. A scrum is a short 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 tow-truck 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.
      2. 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. We will be checking this.

      3. 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.

      4. Every project team will take part in every scrum during the final project.

    4. 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.

  3. Policies

    1. Attendance

      1. All students are expected to attend every class on time and to stay for the duration. If you must miss a class due to an extenuating circumstance, you must email the staff at prior to your absence. If you are on a team with someone, keep them as well informed.

      2. All readings assigned from Introduction to Game Design, Prototyping, and Development or any other source must be completed before class on the day that they are listed in the schedule.

    2. Class Resources

      1. Canvas must be monitored for announcements and used to turn in all assignments. Due dates and other details listed there are authoritative. You will also find lecture recordings (for most but not all lectures) there.

      2. Piazza must be monitored for additional announcements and for all collaboration other than that which is outlined as acceptable for specific group assignments.

      3. is the email address to use to contact all instructors in the event that you must discuss a private matter with us remotely.

      4. You are encouraged to attend office hours and to ask questions in class (and just after) when needed. Online assistance is sometimes not the most efficient approach for any of us.

      5. Don't forget about Introduction to Game Design, Prototyping, and Development or its website,

    3. Collaboration and Honor Code

      We encourage you to discuss general concepts and techniques with other class members both in person and through Piazza, but specifics of assigned tutorials and projects must be worked on individually or in groups as outlined in the assignment descriptions. Sharing of code is strictly 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, do not hesitate to contact us. One of the best ways to be sure that your collaboration is okay is to ask the question publicly on Piazza. If you see a question on Piazza that you're unsure that it's okay for you to answer, however, please either contact us or wait to see our response before proceeding.

      It is permissible to use software and materials (e.g bitmaps, models, code libraries) available from other sources only if certain conditions are met:

      1. You must check with us beforehand.
      2. You must explicitly credit each and every asset and game function that you did not create yourselves to verifiable sources.
      3. Assets must be freely available to you under a license that would permit you to use them in your game even if you were not making it for educational purposes. And you must provide documentation of this licensing.
      4. Assets must not have been created as part of this course in a previous semester or by another student in the course this semester.

      Failure to meet these conditions will result in arbitrarily high penalties on your assignments and could be considered honor code violations, so ask first.

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

    4. Project Deliverables and Late Policy

      1. Assignments must be turned in following a standard submission procedure by the time listed on Canvas. Any other due date listings such as those you might find on Google Calendar or in assignment descriptions are not authoritative. Please inquire about any discrepancies, however.

      2. Assignments turned in up to 6 hours past the deadline will be assessed a penalty of 2.5%. Additional 2.5% penalties will be assessed for every additional 6 hour window that passes up until the point that the cutoff window listed on Canvas has passed. Grading past that point is unlikely to happen.

      3. Under no circumstances will these penalties be waived without extenuating circumstances on the order of extended illness with a doctor's note, death in the immediate family with a death certificate, or severe technical malfunction on our end at moment the assignment is due.

    5. Grading

      1. This is a difficult class that requires you to put in a great deal of time. You are graded on:

        1. Tutorials and projects
        2. Writing assignments and analyses that are tied to the projects
        3. Playtests that you run for your fellow students
        4. Participation in the form in class and online contributions and feedback to your peers.
      2. Outline of assignments:

        Item Grade Description
        Tutorial 1 4% Chapter 28 or 29 from the book (individual)
        Tutorial 2 6% Chapter 30 tutorial from the book (individual)
        Project 1 15% Class Game Project (chosen pair)
        Project 2 15% Game Prototype A (individual)
        Project 3 40% Final Game Project (chosen group of 4)
        Formal Playtests 10% Formal Playtesting of Other Team's Projects
        Participation 10% Participation in class and on Piazza as well as Game Feedback (individual)
  4. Instructor Autobiographies

    1. Mitchell Keith Bloch

      I'm the instructor for the course. I'm also working on my PhD in artificial intelligence.

      I attended Camp CAEN the summers of 2000-2002 and it was there that I made my first game, a centipede clone, in 2000. It was in the summer of 2002 that I first became aware of Wolverine Soft thanks to my class's instructor, Matt Gilgenbach. I first heard about EECS 494 during an orientation presentation during the summer of 2004.

      I joined Wolverine Soft in Fall 2004 and I became more involved near the end of that academic year. I became their webmaster starting in the summer of 2005 and I maintained that position through Winter 2007 before transitioning to the role of president for one year. I developed the first user-editable version of the website using PHP and MySQL and I followed up with one major redesign of the site.

      I wrote a non-hardware-accelerated C++ framework for putting together a video game based on what I'd read in Focus on SDL and I used it for my first 48 Hour Game Development Contest with Wolverine Soft in Winter 2006. After taking EECS 381 in my second year of undergrad, I began developing a more serious game engine and frontend to both Direct3D and OpenGL. I released the first version of zenilib not long after that and I continued to develop it for many years.

      I began giving tutorials on zenilib to Wolverine Soft Fall 2006 and I additionally taught high-school-aged kids to make video games using zenilib in the Advanced C++ class at Camp CAEN for two weeks each summer, 2007-2010. Starting in Fall 2008, EECS 494 adopted zenilib as well and I GSI'd using zenilib Fall 2008-2013. EECS 494 shifted to Unity for Winter 2014 and I subsequently rejoined the class and assisted in the role of GSI two more times, Fall 2014 and Winter 2015.

      I started playing video games as a young child and I've never lost interest. However, I have other interests worth noting. I've started dancing Argentine tango in November 2010 and I taught a class series with the Michigan Argentine Tango Club for the first time July-August 2016. I've also been taking private singing lessons since late August 2015.

    2. Austin Yarger

      Austin Yarger is a graduate student studying Computer Engineering at the University of Michigan. Ever since Crash Bandicoot hit the Playstation in 1996, he's been enamored with technology's potential to surprise and delight. A long-time hobbyist game developer (, Austin got his taste of AAA development the summer of 2014, with an internship at Maxis (Electronic Arts) where he contributed to 2014's top selling computer game, The Sims 4. He served as President of Wolverine Soft ( during his four years of undergrad.

      Austin also provided a humorous bio:

      "Take 3 eggs, 2 summer stints at EA, 4-years of a Wolverine Soft (game dev club) presidency, mix in a fine linen bowl. Season with Nintendo Fandom, place into dutch oven at 500 degrees Fahrenheit. Forget about it for about a day. Remove from Oven.

      Your Austin is now prepared. Chill and Serve."

    3. Kurt Waldowski

      I started developing video games at the age of 12 using RPG Maker and GameMaker Studio, which led me to major in Computer Science at the University of Michigan. During my junior year of college, I started a small game studio doing freelance mobile game development for various clients around the world, and released titles for iOS and Android including DinoMash (, Courts Digital Dash, Tracy's Black Jack and Red Ball Blast. After a year and a half away from the University, I earned enough from my endeavours to return, finish my degree, and IA this class. Woohoo! If you ever see someone doing Parkour around campus or kicking a hacky sack, it very well may be me so come up and say hello!

  5. Other Resources

    1. 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 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, or for alcohol or drug concerns, see

      For a listing of other mental health resources available on and off campus, visit: