![]() | ![]() |
|
Main
About:
Resources: |
Project RequirementsWe 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:
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.
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.
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 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.
Why: We don't 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. Note: If you are worried about intellectual property issues, as some students have been in the past, then look at Microsoft's FAQ on XNA.
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.)
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.
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).
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.
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.
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. |