CIS 3000: Introduction to Computer Game Design

Project Requirements

We have several requirements for the game you will be making in CIS 3000 this semester. These are not just arbitrary rules, and in fact they are for your own benefit. To reduce confusion, here is a list of exactly what these requirements are, our reasons for requiring them, and what exceptions we might make regarding them:

Your game must not be networked, and it must have a single-player mode.

Why: We do not want your game to rely on the presence of human opponents to be fun, especially because most people who try your game will do so alone, and time you spend getting networking to work could be spent making the rest of the game more fun. Also, we want you to have some AI in the game, and not just rely on human opponents.

Exceptions: If you can convince us that your single-player mode is sufficiently done, you can add networking as an extra feature. Multiplayer co-op-required games are also a possibility. However, the single player game must be finished and fully tested before we will allow this.

Your game must be feasible to develop in a single semester with each person contributing 10 hours of work each week.

Why: The purpose of this course is to have a completed game by the end of the semester, not parts of a game or game technology. Because of this, there are certain types games that we frown upon because they require significantly more work and content than other types. In particular, students are encouraged to avoid RPGs, real-time strategy games, and exploration-style adventure games.

Exceptions: There are no exceptions to the feasibility requirement. However, we do make specific exceptions to the games listed: RPGs, real-time strategy games, and exploration-style adventure games. Your game can have elements taken from these games so long as the scale is kept small. In particular, you should take a look at the adventure and RPG flash games at Kongregate to get an idea of what might be feasible in a semester.

Your game must not be fully/fundamentally 3D.

Why: Games like this (such as first-person shooters or flight simulators) tend to be beyond what you can reasonably hope to complete and polish in a small group working for a single semester in CIS 3000.

Exceptions: Go ahead and use a Z coordinate, 3D graphics with some polygons, 3D lighting, multiple height levels that affect the gameplay, etc. In fact we encourage things like this. Just do not make your game concept rely on having a first-person view or being in an expansive 3D world. The general rule is as follows: fixed camera good, player-controlled camera bad.

Your game must use XNA as its sound and graphics engine.

Why: We do not want you wasting too much time on low-level features. XNA is rapidly becoming a standard for game design education. It provides a lot features, and there are a lot of examples out there for you to play with. It is not perfect, but it allows us to hit the ground running.

Exceptions: If you are very familiar with some other engine, and can demonstrate that you can do everything with it that we expect you to be able to do with XNA, then we might allow you to use a different engine. You will still have to complete all the intro labs with XNA (as a programmer), and for Lab 4, show us a prototype using the your proposed engine that proves to us that it will work for you.

Your game (graphics, sound, music and all) must be less than 100 MB when zipped.

Why: We don't want your game to be so bloated that nobody will bother to download it. Also, if your game starts becoming large, that often indicates a problem with the way you are managing your game's resources, and we want to catch problems as early as possible.

Exceptions: If you think you need more than 100 MB for your game, you must talk with us about it. If you can convince us that you're right, we'll make an exception, otherwise we will tell you how to be less wasteful. We will be reasonable; we don't want to limit what you can do with your game. (We are especially likely to grant exceptions for music, but you still must ask.)

Your game must not run slower than 60 frames per second.

Why: If your game runs slower than this on whatever computer you are using, you are probably doing something wrong.

Exceptions: 60 FPS is more of a goal for you than a hard requirement, but if it often drops below 55 or so and you are not sure how to fix it, then you should ask us and we'll give advice on how to speed up your game.

You must have a readme file with your game that describes how to play, what all of the controls are, what the game's basic concept is, and which people contibuted to making it.

Why: We do not enjoy trying every button on the keyboard just to find out how to play your game, and neither will anyone else who tries to play it. Some people do actually read readme's.

Exceptions: Instead of a readme file, you may put this information inside the game itself, if it is easily accessible upon starting the game. In fact, we encourage you to go beyond merely telling us the controls, and actually make them user-configurable in-game (which is a big plus, although not required).

Your game must be original, and it must not be directly based upon previous work.

Why: This is a course about designing games, so if you come in with a game that's already designed or steal someone else's, something is wrong. Hopefully you will be excited to come up with new ideas and this won't be an issue.

Exceptions: There are no exceptions. However, this requirement refers to your game as a whole and your game's design; It's still okay for you to borrow code/art/sound/whatever from previous things you have done or even from labs/demos or anything anyone else has done (within the limits of legality) as long as your game itself is original, not a complete rip-off, and contains a sufficient amount of work from each group member.

Your game must be fun to play and contain a reasonable amount of content.

Why: Despite how subjective the word "fun" is, this is the entire point of making a game, so at the very least you should be able to enjoy it and have a sense of why others might enjoy it. Also, a game that is not finished tends not to be fun, so if your game ends up being incomplete, the parts you did complete had better be good.

Exceptions: Nope. This is an expectation we have of your game, even if we can't technically require such an intangible thing.

You must pass at least one of your other courses.

Why: Because we do not want other professors on Campus to hate us.

Those are the main requirements. Your grade will be affected if you fail to meet any of them without permission to do otherwise. If you have any questions or concerns, please contact the course staff.