Assignment 2: Insert Coin(s)!
- Out on: September 9, 2017
- Due by: September 15, 2017 before 10:00 pm
- Collaboration: Team
For your second assignment in 601.255/256 you'll again do two very different things, but you'll do them as a team this time:
- First you'll write up your team's proposal for the kind of game you'll build this semester.
- Second you'll put together the very basics of a game engine as outlined below. Note that you're welcome to exceed the minimum requirements, just make sure you're not missing any of the expected pieces.
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: What's your game? (30%)
You had to write up your personal proposal for a two-dimensional top-down action adventure game for Assignment 1. Now it's time to consolidate the ideas each of your team members had into one proposal. Ideally you discuss your individual proposals in your team and try to come up with something that everybody can live with. Note that it's not necessary that everybody love it, but at the same time nobody should hate it either, that would be bad.
Please try to take into account any feedback you have received on your first proposal. If we already said "This is way too ambitious!" or "This doesn't sound fun at all!" or "This isn't even the right genre!" or whatever, you should not try to sell us the same thing again. Here some "general" advice for your combined proposal:
- Make sure that you can sensibly defend your vision/design as a two-dimensional top-down action adventure game. There must be action (of some sort), exploration (of some sort), a progression (of some sort), etc. If you're missing these things, revise your proposal to actually include them.
- Streamline your backstory, if you have one, especially if it's currently a little too "all over the place" as it were. Ideally you want the backstory to come out in play, without too much in terms of introductory cut-scenes. You'll want to make it obvious who the bad guys are by designing them with a "bad-guy look"; or by having them shoot at the player; or whatnot. Walls and walls of text are not something most players will have the patience to read. If you have no backstory so far, make up something short and sweet! (It's okay to rip something off, but there needs to be something the game is about.)
- Identify your core mechanic. There may be many things you'll want the player to be able to do, but ideally a game centers around one thing that remains (mostly) consistent throughout, and that one thing already makes the game fun. So if you currently talk about maze puzzles and shooting enemies and using the right powerup and having switchable player characters... Focus on one aspect and make the rest "nice to have" but not essential for the near future.
- There are things everybody in gaming knows are "hard" to pull off. Things like procedural generation, destructable environments, real-time networked multiplayer, etc. If you are currently thinking about one of these "monsters" please think very carefully about whether you must keep it for a fun game. Chances are you do not, and by not wasting any more cycles on those "hard" things you'll actually build a much better game. Simpler in way, maybe, but certainly more polished.
There are many other general pointers, but these should suffice. Think about them, talk them over, use the more specific feedback you'll still get, etc. And come up with an awesome proposal.
Please see Assignment 1 for the details you should have addressed already. Make sure you still follow the same basic structure and format we outlined there. If you forgot to address something from Assignment 1, add it now. It's your last chance!
Problem 2: The Most Basic Game Engine (70%)
Your actual game project starts now, with this problem. We have some minimum requirements for what we want to see on the screen when we run your game, but please don't take these as strict limitations for what you can do. You can do more, but you need to be careful to cover at least all the required basics! Here are the on screen, interactive minimum requirements:
- There are two kinds of objects on the screen, the player's hero and some kind of enemy. To be precise, there's (for now) one player and 5 enemies. The player looks one way, the enemies look another way, and ideally your team will produce basic graphics for both. Worst case, there's a "red blob" for the player and a bunch of "blue blobs" for the enemies, but hopefully you can do better.
- The player can control the hero with the cursor keys of the keyboard. The enemies move randomly around the screen (not too erratic please!). Neither player nor enemies can leave the screen. When enemies hit a screen boundary, they turn around. When the hero hits a screen boundary, their movement in that direction stops. When the hero collides with an enemy, a short (and not too annoying!) sound effect is played; ideally that's a sound effect someone on your team produced. Worst case, use something like this to produce a random sound.
- Hitting the escape key stops the entire thing immediately; no "Are you sure?" checking, no annoying end-credits, just stop everything.
Here are the in code, programming minimum requirements:
- All your on-screen movement should be (at least) time-based as discussed in lecture. This means, in particular, that acceleration and velocity are "per second" and not "per frame". Methods you write/call to compute any on-screen movement should have a "delta time" parameter.
- All your on-screen drawing should be hardware-accelerated at least in
principle. This means, in particular, that you draw
Textureobjects using the
RendererAPI of libsdl2, not the software-based drawing stuff that works with
- You'll probably want to use
Rectobjects to do collision detection for now, that's going to be the easiest choice; pixel-perfect collisions or otherwise more sophisticated methods might be appropriate later, but could take a long time to hack right now.
- There should be at least one class to represent a "sprite" on screen, meaning something that, for example, can draw itself, you can compute collisions with other "sprites" for, can update its position based on things like acceleration, velocity, and delta time, etc. (If you're familiar with alternative architectures, for example component-based design, that avoid conflating all these concerns in a single class, feel free to use that instead; but use it correctly!)
- Cleanly seperate your code into modules/files, classes, methods, functions, whatever. Do not hand us a single source file for this, we should be able to see that you know how to build a system out of independently developed/compiled parts.
- Also make sure that you have an appropriate
Makefilefor a clean build on Linux this time. (If in doubt, one of you should take on the role of "Linux producer" and have that as part of their permanent job description for the rest of the semester.)
You can look at this problem (and the ones on the following assignments) in two ways: As an "obstacle" that keeps you from building "your" game, or as a "checkpoint" for what should be possible in "your game" for a given week. Obviously I recommend taking the latter perspective, but if past semesters are any indication, the former sometimes wins out. None of the assignments are designed to "ruin your plans" in any way, indeed they are (usually) open-ended enough so you can actually be (much) further along with your game if you want to. As we said above, you just have to make sure that whatever we want to see in a given week is actually there in some form or another.
- 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!