Assignment 9: Cleanup and Polish
- Out on: October 28, 2017
- Due by: November 3, 2017 before 10:00 pm
- Collaboration: Team
The ninth assignment is a little bit of a surprise: It's all about cleaning up your code and polishing your game! In the "real world" you never get a week just to clean up and polish your product, but we can afford it here.
Also, we like making the point that "polish" is very important for your final game: nothing should go wrong when you demo it, nothing should look or sound awkward in any way, etc. Why not get started looking professional now?
And you have a BETA presentation coming up soon! Everybody cuts you some slack for the ALPHA, but you better wow the audience for the BETA. You really need to have a fun game!
Please remember that as outlined in Assignment 6, you have to document what you've been doing, including who has achieved what for a given assignment. If in doubt, re-read the relevant sections of Assignment 6 again, they apply in full for this assignment as well.
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: Cleanup and Polish (100%)
First let's make clear that this week is supposed to focus on cleaning up and polishing what you already have so ideally you don't add any new features. However, we won't make that a hard rule, just a guideline. If you really want to "waste" this week by making your game worse instead of better, you're welcome to do that too. It would just be a sad outcome, wouldn't it? So what should you be doing?
- Look over the current state of your game, ideally as a team in one long play-testing session, and decide on the most important things to fix; write this list from the player's perspective, not the developer perspective. What are the things in your current game that players are going to get turned off by? This can be about game mechanics, enemy movement, the explosion sound you never actually added, the music that sounds awful, etc. Put together at least five things that desperately need fixing. And be sure to submit that list when you turn in your game this week!
- Actually fix those things! Keep a record of what you had to do to make those improvements, and submit a short summary of how you fixed each with your list from above. This can be stuff that programmers or artists had to do, doesn't matter.
- Programmers: Get your code into shape! You should not have four huge files, there should be plenty of little modules. You should not be touching every module from every other module. Most of the things in your game should not be hardcoded anymore. Make sure the compiler and your debugging tools are happy, if not track down the problems. And so on, and so forth. The TAs will be more picky than usual in terms of grading the quality of your code!
- Artists: Get your assets into shape! This is the week for finally adding those additional animation frames that you didn't think you'd have time for. This is the week for going over all your artwork and making sure it's consistent in terms of colors and light/shadow direction. This is the week to finally record good voice-overs and to replace the music you ripped off from somewhere else with the real thing that you had been working on. And so on, and so forth. Keep the amount of new assets to a minimum, but polish the stuff you already have to semi-professional levels.
Aside from your prioritized list of things to fix and a description of what you actually fixed, please also hand in a short summary of how you improved your code and assets overall. You should already be doing this since Assignment 6 anyway, but this week it's extra important!
Please turn in a gzip-compressed
tarball of your assignment.
The filename should be
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.
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!