Assignment 4: Win, Lose, and Scores
- Out on: September 19, 2017
- Due by: September 29, 2017 before 10:00 pm
- Collaboration: Team
For your fourth assignment in 601.255/256 you'll (once again) do two things:
- First, you're going to make sure that the "game" as it stands now can be lost as well as won.
- Second, you'll add some kind of scoring system and integrate it with the high-score screen you already have.
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: Win or Lose (50%)
After this assignment it must be possible to win or lose the game. Given that all you have so far (at least according to Assignments 2 and 3) is a bunch of randomly moving enemies, you may want to spend at least a little time on making those enemies slightly less random first. (Depending on your game, maybe you even want to allow them to "shoot" at the hero instead of just crashing into it?)
It's up to you what the lose condition is exactly. It could be as simple as the player getting hit once. It could be that there's a health bar that goes down with each hit and the game is lost only when all the health is used up. Or it could be that there's a time limit for getting all the enemies and if the time limit is exceeded, the game is lost. The details are up to you, but you should try to pick something "typical" from your vision of the final game, not something you'll never use again.
The win condition is a little more stringent. What we want you to implement is straightforward, but it may not be exactly what your actual game design calls for. Just roll with it for now! The win condition should be that the hero reaches a certain point on the screen, a point that's clearly marked somehow. The enemies should make reaching this point at least a little difficult to achieve. Given the theme for the course, this should be an okay win condition, but of course your game may call for something different. It matters not, for this assignment, winning means reaching that point. Done!
Problem 2: Scores High and Low (50%)
You need to design some kind of scoring system for your game as it stands now.
Go for something simple, for instance a fixed number of points for each enemy
destroyed or obstacle overcome or powerup picked up or whatnot.
Just make sure the scoring makes sense (takes the difficulty of the task into
account to some extent) and don't make the scores too low: Arcade games thrive
on scores like "10.000 points for the secret trapdoor" instead of "1 point for
the secret trapdoor".
Maybe there's even a bonus for the time it took to finish the game?
Whatever you do, be sure you include your reasoning in the
Obviously the player's current score should be displayed while the game is being played, and it should (also obviously) go up whenever more points are awarded. Cute little special-effects (graphics and sound!) are a nice touch when points are netted! All of this should get tied in with the high-score screen, meaning you should implement that part of the game as well. Now that you can win, lose, and score points, you have everything you need to call this a first approximation of an actual game!
- 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!