Due at varying times CS 4455 - Video Game Design & Programming Spring 2006

Group Project: Video Game Design and Programming

Outline

Quick access to the sections of this document:

Project Overview

This term you will undertake a group project (4 or 5 people) to design and build a prototype game.
    Each team member will receive a grade based upon the quality of the project and a peer evaluation. 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.

     One of the learning objectives of the class is to learn how a modern game engine works.  Therefore, you will be expected to use an existing game engine for your project, and work with that engine at the source level.  This means that you should not consider building your own engine, nor should you design a game that can be built with no programming using level editors or simple scripting.  This also means that when judging a game, we will judge all aspects of the game, but be biased toward the technical quality.

Project Reports

Each part of the project will include a deliverable report. This report will be provided in html or pdf, on the teams' website. Each team should create a "home" page which includes: 1) a brief (paragraph) description of the game; 2) the team members; 3) Links forming a table of contents for the rest of the reports. 4) Demo executables.. 

The format of the reports for the individual parts is up to you, but it should be professional in appearance, grammatically sound, illustrative of your efforts and process, and easy to understand. Do not expect us to assume things, or know what you are thinking. A good design effort can easily be hampered (and thus receive a low grade) by a poor communication of what was done. At the end of the term, the teams should be able to archive the report, source code, and executables into a single zip or tar.

Presentations

All presentations must be attended by all class members.
Every group must be ready to present on the first presentation day.
You are welcome to bring you own computer(s).
You can volunteer to go first, if you wish.

Part 0 - Group + Topic

Due January 23  (week 3)

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

Remember, the focus of this class is the technological rather than the artistic side of game design.  You should aim to build a game that has you engaged with the technology, in contrast to having a game with a focus on content elements.

Part 1 - Game Proposal + Design Sketch

Due February 6  (week 5)

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. You could focus on doing something interesting with one piece of game technology, such as doing something neat with a twist on physics. If you do a text adventure, you could focus on the AI behind the characters or the reasoning about what the player types.  A 3D game could do something interesting with the graphics engine.  Your game could focus on creating an innovative and well-tuned user interface. Make it really stand out in one way.

  3. Do Enough and Only Enough Content to Make Your Game Compelling

    Do NOT do lots of levels for your game. All you need is one, small well-done level. You could focus your content efforts on creating gorgeous graphics, witty sound effects, clever puzzles.  You will not get a good grade for a poor quality game that looks great.

  4. 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 an engine that gives you higher-level control of 3D content like UnReal or Torque (especially if you don't already know OpenGL or DirectX). You give up a certain amount of creative control when you decide to use an engine --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.

  5. 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 March 6, 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.

Due on Feb 20th: 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 four copies of your proposal document, which includes two extra copies 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 Feb 22  (week 7)


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 or on your own laptop. Briefly show the latest and greatest of what you got.

Your progress report will be graded on:

 

NOTE:  you will have 10 minutes TOTAL (from when you are called till when you sit down).  So, you should aim for a 5 minute presentation (including quick demos) to leave time for discussion.  Be prepared. 

Part 3 - Minimum Target

Due March 6 (week 9)

You must have completed layer 1 by this time!

    1. Hand in a one page (one page text + one page schedule) 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.
          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 there aspects that you wanted to build but were unable to do so?
    2. Include your entire layered schedule in list or tabular form.  Indicate what has been completed and the anticipated completion date or percent completed for uncompleted items.
    3. 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

Due April 3 (week 13) 


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 April 3rd , 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 wasnt 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 you will use in class before you arrive, so there are no surprises. 

Grading

You will be graded on:

Part 5 - Playtesting and Final Paper and Video

Updated Game Due April 17

Presentation and Paper Due April 24  
(week 15 and 16)


Between the time that you demo your game in the demo fair and April 17, 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!

The improved game is what you should demo during playtesting week to the class.  During this week, the groups will be given the opportunity to play each others games. 

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.

An sample final report is provided to give an example of a great report.  Sample P5

Brief Final Presentation

A representative of each group will give a brief (4-5 minute) presentation on the results of the playtesting phase for their game and show their video demonstration (see below). 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.

Digital Video

By April 24th, 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 high resolution digital video file that is 720 x480 pixels with standard NTSC digital video timing (29.97 fps).   You must also deliver a compressed version of the file that you can show in class during your presentation.

There are a number of steps:

  1. Record Video:

    2. You have a number of 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). He will hold office hours in the Digital Media Lab on the week before the video is due

  2. Edit it:
    1. After you have your footage captured to a machine in the video lab (or other machine where you are comfortable editing), use Premiere, Final Cut Pro, etc. to edit your video. Premiere is available in the Media Lab and Final Cut Pro is available in the Mac Lab. After Effects, SoundForge, and other support programs are also available in the above labs.
    2. When you write your final video, MAKE SURE you encode your video using the a codec that can play on any machine (e.g., if you use the Canopus DVRaptor capture hardware in the Media Lab, transcode to something else that can be used anywhere).  Use a high quality codec with very little compression so the quality is preserved.  Do not worry about file size.
  3. Give it to us:
    1. Create data DVD (NOT Video DVD) or CD and put the file(s) on it
    2. Bring the file on disk to the TA's office hours and copy it to his computer, or upload the file and send us a pointer to it WELL BEFORE the deadline.
    3. If you have any problems or questions, contact the TA well in advance.  It is your responsibility to get the file to us on time, and the TA in not responsible for adapting to your schedule.

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.

Grading

You will be graded on: