For "the game project" you need to write a game. Here are some ground rules for what the game must be. Note: our goal here is to be as flexible as possible about what game you design and build, but still have the project "work" for the class.
On this page... (hide)
Note: some of these requirements make more sense when you understand how the project will be evaluated when the project is done.
On one hand, trying to do a game design that fits into this funny class project setting is kindof silly - since the constraints are pretty artificial. However, any real design project is about meeting a set of constraints - and the ones imposed by a class could be the ones imposed by the reality of a companies situation, ...
I could have made up a hokey story about how these constraints aren't because this is a class project, but rather, because you are working for a real game studio and a big publisher is considering buying you, therefore you need to demonstrate to them how good you are in a very short amount of time.
OK, the rules:
You should think about how you will use game design principles to make it fun.
This is a big constraint. There isn't much time.
So, I recommend in your design you consider 3 things:
A different way to put it: your design should have a simple version that can easily be pulled off in 3 weeks (or faster, if things go well), but can be extended into something bigger and cooler (if you have time).
Many students in class have their hobby projects or code they've written previously. You can't use this.
For one: you might not even be part of the team building your game. And while you might be willing to give another group your code, you'll be too busy making your own game to give them much support.
Update 2/15/07: While games must be designed so they are practical to build without using previously written code, teams can make use of "old" code from their members providing that the entire team agrees, the person providing the code agrees to make it publicly available, the code is not overly "game specific", and the students get permission (by email) from the instructor.
Your playtesters (and target audience) will not have a lot of time. In 15 minutes, they need to figure out your game, and play it enough to appreciate it. (although, it should leave them wanting to play more)
This puts a little bit of pressure on you to make your game "demo well." A design that is hard to learn, requires you to get to level 17 before its interesting, or offers no sense of "progress" until you've played for hours might be less attractive. (note: the game should offer the depth for long term play - it just needs to get the player hooked quickly).
The target audience for your game includes the TA and professor, and other members of the class.
If your game requires the player to be familiar with (for example) the scenario from some book, the characters from some movie, or the rules of some existing game, you might be in trouble if the player hasn't read the book, seen the movie, or played the game.
A new player needs to be able to sit down at the game and start playing. This means that any instructions / explanations need to be part of the game itself.
If you want to use a story, a character, music, ... from a copyrighted source, you can't (since you won't have a license to do so).
If you need a technology to implement the game, it must be freely available. So (for example) its not OK to design an add-on to a commercial game (and couldn't be feasibily built from scratch in 3 weeks).
Note: for the project, teams may use available engine platforms, providing they are either freely available or are flash (because we have flash licenses).
This restriction is to make play testing easier. Its a great bonus if there is a multi-player mode, but there should be a single player experience.
Avoid gratuitous violence, references that may be offensive to some, ...
Your game must get an "E" (everyone - all audiences) rating.
This is a hard one to describe.
Basically, the work of building the game must be primarily computer science. It can't just be making artwork and showing a slideshow. It has to be "hard enough" to build, but there's a tradeoff: you don't want to pick something that's too hard (and risk not finishing by the deadline).
This is why we suggested a "Scalable" design above - pick something where you know you'll have something at the end, and hopefully you'll do better than the minimum.