Project Requirements

We have several requirements for the game you will be making in CS/INFO 3152 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 use LibGDX as its sound and graphics engine.

Why: We do not want you wasting too much time on low-level features, but we do want you to learn proper software architecture (so Unity is off limits). For many years Microsoft XNA was the best balance here, and had become the standard for game design education. However, Microsoft has abandoned XNA and their official stance is that Unity is its replacement.

While we have resisted using Java in this course for many years, LibGDX has grown into an extremely powerful game engine provided that you follow proper conventions on memory allocation. It is also one of the cleanest, best-designed game APIs out there. If you can use LibGDX, you can figure out any other game engine. Therefore, it is now our engine for the introductory class.

Exceptions: None. Long ago we allowed people to use other game engines if they could prove that they understood the API. These days we want everyone to be working with the same engine so we are not going to allow this -- not even MonoGame. If using Java for game programming makes you feel dirty, do not worry. We use C++ in CS/INFO 4152.

Your game must be feasible in a semester with each person contributing 10 hours 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. 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 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 is already designed or borrow 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 is 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.

When borrowing assets, please remember the academic integrity policy. You must properly cite any sources that you use. You also may not include any assets that you are not licensed to use, regardless of whether or not you cite the source.

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 cannot technically require such an intangible thing.

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 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 CS/INFO 3152.

Exceptions: Go ahead and use a Z coordinate, 3D graphics with some polygons, 3D lighting, multiple height levels that affect the gameplay, and so on. 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 (graphics, sound, music and all) must be less than 300 MB when zipped.

Why: We do not 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 300 MB for your game, you must talk with us about it. If you can convince us that you are right, we'll make an exception, otherwise we will tell you how to be less wasteful. We will be reasonable; we do not 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 pass at least one of your other courses.

Why: Because we do not want other professors on Campus to hate this class. Well, no more than already do.

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.