Due at varying times IAT 410 - Advanced Game Design Fall 2006

Group Project: Video Game Design and Programming


Quick access to the sections of this document:

Project Overview

This term you will undertake a group project (4 people) to design and build a prototype game.
    Each project group will be graded as a team. That is, each person receives the same grade if each person contributes equally. At the end of the semester, I will ask each student how much each team member contributed, including themselves. Lack of participation will result in a lower grade. Great teams have great contributors, each contributing equally. Within the team, you must negotiate on how much and what each person will contribute. Think carefully about your team members: Where do people live and what hours do they work? Where will you meet? What skills do the different individuals bring to the group (computing, programming, design, evaluation, statistics, etc.)? I would strongly encourage you to form a heterogeneous team full of individuals with varying types of skills.

Project Reports

Each part of the project will include a deliverable report. This report will be handed in on paper. Each team should also create a "home" page which includes: 1) a brief (paragraph) description of the game; 2) the team members; 3) Links to auxiliary material for project parts 1-4 (no report is needed for part 0), 4) Demo executables.. 

The format of the reports for the individual parts is up to you, but it should be professionally prepared, expressive, grammatically sound, illustrative of your efforts and process, and easy to understand. A good design effort can easily be hampered by a poor communication of what was done. We will help you get space for your pages and get this all set up.

Part 0 - Group + Topic

Due September 11
(1 week from start, 12 weeks until end of term)

This first part of the project is relatively simple. You must list the members of your team and identify the genre of game or a one-line game synopsis that you will be working on. You should also identify one person who will be the owner of any project web pages you may wish to have (who will own the files).

Part 1 - Game Proposal + Design Sketch

Due September 18  
(2 weeks from start, 11 weeks until end of term)

Advice on how to make a good game:

  1. Think Small

    Most of the games you buy in the store involve six to twelve months of work by twenty to one hundred trained professionals. Those trained professionals include full-time artists, full-time sound designers and hordes of programmers. People with years of experience in those arts alone. And many game titles build off of a body of code developed by the company for previous titles or related merchandising--they're not starting from scratch. You need to design a very small project.

  2. Do One Thing Well

    To do well in this course, you need to do one thing well. Your game needs to really stand out in one way (but NOT all ways). Doing one aspect of it well will get you a better grade than doing a mediocre job on a lot of things. If you're doing an Unreal game, maybe you could do something neat with a twist on physics. If you do a text adventure, make it witty, well-written and with clever puzzles. A few extremely well done puzzles are better than an entire involved game with mediocre quality throughout. Do NOT do lots of levels for your game. All you need is one, small well-done level. Your game might excel in the gorgeous graphics, the witty sound effects, the clever puzzles, the well-tuned user interface. Make it really stand out in one way.

  3. Understand the Affordances of Your Chosen Tools

    The tools that are available for game development have different strengths and weaknesses. Use your chosen tool for what it's best for. Don't fight against it. If you want to do 3D, you might be better off using a higher-level package like UnReal (especially if you don't already know OpenGL or DirectX). You give up a certain amount of creative control when you decide to use UnReal--there are things it does well, and things it does badly. Design your game so that you can use the tool for what it's best for.

  4. Plan in Layers

    "The best laid plans of mice and men...."
    You can't accurately anticipate how long each step in your project is going to take. Consequently, you need to make a detailed development schedule that is layered. I suggest this structure:

    1. Functional minimum: minimal items to make something that you might call a game. You'd be embarassed if you only got this far, but at least it'd be something.
      I expect to see this functional minimum working by October 23, 2006.
    2. Your low target: Your target for what you want to get done--the least possible to feel sort-of OK about the result.
    3. Your desirable target: This is what you're aiming for, if things go reasonably well.
    4. Your high target: It might be possible to get this much done, if all goes extremely well
    5. Your extras: Stuff that you know you can't get done this semester, but you might add later if you decide your game is cool enough to keep working on after the class is over, just for fun.

    Structure your development so that you complete each layer before going on to the next. Plan exactly what is entailed in each layer, and which team member is going to do each component.

  5. Sit Properly

    Now you think I'm joking, eh? I'm not. If you happen to put in marathon sessions working on your games project, think hard about what you're doing to your hands and back. Take frequent breaks. Sit correctly. You will never get that dream game job if you have no hands left. Please read the Typing Injuries FAQ.

  6. Get plenty of Fiber

    Ok, I'm only half joking.


Due on September 18th: Game Proposal and In-Class Presentation

Components of your game proposal:

  1. Description of Your Game: Describe the game in detail: approximately one to two pages text plus three pages of mocked-up screenshots and/or sketches. Pencil sketches are fine. I'm not looking for beautiful art at this point.

  2. Layered Development Schedule: Break your project down into the layers described above and give us a schedule for when you expect to complete each layer. Remember to include which team member will be responsible for each part.

  3. Assessment: Tell us what the main strength of the game will be. What part is going to be the most cool? Who might want to play this game? What do they do in the game? What virtual world should the system simulate? Basically, you are setting up a worldview for your subsequent design. What criteria should be used to judge if your design is a success or not?

Components of your in-class presentation:

Please come to class on this day prepared to give a seven-minute presentation of your game plan. In your talk, you must:

  1. Describe your game.
  2. Argue for what the main strength of your game will be.
  3. State what primary development environment you will use, and why you have chosen it.
  4. Show your development schedule, and make a compelling case that you are not trying to do too much.
  5. Speak for no more than precisely seven minutes (do a practice talk to check your timing--you will be cut off when your time is up).
  6. Use overheads in the style demonstrated in class.

Presentations will continue into the next class, and attendance is mandatory unless you speak to the instructor in advance and have a legitimate excuse.

Please make two extra copies of your proposal document to give to two other groups for them to perform a design critique. Your group will also get two design documents to critique.

Part 2 - Design Specification + Interim Report

Due October 2  
(4 weeks from start, 9 weeks until end of term)

The key goal of part 2 of the project is to firm up the design of  your project. In this part of the project you need to provide mock-ups, storyboards, and sketches of your game The sketches should have significantly more detail than for part 1. You should provide pencil-and-paper or electronic images of the game, and you should be able to show bits and pieces of a working prototype. Your design sketches should be sufficiently detailed to allow useful feedback about the design.

Describe how many layers you have finished. You should be most of the way through layer 1 or perhaps even 2 (depending on how aggressive your proposal was).

Explain what has proved to be harder (or easier) than expected. What design revisions have you made to your game as a result of what you've learned with the preliminary implementation?

Demo your progress so far on the machine(s) in the classroom. Briefly show the latest and greatest of what you got.

Your progress report will be graded on:

Part 3 - Minimum Target

Due October 23
(7 weeks from start, 6 weeks until end of term)

  1. Hand in a one page progress report on your game. Describe how many layers you have finished. You can include screen dumps to help explain it and text to describe how a user would interact with it. You should be most of the way through layer 3 or perhaps even layer 4 (depending on how aggressive your proposal was). Your report should have no more than 5 pages.

    You must have completed layer 1 by this time!

    Explain what has proved to be harder (or easier) than expected. What design revisions have you made to your game as a result of what you've learned with the implementation?  Discuss the implementation challenges you faced. Were their aspects that you wanted to build but were unable to do so?

  2. Each group will do an in-class demo of their work to date. Briefly show the latest and greatest of what you got. When we run out of time on the first day, we will continue on the next class day.

Grading:  The main purpose of this milestone is to make sure that you are making progress in your implementation and that your team will be able to finish the whole project in time. Grading is a comparative process: groups that show more progress will receive higher grades.

Part 4 - Alpha Release Demo Fair and Video

Due November 6
(9 weeks from start, 4 weeks until end of term)

At this point, you're almost done. "Alpha Release" is intended to allow you to freeze a version that will be suitable for playtesting. You will start real playtesting immediately after this date. For the Alpha Release, principal design is long complete. Principal coding is also complete. You now have to put your game in front of customers and learn what they like and don't like. In the few weeks after this date, you will take user opinions and adjust your game to suit.

In class on November 6th, you will demo your game to everyone. Bring your own computer, select a spot near the wall in the class, and prepare to be visited by me, the TA, and by a large number of guests. People will drop by and play.  Please turn in a brief report (max 5 pages) detailing your progress and the current state of your game.  Include the layers completed, current screenshots, and a brief section explaning what you wanted to do but wasn't able to accomplish and why.

Attendance at this class is mandatory.

Technical Setup

Technical setup for your demo MUST be done in advance of the start of class. We suggest you prepare by moving your demo machine around and setting it up somewhere other than its usual home. If you need networking, we need to know. The TA will be available to help with setup before the class. Email him.

Not all graphics cards are alike--you may get radically different performance on a machine you're unfamiliar with. You are encouraged to test your game on the machine in class the week before, so there are no surprises. 


You will be graded on:

Digital Video

By December 11, or soon after, your team must deliver a digital video demonstration of your game. This video will briefly demonstrate the high points of your game. The maximum length is 4 minutes. You must deliver a digital video file that is 720 x480 pixels with standard NTSC digital video timing (29.97 fps). 

There are a number of steps:

  1. Record video:
  2. You have several options:
    1. Use a DV camera to capture the video out of a computer and save it back to the disk..

    2. Use a graphics card that will output TV composite sync. Play the game on one computer, output NTSC, and use another computer to do live image capture onto its disk.

    3. Use your computer to do live image capture onto your computer's disk. This will slow down things substantially.

    NOTE: The TA will help you if you want to capture your game to a DV camera and copy it back to a local disk (option 1). Contact him if you need to schedule a meeting in the digital media Lab.

    Part 5 - Playtesting and Final Paper

    Due December 4  
    (14 weeks from start, This is end of term)

    Between the time that you demo your game in the demo fair you should get several friends or classmates not on your team to playtest your game. Test your game with five or more people. Observe them playing the game to see what is harder or easier for them than expected. Interview them afterwards to find out what was fun about the game as well as what might be improved both in the short term and the long term. Listen to what they have to say and don't be defensive about their complaints. Improve your game based on their comments!

    Final Writeup

    Each team should turn in a final writeup for their game. Your final writeup for your game should be paper that addresses the following issues:

    Include screenshots of your game to illustrate your points as well as references to the class readings or other materials.

    A sample final report is provided to give an example of a great report.

    Brief Final Presentation

    A representative of each group will give a brief (4 minute) presentation on the results of the playtesting phase for their game. Concentrate on the results of playtesting. It can be safely assumed that you could use more time to improve your game, so you can skip mentioning that. There will not be time for a game demo. If you have slides, please preload them on one of the machines in the classroom.

    Personal Contribution Writeup

    In addition to the group paper, each team member must separately turn in one page describing that person's individual contribution. We are primarily interested in a detailed description of which parts of the code and game design you were responsible for, but you may also mention if you had primary responsibility for a particular group task such as writing the project proposal.


    Each group member must also distribute 100 points among the members of your group, including yourself. The number you assign to a member is an assessment of the quality and quantity of their work. More points = better work/more work. You must hand out all 100 points.
    Groups that function well most likely have an even distribution.

    You can put this report in a sealed envelope if you like.
    You must each include your rating with the final group report.


    You will be graded on: