Your job in this class is to make a game.

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 (see the zero gravity physics in Scott Lewis and Jeffrey Wilson's senior project). 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. We 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.
   2. Your low target: Your target for what you want to get done--the least possible to feel sorta 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 quarter, 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 we're joking, huh? We're 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.

Due on April 12th: 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 one to three pages of mocked-up screenshots and/or sketches.
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?

Components of your in-class presentation:

Please come to class on April 12th 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--we will cut you off when your time is up).
6. Use overheads in the style demonstrated in class on April 5th.

Presentations will continue into the evening from 7 to 10 pm, and attendance is mandatory unless you speak to the instructors in advance and have a legitimate excuse.