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, iPod Touch) 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 $150. For just 50 more dollars, you can buy an iPod Touch. If you split the cost among your group, this is cheaper than most textbooks (and there is no textbook for this course).

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: Students who wish to create a 3D PC game are exempt from the mobile requirement. However, 3D games have much greater requirements, both in terms of programming ability (see below) and artist requirements. In our experience, it is hard to complete a 3D game in a semester without a middleware platform like Unity which is not allowed. Almost no 3D game has ever made an A in this course.

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. This can be tricky, since this is the first semester in a while that this course has been offered. But we are adamant about this requirement.

Exceptions: There are none. If you cannot satisfy this requirement, you should work on a mobile device.

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 was cleanly designed and was relatively inexpensive to deploy to a mobile device (so not Unity, as it fails on both counts). There are currently only three viable options: LibGDX, Godot, and Cocos2D-X.

While many students like LibGDX, garbage collection and memory issues make it very difficult to design high performance mobile games in Java. It is clear that we needed a C++ solution. This is also why we rejected Godot. Coding in Godot is largely limited to scripting, and so that makes it inappropriate for a course like this.

For several years we used Cocos2D-X. 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 Cocos2D-x, 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 fourth 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.

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 p arts of a game or game technology. As usual, this means you should be careful with proposing RPGs or real-time-strategy 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.

App Store Distribution

Your game should be designed for public distribution.

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.

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.

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.