CIS 300: Introduction to Computer Game Design

Project Requirements

We have several requirements for the game you will be making in CIS 300 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.

Your game must not be an RPG.
why: RPGs are very big games to develop, especially from a content perspective. You will not have time in this class to make a complete RPG, even a very scaled back one.
exceptions: Certainly games with RPG elements are fine. The key here is keeping your game feasible in the scope of 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 300.
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 don't make your game concept rely on having a first-person view or being in an expansive 3D world, and don't do anything else that's overly ambitious for that matter. If you're not sure whether something is reasonable, ask us about it.

Your game must use GameX as its sound and graphics engine.
why: We don't want you wasting too much time on low-level features.
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 GameX, then we might allow you to use a different engine. You will still have to complete all the intro labs with GameX (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.
note: There is really not much reason to worry about this as relates to GameX, but if you are worried about intellectual property issues as some students have been in the past: GameX is released under a slightly modified GNU General Public License. If you will not be publicly releasing your game, you are not obligated to release its source code. Even if you ARE planning on publicly releasing your game commercially, the GameX license has a clause which allows you to do so, under certain easily-met conditions, without releasing your source code. In either case, your game and your code are still your own property regardless of whether the game runs using GameX.

Your game (graphics, sound, music and all) must be less than 15 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 15 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'll 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 (in Release mode).
why: If your game runs slower than this on whatever computer you're 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're 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 don't 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's 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 not leak memory (this one only applies to the programmers).
why: Memory leaks (failure to delete allocated memory) are one of the surest signs of unstable software, and we want your game to be stable.
exceptions: None. If you make sure to include GameX in every code file, you will be automatically notified of where in your code your memory leaks are, so there is really no excuse to submit a final game to us that leaks memory.

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: None. But, 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've 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: Just kidding, why would we care about that? :-)

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.