Assignment 11: An Honest Free for All
Out on:
April 21, 2008
Due by:
April 28, 2008, 3:00 pm (before lecture)
Collaboration:
Teams
Grading:
Packaging 10%, Design 20%, Style 20%, Functionality 50%
Overview
The eleventh (!) and final assignment deals with battle ships one last time. It's a very straightforward assignment: You can do whatever you want to improve your battle ships game! Of course your program has to be able to do whatever was required in the previous two assignments of the project, those requirements still stand. But beyond that, it's really up to you! Try to be extra-smart with your generals! Try to make the user interface really kick backside! Use colors! Add sound effects! Whatever! :-)
This is a team assignment, and all of you should
know which team you're in (I hope).
Decide early on who is going to be responsible for submitting
the assignment and when.
Make sure to include all the relevant information (who is in the
team?) in your README file!
Decide on a schedule early on as well, nothing delays working
in a team more than having to schedule meetings ad-hoc; compare
your schedules and arrange to meet in advance!
All members of a team will receive the same score for the product
you submit together.
After the assignment is over, each of you will be asked to
evaluate
the contribution your partners and yourself made to the assignment.
Rules of the Game
There is one minor change compared to the previous two iterations of the final project: You are not allowed to cheat anymore! So if you had a cheating battle ship program for Assignment 10, you have to take out any code related to cheating, otherwise you'll lose a lot of points on this assignment. It's an honest Free for All, just like the title implies. You are of course allowed to keep code that detects cheating, but be very careful with your accusations!
Development Tasks
In updating your current Battleships program, you should also
update your design as documented in your README
file.
Include a short section that discusses the improvements you
made compared to the previous version, and explain how you
had to adapt your design and implementation to make things
work.
For this assignment you must include
a UML class diagram as well! You should have
seen enough of those by now to know how to make one, and there
are tools to draw them as well (just Google around). Please make
sure that your diagram is in PDF format
in the submission.
Finally, if you want to reflect on your team experience as a
whole after three weeks of working together and what you think
you learned from it, please do so.
Enjoy!
Tournament!
Note that a decent part of your score for the final assignment will depend on how well you compete against the programs by other teams in the course. We'll run a big tournament that pits all of the programs against each other to find a winner. The winner will also be announced after final presentations on the last day of classes a receive a roaring round of applause!
Hints
You can find an archive of all available versions
of the battle program
here.
Try to make yours beat all the others! :-)
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs120-assign-11-teamcode.tar.gz
with teamcode replaced by the code
assigned to your team for your repository and your mailing list.
The tarball should contain no derived files whatsoever
(i.e. no executable files),
but allow building all derived files.
In particular, make sure you don't submit all those
.svn folders from your repository!
Include a README file that briefly explains what your
programs do and contains any other notes you want us to check out
before grading.
Include a Makefile to build your project.
Grading
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to C++ programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable documentation, good use of private
and const, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization (into files
and classes) and the proper choice of algorithms and data structures.
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your programs cannot be built you will get no points whatsoever.
If your programs cannot be built without warnings using
g++ -ansi -pedantic -Wall -Wextra -std=c++98 -O -Wabi -Weffc++ -Wctor-dtor-privacy -Wold-style-cast -Woverloaded-virtual -Wno-pmf-conversions -Wsign-promo
we will take off 10% (except if you document a very good reason).
If your programs cannot be built using make we will
take off 10%.
If your programs fail miserably even once,
i.e. terminate with an exception of any kind or dump core,
we will take off 10%.
Finally, make sure to include your name and email address in every
file you turn in!
