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 $250. 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. Right now the cheapest Steam Deck is $350 (though its hard drive is so small you should really go for the $400 model).


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 game engines is in a separate course: CS 5625. But in that course, the students are only expected to make the engine. 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 eliminates both Unity and Godot. While Godot is not as closed as Unity is, it is not designed to make working with its internals very easy.

For several years we used Cocos. The results were okay, and the design has several good ideas. However, the compile times were long (as long as an hour on some Windows machines) and the file sizes were huge (over 2 GB). In addition, there were a lot of legacy issues that prevented students from using modern C++ features like smart pointers.

Looking at the projects that students wrote for Cocos, we noticed that they all used a very small core group of classes. Therefore, we decided to do something radical. We made our own game engine, which we call CUGL from just these core classes. If you need anything else, you will need to write it yourself.

While this may seem sketchy, this is the seventh year we are using this engine. We have had two massive viral successes breakout in this time. This engine is more than enough for the games that you want to develop in this course.

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 are in 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.