Assignment 6: Level One

  • Out on: October 8, 2017 (sorry!)
  • Due by: October 13, 2017 before 10:00 pm
  • Collaboration: Team

Overview

The sixth assignment in 601.255/256 starts you on the (long-awaited?) path toward more open-ended assignments. From here on out, your team will be in charge of most of the details, however we still set the general goals for a given week.

Yes, there are still "problems" below, but as you will see they are nowhere near as specific as the "problems" on previous assignments. There is also a large section of "options" where we suggest things you may want to look into to improve your game, but none of those "options" are "required" in any strict sense of that word.

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!

Obligation: Document Achievements!

Since you're "taking over the reins" so to speak, you'll actually have to document what you've been doing! Starting with this assignment, we require that your README file "breaks down" what each team member achieved for a given assignment. Achievements are tangible things! It's not an achievement to have "thought about" something or "played around" with something or "done some research" on something. Be sure to have measurable achievements, stuff we can see in code, assets, game play, etc. (No, spending 12 hours to reformat all the code to a different indentation style is also not an achievement...)

Benefit: Decide Everything!

Starting with this assignment you are free to revise/replace all the basic mechanics we required before. You can handle controls in any way you want. You can handle scoring in any way you want. You can handle enemies in any way you want. And so on and so forth. Just make sure that you work toward the "end goal" for the course: Producing a complete game that you would be willing to pay $0.99 for in the "app store" of your choice. (Of course you need to document your control scheme and user interface in your README because we won't "guess" how to play your game.)

Problem 1: Level One! (70%)

For this problem, you have to develop a first complete level of your game. Last week was "playing around with some sort of level" but this week is "this will actually be in our game" so it's time to get serious about designing a level, not just glueing one together at random.

Note that we say "a first complete level" not "the first level" so what you hand in can be, for example, level three in the final game. Just pick one of the levels you have plotted out already, ideally one that's mostly doable with the technology you have developed so far, and actually make it!

If your game has some kind of story, even if it's a rather incoherent and crazy story, we'll expect at least some story-telling elements such as cut-scenes (static, animated, temporary, whatever) or voice-overs (maybe imperfect but somewhat understandable), etc. Of course it would be even better if you could "tell the story" in the game itself, maybe by scripting scenes directly with your engine. Whatever you decide, please make sure there's an obvious way to skip cut-scenes or text-overlays or whatnot because nobody who plays the second or third time wants to be forced to sit through all that again.

You should set up the level so the goal for the player is clear (or as clear as it's ever gonna be given your story), and you should explain special mechanics beyond "run around, have fun" that the player may not be familiar with. Once again, ideally you just show the player what to do by scripting an example in your engine (just make sure they can skip it, see above). That's a whole lot more enjoyable (and instructive) than reading a wall of text that tries to explain what to do.

As in the previous assignments, it should be possible for the player to "win" or "lose" the level (and therefore the game) and your scoring system should allow players to try the level again and improve their skill in order to reach a better score next time. In other words, try to hand in something that is a "real game" except for the (minor?) fact that it consists only of a single level so far. Of course nothing that worked before should suddenly not be present anymore, although the details may be different to suit your team's vision instead of ours.

Level Design Hints

(These are mostly 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 (30%)

For these 30% 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 first 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 30% 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.

Deliverables

Please turn in a gzip-compressed tarball of your assignment. The filename should be cs255-assignment-6-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!