Assignment 5: Camera, Walls, Action!
- Out on: September 20, 2017
- Due by: October 6, 2017 before 10:00 pm
- Collaboration: Team
For your fifth assignment in 601.255/256 you'll (once again) do two things:
- First, you're going to make sure that your game fulfills the core top-down action adventure game requirements for this semester.
- Second, you'll put together your first complete level for the game, something that has at least four "screens" worth of action.
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: Top-Down Action Adventure Requirements (50%)
This problem is mostly about code and technical stuff, but it affects level design as well (see Problem 2).
- There must be an environment to "adventure" in that consists of (at least) areas that can be explored freely and obstacles that constrain the hero's movement; think walls for a game set in a castle, rivers for a game set in a wilderness, etc.
- Levels must be bigger than the screen and should be "exposed" only partially by a (smoothly!) moving camera that is (usually!) focused on the hero.
It is certainly possible that you already implemented these features before this assignment. If that's the case, we still recommend that you spend some time to "polish them" more. If, for example, your camera movements so far are "bland" as in the camera is always perfectly centered on the hero, maybe it's a good idea to introduce a little (emphasis on little!) lag to make the movements more interesting?
Note that we don't require any specific kind of "obstacle" so you have some leeway as to exactly what you do, but it can't all just be "the border of the level" anymore.
As we talked about in class you should probably extend your engine with a camera object that determines which part of the world will actually be rendered on screen. In other words, the camera has coordinates in the overall level (so those are world coordinates) and it's as big (width, height) as one screen worth of pixels. All the pixels visible in that particular section of the world will actually be rendered, everything else that may exist in the world will not be.
Note that it would be convenient to implement the camera in such a way that movement in all four cardinal directions (left, right, up, down) is possible. Even if none of your levels actually extend up or down, having a camera capable of those directions will allow you to do nice "special effects," for example the classic "screen shake" when something really big "blows up".
We recommend that you use a tile-based approach to level design and rendering; this has been illustrated in class and with example code earlier in the course, but you didn't have to implement it yet. It's still not a strict requirement, just something that seems like a good idea judging from the decades of games that have gone before yours. If you don't go for tiles, try to at least not "hard code" each level but to somehow "externalize" the necessary data; it will be much easier for everybody to contribute to level design (even for programmers!) if no code is involved in that process.
Problem 2: Your First Complete Level (50%)
This problem is mostly about level design, not about the code necessary to do "scrolling" or "collisions" or whatever, but it's obviously affected by it (see Problem 1).
In almost all top-down action adventure games the levels the hero has to "explore" and "overcome" are bigger than the screen itself. This allows for more varied action, for more interesting "surprises", etc. Problem 1 was about the technical aspects of this, now we're concerned with actually designing such an experience for the player.
You should think of this first level as "level zero" so to speak. It may very well be that the particular level you design now doesn't make it into the final game. Your goal for this assignment should be to get experience with the technology for levels and with the process of designing interesting and fun challenges. (And even if you keep the level for your final game, it may actually end up being level 3 there.)
The minimum requirement for this problem is that "four screen-fulls of stuff" happen in your level (and therefore your game, because it will only have one level so far). So if your game is played at 1024x768 screen resolution, your level could be 2048x1536 or 1024x3072 or whatever format you find natural.
Level Design Hints
Here are a few things to think about. They are in no way "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.
- 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.
- Remember that we want the escape key to immediately quit your game completely regardless of what state it is currently in!
Please turn in a gzip-compressed
of your assignment.
The filename should be
team replaced by 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.
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!