|
Coding style (marks independent of program functionality) |
| |
|
Actual score |
Max score |
|
|
Follows good programming conventions common to all programs (e.g.,
Appropriate source code white space, self documenting names,
clear/simple expressions, methods implementing one task/max 30 lines of
code, appropriate used of named constants): Never (0), Sometimes (4),
Often (8), Mostly (12), Always (14) |
|
14 |
|
|
Follows good Object-Oriented conventions |
|
|
|
|
|
Information hiding: Never (0), Sometimes (1), often (2), Mostly (3),
Always (4) |
|
4 |
|
|
|
Class attributes are logical to the definition (e.g., not variables that
are just local to a method but belong to each instance): Never (0),
Sometimes (2), Often (4), Mostly (6), Always (8) |
|
8 |
|
|
|
Each class (save the "Driver"
and "Debug"
classes) consists of at least 3 methods |
|
6 |
|
|
|
Program decomposition into classes is logical e.g.,
Driver does not include code for the user
interface |
|
5 |
|
|
|
Static variables employed (the attribute of class "Debug"
specified in the assignment description excepted), -4 marks each
instance with a max of 12 marks lost |
|
-12 |
|
|
|
The code for the classes are not included in its own file (-3 each
instance, max of 15 marks lost) |
|
-15 |
|
|
|
Unless strictly required, the parent class not modified (attributes and
methods are shadowed and overridden instead) |
|
-3 |
|
|
Sub total |
0 |
37 |
|
Documentation (marks independent of program functionality) |
|
|
|
|
Header documentation includes full name and tutorial section |
|
8 |
|
|
Some form of versioning system is demonstrated in the header
documentation |
|
2 |
|
|
Each method is documented (similar to documentation for the entire
program but applies only to that method) |
|
6 |
|
|
Program limitations documented |
|
2 |
|
|
Program features documented (cut and paste out of the assignment
specifications acceptable but it MUST be detailed, clear and
specific...the marker must be able to know exactly what features in this
marking key were actually working) |
|
20 |
|
|
Sub total |
0 |
38 |
|
Functionality (only qualify for these marks if the program runs: note
some features obviously requires other features to be implemented before
credit will be granted) |
|
|
Classes listed in assignment description submitted (the class methods
can be largely empty) |
|
5 |
|
|
Each track is properly initialized and displayed at appropriate time |
|
2 |
|
|
Displays clear and sufficiently detailed instructions in the
introduction |
|
2 |
|
|
Game proceeds on a turn-by-turn basis |
|
1 |
|
|
Order of the turns is correct (1 mark per sub-turn in correct order) |
|
6 |
|
|
Displays an appropriate status message when the program ends (quit,
win/lose, tie) |
|
4 |
|
|
SUV and sports car movement menu |
|
|
|
|
|
Displays menus |
|
2 |
|
|
|
Gets user input for the SUV and sports car menu and repeats prompts
until valid input is entered. |
|
2 |
|
|
|
Player can quit/program runs indefinitely until end game condition met |
|
2 |
|
|
|
Cheat menu can be invoked from either car menu. |
|
2 |
|
|
Cheat menu |
|
|
|
|
|
Gets user input for the cheat menu and repeats prompts until valid input
is entered. |
|
2 |
|
|
|
Can toggle debug mode |
|
2 |
|
|
|
Can change fuel of sports car |
|
2 |
|
|
|
Can change fuel of SUV |
|
2 |
|
|
|
Can change location of sports car |
|
4 |
|
|
|
Can change location of SUV |
|
4 |
|
|
|
Can invoke a blizzard in the arctic track during the arctic track
sub-turn in the next turn (current sub-turn has already passed) |
|
4 |
|
|
|
Can invoke a heat wave in the desert track during the desert sub-turn
coming up in the same turn |
|
4 |
|
|
Debug mode implemented |
|
4 |
|
|
SUV can move and consume fuel as specified in the class description
(non-AWD mode) |
|
4 |
|
|
Sports car can move and consume fuel as specified in the class
description |
|
4 |
|
|
Program checks and properly handles when cars run out of fuel |
|
4 |
|
|
SUV can move and consume fuel as specified in the class description (AWD
mode) |
|
4 |
|
|
Arctic track can randomly generate and properly handle the effects of a
blizzard on the SUV (regular mode) |
|
8 |
|
|
AWD mode working properly during a blizzard |
|
4 |
|
|
Desert track can randomly generate and properly handle the effects of a
heat wave on the sports car |
|
8 |
|
|
Program can determine when one or both cars have reached the end |
|
4 |
|
|
Graphical display of output (input may still be console-based) |
|
6 |
|
|
Program has appropriate sounds effects |
|
4 |
|
|
Subtotal |
0 |
106 |
|
Design requirements (may modify the raw functionality score) |
|
|
|
|
Implements static methods (other than 'main()'
and methods that access the "GameStatus"
static attributes) |
Divide functionality marks by two1 |
|
|
Program implemented with a single class (style marks will also be lost) |
Divide functionality marks by two1 |
|
|
Classes don't consist of at least 2 methods (save for the "Driver"
and the class to determine operating mode). |
Max loss of 8 marks to functionality (tallied after the above two
modifiers, if applicable) |
|
|
Functionality not assigned to the appropriate class as specified in the
assignment description |
Max loss of 8 marks to functionality (tallied after the above two
modifiers, if applicable) |
|
UML class diagram (marks independent of program functionality) |
|
|
|
|
Class Track attributes
(3) and methods (3) properly specified and matches actual code |
|
6 |
|
|
Class ArcticTrack
attributes (3) and methods (3) properly specified and matches actual
code |
|
6 |
|
|
Class DesertTrack
attributes (3) and methods (3) properly specified and matches actual
code |
|
6 |
|
|
Class SUV attributes (3)
and methods (3) properly specified and matches actual code |
|
6 |
|
|
Relationship properly specified (multiplicity not needed) |
|
3 |
|
|
Subtotal |
0 |
27 |