• Blair MacIntyre, blair (at) cc (dot) gatech (dot) edu
    Office hours:  11-12 W and 1-2 Thursday (TSRB 231)
  • Teaching assistants
    • David Chi, david.chi (at) gatech (dot) edu
    • Anshul Bhatnagar, anshul.bhatnagar (at) gatech (dot) edu
  • TA Office hours
    • MW: 2:00-3:00 @ CoC Commons, and also by appointment.
    • T: 10:30-11:30, W: 10-11, 2nd floor of Klaus overlooking foyer.

General Infromation


You will be required to bring a laptop to class, and having Unity3D 4.x installed on it.  We will do in-class prototyping and programming exercises.  Please ensure you have a laptop that will run Unity3D effectively.

When we are not using them for in-class work, I will ask students to close them.  While I am inclined to let people do what they want with their time (and grade their results), I have received many complaints from students over the past few years about how distracting it is to have students browsing the web/facebook/twitter, watching videos, and playing games in class.  And here’s a nice article about a study documenting the negative impact on performance of students who are  seated near folks using laptops (even if they aren’t).

Please be courteous to your fellow students.   To put this another way:  I view using social media and unrelated web browsing as equivalent to talking on a phone in class.  If you are doing it and bothering me or others around you, I may ask you to leave class for the day.


This class is a project based class on Video Game Design and Architecture.  At the end of the semester, you will work in groups of 3 students to design, prototype and test a 3D video game using the Unity3D game engine.  Before then, you will learn about game architecture and some elements of game design, but particularly how to build responsive, interactive games that feel good.  You will build a number of small game prototypes before you begin to develop your game, to learn how to build interactive game mechanics and controls.

Every student in the class will build a sequence of game interaction/mechanic prototypes by themselves, and will be expected to contribute significantly to their team’s game.  This is not a “process” class, where each member takes on a well-defined roll, with some programming, some designing and some managing.  Nor is this a “design” class, where we focus on the overall design process for games.  Rather, this is a game architecture and programming class, where each member of the team is expected to take on many roles to ensure the game is completed and working before the due date.

While this is not primarily a game design class, we will discuss the elements of games, and some ideas on game design, in support of you building games.  The main goal of this class is to understand how games are built (game architecture) and how the elements of a game engine are leveraged to build interactive experiences that are a pleasure to play.  While there are many parts to a game, from the story to the content to the levels, the part we will focus on in this class is how to build the second-by-second interactive experience such that it is fun and enjoyable to play.  In many ways, this is the core element of games that distinguishes them from other digital systems.

Beyond learning how to build engaging and fun interactions, building prototypes to test such interactions is useful because a major part of designing a game is testing and refining  the prototypes of the various parts of the game, especially the game mechanics, controls and interactive elements.  Since games are as much about the feel of the experience as they are about the technical implementation, testing and refining how the game feels and “plays” is critically important.  Therefore, a goal of this class is to give you experience developing such prototypes for a game you are building.


The grade for the class will be computed as follows:

  • Class participation: 5% (measured by participation, attendance, in class exercises, etc)
  • Non-programming Assignments: 10% (2.5% each)
  • Individual Prototypes + Critiques: 45% (10% each for P1-P3, 15% for P4)
  • Initial Group Game Project Pitch and Design Document: 10%
  • Alpha Milestone: 10%
  • Playable Complete Game Milestone (for final playtesting): 10%
  • Final Presentation, Video and Materials: 10%

Final grades are computed as follow:  <50 (F), 50-65 (D), 65-75 (C), 75-85 (B), 85-100 (A)

Late Policy

Late submission will have 25% taken off the grade immediately, and an additional 25% taken off for each additional day.  A day is 24 hours from the specific time the assignment is due (e.g., if something is due at 6am Monday, and it turned in at 6:01am Monday, it is 25% off;  if it’s turned in at 5:59am Tuesday, it’s 25% off but will be 50% off at 6:00am Tuesday).


The major activity of the class is centered around the individual prototypes and the group project (below), but there will be some individual assignments and in-class activities worth 20% of your grade.

We will do a number of in-class activities over the semester.  I will

Individual Web Pages

Each student will create an account on this blog, using an alias of their choosing.  DO NOT use a personally identifiable account name, but something that is not identifiable as you (if you want others to know about your work, you can re-publish the content on your own website).   We will use the t-square wiki to maintain a list of the aliases, and you will use this blog to publish your prototypes for testing.

The Project Web Page

Each team will have an identifying category for their group, as a sub-category of “Groups”.  For each deliverable, the group will do a blog post, categorized with their group category.  The “description” of the group should provide an appropriate one sentence summary of their group.  The first post will be a summary of the project, including a list of group members, the game design idea, etc.  Additional posts will be added for all the game turn-ins, the final game, all game prototypes, and the final video.  The content should be neatly and concisely laid out on each of these posts, such that the final page containing those posts is polished.  All game projects are expected to be targeted to Unity’s web plugin (with the unity3d file stored in t-square’s resources), so all of the game milestones will be playable on your post’s pages, and available to the your classmates and anyone on the internet who stumbles on your page.


The final project will be done in groups of 3.  Not 4, not 2.  But 3.  Teams will be formed after fall break, and an initial game pitch will be done by each team. Each team will then work on their game over the last month of the semester.  There will be two major milestones (the Alpha build, and a final complete build, both of which will be play-tested in class.)

The game project is best thought of as “30 to 60 seconds of pure fun that demonstrates the core fun of your game idea.”  The emphasis is on demonstrating the fun.  The game should play well for that brief period, and it should be clear to the player where this game would go if it were to become real.  Polished art is not necessary, but the prototype should be complete and clean enough to not interfere with the experience; opting for a clean geometric world rather than “cobbled together mismatched models” is a good idea.  While you should have minimal splash screens, menus, instructions and environmental polish, you will NOT get additional credit for things unrelated to the fun of your core idea: no complex levels or level editors, no generalized internal structures, no super-cool animated 3D characters, etc.  But the critical elements of game feel (as described in the text and in class) are important, insofar as they contribute to a smooth and compelling game experience.

A summary of the elements of the project are as follows (additional details will be provided in class and on separate pages):

  • The Pitch will be short (3 mins) and have follow a fixed format (we will provide more detail separately).  The focus should be on the “core idea” of the game.
  • Alpha.  The Alpha should be an initial playable demo.  It should demonstrate the central part of your game, and allow you to get an idea (and feedback) about whether you are going down a good path with your game.  You will bring these to class, and we will use two class periods to allow students to play each others games and give their feedback.
  • Final Playtesting Build.  You will be expected to have your game 99% complete by the time we playtest in class.  After the playtesting, you may continue to tweak the game based on what you learned (e.g., adjust balance, update some content or technical bugs, etc) but this should be purely refinement.  Adding features after the playtesting build, rather than adjusting features that were there, will NOT count toward your final grade.
  • Final Presentation.  You will present your game, including showing a short video (less than two minutes) documenting your game.  You should also present what you learned, and what you may have changed since the final playtest;  what did your game do and not do;  what you would do differently.