Project Requirements

We have several requirements for the game you will be making in CS/INFO 4152. The primary purpose of these requirements are intended to ensure that you are growing as a game developer, and that your are not just making another CS/INFO 3152-level game. For some of you, your CS/INFO 4152 project will determine whether you are able to get a job in the industry, and so you want to make this project “count”.

Mobile Gameplay

Your game should target a mobile device (smartphone or tablet).

Why: Mobile games are the most popular and accessible market right now, and therefore they are a major focus of this course. Almost all of the lectures will involve these types of games. When we allowed any sort of game development in this class, the quality of games was extremely uneven. Since focusing on mobile development, the quality of CS/INFO 4152 games has risen dramatically.

Acceptable mobile devices for this class are iOS devices (iPhone, iPad) or the Android (smartphone or tablet). If you want to develop for Windows Phone or Surface, please talk to us first; we do want you making another PC game that just happens to work on a mobile device. We want this project to be substantially different than CS/INFO 3152.

We cannot provide you with hardware for these platforms. If you wish to work on a particular mobile device, we suggest that your group get together and purchase one (in lieu of the cost of a textbook). You can buy a Samsung Galaxy Tab A for under $100. If you split the cost among your group, this is cheaper than most textbooks (and there is no textbook for this course). Unfortunately, Apple devices are a little pricer as the cheapest iPad is almost $290. With that said, the likelihood that someone in your group has an iPhone is pretty high.

Note that targeting a mobile device does not preclude you from targeting desktop platforms as well. The engine supports Mac and Windows as well as Android and iOS. Indeed, having a cross-platform release would be much more appealing for Showcase.

Exceptions: The only exception to this rule is for you target the Steam Deck. While this is more like a traditional computer, it is still a mobile device (nominally), and your game should leverage its unique form factor. If you target the Steam Deck, someone in your group must own one and be willing to bring it to Showcase. Unfortunately, Valve sold out of the cheapest and refurbished, so the cheapest model right now is $550. This is a pretty significant investment. So only do this is you want the device.

3D Restrictions

If you develop a 3D PC game, your team must have students who are either previously or currently enrolled in CS 5625.

Why: In the past, we have had many students work on a 3D game only to end the semester with a technical prototype that had very little gameplay. Sometimes this is because the students tried to implement their rendering and physics engines from scratch. Other times they used an existing engine, but spent all semester trying to figure out how to get it working.

The only times in which students have been successful with their own graphics pipeline is in a separate course: CS 5625. But in that course, the students are only expected to make the pipeline. the game they make is irrelevant. Indeed, it seems like making a 3D game is really two classes: one for the engine and one for the game.

Therefore, our experience is that that only way to make a 3D game in a semester is to reuse the technology developed for CS 5625. Hence our requirement. Even with this requirement, no 3D game has made an A in this course in the past ten years. Be warned.

Exceptions: There are none. If you cannot satisfy this requirement, you should work on a 2D game.

Provided Game Engine

Your game must use our custom engine.

Why: For years we let students use whatever engine they wanted for this course. It was a support nightmare. In addition, we had to make sure to break people up into Android-only groups and iOS-only groups, which made team formation difficult. We desperately needed a cross-platform solution for this course. We also needed one in which gave students access to the internals for study and experimentation. The latter criteria unfortunately eliminates Unity. While Godot is a possibility, we have found its performance to be poor once you start making major changes to the game systems.

While a custom game engine might seem sketchy, CUGL is built on top of SDL, which is actually a very popular engine for indie games. It is just that working directly in SDL is challenging because it only uses pure C and does not provide access to modern programming language features (like lambdas, coroutines, and type polymorphism). CUGL is a C++ layer on top of SDL that makes the transition easier and gives you a lot more to work with.

With that said, CUGL is very minimal. It has a robust 2d graphics pipeline, but a very minimal (but still existent) 3d pipeline. It supports 3d models, but not rigging. Its only physics support is 2d. There are no built-in AI features. The idea is to give you enough to write a good game, but also to force you to extend the engine when you want to do anything fancy. Even with all of this, we have had several massive viral successes breakout in the almost decade we have used this engine.

Exceptions: You are free to add as much code to the engine as you want. This is why we have provided you the source code for everything. And if you have taken CS 5625, you may wish to completely replace the rendering pipeline with your own. This is fine, though you must have a playable game at the end of the semester.

Your game must satify the legal requirements for a release on one of the app stores (including Steam).

Why: While games are posted on the GDIAC site, you should get experience in serious self-promotion of your game. That is the only way that anyone will ever play your game. If your game is a mobile game, this means getting your app on to either the iTunes or Android App Store. For a Steam Deck game, it obviously means getting your game on Steam.

Doing this requires that you must obey certain restrictions with respect to software licensing, game assets, and generative AI. You may not use any third-party software that has a license that is incompatible with a commercial release (such as the GPL). You must have a proper license for any art, music or other assets that you did not create yourself. And you should follow Steam’s Guidelines on the use of generative AI in your game.

Exceptions: You do not actually have to publish the game to that venue at the end of the semester, should you decide to “chicken” out. However, actual distribution is greatly encouraged, particularly if you are looking for a job in the industry. And regardless of your choice, there are no exceptions to the policies on licensing, game assets, and generative AI.

Reasonable Scope

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. As usual, this means you should be careful with proposing RPGs or collectible card games (though they are possible if you keep your scope limited). More importantly, this is why we have significant restrictions on 3D games. Even producing the art for a 3D game will eat up your semester.

Exceptions: There are no exceptions to the feasibility requirement. If we are worried that you cannot implement your proposal in a semester, we will challenge you for evidence that it is possible, or reject your proposal outright.

Reasonable Originality

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.

Reasonable Quality

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: There are no exceptions. This is an expectation we have of your game, even if we cannot technically require such an intangible thing.

Reasonable Performance

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 will give advice on how to speed up your game.

Reasonable Workload

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.