Assignment 3: Animation and Game States
- Out on: September 16, 2017
- Due by: September 22, 2017 before 10:00 pm
- Collaboration: Team
For your third assignment in 601.255/256 you'll (once again) do two things:
- First, you're going to animate your hero and your (one and only so far) enemy sprite.
- Second, you're going to wrap everything you have so far (plus animated sprites) into a framework that provides "the other things" a game is expected to have: a title screen, a menu, and a high-score list.
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: Animated Sprites (40%)
The sprites in most 2D arcade games are animated in a very stylized way, and for this problem you need to add animation for both your hero (aka "player character") sprite and your first enemy sprite (you had to have both of these for the last assignment). The details of your animation will of course depend on the specifics of your game, but here are a few examples:
- Imagine your hero is a space-ship of some sort. You could either add "flaming thrusters" or you could add a "left-right tilt" that shows the space-ship at a slightly "tipped" angle from the top as the player moves it left or right.
- Imagine your hero is a cartoonish humanoid of some sort. In this case your character should get a "walk cycle" that shows its limbs moving in a semi-believable fashion to actually induce locomotion.
- Imagine your hero is some other kind of life-form, for example a fish or some energy-blob. You should probably add some kind of "organic wiggle" for the former or some kind of "pulsating goodness" for the latter.
- Imagine your hero is a pumpkin that bounces around like a tennis ball. You'll need various stages of "compression" of the pumpkin as it squishes onto the ground and takes off again.
For your enemies, you're totally on your own, but we are sure you can come up with something cool. There's no hard-and-fast rule for the length (number of frames) of the animation, but we'd like to see something semi-smooth, so three to five frames are probably needed. Note that we expect drawn animation frames/steps, not simply some geometric transformation like rotation or zoom. Except of course if your entire game is using custom vector graphics of your own devising, then you'll also have to devise a suitably impressive way of animating those things...
Please try to follow the ideas you outlined for your game as part of Assignment 2 if at all possible: Don't completely change the look you're going for now that you realize that it's a pain to draw the animations...
Obviously adding animations requires that you add support for animations to your game engine as well. Just like anything else on the screen, the timing for when to display which frame should involve a "delta time" somewhere: animation steps per second not per frame of the game! Of course you may have to adjust things a little to match the overall acceleration/velocity of your characters...
Problem 2: Extended Game Framework (60%)
For Assignment 2, you built a very basic framework for your game. You did this (truth be told) mostly to learn enough about libsdl2 to be moderately comfortable. You won't be able to use it "as-is" for the final game. One reason is that animating a few sprites on the screen is not all you need for a game. You also need a few additional ingredients: a title screen, a menu, and a high-score list. (Of course you could have even more, a "pause screen" perhaps, but those three are the minimum requirement for this problem.)
We talked about various approaches to "high-level game-states" in class and ended up with an approach based on the State design pattern. You are going to use those ideas to implement a new framework that contains title, menu, high-score, and your basic "game" from Assignment 2 (plus the animations from Problem 1). This framework can, if you do it carefully, serve for the whole rest of the course. But you need to think things through in a bit of detail if you don't want to have to redo it later. Here is a list of things we'll look for:
- You have a title screen that identifies your game and your team clearly. Ideally you have something related to the game going in, for example an artist's rendition of either a typical event in the game or some kind of intruiging encounter with a boss. You should have something going on here aside from just showing a picture, maybe you can make the title text "fly in" in some interesting way as it would at the beginning of a movie? Or at least "fade in" from black?
- You have a menu screen that offers at least the following choices to the player: Start a new game, adjust visual brightness, adjust audio volume, display high-scores, and quit. You don't actually have to implement the brightness and volume stuff yet, but it should be in the menu; new game, high-scores, and quit have to work though. It's up to you how you present the menu. You could render it on top of the title image instead of the actual titles, or you could render it on a new background image, or just on a black or white background. Up to you. The menu items should be clearly labeled and it should be obvious how to select them; giving visual and audible cues would be great as well. The menu must be usable with the keyboard (cursor keys to switch around, space/enter to select), but of course you can support mouse or joystick/gamepad as well.
- You have a game screen that basically does what you handed in last week for Assignment 2 plus the animations from Problem 1. Not much else to say here, if the user hits "Q" or selects something on the game screen, it should be possible to get back to the menu screen. If you can resume the current game from there without starting a new one, that would be great (but it's not required).
- You have a high-score screen. You can fake the contents of this, or you can already read them from a file if you want. Since you can't play your game yet, it's hard to make a new high-score of course. But it should be there. Once again, hitting "Q" or some other simple/obvious thing should get the player back to the menu screen.
- You should use the techniques discussed in class to implement your high-level game state. There should be one state "base-class" and four "derived classes," one for each game state required. You should split your code into modules and have each game state in one distinct module. Your main game screen should of course use whatever modules you wrote for the previous assignment, although some slight re-juggling may be needed.
As you add controls for various new features, please remember that we want the escape key to immediately quit your game completely! It shouldn't matter in what state or at what point we hit escape the result should always be that it gets us out safely. (Just in case we can't take all that juicy on-screen goodness anymore...)
- 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
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!