Project
Your project for this course will be to develop an actual video game in interdisciplinary teams of 3-4 students. Since this is where you will spend most of your time, your project is the most important grade item in the course. You can mess up everything else and still (barely) pass if you have a great project. Make sure you read the following notes carefully and ask the course staff if anything is unclear.
Teams
We will form teams depending on the skill surveys you filled out. We will try to balance the teams both regarding the areas of expertise you have as well as your level of accomplishment in these areas. This is not going to be perfect, but it will hopefully give every team a good shot at producing a great game.
Each team will get its own mailing list for coordination as well as a Subversion repository to keep its various artifacts in. If you have no clue what a repository is, rest assured that someone on your team will know. You are expected to use these resources to coordinate your team work. Each team is also expected to put together a rough website on the gaming lab server, details about this will follow.
Each team will meet with a mentor once a week for about an hour. The purpose of these meetings is to get feedback on your game from someone with a lot of experience in game design. Your mentor will also be on your mailing list, but he or she may not answer every single email, waiting for the meeting instead. We recommend that you use Doodle to set up a meeting time with your mentor, and he or she may point you to a Doodle poll of their own.
You should also coordinate your own schedules in a way that allows you to work together face-to-face. It is certainly possible to work mostly remotely, but experience from previous project courses has shown that working together in the same area can make your team jell much better, eventually resulting in a better product than what you would otherwise have accomplished. Once again, we recommend that you use Doodle to set up a poll to coordinate meeting times for your team.
Games
The details of the course project are to a large extent up to you. You can decide what kind of game you want to write, what technologies you will use, and how you will go about coordinating your development process. However, since it is easy to get carried away and plan too big a project, you will need to submit a proposal first to be approved by the course staff. Once approved though, your project is 100% your own.
Since teams will have very different skill levels and ambitions, we cannot expect every game to meet the same standard of sophistication. The games you produce will probably range from an improved Pacman all the way to a neat rendition of Half Life 2. You may think that we can't possibly consider both of these "A grade" but if they meet our criteria, we will. :-) Here are the criteria:
- Your game must be fun! This is the most important ingredient, and it's the most difficult to describe and achieve. A good way to ensure fun is to follow an established pattern that others have shown to be fun and improve on it. If you don't want to follow a pattern, you will have to do lots of play testing while you develop the game. Other teams will give you feedback on your game at certain points during the course, but you probably want to run your own play testing sessions as well to make sure you're building a fun game.
- It must be a game! It cannot be some other kind of interactive experiment. It must have objectives for the player to accomplish, it must have obstacles the player has to overcome, it must support some kind of progression in difficulty that can realistically be mastered in several hours of play, it must have loading/title screens and menu-based configuration, it should provide some way for players to review statistics of how well they and others did.
- Speaking of "progression". Part of the "progression" of your game should be a variety of levels or stages. Think different mazes for a Pacman-type game, different flying patterns for a Galaxians-type game, the various levels of Doom or Quake, and so on and so forth. Challenge stages, boss levels, everything that adds some variety to the game (variety that the player will look forward to) is good.
- It must have graphics! Your game must be graphical in nature, text adventures and other text-based games are too pre-historic at this point. Whether your graphics are 2D or 3D is secondary. Whether your models/textures/images are fancy or plain is secondary. Of course 3D and fancy is cooler, but you can get an A with 2D and plain as well. If your game requires state-of-the-art graphics hardware, it would be good to make level of detail and texturing configurable to support a wider range of machines.
- It must have sound! Your game must have sound effects and a musical score of some kind. Ideally the score is built around a recurring theme but has variations according to the mood you want to create for a given level or stage in the game. A more involved title/loading score combined with various background scores throughout the game and maybe a sad ending score when the player fails are all good ideas. Make sure that the volume of music and sound effects can be adjusted by the player.
- There's more than the program! Your game must come with supporting materials. A manual is a must, but depending on the kind of game you produce it can be brief. It should cover the basic plot, installation procedures, and basic configuration for sure. It would be great it you could design a retail box as well. However, don't spend too much of your time on marketing materials, the game itself is more important in the end.
For example: We would be thrilled if you produced a game like Urban Terror or Call of Duty 4, but we'll be quite happy if your version is 2D instead of 3D, features 3 instead of 10 types of weapons, has 2 instead of 20 hours of game play, supports play on only one machine instead of across a network, etc. As long as our criteria above are otherwise met that is. :-)
We will do our best to give you feedback on your games regularly. You'll have a mentor with whom your team will meet once a week to discuss how things have been going. You'll have the opportunity to review the games other teams are working on. Your game will get reviews from other teams as well. We'll also have at least one public play test session in the DMC that will be advertised widely to get you some outside feedback. In the end, it's all about a fun game with decent graphics and sound and you should be good to go. :-)
Submissions
You will submit your project three times, and we call those the ALPHA, BETA, and GOLD submissions. You can find a little more about each of these below, the following is about submissions in general and applies to all of them.
Content
Each submission should include all source code and
all other assets that you have produced for your
game.
It should also include all assets that you are using but didn't
produce, ideally clearly labeled as such in the documentation.
Each submission should also include the fully built and ready-to-run
game itself, at least for your main platform (and better yet for all
the platforms you support).
Of course your manual and other marketing materials should be there
as well.
It is important that you include a short README that
explains the structure of your submission and contains anything else
you'd like us to know about before grading; clear instructions on how
to install and run the game would be appreciated as well.
Email Submission
If your game is small enough to be submitted by email, simply send
a .zip or .tar.gz archive to the
submission address for the course
(see Contacts).
You should get a confirmation email that explains whether your
submission was successful or not.
CD/DVD Submission
If your game is too huge to be submitted by email, we need you to hand us a CD (or DVD in the worst case) with the required materials. Note that this means you have to submit early enough for someone on the course staff to still be around to accept your submission in person. Also, you need to make your submission available online for other staff members and other students to download. The link to your submission needs to be submitted in email! Yes, we need both the CD/DVD and a link to the online version! However, since I just made this up, for the first ALPHA a link to the online version alone suffices.
