Assignment 8: Level Three

  • Out on: October 20, 2017
  • Due by: October 27, 2017 before 10:00 pm
  • Collaboration: Team


The eighth (sp?) assignment in 601.255/256 continues the trend of more open-ended assignments, just like we threatened earlier.

Please remember that you must document what you've been doing, including who achieved what! If you're not sure what this means, please re-read the relevant sections of Assignment 6 again, they apply in full for this one as well!

Everybody should have plenty of things to do for this assignment. If that's not the case, you're doing something wrong inside your team. Fix it!

Make sure you clearly designate one member of your team as responsible for handing in the deliverables for this assignment! You don't want to lose points because each of you thought someone else would submit!

Problem 1: Level Three! (50%)

For this problem, you have to develop a third complete level of your game. It doesn't matter if the level you build this week comes before or after the two you built previously, that's totally up to you. What does matter is that it should be different enough to actually qualify as a new level. There should be at least some new kind of challenge, some new kind of enemy, some new kind of power-up, etc. Something must be different! Just like last week, we again expect some story-telling elements, although the details are again up to you. When you're finished with this assignment, the player should be able to "win" the first level, get to the second level, "win" the second level, get to the third level, "win" the third level, and therefore "win" the game. Please re-read the advice we provided regarding level design last week, it also applies in full to this assignment.

Level Design Hints

(These are recycled from the last assignment. Just for reference.) Here are a few things to think about. They are in not "required" at this point, but some may turn into "real" requirements later on.

  • Include a variety of challenges. Not the entire level should be about the same thing (killing enemies by shooting them for example), there should be something that tests the player's wits or at least their skill at timing an attack or whatnot.
  • Not everything in a level needs to be "mandatory" for the player to do. For example, if you include a "hard to reach" room with a power-up, but you also award bonus points for finishing the level quickly, you create an interesting tradeoff for the player. (Including two routes to the exit, each with slightly different challenges, can also be cool.)
  • Consider starting the level with a fun camera movement. One thing you could do is start the camera at the exit for the level and pan over everything until reaching the spawn point of the player's hero.
  • A simple way to include "surprises" is to have "triggers" in the level. These are (potentially) invisible objects/tiles that, on collision, set something in motion. There could be a trigger that drops a huge weight onto a boss. There could be a trigger that opens a lava pit. There could be a trigger that causes new ghost monsters to spawn. And so on.

Also, don't be afraid to revisit an earlier decision. You may have decided that your game uses a "one hit kills" mechanic, even for the hero. But as you design a challenging level, you may realize that this mechanic does not actually lead to a great experience for the player. You may need to add checkpoints or you may have to think about actually changing to a "two hits kill" or "healthbar" approach. Remember that the goal is to make the game fun (not just for the three or four of you, but for as many people as possible); that may require rethinking your original vision if it turns out not to be fun.

Problem 2: Technical, Artistic, Game Play Progress (50%)

For these 50% you are essentially free to do "whatever you want" in terms of programming, story development, game play mechanics, visual art/animation/effects, sound effects, music, etc.

The point of this problem is that there has to be some kind of progress that's easy to describe. Even better: Progress that's easy to actually experience when we play the game! Describe all your improvements in your README and don't forget to attribute them to the team members who actually made them happen! Don't miss anything!

So go wild! Just make sure that whatever you hand in for this assignment has several obvious improvements in these various dimensions over the previous assignment. No, saying "we now have a third level, and we all worked on that" is not good enough to get points for this problem!

Options to Consider

First let me be clear that all these are just suggestions, they are not "required" for the 50% you can make here. That said, you also don't want to try to do too many things at once: If each of 4 people picks a completely different thing to do, the most likely outcome is that you'll scream at each other over merge conflicts like nobody's business.

Discuss your options, try to figure out what is really going to make your game "stand out" compared to others, then go for one or two features. It's totally fine if everybody first works on feature A, then once that's done everybody works on feature B. (Or you can split it in some other way, your call.) We'd much rather have one polished feature than 17 broken ones.

  • Editor: Level editors are super-cool. But they are also a major investment of time and energy that could distract from your actual game code. You should carefully consider the tradeoffs: The high upfront cost may very well pay off in the weeks to come when you start to churn out more and better-tested levels than anyone else. And don't think of the level editor as something that must be "separate" from the game! In fact, having the level editor in game activated by some special key combination, is the best way to quickly develop, test, and polish your levels.

  • Animations: You may want to think about more (or more detailed) animations to add for the player's hero as well as the enemies. We mention this distinct from "artistic progress" because it's harder to tell that you added three frames to make things smoother, it's much easier to tell that you have a completely new object on the screen. Note that some of the animations could be dependent on game events, while others could just add "visual variety" without any deeper gameplay implications. For example, changing the hero sprite when running into a wall may have no game play effect, it just looks better. On the other hand, if you added a dodge mechanic with a new animation while the hero is doing cartwheels, that new animation would help the player to understand that now different rules apply.

  • Particle Effects: A neat little particle system can provide a lot of "visual bang" for comparatively little "programming buck" as it were. (As long as you're careful not to go "feature crazy" anyway.) They are also a way to get by with less art, something that may be attractive for engineering-heavy teams. Instead of doing, for example, explosions and the like with sprite animations, you can do them procedurally (with code). No more tedious drawing things frame-by-frame, and since you can get random numbers involved, each explosion is going to look a little different for free. But it's not just explosions, you can do "dust" or "fog" or just "glitter for no reason" using a particle system.

  • Lighting Effects: If your game/level features light sources of one kind or another (and particle effects could be light sources) you may want to consider looking into how the various "blend modes" of the rendering API allow you to "fake" something like light. The basic idea is to produce special "sprites" that represent the shape of the light source (a circle for a torch, a cone for a headlight, etc.) and to blit those sprites over places in your visible graphics where a light source should exist. Some kind of simple "shadow" beneath your player character could also be a good idea to make things look a little more polished. Note, however, that you shouldn't attack this with realistic expectations. Like much in game programming, "faking it well enough" is what you're after; so keep those raytracers and radiosity renderers where they belong: the graphics course.

That's it for now. I may have more suggestions on future assignments, or I may just recycle these again and again, we'll see. Get hacking!

General Hints

  • The libsdl2 (and language binding!) documentation is your friend! Read lots and lots of it, that's an investment that will really pay off.
  • Feel free to exceed our expectations for a given week; just make sure you can actually point to something in the game that fulfills our minimum requirements.


Please turn in a gzip-compressed tarball of your assignment. The filename should be cs255-assignment-8-team.tar.gz with team replaced by the short version of your team's name as used for your git repository. (See Piazza for additional information on how to submit assignments.)

The tarball should contain no derived files whatsoever but allow building all derived files. Include a README file that briefly explains what your programs do and that contains any other notes you want us to check out before grading. Make sure to include an appropriate Makefile for a clean build on Linux!

Please note that we reserve the right to dock points for revoltingly bad code, excessively bland art, and ear-shattering sound disasters!